OpenID Connect Core 1.0 - draft 06

Abstract

OpenID Connect is an identity framework that provides authentication, authorization, and attribute transmition capability. It allows third party attested claims from distributed sources. The specification suite builts on OAuth 2.0 and consists of Building Blocks (Core, JSON Web Token, JSON Web Signatures, JSON WEB Encryption, JSON Web Keys, Simple Web Discovery), Protocol Bindings (e.g, Artifact Binding, Authorization Code Binding, User Agent Binding) and Extensions. This specification is the "Core" of the suite that defines the messages used and abstract flow which will be further constrained or extended in the companion specifications in the suite.

Table of Contents

1.  Requirements Notation and Conventions
2.  Terminology
3.  Overview
4.  Messages
    4.1.  Authorization Endpoint
    4.2.  Token Endpoint
    4.3.  UserInfo Endpoint
    4.4.  Introspection Endpoint
    4.5.  Session Management
5.  serializations
    5.1.  Query String serialization
    5.2.  JSON Serialization
6.  Signatures
7.  Encryption
8.  Verification
    8.1.  Authorization Request Verification
    8.2.  Authorization Response Verification
    8.3.  UserInfo Request Verification
    8.4.  UserInfo Response Verification
9.  Extensions
10.  Security Considerations
    10.1.  Assertion manufacture/modification
    10.2.  Assertion disclosure
    10.3.  Assertion repudiation
    10.4.  Assertion redirect
    10.5.  Assertion reuse
    10.6.  Secondary authenticator manufacture
    10.7.  Secondary authenticator capture
    10.8.  Assertion substitution
    10.9.  Authentication Request Disclosure
    10.10.  Timing Attack
    10.11.  Authentication Process Threats
11.  IANA Considerations
    11.1.  OAuth Parameters Registry
12.  Open Issues and Things To Be Done (TBD)
Appendix A.  Acknowledgements
Appendix B.  Document History
13.  Normative References
§  Authors' Addresses

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) .

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.

2.  Terminology

In addition to "Access Token", "Refresh Token", "Authorization Code", "Authorization Grant", "Authorization Server", "Authorization Endpoint", "Client", "Client Identifier", "Client Secret", "Protected Resource", "Resource Owner", "Resource Server", "Token Endpoint" defined in OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849], this specification defines the following terms:

Assertion

A set of Claims about the End-User which is attested by the OP and Resource Servers.

Authentication

An act of verifying End-User's identity through the verification of the credential.

Base64url

Base 64 Encoding [RFC3548] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) with URL and Filename Safe Alphabet without padding.

Claims

A piece of information about an Entity that a Claims Provider asserts about that Entity.

Entity

Something that has separate and distinct existence and that can be identified in context.

End-user

A human resource owner.

OpenID Provider (OP)

Authorization Servers that are able to support OpenID Connect Messages. OP.

OP Endpoints

End-User Authentication, Authorization, and Token Endpoint.

OpenID Request Object

A JSON object that holds the request variables. It holds OpenID request variables. It MAY also contain other OAuth parameters for the request signing purpose, in which case the parameter values MUST match with the OAuth request parameters.

Relying Party (RP)

Client and Resource Servers.

RP Endpoints

The endpoint to which the OP responses are returned through redirect.

UserInfo Endpoint

A protected resource that when presented with a token by the client returns authorized information about the current user.

Session Token

A JWS token that provides claims about an authenticated user but may or may not be bound to an authentication session.

3.  Overview

OpenID Connect protocol in abstract follows the following steps.

1. The Client sends a request to the Server's End-User Authorization Endpoint.
2. The Server authenticates the user and obtains appropriate authorization.
3. The Server responds with access_token and a few other variables.
4. The Client sends a request with the access_token to the Userinfo Endpoint.
5. Userinfo Endpoint returns the additional user information supported by the Server.

Each message may be signed and encrypted. When the message is encrypted, it MUST be signed first then encrypted. This specification only defines the abstract messsage flow and message formats. The actual use MUST be based on one of the companion protocol bindings specifications such as OpenID Connect Artifact Binding 1.0 (Sakimura, N., Ed., Bradley, J., de Madeiros, B., Ito, R., and M. Jones, “OpenID Connect Artifact Binding 1.0,” January 2011.) [OpenID.AB] or OpenID Connect Authorization Code Binding 1.0 (Mortimore, C., Ed., Sakimura, N., Bradley, J., de Madeiros, B., Ito, R., and M. Jones, “OpenID Connect Authorization Code Binding 1.0,” January 2011.) [OpenID.AC].

4.  Messages

In OpenID Connect protocols in abstract, the process proceeds by the Client interacting with Endpoints. There are number of Endpoints involved.

1. Authorization Endpoint: The Client sends a request to the Server at the Authorization endpoint. The Server then authenticate the End-User to find out if he is eligible to make the authorization. Then, upon the authorization action of the End-User, the Server returns an Authorization Response that includes Authorization Code, code. For some Clients, Implicit Grant may be used to obtain access_token without using code. In this case, response_type MUST be set to token.
2. Token Endpoint: The Client sends the Access Token Request to the Token Endpoint to obtain Access Token Response which includes access_token and session token.
3. UserInfo Endpoint: The access_token MAY be sent to the UserInfo Endpoint to obtain user information/assertion/claims about the user by sending a request to the userinfo endpoint.
4. Session Management Endpoints: The session token MAY be sent to these endpoints to manage the session.

