OpenID Connect - Part 6: String operations, Security & Privacy Consideration

Abstract

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

This specification only defines the endpoints, associated messages, and message exchange sequences. These are used in protocol bindings such as OpenID Connect Standard 1.0, which is a binding of these messages to OAuth 2.0. Actual use requires also using a companion protocol binding specification, such as OpenID Connect Standard 1.0.

Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
2.  Terminology
3.  Client Authentication
4.  Signatures and Encryption
    4.1.  Supported Algorithms
    4.2.  Keys
    4.3.  Signing
    4.4.  Encryption
5.  Validation
    5.1.  Authorization Request Validation
6.  String Operations
7.  Serializations
    7.1.  Query String Serialization
    7.2.  Form Serialization
    7.3.  JSON Serialization
8.  Security Considerations
    8.1.  TLS Version
    8.2.  Request Disclosure
    8.3.  Server Masquerading
    8.4.  Token Manufacture/Modification
    8.5.  Server Response Disclosure
    8.6.  Server Response Repudiation
    8.7.  Request Repudiation
    8.8.  Access Token Redirect
    8.9.  Token Reuse
    8.10.  Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)
    8.11.  Token Substitution
    8.12.  Timing Attack
    8.13.  Other Crypto Related Attacks
    8.14.  Signing and Encryption Order
    8.15.  Issuer Identifier
    8.16.  TLS Requirements
    8.17.  Lifetimes of Access Tokens and Refresh Tokens
    8.18.  Symmetric Key Entropy
    8.19.  Need for Signed Requests
    8.20.  Need for Encrypted Requests
9.  Privacy Considerations
    9.1.  Personally Identifiable Information
    9.2.  Data Access Monitoring
    9.3.  Correlation
    9.4.  Offline Access
10.  IANA Considerations
11.  Implementation Considerations
    11.1.  Mandatory to Implement Features for All OpenID Providers
    11.2.  Mandatory to Implement Features for Dynamic OpenID Providers
    11.3.  Related Specifications
12.  References
    12.1.  Normative References
    12.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Notices
§  Authors' Addresses

1.  Introduction

The OpenID Connect Messages 1.0 specification defines endpoints, associated messages, and message sequences that can be used to build an actual OpenID Connect identity protocol. OpenID Connect Standard 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” July 2013.) [OpenID.Standard] is such a protocol. It binds the OAuth 2.0 code and implicit flows to the elements defined by this specification to define an interoperable identity protocol over HTTPS. Similarly, one could use this specification to write bindings to other protocols such as IMAP or XMPP.

1.1.  Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.

All uses of JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2013.) [JWS] and JSON Web Encryption (JWE) (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2013.) [JWE] data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used.

2.  Terminology

This specification strives to make itself readable without constantly refering to the term definitions. Defined terms are shown with its first letters capitalized. When in doubt, refer to OpenID Connect Messages 1.0 for the authoritative defintion of the defined terms.

3.  Client Authentication

During Client Registration, the RP (Client) MAY register an authentication method. If no method is registered, the default method of client_secret_basic MUST be used.

The Supported options are:

client_secret_basic

Clients that have received a client_secret value from the Authorization Server, authenticate with the Authorization Server in accordance with Section 3.2.1 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] using HTTP Basic authentication scheme.

client_secret_post

Clients that have received a client_secret value from the Authorization Server, authenticate with the Authorization Server in accordance with Section 3.2.1 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] by including the Client Credentials in the request body.

client_secret_jwt

Clients that have received a client_secret value from the Authorization Server create a JWT using an HMAC SHA algorithm, such as HMAC SHA-256. The HMAC (Hash-based Message Authentication Code) is calculated using the octets of the UTF-8 representation of the client_secret as the shared key.

The Client authenticates in accordance with Section 2.2 of OAuth JWT Bearer Token Profiles (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” March 2013.) [OAuth.JWT] and OAuth 2.0 Assertion Profile (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” March 2013.) [OAuth.Assertions]. The JWT MUST contain the following REQUIRED Claim Values and MAY contain the following OPTIONAL Claim Values:

iss

REQUIRED. Issuer. This MUST contain the client_id of the OAuth Client.

sub

REQUIRED. Subject. This MUST contain the client_id of the OAuth Client.

aud

REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

jti

REQUIRED. JWT ID. A unique identifier for the token. The JWT ID MAY be used by implementations requiring message de-duplication for one-time use assertions.

exp

REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing.

iat

OPTIONAL. Time at which the JWT was issued.

ID Tokens MAY contain other Claims. Any Claims used that are not understood MUST be ignored.

The authentication token MUST be sent as the value of the [OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” March 2013.) client_assertion parameter.

The value of the [OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” March 2013.) client_assertion_type parameter MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer", per [OAuth.JWT] (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” March 2013.).

private_key_jwt

Clients that have registered a public key sign a JWT using that key. The Client authenticates in accordance with Section 2.2 of OAuth JWT Bearer Token Profiles (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” March 2013.) [OAuth.JWT] and OAuth 2.0 Assertion Profile (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” March 2013.) [OAuth.Assertions]. The JWT MUST contain the following REQUIRED Claim Values and MAY contain the following OPTIONAL Claim Values:

