WO2008099420A2

WO2008099420A2 - System and method to dynamically provide a contract bridge to enable control of transactions over multiple channels

Info

Publication number: WO2008099420A2
Application number: PCT/IN2008/000084
Authority: WO
Inventors: Ajay Madhok
Original assignee: Ajay Madhok
Priority date: 2007-02-12
Filing date: 2008-02-11
Publication date: 2008-08-21
Also published as: WO2008099420A3

Abstract

The present invention relates to a method for controlling a transaction between a source identity and a destination identity. The source identity belongs to a trust domain A and the destination identity belongs to a trust domain B. The method includes initiation of a service request from the source identity. Further, the method includes formulation of a contract bridge between the trust domain A and the trust domain B. Moreover, the method includes controlling the transaction based on the formulated contract bridge. The source identity and the destination identity transact a single or multiple channels. Furthermore, the method includes controlling the transaction based on an identity contract between the source identity and the destination identity.

Description

SYSTEM AND METHOD TO DYNAMICALLY PROVIDE A CONTRACT BRIDGE TO ENABLE CONTROL OF TRANSACTIONS OVER MULTIPLE

CHANNELS

FIELD OF INVENTION

The invention relates generally to systems and networks enabling communication and / or financial and / or any transaction in general. In particular, the present invention relates to providing a system and method of providing transaction control to identities belonging to same or different trust domains using single or multiple channels for conducting a transaction.

DESCRIPTION OF RELATED ART

In the past, before phenomenon like the internet and globalization changed the face of world economy and commerce, people lived in small communities wherein two individuals would do business by meeting face to face.

Since the transactions materialized face to face using cash or barter, there was never a need to authenticate and / or authorize the transacting parties. Rarely, when a person moved from one city to another to do business, they would carry with them a letter of introduction and / or do business using a letter of credit. The letter of introduction acted as a referral for authenticating the person, whereas the letter of credit, issued by a bank acting as a trusted third party between two transacting entities, asserted that the other entity would get credited should the transaction go through.

In today's networked and distributed world, a transaction requires the transacting parties to have a trusted relationship and / or a secure and trusted channel between them. However, the transacting parties may come from different geographies, may connect through different networks, applications, clients etc. Consequently, the means for establishing a common ground for security and trust was missing. This has given rise to creation of 'Digital Identity¹ that returns the ease of use and trustworthiness of identity-based transactions that existed when interactions were done face-to-face with parties that already knew each other, at the same time maintaining the security and accountability for the transaction. In short, the Digital Identity reflects the identity of an end point in its interactions where transacting parties may never meet face-to-face.

While possessing digital identity is necessary, it is not sufficient. The question that still hampered commercial transactions was that the transacting party was known 'to whom' and / or belonged 'to which trust domain'. An identity known to a particular trust domain was not enough for related transactions to be accomplished on a wider scale. The credit worthiness (or reputation) and such attributes associated with an Identity were caught up in a single domain. What happens when this identity, wants to do transactions outside its trust domain? Carrying out such a transaction, where the end points belonged to different trust domains, required either / both end points to federate their respective users and / or identities registered and their respective data and / or attributes present with them or unless the distinct domains had an understanding (contracts) among themselves there was no way transactions could be accomplished between the parties. For any such transaction, apart from authenticating the identity, there is also the question of setting the limit or constraints to resources accessible to / shared with the identity. This gave rise to a third party trust domain, akin to an escrow agent. This third party would guarantee transaction accomplishment between the domains and provided a secure trust bridge (something like letter of introduction & credit mentioned earlier). Porting the attributes (like credit worthiness / reputation) outside the trust domain still remained a problem that did not work in all scenarios and / or across all trust domains. In other words, the problem of sharing and complying with policies, preferences and attributes for these shared resources, across trust domains still persisted.

For a transaction to go through between any two end points, the following three pre requisites must be met- regardless of the type of transaction or the transaction channel or mechanism: • Authentication: In order to bring in Trust in the system, the two end points need to be persistently identified, regardless of the client or device they use, or the trust domain they come from

⁰ Authorization: The authorization and privileges such as credit worthiness associated with the identity at each end point has to be known

^■ Attributes: required for the transaction (such as account number, for a financial transaction OR mobile number, for a communication transaction) have to be understood by both end points and their underlying domains.

Given that a network / trust domain owns applications and applications owns users- their rights, privileges, authorization of the user are known only within that application or that trust domain.

Likewise attribute semantics are known / understood only in the trust domain that the end point belongs to. For a transaction to go through, all three pre-requisites must be met, understood and exchanged between the trust domains.