Both Request and Response may either be serialized into Query String serialization (Query String serialization) or JSON (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627].

4.1.  Authorization Endpoint

Client sends Authorization Request to the Authorization Endpoint to obtain Authorization Response.

4.1.1.  Authorization Request

Section 4.1.1 and 4.2.1 of OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849] defines OAuth Authorization Request parameters. In this specification, the values to the parameters are defined as follows.

response_type

The is a space delimited, case sensitive list of string values(Pending Oauth 2.0 changes). Acceptable values are code, token, session, and none. The value MUST include code for requesting an Authorization Code, token for requesting an Access Token, session for requesting a Session Token, and none if no response is needed..

scope

It MUST include openid as one of the string.

In addition, this specification defines the following extension parameters.

req

OPTIONAL. A JWT (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.) [jwt] encoded OpenID Request Object (OpenID Request Object).

request_uri

OPTIONAL. A URL that points to the OpenID Request Object.

display

OPTIONAL. A string value that specifies how the authorization server displays the authentication page to the user.

none

The authorization server MUST NOT display any authentication page.

popup

The authorization server displays a popup authentication page.

mobile

The authorization server performs authentication using a mobile device???

prompt

OPTIONAL. A space delimited, case sensitive list of string values that specifies how the authorization server prompts the user for reauthentication and reapproval. The possible values are :

login

The authorization server MUST prompt the user for reauthentication.

consent

The authorization server MUST prompt the user for reapproval before returning information to the client.

select_account

The authorization server MUST prompt the user to select a user account if the current account does not match the account in the request.

nonce

OPTIONAL. A random, unique string. The nonce value is returned in the session token.

session_aud

OPTIONAL. The identifier of the target audience for a session token.

Following is a non-normative example when they are sent in the query parameters serialization.

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

4.1.1.1.  OpenID Request Object

The OpenID Request object is used to provide OpenID request parameters that MAY differ from the default ones. Implementing support for the OpenID Request object is OPTIONAL. Supporting it is necessary for implementations that need to request or provide sets of claims other than the default UserInfo claim set.

If present, the OpenID Request object is passed as the value of a "req=" OAuth 2.0 parameter and is represented as a JWT. Parameters that affect the information returned from the UserInfo Endpoint are in the "inf" member. Parameters that affect the information returned in the Session Token are in the "ses" member. If the same parameters are available both as query strings and in the OpenID Request Object, the later takes the precedence.

An example an OpenID request object is as follows:

{
 "inf":
   {
     "clm":
       {
         "name": null,
         "displayName": {"opt": true},
         "emails": null,
         "photos": {"opt": true},
       },
     "fmt": "sig"
   }
 "ses":
   {
     "clm":
       {
        "aat": null
       }
     "mxa": 86400,
     "eaa": 2
   }
}

The OpenID Request object is a JWT (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.) [jwt] that MAY contain a set of members defined by this specification and MAY contain other members that are not defined by this specification. The JWT MAY be signed or unsigned. When it is unsigned, it will be indicated by the JWT "sig":"none" convention in the JWT header.

The members defined by this specification are:

inf

OPTIONAL. (UserInfo Endpoint request): Requests affecting the values to be returned from the UserInfo Endpoint. If not present, the UserInfo Endpoint behaves in the default manner.

ses

OPTIONAL. (Session Token request): Requests affecting the values to be included in the Session Token. If not present, the default Session Token contents are used. If present, these parameters are used to request deltas to the default contents of the Session Token.

If signed, the OpenID Request object SHOULD contain the standard JWT "iss" and "aud" claims.

The structure of the "inf" (UserInfo Endpoint request) member is a JSON object that MAY contain the following members:

clm

OPTIONAL. (Requested Claims): Set of requested claims from the UserInfo Endpoint. If not present, the default UserInfo claims held by the IdP are returned.

fmt

OPTIONAL. (Format): The requested format for the UserInfo Endpoint information. If not present, the format is an unsigned JSON object.

The "clm" member is a JSON object with a member for each requested claim. The member names are the requested claim names. The member values may be either:

null

This indicates that this claim is being requested in the default manner. In particular, this is a required claim. OR

A JSON Object

This is used to provide additional information about the claim being requested.

All members of the "clm" object are OPTIONAL.

The members of the JSON object value following a claim name defined by this specification are:

opt

If this is an optional claim, this member's value MUST be true, else, if present, its value MUST be false, which indicates that it is a required claim. If it is not present, it is a required claim.

Other members MAY be defined to provide additional information about the requested claim. If the "clm" member is present in the "info" object, the claims requested within it override the default claim set that would otherwise be returned from the UserInfo Endpoint.

The "fmt" member of the "inf" object is used to specify the requested format of the UserInfo Endpoint contents. Values defined are:

nor

(normal) - in which case the contents are an unsigned JSON object

sig

(signed) - in which case the contents are a signed JWT

enc

(encrypted) - in which case the contents are an signed and encrypted JWT

All members of the "inf" object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties.

The structure and function of the "ses" (Session Token request) member of the OpenID Request object is similar to that of the "inf" member. It also contains an optional "clm" member, with the same structure as that for the "inf" member. If the "clm" member is present in the "ses" object, the claims requested within it modify the default claim set that would otherwise be returned in the Session Token. Unlike for the "inf" member, typically these claims will augment, rather than override the default set.

Following claim MAY be requested in the Session Token by specifying it in the "clm" member:

aat

