TOC 
DraftN. Sakimura
 NAT.Consulting
 J. Bradley
 Yubico
 M. Jones
 Self-Issued Consulting
 B. de Medeiros
 Google
 C. Mortimore
 Disney
 December 15, 2023


OpenID Connect Implicit Client Implementer's Guide 1.0 - draft 30

Abstract

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables 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 OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the OpenID Connect Core 1.0 specification that is designed to be easy to read and implement for basic Web-based Relying Parties using the OAuth 2.0 Implicit Flow. This specification intentionally duplicates content from the Core specification to provide a self-contained implementer's guide for basic Web-based Relying Parties using the OAuth Implicit Flow.

OpenID Providers and non-Web-based applications should instead consult the Core specification.



Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
    1.2.  Terminology
    1.3.  Overview
2.  Protocol Elements
    2.1.  Implicit Flow
        2.1.1.  Client Prepares Authentication Request
            2.1.1.1.  Request Parameters
        2.1.2.  Client Sends Request to Authorization Server
        2.1.3.  Authorization Server Authenticates End-User
        2.1.4.  Authorization Server Obtains End-User Consent/Authorization
        2.1.5.  Authorization Server Sends End-User Back to Client
            2.1.5.1.  End-User Grants Authorization
            2.1.5.2.  End-User Denies Authorization or Invalid Request
            2.1.5.3.  Redirect URI Fragment Handling
    2.2.  ID Token
        2.2.1.  ID Token Validation
        2.2.2.  Access Token Validation
    2.3.  UserInfo Endpoint
        2.3.1.  UserInfo Request
        2.3.2.  Successful UserInfo Response
        2.3.3.  UserInfo Error Response
    2.4.  Scope Values
    2.5.  Standard Claims
        2.5.1.  Address Claim
        2.5.2.  Claims Languages and Scripts
        2.5.3.  Claim Stability and Uniqueness
3.  Self-Issued OpenID Provider
    3.1.  Self-Issued OpenID Provider Discovery
    3.2.  Self-Issued OpenID Provider Registration
        3.2.1.  Providing Information with the "registration" Request Parameter
    3.3.  Self-Issued OpenID Provider Request
    3.4.  Self-Issued OpenID Provider Response
    3.5.  Self-Issued ID Token Validation
4.  Serializations
    4.1.  Query String Serialization
    4.2.  Form Serialization
5.  String Operations
6.  Implementation Considerations
    6.1.  Discovery and Registration
7.  Security Considerations
    7.1.  TLS Requirements
8.  Privacy Considerations
    8.1.  Personally Identifiable Information
    8.2.  Data Access Monitoring
    8.3.  Correlation
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
§  Authors' Addresses




 TOC 

1.  Introduction

This OpenID Connect Implicit Client Implementer's Guide 1.0 contains a subset of the OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” December 2023.) [OpenID.Core] specification that is designed to be easy to read and implement for basic Web-based Relying Parties using the OAuth [RFC6749] (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) Implicit Flow. This specification intentionally duplicates content from the Core specification to provide a self-contained implementer's guide for basic Web-based Relying Parties using the OAuth Implicit Flow. Should there be any conflicts between the contents of this implementer's guide and the OpenID Connect Core specification, the latter takes precedence.

See the OpenID Connect Basic Client Implementer's Guide 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Implementer's Guide 1.0,” December 2023.) [OpenID.Basic] for a related guide for basic Web-based Relying Parties using the OAuth authorization_code grant type. OpenID Providers and non-Web-based applications should instead consult the Core specification. This guide omits implementation and security considerations for OpenID Providers and non-Web-based applications.

As background, the OAuth 2.0 Authorization Framework (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] and OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] specifications provide a general framework for third-party applications to obtain and use limited access to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. Readers are expected to be familiar with these specifications.

OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by Clients by including the openid scope value in the Authorization Request. An Authorization Request using these extensions is called an Authentication Request.

Information about the authentication performed is returned in a JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] called an ID Token (see Section 2.2 (ID Token)). OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs). OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs).

This specification assumes that the Relying Party has already obtained configuration information about the OpenID Provider, including its Authorization Endpoint location. This information is normally obtained via Discovery, as described in OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” December 2023.) [OpenID.Discovery], or may be obtained via other mechanisms.

Likewise, this specification assumes that the Relying Party has already obtained sufficient credentials and provided information needed to use the OpenID Provider. This is normally done via Dynamic Registration, as described in OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2023.) [OpenID.Registration], or may be obtained via other mechanisms.



 TOC 

1.1.  Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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.).

In the .txt version of this specification, 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. In the HTML version of this specification, values to be taken literally are indicated by the use of this fixed-width font.

All uses of JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] data structures in this specification utilize the JWS Compact Serialization; the JWS JSON Serialization is not used.

When the RFC 2119 language applies to the behavior of OpenID Providers, it is in this specification for explanatory value to help Client implementers understand the expected behavior of OpenID Providers.



 TOC 

1.2.  Terminology

This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Identifier", "Client Secret", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749], the terms "Claim Name", "Claim Value", "JSON Web Token (JWT)", and "JWT Claims Set" defined by JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT], the terms "Header Parameter" and "JOSE Header" defined by JSON Web Signature (JWS) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS], and the term "User Agent" defined by RFC 7230 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” June 2014.) [RFC7230].

This specification also defines the following terms:

Authentication
Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.
Authentication Request
OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the Client, which is an OpenID Connect Relying Party.
Claim
Piece of information asserted about an Entity.
Claims Provider
Server that can return Claims about an Entity.
End-User
Human participant.
Entity
Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity.
ID Token
JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT] that contains Claims about the Authentication event. It MAY contain other Claims.
Identifier
Value that uniquely characterizes an Entity in a specific context.
Issuer
Entity that issues a set of Claims.
Issuer Identifier
Verifiable Identifier for an Issuer. An Issuer Identifier is a case-sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
OpenID Provider (OP)
OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User.
Pairwise Pseudonymous Identifier (PPID)
Identifier that identifies the Entity to a Relying Party that cannot be correlated with the Entity's PPID at another Relying Party.
Personally Identifiable Information (PII)
Information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates.
Relying Party (RP)
OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.
Self-Issued OpenID Provider
Personal, self-hosted OpenID Provider that issues self-signed ID Tokens.
Subject Identifier
Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.
UserInfo Endpoint
Protected Resource that, when presented with an Access Token by the Client, returns authorized information about the End-User represented by the corresponding Authorization Grant.
Validation
Process intended to establish the soundness or correctness of a construct.
Verification
Process intended to test or prove the truth or accuracy of a fact or value.
Voluntary Claim
Claim specified by the Client as being useful but not Essential for the specific task requested by the End-User.

