WO2010030458A2

WO2010030458A2 - Method for action assertion generation and usage

Info

Publication number: WO2010030458A2
Application number: PCT/US2009/053331
Authority: WO
Inventors: Samir Dilipkumar Saklikar; Subir Saha
Original assignee: Motorola, Inc.
Priority date: 2008-09-12
Filing date: 2009-08-11
Publication date: 2010-03-18
Also published as: WO2010030458A3; WO2010030458A4

Abstract

A method for providing action information about an identity of a communication device to a relying party in an identity federation environment is disclosed, in accordance with an embodiment of the present invention. The communication device has an identity-based relationship with an asserting party. The method includes, monitoring an action performed in the identity federation environment by the communication device. The action is monitored at the asserting party. Further, the method includes, generating an identity federation token based on the action performed in the identity federation environment. The identity federation token is associated with the identity of the communication device. The identity token indicates information associated with the action to the relying party. Furthermore, the method includes sending the identity federation token to the relying party. The identity federation token indicates the action information to the relying party.

Description

METHOD FOR ACTION ASSERTION GENERATION AND USAGE

[0001] This invention generally relates to communication networks, and more specifically, to a method for action assertion generation and usage in communication networks.

BACKGROUND OF THE INVENTION

[0002] Centralized identity management solutions were created to deal with a user and data security where the user and the systems they accessed were within the same network or 'domain of control'. However, with the decentralization of the Internet, users are accessing external systems which are fundamentally outside their domain of control, and similarly, external users are accessing internal systems. The challenges associated with such type of cross-domain issues have led to the evolution of a new approach of cross-domain identity management known as identity federation network. Identity Federation technologies involve an Asserting Party that has a certain trustworthy relationship with the user. A Relying Party, within an Identity Federation network, is a provider at which the User invokes some Services or requires some information from. Before the Relying Party can provide the desired service or information, it must be assured of the User Identity and associated Identity Information. Hence, it is requires User Identity information to be asserted by a trusted Asserting Party. The Relying Party can be a cross-domain system for example a service provider in a domain different from the domain of the user. In another instances, the Relying Party may be another sub-system hosted within the same administrative domain of the Asserting Party.

[0003] Typically, the trust-worthy relationship between the Asserting Party and the user is an identity -based relationship characterized by different kinds of information namely, User Authentication information, User Authorization information, and User- related Attributes. All of the above information types can be extended and used within the Identity Federation setting. Including the User Authentication within an Identity Federation Token (or Assertion) means that the Asserting Party authenticates the user and is willing to assert the authentication fact to the Relying Party. The User Authorization information is the authorization related information about the user that can be asserted by the Asserting Party to other entities. The User-related Attributes information is some information about the user such as user's preferences that the Asserting Party can assert to the other entities in order to provide better service to the user.

[0004] The Identity Federation technology conventionally has been designed to accommodate the above mentioned information in protocol exchanges between the Asserting Party and the Relying Party. Further, there is typically a business model associated with Identity federation technology that enables Asserting Party to generate revenue by sharing the above mentioned information. However, the mechanism is limited to only these three kinds of user information. Further, the existing mechanism deals with establishing Identity Federation mechanism with major focus on user authentication. Moreover, this kind of information is static and well-defined prior to the usage of Identity Federation framework. Further, the Asserting Party has other information about the user which is more dynamic in nature and that can be used to generate revenue. An example of such dynamic information is information related to Actions performed either by or on the User while interacting with the Asserting Party. The existing mechanisms do not enable use of such Actions-related dynamic information within Identity Federation tokens. Furthermore, the user can require proving that they have performed certain Actions or that certain dynamic information was communicated by them towards a particular Service Provider. For example, the information can be about a particular User Action of sharing an Advertisement-related video to her friends within a telecommunication network and the user expects revenue in return from the Advertising Service Provider. Similarly, the Relying Party may require assertion from a trustworthy Asserting Party that a particular User Action as claimed by the User was indeed performed by the User within the Asserting Party's administrative domain. The existing mechanism does not provide solution to these requirements of the user and the Relying Party.

[0005] Hence, there is a need for a method that enables the Assertion of dynamic information associated with the user, such as the User Actions within an Identity Federation setting. Further, the mechanism needs to be capable of increasing the reliability and accountability of information communicated between the user and the Relying Party. A business model is also required through which the Asserting Party can generate revenue using such mechanism. BRIEF DESCRIPTION OF THE FIGURES

[0006] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, and which, together with the detailed description below, are incorporated in and form part of the specification, serve to further illustrate various embodiments and explain various principles and advantages, all in accordance with the present invention:

[0007] FIG. 1 is an exemplary environment, where various embodiments can be practiced in accordance with the present invention;

[0008] FIG. 2 is a call flow diagram of a method for providing action information about an identity of a communication device to a relying party, in accordance with the present invention;

[0009] FIG. 3 is another call flow diagram of a method for providing action information about an identity of a communication device to a relying party, in accordance with the present invention;

[0010] FIG. 4 is yet another call flow diagram of a method for providing action information about an identity of a communication device to a relying party, in accordance with the present invention;

[0011] FIG. 5 is a call flow diagram of a method for providing a service to a communication device, in accordance with the present invention;

[0012] FIG. 6 is a call flow diagram of a method for providing a third party call control on behalf of a communication device, in accordance with the present invention; and

