WO2010027589A2

WO2010027589A2 - Method for multi-factor assertion generation and usage

Info

Publication number: WO2010027589A2
Application number: PCT/US2009/052621
Authority: WO
Inventors: Samir Dilipkumar Saklikar; Subir Saha
Original assignee: Motorola, Inc.
Priority date: 2008-08-25
Filing date: 2009-08-04
Publication date: 2010-03-11
Also published as: WO2010027589A4; WO2010027589A3

Abstract

A method for providing information about an identity of a communication device to a relying party in an identity federation environment is disclosed. The method includes receiving a first token that is associated with a first identity. The first token includes a set of pre-defined constraints. The method further includes receiving a second token that is associated with a second identity. The second token is used to satisfy the set of pre-defined constraints of the first token. Furthermore, the method includes indicating the first identity and the second identity to the relying party. The first identity and the second identity provide information about the identity of the communication device.

Description

METHOD FOR MULTI-FACTOR ASSERTION GENERATION AND USAGE

[0001] The invention relates generally to the field of communication networks, and more specifically, to a method for multi-factor assertion generation and usage.

BACKGROUND OF THE INVENTION

[0002] A user of a communication device in a communication network can request a service provider for a service that the service provider can provide. In certain cases, the service provider requires the identity of the user to be authenticated and authorized before providing the service. The user needs to provide this proof by giving information, for example, a shared secret, to the service provider. This mechanism requires that the service provider and the user have some means of authenticating their identities to each other. For example, the user may need to stream a video on his/her computer from a website. The website can need authentication and authorization of the user to ascertain that the user is trust- worthy. The website in this case can be the service provider and the shared secret can be login and password information of the user on the website.

[0003] An identity federation technology defines a framework in which the service provider can act as a relying party and receive assertions about the user from a trustworthy asserting party. The asserting party has knowledge about various facts relating to the user that are required to prove the user's identity to the relying party. Typically, a service is provided to the user by the relying party, based on assertions from a single asserting party. In some scenarios, the relying party can require assertions about the user from more than one asserting party. For example, the relying party may require a stronger assertion from a second asserting party along with an assertion provided by a first asserting party. This mechanism is also known as multiple assertion technique.

[0004] However, the existing mechanisms of multiple assertion techniques have certain shortcomings. These mechanisms do not have a capability to aid the relying party in the manner multiple assertions should be used. Therefore, the relying party needs to understand how the multiple assertions can be used together. Further, the asserting parties have no control over the usage of the assertions once they are issued to a user. As an example, certain asserting party may not wish its issued assertion to be used with the assertion from another asserting party. Furthermore, the user cannot be aware at all times about the number and type of assertions that are required together to assert the identity of the user to the relying party. Such a scenario can result in more assertions being shared with the relying party than required, which compromises the security or privacy of the user.

[0005] Therefore, there is a need for a mechanism through which the drawbacks mentioned above can be overcome, and enable the usage of multiple assertions to provide the identity of the user to the relying party.

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 communication network, 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 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 information about an identity of a communication device to a relying party, in accordance with the present invention;

[0010] FIG. 4 is a call flow diagram representing a method for creating a conference, in accordance with the present invention;

[0011] FIG. 5 is a call flow diagram representing a method for joining a conference, in accordance with the present invention;

[0012] FIG. 6 is another call flow diagram representing a method for joining a conference, in accordance with the present invention; and

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

[0014] Skilled artisans will appreciate that the 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 the other elements, to help in improving an understanding of the embodiments of the present invention. DETAILED DESCRIPTION

[0015] Before describing in detail the particular method and system for multi- factor 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 multi-factor assertion generation and usage. Accordingly, the 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, which comprises 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 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 method includes receiving a first identity federation token that is associated with a first identity. The first identity federation token includes a set of pre-defined constraints. The method further includes receiving a second identity federation token that is associated with a second identity. The second identity federation token is used to satisfy the set of pre-defined constraints of the first identity federation token. Furthermore, the method includes indicating the first identity and the second identity to the relying party. The first identity and the second identity provide information about the identity of the communication device.

