WO2013151752A1

WO2013151752A1 - On-demand identity and credential sign-up

Info

Publication number: WO2013151752A1
Application number: PCT/US2013/032172
Authority: WO
Inventors: Vinod Kumar Choyi; Yousif TARGALI; Yogendra C. Shah
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2012-04-05
Filing date: 2013-03-15
Publication date: 2013-10-10

Abstract

An identity and credentials may allow a mobile device to communicate with one or more service providers that provide a service. A hotspot network that provides access to the internet is an example of such a service provider. A user equipment (UE), such as a wireless transmit/recite unit (WTRU), may authenticate with an identity provider, such as an OpenID identity provider, to establish an original identity. A new identity may be requested from the identity provider, and a selected one credential that is associated with the new identity may be requested and obtained from the identity provider. The selected one credential may be required to access a service that is provided by a network entity, such as a hotspot network for example. The UE may authenticate with the network entity using the new identity and the selected credential.

Description

ON-DEMAND IDENTITY AND CREDENTIAL SIGN-UP

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This Application claims the benefit of U.S. Provisional Application Serial No. 61/620,775, filed April 5, 2012, the contents of which are hereby incorporated by reference in their entirety.

BACKGROUND

[0002] Mobile devices are increasingly used to access internet services. Often a network access entity or service, such as a hotspot network for example, may require a user to enter data to access the network and/or obtain a username and password. For example, a hotspot network may require a user to provide sensitive data, such as a credit card number for example, to access the network. Such user input often imposes security risks and authentication burdens on the user in the form of data requirements such as usernames, pins, credit card numbers, and /or passwords.

Additionally, a connection to a hotspot network is often insecure.

[0003] Existing approaches to provisioning a mobile device with an identity and credentials often require an offline process in which an operator or a service provider provisions one type of identity and a corresponding set of credentials for authentication purposes. Such an offline process lacks flexibility and hinders subscription to services. Additionally, existing approaches often provision identities and credentials on a permanent basis and offer little flexibility for deriving identities and credentials.

SUMMARY

[0004] Systems, methods, and apparatus embodiments are described herein for provisioning a mobile device with one or more identities and/or one or more credentials. Identities may be temporary or permanent. Provisioning may be completed a priori or on-demand. Authentication may be based on the provisioned identities and/or credentials. A user may request multiple identities and credentials and certain types of identities and credentials. For example, a mobile device may receive one or more identities and one or more credentials via a trusted authority such as, for example, an identity provider. The identities and credentials may be used to establish secure communication between a mobile device and a network entity, such as a hotspot network for example. At least one of one of the received identities and at least one of the received credentials may be used to authenticate the mobile device with the network access entity.

[0005] In an example embodiment, a user equipment (UE) authenticates with an identity provider to establish an original identity. The UE requests and obtains from the identity provider a new identity and a selected one of a plurality of credentials. The selected one credential is required to access a service that is provided by a network entity. Each of the credentials of the plurality of credentials are classified into different types. Such types may include a certificate, a shared secret, a password, and a token, for example. The UE is authenticated with the network entity using the new identity and the selected one credential, which, again, may be a certificate, a shared secret, or a password/token. The new identity may be a temporary identity that has a finite lifetime or it may be a permanent identity.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0007] Fig. 1 is a diagram illustrating an example provisioning call flow according to an example embodiment;

[0008] Fig. 2 is a diagram illustrating example provisioning functions according to an example embodiment;

[0009] Fig. 3 is a flow diagram for deriving a temporary identity according to an example embodiment;

[0010] Fig. 4 is a flow diagram illustrating an example call flow for the provisioning of an identity and a certificate according to an embodiment;

[0011] Fig. 5 is a flow diagram illustrating an example protocol flow for provisioning with authentication based on EAP-TLS according to an embodiment;

[0012] Fig. 6 is a flow diagram of an example call flow for provisioning with

authentication based on EAP-TTLS according to an embodiment;

[0013] Fig. 7 is a flow diagram illustrating a combined provisioning and authentication call flow according to an embodiment that uses authentication based on EAP-TLS; [0014] Fig. 8 is a flow diagram illustrating another combined provisioning and authentication call flow according to an embodiment that uses authentication based on EAP-TTLS;

[0015] Fig. 9 is a flow diagram illustrating a provisioning and authentication call flow using a generic bootstrapping architecture (GBA) according to an embodiment;

[0016] Fig. 10A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0017] Fig. 10B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in Fig. 10A; and

[0018] Fig. IOC is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in Fig. 10A.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0019] The ensuing detailed description is provided to illustrate exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the invention. Various changes may be made in the function and arrangement of elements and steps without departing from the spirit and scope of the invention.

[0020] Systems, methods, and apparatus embodiments are described herein for

provisioning identities and credentials on a mobile device, such as a user equipment (UE). For example, temporary and/or permanent identities and credentials may be set-up and delivered on- demand. Some embodiments use single sign-on (SSO) systems to provision on-demand identities and credentials to mobile devices. Such mobile devices may be used for secure access to service providers and networks. While the embodiments described herein may be described in the context of OpenID protocols, embodiments are not limited to implementing the OpenID protocols, and may implement other single sign-on (SSO) protocols and/or federated identity protocols for example. Similarly, while OpenID entities may be used as references herein, embodiments are not limited to OpenID entities, and the OpenID entities may be extendable to other entities that perform the same, or similar, functions as OpenID entities. For example, as used herein, the terms relying party (RP) and client may refer to a service provider (SP), such as a service website. The terms OpenID identity provider (OP) and authorization server may refer to a network identity provider (IdP) or an authentication endpoint (AEP). The term user equipment (UE) may refer to any appropriate wireless transmit/receive unit (WTRU), as further described herein. [0021] Embodiments described herein use SSO systems to request on-demand identities and/or authentication credentials. Identities may be temporary or permanent and identities may be based on various protocols such as, for example, OpenID or OpenID connect. Identities may be provided by various entities such as, for example, a mobile network operator (MNO) or an OpenID identity provider (OP). Authentication credentials such as, for example, passwords, tokens (e.g., one-time passwords), certificates, and shared secrets may be used to authenticate mobile devices and/or users for secure access to services or networks. SSO systems may be used for obtaining an on-demand identity and an authentication credential for use in authenticating a mobile device and/or user for communication with a network entity or other service providers. Requesting and