iss

REQUIRED. Issuer. This MUST contain the client_id of the OAuth Client.

sub

REQUIRED. Subject. This MUST contain the client_id of the OAuth Client.

aud

REQUIRED. Audience. The aud (audience) Claim. Value that identifies the Authorization Server as an intended audience. The Authorization Server MUST verify that it is an intended audience for the token. The Audience SHOULD be the URL of the Authorization Server's Token Endpoint.

jti

REQUIRED. JWT ID. A unique identifier for the token. The JWT ID MAY be used by implementations requiring message de-duplication for one-time use assertions.

exp

REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing.

iat

OPTIONAL. Time at which the JWT was issued.

The JWT MAY contain other Claims. Any Claims used that are not understood MUST be ignored.

The authentication token MUST be sent as the value of the [OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” March 2013.) client_assertion parameter.

The value of the [OAuth.Assertions] (Campbell, B., Mortimore, C., Jones, M., and Y. Goland, “Assertion Framework for OAuth 2.0,” March 2013.) client_assertion_type parameter MUST be "urn:ietf:params:oauth:client-assertion-type:jwt-bearer", per [OAuth.JWT] (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” March 2013.).

For example (with line wraps within values for display purposes only):

  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  grant_type=authorization_code&
    code=i1WsRn1uB1&
    client_id=s6BhdRkqt3&
    client_assertion_type=
    urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
    client_assertion=PHNhbWxwOl ... ZT

4.  Signatures and Encryption

Depending on the transport through which the messages are sent, the integrity of the message might not be guaranteed and the originator of the message might not be authenticated. To mitigate these risks, Request Object, Token Request, ID Token, and UserInfo Response values MAY utilize JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2013.) [JWS] to sign the contents.

To achieve message confidentiality, Request Object, Token Request, ID Token, and UserInfo Response values MAY use JSON Web Encryption (JWE) (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2013.) [JWE] to encrypt the content.

When the message is both signed and encrypted, it MUST be signed first and then encrypted, per Section 8.14 (Signing and Encryption Order), with nesting performed in the same manner as specified for JWTs [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.). Note that all JWE encryption methods perform integrity checking.

4.1.  Supported Algorithms

The server advertises its supported signing and encryption algorithms in its discovery document. The algorithm identifiers are specified in JWA (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) [JWA]. The related elements are:

userinfo_signing_alg_values_supported

JSON array containing a list of the JWS [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2013.) signing algorithms (alg values) [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.).

userinfo_encryption_alg_values_supported

JSON array containing a list of the JWE [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2013.) encryption algorithms (alg values) [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.).

userinfo_encryption_enc_values_supported

JSON array containing a list of the JWE encryption algorithms (enc values) [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.).

id_token_signing_alg_values_supported

JSON array containing a list of the JWS signing algorithms (alg values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.).

id_token_encryption_alg_values_supported

JSON array containing a list of the JWE encryption algorithms (alg values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.).

id_token_encryption_enc_values_supported

JSON array containing a list of the JWE encryption algorithms (enc values) supported by the Authorization Server for the ID Token to encode the Claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.).

request_object_signing_alg_values_supported

JSON array containing a list of the JWS signing algorithms (alg values) supported by the Authorization Server for Request Object values. Servers SHOULD support none and RS256.

request_object_encryption_alg_values_supported

JSON array containing a list of the JWE encryption algorithms (alg values) supported by the Authorization Server for Request Object values.

request_object_encryption_enc_values_supported

JSON array containing a list of the JWE encryption algorithms (enc values) supported by the Authorization Server for Request Object values.

token_endpoint_auth_signing_alg_values_supported

JSON array containing a list of the JWS signing algorithms (alg values) supported by the Token Endpoint for the private_key_jwt and client_secret_jwt methods to encode the JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.). Servers SHOULD support RS256.

The Client registers its REQUIRED algorithms for Signing and Encryption using the following Registration parameters:

request_object_signing_alg

OPTIONAL. JWS signature algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) REQUIRED for Request Objects by the Authorization Server. All Request Objects from this client_id MUST be rejected if not signed by this algorithm. Servers SHOULD support RS256.

userinfo_signed_response_alg

OPTIONAL. JWS signature algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) REQUIRED for UserInfo Responses. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.) [JWT] serialized.

userinfo_encrypted_response_alg

OPTIONAL. JWE alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) REQUIRED for UserInfo Responses. If this is requested in combination with signing, the response MUST be signed first then encrypted, per Section 8.14 (Signing and Encryption Order). If this is specified, the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.) [JWT] serialized.

userinfo_encrypted_response_enc

OPTIONAL. JWE enc algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) REQUIRED for UserInfo Responses. If userinfo_encrypted_response_alg is specified the default for this value is A128CBC-HS256.

id_token_signed_response_alg