[0019] A method for determining an identity of a communication device in an identity federation environment is disclosed, in accordance with an embodiment of the present invention. The method includes providing a first identity federation token to a relying party by a first asserting party. The first identity federation token is associated with a first identity and is related to a set of pre-defined constraints. The method also includes providing a second identity federation token to the relying party by a second asserting party. The second identity federation token is associated with a second identity and satisfies the set of pre-defined constraints of the first identity federation token. Furthermore, the method includes indicating the first identity and the second identity to the relying party. The first identity and the second identity determine the identity of the communication device.

[0020] FIG. 1 is an exemplary communication network 100 in which various embodiments can be practiced, in accordance with the present invention. Communication network 100 is an interconnected system of a communication device 102, an asserting party 104, an asserting party 106 and a relying party 108. 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 similar networks. The communication device 102, the asserting parties 104 and 106, and the relying party 108 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.

[0021] 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 device, a wired phone device, and the like. Further, the asserting parties 104 and 106 can provide assertions about the identity of the user of the communication device 102. Examples of the asserting parties 104 and 106 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 parties 104 and 106 can be identity providers. The asserting parties 104 and 106 are present in the identity federation environment, which defines a framework through which they assert the identity of the user of the communication device 102.

[0022] Further, the relying party 108 can be a device to which the communication device 102 can make a request for the service. The relying party 108 requires assertions from the asserting parties 104 and 106 about the identity of the user of the communication device 102 before the relying party 108 can provide the required services to the communication device 102. Examples of the relying party 108 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 108 can be a service provider. For this embodiment, the relying party 108 can provide services that are related to any form of digital information, for example, databases, music, songs, pictures, movies, source codes, computers 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, two asserting parties 104 and 106, and one relying party 108 are shown, for the sake of clarity of description.

[0023] 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. [0024] FIG. 2 is a call flow diagram of a method for providing information about an identity of the communication device 102 to the relying party 108, in accordance with the present invention. To describe the method, reference will be made to FIGs. 1 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 a first 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 first identity can be a mobile phone number that is registered with the mobile service provider. 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 receive a first identity federation token associated with a first identity of the communication device 102.

[0025] The asserting party 104 then creates an assertion about the first identity of the communication device 102 as the first identity federation token. The asserting party 104 then sends the first identity federation token to the communication device 102 as a first token delivery 206.

[0026] The first identity federation token issued by the asserting party 104 at first token delivery 206 is a constraint-based assertion. This means that the first identity federation token has a set of pre-defined constraints and cannot be used to provide the first identity of the communication device 102 unless the set of predefined constraints is satisfied. In accordance with the present invention, the set of pre-defined constraints need to be satisfied by a second assertion from a second asserting party. For some cases, the set of pre-defined constraints can be satisfied by a set of assertions provided by a set of asserting parties. [0027] The communication device 102 sends a second token request 208 to the asserting party 106 to obtain a second identity federation token to satisfy the set of pre-defined constraints. On receiving the second token request 208, the asserting party 106 may need to authenticate the communication device 102. In one embodiment, the second token request 208 can include authentication information related to the communication device 102. In another embodiment, the communication device 102 can be authenticated by sending an authentication request similar to the authentication and registration request 202. After the communication device 102 is authenticated by the asserting party 106, the asserting party 106 creates an assertion about the identity of the communication device 102 as a second identity federation token. The asserting party 106 then sends the second identity federation token by using a second token delivery 210 to the communication device 102. In some cases, the second identity federation token is associated with a second identity of the communication device 102.