IMPORTANT NOTE TO READERS: The terminology definitions in this section are a normative portion of this specification, imposing requirements upon implementations. All the capitalized words in the text of this specification, such as "Issuer Identifier", reference these defined terms. Whenever the reader encounters them, their definitions found in this section must be followed.



 TOC 

1.3.  Overview

The OpenID Connect protocol, in abstract, follows the following steps.

  1. The RP (Client) sends a request to the OpenID Provider (OP).
  2. The OP authenticates the End-User and obtains authorization.
  3. The OP responds with an ID Token and usually an Access Token.
  4. The RP can send a request with the Access Token to the UserInfo Endpoint.
  5. The UserInfo Endpoint returns Claims about the End-User.

These steps are illustrated in the following diagram:

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+


 TOC 

2.  Protocol Elements

Authentication Requests can follow one of three paths: the Authorization Code Flow, the Implicit Flow, or the Hybrid Flow. The Authorization Code Flow is intended for Clients that can securely maintain a Client Secret between themselves and the Authorization Server, whereas the Implicit Flow is intended for Clients that cannot. However, the Authorization Code flow is sometimes also used by Native applications and other Clients in order to be able to obtain a Refresh Token, even when they cannot ensure the secrecy of the Client Secret value. The Hybrid Flow combines aspects of the Authorization Code Flow and the Implicit Flow. It enables Clients to obtain an ID Token optionally an Access Token with only one round trip to the Authorization Server, possibly minimizing latency, while still enabling Clients to later get tokens from the Token Endpoint -- especially a Refresh Token.

This specification only provides information that is sufficient for basic Clients using the Implicit Flow.



 TOC 

2.1.  Implicit Flow

The Implicit Flow consists of the following steps:

  1. Client prepares an Authentication Request containing the desired request parameters.
  2. Client sends the request to the Authorization Server.
  3. Authorization Server authenticates the End-User.
  4. Authorization Server obtains End-User Consent/Authorization.
  5. Authorization Server sends the End-User back to the Client with an ID Token and, if requested, an Access Token.
  6. Client validates the tokens and retrieves the End-User's Subject Identifier.



 TOC 

2.1.1.  Client Prepares Authentication Request

When the RP wishes to Authenticate the End-User or determine whether the End-User is already Authenticated, the Client prepares an Authentication Request to be sent to the Authorization Endpoint.

Communication with the Authorization Endpoint MUST utilize TLS. See Section 7.1 (TLS Requirements) for more information on using TLS.

Clients MAY construct the request using the HTTP GET or the HTTP POST method as defined in RFC 7231 (Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” June 2014.) [RFC7231].

If using the HTTP GET method, the parameters are serialized using the Query String Serialization, per Section 4.1 (Query String Serialization). If using the HTTP POST method, the request parameters are added to the HTTP request entity-body using the application/x-www-form-urlencoded format as defined by [W3C.SPSD‑html401‑20180327] (, “HTML 4.01 Specification,” March 2018.).

The following is a non-normative example of an Authentication Request URL (with line wraps within values for display purposes only):

  https://server.example.com/authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj


 TOC 

2.1.1.1.  Request Parameters

This subset of OpenID Connect uses the following OAuth 2.0 request parameters:

response_type
REQUIRED. This value consists of id_token and token, as a space-delimited list. This requests that both an Access Token and an ID Token be returned from the Authorization Endpoint, as specified in OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.) [OAuth.Responses].
client_id
REQUIRED. OAuth 2.0 Client Identifier valid at the Authorization Server.
scope
REQUIRED. OpenID Connect requests MUST contain the openid scope value. OPTIONAL scope values of profile, email, address, phone, and offline_access are also defined. See Section 2.4 (Scope Values) for more about the scope values defined by this specification.
redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) (Simple String Comparison). The Redirection URI MUST NOT use the http scheme unless the Client is a native application, in which case it MAY use the http scheme with localhost or the IP loopback literals 127.0.0.1 or [::1] as the hostname.
state
RECOMMENDED. Opaque value used to maintain state between the request and the callback. Typically, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie.

This specification also defines the following request parameters:

nonce
REQUIRED. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values. One method to achieve this is to store a cryptographically random value in HTML5 local storage and use a cryptographic hash of the value as the nonce parameter. In that case, the nonce in the returned ID Token is compared to the hash of the value in local storage to detect ID Token replay by third parties.
display
OPTIONAL. ASCII [RFC20] (Cerf, V., “ASCII format for Network Interchange,” October 1969.) string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User. The defined values are:
page
The Authorization Server SHOULD display the authentication and consent UI consistent with a full User Agent page view. If the display parameter is not specified, this is the default display mode.
popup
The Authorization Server SHOULD display the authentication and consent UI consistent with a popup User Agent window. The popup User Agent window should be of an appropriate size for a login-focused dialog and should not obscure the entire window that it is popping up over.
touch
The Authorization Server SHOULD display the authentication and consent UI consistent with a device that leverages a touch interface.
wap
The Authorization Server SHOULD display the authentication and consent UI consistent with a "feature phone" type display.
The Authorization Server MAY also attempt to detect the capabilities of the User Agent and present an appropriate display.
If an OP receives a display value outside the set defined above that it does not understand, it MAY return an error or it MAY ignore it; in practice, not returning errors for not-understood values will help facilitate phasing in extensions using new display values.
prompt
OPTIONAL. Space-delimited, case-sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The defined values are:
none
The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be login_required, interaction_required. This can be used as a method to check for existing authentication and/or consent.
login
The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically login_required.
consent
The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required.
select_account
The Authorization Server SHOULD prompt the End-User to select a user account. This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for. If it cannot obtain an account selection choice made by the End-User, it MUST return an error, typically account_selection_required.
The prompt parameter can be used by the Client to make sure that the End-User is still present for the current session or to bring attention to the request. If this parameter contains none with any other value, an error is returned.
If an OP receives a prompt value outside the set defined above that it does not understand, it MAY return an error or it MAY ignore it; in practice, not returning errors for not-understood values will help facilitate phasing in extensions using new prompt values.
max_age
OPTIONAL. Maximum Authentication Age. Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User. When max_age is used, the ID Token returned MUST include an auth_time Claim Value. Note that max_age=0 is equivalent to prompt=login.
ui_locales
OPTIONAL. End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] language tag values, ordered by preference. For instance, the value "fr-CA fr en" represents a preference for French as spoken in Canada, then French (without a region designation), followed by English (without a region designation). An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.
claims_locales
OPTIONAL. End-User's preferred languages and scripts for Claims being returned, represented as a space-separated list of BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] language tag values, ordered by preference. An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.
id_token_hint
OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.
login_hint
OPTIONAL. Hint to the Authorization Server about the login identifier the End-User might use to log in (if necessary). This hint can be used by an RP if it first asks the End-User for their e-mail address (or other identifier) and then wants to pass that value as a hint to the discovered authorization service. It is RECOMMENDED that the hint value match the value used for discovery. This value MAY also be a phone number in the format specified for the phone_number Claim. The use of this parameter is left to the OP's discretion.
acr_values
OPTIONAL. Requested Authentication Context Class Reference values. Space-separated string that specifies the acr values that the Authorization Server is being requested to use for processing this authentication request, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value, as specified in Section 2.2 (ID Token). The acr Claim is requested as a Voluntary Claim by this parameter.
registration
OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration, as specified in Section 3.2.1 (Providing Information with the "registration" Request Parameter).



 TOC 

2.1.2.  Client Sends Request to Authorization Server

Having constructed the Authentication Request, the Client sends it to the Authorization Endpoint using HTTPS.

The following is a non-normative example HTTP 302 redirect response by the Client, which triggers the User Agent to make an Authentication Request to the Authorization Endpoint (with line wraps within values for display purposes only):

  HTTP/1.1 302 Found
  Location: https://server.example.com/authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj

The following is the non-normative example request that would be sent by the User Agent to the Authorization Server in response to the HTTP 302 redirect response by the Client above (with line wraps within values for display purposes only):

  GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj HTTP/1.1
  Host: server.example.com


 TOC 

2.1.3.  Authorization Server Authenticates End-User

The Authorization Server logs in the End-User or verifies whether the End-User is logged in, depending upon the request parameter values used. If interaction with the End-User occurs over an HTTP channel, it MUST use TLS, as per Section 7.1 (TLS Requirements). The exact authentication methods used are out of scope for this specification.



 TOC 

2.1.4.  Authorization Server Obtains End-User Consent/Authorization

The Authorization Server obtains an authorization decision for the requested Claims. This can be done by presenting the End-User with a dialogue that enables the End-User to recognize what is being consenting to and grant consent or by establishing consent via other means (for example, via previous administrative consent).

The openid scope value declares that this OAuth 2.0 request is an OpenID Connect request. Use of all other scope values is OPTIONAL.



 TOC 

2.1.5.  Authorization Server Sends End-User Back to Client

Once the authorization is determined, the Authorization Server returns a successful response or an error response.



 TOC 

2.1.5.1.  End-User Grants Authorization

If the End-User grants the access request, the Authorization Server issues an Access Token and delivers it to the Client by adding the following parameters to the fragment component of the Redirection URI using the application/x-www-form-urlencoded format as defined in Section 4.2.2 of OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] and OAuth 2.0 Multiple Response Type Encoding Practices (de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.) [OAuth.Responses].

In the Implicit Flow, the entire response is returned in the fragment component of the Redirection URI, as defined in Section 4.2.2 of OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].

access_token
REQUIRED. Access Token for the UserInfo Endpoint.
token_type
REQUIRED. OAuth 2.0 Token Type value. The value MUST be Bearer, as specified in OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750], for Clients using this subset. Note that the token_type value is case insensitive.
id_token
REQUIRED. ID Token.
state
OAuth 2.0 state value. REQUIRED if the state parameter is present in the Authorization Request. Clients MUST verify that the state value is equal to the value of state parameter in the Authorization Request.
expires_in
OPTIONAL. Expiration time of the Access Token in seconds since the response was generated.

The Client can then use the Access Token to access protected resources at Resource Servers.

The following is a non-normative example (with line wraps for the display purposes only):

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=SlAV32hkKG
    &token_type=bearer
    &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
    &expires_in=3600
    &state=af0ifjsldkj


 TOC 

2.1.5.2.  End-User Denies Authorization or Invalid Request

Whenever Error Response parameters are returned, such as when End-User denies the authorization or the End-User authentication fails, the Authorization Server MUST return the error Authorization Response in the fragment component of the Redirection URI, as defined in Section 4.2.2.1 of OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]. (HTTP errors unrelated to RFC 6749 are returned to the User Agent using the appropriate HTTP status code.)



 TOC 

2.1.5.3.  Redirect URI Fragment Handling

Since response parameters are returned in the Redirection URI fragment value, the Client needs to have the User Agent parse the fragment encoded values and pass them to on to the Client's processing logic for consumption. User Agents that have direct access to cryptographic APIs may be able to be self-contained, for instance, with all Client code being written in JavaScript.

However, if the Client does not run entirely in the User Agent, one way to achieve this is to post them to a Web Server Client for validation.

The following is an example of a JavaScript file that a Client might host at its redirect_uri. This is loaded by the redirect from the Authorization Server. The fragment component is parsed and then sent by POST to a URI that will validate and use the information received.

