IDENTITY MANAGEMENT WITH LOCAL FUNCTIONALITY

• US 20130191884A1
• Filed: 01/18/2013
• Published: 07/25/2013
• Est. Priority Date: 01/20/2012
• Status: Active Grant

• Current Assignee: InterDigital Patent Holdings, Inc. (InterDigital, Inc.)
• Original Assignee: InterDigital Patent Holdings, Inc. (InterDigital, Inc.)
• Inventors: Leicher, Andreas, Shah, Yogendra C.
• Granted Patent: US 9,774,581 B2
• Time in Patent Office: Days
• US Class Current: 726/4
• 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. In a system comprising a user equipment (UE), an identity provider (IdP), and a service provider (SP) which communicate via a network, a method comprising:

receiving a request for a token, wherein the request for the token is responsive to a request for access to a service provided by the service provider;

in response to the request for the token, at the UE, creating an identity (ID) token in accordance with the request for the token; and

issuing, via the UE, the ID token, wherein the ID token is verified to provide the UE access to the service.

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, the method further comprising:

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

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

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

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

6. The method as recited in claim 5, 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.

7. The method as recited in claim 5, 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.

8. The method as recited in claim 5, wherein the user information endpoint is located on at least one of the UE or a network entity that communicates with the SP via the network.

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

10. The method as recited in claim 3, 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.

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

receiving an authorization request to create an access token for the SP,

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

12. The method as recited in claim 11, wherein the first access token comprises information indicative of a 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 UE and the second user information endpoint is located on a network entity that communicates with the SP via the network.

13. The method as recited in claim 12, 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.

14. 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).

15. In a system comprising a user equipment (UE), an identity provider (IdP) and a service provider (SP) which communicate via a network, a method comprising, at the UE:

receiving a request for user data;

receiving a user consent to release a consented portion of the user data;

in response to the user consent, generating an access token associated with the SP; and

issuing the access token to the SP, wherein the consented portion of the user data is released to the SP upon a verification of the access token.

16. The method as recited in claim 15, wherein the requested user data comprises a plurality of user attributes, wherein at least one of the plurality of the user attributes are not part of the consented portion of the user data that is released.

17. The method as recited in claim 15, further comprising:

signing the access token with a signature, the signature comprising at least one of an identifier of the UE or an identifier of a trusted environment that resides within the UE.

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

signing the access token with a secret that is shared by the UE and the IdP that communicates with the SP via the network.

19. The method as recited in claim 15, wherein a user information endpoint resides within the UE, the method further comprising:

receiving the access token at the user information endpoint; and

in response to receiving the access token, providing the consented portion of the user data to the SP.

20. In a system comprising a user equipment (UE) and a service provider (SP) which communicate via a network, a method comprising:

receiving, at the SP, a request for access to a service that is provided by the SP, the request comprising at least one of an identifier of a user of the UE or an identifier of the UE;

in response to the request for access, at the SP, receiving an identity (ID) token and a first access token; and

in response to a verification of the access token, at the SP, retrieving a first user attribute from a first user information endpoint, wherein the first user information endpoint resides on the UE.

21. The method as recited in claim 20, the method further comprising:

verifying, at the SP, a signature of the ID token using a secret stored on the SP; and

in response to the verification, granting the UE access to the service.

22. The method as recited in claim 20, the method further comprising:

sending the received ID token to a check ID endpoint for verification; and

sending the received first access token to the first user information endpoint for verification, thereby treating the ID token and access token as opaque values.

23. The method as recited in claim 20, the method further comprising:

in response to the request for access, receiving a second access token;

in response to a verification of the second access token, at the SP, retrieving a second user attribute from a second user information endpoint, wherein the second user information endpoint resides on a network entity that communicates with the SP via the network; and

combining, at the SP, the first user attribute and the second user attribute.

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

a memory comprising executable instructions; and

a processor in communications with the memory, the instructions, when executed by the processor, cause the processor to effectuate operations comprising;

receiving a request for a token, wherein the request for the token is responsive to a request for access to a service provided by a service provider (SP);

in response to the request for the token, creating an identity (ID) token in accordance with the request for the token; and

issuing the ID token, wherein the ID token is verified to provide the WTRU access to the service.

25. The WTRU as recited in claim 24, wherein the processor is further configured to execute the instructions to perform operations comprising:

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

in response to the authorization request, creating the access token associated with the user approval of the authorization request.

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

27. The WTRU as recited in claim 26, 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.

28. The WTRU as recited in claim 25, wherein the user information endpoint is located on at least one of the WTRU or a network entity that communicates with the SP via the network.

29. The WTRU as recited in claim 24, wherein the processor is further configured to execute the instructions to perform operations comprising:

receiving an authorization request to create an access token for the SP,

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

30. The WTRU as recited in claim 29, wherein the first access token comprises information indicative of a 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.