[0028] After receiving the first identity federation token and the second identity federation token, the communication device 102 sends a request and tokens delivery 212 to the relying party 108. The request and tokens delivery 212 forwards the request along with the first identity federation token and the second identity federation token to the relying party 108. On receiving the request and tokens delivery 212, the relying party 108 verifies the first identity federation token, delivered by the communication device 102. Further, the relying party 108 identifies the set of pre-defined constraints of the first identity federation token. The relying party 108 then verifies the second identity federation token delivered and checks if it satisfies the set of pre-defined constraints of the first identity federation token. When the second identity federation token satisfies the set of pre-defined constraints, the first and the second identity federation tokens provide the first identity and the second identity of the communication device 102 to the relying party 108. Thus, the identity of the communication device 102 is asserted to the relying party 108. The relying party can then send a service access notification 214 to provide the desired service to the communication device 102.

[0029] For one embodiment, the identity of the communication device 102 can also be the identity of the user of the communication device 102. Further, the set of pre-defined constraints can also have a timing-based constraint. For some cases, the set of pre-defined constraints can have a condition that a specific relying party is a valid recipient of the first identity federation token. The first identity federation token can indicate at least one status of a federation relationship between the asserting party 104 of the first identity and the relying party 108. Also, the first identity federation token can indicate at least one status of a federation relationship between the asserting party 104 and the asserting party 106. Moreover, the set of pre-defined constraints can be used to identify a specific communication device which can be used for providing an assertion for the communication device 102. The set of predefined constraints can also specify a set of second asserting parties that are needed to provide a set of second identity federation tokens. Further, the set of pre-defined constraints can be used to specify a method for using the first identity federation token or to specify the set of required characteristics of the set of second identity federation tokens. The set of pre-defined constraints can also be encoded such that they can be decoded exclusively by a pre-defined relying party.

[0030] The second identity federation token includes a set of linking constraints, which asserts whether it can be used to support the constraints of the first identity federation tokens. The second identity federation token can also include another set of constraint-based assertions, which require it to be supported by other set of assertions from various other asserting parties. For example, the set of constraints of the second identity federation token may require assertions from a third identity federation token

[0031] FIG. 3 is another call flow diagram of a method for providing information about the identity of the communication device 102 to the relying party 108, 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 request 302 to the asserting party 104 to connect to the relying party 108 for a service. In some cases, the asserting party 104 may need to authenticate the communication device 102 on receiving the request 302. For one embodiment, the request 302 can be used to establish an identity -based relationship between the communication device 102 and the asserting party 104. In another embodiment, the communication device 102 can be authenticated by the asserting party 104 before the request 302. Such authentication step will be similar to the registration and authentication request 202.

[0032] The relying party 108 can require information pertaining to the identity of the communication device 102 before it can provide the requested service to the communication device 102. This information can be asserted by the asserting party 104 to the relying party 108 in the identity federation environment of the communication network 100. For this, the asserting party 104 creates an assertion about the identity of the communication device 102 as a first identity federation token. The first identity federation token is associated with the first identity of the communication device 102. Then, the asserting party 104 send a request and first token delivery 304 to the relying party 108. The request and first token delivery 304 forwards the request 302 along with the first identity federation token to the relying party 108.

[0033] The first identity federation token issued by the asserting party 104 is encoded with a set of dependency constraints. This means that the first identity federation token has a set of pre-defined constraints and cannot be used to provide the first identity of the communication device 102 unless the set of pre-defined constraints is satisfied. In accordance with the present invention, the set of predefined constraints need to be satisfied by a second assertion from a second asserting party. For some cases, the set of pre-defined constraints can be satisfied by a set of assertions provided by a set of asserting parties. The relying party 108 verifies the first identity federation token, along with the pre-defined constraints set, for assertions from a second asserting party, for example the asserting party 106. Further, the relying party 108 may send a second identity federation token requirement notification 306 to the communication device 102 to obtain a second identity federation token to satisfy the set of pre-defined constraints of the first identity federation token.