OPTIONAL. JWS signature algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) REQUIRED for ID Tokens issued to this client_id. The default if not specified is RS256. The public key for validating the signature is provided by retrieving the JWK Set referenced by the jwks_uri element from Discovery.

id_token_encrypted_response_alg

OPTIONAL. JWE alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) REQUIRED for ID Tokens issued to this client_id. If this is requested, the response MUST be signed then encrypted. The default if not specified is no encryption.

id_token_encrypted_response_enc

OPTIONAL. JWE enc algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) REQUIRED for ID Tokens issued to this client_id. If id_token_encrypted_response_alg is specified the default for this value is A128CBC-HS256.

4.2.  Keys

The OpenID Provider provides its public keys during Discovery using the following element:

jwks_uri

REQUIRED. URL of the OP's JSON Web Key Set [JWK] (Jones, M., “JSON Web Key (JWK),” May 2013.) document. This contains the signing key(s) the Client uses to validate signatures from the OP. The JWK Set MAY also contain the Server's encryption key(s), which are used by Clients to encrypt requests to the Server. When both signing and encryption keys are made available, a use (Key Use) parameter value is REQUIRED for all keys in the document to indicate each key's intended usage.

Likewise, the Client can provide its public keys during Registration using the following element:

jwks_uri

OPTIONAL. URL for the Client's JSON Web Key Set [JWK] (Jones, M., “JSON Web Key (JWK),” May 2013.) document. If the Client signs requests to the Server, it contains the signing key(s) the Server uses to validate signatures from the Client. The JWK Set MAY also contain the Client's encryption keys(s), which are used by the Server to encrypt responses to the Client. When both signing and encryption keys are made available, a use (Key Use) parameter value is REQUIRED for all keys in the document to indicate each key's intended usage.

When both signing and encryption keys are made available, the use (Key Use) parameter value is REQUIRED for all keys in the JWK Set at the jwks_uri to indicate each key's intended usage. Although some algorithms allow the same key pair to be used for both signatures and encryption, doing so is NOT RECOMMENDED, as it is less secure.

In both cases, the JWK x5c parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate.

4.3.  Signing

The signing party MUST select a signature algorithm based on the supported algorithms of the recipient in Section 4.1 (Supported Algorithms).

Asymmetric Signatures

When using RSA or ECDSA Signatures, the alg Claim of the JWS header MUST be set to the appropriate algorithm as defined in JSON Web Algorithms (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) [JWA]. The private key MUST be the one associated with the Public Signing Key provided in Section 4.2 (Keys). If there are multiple keys in the referenced JWK document, a kid value MUST be provided in the JWS header. The key usage of the respective keys MUST support signature.

Symmetric Signatures

When using MAC-based signatures, the alg Claim of the JWS header MUST be set to a MAC algorithm, as defined in JSON Web Algorithms (Jones, M., “JSON Web Algorithms (JWA),” May 2013.) [JWA]. The MAC key used is the octets of the UTF-8 representation of the client_secret value. See Section 8.18 (Symmetric Key Entropy) for a discussion of entropy requirements for client_secret values. Symmetric signatures MUST never be used by public (non-confidential) Clients because of their inability to keep secrets.

See Section 8.19 (Need for Signed Requests) for Security Considerations about the need for signed requests.

4.3.1.  Rotation of Asymmetric Signing Keys

Rotation of signing keys can be accomplished with the following approach. The signer publishes its keys in a JWK Set at the jwks_uri location and includes the kid of the signing key in the JWS header of each message to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over by periodically adding new keys to the JWK Set at jwks_uri. The signer can begin using a new key at its discretion and signals the change to the verifier using the kid value. The verifier knows to go back to the jwks_uri to re-retrieve the keys when it sees an unfamiliar kid value. The JWK Set document at the jwks_uri SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.

4.4.  Encryption

The encrypting party MUST select an encryption algorithm based on the supported algorithms of the recipient in Section 4.1 (Supported Algorithms). All JWTs MUST be signed before encryption to enable verification of the Issuer.

Asymmetric Encryption: RSA

Use the link registered/discovered in Section 4.2 (Keys) to retrieve the relevant key. If there are multiple keys in the referenced JWK document, a kid value MUST be provided in the JWE header. Use the supported RSA key wrapping algorithm to wrap a random Content Master Key to be used for encrypting the signed JWT. The key usage of the respective keys MUST include encryption.

Asymmetric Encryption: Elliptic Curve

Create an ephemeral Elliptic Curve public key for the epk element of the JWE header. Use the link registered/discovered in Section 4.2 (Keys) to retrieve the relevant key. If there are multiple keys in the referenced JWK document, a kid value MUST be provided in the JWE header. Use the ECDH-ES algorithm to wrap a random Content Master Key to be used for encrypting the signed JWT. The key usage of the respective keys MUST support encryption.

Symmetric Encryption

The symmetric encryption key is derived from the client_secret value by using a left truncated SHA-256 hash of the octets of the UTF-8 representation of the client_secret. The SHA-256 value MUST be left truncated to the appropriate bit length for the AES key wrapping algorithm used, for instance, to 128 bits for A128KW. If a key wrapping key with greater than 256 bits is needed, a different method of deriving the key from the client_secret would have to be defined by an extension. Symmetric encryption MUST never be used by public (non-confidential) Clients because of their inability to keep secrets.

