Identity management with local functionality

• US 9,774,581 B2
• Filed: 01/18/2013
• Issued: 09/26/2017
• Est. Priority Date: 01/20/2012
• Status: Expired due to Fees

• Current Assignee: InterDigital Patent Holdings, Inc. (InterDigital, Inc.)
• Original Assignee: InterDigital Patent Holdings, Inc. (InterDigital, Inc.)
• Inventors: Leicher, Andreas, Shah, Yogendra C., Choyi, Vinod K.
• Primary Examiner(s): Pham, Luu
• Assistant Examiner(s): JACKSON, JENISE E
• Application Number:
  US13/745,004
• Publication Number:
  US 20130191884A1
• Time in Patent Office: 1,712 Days
• Field of Search: 726 4, 726 9, 713172, 713193
• CPC Class Codes: H04L 2463/081 applying self-generating credentials, e.g. instead of receiving credentials from an authority or from another peer, the credentials are generated at the entity itself
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0815 providing single-sign-on or federations
• CPC Class Codes: H04W 12/069 using certificates or pre-shared keys

Abstract

A user equipment (UE) may perform functions locally, such as on a trusted module that resides within the UE. For example, a UE may perform functions associated with a single sign-on protocol, such as OpenID Connect for example, via a local identity provider function. For example, a UE may generate identity tokens and access tokens that can be used by a service provider to retrieve user information, such as identity information and/or user attributes. User attributes may be retrieved via a user information endpoint that may reside locally on the UE or on a network entity. A service provider may grant a user access to a service based on the information that it retrieves using the tokens.

Claims

1. A method for implementing identity management within a system comprising a user equipment (UE), an identity provider (IdP), and a service provider (SP) which communicate via a network, wherein the UE comprises a processor, the method comprising:

receiving, by the UE comprising the processor, a request for at least one token, wherein the request for the at least one token is responsive to a request for access to a service provided by the service provider;

receiving, by the UE comprising the processor, an authorization request to create an access token for the SP, wherein the authorization request is approved by a user of the UE;

in response to the authorization request, at the UE, creating the access token, wherein the access token is associated with the user approval of the authorization request;

issuing, by the UE, an identity (ID) token in accordance with the request for at least one token, such that the ID token is verified to provide the UE access to the service;

issuing, by the UE, the access token; and

releasing, by a user information endpoint that resides on the UE, a user attribute if the access token is verified.

2. The method as recited in claim 1, wherein the ID token is created securely in a trusted environment that resides within the UE.

3. The method as recited in claim 1, wherein the user approval of the authorization request is received automatically via a policy of the UE.

4. The method as recited in claim 1, wherein the access token comprises information indicative of a location of the user information endpoint, wherein the user information endpoint provides a requested user attribute to the SP upon a verification of the access token.

5. The method as recited in claim 4, wherein the verification of the access token comprises a verification that the user consented to a release of the requested user attribute to the SP.

6. The method as recited in claim 4, wherein the access token is created securely in a trusted environment that resides within the UE, and wherein the verification of the access token comprises a verification that the trusted environment is valid.

7. The method as recited in claim 1, wherein the ID token and the access token are created in accordance with an OpenID Connect protocol.

8. The method as recited in claim 1, wherein the ID token and the access token are created securely in a trusted environment that resides within the UE, the method further comprising:

determining an authentication status of the user with the trusted module; and

if the authentication status indicates that the user is not authenticated, authenticating the user at the trusted environment.

9. The method as recited in claim 1, wherein the access token is a first access token, the method further comprising:

based on the authorization request, at the UE, creating the first access token and a second access token, the access tokens associated with the service and the user.

10. The method as recited in claim 9, wherein the user information endpoint is a first user information endpoint and the first access token comprises information indicative of a location of the first user information endpoint that provides a first requested user attribute to the SP upon a verification of the first access token, and the second access token comprises information indicative of a location of a second user information endpoint that provides a second requested user attribute to the SP upon a verification of the second access token, and wherein the first user information endpoint is located on the UE and the second user information endpoint is located on a network entity that communicates with the SP via the network.

11. The method as recited in claim 10, wherein the first requested user attribute provided by the first user information endpoint is classified as confidential data by the user, and the second requested user attribute provided by the second user information endpoint is classified as nonconfidential data by the user.

12. The method as recited in claim 2, wherein the SP is an OpenID Connect client and the trusted environment is a local OpenID identity provider (OP).

18. The method as recited in claim 1, the method further comprising:

receiving, by the UE, the access token.

13. A wireless/transmit receive unit (WTRU) comprising:

a memory comprising executable instructions; and

a hardware processor in communications with the memory to execute the instructions, such that the processor is configured to;

receive a request for at least one token, wherein the request for the at least one token is responsive to a request for access to a service provided by a service provider (SP);

receive an authorization request to create an access token for the SP, wherein the authorization request is approved by a user of the WTRU;

in response to the authorization request, create the access token, wherein the access token is associated with the user approval of the authorization request;

issue the identity (ID) token in accordance with the request for the at least one token, wherein the ID token is verified to provide the WTRU access to the service;

issue the access token; and

release, by a user information endpoint that resides on the WTRU, a user attribute if the access token is verified.

14. The WTRU as recited in claim 13, wherein the access token comprises information indicative of the location of the user information endpoint, wherein the user information endpoint provides the requested user attribute to the SP upon a verification of the access token.

15. The WTRU as recited in claim 14, wherein the verification of the access token comprises a verification that the user consented to a release of the requested user attribute to the SP.

16. The WTRU as recited in claim 13, wherein the access token is a first access token and the processor is further configured to:

based on the authorization request, at the WTRU, create the first access token and a second access token, the access tokens associated with the service and the user.

17. The WTRU as recited in claim 16, wherein the user information endpoint is a first user information endpoint and the first access token comprises information indicative of the location of a first user information endpoint that provides a first requested user attribute to the SP upon a verification of the first access token, and the second access token comprises information indicative of a location of a second user information endpoint that provides a second requested user attribute to the SP upon a verification of the second access token, and wherein the first user information endpoint is located on the WTRU and the second user information endpoint is located on a network entity that communicates with the SP via a network.

19. The WTRU as recited in claim 13, wherein the processor is further configured to receive the access token.