[0034] On receiving the second token requirement notification 306, the communication device 102 sends a second token request 308 to the asserting party 106 to receive a second identity federation token from the asserting party 106. The communication device 102 may include a set of constraints in the second token request 308 which the asserting party 106 needs to satisfy while generating the second token. The communication device 102 may also need to authenticate itself by sending a registration and authentication request to asserting party 106. After authenticating the communication device 102, the asserting party 106 then creates an assertion about a second identity of the communication device 102 as the second identity federation token. Then, the asserting party 106 sends the second identity federation token by using a second token delivery 310 to the relying party 108. In another embodiment, the asserting party 106 sends the second identity federation token by using a second token delivery to the communication device 102. In that case, the communication device is expected to send the second token along with re-sending the first token to the relying party 108. The second identity federation token should be such that it satisfies the set of pre-defined constraints of the first identity federation token. For one embodiment, the first identity and the second identity can be provided by different asserting parties 104 and 106. For another embodiment, the asserting party 104 and the asserting party 106 can be one party. Further, at least one of the first identity and the second identity is the identity of the communication device 102.

[0035] On receiving the second identity federation token, the relying party 108 verifies it and checks if it satisfies the set of pre-defined constraints of the first identity federation token. When the second identity federation token satisfies the set of pre-defined constraints, the first and the second identity federation tokens can be used to provide the first identity and the second identity of the communication device 102 to the relying party 108. Thus, the identity of the communication device 102 is asserted to the relying party 108. The relying party can then send a service access notification 312 to provide the desired service to the communication device 102. If the constraints of first identity federation token are not satisfied by the second identity federation token, during the verification done by the relying party 108, the identity of the communication device 102 cannot be asserted to the relying party 108 and the communication device 102 would not be able to access the required service.

[0036] For one embodiment, the identity federation network can be a telecommunication network. For this embodiment, one or more of the asserting parties 104 and 106 or the relying party 108 can be a service provider. The communication device 102 can be a mobile phone that makes a request for a service to the service provider. The service to the communication device 102 can be provided by the service provider, based on assertions from the first identity federation token and the second identity federation token. For one embodiment, the desired service can be a conferencing service of a set of users. Further, the relying party 108 can be the same as one of the asserting parties 104 and 106. This embodiment of the invention related to a conferencing service has been described in detail in conjunction with FIGs. 4, 5, and 6. Hereinafter, the relying party 108 has been interchangeably referred to as the service provider 108, for the sake of clarity.

[0037] FIG. 4 is a call flow diagram representing a method for creating a conference by the communication device 402 in accordance with the present invention. Reference will be made to FIGs. 1, 2 and 3, although it will be apparent to those skilled in art that the method can be implemented in any other suitable network. The conference is desired between a communication device 402 and a communication device 404 through the service provider 108. The communication devices 402 and 404 can be functionally similar to the communication device 102. For one embodiment, the conference network can be created in a telecommunications network in an identity federation environment. The communication device 402 sends a create conference request 406 to the service provider 108 to schedule a conference with the communication device 404. Example of the service provider 108 can be a collaborative application such as a calendaring server, which enables meetings to be scheduled with other participants in the identity federation environment. The collaborative application can also include a conferencing service.

[0038] On receiving the create conference request 406, the service provider 108 authenticates the communication device 402. Once the service provider 108 authenticates the communication device 402, the communication device 402 can send rights and privilege 408 to the service provider 108 to set appropriate rights and privileges for other members of the conference. For the sake of clarity of description, FIG. 3 indicates the communication device 402 and the communication device 404 as the members of the conference. However it will be apparent to those skilled in the art that in the present invention more communication devices can be added as the members of the conference. Further, in one embodiment, while setting the rights and privileges, the communication device 402 can enable the communication device 404 to delegate conference participation to some other entity. In some cases, the communication device 402 can also enable the communication device 404 to invite an outside participant to the conference.