[0013] FIG. 7 is a call flow diagram of a method for providing seamless mobility in communication to a user of a communication device, in accordance with the present invention.

[0014] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated, relative to other elements, to help in improving an understanding of embodiments of the present invention. DETAILED DESCRIPTION

[0015] Before describing in detail the particular method for action assertion generation and usage, in accordance with the present invention, it should be observed that the present invention resides primarily in combinations of method steps related to action assertion generation and usage. Accordingly, the apparatus components and method steps have been represented, where appropriate, by conventional symbols in the drawings, showing only those specific details that are pertinent for understanding the present invention, so as not to obscure the disclosure with details that will be readily apparent to those with ordinary skill in the art, having the benefit of the description herein.

[0016] In this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such a process, method, article or apparatus. An element proceeded by "comprises ... a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article or apparatus that comprises the element.

[0017] A "set", as used in this document, means a non-empty set, i.e., comprising at least one member. The term "another," as used in this document, is defined as at least a second or more. The terms "includes" and/or "having", as used herein, are defined as comprising.

[0018] A method for providing action information about an identity of a communication device to a relying party in an identity federation environment is disclosed, in accordance with an embodiment of the present invention. The communication device has an identity-based relationship with an asserting party. The method includes, monitoring an action performed in the identity federation environment by the communication device. The action is monitored at the asserting party. Further, the method includes, generating an identity federation token based on the action performed in the identity federation environment. The identity federation token is associated with the identity of the communication device. The identity token indicates information associated with the action to the relying party. Furthermore, the method includes sending the identity federation token to the relying party. The identity federation token indicates the action information to the relying party.

[0019] A method for providing information about an identity of a communication device to a relying party in an identity federation environment is disclosed, in accordance with an embodiment of the invention. The method includes generating an identity federation token for the relying party based on an action performed in the identity federation environment by the communication device. The identity federation token is associated with the identity of the communication device and indicates information associated with the action. Further, the method includes sending the identity federation token to the relying party. The identity federation token indicates the action information to the relying party.

[0020] A method for providing action information about an identity of a communication device to a relying party in an identity federation environment is disclosed, in accordance with another embodiment of the invention. The method at the relying party includes receiving an identity federation token, based on an action performed in the identity federation environment, from the communication device. The identity federation token is associated with the identity of the communication device and indicates the information associated with the action to the relying party. Further, the method includes providing a response action to a set of communication devices based on the action from the communication device.

[0021] FIG. 1 is an exemplary communication network 100, where various embodiments of the present invention can be practiced. The communication network 100 is an interconnected system of a communication device 102, an asserting party 104, and a relying party 106. Examples of the communication network 100 include, but are not limited to, a Local Area Network (LAN), a Wide Area Network (WAN), a satellite network, a wireless network, a wireline network, a mobile network, a wired phone network and other similar networks. The communication device 102, the asserting party 104 and the relying party 106 are interconnected through network devices in the communication network 100. Examples of such network devices can include, but are not limited to, hubs, switches, bridges, routers for a website, servers, and the like. Moreover, the communication network 100 may comprise any number of network devices that are required for a given commercial implementation. [0022] For one embodiment, the communication device 102 can be used by a user for obtaining a service. The user can be a human or a software application. Examples of the communication device 102 can include, but are not limited to, a mobile phone, a laptop, a Personal Digital Assistant (PDA), a pager, a Programmable Logic Controller (PLC), a wired phone device, and the like. Further, the asserting party 104 can provide assertions about the identity of the user of the communication device 102. Examples of the asserting party 104 can include, but are not limited to, a mobile service provider, a wired phone service provider, an Internet service provider, and the like. For one embodiment, the asserting party 104 can be identity provider for the communication device 102. The asserting party 104 is present in the identity federation environment, which defines a framework through which it can assert the identity of the user and associated user identity information of the communication device 102.

[0023] Further, the relying party 106 can be a device to which the communication device 102 can make a request for the service. The relying party 106 requires assertions from the asserting party 104 about the identity of the user of the communication device 102 before the relying party 106 can provide the required service to the communication device 102. Examples of the relying party 106 can include, but are not limited to, an Internet-based shopping provider, a software provider, a network- connection provider, an application provider, and the like. The relying party 106 can be a service provider. For this embodiment, the relying party 106 can provide services that are related to any form of digital information, for example, databases, music, songs, pictures, movies, source codes, computer programs, software, and the like. Moreover, the communication network 100 may comprise any number of communication devices, asserting parties, and relying parties that are required for a given commercial implementation, although only one communication device 102, one asserting party 104, and one relying party 106 are shown, for the sake of clarity of description.

[0024] Those skilled in the art will, however, recognize and appreciate that the specifics of this illustrative example are not the specifics of the invention, and that the method set forth herein can be applicable in a variety of alternative settings. For example, since the invention described does not depend on the type of communication devices deployed or communication network implemented, it can be applied to any type of communication device or network. As such, other alternative implementations, using different types of networks and network devices, are contemplated and are included within the scope of the various embodiments described.