OPTIONAL. (authenticated at): Requests that the "aat" claim be present. The claim value is the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time that the user authentication occurred. (The "aat" claim semantically corresponds to the openid.pape.auth_time response parameter.)

In addition to the "clm" member, this additional member is defined within the "ses" member of the OpenID Request object:

mxa

OPTIONAL. (max authentication age): Specifies that the user must be actively authenticated if any present authentication is older than the specified number of seconds. (The "mxa" request parameter corresponds to the OpenID 2.0 openid.pape.max_auth_age request parameter.)

eaa

OPTIONAL. (entity authentication assurance): Specifies the X.eaa / ISO/IEC29115 (McCallister, E., “ITU-T Recommendation X.eaa | ISO/IEC 2nd CD 29115 -- Information technology – Security techniques – Entity authentication assurance framework,” .) [ISO29115] entity authentication assurance level that is requested by the client.

It is anticipated that additional "ses" parameters MAY be defined to request that additional properties hold for the authentication - for instance, that certain authentication policies be applied (in the same spirit of the OpenID 2.0 openid.pape.auth_policies values), or that the authentication conform to the policies defined by a specified trust framework. These parameters MAY be defined by extension specifications.

All members of the "ses" object are OPTIONAL. Other members MAY be present and if so, SHOULD understood by both parties.

All members of the OpenID Request object are OPTIONAL. Other members MAY be present and if so, SHOULD be understood by both parties.

4.1.2.  Authorization Response

When the response_type in the request includes code, the Authorization Response MUST return the parameters defined in section 4.1.2 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” November 2011.) [OAuth2.0]. Response values for other requested response_type parameters are returned in the Access Token Endpoint (Need Confirmation). Note that if the response_type in the request includes token, the Access Token Response (Access Token Response) defined later MUST be returned instead. The response_type "none" preempts all other values and no other response values are included.

For example, the Authorization Server redirects the End-User's user-agent by sending the following HTTP response:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=i1WsRn1uB1&state=1f 8skd

4.1.3.  Authorization Error Response

If the end-user denies the access request or if the request fails, the authorization server informs the client by returning parameters defined in section 4.1.2.1 of OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849] .

4.1.3.1.  Error Codes

In addition to the error codes defined in section 4.1.2.1 of OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849], this specification defines the following additional error codes:

invalid_request_redirect_uri

The redirect_uri in the request is missing or malformed.

invalid_request_signature

The request has an invalid signature.

login_required

The authorization server requires user authentication.

session_selection_required

The user is required to select a session at the authorization server.

approval_required

The authorization server requires user approval.

user_mismatched

The current logged in user at the authorization server does not match the requested user.

The error codes can be extended by the string prefixed by x_. If custome error code are used, error_uri MUST be provided.

4.2.  Token Endpoint

Access Token Request / Response interacts with a Token Endpoint. Upon the successful request, it returns two tokens, an Access Token and a Session Token if requested.

4.2.1.  Access Token Request

The client obtains an access token by authenticating with the authorization server and presenting its access grant (in the form of an authorization code, resource owner credentials, an assertion, or a refresh token).

The request parameters of of the Access Token Request is defined in section 4.1.3 of OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849] .

4.2.2.  Access Token Response

After receiving and verifying a valid and authorized Access Token Request from the client, the Authorization Server returns a Positive Assertion that includes an Access Token. The parameters in the successful response is defined in Section 4.2.2 of OAuth 2.0 (Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” November 2011.) [OAuth2.0] .

In addition, this specification defines the following parameter:

session

REQUIRED if it was requested in the authorization request. It is a JWS (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” March 2011.) [jws] of the session token (Session Token) described below.

Following is a non-normative example.

{
    "access_token": "SlAV32hkKG",
    "token_type": "jwt",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "session":"jwtheader.jwtpayload.jwtcrypto"
}

As in the OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849], Clients SHOULD ignore unrecognized response parameters.

4.2.2.1.  Session Token

The Session Token is a JWS signed claim that attests the following:

server_id

REQUIRED. The unique identifier of the authorization server such that when paired with the user_id creates a globally unique and never reassigned identifier.

client_id

REQUIRED. The unique identifier of the client.

user_id

REQUIRED. A locally unique and never reassigned identifier for the user, which is intended to be consumed by the Client. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length.

aud

REQUIRED. The JWT (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.) [jwt]aud (audience) claim.

exp

REQUIRED. The JWT (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.) [jwt] exp (expiration time) claim.

pape

OPTIONAL. (TBD) If we want this token to be short, we probably want to define a shorter equivalent of PAPE.

nonce

OPTIONAL. If the authorization request includes a nonce request value, then this value is REQUIRED and it's value is set to the same value as the request value.

4.2.3.  Token Error Response

If the token request is invalid or unauthorized, the authorization server constructs the error response. The parameters of the Token Error Response is defined as in Section 5.2 of OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849].

4.2.3.1.  Error Codes

In addition to the error codes defined in Section 5.2 of OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849], this specification defines the following error codes.

invalid_client_secret

The client secret does not matched pre-shared secret code, is of a different type, or has an invalid signature.

invalid_secret_type

The specified secret type is unsupported.

invalid_request_signature

The request has an invalid signature.

invalid_request_code

The authorization code is missing, malformed, or invalid.

The error codes can be extended by the string prefixed by x_. If custome error code are used, error_uri MUST be provided.

4.3.  UserInfo Endpoint

UserInfo Request/Response interacts with UserInfo Endpoint.

4.3.1.  UserInfo Request