[0039] The service provider 108 then checks the availability and creates a slot for the conference. For one embodiment, the service provider 108 can create the appropriate pseudonyms for the various conference participants, to hide their actual identities resulting in enhanced security. The request for a service can identify all the participants at the conference by their specific pseudonyms, which are specifically generated for the conference. Further, the service provider 108 creates the first identity federation tokens for the communication device 402 and the communication device 404. The service provider 108 will require the first identity federation tokens from the members of the conference later to allow them to join the conference call. Further, the service provider 108 can lay down the requirement for members in order to join the conference in the form of a set of pre-defined constraints in the first identity federation token. For example, the requirement may be that users need to prove that they are valid employees of the enterprise, or have been invited by one of the intended participants of the conference. Also, when the users were initially invited to join the conference from their office work phones, but now if they want to join from their home phone then they have to produce another set of assertion which proves their authentication from the home phone provider. The set of pre-defined constraints in the first identity federation token needs to be satisfied by a second identity federation token provided by an asserting party. For an embodiment the asserting party providing the second identity federation token can be the enterprise where the user is an employee.

[0040] The service provider 108 then sends conference invitations 410 and 412 along with the first identity federation tokens to the communication device 402 and the communication device 404 respectively. For one embodiment, the conference invitations 410 and 412 can be sent in the form of an email. Further, the email can have a clickable dial link. The dial link may have an embedded first identity federation token for the communication devices that can be used to access the conference. This identity federation token needs the support of the appropriate assertion to satisfy the constraints of the identity federation token. In some cases, when the communication device 404 is a mobile phone, the communication device 404 can receive the conference invitation 412 for the conference in the form of an MMS or SMS. In these cases, the MMS or SMS can have a first identity federation token, which can be used by the user to join the conference after supporting the first identity federation token appropriately with the required assertions from a second identity federation token. In one embodiment, the second identity federation token can be provided by the mobile service provider. The detailed method of joining a conference has been explained in conjunction with FIGs. 5 and 6.

[0041] FIG. 5 is a call flow diagram representing a method for joining a conference by the communication device 404, in accordance with the present invention. References have been made to FIGs. 1, 2, 3 and 4, for the sake of clarity of description, although it will be apparent to those skilled in art that the method can also be implemented in any other suitable network. The service provider 108 has provided the first identity federation token to the communication device 404 as described in conjunction with FIG. 4. Therefore, in this embodiment, the service provider 108 also acts as an asserting party as described in FIGs. 2 and 3.

[0042] The first identity federation token issued by the service provider 108 at the conference invitation 412 is a constraint-based assertion that is encoded with constraints which needs to be satisfied by another set of identity federation tokens. This means that the first identity federation token issued at the conference invitation 412 has a set of pre-defined constraints and cannot be used to provide the first identity of the communication device 404 unless the set of pre-defined constraints is satisfied. The set of pre-defined constraints need to be satisfied by a second identity federation tokens from a second asserting party.

[0043] In one embodiment, the communication device 404 sends a request 504 to the asserting party 502 to obtain a second identity federation token to satisfy the set of pre-defined constraints of the first Identity federation token received from the service provider 108. On receiving the request 504, the asserting party 502 may need to authenticate the communication device 102. After the communication device 404 is authenticated by the asserting party 502, the asserting party 502 creates an assertion as the second identity federation token. The asserting party 502 then sends the second identity federation token by using a second token delivery 506 to the communication device 404. In one embodiment, the second identity federation token is associated with a second identity of the communication device 404.

[0044] After receiving the second identity federation token from the asserting party 502, the communication device 404 can request the service provider 108 to allow it to join the conference. The communication device 404 sends a conference join request and tokens delivery 508 to the service provider 108. The conference join request and tokens delivery 508 forwards the conference invitation along with the first identity federation token and the second identity federation token to the service provider 108. For example, if the invitation to join the conference is sent via email, a user of the communication device 404 clicks on a link for joining the conference, provided with the invitation. For one embodiment, the service provider 108 can be a collaborative application with calendar and conference services as described in FIG. 4. On receiving the conference join request and tokens delivery 508, the service provider 108 verifies the first identity federation token for assertion about the first identity of the communication device 404.