Taking the example of an Online Credit card transaction - Several entities are involved in carrying out an online credit card transaction, which includes the card holder, the Banks - card issuing and merchant, the merchant and payment gateway. For a POS (Point of Sales) transaction, the authentication of the card takes place between the merchant and the issuing bank over the proprietary card network (e.g. - VISA net), whereas an online transaction involves the transfer of the merchant / order information (merchant ID, signature, transaction amount and the sender's URL address) and card holder information through a secure link to the payment gateway, which passes the information to acquiree (merchant's) bank. The acquiree bank then contacts the issuing (customer's) bank through a third party processor which in-tum connects with the proprietary card network (such as Visa Net) for payment authorization. Post transaction with the issuing bank, the acquiree bank sends back a confirmation (or a failure notification, based on the status of the transaction between acquiree and issuing banks respectively) to the merchant / consumer. Fig. 1 shows an example of such a transaction between two parties that use a trust bridge 102 to accomplish the transaction. As in the above example, a contract bridging channel is usually like a credit card network VisaNet, where VISA acts as the trust bridge 102 between the two domains of the issuing Bank 104 (the bank that issues credit card) and the Acquiree bank 106 (the bank that the merchant uses to collect the money from consumer).

The procedure is inherently dependent on the proprietary card network for assertions (authentication, authorizations and attributes) to carry out the transaction. The solution for providing a secure trust bridge 102 to the identities at either end point requires setting up a whole private network among users, merchants & domains. Instead, what is needed is the utilization of the existing networks to provide such trusted bridge across transacting domains.

To further add to the limitation of mandatory utilization of proprietary networks for carrying out the transaction, the identities involved in the transaction are tied down to their respective concrete Identifier on the domain

/ network / channel for executing the transaction. In the previous example, the user is tied down to his card number, which is his concrete identifier on the network for carrying out the transaction, the selection of which is a manual process in the current scenario.

In this respect, any transaction between real world identities takes place using concrete identifiers that are bound to a specific domain / network. Exchange of concrete identifiers exposes either identities to the risk of SPAM and possibly unauthorized access. Control over any transaction is exercised using a set of control policies, that are tied to the identifier for the respective channel / application and / or the duration of the transaction and hence the control defined using these is valid only on the respective domain / channel / application or even just for the respective temporal session or the type of transaction initiated between the identities involved. In case of change in any parameter for the transaction, a new set of rules / policies are referred to / defined. Moreover, these controls are not extended to artifacts and / or attributes exchanged during the transaction / session. The control extended through set policies, is usually single dimensional in nature, amounting to just one or two levels (ordinarily access and / or privacy) as defined in the control hierarchy.

In a cross domain transaction and / or transaction involving multiple accounts, the same Identity is asserted more than once. An example worthy of noting here is that of an online auctioning system. An auction site requires a Credit card or a Peer-to-Peer global online payment account (like paypal) of the buyer to conclude a transaction. The procedure requires two separate IDs, one for login to auction site, the second for making payment, for any transaction. To accomplish a transaction, the same identity has to be asserted more than once, because of the absence of a seamless linkage between the two identifiers of the same identity. Various parameters related to the identity and relevant for both channels / accounts (such as credit worthiness / reputation) may exist on both in a non portable format. Further, the existing system does not offer users, the flexibility of setting policies for automatically selecting payment modes / sources depending on a variable (temporal) set of parameters like context of the identity or the purpose of payments.

A multi-user access account (belonging to a Peer-to-Peer global online payment account) offers the end user the flexibility to link an account with multiple users, each of the linked users can have a function or a combination of functions (like withdrawing payments, adding funds, editing profiles, administering more users etc.) associated with their respective logins for the account. These are usually static in nature and do not offer flexibility to associate different credit / debit limits with the provisioned users and cannot be linked to different payment sources. The invention aims at overcoming the limitations existing in the current systems by unifying the identifiers for an identity on different domains / channels / applications using single, abstract and persistent identifiers and providing transaction control to these real world identities in same or different trust domains that may use multiple channels for executing a transaction. SUMMARY

An object of the present invention is to provide a system and method to use single, abstract, persistent (transaction / channel independent) identifiers that unify concrete identifiers, that may belong to different domains / channels / applications, for carrying out transactions across different trust domains, without requiring the trust domains to federate their users or related information.

An object of the present invention is to provide a system and method of forming a contract bridge between two or more arbitrary identities that may belong to different trust domains, over public infrastructure.

An object of the present invention is to provide a system and method of extending multidimensional control over a transaction between arbitrary end points using single, abstract, persistent (channel / transaction independent) identifiers, where both / either identities involved can control the transaction.

An object of the present invention is to provide a dynamic (on-the-fly) control mechanism that may be disassociated from the actual transaction mechanism and / or communication mediums, using transaction / communication independent identifiers. The dissociation may be consequent to temporal values / changes in associated parameters of transaction / communication.

Further, an object of the present invention enables linking of these channel / transaction independent identifiers and / or channel / application specific identifiers, in a manner that enables / disables / screens / re-routes and / or alters presentation of transaction(s) and / or related content for an identity over underlying channel(s) / application(s), subject to an individual / combination of control parameters defined by the same / other identity(s), such as specific time duration for inbound / outbound communication, on-the- fly screening of inbound numbers, permissible list of channel(s) / application(s) identifiers, keywords in content, subject of the transaction, reroute transaction based on unavailability etc. Further, an object of the present invention is to provide a mechanism to aggregate Identity specific data such as attributes / metadata including, but not limited to, preferences or parameters like state, presence, location, availability, profile, age, sex, hobbies, interests, dislikes, affiliations, etc., from various underlying channel(s) / application(s) to form an augmented layer of Identity specific data that can then be associated with / pushed to any underlying network / channel / application.

An object of the present invention is to record a transaction and related metadata and associate control levels, as defined in the control hierarchy, with individual recorded artifacts), depending on transaction parameters such as relationship between the Identities, channel(s) / application(s) / domain(s) of end points etc., that maybe defined by either identity.