See Section 8.20 (Need for Encrypted Requests) for Security Considerations about the need for encrypted requests.

4.4.1.  Rotation of Asymmetric Encryption Keys

Rotating encryption keys is necessarily a different process than for signing keys because the encrypting party starts the process and thus cannot rely on a change in kid as a signal to know that keys need to change. The encrypting party still uses the kid header in the JWE to tell the decrypting party which private key to use to decrypt, however, the encrypting party needs to first select the most appropriate key from those provided in the JWK Set at jwks_uri. To rotate keys, the decrypting party can publish new keys at jwks_uri and remove from the JWK Set those that are being decommissioned. The jwks_uri SHOULD include a Cache-Control header in the response that contains a max-age directive, as defined in RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616], which allows the encrypting party to safely cache the JWK Set and not have to re-retrieve the document for every encryption event. The decrypting party SHOULD remove decommissioned keys from the JWK Set at jwks_uri but retain them internally for some reasonable period of time, coordinated with the cache duration, to facilitate a smooth transition between keys by allowing the encrypting party some time to obtain the new keys. The cache duration SHOULD also be coordinated with the issuance of new signing keys as described in Section 4.3.1 (Rotation of Asymmetric Signing Keys).

5.  Validation

If any of the validation procedures defined in this specification fail, any operations requiring the information that failed to correctly validate MUST be aborted and the information that failed to validate MUST NOT be used.

5.1.  Authorization Request Validation

Authorization Request Validation consists of two main steps: (1) decryption and signature validation of the value of request or the content of request_uri, and (2) parameter validation. If a Request Object value was sent in the request parameter or by reference in the request_uri parameter, the Request Object MUST validate as JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2013.) [JWS] or JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2013.) [JWE] encoded objects, for which nested encryption and signing can be utilized in the manner described in the JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.) [JWT] specification.

5.1.1.  Encrypted Request Object

If the Authorization Server has advertised JWE encryption algorithms in the request_object_encryption_alg_values_supported and request_object_encryption_enc_values_supported elements of its Discovery Document, these are used by the Client to encrypt the JWT.

The Authorization Server MUST decode the JWT in accordance with the JSON Web Encryption (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” May 2013.) [JWE] specification. The result MAY be either a signed or unsigned (plaintext) Request Object. In the former case, signature validation MUST be performed as defined in Section 5.1.2 (Signed Request Object).

The Authorization Server MUST return the error if there is a decryption error.

5.1.2.  Signed Request Object

To perform Signature Validation, the alg parameter in the JWS header MUST match the value of the request_object_signing_alg set during Client Registration (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” July 2013.) [OpenID.Registration] or a value that was pre-registered by other means.

The signature MUST be validated against the key registered for that client_id and algorithm, in accordance with the JSON Web Signature (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2013.) [JWS] specification.

The Authorization Server MUST return the Authorization Error Response if there is a signature validation error.

5.1.3.  Parameter Validation

The Authorization Server MUST construct the Authorization Request Message from the Request Object value and the OAuth 2.0 Authorization Request parameters. If the same parameter exists both in the Request Object and the OAuth Authorization Request parameters, the parameter in the Request Object is used. Using this Authorization Request Message, the Authorization Server performs the following steps of the request validation:

1. The Authorization Server MUST validate all the OAuth 2.0 parameters according to the OAuth 2.0 specification.
2. The Authorization Server MUST verify that all the REQUIRED parameters are present.
3. If the sub (subject) Claim as a member of id_token element is requested with a specific value, the Authorization Server MUST only send a positive response if that user has an active session with the Authorization Server. The Authorization Server MUST NOT reply with an ID Token or Access Token for a different user, even if they have an active session with the Authorization Server.
4. If the acr Claim is requested as an Essential Claim for the ID Token with a values parameter requesting specific Authentication Context Class Reference values, then the Authorization Server MUST return an acr Claim Value that matches one of the requested values. The Authorization Server MAY ask the End-User to re-authenticate with additional factors to meet this requirement. If this is an Essential Claim and the requirement cannot be met, then the Authorization Server MUST treat that outcome as a failed authentication attempt.
5. The Client MAY request this Claim as a Voluntary Claim by using the acr_values request parameter or by not including "essential": true in the individual acr Claim request. If the Claim is not Essential and the requested value cannot be provided, the Authorization Server SHOULD return the session's current acr as the value of the acr Claim. If the Claim is not Essential, the Authorization Server is not required to provide this Claim in its response.

If the Authorization Server encounters any error, it MUST return the error response.

6.  String Operations

Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the Claim Names returned by the UserInfo Endpoint might be compared to specific Claim Names such as sub. Comparing Unicode strings, however, has significant security implications.

Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:

1. Remove any JSON applied escaping to produce an array of Unicode code points.
2. Unicode Normalization (Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.) [USA15] MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against.
3. Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison.