Client MAY send request with following parameters to the UserInfo Endpoint to obtain further information about the user.

access_token

REQUIRED. The access_token obtained above.

user_id

REQUIRED. A locally unique and never reassigned identifier for the user. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length. It could be a pairwise private identifier of the enduser between the Client and the Server.

client_id

REQUIRED. The client identifier recognized by the authorization server.

4.3.2.  UserInfo Response

The response is a JSON object which contains some (or all) of the following reserved keys:

[ToDo: Replace with scim based definition -- Pam doing the table.]

user_id

REQUIRED. A locally unique and never reassigned identifier for the user. e.g. "24400320" or "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4". It MUST NOT exceed 255 ASCII characters in length. It MUST NOT be reassigned to another user.

server_id

REQUIRED. The unique identifier of the authorization server such that when paired with the user_id creates a globally unique and never reassigned identifier.

client_id

REQUIRED. The client identifier recognized by the authorization server.

asserted_user

REQUIRED. One of "true" if the access was issued for this user or "false" if it is for a different user.

profile_urls

OPTIONAL. An array of URLs that belong to the user across any number of domains.

display_name

OPTIONAL. The display name of the user. e.g., "David Recordon".

given_name

OPTIONAL. The first name of the user. e.g., "David".

family_name

OPTIONAL. The family name of the user. e.g., "Recordon".

email

OPTIONAL. The verified email address of the user. e.g., "recordond@gmail.com".

language

OPTIONAL. End User's preferred language as specified by ISO639.

picture

OPTIONAL. The URL of End User's Picture. e.g., "http://graph.facebook.com/davidrecordon/picture".

openid

REQUIRED if OpenID variables were specified in the Authorization Request. It is a JSON Object that includes the claim responses.

4.3.3.  UserInfo Error Response

The Authorization Server includes one of the following error codes with the error response:

invalid_request

The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.

invalid_client

The client identifier provided is invalid, the client failed to authenticate, the client did not include its credentials, provided multiple client credentials, or used unsupported credentials type.

unauthorized_client

The authenticated client is not authorized to use the access grant type provided.

invalid_grant

The provided access grant is invalid, expired, or revoked (e.g. invalid assertion, expired authorization token, bad end-user password credentials, or mismatching authorization code and redirection URI).

unsupported_grant_type

The access grant included - its type or another attribute - is not supported by the authorization server.

invalid_scope

The requested scope is invalid, unknown, malformed, or exceeds the previously granted scope.

invalid_access_token

The access token is not valid for the requested resource, malformed, is in an incorrect format, outside the valid scope, or expired.

invalid_refresh_token

The refresh token is not valid, malformed, is in an incorrect format, outside the valid scope, or expired.

invalid_request_signature

The request has an invalid signature.

invalid_request_type

The request type is unsupported.

invalid_request_atype

The request contains an unsupported response assertion type.

invalid_request_recipient

The recipient of the request is invalid or does not match.

4.4.  Introspection Endpoint

The introspection endpoint returns a text JSON object which contains information about the end user associated with supplied access token or session. It is for use by clients that cannot or do not wish to handle signed tokens.

Request Parameters: One of the following parameters

access_token

OPTIONAL. A token obtained from the token endpoint.

session

OPTIONAL. A session token obtained from the authorization request.

Both parameters are optional, but at least one parameter must be supplied.

Response:

The response is a text JSON object of the session token (Session Token) using the "application/json" media type. If the request contains an access token, the authorization server creates a version of a session token and returns it as a JSON object. However, a session is not created. If the request contains a session token, then the server returns the JSON object of the session token.

The following is a non-normative example of a request to the introspection endpoint:

Request:

GET /op/introspection?access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ
Host: server.example.com

Response:

HTTP/1.1 200 OK
Content-Type: application/json

{
"server_id": "http://server.example.com",
"client_id": "http://client.example.net",
"user_id": "Jane Doe",
"aud": "http://client.example.net",
"exp": "1236485123"
}

4.4.1.  Error Codes

In addition to the error codes defined in Section 5.2 of OAuth 2.0 (Hammer-Lahav, E., “The OAuth 1.0 Protocol,” April 2010.) [RFC5849], this specification defines the following error codes.

invalid_access_token

The access token is not valid for the requested resource, malformed, is in an incorrect format, outside the valid scope, or expired.

invalid_session

The session token is not valid for the requested resource, malformed, is in an incorrect format, or expired.

4.5.  Session Management

The OpenID Connect Core supports life-cycle session management and synchronization for third parties that support authentication with the authorization server. In addition, session management for fourth parties such as desktop, native or mobile applications that utilizes authorization server credentials at fourth party web sites are also supported.

4.5.1.  Creating Sessions

To create a session, the client sends an authorization request to the authorization server with session as one of the response_type values. If the response_type includes the value code, then a session token is returned in the response of the Token Endpoint when the Access Token is retrieved. If the response_type includes the value token, then a session token is returned as a parameter in the redirection URI specified in the request. In either case, a session token will also be returned along with the access token when submitting a refresh token to the token access endpoint if the initial authorization request included session in the response_type parameter.

4.5.1.1.  User-Agent Flow

User-agents can use the OAuth implicit grant flow by including token and session in the response_type of the authorization request to get a session token.

1. The user-agent makes an authorization request to the authorization endpoint.
2. The authorization authenticates the user and returns an access and session token.
3. The user-agent and client servlet can then use the session management endpoints by presenting the session token to the endpoints.

                                 +----------------------------------+