An object of the present invention is to provide a temporary / permanent storage for recording a transaction and related metadata for an identity, based on identity specified multi-dimensional parameters (such as a combination of identity attributes, relationship with the transacting identity, purpose of the transaction etc.).

An object of the present invention is to provide a mechanism for permitted outreach or permissions marketing, wherein the aggregated information or advertisements are pushed to the end points before / during / after a transaction based on Identity specified multi-dimensional parameters (such as a combination of identity attributes, context, availability on devices / channels etc.) and / or relationship and / or capabilities, using transaction / communication independent identifiers. An object of the present invention is to provide a mechanism for asynchronous transaction requests for an identity on an existing physical / logical network. Transactions originating from these artifacts may be handled / resolved based on defined set of rules / relationships associated with the source and or requesting identity. DEFINITIONS AND PRESUMPTIONS

CONTRACT BRIDGE

A Contract bridge is formulated between distinct trust domains to agree on how an identity belonging to Trust Domain A can assert AAA (authentication, authorizations and attributes) to another identity belonging to Trust Domain B:

1. Authentication of an identity that Trust Domain A presents to Trust Domain B

2. Authorizations that Trust Domain A would like Trust Domain B to accord to the identity being presented

3. Attributes that Trust Domain B will need to complete the transaction with the identity being presented by Trust Domain A In this context, the attributes may include relevant elements of the control hierarchy (access, usage, privacy, synchronization, expiry and compliance) and / or parameters required to service the transaction and / or policies to guide the terms and conditions for the transaction and / or provide desired quality of service, as specified by identity(s) at either end or as per equivalent quality of service in destination trust domain.

Moreover, a contract bridge may involve one or more physical / logical paths / networks including any multiplicity of different types of channels.

Certain transactions might involve more than two identities. In which case, the contract bridge would comprise of single or multiple paths.

CONCRETE IDENTIFIER

An Absolute address, specific to a domain and / or an application / channel, used to represent a real world identity. IDENTITY

An identity represents a real world entity that may be represented by a concrete identifier or a single, abstract, persistent identifier.

CONTROL

Control is defined as enforcement of a set of constraints over an entity / exchange / action. The control hierarchy comprises of several levels of constraints exertion -

• Access : Applying identity specific restriction

• Privacy : Applying purpose specific usage restriction

• Usage : Applying distribution specific usage restriction

• Synchronization : Applying synchronization restrictions across domain / channel / application boundaries

• Expiry : Applying recall / invalidate restrictions

• Compliance : Applying enforcement and monitoring of policies

TRANSACTION

A Transaction is defined as an exchange between end-points that may belong to same or different domains. A transaction usually involves two identities (source and destination) but could extend to involve multiple identities to form an n-way exchange. There may be sharing / interchange of artifacts in a transaction that may prevail for the temporal session or become persistent for identity defined time period.

RELATIONSHIP

Throughout the scope of this document, Relationship is referred to as a set of rules / policies defined by each identity with respect to the other, to alter parameters of transactions originating from the other, based on its current set of preferences.

The terms Relationship and Contract are used synonymously throughout the document.

BRIEF DESCRIPTION OF DRAWINGS

The preferred embodiments of the invention will hereinafter be described in conjunction with the appended drawings provided to illustrate and not to limit the invention, wherein like designations denote like elements, and in which:

Figure 1 shows an example of a transaction between two identities that use a trust bridge to accomplish a transaction (Prior Art);

Figure 2 is a block diagram that illustrates logical representation of a channel / transaction independent identifier as per an embodiment of the present invention;

Figure 3 is a block diagram illustrating the transaction between identities represented by single, abstract, persistent (channel / transaction independent) identifier(s) and / or concrete identifier(s) where at least one identity is represented through a channel / transaction independent identifier, as per an embodiment of the present invention;

Figure 4 is a block diagram that represents exchange of a resource or its digital representation between Identities;

Figure 5 is a block diagram that illustrates the system elements of the invention, in accordance with an embodiment of the present invention;

Figures 6a, 6b and 6c illustrate a flowchart of the method carried out for resolving the end points for an identity and negotiating control before and during a transaction;

Figure 7 is a block diagram that represents linking of identities represented through single, abstract, persistent identifiers for the purpose of extending control; and Figure 8 is a block diagram that represents a technique for permitted outreach or permissions marketing for aggregated information including (but not limited to) advertisements and / or content (like news, blogs etc.) for channel / transaction independent identifiers. While the invention is susceptible to various modifications and alternative forms, specific embodiments of the invention are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the invention to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives failing within the spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF DRAWINGS

Just like the physical world, on a digital network, an observer's perception of the digital identity of an entity is mediated by the subjective viewpoint of that observer. Therefore, in order to attribute a digital representation of an entity, the observer (the other end-point) has to Trust that the representation presented indeed relates/pertains to the entity and thus the observing end-point can grant some privileges, authorizations, etc. to the presenting end-point.