[0045] Further, the service provider 108 identifies the set of pre-defined constraints defined in the first identity federation token. The service provider 108 verifies the second identity federation token to check if it satisfies the set of predefined constraints present in the first identity federation token. Once all the identity federation tokens have been validated, the service provider 108 sends a conference access notification 510 to the communication device 404 to indicate that the communication device 404 is allowed to join the conference. It should be noted that the service provider 108 has provided the first identity federation token to the communication device 404 in FIG. 4. Therefore, in this embodiment, the service provider 108 also acts as an asserting party as described in FIG. 2 and FIG. 3.

[0046] FIG. 6 is another call flow diagram representing a method for a conference being joined with the communication device 404, in accordance with the present invention. References have been made to FIGs. 1, 2, 3, 4 and 5 for the sake of clarity of description, although it will be apparent to those skilled in art that the method can also be implemented in any other suitable network. It should be noted that the service provider 108 has provided the first identity federation token to the communication device 404 in FIG. 4. Therefore, in this embodiment, the service provider 108 also acts as an asserting party as described in FIG. 2 and FIG. 3.

[0047] The first identity federation token issued by the service provider 108 at the conference invitation along with first token 412 is a constraint-based assertion encoded with set of constraints in Fig. 4. This means that the first identity federation token has a set of pre-defined constraints and cannot be used to provide the first identity of the communication device 404 unless the set of pre-defined constraints is satisfied. In accordance with the present invention, the set of pre-defined constraints need to be satisfied by a second assertion from a second asserting party.

[0048] In one embodiment, the communication device 404 sends a request 602 to the asserting party 502 to obtain a second identity federation token to satisfy the set of pre-defined constraints. On receiving the request 602, the asserting party 502 sends a second identity federation token by using a second token delivery 604 to the communication device 102. The second identity federation token is associated with a second identity of the communication device 102. In a specific case, the second identity federation token can also be a constraint-based assertion and is associated with another set of constraints. This set of constraints can require the support of a set of assertions provided by a set of asserting parties 606. For example, when the communication device 404 is a mobile phone of a user, the user may intend to join the conference initiated by a conferencing service of his/her enterprise from this mobile phone. The conferencing service in this case can act as the service provider 108. Further, the user needs to provide an assertion from the enterprise, to indicate to the service provider 108 that he/she is the intended participant of the conference. This indication can be in the form of a second identity federation token as provided by the enterprise. The enterprise therefore, acts as the asserting party 502. Further, the second identity federation token can also be a constraint-based assertion that requires an assertion from a mobile service provider of the communication device 404 to assure the trustworthiness of the mobile phone used by the user to join the conference. [0049] The communication device 404 sends a set of tokens request 608 to the set of asserting parties 606 to obtain a set of identity federation tokens to satisfy the set of pre-defined constraints of the second identity federation token. The set of asserting parties 606 then sends a set of tokens delivery 610, after appropriate authentication, if required, to the communication device 404 to provide the set of identity federation tokens that satisfies the pre-defined constraints of the second identity federation token. In the example mentioned above, the set of identity federation tokens can be provided by the mobile service provider.

[0050] After receiving the set of tokens from the set of asserting parties 606, the communication device 404 sends a conference joining request 612 to the service provider 108, along with the tokens to join the conference. The communication device 404 sends the first identity federation token, the second identity federation token and the set of identity federation tokens with the conference joining request 612. On receiving the conference joining request 612, the service provider 108 verifies the first identity federation token associated with a first identity of the communication device 404. The service provider 108 identifies the set of pre-defined constraints defined in the first identity federation token. The service provider 108 then verifies the second identity federation token and checks if it satisfies the set of pre-defined constraints associated with the first identity federation token. Further, the service provider 108 then checks the set of identity federation tokens to verify if they satisfy the set of constraints of the second identity federation token. Once all the assertions have been validated, the service provider 108 sends a conference access notification 614 to the communication device 404 to indicate that the communication device 404 is allowed to join the conference.