In several places, this specification uses space delimited lists of strings. In all such cases, only the ASCII space character (0x20) MAY be used for this purpose.

7.  Serializations

Messages are serialized using one of the following methods:

1. Query String Serialization
2. Form Serialization
3. JSON Serialization

Not all methods can be used for all messages.

7.1.  Query String Serialization

In order to serialize the parameters using the Query String Serialization, the Client constructs the string by adding the parameters and values to the query component of a URL using the application/x-www-form-urlencoded format as defined by [W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.). Query String Serialization is typically used in HTTP GET requests. The same serialization method is also used when adding parameters to the fragment component of a URL.

Following is a non-normative example of this serialization (with line wraps within values for display purposes only):

  GET /authorize?scope=openid&response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com

7.2.  Form Serialization

Parameters and their values are Form Serialized by adding the parameter names and values to the entity body of the HTTP request using the application/x-www-form-urlencoded format as defined by [W3C.REC‑html401‑19991224] (Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” December 1999.). Form Serialization is typically used in HTTP POST requests.

Following is a non-normative example of this serialization (with line wraps within values for display purposes only):

  POST /authorize HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencoded

  scope=openid&response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

7.3.  JSON Serialization

The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. Each parameter MAY have a JSON structure as its value.

Following is a non-normative example of this serialization:

  {
   "access_token":"SlAV32hkKG",
   "expires_in":3600,
   "refresh_token":"8xLOxBtZp8"
  }

8.  Security Considerations

OAuth 2.0 Threat Model and Security Considerations (Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.) [RFC6819] provides an extensive list of threats and controls that applies to this standard as well. ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013 -- Information technology - Security techniques - Entity authentication assurance framework,” March 2013.) [ISO29115] also provides threats and controls that implementers need to take into account. In addition, this standard provides additional control measures listed below.

8.1.  TLS Version

Whenever Transport Layer Security (TLS) is used by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) is the most recent version, but has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) is the most widely deployed version and will provide the broadest interoperability.

8.2.  Request Disclosure

If appropriate measures are not taken, a request might be disclosed to an attacker, posing security and privacy threats.

In addition to what is stated in Section 5.1.1 of [RFC6819] (Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.), this standard provides a way to provide the confidentiality of the request end to end through the use of request or request_uri parameters, where the content of the request is an encrypted JWT with the appropriate key and cipher. This protects even against a compromised User-Agent in the case of indirect request.

8.3.  Server Masquerading

A malicious Server might masquerade as the legitimate server using various means. To detect such an attack, the Client needs to authenticate the server.

In addition to what is stated in Section 5.1.2 of [RFC6819] (Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.), this standard provides a way to authenticate the Server through either the use of Signed or Encrypted JWTs with an appropriate key and cipher.

8.4.  Token Manufacture/Modification

An Attacker might generate a bogus token or modify the token content (such as the authentication or attribute statements) of an existing parseable token, causing the RP to grant inappropriate access to the Client. For example, an Attacker might modify the parseable token to extend the validity period; a Client might modify the parseable token to have access to information that they should not be able to view.

There are two ways to mitigate this attack:

1. The token can be digitally signed by the OP. The Relying Party SHOULD validate the digital signature to verify that it was issued by a legitimate OP.
2. The token can be sent over a protected channel such as TLS. See Section 8.16 (TLS Requirements) for more information on using TLS. In this specification, the token is always sent over a TLS protected channel. Note however, that this measure is only a defense against third party attackers and is not applicable to the case where the Client is the attacker.

8.5.  Server Response Disclosure

The server response might contain authentication and attribute statements that include sensitive Client information. Disclosure of the response contents can make the Client vulnerable to other types of attacks.

The server response disclosure can be mitigated in the following two ways:

1. Using the code response type. The response is sent over a TLS protected channel, where the Client is authenticated by the client_id and client_secret.
2. For other response types, the signed response can be encrypted with the Client's public key or a shared secret as an encrypted JWT with an appropriate key and cipher.

8.6.  Server Response Repudiation

A response might be repudiated by the server if the proper mechanisms are not in place. For example, if a Server does not digitally sign a response, the Server can claim that it was not generated through the services of the Server.

To mitigate this threat, the response MAY be digitally signed by the Server using a key that supports non-repudiation. The Client SHOULD validate the digital signature to verify that it was issued by a legitimate Server and its integrity is intact.

8.7.  Request Repudiation

Since it is possible for a compromised or malicious Client to send a request to the wrong party, a Client that was authenticated using only a bearer token can repudiate any transaction.

To mitigate this threat, the Server MAY require that the request be digitally signed by the Client using a key that supports non-repudiation. The Server SHOULD validate the digital signature to verify that it was issued by a legitimate Client and the integrity is intact.

8.8.  Access Token Redirect

An Attacker uses the Access Token generated for one resource to obtain access to a second resource.

To mitigate this threat, the Access Token SHOULD be audience and scope restricted. One way of implementing it is to include the identifier of the resource for whom it was generated as audience. The resource verifies that incoming tokens include its identifier as the audience of the token.