provisioning of identities and credentials may be performed using one or more connections with an identity provider. In one embodiment, an association (e.g., connection) with an identity provider is bootstrapped to derive identities and/or credentials for use in another connection, service, or context. Derived identities may be stored in a secure storage such as, for example, a universal integrated circuit card (UICC), a soft subscriber identity module (SIM), or the like. Such secure storage may interact (e.g., communicate) directly with an identity provider or may interact with an identity provider through intermediaries. Various SSO systems may be utilized for provisioning identities and credentials for a mobile device and a user. For example, an SSO system may comprise an identity provider server (e.g., an OpenID identity provider (OP) server) and a service provider (e.g., a relying party (RP)). In one example embodiment, an SSO system comprises an OpenID connect server and a client. In another example embodiment, an SSO system comprises a bootstrapping server function (BSF) and a network access function (NAF). SSO systems may be implemented by other network entities and other protocols in accordance with various embodiments.

[0022] In various embodiments described herein, identities and credentials may be provisioned on a temporary or permanent basis. For example, temporary identities and credentials that are associated with the temporary identities may be derived. Requesting and provisioning temporary or permanent identities and credentials may be done a priori or on-demand.

Authentication may be based on the provisioned identity and credentials. For example, Fig. 1 shows a high level provisioning process that uses a temporary identity and associated credentials according to an example embodiment. A temporary identity and credentials may allow a mobile device to access a service provided by a service provider on a temporary basis. Referring to Fig. 1 , a user/UE 10, at 16, requests a temporary identity and credentials from an identity provider (IdP) 12. At 18, the IdP 12 requests the appropriate credentials and interacts with a credentials provisioning entity 14 to receive the credentials. At 20, the requested temporary identity is received by the user/UE 10, and the appropriate credentials are provisioned to the user/UE 10. The IdP 12 may be physically located with the credentials provisioning entity 14 or the IdP 12 may be physically separate from the credentials provisioning entity 14.

[0023] Fig. 2 shows an example of identity and credential provisioning according to an embodiment in which a user/UE 200 is authenticated using an OpenID protocol. Thus, the IdP 202 in Fig. 2 may be referred to as an OpenID identity provider (OP) 202, although other SSO protocols may be utilized as desired. Referring to Fig. 2, the UE 200 (e.g., a mobile device) may

communicate with one or more trusted authorities such as, for example, one or more identity providers (IdPs). For example, the UE 200 may request an identity and/or credentials used for authenticating with service providers on a temporary basis in a proactive manner or a reactive manner. Thus, the UE 200 may request temporary credentials and identities in response to a current need (e.g., reactive manner) or based on a possibility that they will be used in the future (e.g., proactive manner). The IdP 202 may interact with other entities within its domain in order to provision the credentials. Such entities may be functions that are included as part of the IdP, entities that are separate from the IdP, or a combination thereof. Referring to the example embodiment shown in Fig 2, the IdP 202 comprises various entities including an identity generating function 204, a crypto function 206 (e.g., HMAC-SHA-256 or any other function), a shared key generation function 208, a token/password generation function 210, a certificate authority (CA) 212, an authentication function 214, and an identity computation function 216. The IdP 202 may include other entities, for example, that are involved with setting up communications (e.g., secure and/or regular) with the UE 200. The UE 200 comprises entities that are associated with entities of the IdP 202, and that interact with respective entities of the IdP 202. Functions may reside on the UE 202 and/or on the UICC or another trusted environment. Entities residing on the UE 200 comprise, without limitation, an authentication function 218, an identity/credential request function 220, and a crypto and key generation function 222 (e.g., shared secret, public/private key pair).

[0024] Still referring to Fig 2, at 224, the UE 200 communicates with the IdP 202 and may authenticate with the IdP 202 using OpenID or another SSO protocol. For example, the

authentication function 218 of the UE 200 and the authentication function 214 of the IdP 202 authenticates the UE 200 with the IdP 202 to verify an original identity. The UE 200 and the IdP 202 may mutually authenticate one another. At 226, the UE 200 requests an identity, which may be referred to as a new identity, from the IdP 202. The request may be for a permanent or temporary identity, and the requested new identity may correspond to a specific type of credentials. For example, the request at 226 may include a request for a credential from a plurality of credentials, wherein each credential of the plurality of credentials is classified into different types. Thus, the request at 226 may comprise a request for a specific type of credential. Types of credentials may include, without limitation, a certificate, a shared secret, a password, and a token.