[0051] FIG. 7 is a call flow diagram representing a method for providing a service to a communication device 702, in accordance with the present invention. Reference has been made to FIGs. 1, 2, 3, 4, 5 and 6 for the sake of clarity of the description, although it will be apparent to those skilled in the art that the invention can also be applicable to other networks. Further, the network connection is assumed to be a mobile network in an identity federation environment. For example a home provider 704 can provide mobile services to the communication device 702. The service provider 108 can be a foreign mobile service provider in a different country without any trust-based relationship with the home provider 704 of the communication device 702. When the communication device 702 is in the foreign country, the home provider 704 will not be able to provide the communication device 702 with mobile services, and therefore, the user will need to contact a foreign mobile service provider for communication. For this the communication device 702 sends a connection request 706 to the service provider 108, to gain access to the mobile services from the service provider 108 in the foreign country.

[0052] Since there is no trust-based relationship between the home provider 704 and the service provider 108, an identity federation token sent by the home provider 704 alone would not be sufficient for the service provider 108 to verify the identity of the communication device 702. Therefore, the communication device 702 requires an assertion from another asserting party that has a trust-based relationship with the service provider 108. For example, an asserting party 708 can have a trust-based relationship with the service provider 108. The communication device 702 can send a first token request 710 to the asserting party 708 to request for a first identity federation token. Further, the first identity federation token can be associated to a first identity of the communication device 702. In one embodiment, the first identity can be a web-based login of the user of the communication device 702 at some web- portal which the home provider is willing to trust. In another embodiment, the first identity can be an identity issued by a financial organization like a bank. The first identity is defined by an identity -based relationship between the communication device 702 and the asserting party 708. The first identity federation token should be such that it is capable of indicating the identity of the communication device 702 to the service provider 108. On receiving the first token request 710, the asserting party 708 may need to authenticate and verify the identity of the communication device 702. The asserting party 708 then sends a first token delivery 712 to the communication device 702. The first identity federation token includes a set of predefined constraints that can be satisfied by a second identity federation token from the home provider 704 based on the identity-based relationship between the communication device 702 and the home provider 704. In one embodiment, the second identity federation token is generated locally based on secure credentials stored within the mobile device by the home provider 704. In another embodiment, the second federation tokens can be pre-loaded into the mobile phone, prior to the roaming scenario by the home provider 704.

[0053] The second identity federation token should be such that it satisfies the set of pre-defined constraints of the first identity federation token. The communication device 702 then sends the first identity federation token and the second identity federation token to the service provider 108 by a delivery of tokens 714. The service provider 108 then verifies the first identity federation token, to assert the first identity of the communication device 702, and identifies the set of predefined constraints associated with the first identity federation token. Further, the service provider 108 checks if the second identity federation token satisfies the set of pre-defined constraints of the first identity federation token. On verification of the first and the second identity federation token, the first identity and the second identity are indicated to the service provider 108. The service provider 108 then sends a service access notification 716 to the communication device 702 indicating activation of the services based on the connection request 706.

[0054] It should be apparent to those skilled in the art that the present invention is independent of the way in which the relying party receives the first and second identity federation tokens. The relying party can receive the first identity federation token and the second identity federation token from the asserting parties as indicated in FIG. 3. Further, the relying party can receive the first identity federation token and the second identity federation token from the communication device as described in FIG. 2, 4, 5, 6 and 7.

[0055] Various embodiments of the present invention provide a method for multi- factor assertion generation and usage. The method enables multiple usage of assertions. A single constraint-based assertion that is encoded with constraints which needs to be satisfied by another set of assertions can be provided to multiple users by laying down the requirements that must be produced at the time of usage. Thus, multiple users can use the single constraint-based assertion by providing different supporting assertions, which satisfy the requirements of the constraint-based assertion. The constraint-based assertion may lay down different requirements, to increase the number of users who can use the assertion. Further, the method ensures dynamic linking of assertions with users. Further, it is possible to issue constraint- based assertions without prior knowledge of exactly which users will use them. Thus, there can be run-time coupling between an assertion and a user if the user can produce sufficient assertions to prove its claim to be the user of the constraint-based assertion.