Further, the presenting end-point may need to provide some selective access (depending upon who the other end-point is and the temporal context of the transaction) to some of its informational attributes and any contextual data required for the transaction.

In the network world today, this exchange before the transaction (claims asserted by the presenting end-point, the provisioning of selective access and privileges by the other end-point, and the selective access to identity attributes and transaction context specific data) is done within the same trust domain or domains that are governed by a central authority where the user identities and their authorization is federated. In the absence of a single central authority, the transaction has to be mediated by a mutually known and trusted third party. This mediation before a transaction, whenever the end-points belong to different trust domains, is required for three reasons: a. lack of Trust (how to provide a codified assurance of the identity of one entity to another), b. lack of knowledge of authorization and privileges of the entity

(given that the Identity and its authorization and privileges are not known outside its originating domain (unless the users from both domains are federated, in which case the two domains act as a single domain) and c. lack of interoperability (what format and semantics to use to represent and provide the data so that it can be understood and consumed by the other end-point)

A private Network such as a Credit Card Network like VisaNet, is often used to mediate and act as the trusted third party providing a contract bridge between the domains of the Issuing Bank and the Acquiree Bank, to enable a transaction.

In the absence of a trusted third party, or whenever the two end-points are on a public network, the pre-conditions for a transaction (Authentication (Trust), Authorization and selective Attributes (data) exchange)) are not met. Consequently, the web remains a global library and has not become the promised global market place and on-line payments are only 2% of all payment transactions

This is because, in a decentralised network like the Internet, such extended identity relationships effectively require both a. the existence of independent trust relationships between each pair of entities in the relationship b. and a means of reliably integrating the paired relationships into larger relational units so that their privileges and authorizations can be derived c. and if identity relationships are to reach beyond the context of a single, federated ontology of a single domain, identity attributes must somehow be matched and understood across diverse ontologies / that can interoperate ontologically-diverse representations of digital identity and any data that might be required to be exchanged The objective of this invention is a method to enable transactions by providing Control before Transaction to two or more identities belonging to possibly different domains. It enables them to conduct a transaction without requiring the trust domains to federate each other's users or employ a private network to exchange attributes necessary for the transaction. It enables two or more identities to communicate over control channel(s) / network(s), which may be distinct from the transaction channel(s) / network(s), before / during / after a transaction, to alter parameters governing the terms of transaction and related artifacts between the source and destination identities.

It aims at solving the problems of transacting parties that communicate through multiple channels in the first place, wishing to unify their relationship and related parameters across those channels, be it for business purposes or for end-user convenience.

For end users, the concept of negotiating before transacting is useful when setting up a relationship with service providers on the Internet - one may want to have one ID whether dealing with a flickr account or an mobile operator - and they want to be able to negotiate those contracts over a separate channel (i.e. through the web) whether or not the provider provides services or goods through the Internet, over a mobile network, or through the mail. The invention aims at providing a system and method of dynamically negotiating control over any underlying networks / channels based on channel and / or transaction independent identifiers. The method creates a dynamic contract/relationship bridge for Authentication, Authorization and Attribute exchange can be controlled and mediated before the transaction without using a central authority, or user federation or a shared ontology. In general, Identifiers used in transactions are resolvable and machine- understandable, such as a credit card number or an e-mail address, so that they can be de-referenced into the entity they represent.

The method uses abstract identifiers that are intended to be public and easily discoverable identifiers (also called omni-directional and universal) such as the XRI and brings the control to the control of both the end-points. A key feature of the method is the dynamic construction of trust relationships, and the possibility of selective disclosure from one entity to another of transitionally relevant information. Figure 2 is a block diagram that represents an identity 202 as a single, abstract, persistent (channel / transaction independent) identifier. This procedure is capable of encompassing various concrete identifiers 204 belonging to different addressing domains through abstraction and static / dynamic resolution. The resolution process for determining the end point which an identity 202 gets resolved to for completing the transaction is detailed as a part of procedure described under Figure 4.

Figure 3 is a block diagram that represents transaction(s) using such identifiers 304a and 304b. For any inbound or outbound transaction, the location of the relevant end point takes place based on a resolution process using a set of criteria which may depend on current set of control parameters pertaining to / defined by the identity or representative authority. The Identifier 304a and 304b Abstraction and Resolution procedure converts various formats of the underlying concrete identifier(s) 302a and 302b into a single, abstract, persistent (channel / transaction independent) identifier such as identifiers 304a and 304b, which is further processed by the transaction framework (comprising of single / several transaction networks) to execute the transaction.

The selection of the control network 306 and / or transaction network(s)

308 and the terms of the transaction are dynamically negotiated, depending on the terms of the contract between the negotiating identities 304a and 304b and / or temporal values / changes in associated parameters of transaction / communication. If the identities 304a and 304b belong to different trust domains, a Contract bridge is formulated between the distinct trust domains to agree on how an identity belonging to Trust Domain A can assert AAA (Authentication, Authorizations and Attributes) to another identity belonging to Trust Domain B, the steps for which are listed below - 1. Authentication of the identity 304a that Trust Domain A presents to Trust Domain B