[0025] FIG. 2 is a call flow diagram of a method for providing action information about the identity of the communication device 102 to the relying party 106, in accordance with the present invention. To describe the method, reference will be made to FIG. 1, for the sake of clarity, although it will be apparent to those skilled in the art that the method can also be implemented in any other suitable network. The communication device 102 sends a registration and authentication request 202 to the asserting party 104. The asserting party 104 authenticates the communication device 102 on receiving the registration and authentication request 202. For one embodiment, the registration and authentication request 202 can be used to establish an identity-based relationship between the communication device 102 and the asserting party 104. The communication device 102 has an identity that is associated with its identity-based relationship with the asserting party 104. For example, the communication device 102 can be a mobile phone and the asserting party 104 can be a mobile service provider. Further, the identity of the communication device 102 can be a mobile phone number that is registered with the mobile service provider.

[0026] After the communication device 102 is authenticated by the asserting party 104, the communication device 102 sends a request 204 to the asserting party 104 to connect to the relying party 106. For one embodiment, the request 204 by the communication device 102 can be a request for a service provided by the relying party 106. The sending of the request 204 by the communication device 102 can be termed as an 'action' performed by the communication device 102. The relying party 106 can require action information pertaining to the 'action' performed by the communication device 102 before it can provide the requested service to the communication device 102. The action information can ensure the relying party 106 that the action was indeed performed by the communication device 102. It should be noted that the term 'action' as used anywhere in this patent application refers to action as defined above and performed by or performed upon any of the communication device 102, asserting party 104, and the relying party 106 in the identity federation environment. Further, it will be apparent to those skilled in the art that the asserting party 104 can also assert the action of the communication device 102 for information other than request related information.

[0027] The above method can be understood by considering the following example. Carla is a user of the communication device 102. The communication device 102 can be a mobile phone and the asserting party 104 can be a mobile service provider. Further, the relying party 106 can be a service provider. Carla can have some advertising related content about the relying party 106 on her mobile phone i.e. the communication device 102. She can send this advertising content to her friends (for e.g. via SMS or MMS) and thus contribute in promoting the services provided by the relying party 106. The sending of the advertising content to a friend is an action performed by Carla. The asserting party 104 can monitor these actions as performed by Carla.

[0028] Further, the relying party 106 can have a policy that rewards on promoting about their services. Before the relying party 106 can reward Carla for promoting services of the relying party 106, the relying party 106 needs to be sure that Carla indeed performed such action of sending relevant advertising content to her friends. The asserting party 104 monitors the action performed by Carla and thus can provide assertions confirming the actions performed by Carla. Based on this asserted information, the relying party 106 can reward Carla. In one embodiment, the relying party 106 can directly provide some benefit to Carla. In another embodiment, the relying party 106 can involve a set of service providers to provide some benefits to Carla i.e. the user of the communication device 102.

[0029] In another example, Jim is a user of the communication device 102 and requires to stream music to listen. The communication device 102 in this example can be a mobile phone and the asserting party 104 can be a mobile service provider for the communication device 102. The relying party 106 can be a service provider hosting a music streaming server for providing various multimedia services. To listen to the music, Jim sends the request 204 in form of an SMS/MMS via the asserting party 104, but directed towards the relying party 106. Therefore, Jim has performed an 'action' of sending the request 204. Further, the relying party 106 can require information associated with this action i.e. the action information, to ensure that the Jim is indeed the person who requested for music. For one embodiment, the action information for validation of user can be required by the relying party 106 to ensure that the relying party is not subjected to spamming. For another embodiment, the action information can be used by the music streaming server for billing and auditing purpose as a proof that the music was provided to Jim based on the request 204 made by Jim.

[0030] The asserting party 104, the mobile service provider, monitors the actions performed by the communication device 102 (i.e. by Jim) and is therefore in a position to assert these actions to the relying party 106. Therefore, the action information can be asserted by the asserting party 104 to the relying party 106 in the identity federation environment of the communication network 100. On receiving the request 204 from the communication device 102, the asserting party 104 can generate an identity federation token. The identity federation token is based on the action performed in identity federation environment. Further, the identity federation token is associated with the identity of the communication device 102. After generating the identity federation token, the asserting party 104 sends a request and the identity federation token delivery 206 to the relying party 106. The request and assertion delivery 206 forwards the request 204 along with the identity federation token to the relying party 106. Thus, the action information about the identity of the communication device 102 is provided to the relying party 106. The relying party 106 can verify the identity federation token and provide the service to the communication device 102. In some cases the relying party 106 can present the identity federation token to other service providers that can aid the relying party 106 in providing the service to the communication device 102. The identity federation token can act as a proof to other service providers to indicate and prove that Jim has indeed invoked the particular action. For example, Jim may have typed in a few words in the SMS indicating that it needs a particular service from the relying party 106. In such a case, the assertions from the asserting party 104 acts as proof of Jim having invoked the particular action (in this case, streaming of songs) via sending an SMS towards the relying party 106. The relying party 106 can also present and use this assertion at other service providers, to prove that it has a request from the user. [0031] For one embodiment, the identity of the communication device 102 can also be the identity of the user of the communication device 102. In some cases, the identity federation token can be sent to the relying party 106 through the communication device 102. In such cases, it is not necessary for the asserting party 104 to send the identity federation token directly to the relying party 106. Rather, it is required that the asserting party 104 generates and sends the token towards the communication device 102. The identity federation token can include information about the action performed by the communication device 102. Further, the identity federation token can have information about an action performed on the communication device 102. In some cases, the identity federation token can have information about action performed by the user of the communication device 102 and action performed on the user of the communication device 102.