Following is a non-normative example of a Redirect URI response:

  GET /cb HTTP/1.1
  Host: client.example.org

  HTTP/1.1 200 OK
  Content-Type: text/html

  <script type="text/javascript">

  // First, parse the query string
  var params = {}, postBody = location.hash.substring(1),
      regex = /([^&=]+)=([^&]*)/g, m;
  while (m = regex.exec(postBody)) {
    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  }

  // And send the token over to the server
  var req = new XMLHttpRequest();
  // using POST so query isn't logged
  req.open('POST', 'https://' + window.location.host +
                   '/catch_response', true);
  req.setRequestHeader('Content-Type',
                       'application/x-www-form-urlencoded');

  req.onreadystatechange = function (e) {
    if (req.readyState == 4) {
      if (req.status == 200) {
  // If the response from the POST is 200 OK, perform a redirect
        window.location = 'https://'
          + window.location.host + '/redirect_after_login'
      }
  // if the OAuth response is invalid, generate an error message
      else if (req.status == 400) {
        alert('There was an error processing the token')
      } else {
        alert('Something other than 200 was returned')
      }
    }
  };
  req.send(postBody);


 TOC 

2.2.  ID Token

The ID Token is a security token that contains Claims about the authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT) (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” May 2015.) [JWT].

The following Claims are used within the ID Token:

iss
REQUIRED. Issuer Identifier for the Issuer of the response. The iss value is a case-sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components.
sub
REQUIRED. Subject Identifier. Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case-sensitive string.
aud
REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case-sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case-sensitive string.
exp
REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value is a JSON [RFC8259] (Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” December 2017.) number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time. See RFC 3339 (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.) [RFC3339] for details regarding date/times in general and UTC in particular.
iat
REQUIRED. Time at which the JWT was issued. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.
auth_time
Time when the End-User authentication occurred. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time. When a max_age request is made then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL.
nonce
REQUIRED. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request. If present in the Authentication Request, Authorization Servers MUST include a nonce Claim in the ID Token with the Claim Value being the nonce value sent in the Authentication Request. The nonce value is a case-sensitive string.
at_hash
REQUIRED. Access Token hash value. If the ID Token is issued with an access_token in an Implicit Flow, this is REQUIRED, which is the case for this subset of OpenID Connect. Its value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the access_token value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is RS256, hash the access_token value with SHA-256, then take the left-most 128 bits and base64url-encode them. The at_hash value is a case-sensitive string.
acr
OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 (International Organization for Standardization, “ISO/IEC 29115:2013. Information technology - Security techniques - Entity authentication assurance framework,” April 2013.) [ISO29115] level 1. For historic reasons, the value "0" is used to indicate that there is no confidence that the same person is actually there. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value. An absolute URI or an RFC 6711 (Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.) [RFC6711] registered name SHOULD be used as the acr value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context specific. The acr value is a case-sensitive string.
amr
OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The amr value is an array of case-sensitive strings. Values used in the amr Claim SHOULD be from those registered in the IANA Authentication Method Reference Values registry [IANA.AMR] (IANA, “Authentication Method Reference Values,” .) established by [RFC8176] (Jones, M., Hunt, P., and A. Nadalin, “Authentication Method Reference Values,” June 2017.); parties using this claim will need to agree upon the meanings of any unregistered values used, which may be context specific.
sub_jwk
Public key used to check the signature of an ID Token issued by a Self-Issued OpenID Provider, as specified in Section 3 (Self-Issued OpenID Provider). The key is a bare key in JWK [JWK] (Jones, M., “JSON Web Key (JWK),” May 2015.) format (not an X.509 certificate value). Use of the sub_jwk Claim is REQUIRED when the OP is a Self-Issued OP and is NOT RECOMMENDED when the OP is not Self-Issued. The sub_jwk value is a JSON object.

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

ID Tokens MUST be signed using JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS]. Clients MUST validate the ID Token per Section 2.2.1 (ID Token Validation).

ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk Header Parameter fields. Instead, keys used for ID Tokens are communicated in advance using Discovery and Registration parameters.

The following is a non-normative example of the set of Claims (the JWT Claims Set) base64url-decoded from an ID Token:

  {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "at_hash": "MTIzNDU2Nzg5MDEyMzQ1Ng"
  }


 TOC 

2.2.1.  ID Token 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.

To validate the ID Token in the Authorization Response, the Client MUST do the following:

  1. The Issuer Identifier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim.
  2. The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client.
  3. The Client MUST validate the signature of the ID Token according to JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header. The Client MUST use the keys provided by the Issuer.
  4. The alg value SHOULD be RS256. Validation of tokens using other signing algorithms is described in the OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” December 2023.) [OpenID.Core] specification.
  5. The current time MUST be before the time represented by the exp Claim (possibly allowing for some small leeway to account for clock skew).
  6. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.
  7. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.
  8. If the acr Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of acr Claim Values is out of scope for this specification.
  9. When a max_age request is made, the Client SHOULD check the auth_time Claim value and request re-authentication if it determines too much time has elapsed since the last End-User authentication.



 TOC 

2.2.2.  Access Token Validation

To validate an Access Token issued with an ID Token in the Implicit Flow, the Client SHOULD do the following:

  1. Hash the octets of the ASCII representation of the access_token with the hash algorithm specified in JWA (Jones, M., “JSON Web Algorithms (JWA),” May 2015.) [JWA] for the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is RS256, the hash algorithm used is SHA-256.
  2. Take the left-most half of the hash and base64url-encode it.
  3. The value of at_hash in the ID Token MUST match the value produced in the previous step if at_hash is present in the ID Token.



 TOC 

2.3.  UserInfo Endpoint

The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. The location of the UserInfo Endpoint MUST be a URL using the https scheme, which MAY contain port, path, and query parameter components. The returned Claims are represented by a JSON object that contains a collection of name and value pairs for the Claims.

Communication with the UserInfo Endpoint MUST utilize TLS. See Section 7.1 (TLS Requirements) for more information on using TLS.



 TOC 

2.3.1.  UserInfo Request

Clients send requests to the UserInfo Endpoint to obtain Claims about the End-User using an Access Token obtained through OpenID Connect Authentication. The UserInfo Endpoint is an OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] Protected Resource that complies with the OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] specification. The request SHOULD use the HTTP GET method and the Access Token SHOULD be sent using the Authorization header field.

The following is a non-normative example of a UserInfo Request:

  GET /userinfo HTTP/1.1
  Host: server.example.com
  Authorization: Bearer SlAV32hkKG


 TOC 

2.3.2.  Successful UserInfo Response