[0025] For example, if the request at 226 is for a shared key credential, the shared key generation function 208 of the IdP 202, in conjunction with the crypto and key generation function 222 of the UE 200, may derive a master session key at 228. Such a master session key may be used to generate session keys for accessing services, for example, that are of interest to the UE and are provided by a service provider. If the request at 226 is for a certificate, a certificate provisioning process is initiated with the UE 200 at 230. For example, the UE 200 may send a request (e.g., based on public key cryptography standard (PKCS) #7 format) comprising its public key. The IdP 202 may generate an identity and issue a certificate with a specific lifetime, for example, with the aid of the CA 212. The certificate may be signed by the CA 212. An example method of deriving the identity for use with the certificate according to one embodiment is described herein. If the request at 226 is for a password and/or a token (e.g., one time use and throw), the token/password generating function 210 generates the token/password and sends it to the UE/user 200 at 232. The token/password may be sent to the UE 200 via a secure tunnel and/or it may be encrypted. At 234, the new identity is sent to the UE 200. If the request at 228 is for a shared key credential, the identity may be derived and sent to the UE 200, at 234, as part of the key generation process that occurs at 228.

[0026] The new identity may be generated by the identity (ID) generation function 204. The identity may be generated a priori or parallel to generating the credentials, for example, depending on the type of credentials that are generated. In an example embodiment in which the credentials comprise a provisioned certificate, the identity is placed in the certificate before it is signed by the CA 212. In such an embodiment, the identity is derived before the certificate is signed. In an example embodiment in which the credentials are based on shared-key generation, the identity may be generated as part of the key generation (see 228). In an embodiment in which a password/token is generated, the temporary identity may be generated a priori the credentials (password/token) are generated. For example, the ID generation function 204 may use the ID computation function 216 and the crypto function 206 to generate a temporary identity before a token is generated. The UE 200 (or user) may request for multiple identities and associated credentials in a parallel or a serial fashion.

[0027] In an example embodiment, temporary and/or permanent identities (e.g., OpenID identities) may be provisioned based on a user's (e.g., subscriber) original identity via cryptographic means. For example, a new identity may be provisioned by starting with a temporary identity that is created using a username that belongs to the user and applying the crypto function 206, such as HMAC-SHA-256 for example, to the temporary identity (e.g., username). Other temporary identities may be derived based on a password, shared key, or a token that is generated after the type of credentials are requested at 226, for example.

[0028] Fig. 3 shows a flow diagram for deriving a temporary identity 300 according to an example embodiment. In accordance with the illustrated embodiment, the temporary identity 300 is derived from a public key 302. Referring also Fig. 2, the public key 300 may be derived by the UE 200 as part of a public/private key pair and may be provided to the IdP 202 as part of the identity/certificate request at 226. The public key 302 may be used to derive the temporary identity 300 or a permanent identity. For example, in accordance with the illustrated embodiment shown in Fig. 3, the public key 302 is input into a key derivation function (KDF) 306 that takes a key (e.g., the public key 302) and a string 304 as an input, and produces an output that may be 256 bits or any other size based on the KDF 306. The string 304 may comprise information indicative of the domain of the IdP, the type of request, and/or or any other relevant information, for example, that may pertain to the requester/issuer, type of request, and/or use of the credentials. Referring again to Fig. 3, at 308, the first 32 bits of the crypto function are encoded using Base64, for example, to create a textual identity, and the "realm" portion of the IdP is appended to the identity 300. The identity 300 that is created may be in the form of an NAI, URL, or any other form, for example, that may be used for authentication. The size and order of the bits may vary and depend on the request from the UE/user/service. In the illustrated embodiment, at 308, only the first 32 bits are encoded, but it will be understood that the number of bits, order of bits, and encoding of the bits may vary as desired.

[0029] Referring again to Fig. 2, credentials of various types may be requested by the UE 200 at 226. Certificates, such as X.509 certificates for example, may be generated based on a user request at 226. For example, the UE 200 may request a subscription to an identity and a certificate using appropriate requests. Such requests may use public key cryptography standard (PKCS) #7 and a secure tunnel. The certificate may be signed by a CA, for example the CA 212, which is trusted by the IdP 202. At 234, the IdP 202 may provide the derived identity with the user supplied public key to the UE 200. In an example embodiment, the message at 234 includes an agreed lifetime of the certificate, which may be based on the subscription to the CA that issued the certificate. In an example embodiment, the lifetime may be based on policies that dictate the life of the certification according to various parameters, such as the type of service and type of usage for example. For example, the lifetime of a certificate may vary from a day to multiple years, although embodiments are not so limited. The lifetime of a certificate may depend upon the agreed upon subscription and/or terms and conditions for use.

[0030] Shared secrets may be derived based on an earlier authentication or may be newly derived, for example at 228 in Fig. 2. Shared secrets may be newly derived based on protocols such as, for example, the Internet Key Exchange protocol or algorithms leveraging the Diffie-Hellman process. The shared secret may be mapped to an identity that was derived or provided to the UE. The shared secret may have an associated lifetime, for example, based on terms and conditions of the subscription.

[0031] In an example embodiment, a UE (or user) requests one-time passwords (or temporary tokens) that may be used to access a service for a limited amount of time. Referring to Fig. 2, temporary passwords may be derived by the IdP 202 with the temporary identity by invoking the Token/Password Generation Function 210. Temporary passwords/tokens are sent to the UE at 232. The token/password may be sent to the UE 200 via a secure tunnel and/or the token/password may be encrypted. Derived passwords may be long term passwords, as reflected in an increased lifetime of such derived passwords.

[0032] Fig. 4 shows a flow diagram of dynamic provisioning of an identity and an associated certificate according to one example embodiment. At 414 and 416, a UE (user) 400 registers with an identity provider (IdP) 408 and receives an OpenID Identity. The registration may be referred to as an "out-of-band" registration or an a priori registration. During the registration, the UE 400 may be provided with an SSO identity (e.g., a username) and/or a password. In accordance with the illustrated embodiment, the UE/user 400 is provided with an OpenID identity (e.g., username) and password. At 418, the UE 400 associates with an open service set identifier (SSID) of a hotspot network 402. In particular, at 418, the UE 400 associates with an access point (AP) 404 of the hotspot network 402. While the illustrated embodiments include hotspot networks such as the hotspot network 402, embodiments described herein may be implemented with various types of networks and various types of service providers as desired. The IdP 408 may include a server 410 and a certificate authority 412. The server 410 may also be referred to as an OP server, an authorization server, or an authentication/authorization/accounting (AAA) server.

[0033] At 420, a user, via the UE 400, may attempt to connect to a website on the internet. In the illustrated example, the UE 400 attempts to connect to Google's homepage. At 422, the hotspot network 402 redirects the UE 400 to a page that may include a menu. The menu may include various options that can be selected in order to access the hotspot network 402, and thus the internet. Options may include subscription options, payment options, rate options, and the like. In accordance with the illustrated embodiment, the hotspot network 402 includes the AP 404 and various entities and functions 406 such as a relying party (RP), an AAA proxy, a Captive Portal, and an online-sign-up (OSU) function. At 424, the UE 400 selects one or more options from the menu. The selected option may correspond to a type of internet access that is purchased by the user of the UE 400. At 424, the UE 400 provides an identity such as, for example, the user's OpenID identity (e.g., username) to an entity 406 (e.g., service provider) on the hotspot network 402. At 426, based upon the identity, at least one of the entities and functions 406 of the hotspot network 402 determines the identity provider 408 that provided the identity (e.g., username) that is associated with the UE 406. In accordance with the illustrated example, at 426, the RP determines that the IdP 408 provided the OpenID Identity (e.g., username) of the user/UE 400, and the RP and IdP 408 perform discovery and association. At 428 and 430, the service provider (e.g., the RP) re-directs the UE 400 to the IdP 408, which may be referred to as an OP, so that the UE 400 may authenticate with its IdP 408. At 432, The UE 400 and the IdP 408 perform authentication of the user/UE 400 based on the OpenID identity (e.g., username) and password from 414 and 416. At 432, the UE 400 may also perform an authentication of the IdP 408. At 434, after the UE 400 is authenticated, the UE 400 generates a public/private key pair.

[0034] In accordance with the illustrated embodiment, at 436, the UE 400 requests to obtain and/or purchase an X.509 certificate. The request at 436 that is carried out by the UE 400 may be proactive request that anticipates a future use for the certificate. Alternatively, the request at 436 may be a reactive request that is based on a current requirement. The UE 400 requests the certificate by issuing a message, based on the PKCS #10 standard for example, to the IdP 408. At 438, the IdP 438 derives an identity for the user/UE 400 based on the provided public key and/or other means that may be random or based on contextual usage of that identity. For example, if the usage is for playing a game called "Hulo" then the temporary identity may be

huloplayerl234@xyz.com. For example, the server 410 may communicate the public key, the derived identity of the user/UE 400, and the lifetime of the certificate to the CA 412. In accordance with the illustrated embodiment, the CA 412 issues a certificate and signs the certificate. At 440, the certificate is sent to the UE 400 via the IdP 408, for example, using PKCS #7 messaging. At 442, the IdP 408 sends a re-direct message comprising an assertion to the UE 400. The re-direct message at 442 may be sent after authentication at 432, or 442 may performed in parallel with steps 432, 434, and/or 436. The assertion at 442 confirms the authentication of the user/UE 400 and it may also confirm that a subscription was purchased by the user, thus confirming that the credentials (e.g., the certificate) may be used to access the hotspot network 402. The assertion may contain the certificate that was issued by the CA 412, and thus the IdP 408. In other embodiments, the assertion may contain the MSK or a domain key. In an embodiment in which the OpenID Connect protocol is implemented to authenticate the user/UE 400, it will be understood that the functions of the assertion may be implemented by an identity token and an access token. For example, the tokens may be used by the RP in the hotspot network 402 to verify the subscription and obtain the certificate.

[0035] As shown in the example embodiment illustrated in Fig. 5, a user/UE 500 may authenticate with a hotspot network 502 after an identity and a credential has been provisioned to the user/UE 500, and the authentication may be based on an extensible authentication protocol (EAP) with transport layer security (EAP-TLS). For example, UE authentication may implement EAP- TLS using client certificates. The hotspot network 502 includes an access point (AP) 504 and various entities and functions 506 such as a relying party (RP), an AAA proxy, a Captive Portal, and an online-sign-up (OSU) function.

[0036] In accordance with the illustrated embodiment, at 512, the UE 500 initially associates with the AP 504 using hotspot (HS) 2.0 SSID for example. At 514, the hotspot network 502 initiates an EAP authentication by requesting the identity of the user/UE 500. For example, an entity 506, such as the RP, may request the identity. At 516, the UE 500 sends its previously derived or created single sign-on temporary identity to the entity 506 of the hotspot network 502. In an alternative embodiment, the UE 500 may send its permanent identity at 516. At 518, the hotspot network 502 requests the UE 500 to use EAP-TLS authentication. For example, such a request may be negotiated as part of the EAP process. At 520, the UE 500 sends an EAP message to the hotspot network 502. The EAP message comprises a TLS client hello message with a client random value. At 522, the EAP message is forwarded to an identity provider 508. As illustrated, the identity provider 508 may include a server 510 which may also be referred to as an OP server 510, an authorization server 510, or an AAA server 510. Thus, the EAP message at 522 may be sent to the AAA server 510, and the EAP message may be encapsulated in a radius message.

[0037] Still referring to the example embodiment shown in Fig. 5, at 524, the AAA server 510 sends a server hello message with a server certificate and requests a client certificate. At 526, the server hello message with its certificate and the client certificate request is forwarded to the UE 500, for example, using an EAP message. In response to the client certificate request, the UE 500 sends its certificate toward the AAA server 510 at 530. The certificate that is sent at 530 was dynamically created and issued by the IdP 408, and was signed by the CA 412. At 532, the certificate of the UE 500 is forwarded to the AAA server 510 from the hotspot network 502. At 534, the AAA server 510 derives the master session key (MSK), for example, after authenticating the certificate of the UE 500. The MSK may be derived using the pre -master key and the random values established during the TLS handshake protocol. At 536, the MSK is forwarded to the hotspot network 502 in a secure manner, for example, using an EAP Success message. In accordance with the illustrated embodiment, at 538, the hotspot network 502 forwards the EAP Success message to the UE 500. At 540, the UE 500 derives the MSK. The UE 500 may derive the MSK in a manner similar to how the AAA server 510 derived its key at 534. At 542, the UE 500 and the AP 504 complete a handshake such as an 802.11 4-way handshake, for example, using the MSK. At 544, the UE 500 may acquire an internet protocol (IP) address. At 546, the UE 500 may access the internet using the secure hotspot network 502.

[0038] As shown in the example embodiment illustrated in Fig. 6, a user/UE 600 may authenticate with a hotspot network 602 after an identity and a credential has been provisioned to the user/UE 600, and the authentication may be based on an extensible authentication protocol (EAP) with tunneled transport layer security (EAP-TTLS). For example, UE authentication may implement EAP-TTLS using client passwords. The illustrated hotspot network 602 includes an access point (AP) 604 and various entities and functions 606 such as a relying party (RP), an AAA proxy, a Captive Portal, and an online-sign-up (OSU) function. [0039] In accordance with the illustrated embodiment, at 612, the UE 600 initially associates with the AP 604 using hotspot (HS) 2.0 SSID for example. At 614, the hotspot network 602 initiates an EAP authentication by requesting the identity of the user/UE 600. For example, an entity 606, such as the RP, may request the identity. At 616, the UE 600 send its previously derived single sign-on temporary identity to the entity 606 of the hotspot network 602. In an alternative embodiment, the UE 600 may send its permanent identity at 616. At 618, the hotspot network 602 requests the UE 600 to use EAP-TTLS authentication. For example, such a request may be negotiated as part of the EAP process. At 620, the UE 600 sends an EAP message to the hotspot network 602. The EAP message comprises a TLS client hello message with a client random value. At 622, the EAP message is forwarded to an identity provider 608. As illustrated, the identity provider 608 may include a server 610 which may also be referred to as an OP server 610, an authorization server 610, or an AAA server 610. Thus, the EAP message at 622 may be sent to the AAA server 610, and the EAP message may be encapsulated in a radius message.

[0040] Still referring to the example embodiment shown in Fig. 6, at 624, the AAA server 610 sends a server hello message with a server certificate. At 626, the server hello message with its certificate is forwarded to the UE 600, for example, using an EAP message. Steps 620, 622, 624, 626 may be referred to as a TLS handshake. The UE 600 authenticates with the AAA server 610 at 628. Such authentication may be based on a challenge-response mechanism, for example, wherein the UE 600 sends its temporary identity (e.g., a username) and the password that corresponds to the identity to the identity provider 608. The temporary identity was derived or created previously and the password was generated. In an alternative embodiment, the UE 600 may send a permanent identity and the password that corresponds to the permanent identity. At 630, the AAA server 610 derives the MSK, for example, after authenticating the user's password. The MSK may be derived by using the pre-master key and the random values that were established during the TLS handshake protocol. At 632, the MSK is forwarded to the hotspot network 602 in a secure manner, for example, using an EAP Success message. In accordance with the illustrated embodiment, at 634 and 636, the hotspot network 602 forwards the EAP Success message to the UE 600. For example, the AAA proxy server of the hotspot network may forward the EAP success message to the AP 604, which may forward the message to the UE 600. At 638, the UE 600 derives the MSK. The UE 600 may derive the MSK in a manner similar to how the AAA server 610 derived its key at 630. At 640, the UE 600 and the AP 604 complete a handshake such as an 802.1 1 4-way handshake, for example, using the MSK. At 642, the UE 600 may acquire an internet protocol (IP) address for the hotspot network 602. At 644, the UE 600 may access the internet using the secure hotspot network 602.

[0041] Fig. 7 shows a combined identity/credential provisioning and authentication protocol flow according to one example embodiment. Alternatively, the credential provisioning phases and the authentication phases may be separate. The phases may be implemented proactively or reactively. The provisioning phases and the service authentication phases may be combined, for example, in an on-demand scenario. A user in such a scenario may be prompted to subscribe to a service based on local requirements. Referring to the example embodiment shown in Fig. 7, temporary identity and credential provisioning (e.g., phase 1) and flexible authentication (e.g., phase 2) is based on EAP-TLS. In accordance with the illustrated embodiment, an identity and a certificate are provisioned from an access network 702 via an insecure connection (e.g., an open access point), and an authentication is performed (e.g., using EAP-TLS) for a UE 700 to access the internet via the network 702 using secure hotspot 2.0 SSID.

[0042] In accordance with the illustrated embodiment shown in Fig. 7, at 714 and 716, a UE (user) 700 registers with an identity provider (IdP) 708 and receives an OpenlD Identity. The registration may be referred to as an "out-of-band" registration or as an a priori registration. During the registration, the UE 700 may be provided with an SSO identity (e.g., a username) and/or a password. In accordance with the illustrated embodiment, the UE/user 700 is provided with an OpenlD identity (e.g., username) and password. At 718, the UE 700 associates with an open service set identifier (SSID) of a hotspot network 702. In particular, at 718, the UE 700 associates with an access point (AP) 704 of the hotspot network 702. While the illustrated embodiments include hotspot networks such as the hotspot network 702, embodiments described herein may be implemented with various types of networks and various types of service providers as desired. The IdP 708 may include a server 710 and a certificate authority 712. The server 710 may also be referred to as an OP server 710, an authorization server 710, or an AAA server 710.

[0043] At 720, a user, via the UE 700, may attempt to connect to a website on the internet. In the illustrated example, the UE 700 attempts to connect to Google's homepage. At 722, the hotspot network 702 redirects the UE 700 to a page that may include a menu. The menu may include various options that can be selected in order to access the hotspot network 702, and thus the internet. Options may include subscription options, payment options, rate options, and the like. In accordance with the illustrated embodiment, the hotspot network 702 includes the AP 704 and various entities and functions 706 such as a relying party (RP), an AAA proxy, a Captive Portal, and an online-sign-up (OSU) function. At 724, the UE 700 selects one or more options from the menu. The selected option may correspond to a type of internet access that is purchased by the user of the UE 700. At 724, the UE 700 provides an identity such as, for example, the user's OpenID identity (e.g., username) to an entity 706 (e.g., a service provider) on the hotspot network 702. At 726, based upon the identity, at least one of the entities and functions 706 of the hotspot network 702 determines the identity provider 708 that provided the identity (e.g., username) that is associated with the UE 706. In accordance with the illustrated example, at 726, the RP determines that the IdP 708 provided the OpenID Identity (e.g., username) of the user/UE 700, and the RP and IdP 708 perform discovery and association. At 728 and 730, the service provider (e.g., the RP) re-directs the UE 700 to the IdP 708, which may be referred to as an OP, so that the UE 700 may authenticate with its IdP 708. At 732, the UE 700 and the IdP 708 perform authentication of the user/UE 700 based on the OpenID identity (e.g., username) and password from 714 and 716. At 732, the UE 700 may also perform an authentication of the IdP 708. After the UE 700 is authenticated, the UE 700 may derive a public/private key pair.

[0044] In accordance with the illustrated embodiment, at 734, the UE 700 requests to obtain and/or purchase an X.509 certificate. The UE 700 requests the certificate by issuing a message, based on the PKCS #10 standard for example, to the IdP 708. At 736, the IdP 738 derives an identity for the user/UE 700 based on the provided public key and/or other means as described in Fig. 2. For example, the server 710 may communicate the public key, the derived identity of the user/UE 700, and the lifetime of the certificate to the CA 712. In accordance with the illustrated embodiment, the CA 712 issues a certificate and signs the certificate. At 738, the certificate is sent to the UE 700 via the IdP 708, for example, using PKCS #7 messaging. At 740, the IdP 708 sends a re-direct message comprising an assertion to the UE 700. The re-direct message at 740 may be sent after authentication at 732, or 740 may be performed in parallel with steps 732, and/or 734. The assertion at 740 confirms the authentication of the user/UE 700 and it may confirm that a subscription was purchased by the user, thus confirming that the credentials (e.g., the certificate) may be used to access the hotspot network 702. If the message is done in a parallel manner then confirmation of the purchase of the credentials may be omitted. In an embodiment in which the OpenID Connect protocol is implemented to authenticate the user/UE 700, it will be understood that the functions of the assertion may be implemented by an identity token and an access token. For example, the tokens may be used by the RP in the hotspot network 702 to verify the subscription and obtain the certificate.

[0045] At 742, the UE 700 is redirected to the RP in the hotspot network 702. At 744, the hotspot network 702 initiates an EAP authentication by requesting the identity of the user/UE 700. For example, an entity 706, such as the RP, may request the identity. At 746, the UE 700 sends its previously derived single sign-on temporary identity to the entity 706 of the hotspot network 702. In an alternative embodiment, the UE 700 may send its permanent identity at 746. At 748, the hotspot network 702 requests the UE 700 to use EAP-TLS authentication. For example, such a request may be negotiated as part of the EAP process. At 750, the UE 700 sends an EAP message to the hotspot network 702. The EAP message comprises a TLS client hello message with a client random value. At 752, the EAP message is forwarded to an identity provider 708. Thus, the EAP message at 722 may be sent to the AAA server 710, and the EAP message may be encapsulated in a radius message.

[0046] Still referring to the example embodiment shown in Fig. 7, at 754, the AAA server 710 sends a server hello message with a server certificate and requests a client certificate. At 756, the server hello message with its certificate and the client certificate request is forwarded to the UE 700, for example, using an EAP message. In response to the client certificate request, the UE 700 sends its certificate toward the AAA server 710 at 758. At 760, the certificate of the UE 700 is forwarded to the AAA server 710 from the hotspot network 702. At 762, the AAA server 710 derives the master session key (MSK), for example, after authenticating the certificate of the UE 700. The MSK may be derived using the pre-master key and the random values established during the TLS handshake protocol. At 764, the MSK is forwarded to the hotspot network 702 in a secure manner, for example, using an EAP Success message. In accordance with the illustrated

embodiment, at 766, the hotspot network 702 forwards the EAP Success message to the UE 700. At 768, the UE 700 derives the MSK. The UE 700 may derive the MSK in a manner similar to how the AAA server 710 derived its key at 762. At 770, the UE 700 and the AP 704 complete a handshake such as an 802.1 1 4-way handshake, for example, using the MSK. At 772, the UE 700 may acquire an internet protocol (IP) address. At 774, the UE 700 may access the internet using the secure hotspot network 702.

[0047] Fig. 8 is an example call flow for a UE 800 to authenticate with an access network (e.g., a hotspot network 802) using EAP-TTLS in order to access the internet using a secure SSID. For example, the UE 800 may use a permanent OpenlD username and associated password that was created out of band or the UE 800 may use a temporary on-demand provisioned identity and associated password.

[0048] In accordance with the illustrated embodiment shown in Fig. 8, at 814 and 816, a UE (user) 800 registers with an identity provider (IdP) 808 and receives an OpenlD Identity. The registration may be referred to as an "out-of-band" registration or as an a priori registration. During the registration, the UE 800 may be provided with an SSO identity (e.g., a username) and/or a password. In accordance with the illustrated embodiment, the UE/user 800 is provided with an OpenlD identity (e.g., username) and password. At 818, the UE 800 associates with an open service set identifier (SSID) of a hotspot network 802. In particular, at 818, the UE 800 associates with an access point (AP) 804 of the hotspot network 802. While the illustrated embodiments include hotspot networks such as the hotspot network 802, embodiments described herein may be implemented with various types of networks and various types of service providers as desired. The IdP 808 may include a server 810. The server 810 may also be referred to as an OP server 810, an authorization server 810, or an AAA server 810.

[0049] At 820, a user, via the UE 800, may attempt to connect to a website on the internet. In the illustrated example, the UE 800 attempts to connect to Google's homepage. At 822, the hotspot network 802 redirects the UE 800 to a page that may include a menu. The menu may include various options that can be selected in order to access the hotspot network 802, and thus the internet. Options may include subscription options, payment options, rate options, and the like. In accordance with the illustrated embodiment, the hotspot network 802 includes the AP 804 and various entities and functions 806 such as a relying party (RP), an AAA proxy, a Captive Portal, and an online-sign-up (OSU) function. At 824, the UE 800 selects one or more options from the menu. The selected option may correspond to a type of internet access that is purchased by the user of the UE 800. At 824, the UE 800 provides an identity such as, for example, the user's OpenlD identity (e.g., username) to an entity 806 (e.g., a service provider) on the hotspot network 802. At 826, based upon the identity, at least one of the entities and functions 806 of the hotspot network 802 determines the identity provider 808 that provided the identity (e.g., username) that is associated with the UE 806. In accordance with the illustrated example, at 826, the RP determines that the IdP 808 provided the OpenlD Identity (e.g., username) of the user/UE 800, and the RP and IdP 808 perform discovery and association. At 828 and 830, the service provider (e.g., the RP) re-directs the UE 800 to the IdP 808, which may be referred to as an OP, so that the UE 800 may authenticate with its IdP 808. At 832, the UE 800 and the IdP 808 perform authentication of the user/UE 800 based on the OpenID identity (e.g.,username) and password from 814 and 816. At 832, the UE 800 may also perform an authentication of the IdP 808. After the UE 800 is authenticated, the UE 800 may be provisioned a temporary identity and password, using components and mechanisms previously described in reference to Fig. 2 for example, and a secure tunnel may be created.

[0050] In accordance with the illustrated embodiment, at 834, the hotspot network 802 initiates an EAP authentication by requesting the identity of the user/UE 800. For example, an entity 806, such as the RP, may request the identity. At 836, the UE 800 send its previously derived single sign-on temporary identity to the entity 806 of the hotspot network 802. In an alternative embodiment, the UE 800 may send its permanent identity at 836. At 840, the hotspot network 802 requests the UE 800 to use EAP-TTLS authentication. For example, such a request may be negotiated as part of the EAP process. At 842, the UE 800 sends an EAP message to the hotspot network 802. The EAP message comprises a TLS client hello message with a client random value. At 844, the EAP message is forwarded to an identity provider 608. As illustrated, the identity provider 808 may include a server 810 which may also be referred to as an OP server 810, an authorization server 810, or an AAA server 810. In accordance with the example embodiment shown in Fig. 8, the AAA server 810 is part the mobile network operator (MNO) network. Thus, the EAP message at 822 may be sent to the AAA server 810 in the MNO network, and the EAP message may be encapsulated in a radius message.

[0051] Still referring to the example embodiment shown in Fig. 8, at 846, the AAA server 810 sends a server hello message with a server certificate. At 848, the server hello message with its certificate is forwarded to the UE 800, for example, using an EAP message. Steps 842, 844, 846, and 848 may be referred to as a TLS handshake. The UE 800 authenticates with the AAA server 810 at 850. Such authentication may be based on a challenge-response mechanism, for example, wherein the UE 800 sends its temporary identity (e.g., a username) and the password that corresponds to the identity to the identity provider 808. In an alternative embodiment, the UE 800 may send a permanent identity and the password that corresponds to the permanent identity. At 852, the AAA server 810 derives the MSK, for example, after authenticating the user's password. The MSK may be derived by using the pre-master key and the random values that were established during the TLS handshake protocol. At 854, the MSK is forwarded to the hotspot network 802 in a secure manner, for example, using an EAP Success message. In accordance with the illustrated embodiment, at 856, the hotspot network 802 forwards the EAP Success message to the UE 800. At 858, the UE 800 derives the MSK. The UE 800 may derive the MSK in a manner similar to how the AAA server 810 derived its key at 852. At 860, the UE 800 and the AP 804 complete a handshake such as an 802.1 1 4-way handshake, for example, using the MSK. At 862, the UE 800 may acquire an internet protocol (IP) address for the hotspot network 802. At 864, the UE 800 may access the internet using the secure hotspot network 802.

[0052] Fig. 9 is a flow diagram illustrating a combined provisioning and authentication call flow according to an embodiment in which a user/UE 900 accesses the internet using a secure SSID and using the Generic Bootstrapping Authentication (GBA)-based process leveraging OpenID and EAP-TTLS protocols. Referring to Fig. 9, an out-of-band registration is performed by the UE 900 bootstrapping function. In accordance with the illustrated embodiment, the user/UE performs bootstrapping and derives a network access function (NAF) key (Ks_NAF) at both UE and/or a bootstrapping server function (BSF) 910. The UE 900 uses the Ks NAF for authenticating to a hotspot network 902 and for deriving session keys (e.g., using a MSK).

[0053] In accordance with the illustrated embodiment shown in Fig. 9, at 914 and 916, the user/UE 900 registers with the identity provider (IdP) 908 and receives an OpenID Identity. The registration may be referred to as an "out-of-band" registration or as an a priori registration. During the registration, the UE 900 may be provided with an SSO identity (e.g., a username) and/or a password. In accordance with the illustrated embodiment, the UE/user 900 is provided with an OpenID identity (e.g., username) and password that corresponds to the OpenID identity. At 918, the UE 900 associates with an open service set identifier (SSID) of a hotspot network 902. In particular, at 918, the UE 900 associates with an access point (AP) 904 of the hotspot network 902. While the illustrated embodiments include hotspot networks such as the hotspot network 902, embodiments described herein may be implemented with various types of networks and various types of service providers as desired. The IdP 908 may include a server 910 and a certificate authority 912. The server 910 may also be referred to as an OP server 910, an authorization server 910, or an AAA server 910.

[0054] At 920, a user, via the UE 900, may attempt to connect to a website on the internet. In the illustrated example, the UE 900 attempts to connect to Google's homepage. At 922, the hotspot network 902 redirects the UE 900 to a page that may include a menu. The menu may include various options that can be selected in order to access the hotspot network 902, and thus the internet. Options may include subscription options, payment options, rate options, and the like. In accordance with the illustrated embodiment, the hotspot network 902 includes the AP 904 and various entities and functions 906 such as a NAF, an AAA proxy server, a Captive Portal, and an online-sign-up (OSU) function. At 924, the UE 900 selects one or more options from the menu. The selected option may correspond to a type of internet access that is purchased by the user of the UE 900. At 924, the UE 900 provides an identity such as, for example, the user's GBA SSO identity (e.g., username) to an entity 906 (e.g., the NAF) on the hotspot network 902. At 926, the UE 900 performs a bootstrapping with the BSF 910. The UE 900 and the BSF 910 mutually authenticated one another based on the trust that exists between the SIM/ISIM provided by the MNO and the BSF 910 that is located within the MNO network. As a result of the bootstrapping, a Bootstrap ID (B-TID) is derived at 932. The B-TID may be derived using similar mechanisms as described in the GBA standards or it may be derived using mechanisms described herein with reference to Fig. 2. Thus, the B-TID may be the temporary identity that may be used within a service domain. As described with reference to Fig. 2, as part of the provisioning phase, a credential (e.g., a credential, password, shared secret) may be created. In one embodiment, the domain information of the OSU 906 is used to derive a Ks NAF as the shared secret. For example, the id, such as the FQDN, of the NAF/OSU 906 is used to create the temporary credential. At 934, the UE 900 sends its temporary identity (B-TID) to the NAF 906. At 936, the NAF 906 resolves the B-TID to the appropriate BSF. At 938, the BSF sends the Ks NAF to the NAF 906. At 940, the UE 900 associates with a secure SSID.

[0055] In accordance with the illustrated embodiment, at 942, the hotspot network 902 initiates an EAP authentication by requesting the identity of the user/UE 900. For example, an entity of the hotspot network 902, such as the AP 904, may request the identity. At 944, the UE 900 sends its previously derived single sign-on temporary identity (B-TID) to the entity 904 of the hotspot network 902. In an alternative embodiment, the UE 800 may send its permanent identity at 944. At 948, the hotspot network 902 requests the UE 900 to use EAP-TTLS authentication. For example, such a request may be negotiated as part of the EAP process. At 948, the UE 900 sends an EAP message to the hotspot network 902. The EAP message comprises a TLS client hello message with a client random value. [0056] Still referring to the example embodiment shown in Fig. 9, at 950, the AAA proxy server 906 sends a server hello message with a server certificate to the UE using EAP messages. Steps 948 and 950 may be referred to as a TLS handshake. The UE 900 authenticates with the AAA proxy server 910 at 952. Such authentication may be based on a challenge-response mechanism, for example, where the UE 900 uses its temporary identity (B-TID) and the Ks NAF that corresponds to the B-TID and the identity provider 908. In an alternative embodiment, the UE 900 may send a permanent identity and the password that corresponds to the permanent identity. At 952, the AAA proxy 906 derives the MSK, for example, after authenticating the Ks NAF. The MSK may be derived by using the pre -master key and the random values that were established during the TLS handshake protocol. Alternatively, the Ks_NAF may be used as the MSK. At 954, the MSK is forwarded to the AP 904 in a secure manner, for example, using an EAP Success message. In accordance with the illustrated embodiment, at 956, the hotspot network 902 forwards the EAP Success message to the UE 900. The UE 900 derives the MSK. The UE 900 may derive the MSK in a manner similar to how the AAA proxy server 906 derived its key at 952. At 958, the UE 900 and the AP 904 complete a handshake such as an 802.11 4-way handshake, for example, using the MSK. At 960, the UE 900 may acquire an internet protocol (IP) address for the hotspot network 902. At 962, the UE 900 may access the internet using the secure hotspot network 902.

[0057] Fig. 10A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC- FDMA), and the like.