[0032] The identity federation token can include content of the action. Also, the identity federation token can include information associated or derived from the content of the action. As an example, the identity federation token can include a cryptographic hash value generated from the content of the action. The cryptographic hash value as present in the identity federation token can serve as a check to ensure that indeed the same content is being asserted. The content is not included in the identity federation token and can be sent in parallel to the identity federation token. The relying party 106 can receive the content and apply a hash over it. The relying party 106 can then compare the hash value of the content with the cryptographic hash value contained in the identity federation token to match and ensure that it is indeed the same content that the asserting party 104 has asserted. The use of cryptographic hash value in the identity federation token reduces the size of identity federation token considerably when compared to an identity federation token which includes content. Also, the identity federation token can include information on the cost of transaction involved in providing the identity federation token. The identity federation token can also have information about the identity of the relying party 106. The identity federation token can have time-instance of occurrence of the action. The identity federation token can also have a record of duration of the action. Further, the identity federation token can also define a set of characteristics of response actions by the relying party 106 allowed in response to the action performed by the communication device 102. In this embodiment, the identity federation token is associated with the identity of the communication device 102, although in general, the identity federation token can be associated with an identity of a device that performs the action. In some cases, the identity federation token can be associated with an identity of a user who is performing the action using the communication device 102.

[0033] Further, many similar identity federation tokens corresponding to various communication between the communication device 102 and the relying party 106 will be generated and used in the similar way during each communication between the communication device 102 and the relying party 106. In some cases, a record of the identity federation tokens used for communication between the communication device 102 and the relying party 106 is stored. The record of identity federation tokens can be used for auditing and billing purposes. Further, a query-based search can be provided to the communication device 102 based on the record of identity federation tokens stored.

[0034] FIG. 3 is another call flow diagram of a method for providing action information about the identity of the communication device 102 to the relying party 106, in accordance with the present invention. To describe the method, reference will be made to FIGs. 1 and 2, for the sake of clarity, although it will be apparent to those skilled in the art that the method can also be implemented in any other suitable network. The communication device 102 sends a registration and authentication request 302 to the asserting party 104. The asserting party 104 authenticates the communication device 102 on receiving the registration and authentication request 302. For one embodiment, the registration and authentication request 302 can be used to establish an identity -based relationship between the communication device 102 and the asserting party 104. The communication device 102 has an identity that is associated with its identity-based relationship with the asserting party 104. For example, the communication device 102 can be a mobile phone and the asserting party 104 can be a mobile service provider. Further, the identity of the communication device 102 can be a mobile phone number that is registered with the mobile service provider.

[0035] The communication device 102 can create a request to send to the relying party 106 for a service. As described in FIG. 2, the sending of the request by the communication device 102 to the relying party 106 is an 'action'. Further, the relying party 106 can require action information pertaining to the 'action' performed by the communication device 102 before it can provide the requested service to the communication device 102. The communication device 102 can then create an identity federation token. The identity federation token is based on the action performed in identity federation environment. Further, the identity federation token is associated with the identity of the communication device 102. After generating the identity federation token, the communication device 102 can send a request and the identity federation token delivery 304 to the asserting party 104. The asserting party 104 receives the request and the identity federation token. The asserting party 104 then validates the identity federation token and then sends a request and assertion delivery 306 to forward the request along with the identity federation token to the relying party 106. In some cases, it is also possible for the asserting party 104 to generate another identity federation token and include the received identity federation token within it. The asserting party 104 can then forward the request, along with this newly generated identity federation token to the relying party 106. Thus, the action information about the identity of the communication device 102 is provided to the relying party 106. The relying party 106 can verify the identity federation token and content of the request. Further the fact, that the token was forwarded by the Asserting Party indicates that the Asserting Party is assuring about the information which the Communication Device has encoded within the identity federation token. After verification of the identity federation token, the relying party 106 can provide service to the communication device 102.

[0036] FIG. 4 is a call flow diagram of a method for providing action information about the identity of the communication device 102 to the relying party 106, in accordance with the present invention. To describe the method, reference will be made to FIGs. 1 and 2, for the sake of clarity, although it will be apparent to those skilled in the art that the method can also be implemented in any other suitable network. The communication device 102 sends a request 402 to a asserting party 404 to connect to the relying party 106. For one embodiment, the request 402 by the communication device 102 can be a request for a service provided by the relying party 106. The sending of the request 402 by the communication device 102 can be termed as an 'action' performed by the communication device 102. Further, as described in conjunction with FIG. 2, the communication device 102 can also perform an action other than the request to the relying party 106. It should be apparent to those skilled in the art that regardless of the purpose of the action, the asserting party 404 can monitor the action performed by the communication device 102. Therefore, the asserting party 404 is in a position to assert the action performed by the communication device 102 as well as the action information associated with such action. Upon receiving the request 402, the asserting party 404 can send an assertion creation request 406 to an asserting party 408. In some cases, prior to sending the assertion creation request 406, the asserting party 404 can generate an identity federation token based on the action. The asserting party 404 can add the identity federation token to the request, to indicate that the user has performed a particular action of accessing the relying party 106. Then, the asserting party 404 can send the identity federation token along with the assertion creation request 406. For one embodiment, the asserting party 408 can be an identity provider for the identity of the communication device 102. Upon receiving the assertion creation request 406, the asserting party 408 can validate the received identity federation token and then provide assertion 410 to the asserting party 404. The assertion 410 can include identity information for the communication device 102 and action information for the action performed by the communication device 102. For some embodiments, the assertion 410 can include one of the identity information of the communication device 102. For such embodiments, the asserting party 404 can be willing to provide action information for the action performed by the communication device 102. Upon receiving the assertion 410, the asserting party 404 can send a request and assertion delivery 412 to the relying party 106. The request and assertion delivery 412 can forward the request 406, the action information and identity information associated with the communication device 102 to the relying party 106. In some cases, the request and assertion delivery 406 can include identity federation tokens generated by the asserting party 404 and the asserting party 408. Thus, the communication device can connect to the relying party 106.