2. Authorizations that Trust Domain A would like Trust Domain B to accord to the identity 304a being presented

3. Attributes that Trust Domain B will require to complete the transaction with the identity 304a being presented by Trust Domain A. Attributes presented include (but are not limited to) relevant elements of the control hierarchy (access, usage, privacy, synchronization, expiry and compliance) and / or parameters required to service the transaction and / or policies to guide the terms and conditions for the transaction and / or provide desired quality of service as per equivalent service in destination trust domain and / or specified by identity(s) 304a and 304b at either end.

On completion of the assertions, the identities 304a and 304b can then, in a trusted manner transact over the negotiated channel (s) / network (s) 308 with same / different communication modes (i.e. - encrypted vs. unencrypted messages, message vs. stream oriented transactions, between different type of network endpoints for each identity etc.).

The control mechanism employed is independent of the transaction mechanism and allows both identities 304a and 304b (and any number, if there are more than two identities) involved in a transaction to control, block, permit, or otherwise alter the parameters of a transaction before the transaction takes place.

The invention allows for transfer of parameters such as credit worthiness / reputation as a part of the attribute assertion which facilitates and enhances the logic for transactions between identities 304a and 304b belonging to different trust domains and / or portable reputation for an identity represented by a single, abstract, persistent (channel / network independent) identifier. An application of the invention includes a web service interaction between two or more negotiating identities. They initially communicate over the internet by resolving each other's identifiers into web-services end points, conduct the initial negotiations on the internet and then (with a token or any other relevant mechanism) begin communication on the mobile or any other network (such as a payment network like VisaNet) which has no notion of this control layer.

The invention provides a mechanism for developing randomized or multi-network authentication and / or authorizations as part of enhanced security and / or privacy options for an identity and / or a transaction.

Figure 4 is a block diagram that represents exchange of a 'resource' 402 between Identity A 404 (requesting identity) and Identity B 406 (identity with the resource). The following sequence of steps broadly describe the sequence carried out for completing such a transaction - 1. Identity A 404 requests for a 'resource' 402 from Identity B 406.

2. An Identity Centric Mediation Service 408 looks up for the contract governing the sharing agreement between the identities.

3. The resource 406 is then transacted if permitted by the contract controlling the resource. A resource 406 may be referred to as identity specific information or data, including but not limited to an identity's context, location, presence on networks and / or channels and / or applications, an identity's attributes, profiles and preference information and / or artifacts shared by the identity. A contract could enforce control constraints including access, privacy, usage, synchronization, expiry and compliance on the shared 'resource' 406 before, during or after completion of a transaction.

Figure 5 is a diagram that illustrates the system elements of the invention, in accordance with an embodiment of the present invention. The system elements are used for transaction between a source identity 502a and a destination identity 502b.

The figure illustrates the following system elements: ■ RCP / PCP / SCP - Requestor Service Control Point 504a / Provider Service Control Point 504b: Source / Destination Identity's Service Control Point. A service control point entails the application logic (what gets fetched and from where) for resolution of end points for an identity and invoking sub-services for all transaction requests.

■ RSP / PSP / SAP - Requestor Service Access Point 506a / Provider Service Access Point 506b: Source / Destination Identity's Service access point. An access point acts an entry / termination point for any transaction request; it is essentially a request proxy which forwards all transaction requests to relevant control points.

^■ GRS - Global Resolution Service 508: Repository of all identity specific metadata. It returns references to various data authorities and end points for an Identity.

^■ Discovery Service - A discovery service acts as a gateway or interface for gathering all identity specific data. It may or may not be distinct for a source and destination identity.

^■ Identity Authority - Requester Identity Authority 512a and Provider Identity Authority 512b are responsible for authenticating the identities / end points involved in a transaction. It may or may not be distinct for a source and destination identity.

^■ Transaction Parameters Authority -Transaction Parameters Authority 514 contains identity and / or transaction specific data / parameters such as an identity's temporal context, network state, network latency etc. that can be employed in conjunction with contracts by either / both identities and / or representative authorities for negotiating the terms of the transaction and / or artifacts exchanged during a transaction. A Transaction Parameters Authority 514 may or may not be distinct for a source and destination identity.

^■ Attribute Authority - Requester Attribute Authority 516a and Provider Attribute Authority 516b contains all identity specific attributes (mostly static but can include dynamic attributes) like an identity's temporal state, location, presence on associated networks / channels / applications, an identity's profile (hosted and / or aggregated from profiles scattered on various networks / channels / applications), its preferences (like pre and post filters on transaction notifications, organizing / viewing preferences at either ends etc.) etc. Requester Attribute Authority 516a and Provider Attribute Authority 516b may or may not be distinct for a source and destination identity.

■ Relationship Authority - Requestor Relationship Authorities 518a and Provider Relationship Authority 518b holds the relationship contracts and / or policies defined by identities at either / both end points, for governing the terms of the transactions with the other. Requestor Relationship Authority 518a and Provider Relationship Authority 518b may or may not be distinct for a source and destination identity.