The UserInfo Claims MUST be returned as the members of a JSON object. The response body SHOULD be encoded using UTF-8 [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.). The Claims defined in Section 2.5 (Standard Claims) can be returned, as can additional Claims not specified there.

If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value.

The sub (subject) Claim MUST always be returned in the UserInfo Response.

NOTE: Due to the possibility of token substitution attacks, the UserInfo Response is not guaranteed to be about the End-User identified by the sub (subject) element of the ID Token. The sub Claim in the UserInfo Response MUST be verified to exactly match the sub Claim in the ID Token; if they do not match, the UserInfo Response values MUST NOT be used.

The Client MUST verify that the OP that responded was the intended OP through a TLS server certificate check, 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].



 TOC 

2.3.3.  UserInfo Error Response

When an error condition occurs, the UserInfo Endpoint returns an Error Response as defined in Section 3 of OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750].



 TOC 

2.4.  Scope Values

OpenID Connect Clients use scope values as defined in Section 3.3 of OAuth 2.0 (Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] to specify what access privileges are being requested for Access Tokens. The scopes associated with Access Tokens determine what resources will be available when they are used to access OAuth 2.0 protected endpoints. For OpenID Connect, scopes can be used to request that specific sets of information be made available as Claim Values. This specification describes only the scope values used by OpenID Connect.

OpenID Connect allows additional scope values to be defined and used. Scope values used that are not understood by an implementation SHOULD be ignored.

Claims requested by the following scopes are treated by Authorization Servers as Voluntary Claims.

OpenID Connect defines the following scope values:

openid
REQUIRED. Informs the Authorization Server that the Client is making an OpenID Connect request. If the openid scope value is not present, the behavior is entirely unspecified.
profile
OPTIONAL. This scope value requests access to the End-User's default profile Claims, which are: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at.
email
OPTIONAL. This scope value requests access to the email and email_verified Claims.
address
OPTIONAL. This scope value requests access to the address Claim.
phone
OPTIONAL. This scope value requests access to the phone_number and phone_number_verified Claims.
offline_access
This scope value MUST NOT be used with the OpenID Connect Implicit Client Implementer's Guide 1.0. See the OpenID Connect Basic Client Implementer's Guide 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Implementer's Guide 1.0,” December 2023.) [OpenID.Basic] for its usage in that subset of OpenID Connect.

Multiple scope values MAY be used by creating a space-delimited, case-sensitive list of ASCII scope values.

The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 2.3.2 (Successful UserInfo Response).

In some cases, the End-User will be given the option to have the OpenID Provider decline to provide some or all information requested by RPs. To minimize the amount of information that the End-User is being asked to disclose, an RP can elect to only request a subset of the information available from the UserInfo Endpoint.

The following is a non-normative example of a scope Request:

  scope=openid profile email phone


 TOC 

2.5.  Standard Claims

This subset of OpenID Connect defines a set of standard Claims. They are returned by normal OPs in the UserInfo Response and are returned by Self-Issued OPs in the ID Token.



MemberTypeDescription
sub string Subject - Identifier for the End-User at the Issuer.
name string End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences.
given_name string Given name(s) or first name(s) of the End-User. Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters.
family_name string Surname(s) or last name(s) of the End-User. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters.
middle_name string Middle name(s) of the End-User. Note that in some cultures, people can have multiple middle names; all can be present, with the names being separated by space characters. Also note that in some cultures, middle names are not used.
nickname string Casual name of the End-User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael.
preferred_username string Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. The RP MUST NOT rely upon this value being unique, as discussed in Section 2.5.3 (Claim Stability and Uniqueness).
profile string URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User.
picture string URL of the End-User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User.
website string URL of the End-User's Web page or blog. This Web page SHOULD contain information published by the End-User or an organization that the End-User is affiliated with.
email string End-User's preferred e-mail address. Its value MUST conform to the RFC 5322 (Resnick, P., Ed., “Internet Message Format,” October 2008.) [RFC5322] addr-spec syntax. The RP MUST NOT rely upon this value being unique, as discussed in Section 2.5.3 (Claim Stability and Uniqueness).
email_verified boolean True if the End-User's e-mail address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context specific, and dependent upon the trust framework or contractual agreements within which the parties are operating.
gender string End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable.
birthdate string End-User's birthday, represented as an ISO 8601-1 (International Organization for Standardization, “ISO 8601-1:2019/Amd 1:2022. Date and time - Representations for information interchange - Part 1: Basic rules,” October 2022.) [ISO8601‑1] YYYY-MM-DD format. The year MAY be 0000, indicating that it is omitted. To represent only the year, YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just year can result in varying month and day, so the implementers need to take this factor into account to correctly process the dates.
zoneinfo string String from IANA Time Zone Database [IANA.time‑zones] (IANA, “Time Zone Database,” .) representing the End-User's time zone. For example, Europe/Paris or America/Los_Angeles.
locale string End-User's locale, represented as a BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] language tag. This is typically an ISO 639 Alpha-2 (International Organization for Standardization, “ISO 639:2023. Code for individual languages and language groups,” November 2023.) [ISO639] language code in lowercase and an ISO 3166-1 Alpha-2 (International Organization for Standardization, “ISO 3166-1:2020. Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” August 2020.) [ISO3166‑1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Relying Parties MAY choose to accept this locale syntax as well.
phone_number string End-User's preferred telephone number. E.164 (International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.) [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.) [RFC3966] extension syntax, for example, +1 (604) 555-1234;ext=5678.
phone_number_verified boolean True if the End-User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format.
address JSON object End-User's preferred postal address. The value of the address member is a JSON [RFC8259] (Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” December 2017.) structure containing some or all of the members defined in Section 2.5.1 (Address Claim).
updated_at number Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.

 Table 1: Reserved Member Definitions 

Following is a non-normative example of such a response:

  {
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "preferred_username": "j.doe",
   "email": "janedoe@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }

The UserInfo Endpoint MUST return Claims in JSON format unless a different format was specified during Registration [OpenID.Registration] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2023.). The UserInfo Endpoint MUST return a content-type header to indicate which format is being returned. The following are accepted content types:

Content-TypeFormat Returned
application/json plain text JSON object
application/jwt JSON Web Token (JWT)



 TOC 

2.5.1.  Address Claim