8.9.  Token Reuse

An Attacker attempts to use a one-time use token such as an Authorization Code that has already been used once with the intended Resource. To mitigate this threat, the token SHOULD include a timestamp and a short validity lifetime. The Relying Party then checks the timestamp and lifetime values to ensure that the token is currently valid.

Alternatively, the server MAY record the state of the use of the token and check the status for each request.

8.10.  Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture)

In addition to the attack patterns described in Section 4.4.1.1 of [RFC6819] (Lodderstedt, T., McGloin, M., and P. Hunt, “OAuth 2.0 Threat Model and Security Considerations,” January 2013.), an Authorization Code can be captured in the User-Agent where the TLS session is terminated if the User-Agent is infected by malware. However, capturing it is not useful as long as the profile uses either Client authentication or an encrypted response.

8.11.  Token Substitution

Token Substitution is a class of attacks in which a malicious user swaps various tokens, including swapping an Authorization Code for a legitimate user with another token that the attacker has. One means of accomplishing this is for the attacker to copy a token out one session and use it in an HTTP message for a different session, which is easy to do when the token is available to the browser; this is known as the "cut and paste" attack.

The implicit flow of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] is not designed to mitigate this risk. In Section 10.16, it normatively requires that any use of the authorization process as a form of delegated End-User authentication to the Client MUST NOT use the implicit flow without employing additional security mechanisms that enable the Client to determine whether the Access Token was issued for its use.

In OpenID Connect, this is mitigated through mechanisms provided through the ID Token. The ID Token is a signed security token that provides Claims such as iss (issuer), sub (subject), aud (audience), azp (authorized party), at_hash (access token hash), and c_hash (code hash). Using the ID Token, the Client is capable of detecting the Token Substitution Attack.

The c_hash in the ID Token enables Clients to prevent code substitution.

Also, a malicious user may attempt to impersonate a more privileged user by subverting the communication channel between the Authorization Endpoint and Client, or the Token Endpoint and Client, for example by swapping the code or reordering the messages, to convince the Token Endpoint that the attacker's authorization grant corresponds to a grant sent on behalf of a more privileged user.

For HTTP bindings such as OpenID Connect Standard 1.0, the responses to Token Requests are bound to the corresponding requests by message order in HTTP, as both the response containing the token and requests are protected by TLS, which will detect and prevent packet reordering.

When designing another binding of OpenID Connect Messages to a protocol incapable of strongly binding Token Endpoint requests to responses, additional mechanisms to address this issue MUST be utilized. One such mechanism could be to include an ID Token with a c_hash Claim in the token request and response.

8.12.  Timing Attack

A timing attack allows the attacker to obtain an unnecessary large amount of information through the elapsed time differences in the code paths taken by successful and unsuccessful decryption operations or successful and unsuccessful signature validation of a message. It can be used to reduce the effective key length of the cipher used.

Implementations SHOULD NOT terminate the validation process at the instant of the finding an error but SHOULD continue running until all the octets have been processed to avoid this attack.

8.13.  Other Crypto Related Attacks

There are various crypto related attacks possible depending on the method used for encryption and signature / integrity checking. Implementers need to consult the Security Considerations for the JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2013.) [JWT] specification and specifications that it references to avoid the vulnerabilities identified in these specifications.

8.14.  Signing and Encryption Order

Signatures over encrypted text are not considered valid in many jurisdictions. Therefore, for integrity and non-repudiation, this specification requires signing the plain text JSON Claims.

8.15.  Issuer Identifier

OpenID Connect supports multiple issuers per Host and Port combination. The issuer returned by discovery MUST exactly match the value of iss in the ID Token.

OpenID Connect treats the path component of any URI as part of the user identifier. For instance, the subject "1234" with an issuer of "https://example.com" is not equivalent to the subject "1234" with an issuer of "https://example.com/sales".

It is RECOMMENDED that only a single issuer per host be used.

8.16.  TLS Requirements

Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) is the most widely deployed version, and will give the broadest interoperability.

To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

Whenever TLS is used, a TLS server certificate check MUST be performed, per RFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125].

8.17.  Lifetimes of Access Tokens and Refresh Tokens

Access Token grants are not revocable by the Authorization Server. Access Token grant lifetimes SHOULD be kept to single use or very short lifetimes.

If access to the UserInfo Endpoint or other protected resources is required, a Refresh Token SHOULD be used. The Client MAY then exchange the Refresh Token at the Token Endpoint for a fresh short-lived Access Token that can be used to access the resource.

The Authorization Server SHOULD clearly identify long-term grants to the User during Authorization. The Authorization Server SHOULD provide a mechanism for the End-User to revoke Refresh Tokens granted to a Client.

8.18.  Symmetric Key Entropy