Various authorities for an Identity could be hosted by a single service provider or could be distributed between different providers. Each authority could host / aggregate identity specific data such as attributes, metadata etc.

Figs 6a, 6b and 6c illustrate a flowchart of the method carried out for resolving the end points for an identity and negotiating control before and during a transaction. The method starts at step 602. At step 604, RSP 506a receives a service request from source identity 502a. An application of source identity 502a creates and sends the service request to RSP 506a. On receiving the service request RSP 506a finds RCP 504a for this service. At step 606, RCP 504a sends a request for end points of identity service and discovery service of source identity 502a. The request is sent to GRS 508. Thereafter, at step 608, RCP 504a receives the information about end point of the identity service and the discovery service of source identity 502a from GRS 508. At step 610, RCP 504a gets the end points of source identity 502a authenticated from Identity Authority 512a. RCP 504a then passes back the sign-on token to ECP (Enhanced Client and Proxy - Requesting Application + RSP 506a). RCP 504a also receives an assertion from Identity Authority 512a.

At step 612, RCP 504a sends a query for a contract of source identity 502a with destination identity 502b to the discovery service of the source identity 502a. The discovery service forwards the query to Relationship Authority 518a of source identity 502a. The query is answered by Relationship Authority 518a, which provides details of the contract with destination identity 502b to RCP 504a via the discovery service. At step 614, RCP 504a determines all the attributes that need to be passed to PSP 506b of destination identity 502b as part of the Authentication, Authorization and Attribute (AAA) Assertion. The attributes are derived from the contract of source identity 502a with destination identity 502b. RCP 504a of source identity 502a also gets the service end points for SCP 504b of destination identity 502b. At step 616, RCP 504a sends a request package containing the attributes to Mediation Service 510.

Mediation Service 510 transforms an assertion in format A such as SAML V1 to another format such as Liberty Alliance SAML 2 implementation. Mediation Service 510 transforms the request package data to a format that is acceptable to and adheres to the semantics supported by the service provider of destination identity 502b. Thereafter, Mediation Service 510 sends the package as a Secure Signed Token to PCP 504b of destination identity 502b.

At step 618, the request package is received at PCP 504b from mediation service 510 in a compatible format with PCP 504b. At step 620, PCP 504b sends a request for the identity authority and discovery service of destination identity 502b to GRS 508. At step 622, the relevant information is received at PCP 504b from GRS 508. At step 624, a request is sent by PCP 504b for the contract of destination identity 502b with source identity 502a to the discovery service. The request is forwarded to Relationship Authority 518b of destination identity 502b by the discovery service. The validated contract is obtained by PCP 504b from Relationship Authority 518b via the discovery service. At step 626, a request is sent from PCP 504b for the attributes and transaction parameters to the discovery service of destination identity 502b. The information is received at PCP 504a from Attribute Authority 516b and Transaction Authority 514 of destination identity 502b via the discovery service of destination identity 502b. At step 628 a request result is sent from PCP 504b to PSP 506b. These may be verified by destination identity 502b before forwarding to source identity 502a. At step 630, the request result is sent to RSP 506a from PSP 506b. At step 632, RSP 506a selects an appropriate channel to complete the transaction. RSP 506a also selects an appropriate identifier for the transaction.

Either identity could dictate controls (including but not limited to access, privacy, usage, synchronization, expiry and compliance) over artifacts or references linked to artifacts exchanged / logged (recorded) during any transaction during and after completion of the transaction. The invention provides a temporary storage for transaction data and / or artifacts for the purpose of placing various controls over the shared data. The transaction data could also be stored permanently for archival or any other purposes such as reputation monitoring.

The invention allows for the transaction request to originate from an existing physical / logical network. The logical network can arise from a web based property such as a social networking site. An identity can define a relationship contract for source(s) of inbound transactions. Hence, a relationship contract can exist for an entity as well as any source of a transaction request, which can be a physical or logical network. An identity, for example identity 502b, can define relationship contracts for all transactions from a logical network such as an online social network, and / or from identities that have specified their identifier(s) on such logical networks as one of the end points to which their single, abstract and persistent identifiers can resolve to and / or with identities belonging to such a network.