The Address Claim represents a physical mailing address. Implementations MAY return only a subset of the fields of an address, depending upon the information available and the End-User's privacy preferences. For example, the country and region might be returned without returning more fine-grained address information.

Implementations MAY return just the full address as a single string in the formatted sub-field, or they MAY return just the individual component fields using the other sub-fields, or they MAY return both. If both variants are returned, they SHOULD represent the same address, with the formatted address indicating how the component fields are combined.

All the address values defined below are represented as JSON strings.

formatted
Full mailing address, formatted for display or use on a mailing label. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").
street_address
Full street address component, which MAY include house number, street name, Post Office Box, and multi-line extended street address information. This field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").
locality
City or locality component.
region
State, province, prefecture, or region component.
postal_code
Zip code or postal code component.
country
Country name component.



 TOC 

2.5.2.  Claims Languages and Scripts

Human-readable Claim Values and Claim Values that reference human-readable values MAY be represented in multiple languages and scripts. To specify the languages and scripts, BCP47 (Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” September 2009.) [RFC5646] language tags are added to member names, delimited by a # character. For example, family_name#ja-Kana-JP expresses the Family Name in Katakana in Japanese, which is commonly used to index and represent the phonetics of the Kanji representation of the same name represented as family_name#ja-Hani-JP. As another example, both website and website#de Claim Values might be returned, referencing a Web site in an unspecified language and a Web site in German.

Since Claim Names are case sensitive, it is strongly RECOMMENDED that language tag values used in Claim Names be spelled using the character case with which they are registered in the IANA "Language Subtag Registry" [IANA.Language] (IANA, “Language Subtag Registry,” .). In particular, normally language names are spelled with lowercase characters, region names are spelled with uppercase characters, and scripts are spelled with mixed case characters. However, since BCP47 language tag values are case insensitive, implementations SHOULD interpret the language tag values supplied in a case-insensitive manner.

Per the recommendations in BCP47, language tag values for Claims SHOULD only be as specific as necessary. For instance, using fr might be sufficient in many contexts, rather than fr-CA or fr-FR. Where possible, OPs SHOULD try to match requested Claim locales with Claims it has. For instance, if the Client asks for a Claim with a de (German) language tag and the OP has a value tagged with de-CH (Swiss German) and no generic German value, it would be appropriate for the OP to return the Swiss German value to the Client. (This intentionally moves as much of the complexity of language tag matching to the OP as possible, to simplify Clients.)

A claims_locales request can be used to specify the preferred languages and scripts to use for the returned Claims.

When the OP determines, either through the claims_locales parameter, or by other means, that the End-User and Client are requesting Claims in only one set of languages and scripts, it is RECOMMENDED that OPs return Claims without language tags when they employ this language and script. It is also RECOMMENDED that Clients be written in a manner that they can handle and utilize Claims using language tags.



 TOC 

2.5.3.  Claim Stability and Uniqueness

The sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2.2 (ID Token). Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.

All other Claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and Issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use an email Claim Value across different End-Users at different points in time, and the claimed email address for a given End-User MAY change over time. Therefore, other Claims such as email, phone_number, and preferred_username and MUST NOT be used as unique identifiers for the End-User.



 TOC 

3.  Self-Issued OpenID Provider

OpenID Connect supports Self-Issued OpenID Providers - personal, self-hosted OPs that issue self-signed ID Tokens. Self-Issued OPs use the special Issuer Identifier https://self-issued.me.



 TOC 

3.1.  Self-Issued OpenID Provider Discovery

If the input identifier for the discovery process contains the domain self-issued.me, dynamic discovery is not performed. Instead, then the following static configuration values are used:

  {
   "authorization_endpoint":
     "openid:",
   "issuer":
     "https://self-issued.me",
   "scopes_supported":
     ["openid", "profile", "email", "address", "phone"],
   "response_types_supported":
     ["id_token"],
   "subject_types_supported":
     ["pairwise"],
   "id_token_signing_alg_values_supported":
     ["RS256"],
   "request_object_signing_alg_values_supported":
     ["none", "RS256"]
   }

NOTE: The OpenID Foundation plans to host the OpenID Provider site https://self-issued.me/, including its WebFinger service, so that performing discovery on it returns the above static discovery information, enabling RPs to not need any special processing for discovery of the Self-Issued OP. This site will be hosted on an experimental basis. Production implementations should not take a dependency upon it without a subsequent commitment by the OpenID Foundation to host the site in a manner intended for production use.



 TOC 

3.2.  Self-Issued OpenID Provider Registration

When using a Self-Issued OP, registration is not required. The Client can proceed without registration as if it had registered with the OP and obtained the following Client Registration Response:

client_id
redirect_uri value of the Client.
client_secret_expires_at
0

NOTE: The OpenID Foundation plans to host the (stateless) endpoint https://self-issued.me/registration/1.0/ that returns the response above, enabling RPs to not need any special processing for registration with the Self-Issued OP. This site will be hosted on an experimental basis. Production implementations should not take a dependency upon it without a subsequent commitment by the OpenID Foundation to host the site in a manner intended for production use.



 TOC 

3.2.1.  Providing Information with the "registration" Request Parameter

OpenID Connect defines the following Authorization Request parameter to enable Clients to provide additional registration information to Self-Issued OpenID Providers:

registration
OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration. The value is a JSON object containing Client metadata values, as defined in Section 2.1 of the OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2023.) [OpenID.Registration] specification. The registration parameter SHOULD NOT be used when the OP is not a Self-Issued OP.

None of this information is REQUIRED by Self-Issued OPs, so the use of this parameter is OPTIONAL.

The registration parameter value is represented in an OAuth 2.0 request as UTF-8 encoded JSON (which ends up being form-urlencoded when passed as an OAuth parameter).

The Registration parameters that would typically be used in requests to Self-Issued OPs are policy_uri, tos_uri, and logo_uri. If the Client uses more than one Redirection URI, the redirect_uris parameter would be used to register them.



 TOC 

3.3.  Self-Issued OpenID Provider Request

The Client sends the Authentication Request to the Authorization Endpoint with the following parameters:

response_type
REQUIRED. Constant string value id_token.
client_id
REQUIRED. Client ID value for the Client, which in this case contains the redirect_uri value of the Client. Since the Client's redirect_uri URI value is communicated as the Client ID, a redirect_uri parameter is NOT REQUIRED to also be included in the request.
scope
REQUIRED. scope parameter value, as defined in Section 2.1.1.1 (Request Parameters).
id_token_hint
OPTIONAL. id_token_hint parameter value, as specified in Section 2.1.1.1 (Request Parameters).
registration
OPTIONAL. This parameter is used by the Client to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic Client Registration, as specified in Section 3.2.1 (Providing Information with the "registration" Request Parameter).

Other parameters MAY be sent. Note that all Claims are returned in the ID Token.

The entire URL MUST NOT exceed 2048 ASCII characters.

The following is a non-normative example HTTP 302 redirect response by the Client, which triggers the User Agent to make an Authentication Request to the Self-Issued OpenID Provider (with line wraps within values for display purposes only):

  HTTP/1.1 302 Found
  Location: openid://
    ?response_type=id_token
    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj
    &nonce=n-0S6_WzA2Mj
    &registration=%7B%22logo_uri%22%3A%22https%3A%2F%2F
      client.example.org%2Flogo.png%22%7D


 TOC 

3.4.  Self-Issued OpenID Provider Response

The self-issued OpenID Provider response is the same as the normal Implicit Flow response with the following refinements. Since it is an Implicit Flow response, the response parameters will be returned in the URL fragment component.

  1. The iss (issuer) Claim Value is https://self-issued.me.
  2. A sub_jwk Claim is present, with its value being the public key used to check the signature of the ID Token.
  3. The sub (subject) Claim value is the base64url-encoded representation of the thumbprint of the key in the sub_jwk Claim. This thumbprint value is computed as the SHA-256 hash of the octets of the UTF-8 representation of a JWK constructed containing only the REQUIRED members to represent the key, with the member names sorted into lexicographic order, and with no whitespace or line breaks. For instance, when the kty value is RSA, the member names e, kty, and n are the ones present in the constructed JWK used in the thumbprint computation and appear in that order; when the kty value is EC, the member names crv, kty, x, and y are present in that order. Note that this thumbprint calculation is the same as that defined in the JWK Thumbprint [JWK.Thumbprint] (Jones, M. and N. Sakimura, “JSON Web Key (JWK) Thumbprint,” September 2015.) specification.
  4. No Access Token is returned for accessing a UserInfo Endpoint, so all Claims returned MUST be in the ID Token.



 TOC 

3.5.  Self-Issued ID Token Validation

To validate the ID Token received, the Client MUST do the following:

  1. The Client MUST validate that the value of the iss (issuer) Claim is https://self-issued.me. If iss contains a different value, the ID Token is not Self-Issued, and instead it MUST be validated according to Section 2.2.1 (ID Token Validation).
  2. The Client MUST validate that the aud (audience) Claim contains the value of the redirect_uri that the Client sent in the authentication request as an audience.
  3. The Client MUST validate the signature of the ID Token according to JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” May 2015.) [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header, using the key in the sub_jwk Claim; the key is a bare key in JWK format (not an X.509 certificate value).
  4. The alg value SHOULD be the default of RS256. It MAY also be ES256.
  5. The Client MUST validate that the sub Claim value is the base64url-encoded representation of the thumbprint of the key in the sub_jwk Claim, as specified in Section 3.4 (Self-Issued OpenID Provider Response).
  6. The current time MUST be before the time represented by the exp Claim (possibly allowing for some small leeway to account for clock skew).
  7. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.
  8. If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

The following is a non-normative example of a base64url-decoded Self-Issued ID Token (with line wraps within values for display purposes only):

  {
   "iss": "https://self-issued.me",
   "sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
   "aud": "https://client.example.org/cb",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "sub_jwk": {
     "kty":"RSA",
     "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
     4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
     tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
     QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
     SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
     w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "e":"AQAB"
    }
  }


 TOC 

4.  Serializations

A request message MAY be serialized using one of the following methods:

  1. Query String Serialization
  2. Form Serialization



 TOC 

4.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 using the application/x-www-form-urlencoded format as defined by [W3C.SPSD‑html401‑20180327] (, “HTML 4.01 Specification,” March 2018.). 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=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
  Host: server.example.com



 TOC 

4.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.SPSD‑html401‑20180327] (, “HTML 4.01 Specification,” March 2018.). 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=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb


 TOC 

5.  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 [UNICODE] (The Unicode Consortium, “The Unicode Standard,” .) 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 [USA15] (Whistler, K., “Unicode Normalization Forms,” August 2023.) 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, the ASCII space character (0x20) MUST be the only character used for this purpose.



 TOC 

6.  Implementation Considerations

This specification defines features used by Relying Parties using the OAuth Implicit Flow. These Relying Parties MUST implement the features that are listed in this specification as being "REQUIRED" or are described with a "MUST".



 TOC 

6.1.  Discovery and Registration

Some OpenID Connect installations can use a pre-configured set of OpenID Providers and/or Relying Parties. In those cases, it might not be necessary to support dynamic discovery of information about identities or services or dynamic registration of Clients.

However, if installations choose to support unanticipated interactions between Relying Parties and OpenID Providers that do not have pre-configured relationships, they SHOULD accomplish this by implementing the facilities defined in the OpenID Connect Discovery 1.0 (Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” December 2023.) [OpenID.Discovery] and OpenID Connect Dynamic Client Registration 1.0 (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2023.) [OpenID.Registration] specifications.



 TOC 

7.  Security Considerations

For security considerations other than those listed below, refer to the OpenID Connect Core 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” December 2023.) [OpenID.Core] specification.



 TOC 

7.1.  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. Implementations SHOULD follow the guidance in BCP 195 [RFC8996] (Moriarty, K. and S. Farrell, “Deprecating TLS 1.0 and TLS 1.1,” March 2021.) [RFC9325] (Sheffer, Y., Saint-Andre, P., and T. Fossati, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” November 2022.), which provides recommendations and requirements for improving the security of deployed services that use TLS.

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



 TOC 

8.  Privacy Considerations



 TOC 

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



 TOC 

8.2.  Data Access Monitoring

The Resource Server SHOULD make End-Users' UserInfo access logs available to them so that they can monitor who accessed their data.



 TOC 