[0037] For example, suppose that the communication device 102 is a mobile phone and Emily is a user of the communication device 102. Further, Emily is using her mobile phone i.e. the communication device 102 on roaming. The asserting party 404 can be a mobile service provider that is providing mobile connectivity to Emily when she is using the communication device 102 on roaming. Also, the asserting party 410 can be home mobile service provider for Emily's mobile phone. In some cases, the asserting party 410 can be a provider of the mobile number for Emily's mobile phone. Therefore, the asserting party 410 will be an identity provider for the communication device 102 i.e. Emily's mobile phone. In this example, the relying party 106 can be an online shopping portal. When Emily wants to buy some jewelry from the relying party 106 by performing an electronic transaction through her mobile phone. She sends the request 402 to the asserting party 404 to connect to the relying party 106. The relying party 106 may require validity of identity of the communication device 102 and the action information related to an action of purchasing jewelry by electronic transaction as performed by Emily. In some cases, the asserting party 404 can provide action information and asserting party 408 can provide identity information of Emily using her communication device to access the relying party 106. On receiving this information, the relying party 106 has both assurances viz. that of the identity of the device as well as of the action performed by the communication device. In such cases, this example will be a variant of the methods as described in conjunction with FIGs 2 and 3.

[0038] In some cases, it is possible that the communication device 102 generates an identity federation token stating that it is accessing the roaming mobile service provider, i.e. the asserting party 404. Emily can then send this identity federation token along with the request 402 to the asserting party 404. The asserting party 404 then generates another identity federation token stating that Emily is wiling to access the relying party 106. Further, the asserting party 404 can send the identity federation token generated by the communication device 102, the request 402, and the identity federation token generated by itself through the assertion creation request 406 to the home mobile service provider 410 of the communication device 102. Upon receiving the assertion creation request 406, the asserting party 408 can validate these assertions and can choose to return an assertion 410 to the asserting party 404, which can be presented to the relying party 106 for verification and validation of the communication device 102 and action performed by the communication device 102. The assertion 410 can contain an identity federation token that provides the required information about the action and the identity of the communication device 102. The request and assertion delivery 412 can forward the request 402 and the action information and identity information associated with the communication device 102 to the relying party 106. Thus, Emily will be able to perform electronic transaction through her mobile phone and buy jewelry from the relying party 106.

[0039] FIG. 5 is a call flow diagram of a method for providing a service to the communication device 102, in accordance with the present invention. To describe the method, reference will be made to FIGs. 1, 2, 3, and 4 for the sake of clarity, although it will be apparent to those skilled in the art that the method can also be implemented in any other suitable network. The communication device 102 sends a registration and authentication request 502 to an asserting party 104. The asserting party 104 authenticates the communication device 102 on receiving the registration and authentication request 502. After the communication device 102 is authenticated by the asserting party 104, the communication device 102 sends a request 504 to the asserting party 104 to connect to the relying party 106. As described in the FIG. 2, the sending of the request 504 by the communication device 102 is an action performed by the communication device 102. Further, there can be some other action as performed by the user and monitored by the asserting party 104. Further, the relying party can need action information corresponding to this action as performed by the communication device 102. On receiving the request 504, the asserting party can generate an identity federation token. The identity federation token is based on the action performed in identity federation environment. Further, the identity federation token is associated with the identity of the communication device 102. After generating the identity federation token, the asserting party 104 can send a request and token delivery 506 to the relying party 106. The request and token delivery 506 forwards the request 504 along with the identity federation token to the relying party 106. The relying party 106 can then verify the identity federation token to provide the service to the communication device 102. In some cases, the relying party 106 can be capable of providing the service. In such cases, the method will be similar to as described in conjunction with FIG. 2. [0040] However, in many other cases, it is possible that the relying party 106 alone cannot provide the service to the communication device 102 and require at least a part of the service from a set of relying parties 508 in the identity federation environment. After generating the identity federation token, the asserting party 104 can send a request and identity federation token delivery 506 to the relying party 106. The request and identity federation token delivery 506 forwards the request 504 along with the identity federation token to the relying party 106. The relying party 106 can then verify the identity federation token. The relying party 106 can then send request and tokens delivery 510 to the set of relying parties 508 to provide the service to the communication device 102. The method can be described by considering the following example.