[0056] The method also enables an asserting party to issue an assertion without prior knowledge about the entity that is going to use it. The asserting party can issue a constraint-based assertion, which only asserts some information about the entity and can lay down a requirement that the constraint-based assertion needs to be supported by another assertion from another asserting party, for it to be usable.

[0057] The method also enables the use of assertions for the purpose of delegation. The constraint-based assertions are provided as a part of this delegation. These constraint-based assertions can provide the credentials but can only be used when they are supported by the requisite assertions. The constraint-based assertions can also be passed on to support further levels of delegation. This method for delegation is relatively safe, since it works when it is supported with another assertion that provides a user's credentials.

[0058] It is expected that one with ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, the available time, current technology and economic considerations, when guided by the concepts and principles disclosed herein, will be readily capable of generating such a method for multi-factor assertion generation and usage with minimal experimentation.

[0059] 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

CLAIMSWhat is claimed is:

1. A method for providing information about an identity of a communication device to a relying party in an identity federation environment, the method comprising: receiving a first token associated with a first identity, wherein the first token comprises a set of pre-defined constraints; receiving a second token associated with a second identity, wherein the second token is used to satisfy the set of pre-defined constraints of the first token; and indicating the first identity and the second identity to the relying party, wherein the first identity and the second identity provide information about the identity of the communication device.

2. The method of claim 1, wherein the identity is associated with a user of the communication device.

3. The method of claim 1, wherein the set of pre-defined constraints comprises at least one of a timing-based constraints, condition of a specific relying party, status of a federation relationship between an asserting party of the first identity and the relying party, status of a federation relationship between an asserting party of the first identity and an asserting party of the second identity, identification of a specific communication device, specifying a set of second asserting parties to be needed to provide a set of second tokens with the first token or a method of use of the first token, specifying the set of required characteristics of the set of second tokens.

4. The method of claim 1, wherein the second token is associated with a second set of pre-defined constraints which are satisfied by the first token.

5. The method of claim 1, wherein the set of pre-defined constraints are encoded such that the set of pre-defined constraints can be decoded exclusively by a pre-defined relying party.

6. The method of claim 1, wherein the second token is associated with one or more constraints, the one or more constraints are satisfied by a set of tokens provided by a set of asserting parties.

7. The method of claim 1, wherein at least one of the first identity and the second identity is the identity of the communication device.

8. The method of claim 1, wherein the first identity and the second identity are provided by two different asserting parties.

9. The method of claim 1, wherein the first identity and the second identity are provided by an asserting party.

10. The method of claim 1, wherein the identity federation environment is a telecommunication network and wherein at least one of asserting party for the first identity, asserting party for the second identity, and the relying party is a service provider.

11. The method of claim 1 , 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.

12. The method of claim 1, wherein a service is provided by the relying party based on the first token and the second token.

13. The method of claim 1, wherein the relying party is one of the asserting party of the first identity and asserting party of the second identity.

14. A method for determining identity of a communication device in an identity federation environment, the method comprising: providing a first token to a relying party by a first asserting party, wherein the first token is associated with a first identity and wherein the first token is related to a set of pre-defined constraints; and providing a second token to the relying party by a second asserting party, wherein the second token is associated with a second identity and wherein the second token satisfies the set of pre-defined constraints; and indicating the first identity and the second identity to the relying party, wherein the first identity and the second identity determines the identity of the communication device.

15. The method of claim 14, wherein the relying party is same as one of the first asserting party or the second asserting party.

16. The method of claim 14, wherein the second token is associated with one or more constraints, the one or more constraints are satisfied by using a set of tokens provided by a set of asserting parties.

17. The method of claim 14, wherein the identity federation environment is a telecommunication network and wherein at least one of the first asserting party, the second asserting party, and the relying party is a mobile service provider.