[0058] As shown in Fig. 10A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0059] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0060] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0061] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless

communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0062] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0063] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).

[0064] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0065] The base station 114b in Fig. 10A may be a wireless router, Home Node B, Home eNode B, femto cell base station, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Fig. 10A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.

[0066] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in Fig. 10A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0067] The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0068] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in Fig. 10A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0069] Fig. 10B is a system diagram of an example WTRU 102. As shown in Fig. 10B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. [0070] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While Fig. 10B depicts the processor 1 18 and the transceiver 120 as separate components, it will be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip. The processor 1 18 may perform application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or communications. The processor 1 18 may perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

[0071] In an example embodiment, the WTRU 102 comprises a processor 1 18 and memory coupled to the processor. The memory comprises executable instructions that when executed by the processor cause the processor to effectuate operations associated with provisioning credentials on- demand.

[0072] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over the air interface 1 16. For example, in an embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet an embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0073] In addition, although the transmit/receive element 122 is depicted in Fig. 10B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for

transmitting and receiving wireless signals over the air interface 1 16. [0074] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.1 1 , for example.

[0075] The processor 1 18 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), readonly memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0076] The processor 1 18 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0077] The processor 1 18 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 16 from a base station (e.g., base stations 1 14a, 1 14b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. [0078] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features,

functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0079] Fig. IOC is a system diagram of the RAN 104 and the core network 106 according to an embodiment. As noted above, the RAN 104 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106. As shown in Fig. IOC, the RAN 104 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 104. The RAN 104 may also include RNCs 142a, 142b. It will be appreciated that the RAN 104 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0080] As shown in Fig. IOC, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out and/or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0081] The core network 106 shown in Fig. IOC may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0082] The RNC 142a in the RAN 104 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0083] The RNC 142a in the RAN 104 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0084] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0085] Although features and elements are described above in particular combinations, each feature or element can be used alone or in any combination with the other features and elements. Additionally, the embodiments described herein are provided for exemplary purposes only. For example, while embodiments may be described herein using OpenID and/or SSO authentication entities and functions, similar embodiments may be implemented using other authentication entities and functions. Furthermore, the embodiments described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