[0041] Ron, a user of the communication device 102 may want information about various restaurants in his locality and the cuisines available in these restaurants. Ron can send the request 504 from the communication device 102 to the asserting party 104 in order to connect to the relying party 106. The relying party 106 can be a service provider having a database that contains a list of restaurants in the locality about which Ron requires information. Further, the asserting party 104 can be a communication service provider for the communication device 102. The asserting party 104 can generate the identity federation token associated with the request 504 and the identity of the communication device 102. As an example, the identity federation token can include information associated with the content of the action viz. information about the query issued by Ron. The relying party 106 then realizes that it needs information about the respective cuisine offerings along with the list of restaurants to provide service to the communication device 102. The relying party 106 can obtain information about the cuisines from a set of relying parties 508. The set of relying parties 508 can be for example, online yellow pages, online menu providers for restaurants etc. The relying party 106 can generate a set identity federation tokens. For one embodiment, the set of identity federation tokens can provide information about the relying party 106 so that the set of relying parties can verify that the relying party is a reliable device.

[0042] The relying party 106 can then send request and tokens delivery 510 to the set of relying parties 508. The request and tokens delivery 510 includes the request 504, the identity federation token as received by the relying party 106 from the asserting party 104, and the set of identity federation tokens. The set of relying parties 508 can verify the set of identity federation tokens and the identity federation token. After verifying the set of identity federation tokens, the identity federation token, and checking information related to the content of the action, the set of relying parties 508 are convinced that Ron indeed has performed the action of finding information about various restaurants in his locality and the cuisines available in these restaurants using the relying party 106. The set of asserting parties 508 trust the asserting party 104 who is asserting that Ron has performed the particular action. The set of relying parties 508 can send a cuisine information token 512 to the relying party 106. The cuisine information token 512 includes information on cuisines available in the list of restaurants as requested by the relying party 106. The relying party 106 can then send a service 514 to the communication device 102. The service 514 can include the list of restaurants and cuisines as requested by Ron. Thus, Ron is provided with the desired service by the relying party 106.

[0043] It should be noted that in generating the set of identity federation tokens, the relying party 106 acts as an asserting party with respect to the request sent to the set of relying parties 508. Also, the set of identity federation tokens and the identity federation token can include information related with the cost associated with the action. This information can be later used to settle billing between the relying party 106 and the set of relying parties 508.

[0044] FIG. 6 is a call flow diagram of a method for providing a third party call control on behalf of the communication device 102, in accordance with the present invention. To describe the method, reference will be made to FIGs. 1, 2, 3, 4, and 5 for the sake of clarity, although it will be apparent to those skilled in the art that the method can also be implemented in any other suitable network. The communication device 102 can setup a conference call (third party call)with a communication device A 602 and a communication device B 604 using a third party call control service provider. The relying party 106 can be a central controller for a third party call control (3PCC) service provider. Hereinafter, for the sake of brevity, the central controller can be used to refer to the third party call control service provider as the central controller performs majority of functions in 3PCC set up to initiate and provide conference call services to various users. The communication device 102 can send a request 606 to the asserting party 104 to connect to the relying party 106. The request 606 include request for the relying party 106 to initiate a conference with the communication device A 602 and the communication device B 604. Upon receiving the request 606, the asserting party 104 can create an identity federation token. The identity federation token generated is similar to the identity federation token as described in conjunction with FIG. 2. Then, the asserting party 104 then can send a request and token delivery 608 to the relying party 106. The request and token delivery 608 forwards the request 606 along with the identity federation token to the relying party 106. On receiving the request and token delivery 608, the relying party 106 can verify the identity federation token to validate the identity and action information associated with the communication device 102.

[0045] Upon validating the identity of the communication device 102, the relying party can proceed to initiate the conference call based on the request 606. The relying party 106 can generate an identity federation tokenl and an identity federation token2. The identity federation tokenl and the identity federation token2 contain information about an action associated with conference call as setup by the relying party 106 on behalf of the Communication Device 106. The identity federation tokenl is based on the identity federation token from the asserting party 104. The communication device A 602 can thus, be assured that indeed the conference call is being setup on behalf of the communication device 102 and based on the action performed by the communication device 102, as asserted in the identity federation token from asserting party 104. As described later, these tokens can be used for generating billing information. The relying party 106 can then send an invite and tokenl delivery 610 to the communication device A 602. The invite and tokenl delivery 610 can include the identity federation tokenl and an invite for the communication device A 602 to join the conference call setup by the relying party 106. On receiving the invite and token delivery 610, the communication device A 602 can verify the identity federation tokenl. Further, the communication device A 602 can perform further processing to join the conference call. Similarly, the relying party can send an invite and token2 delivery 612 to the communication device B 604. The invite and token2 delivery 612 can include the identity federation token2 and an invite for the communication device B 604 to join the conference call setup by the relying party. On receiving the invite and token delivery 612, the communication device B 604 can verify the identity federation token2. Further, the communication device B 604 can perform further processing to join the conference call. When both, the communication device A 602 and the communication device B 604 have joined the conference call, they can communicate with each other and the service is thus provided by the relying party 106. After the conference call, the communication device A 602 can generate an identity federation token. The identity federation token can indicate that the communication device A 602 has performed the action of availing conference services as provided by relying party 106. The communication device A 602 can then send a tokens delivery 614 to the asserting party 104. The tokens delivery 614 can forward the identity federation token and the identity federation token 1 to the asserting part 104. Similarly, the communication device B 604 can generate an identity federation token and send a tokens delivery 616 to forward the identity federation token and the identity federation token2 to the asserting party 104. Upon receiving the tokens delivery 614 and the tokens delivery 616, the asserting party 104 has all the billing information related to the services provided by the relying party 106 on request of the communication device 102. For one embodiment, the communication device 102 can be billed for the services provided by the relying party 106 on behalf of the communication device 102. The asserting party 104 can send billing 620 to the communication device 102 for charging a cost involved in providing the conference call service. For another embodiment, the communication device A 602 and the communication device B 604 can be billed separately for the conference call provided by the relying party 106. Further, in some cases, the asserting party 104 can have a business relationship with the relying party 106.