In Section 4.3 (Signing) and Section 4.4 (Encryption), keys are derived from the client_secret value. Thus, when used with symmetric signing or encryption operations, client_secret values MUST contain sufficient entropy to generate cryptographically strong keys. Also, client_secret values MUST also contain at least the minimum of number of octets required for MAC keys for the particular algorithm used. So for instance, for HS256, the client_secret value MUST contain at least 8 octets (and almost certainly SHOULD contain more, since client_secret values are likely to use a restricted alphabet.

8.19.  Need for Signed Requests

In some situations, Clients might need to use signed requests to ensure that the desired request parameters are delivered to the OP without having been tampered with. For instance, the max_age and acr_values provide more assurance about the nature of the authentication performed when delivered in signed requests.

8.20.  Need for Encrypted Requests

In some situations, knowing the contents of an OpenID Connect request can, in and of itself, reveal sensitive information about the End-User. For instance, knowing that the Client is requesting a particular Claim or that it is requesting that a particular authentication method be used can reveal sensitive information about the End-User. OpenID Connect enables requests to be encrypted to the OpenID Provider to prevent such potentially sensitive information from being revealed.

9.  Privacy Considerations

9.1.  Personally Identifiable Information

The UserInfo Response typically contains Personally Identifiable Information (PII). As such, End-User consent for the release of the information for the specified purpose SHOULD be obtained at or prior to the authorization time in accordance with relevant regulations. The purpose of use is typically registered in association with the redirect_uris.

Only necessary UserInfo data should be stored at the Client and the Client SHOULD associate the received data with the purpose of use statement.

9.2.  Data Access Monitoring

The Resource Server SHOULD make the UserInfo access log available to the End-User so that the End-User can monitor who accessed his data.

9.3.  Correlation

To protect the End-User from a possible correlation among Clients, the use of a Pairwise Pseudonymous Identifier (PPID) as the sub (subject) SHOULD be considered.

9.4.  Offline Access

Offline access enables access to Claims when the user is not present, posing greater privacy risk than the Claims transfer when the user is present. Therefore, it is prudent to obtain explicit consent for offline access to resources. This specification mandates the use of the prompt parameter to obtain consent unless it is a priori known that the request complies with the conditions for processing in each jurisdiction.

When an Access Token is returned in the front channel, there is a greater risk of it being exposed to an attacker, who could later use it to access the UserInfo endpoint. If the Access Token does not enable offline access and the server can differentiate whether the Client request has been made offline or online, the risk will be substantially reduced. Therefore, this specification mandates ignoring the offline access request when the Access Token is transmitted in the front channel. Note that differentiating between online and offline access from the server can be difficult especially for native clients. The server may well have to rely on heuristics. Also, the risk of exposure for the Access Token delivered in the front channel for the response types of code token and token is the same. Thus, the implementations should be prepared to detect the channel from which the Access Token was issued and deny offline access if the token was issued in the front channel.

Note that although these provisions require an explicit consent dialogue through the prompt parameter, the mere fact that the user pressed an "accept" button etc., might not constitute a valid consent. Developers should be aware that for the act of consent to be valid, typically, the impact of the terms have to be understood by the End-User, the consent must be freely given and not forced (i.e., other options have to be available), and the terms must fair and equitable. In general, it is advisable for the service to follow the required privacy principles in each jurisdiction and rely on other conditions of processing than simply explicit consent, as online self-service "explicit consent" often does not form a valid consent in some jurisdictions.

10.  IANA Considerations

This specification makes no request to IANA registry.

11.  Implementation Considerations

This specification defines features used by both Relying Parties and OpenID Providers. Features that are mandatory to implement for Relying Parties are already described in the OpenID Connect Basic Client Profile 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” July 2013.) [OpenID.Basic] and OpenID Connect Implicit Client Profile 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” July 2013.) [OpenID.Implicit] specifications, and so are not discussed again here.

It is expected that some OpenID Providers will require static, out-of-band configuration of RPs using them, whereas others will support dynamic usage by RPs without a pre-established relationship between them. For that reason, the mandatory-to-implement features for OPs are listed below in two groups: the first for all OPs and the second for "Dynamic" OpenID Providers.

11.1.  Mandatory to Implement Features for All OpenID Providers

All OpenID Providers MUST implement the following features defined in this specification. This list augments the set of features that are already listed elsewhere as being "REQUIRED" or are described with a "MUST", and so is not, by itself, a comprehensive set of implementation requirements for OPs.

Signing ID Tokens with RSA SHA-256

OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an alg value of RS256).

Prompt Parameter

OPs MUST support the prompt parameter, as defined in [OpenID.Core] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 1: Authentication Core,” July 2013.), including the specified user interface behaviors such as none and login.

Display Parameter

OPs MUST support the display parameter, as defined in [OpenID.Core] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 1: Authentication Core,” July 2013.). (Note that the minimum level of support required for this parameter is simply to have its use not result in an error.)

Preferred Locales

OPs MUST support requests for preferred languages and scripts for the user interface and for Claims via the ui_locales and claims_locales request parameters, as defined in [OpenID.Core] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 1: Authentication Core,” July 2013.). (Note that the minimum level of support required for these parameters is simply to have their use not result in errors.)

Authentication Time

OPs MUST support returning the time at which the End-User authenticated via the auth_time Claim, as defined in [OpenID.Core] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 1: Authentication Core,” July 2013.).

