Identity management with local functionality

Patent metadata

Field	Value
Publication number	US-9774581-B2
Application number	US-201313745004-A
Country	US
Kind code	B2
Filing date	Jan 18, 2013
Priority date	Jan 20, 2012
Publication date	Sep 26, 2017
Grant date	Sep 26, 2017

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.

First claim

What is claimed:

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

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.

18. The method as recited in claim 1 , the method further comprising:
receiving, by the UE, the access token.

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

Assignees

• Interdigital Patent Holdings Inc

Inventors

• Leicher Andreas
• Shah Yogendra C
• Choyi Vinod K

Classifications

• H04L2463/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 title

• H04L9/3213

  using tickets or tokens, e.g. Kerberos (network architectures or network communication protocols for entities authentication using tickets in a packet data network H04L63/0807) · CPC title

• H04L63/08 Primary

  for authentication of entities (cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32) · CPC title

• H04L63/0815 Primary

  providing single-sign-on or federations · CPC title

• H04W12/06

  Authentication · CPC title