+----------+                     |                                  |
|          |                     |      +----------------------+    |
|          |                     |      |    Authorization     |    |
|          |                     |      |         server       |    |
|user-agent|                     |      +----------------------+    |
|          |                     |      |   +---------------+  |    |
|          |>--------------------|------|-->| Authorization |  |    |
|          |<--------------------|------|--<| Endpoint      |  |    |
+----------+                     |      |   +---------------+  |    |
    ^                 +----------|------|--<| Check_Session |  |    |
    |                 | +--------|------|-->| EndPoint      |  |    |
    |                 | |        |      |   +---------------+  |    |
    v                 | |        |      +----------------------+    |
+----------+          | |        |                                  |
|          |          | |        |                                  |
|client    |<---------+ |        |      +----------------------+    |
|servlet   |>-----------+        |      |     Profile API/     |    |
|          |                     |      |     UserInfo Endpoint|    |
|          |                     |      |                      |    |
|          |>--------------------|----->|                      |    |
|          |<--------------------|-----<|                      |    |
|          |                     |      |                      |    |
|          |                     |      |                      |    |
+----------+                     |      +----------------------+    |
                                 |                                  |
                                 |                                  |
                                 +----------------------------------+

                             +-----------------------------+
                             |                             |
                             |      Authorization          |
                             |         Server              |
+-------------+              |                             |
|             |              |     +--------------------+  |
| User-Agent  |              |     |  Refresh Session   |  |
|             |              |     |    Endpoint        |  |
|             |>-------------|---->|                    |  |
|             |<-------------|----<|                    |  |
|             |              |     |                    |  |
|             |              |     +--------------------+  |
|             |              |     |  End Session       |  |
|             |>-------------|---->|    Endpoint        |  |
|             |<-------------|----<|                    |  |
|             |              |     |                    |  |
|             |              |     +--------------------+  |
+-------------+              +-----------------------------+

4.5.1.2.  Web Server Flow

Web server clients can use the OAuth authorization code flow by including code and session in the response_type parameter of the authorization request to obtain a session token. The session token is returned along with the access token after the client submits the authorizaiton code to the access token endpoint.

                                 +----------------------------------+
+----------+                     |                                  |
|          |                     |      +----------------------+    |
|          |                     |      |    Authorization     |    |
|          |                     |      |         server       |    |
|user-agent|                     |      +----------------------+    |
|          |                     |      |   +---------------+  |    |
|          |>--------------------|------|-->| Authorization |  |    |
|          |<--------------------|------|--<| Endpoint      |  |    |
+----------+                     |      |   +---------------+  |    |
    ^                 +----------|------|--<| Access Token  |  |    |
    |                 | +--------|------|-->| EndPoint      |  |    |
    |                 | |        |      |   +---------------+  |    |
    v                 | |        |      |   | Session       |  |    |
+----------+          | |        |      |   | Management    |  |    |
|          |          | |        |      |   | Endpoints     |  +    |
|client    |<---------+ |        |      |   +---------------+  |    |
|servlet   |>-----------+        |      +----------------------+    |
|          |                     |                                  |
|          |                     |      +----------------------+    |
|          |                     |      |     Profile API/     |    |
|          |                     |      |     UserInfo Endpoint|    |
|          |<--------------------|-----<|                      |    |
|          |>--------------------|----->|                      |    |
+----------+                     |      +----------------------+    |
                                 |                                  |
                                 |                                  |
                                 +----------------------------------+

4.5.1.3.  4th Party Native Applications

Fourth party native applications involve four parties: 1) the user, 2) the native (desktop) application, 3) the authorization server, and 4) the client servlet web application. The native application uses protected resources from a client servlet but it integrates with authentication services from the authorization server directly. The native application directs the user to perform authentication at the authorization server to obtain access and session tokens. The tokens can then be used to access protected resources at the web servlet client. The process of obtaining a session token for the native application is very similar to that of using the web server flow method. However, the target audience of the session token is not the the native application, but that of the client servlet. The client needs to indicate the target audience for the session token by setting the session_aud parameter in the authorization request to that of the identifier of the client servlet.

                                     +-----------------------------+
+----------------+                   |                             |
|                |                   |   Authorization             |
|   Native App   |                   |      Server                 |
|                |                   |                             |
|                |                   |      +--------------------+ |
|                |>------------------|----->| Authorization      | |
|                |<------------------|-----<|   Endpoint         | |
|                |                   |      |                    | |
|                |                   |      |                    | |
|                |                   |      +--------------------+ |
|                |                   |      | Access Token       | |
|                |>------------------|----->|   Endpoint         | |
|                |<------------------|-----<|                    | |
|                |                   |      |                    | |
|                |                   |      +--------------------+ |
|                |>------------------|----->| Session Mgmt       | |
|                |<------------------|-----<|   Endpoints        | |
|                |                   |      |                    | |
+----------------+                   |      |                    | |
        ^                            |      |                    | |
        |                            |      +--------------------+ |
        v                            |                             |
+----------------+                   |                             |
| Client         |                   +-----------------------------+
| Servlet        |
|                |
+----------------+

When accessing protected resources at the client servlet, the native application sends the session token as an Auth HTTP header in the request. The client servlet can check the validity of the session token by verifying the cryptographic information or by sending the token to the check token endpoint.

GET /resource1
Auth : sess_jwtheader.sess_jwtpayload.sess_jwtcrypto
Host: servlet.example.com