Certain transactions might involve more than two identities. In which case, the contract bridge could comprise of single or multiple paths. Figure 7 is a block diagram that represents linking of identities 702a and 702b represented through a single, abstract, persistent identifier each, in a one to many parent-child configuration, for the purpose of applying controls over transactions and / or related parameters and / or exchanged artifacts during / after a transaction to / from the child identity. Figure 7 shows identity A 702a and identity B 702b, represented by a single, abstract, persistent identifier each (as described in the Figure above), linked together with identity 'A' 702a forming the parent of identity 'B' 702b. ID1 , ID2 and ID3 are the identifiers 704a encompassed by Identity 'A¹ 702a and ID4, ID5 and ID6 are the underlying identifiers 704b belonging to Identity 'B' 702b. The underlying identifiers may belong to same / different domains / networks / channels. All incoming transactions for Identity 'B' 702b on identifiers 704b, that is ID4 and / or ID5 and / or ID6 and / or the single, abstract, persistent identifier for Identity 'B' 702b are intercepted and get managed according to Identity contracts of Identity 'B' 702b, the terms for which are derived either from the Identity contract of Identity 'A' 702a or directly from Identity 'A' 702a. Identity 'A' 702a can route the transaction to any of its underlying domains, channels, applications (represented here by ID1, ID2 and ID3) or underlying domains, channels, applications (represented here by ID4, ID5 and ID6) of identity 'B' 702b. It can apply controls over transactions and / or related parameters and / or exchanged artifacts during / after all transaction to / from Identity 'B' 702b. Related application of the concept includes parental control over transactions for multiple identities. Another embodiment includes linking of identities within an organization for control on transactions / artifacts exchanged on various communication channels for the purpose of protecting intellectual property. Figure 8 is a block diagram that represents a technique for permissions marketing between an identity 802 represented by a single, abstract, persistent identifier and various businesses. The invention provides for permitted outreach or permissions marketing with an identity 802 wherein information (content) or ads from various content providers and / or businesses 804 and / or ad-aggregators 806 are pushed to the identity 802 based on identity specified attributes and / or parameters such as context. An embodiment of this envisages an identity 802 that wants advertisements or information on a specific product and / or keyword to be delivered to a specific device / channel / application based on a parameter or a combination of parameters such as temporal state and / or location and / or presence(or availability) on various underlying device / channel / application (s).

The method extends to include permissions marketing for a shared transaction session between two or more identities to include pushing of ads, as a part of an ongoing transaction, based on relevant attributes and / or parameters of the transactions.

The system, as described in the present invention, or any of its components, may be embodied in the form of a computer system. Typical examples of a computer system include a general-purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices that are capable of implementing the steps constituting the method of the present invention.

The computer system comprises a computer, an input device, a display unit and the Internet. The computer comprises a microprocessor, which is connected to a communication bus. The computer also includes a memory, which may include Random Access Memory (RAM) and Read Only Memory

(ROM). Further, the computer system comprises a storage device, which can be a hard disk drive or a removable storage drive such as a floppy disk drive, an optical disk drive, and the like. Furthermore, the storage device can be other similar means for loading computer programs or other instructions on the computer system.

To process input data, the computer system executes a set of instructions that are stored in one or more storage elements. The storage elements may also hold data or other information, as desired, and may be an information source or physical memory element present in the processing machine.

The set of instructions may include various commands that instruct the processing machine to perform specific tasks such as the steps constituting the method of the present invention. The set of instructions may be in the form of a software program. The software may be in various forms such as system or application software. The software may also be in the form of a collection of separate programs, a program module with a larger program, or a portion of a program module. Moreover, the software may include modular programming in the form of object-oriented programming. Processing of input data by the processing machine may be in response to user commands, to the results of previous processing, or to a request made by another processing machine. While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the invention as described in the claims.

Claims

CLAIMSWhat is claimed is:

1. A method for controlling a transaction between a source identity and a destination identity, wherein the source identity belongs to a trust domain A and the destination identity belongs to a trust domain B, the method comprising: initiating a transaction request from the source identity; formulating a contract bridge between the trust domain A and the trust domain B; and controlling the transaction based on the formulated contract bridge, wherein the source identity and the destination identity transact over a single or multiple channels.

2. The method as recited in claim 1 , wherein formulating the contract bridge comprises: asserting authentication of the source identity at the trust domain B; authorizing the source identity at the trust domain B; and presenting attributes of the source identity at the trust domain B, wherein the attributes comprise parameters required for completing the transaction.

3. The method as recited in claim 1 , wherein controlling the transaction is performed by at least one of the source identity and the destination identity.

4. The method as recited in claim 1 , wherein the transaction further comprises one or more identities other than the source identity and the destination identity.

5. The method as recited in claim 1 , wherein controlling the transaction is performed over the single or multiple channels used for the transaction.

6. The method as recited in claim 1 , wherein controlling the transaction is performed over one or more channels, wherein the one or more channels are different from the single or multiple channels of the transaction.

7. The method as recited in claim 1 , further comprising extending choice of at least one of control channels and transaction channels as a randomized or multi-network authentication or authorization.

8. The method as recited in claim 1 , wherein controlling the transaction comprises at least one of blocking, permitting and altering the transaction.

9. The method as recited in claim 8, wherein altering the transaction comprises selecting an alternate transaction channel of the single or multiple channels for transaction.

10. The method as recited in claim 1 further comprising controlling the transaction based on identity contracts defined by the source identity and the destination identity with respect to each other.

11. The method as recited in claim 10, wherein the identity contracts comprise a set of rules for altering transaction parameters based on a current set of preferences of the source identity and the destination identity.

12. The method as recited in claim 10, wherein the identity contracts are defined with respect to an existing logical network corresponding to at least one identity.

13. The method as recited in claim 10, wherein the identity contracts are derived from at least one of an existing logical network and a social network.

14. The method as recited in claim 13, wherein the existing logical network arises from a web based property.

15. The method as recited in claim 1 further comprising controlling the transaction and related artifacts of the transaction based on at least one of an access, privacy, usage, synchronization, expiry and compliance for the transaction.