What is Claimed:

1. A method comprising, by a user equipment (UE):

authenticating with an identity provider to establish an original identity;

requesting and obtaining from the identity provider a new identity and a selected one of a plurality of credentials, the selected one credential required to access a service provided by a network entity; and

authenticating with the network entity using the new identity and the selected one credential.

2. The method as recited in claim 1, wherein the new identity is a temporary identity associated with the original identity.

3. The method as recited in claim 1, wherein the new identity is a permanent identity.

4. The method as recited in claim 1 , wherein each of the credentials of the plurality of credentials are classified into different types, the types comprising a certificate, a shared secret, a password, and a token.

5. The method as recited in claim 4, wherein each of the credentials of the plurality of credentials are compatible with the service.

6. The method as recited in claim 1, wherein the selected one credential comprises at least one of a certificate, a shared secret, a password, or a token.

7. The method as recited in claim 1, wherein the network entity comprises an access point of a hotspot network.

8. The method as recited in claim 1, wherein the step of authenticating with the network entity using the new identity uses an extensible authentication protocol (EAP) with transport layer security (EAP-TLS).

9. The method as recited in claim 1, wherein the step of authenticating with the network entity using the new identity uses an extensible authentication protocol (EAP) with tunneled transport layer security (EAP-TTLS).

10. The method as recited in claim 1, wherein the step of requesting the new identity and the selected one credential comprises issuing a request message formatted according to a public key cryptography standard, the request message comprising a public key associated with the UE.