4.5.1.3.1.  Browser Load

Some native applications may wish to start an authenticated browser session for the same user. The native application starts a browser with the location of the client servlet and passing a session token as a query parameter. The client servlet immediately initiates a request to the refresh session endpoint with the session token. The user may need to reauthenticate at the authorization server. The client servlet then gets an session token that is session synchronized with the authorization server.

                                        +--------------------------+
+------------+      +-----------+       |                          |
|            |      |           |       |   Authorization Server   |
| Native App |>---->|User-Agent |       |                          |
|            |      |           |       |    +------------------+  |
|            |      |           |>------|--->| Session Refresh  |  |
|            |      |           |<------|---<|    Endpoint      |  |
+------------+      +-----------+       |    |                  |  |
      ^                   ^             |    +------------------+  |
      |                   |             |                          |
      v                   v             |                          |
+--------------------------------+      |                          |
|                                |      |                          |
|       Client Servlet           |      |                          |
|                                |      |                          |
+--------------------------------+      +--------------------------+



GET
/refesh_token?state=bar&redirect_uri=https://foo.com/oauth2callback&session=$session_token // never uses immediate mode here, to allow login
Host: www.example.com

Response:

HTTP/1.1 302 Found
Location: https://foo.com/oauth2callback?state=bar&session=$new_session_token

4.5.1.4.  Session Synchronization

A session token is usually bound to a user's sign in session at the authorization server, but in some cases, such as offline access by a web server or native application, it may not be. Session tokens obtained in the following scenarios are bound to a user's signed-in state at the authorization server:

• Redeeming a code for an access and session token by way of indirect communication through the browser
• Obtaining an access and session token in the authorization response through the browser
• Obtaing a session token at the refresh session endpoint by submitting a previously issued session token

Session tokens obtained in the above manner are session synchronized.

If a session token is obtained by submitting a refresh token at the access token endpoint, then the resulting session token is not bound to a user's sign in state at the authorization server. The client may be in offline mode or the user has logged out from the authorization server. If a session bound session token is desired, the client should obtain a new session token by sending a request to the refresh session endpoint.

4.5.1.5.  Session Management Endpoints

To manage a session, the client sends a request to the session management endpoints at the authorization server. The session management endpoints at the authorization server are:

Session Refresh

Refreshes an expired Session Token

Check Session

Get a plain text JSON structure from a session token

End Session

Ends a session

4.5.1.5.1.  Session Refresh

To refresh a session that has expired, the client sends a request to the Refresh Session endpoint with a Session Token. A new Session Token is returned in JWS format.

Request Parameters:

session

REQUIRED. A previously issued session token from an authorization request. The session token MAY be expired.

state

REQUIRED. An opaque value used by the Client to maintain state between the request and callback. If provided, the Authorization Server MUST include this value when redirecting the user-agent back to the Client. Clients are strongly advised to use this variable to relate the request and response.

redirect_uri

REQUIRED. An absolute URI to which the authorization server will redirect the user-agent to with the new Session Token.

Response:

The response is a new Session Token. In a typical HTTP binding, an HTTP 302 redirect to the specified redirect_uri in the request with a new Session Token.

session

A new Session Token

The following is a non-normative session refresh request:

Request:

GET /op/refresh_session?session=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ
&state=bar&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fidtoken_cb
Host: server.example.com

Response:

HTTP/1.1 302 OK
Location: http://client.example.com/idtoken_cb#session=eyJ0eXAiOiJKV1QiLCJh
bGciOiJIUzI1NiIsImtpZCI6ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwO
lwvXC9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20
iLCJhdWRpZW5jZSI6ImNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJle
HAiOjEzMDM4NTI4ODB9.aJwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ&state=bar&
expires_in=3600

4.5.1.5.2.  Check Session

For clients that are not capable of dealing with JWS signed Session Tokens, they can send the Session Token to the Check Session endpoint. It will validate the Session Token and return a plain text JSON structure of the Session Token.

Request Parameters:

session

REQUIRED. A previously issued Session Token

Response:

The response body is a plain text JSON structure of the base64url decoded payload of the signed Session Token. In a typical HTTP binding, the response is a HTTP 200 response code with the content-type header set to "application/json".

The following is a non-normative example of a check session request:

Request:
POST /op/check_session?session=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbXBs
ZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6ImNsa
WVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4ODB9.a
JwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ

Response:
HTTP/1.1 200 OK
Content-Type: application/json

{
  "iss":"http://server.example.com",
  "client_id","http://client.example.com",
  "audience", "http://client.example.com",
  "user_id":"user_328723",
  "exp":1303852880
}

4.5.1.5.3.  End Session

To end the session, the client sends a Session Token to the End Session endpoint. Upon receiving the request, the authorization server performs the logout flow for the user and then redirects the user-agent to the specified redirect_uri.

Request Parameters:

session

REQUIRED. A previously issued Session Token

state

REQUIRED. An opaque value used by the Client to maintain state between the request and callback. If provided, the Authorization Server MUST include this value when redirecting the user-agent back to the Client. Clients are strongly advised to use this variable to relate the request and response.

redirect_uri

REQUIRED. An absolute URI to which the authorization server will redirect the user-agent.

Response:

The response is dependant on the particular binding. In HTTP binding, the response is a HTTP 302 redirect response to the redirect_uri specified in the request.

The following is a non-normative session refresh request:

Request:

GET /op/end_session?session=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6
ImNsaWVudC5leGFtcGxlLmNvbSJ9.eyJpc3N1ZXIiOiJodHRwOlwvXC9zZXJ2ZXIuZXhhbX
BsZS5jb20iLCJjbGllbnRfaWQiOiJjbGllbnQuZXhhbXBsZS5jb20iLCJhdWRpZW5jZSI6I
mNsaWVudC5leGFtcGxlLmNvbSIsImlkIjoidXNlcl8yMzQyMzQiLCJleHAiOjEzMDM4NTI4
ODB9.aJwagC6501Da-zK-X8Az9B-Y625aSEfxVuBpFEDjOxQ
&state=bar
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fendtoken_cb
Host: server.example.com

...
   Authorizion server performs logout flow
...

Response:

HTTP/1.1 302 OK
Location: http://client.example.com/endtoken_cb?state=bar

5.  serializations

Each message can be serialized either in query parameter serialization or JSON serialization unless it was explicitly stated in the previous sections.

5.1.  Query String serialization

In order to serialize the parameters into Query String Serialization, the client constructs the string by adding the following parameters to the end-user authorization endpoint URI query component using the application/x-www-form-urlencoded format as defined by HTML 4.01 Specification (Ragget, D., “HTML 4.01 Specification,” December 1999.) [html401]:

Following is a non-normative example of such Serialization.

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

5.2.  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 JSON Structure as its value.

Following is a non-normative example of such Serialization.

{
  "access_token":"SlAV32hkKG",
  "expires_in":3600,
  "refresh_token":"8xLOxBtZp8",
  "openid": {
    "type": "http://openid.net/specs/ab/1.0#id_res",
    "mode": "id_res",
    "op_endpoint": "https://op.example.com/op_endpoint",
    "client_id": "http://rp.example.com/",
    "server_id": "http://op.example.com/",
    "claimed_id": "https://example.com/alice#1234",
    "identity": "alice",
    "issued_at": 1274889460
  }
}

6.  Signatures

Depending on the transport through wich the messages are transported, the integrity of the message may not be guaranteed, nor the originator of the message is not authenticated. To mitigate these risks, OpenID Connect supports JSON Web Signatures(JWS) (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” March 2011.) [jws].

Following is the parameters for JWT.

typ

OPTIONAL. One of "JWT", "openid2json+sig".

alg

REQUIRED. One of the algorithm specified in Table 4 of JWT (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.) [jwt]

Compact Serialization SHOULD BE used when passing it through query parameters, while JSON serialization SHOULD BE used when returning it in HTTP Body.

Following is a non-normative example of such signature in Compact serialization, where HS256 algorithm was used (with line breaks for display purposes only):

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

7.  Encryption

To achieve message confidentiality and audience restriction, OpenID Connect uses JSON Web Encryption (JWE) (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Encryption,” March 2011.) [jwe].

8.  Verification

8.1.  Authorization Request Verification

If the request was signed, the Server MUST verify the signature as in JWT.

8.2.  Authorization Response Verification

To verify the validity of the Authorization Response, the client MUST to the following:

1. If the response was signed, the Client SHOULD verify the signature as in JWT as the first step.
2. Check that OP that it connected was really the intended OP through TLS/SSL server certificate check if the endpoint is TLS/SSL endpoint.
3. Check that current time is within the validity period.

If the client does not verify the signature, it MUST make a User Info API request.

8.3.  UserInfo Request Verification

If the request was signed, the Server MUST verify the signature as in JWT (Jones, M., Belfanz, D., Bradeley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” January 2011.) [jwt].

8.4.  UserInfo Response Verification

To verify the validity of the UserInfo Response, the client MUST to the following:

1. If the response was signed, the Client SHOULD verify the signature as in JWT as the first step.
2. Check that OP that it connected was really the intended OP through TLS/SSL server certificate check if the endpoint is TLS/SSL endpoint.
3. Check if the current time is within the validity period.

9.  Extensions

OpenID Connect supports the extension parameters in OpenID Request Object, Session Token, and UserInfo Response.

10.  Security Considerations

Followings are the list of attack vectors and remedies that were considered for this specification.

For details of the attack vector, see [SP800‑63] (National Institute of Standards and Technology, “NIST SP800-63rev.1: Electronic Authentication Guideline,” .).

10.1.  Assertion manufacture/modification

To mitigate this attack, there are two ways to mitigate it.

1. The assertion may be digitally signed by the OP. The Relying Party SHOULD check the digital signature to verify that it was issued by a legitimate OP.
2. The assertion may be sent over a protected channel such as TLS/SSL. In order to protect the integrity of assertions from malicious attack, the OP MUST be authenticated. In this specification, the assertion is always sent over TLS/SSL protected channel.

10.2.  Assertion disclosure

The Assertion disclosure can be mitigated in the following two ways.

1. Assertion is sent over TLS/SSL protected channel, where RP is authenticated by "client_id" and "client_secret".
2. Signed Assertion is encrypted by the RP's public key.

10.3.  Assertion repudiation

To mitigate this threat, the assertion may be digitally signed by the OP using a key that supports non-repudiation. The RP SHOULD check the digital signature to verify that it was issued by a legitimate OP.

10.4.  Assertion redirect

To mitigate this threat, the assertion includes the identity of the RP for whom it was generated as "client_id". The RP verifies that incoming assertions include its identity as the recipient of the assertion.

10.5.  Assertion reuse

The assertion includes a timestamp and a short lifetime of validity. The Relying Party checks the timestamp and lifetime values to ensure that the assertion is currently valid.