[0046] FIG. 7 is a call flow diagram of a method for providing seamless mobility in communication to a user of the communication device 102, in accordance with the present invention. To describe the method, reference will be made to FIGs. 1, 2, 3, 4, and 5 for the sake of clarity, although it will be apparent to those skilled in the art that the method can also be implemented in any other suitable network.

[0047] For one scenario Bob can be a user of the communication device 102 who wants to connect to his friend Sally. Further, Sally uses a communication device 702 for communication. Bob can send a request and token delivery 704 to the relying party 106 to connect to Sally. The request and token delivery 704 can include a request from Bob connect to Sally and an identity federation token to indicate action and identity information about the communication device 102. The mechanism to obtain the identity federation token and sending request to the relying party 106 from the communication device 102 can be similar to the methods as described in conjunction with FIG. 2 and 3. The relying party 106 can then create a session 706 to connect Bob with Sally. Upon providing the service to Bob, i.e. connecting Bob and Sally through session 706, the relying party 106 can send a tokenl delivery 708 to provide an identity federation tokenl to the communication device 102. For one embodiment, the identity federation tokenl can be billing information related to the communication with Sally. For another embodiment, the identity federation tokenl can be a receipt from the relying party 106 to indicate successful action of connecting to the communication device 702 taken on the communication device 102. This action can be representative of having provided a service. As described in conjunction with FIG. 2 and 3, the identity federation token and the identity federation tokenl can be stored as a record.

[0048] At a later time, when Bob again wants to connect to Sally, the mechanism to connect to Sally will be similar to the method described above and will result in a session 710. The session 710 indicates initiation of the conversation between Bob and Sally. Further, Bob can desire to continue talking to Sally, but through a communication device 712. The communication device 712 can be for example, a wired telephone of which Bob is a user. Further, Bob does not desire to disconnect from the conversation with Sally. In some cases, the communication device 712 may be managed by a different identity provider than that of the communication device 102. Bob can send a session transfer request 714 to the relying party 106. The session transfer request 714 can include a request to transfer the session with Sally to the communication device 712 and the identity federation tokenl. The identity federation tokenl can be required by the relying party 106 to indicate to the communication device 712 that there was a session taking place between the communication device 102 and the communication device 702 and due to some valid reasons the transfer of the session is required. [0049] The communication device 102 can generate a token to indicate that the user of the communication device 102 intends to transfer the session to the communication device 712. Upon receiving the session transfer request 714 along with the token generated by the communication device 102, the relying party 106 can generate an identity federation token2. The identity federation token2 can be used by the communication device 712 to verify that the session transfer has occurred from the session between the communication device 102 and the communication device 702. The relying party 106 can then send a session transfer request 716 along with the token2 and token generated by the communication device 102 to the communication device 702. For one embodiment, the session transfer request 716 can indicate to the communication device 702 that the session with the communication device 102 will be transferred to the communication device 712. For another embodiment, the session transfer request 716 can be a request to the communication device 702 to approve transfer of its session with the communication device 102 to the communication device 712. This indication or approval can be used for example, to address any security related issue that the user of the communication device 702, i.e. Sally can have regarding the transfer of session. Upon receiving the session transfer request 716, the communication device 702 can validate the token-2 and be assured that the user of communication device 102 has performed the action of transferring the session to another communication device 712. The communication device 702 can generate an identity federation token-3. The identity federation token-3 can indicate the validity of the communication device 702 to the communication device 712 and ensure the communication device 712 that the communication device 702 is indeed the device with which session continuation is desired. The communication device 702 can send a session request and tokens delivery 720 to the communication device 712. This token delivery request 720 would include the token-2 received from the relying party 106 and the token-3 generated by the communication device 712. The session and tokens delivery can provide a request for session to the communication device 712 along with the identity federation token-2 and token-3. Upon receiving the session and tokens delivery 720, the communication device 712 verifies the identity federation token-2 and identity federation token-3. On verification of the identity federation tokens, the communication device 712 can connect to the communication device 702 to continue the session initiated by the session 710. Thus, Bob is provided a seamless mobility from his mobile phone to his wired phone without breaking conversation with Sally.

[0050] Various embodiments of the present invention provide a method for action assertion generation and usage. The method enables usage of dynamic information associated with a communication device. Further, the method ensures the reliability and accountability of information communicated between a user and a relying party. Since an asserting party is providing assertions for validation of user as well as relying party, the method also provides revenue opportunities to the asserting party which was earlier merely a mechanism to connect the user and the relying party. Further, the method facilitates auditing and billing related to the services offered by the relying party. The method also enables seamless mobility for users. Furthermore, the method is explained in a typical environment involving a user and a relying party. However, it may be apparent to those skilled in the art that the invention is applicable to communication between two applications in an identity federation environment as well.