11. A wireless/transmit receive unit (WTRU), the 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:

authenticating with an identity provider to establish an original identity; requesting and obtaining from the identity provider a new identity and a selected one of a plurality of credentials, the selected one credential required to access a service provided by a network entity; and

12. The WTRU as recited in claim 11 , wherein the new identity is a temporary identity associated with the original identity.

13. The WTRU as recited in claim 11, wherein the new identity is a permanent identity.

14. The WTRU as recited in claim 11, wherein each of the credentials of the plurality of credentials are classified into different types, the types comprising a certificate, a shared secret, a password, and a token.

15. The WTRU as recited in claim 14, wherein each of the credentials of the plurality of credentials are compatible with the service.

16. The WTRU as recited in claim 11, wherein the selected one credential comprises at least one of a certificate, a shared secret, a password, or a token.

17. The WTRU as recited in claim 1 1, wherein the network entity comprises an access point of a hotspot network.

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

using an extensible authentication protocol (EAP) with transport layer security (EAP-TLS) to authenticate the network entity using the new identity.

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

using an extensible authentication protocol (EAP) with tunneled transport layer security (EAP-TTLS) to authenticate the network entity using the new identity.

20. The method as recited in claim 11 , wherein the operation of requesting the new identity and the selected one credential comprises issuing a request message formatted according to a public key cryptography standard, the request message comprising a public key associated with the UE.