16. The method as recited in claim 1 further comprising storing metadata and artifacts related to the transaction at a temporary storage.

17. The method as recited in claim 1 further comprising storing metadata and artifacts related to the transaction at a permanent storage.

18. The method as recited in claim 17 further comprising facilitating at least one of archiving and tracking transaction reputation history based on the stored metadata and artifacts.

19. The method as recited in claim 1 further comprising linking the destination identity in a parent child configuration with a parent identity.

20. The method as recited in claim 19, wherein the parent identity is linked in the parent child configuration with multiple identities.

21. The method as recited in claim 19 further comprising controlling a destination identity transaction based on an identity contract of the parent child configuration.

22. The method as recited in claim 1 further comprising providing information to at least one of the source identity and the destination identity, wherein channel for providing information and the information provided are based on temporal value of attributes corresponding to each or both identity.

23. The method as recited in claim 22, wherein the information comprise advertisements.

24. The method as recited in claim 22, wherein the information comprise content information.

25. A method for controlling a transaction between a source identity and a destination identity, wherein the source identity belongs to a trust domain A and the destination identity belongs to a trust domain B, the method comprising: initiating a transaction request from the source identity; formulating a contract bridge between the trust domain A and the trust domain B, wherein formulating the contract bridge comprises: asserting authentication of the source identity at the trust domain B; authorizing the source identity at the trust domain B; and presenting attributes of the source identity at the' trust domain B, wherein the attributes comprise parameters required for completing the transaction; and controlling the transaction based on the formulated contract bridge, wherein the source identity and the destination identity transact over a single or multiple channels.

26. The method as recited in claim 25 further comprising controlling the transaction based on identity contracts defined by the source identity and the destination identity with respect to each other.

27. The method as recited in claim 26, wherein the identity contracts comprise a set of rules for altering transaction parameters based on a current set of preferences of the source identity and the destination identity.

28. A system for controlling a transaction between a source identity and a destination identity over single or multiple channels, wherein the source identity belongs to a trust domain A and the destination identity belongs to a trust domain B₁ the system comprising: means for formulating a contract bridge between the trust domain A and the trust domain B; and means for controlling the transaction based on the contract bridge.

29. The system as recited in claim 28, wherein the means for formulating the contract bridge further comprising: means for asserting authentication of the source identity at the trust domain B.

30. The system as recited in claim 28, wherein the means for formulating the contract bridge further comprising: means for authorizing the source identity at the trust domain B.

31. The system as recited in claim 28, wherein the means for formulating the contract bridge further comprising: means for presenting attributes of the source identity at the trust domain B₁ wherein the attributes comprise parameters required for completing the transaction.

32. The system as recited in claim 28, wherein the contract bridge is formulated over one or more channels.

33. The system as recited in claim 28 further comprising: means for controlling the transaction based on identity contracts defined by the source identity and the destination identity with respect to each other.

34. The system as recited in claim 33, wherein the identity contracts comprise a set of rules for altering transaction parameters based on a current set of preferences of the source identity and the destination identity.

35. The system as recited in claim 33, wherein the identity contracts are defined with respect to an existing logical network corresponding to at least one identity.

36. The system as recited in claim 33, wherein the identity contracts are derived from at least one of an existing logical network and a social network.

37. The system as recited in claim 36, wherein the existing logical network arises from a web based property.

38. The system as recited in claim 28 further comprising: means for storing metadata and artifacts related to the transaction.

39. A system for controlling a transaction between a source identity and a destination identity, the system comprising: a Requester Service Access Point configured to receive a service request from the source identity; a Requester Service Control Point configured to receive authentication of the source identity and send a request package to a mediation service; a Provider Service Control Point configured to receive the request package from the mediation service and receive validation of a relationship contract of the destination identity with the source identity; and a Provider Service Access Point configured to send a request result to the Requester Service Access Point.

40. The system as recited in claim 39, wherein the Requester Service Access Point is further configured to select a single or multiple channels for completing the transaction.

41. The system as recited in claim 39, wherein the Requester Service Control Point is further configured to send the request package based on a relationship contract of the source identity with the destination identity.

42. The system as recited in claim 39, wherein the request package comprises at least one of authentication, authorization and attribute assertion.

43. The system as recited in claim 39, wherein the Provider Service Control Point is further configured to send the request result to the Provider Service Access Point based on validation of the relationship contract of the destination identity with the source identity.

44. The system as recited in claim 39, wherein the mediation service is configured to transform a format of the request package.

45. The system as recited in claim 39 further comprising a Global Resolution Service configured to store metadata corresponding to the source identity and the destination identity.

46. A computer program product for use with a computer, the computer program product comprising a computer usable medium having a computer readable program code embodied therein for controlling a transaction between a source identity and a destination identity, wherein the source identity belongs to a trust domain A₁ and wherein the destination identity belongs to a trust domain B, the computer program product performing the steps of: initiating a transaction request from the source identity; formulating a contract bridge between the trust domain A and the trust domain B; and controlling the transaction based on the formulated contract bridge, wherein the source identity and the destination identity transact over a single or multiple channels.