8.3.  Correlation

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



 TOC 

9.  IANA Considerations

This specification makes no requests of IANA.



 TOC 

10.  References



 TOC 

10.1. Normative References

[E.164] International Telecommunication Union, “E.164: The international public telecommunication numbering plan,” 2010.
[IANA.AMR] IANA, “Authentication Method Reference Values.”
[IANA.Language] IANA, “Language Subtag Registry.”
[IANA.time-zones] IANA, “Time Zone Database.”
[ISO29115] International Organization for Standardization, “ISO/IEC 29115:2013. Information technology - Security techniques - Entity authentication assurance framework,” ISO/IEC 29115:2013, April 2013.
[ISO3166-1] International Organization for Standardization, “ISO 3166-1:2020. Codes for the representation of names of countries and their subdivisions - Part 1: Country codes,” August 2020.
[ISO639] International Organization for Standardization, “ISO 639:2023. Code for individual languages and language groups,” November 2023.
[ISO8601-1] International Organization for Standardization, “ISO 8601-1:2019/Amd 1:2022. Date and time - Representations for information interchange - Part 1: Basic rules,” October 2022.
[JWA] Jones, M., “JSON Web Algorithms (JWA),” RFC 7518, DOI 10.17487/RFC7518, May 2015.
[JWK] Jones, M., “JSON Web Key (JWK),” RFC 7517, DOI 10.17487/RFC7517, May 2015.
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” RFC 7515, DOI 10.17487/RFC7515, May 2015.
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” RFC 7519, DOI 10.17487/RFC7519, May 2015.
[OAuth.Responses] de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, “OAuth 2.0 Multiple Response Type Encoding Practices,” February 2014.
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” December 2023.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” December 2023.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2023.
[RFC20] Cerf, V., “ASCII format for Network Interchange,” STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, DOI 10.17487/RFC3339, July 2002.
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003.
[RFC3966] Schulzrinne, H., “The tel URI for Telephone Numbers,” RFC 3966, DOI 10.17487/RFC3966, December 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC5322] Resnick, P., Ed., “Internet Message Format,” RFC 5322, DOI 10.17487/RFC5322, October 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages,” BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.
[RFC6125] 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),” RFC 6125, DOI 10.17487/RFC6125, March 2011.
[RFC6711] Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” RFC 6711, DOI 10.17487/RFC6711, August 2012.
[RFC6749] Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” RFC 6749, DOI 10.17487/RFC6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, DOI 10.17487/RFC6750, October 2012.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing,” RFC 7230, DOI 10.17487/RFC7230, June 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content,” RFC 7231, DOI 10.17487/RFC7231, June 2014.
[RFC8176] Jones, M., Hunt, P., and A. Nadalin, “Authentication Method Reference Values,” RFC 8176, DOI 10.17487/RFC8176, June 2017.
[RFC8259] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format,” STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017.
[RFC8996] Moriarty, K. and S. Farrell, “Deprecating TLS 1.0 and TLS 1.1,” BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022.
[UNICODE] The Unicode Consortium, “The Unicode Standard.”
[USA15] Whistler, K., “Unicode Normalization Forms,” Unicode Standard Annex 15, August 2023.
[W3C.SPSD-html401-20180327] HTML 4.01 Specification,” W3C REC SPSD-html401-20180327, W3C SPSD-html401-20180327, March 2018.


 TOC 

10.2. Informative References

[JWK.Thumbprint] Jones, M. and N. Sakimura, “JSON Web Key (JWK) Thumbprint,” RFC 7638, DOI 10.17487/RFC7638, September 2015.
[OpenID.Basic] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Basic Client Implementer's Guide 1.0,” December 2023.


 TOC 

Appendix A.  Acknowledgements

The OpenID Community would like to thank the following people for their contributions to this specification:

Naveen Agarwal (Naveen.Agarwal@microsoft.com), Microsoft

Casper Biering (cb@peercraft.com), Peercraft

John Bradley (ve7jtb@ve7jtb.com), Yubico

Tim Bray (tbray@textuality.com), independent

Johnny Bufu (johnny.bufu@gmail.com), independent

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

Pamela Dingle (Pamela.Dingle@microsoft.com), Microsoft

George Fletcher (gffletch@aol.com), Capital One

Roland Hedberg (roland@catalogix.se), independent

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

Edmund Jay (ejay@mgi1.com), Illumila

Michael B. Jones (michael_b_jones@hotmail.com), Self-Issued Consulting

Torsten Lodderstedt (torsten@lodderstedt.net), independent

Nov Matake (nov@matake.jp), independent

Chuck Mortimore (charliemortimore@gmail.com), Disney

Anthony Nadalin (nadalin@prodigy.net), independent

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

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

David Recordon (recordond@gmail.com), independent

Justin Richer (justin@bspk.io), Bespoke Engineering

Nat Sakimura (nat@nat.consulting), NAT.Consulting

Luke Shepard (luke@lukeshepard.com), Facebook

Andreas Åkre Solberg (Andreas.Solberg@sikt.no), Sikt

Paul Tarjan (paul@paultarjan.com), Facebook



 TOC 

Appendix B.  Notices

Copyright (c) 2023 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.



 TOC 

Appendix C.  Document History

[[ To be removed from the final document ]]

-30

-29

-28

-27

-26

-25

-24

-23

-22

-21

-20

-19

-18

-17

-16

-15

-14

-13

-12

-11

-10

-09

-08

-07

-06

-05

-04

-03

-02

-01

-00



 TOC 

Authors' Addresses

  Nat Sakimura
  NAT.Consulting
Email:  nat@nat.consulting
URI:  https://nat.sakimura.org/
  
  John Bradley
  Yubico
Email:  ve7jtb@ve7jtb.com
URI:  http://www.thread-safe.com/
  
  Michael B. Jones
  Self-Issued Consulting
Email:  michael_b_jones@hotmail.com
URI:  https://self-issued.info/
  
  Breno de Medeiros
  Google
Email:  breno@google.com
URI:  https://stackoverflow.com/users/311376/breno
  
  Chuck Mortimore
  Disney
Email:  charliemortimore@gmail.com
URI:  https://twitter.com/cmort