10.6.  Secondary authenticator manufacture

Due to the large entropy requirement of the Artifact ("code") and short life nature of its validity, the success probability of this attack is extremely low.

10.7.  Secondary authenticator capture

Secondary authenticator (="code") is transmitted only through HTTPS, thus it is protected between the OP and the User-Agent, and User-Agent and the RP.

Only the place it can be captured is the User-Agent where the TLS session is terminated, and is possible if the User-Agent is infested by malwares. However, it renders no usefulness as long as the profile in use either RP authentication or assertion encryption.

10.8.  Assertion substitution

Responses to assertion requests is bound to the corresponding requests by message order in HTTP, as both assertions and requests are protected by TLS that can detect and disallow malicious reordering of packets.

10.9.  Authentication Request Disclosure

If the authentication request is POSTed directly through a protected channel, it is not possible to disclose the authentication request.

If the Request File is encrypted by the OP's public key, the authentication request will not be disclosed unless OP's private key gets compromised or the encryption algorithm becomes vulnerable.

10.10.  Timing Attack

Timing attack can be used to reduce the effctive key length of the signature if the time required to return the response in case of signature error and correct signature exists. Care should be taken in the implementation to avoid this attack.

10.11.  Authentication Process Threats

In the category of Authentication Process Threats, following threats exists.

• Online guessing
• Phishing
• Pharming
• Eavesdropping
• Replay
• Session hijack
• Man-in-the-middle

Authentication process per se as described in NIST SP800-63-rev1 is out of scope for this protocol, but care SHOULD be taken to achieve appropriate protection.

11.  IANA Considerations

11.1.  OAuth Parameters Registry

11.1.1.  Scope Parameters

The following is the parameter registration request for the "scope" parameter as defined in this specification:

• Parameter name: openid
• Parameter usage location: The End-User Authorization Endpoint request, the End-User Authorization Endpoint response, the Token Endpoint request, the Token Endpoint response, and the WWW-Authenticate header field.
• Change controller: IETF
• Specification document(s): [[ this document ]]
• Related information: None

11.1.2.  Authorization Request Parameters

The follwoing is the parameter registration request for the Authorization Reqeust in this specification:

• Parameter name: openid
• Parameter usage location: Authorization Request
• Change controller: IETF
• Specification document(s): [[ this document ]]
• Related information: None

11.1.3.  Access Token Response Parameters

The following is the parameter registration request for the Access Token Response in this specification:

• Parameter name: openid
• Parameter usage location: Access Token Response
• Change controller: IETF
• Specification document(s): [[ this document ]]
• Related information: None

12.  Open Issues and Things To Be Done (TBD)

[[To be removed from the final specification.]]

Following items remains to be done in this draft.

1. Clean Up and add references.
2. Update JWT/JWS/JWE related things with the most current version of them.
3. Finish the security consideration section.
4. Properly capitalize the Defined Words.
5. Better to split the Authentication and Authorization server? (Model-wise, yes, but it gets complicated. Current model is implicitly assuming that the Authentication and Authorization server are operated by the same entity and the protocol between them are proprietary.)

Appendix A.  Acknowledgements

As a successor version of OpenID Authentication 2.0 (specs@openid.net, “OpenID Authentication 2.0,” 2007.) [OpenID.authentication‑2.0], this specification heavily relies on OpenID Authentication 2.0 (specs@openid.net, “OpenID Authentication 2.0,” 2007.) [OpenID.authentication‑2.0]. Please refer to Appendix C of OpenID Authentication 2.0 (specs@openid.net, “OpenID Authentication 2.0,” 2007.) [OpenID.authentication‑2.0] for the full list of the contributors for OpenID Authentication 2.0 (specs@openid.net, “OpenID Authentication 2.0,” 2007.) [OpenID.authentication‑2.0].

This specification is largely compliant with OAuth 2.0 draft 15. As the draft is not yet referenceable, relevant text has been incorporated into this draft. Please refer to the OAuth 2.0 specification for the list of contributors.

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

Anthony Nadalin (tonynad@microsoft.com), Microsoft.

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

Chuck Mortimore (cmortimore@salesforce.com), Salesforce.com.

David Recordon (dr@fb.com)<author>, Facebook.

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

Hideki Nara (hideki.nara@gmail.com), Takt Communications.

John Bradley (jbradely@mac.com) <author>, Protiviti Government Service.

Mike Jones (Michael.Jones@microsoft.com), Microsoft.

Nat Sakimura (n-sakimura@nri.co.jp) <author/editor>, Nomura Research Institute, Ltd.

Paul Tarjan (pt@fb.com), Facebook.

Ryo Itou (ritou@yahoo-corp.jp), Yahoo! Japan.

Appendix B.  Document History

-01

First Draft that incorporates the core of both openidonnect.com proposal and OpenID Artifact Binding RC3 and abstracted.

-02

Catch up to OAuth 2.0 d15. Replaced JSS and JSE to JWS and JWE. Section grouping and reorganizations. Added more contributors.

-03

Combined with Session Management. Moved "openid" back to Token Endpoint. Renaming the sections according to the Endpoint names. Rewrote intro to the Messages section to be more approacheable.

-04

To keep the ID Token small so that it fits cookie more easily, moved OPTIONAL parameters to UserInfo endpoint response.

-05

Reference OAuth 2.0 now since it will be stable.

-06

Claims Syntax. Session Token. Misc.

13. Normative References

Authors' Addresses