[0051] It will be appreciated that the method for action assertion generation and usage herein may include one or more conventional processors and unique stored program instructions that control the one or more processors, to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the system described herein. The non-processor circuits may include, but are not limited to, signal drivers, clock circuits, power-source circuits, and user-input devices. As such, these functions may be interpreted as steps of a method for action assertion generation and usage. Alternatively, some or all of the functions can be implemented by a state machine that has no stored program instructions, or in one or more application- specific integrated circuits (ASICs), in which each function, or some combinations of certain of the functions, are implemented as custom logic. Of course, a combination of the two approaches could also be used. Thus, methods and means for these functions have been described herein.

[0052] It is expected that one with ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology and economic considerations, when guided by the concepts and principles disclosed herein, will be readily capable of generating such instructions, programs and ICs with minimal experimentation.

[0053] In the foregoing specification, the invention and its benefits and advantages have been described with reference to specific embodiments. However, one with ordinary skill in the art would appreciate that various modifications and changes can be made without departing from the scope of the present invention, as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage or solution to occur or become more pronounced are not to be construed as critical, required or essential features or elements of any or all the claims. The invention is defined solely by the appended claims, including any amendments made during the pendency of this application, and all equivalents of those claims as issued.

Claims

What is claimed is:

1. A method for providing action information about an identity of a communication device to a relying party in an identity federation environment, wherein the communication device has an identity -based relationship with an asserting party, the method comprising: monitoring an action, as performed in the identity federation environment by the communication device at the asserting party; generating an identity federation token based on the action performed in the identity federation environment, wherein the identity federation token is associated with the identity of the communication device and indicates information associated with the action to the relying party; and sending the identity federation token to the relying party, wherein the identity federation token indicates the action information to the relying party.

2. The method of claim 1, wherein the identity federation token is sent to the relying party through the communication device.

3. The method of claim 1, wherein the identity is an identity of a user of the communication device.

4. The method of claim 1, wherein the identity federation token comprises at least one of an identity of the communication device, action performed by the communication device, action performed on the communication device, action performed by a user of the communication device, action performed on a user of the communication device, content of the action, a cryptographic hash value generated from the content of the action, cost of a transaction, identity of the relying party, time- instance of the action, duration of the action, or a set of characteristics of response actions by the relying party allowed in response to the action performed by the communication device.

5. The method of claim 1, wherein the relying party sends a set of actions to a set of service providers, wherein the set of actions is based on the received identity federation token, the method at the relying party comprising: generating a set of identity federation tokens corresponding to the set of actions; and sending the identity federation token and the set of identity federation tokens to the set of service providers, wherein the identity federation token indicates the information associated with the action and wherein the set of identity federation tokens indicates a set of action information corresponding to the set of action.

6. The method of claim 1 further comprising storing a record of identity federation tokens used for communication between the communication device and the relying party.

7. The method of claim 6 comprising providing a query based search based on the record of identity federation tokens.

8. The method of claim 1, wherein the relying party is in a business relationship with the asserting party, the method further comprising: providing a response action and a first identity federation token to the communication device based on a response from the relying party, wherein the first identity federation token indicates information related to the response action as performed by the relying party in response to the action as performed by the communication device; and generating billing information based on the business relationship with the relying party.

9. The method of claim 1, wherein the identity federation environment is a telecommunication network and wherein the asserting party is a communications service provider.

10. The method of claim 9, wherein the relying party is a service provider and wherein the communication device requests the relying party to provide a service to a set of second communication devices.

11. The method of claim 9 further comprising providing a first identity federation token to the communication device based on a response action from the relying party, wherein the first identity federation token indicates response action information to the communication device.

12. The method of claim 9 further comprising providing a response action to a second communication device based on the action from the communication device, wherein the identity federation token associated with the communication device indicates to the second communication device that the response action is provided in response to the action from the communication device.

13. A method for providing action information about an identity of a communication device to a relying party in an identity federation environment, the method at the communication device comprising: generating an identity federation token for the relying party based on an action performed in the identity federation environment by the communication device, wherein the identity federation token is associated with the identity of the communication device and indicates information associated with the action; and sending the identity federation token to the relying party, wherein the identity federation token indicates the action information to the relying party.

14. The method of claim 13, wherein generating the identity federation token is based on an identity-based relationship with an asserting party in the identity federation environment.

15. The method of claim 13, wherein the identity federation token comprises at least one of an identity of the communication device, action performed by the communication device, action performed on the communication device, content of the action, a cryptographic hash value generated from the content of the action, identity of the relying party, time-instance of the action, duration of session of the action, or a set of characteristics of response actions by the relying party allowed in response to the action.

16. A method for providing action information about an identity of a communication device to a relying party in an identity federation environment, the method at the relying party comprising: receiving an identity federation token based on an action performed in the identity federation environment from the communication device, wherein the identity federation token is associated with the identity of the communication device and indicates the information associated with the action to the relying party; and providing a response action to a set of communication devices based on the action from the communication device.

17. The method of claim 16, wherein the communication device belongs to the set of communication devices.