Maximum Authentication Age

OPs MUST support enforcing a maximum authentication age via the max_age parameter, as defined in [OpenID.Core] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 1: Authentication Core,” July 2013.).

Authentication Context Class Reference

OPs MUST support requests for specific Authentication Context Class Reference values via the acr_values parameter, as defined in [OpenID.Core] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 1: Authentication Core,” July 2013.). (Note that the minimum level of support required for this parameter is simply to have its use not result in an error.)

11.2.  Mandatory to Implement Features for Dynamic OpenID Providers

In addition to the features listed above, OpenID Providers supporting dynamic establishment of relationships with RPs that they do not have a pre-configured relationship with MUST also implement the following features defined in this and related specifications.

Discovery

These OPs MUST support Discovery, as defined in OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect - Part 7: Discovery,” July 2013.) [OpenID.Discovery].

Dynamic Registration

These OPs MUST support Dynamic Client Registration, as defined in OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” July 2013.) [OpenID.Registration].

UserInfo Endpoint

All dynamic OPs that issue Access Tokens MUST support the UserInfo Endpoint, as defined in [OpenID.Claims] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 3: Claims Framework,” September 2013.). (Self-Issued OPs do not issue Access Tokens.)

Public Keys Published as Bare Keys

These OPs MUST publish their public keys as bare keys, rather than in X.509 format.

Request URI

These OPs MUST support requests made using a Request Object value that is retrieved from a Request URI that is provided with the request_uri parameter, as defined in [OpenID.JSON] (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect - Part 4: JSON Based Requests,” September 2013.).

11.3.  Related Specifications

This specification is an abstract specification. It needs to be bound to a protocol to be used in practice. One such example of protocol binding is:

• OpenID Connect Standard 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Standard 1.0,” July 2013.) [OpenID.Standard] - Protocol binding for the full set of OpenID Connect messages

These related OpenID Connect specifications MAY OPTIONALLY be used in combination with this specification to provide additional functionality:

• OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect - Part 7: Discovery,” July 2013.) [OpenID.Discovery] - Dynamic discovery for user and Authorization Server endpoints and information
• OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” July 2013.) [OpenID.Registration] - Dynamic registration of OpenID Connect Clients with OpenID Providers
• OpenID Connect Basic Client Profile 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Profile 1.0,” July 2013.) [OpenID.Basic] - Protocol binding for a subset of the OpenID Connect Messages that is intended for use by basic Web-based Relying Parties using the OAuth authorization_code grant type.
• OpenID Connect Implicit Client Profile 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Implicit Client Profile 1.0,” July 2013.) [OpenID.Implicit] - Protocol binding for a subset of the OpenID Connect Messages that is intended for use by basic Web-based Relying Parties using the OAuth implicit grant type.
• OpenID Connect Session Management 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Session Management 1.0,” July 2013.) [OpenID.Session] - Session management for OpenID Connect sessions

12.  References

12.1. Normative References

12.2. Informative References

Appendix A.  Acknowledgements

As a successor version of OpenID, this specification heavily relies on ideas explored in OpenID Authentication 2.0 (OpenID Foundation, “OpenID Authentication 2.0,” December 2007.) [OpenID.2.0]. Please refer to Appendix C of OpenID Authentication 2.0 for the full list of the contributors for that specification.

In addition, the OpenID Community would like to thank the following people for the work they have done in the drafting and editing of this specification.

Naveen Agarwal (naa@google.com), Google

Amanda Anganes (aanganes@mitre.org), Mitre

Casper Biering (cb@peercraft.com), Peercraft

John Bradley (ve7jtb@ve7jtb.com), Ping Identity

Tim Bray (tbray@textuality.com), Google

Johnny Bufu (jbufu@janrain.com), Janrain

Brian Campbell (bcampbell@pingidentity.com), Ping Identity

Breno de Medeiros (breno@gmail.com), Google

Pamela Dingle (pdingle@pingidentity.com), Ping Identity

Vladimir Dzhuvinov (vladimir@nimbusds.com), Nimbus Directory Services

George Fletcher (george.fletcher@corp.aol.com), AOL

Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea

Ryo Ito (ryo.ito@mixi.co.jp), mixi, Inc.

Edmund Jay (ejay@mgi1.com), Illumila

Michael B. Jones (mbj@microsoft.com), Microsoft

Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom

Nov Matake (nov@matake.jp), Independent

Chuck Mortimore (cmortimore@salesforce.com), Salesforce

Anthony Nadalin (tonynad@microsoft.com), Microsoft

Hideki Nara (hdknr@ic-tact.co.jp), Tact Communications

Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom

David Recordon (dr@fb.com), Facebook

Justin Richer (jricher@mitre.org), Mitre

Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.

Luke Shepard (lshepard@fb.com), Facebook

Andreas Akre Solberg (andreas.solberg@uninett.no), UNINET

Paul Tarjan (pt@fb.com), Facebook

Appendix B.  Notices

Copyright (c) 2013 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

Authors' Addresses