Draft N. Sakimura NRI J. Bradley Ping Identity M. Jones Microsoft E. Jay Illumila December 18, 2013 OpenID Connect Discovery 1.0 - draft 20 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 specification defines a mechanism for an OpenID Connect Relying Party to discover the End-User's OpenID Provider and obtain information needed to interact with it, including its OAuth 2.0 endpoint locations. Sakimura, et al. [Page 1] OpenID Connect Discovery 1.0 December 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. OpenID Provider Issuer Discovery . . . . . . . . . . . . . . . 5 2.1. Identifier Normalization . . . . . . . . . . . . . . . . . 6 2.1.1. User Input Identifier Types . . . . . . . . . . . . . 6 2.1.2. Normalization Steps . . . . . . . . . . . . . . . . . 7 2.2. Non-Normative Examples . . . . . . . . . . . . . . . . . . 8 2.2.1. User Input using E-Mail Address Syntax . . . . . . . . 8 2.2.2. User Input using URL Syntax . . . . . . . . . . . . . 9 2.2.3. User Input using Hostname and Port Syntax . . . . . . 9 2.2.4. User Input using "acct" URI Syntax . . . . . . . . . . 10 3. OpenID Provider Metadata . . . . . . . . . . . . . . . . . . . 12 4. Obtaining OpenID Provider Configuration Information . . . . . 17 4.1. OpenID Provider Configuration Request . . . . . . . . . . 17 4.2. OpenID Provider Configuration Response . . . . . . . . . . 17 4.3. OpenID Provider Configuration Validation . . . . . . . . . 19 5. String Operations . . . . . . . . . . . . . . . . . . . . . . 20 6. Implementation Considerations . . . . . . . . . . . . . . . . 21 6.1. Pre-Final IETF Specifications . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.1. TLS Requirements . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8.1. Well-Known URI Registry . . . . . . . . . . . . . . . . . 23 8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Document History . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Sakimura, et al. [Page 2] OpenID Connect Discovery 1.0 December 2013 1. Introduction OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] 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. In order for an OpenID Connect Relying Party to utilize OpenID Connect services for an End-User, the RP needs to know where the OpenID Provider is. OpenID Connect uses WebFinger [RFC7033] to locate the OpenID Provider for an End-User. This process is described in Section 2. Once the OpenID Provider has been identified, the configuration information for that OP is retrieved from a well-known location as a JSON document, including its OAuth 2.0 endpoint locations. This process is described in Section 4. 1.1. Requirements Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In the .txt version of 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. In the HTML version of this document, values to be taken literally are indicated by the use of "this fixed-width font". All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE] data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used. 1.2. Terminology This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [JWT], and the terms defined by OpenID Connect Core 1.0 [OpenID.Core] and OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. Sakimura, et al. [Page 3] OpenID Connect Discovery 1.0 December 2013 This specification also defines the following terms: Resource Entity that is the target of a request in WebFinger. Host Server where a WebFinger service is hosted. Identifier Value that uniquely characterizes an Entity in a specific context. NOTE: this document defines various kinds of Identifiers, designed for use in different contexts. Examples include URLs using the "https" scheme and e-mail addresses. 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 "Identifier", reference these defined terms. Whenever the reader encounters them, their definitions found in this section must be followed. Sakimura, et al. [Page 4] OpenID Connect Discovery 1.0 December 2013 2. OpenID Provider Issuer Discovery OpenID Provider Issuer discovery is the process of determining the location of the OpenID Provider. Issuer discovery is OPTIONAL; if a Relying Party knows the OP's Issuer location through an out-of-band mechanism, it can skip this step and proceed to Section 4. Issuer discovery requires the following information to make a discovery request: resource Identifier for the target End-User that is the subject of the discovery request. host Server where a WebFinger service is hosted. rel URI identifying the type of service whose location is being requested. OpenID Connect uses the following discoverable "rel" value in WebFinger [RFC7033]: +----------------------+--------------------------------------------+ | Rel Type | URI | +----------------------+--------------------------------------------+ | OpenID Connect | http://openid.net/specs/connect/1.0/issuer | | Issuer | | +----------------------+--------------------------------------------+ To start discovery of OpenID endpoints, the End-User supplies an Identifier to the Relying Party. The RP applies normalization rules to the Identifier to determine the Resource and Host. Then it makes an HTTP "GET" request to the Host's WebFinger [RFC7033] endpoint with the "resource" and "rel" parameters to obtain the location of the requested service. All WebFinger communication MUST utilize TLS in the manner described in Section 7.1. The Issuer location MUST be returned in the WebFinger response as the value of the "href" member of a "links" array element with "rel" member value "http://openid.net/specs/connect/1.0/issuer". (Per Section 7 of WebFinger [RFC7033], obtaining the WebFinger response may first involve following some redirects.) The returned Issuer location MUST be a URI RFC 3986 [RFC3986] with a scheme component that MUST be "https", a host component, and optionally, port and path components and no query or fragment components. Note that since the Host and Resource values determined Sakimura, et al. [Page 5] OpenID Connect Discovery 1.0 December 2013 from the user input Identifier, as described in Section 2.1, are used as input to a WebFinger request, which can return an Issuer value using a completely different scheme, host, port, and path, no relationship can be assumed between the user input Identifier string and the resulting Issuer location. 2.1. Identifier Normalization The purpose of Identifier normalization is to determine normalized Resource and Host values from the user input Identifier. These are then used as WebFinger request parameters to discover the Issuer location. The user input Identifier SHOULD be a URL or URI relative reference defined in RFC 3986 [RFC3986]. The user input Identifier MUST include the authority component. NOTE: A URI relative reference includes a string that looks like an e-mail address in the form of "userinfo@host". This is a valid authority component of a URI but excludes various possible extra strings allowed in "addr-spec" syntax of RFC 5322 [RFC5322]. The Identifier normalization rules MAY be extended by additional specifications to enable other identifier types such as telephone numbers or XRIs [XRI_Syntax_2.0] to also be used. 2.1.1. User Input Identifier Types A user input Identifier can be categorized into the following types, which require different normalization processes: 1. User input Identifiers starting with the XRI [XRI_Syntax_2.0] global context symbols ('=','@', and '!') are RESERVED. Processing of these identifiers is out of scope for this specification. 2. All other user input Identifiers MUST be treated as a URI in one of the forms "scheme "://" authority path-abempty [ "?" query ] [ "#" fragment ]" or "authority path-abempty [ "?" query ] [ "#" fragment ]" or "scheme ":" path-rootless", per RFC 3986 [RFC3986]. NOTE: The user input Identifier MAY be in the form of "userinfo@host". For the End-User, this would normally be perceived as being an e-mail address. However, it is also a valid userpart "@" host section of an "acct" URI [I-D.ietf-appsawg-acct-uri], and this specification treats it such as to exclude various extra strings allowed in "addr-spec" of RFC 5322 [RFC5322]. Sakimura, et al. [Page 6] OpenID Connect Discovery 1.0 December 2013 2.1.2. Normalization Steps A string of any other type is interpreted as a URI in one of the forms "scheme "://" authority path-abempty [ "?" query ] [ "#" fragment ]" or "authority path-abempty [ "?" query ] [ "#" fragment ]" or "scheme ":" path-rootless" per RFC 3986 [RFC3986] and is normalized according to the following rules: 1. If the user input Identifier does not have an RFC 3986 [RFC3986] scheme component, the string is interpreted as "[userinfo "@"] host [":" port] path-abempty [ "?" query ] [ "#" fragment ]" per RFC 3986 [RFC3986]. Examples are "example.com", "joe@example.com", "example.com/joe", and "example.com:8080". 2. If the userinfo and host components are present and all of the scheme, path, query, port, and fragment components are absent, the "acct" scheme is assumed. In this case, the normalized URI is formed by prefixing "acct:" to the string as the scheme. Per The 'acct' URI Scheme [I-D.ietf-appsawg-acct-uri], if there is an at-sign character ('@') in the userinfo component, it needs to be percent-encoded, as described in RFC 3986 [RFC3986]. Examples are "joe@example.com" and "Jane.Doe@example.com". 3. For all other inputs without a scheme component, the "https" scheme is assumed, and the normalized URI is formed by prefixing "https://" to the string as the scheme. Examples are "example.com", "example.com/joe", "example.com:8080", and "joe@example.com:8080". 4. When the input contains an explicit scheme such as "acct" or "https" that matches the RFC 3986 "scheme ":" path-rootless" syntax, no input normalization is performed. Examples are "https://example.com", "https://example.com/joe", "https://joe@example.com:8080", and "acct:joe@example.com". 5. If the resulting URI contains a fragment component, it MUST be stripped off, together with the fragment delimiter character "#". The WebFinger [RFC7033] Resource in this case is the resulting URI, and the WebFinger Host is the authority component. NOTE: Since the definition of "authority" in RFC 3986 [RFC3986] is "[ userinfo "@" ] host [ ":" port ]", it is legal to have a user input identifier like "userinfo@host:port", e.g., "alice@example.com:8080". Sakimura, et al. [Page 7] OpenID Connect Discovery 1.0 December 2013 2.2. Non-Normative Examples 2.2.1. User Input using E-Mail Address Syntax To find the Issuer for the given user input in the form of an e-mail address "joe@example.com", the WebFinger parameters are as follows: +---------------------+--------------------------------------------+ | WebFinger Parameter | Value | +---------------------+--------------------------------------------+ | resource | acct:joe@example.com | | | | | host | example.com | | | | | rel | http://openid.net/specs/connect/1.0/issuer | +---------------------+--------------------------------------------+ Note that in this case, the "acct:" scheme [I-D.ietf-appsawg-acct-uri] is prepended to the Identifier. The RP would make the following WebFinger request to discover the Issuer location (with line wraps within lines for display purposes only): GET /.well-known/webfinger ?resource=acct%3Ajoe%40example.com &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/jrd+json { "subject": "acct:joe@example.com", "links": [ { "rel": "http://openid.net/specs/connect/1.0/issuer", "href": "https://server.example.com" } ] } Sakimura, et al. [Page 8] OpenID Connect Discovery 1.0 December 2013 2.2.2. User Input using URL Syntax To find the Issuer for the given URL, "https://example.com/joe", the WebFinger parameters are as follows: +---------------------+--------------------------------------------+ | WebFinger Parameter | Value | +---------------------+--------------------------------------------+ | resource | https://example.com/joe | | | | | host | example.com | | | | | rel | http://openid.net/specs/connect/1.0/issuer | +---------------------+--------------------------------------------+ The RP would make the following WebFinger request to discover the Issuer location (with line wraps within lines for display purposes only): GET /.well-known/webfinger ?resource=https%3A%2F%2Fexample.com%2Fjoe &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/jrd+json { "subject": "https://example.com/joe", "links": [ { "rel": "http://openid.net/specs/connect/1.0/issuer", "href": "https://server.example.com" } ] } 2.2.3. User Input using Hostname and Port Syntax If the user input is in the form of "host:port", e.g., example.com: 8080, then it is assumed as the authority component of the URL. To find the Issuer for the given hostname, "example.com:8080", the WebFinger parameters are as follows: Sakimura, et al. [Page 9] OpenID Connect Discovery 1.0 December 2013 +---------------------+--------------------------------------------+ | WebFinger Parameter | Value | +---------------------+--------------------------------------------+ | resource | https://example.com:8080/ | | | | | host | example.com:8080 | | | | | rel | http://openid.net/specs/connect/1.0/issuer | +---------------------+--------------------------------------------+ The RP would make the following WebFinger request to discover the Issuer location (with line wraps within lines for display purposes only): GET /.well-known/webfinger ?resource=https%3A%2F%2Fexample.com%3A8080%2F &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com:8080 HTTP/1.1 200 OK Content-Type: application/jrd+json { "subject": "https://example.com:8080/", "links": [ { "rel": "http://openid.net/specs/connect/1.0/issuer", "href": "https://server.example.com" } ] } 2.2.4. User Input using "acct" URI Syntax To find the Issuer for the given user input in the form of an account URI "acct:juliet%40capulet.example@shopping.example.com", the WebFinger parameters are as follows: +--------------+----------------------------------------------------+ | WebFinger | Value | | Parameter | | +--------------+----------------------------------------------------+ | resource | acct:juliet%40capulet.example@shopping.example.com | | | | | host | shopping.example.com | | | | Sakimura, et al. [Page 10] OpenID Connect Discovery 1.0 December 2013 | rel | http://openid.net/specs/connect/1.0/issuer | +--------------+----------------------------------------------------+ The RP would make the following WebFinger request to discover the Issuer location (with line wraps within lines for display purposes only): GET /.well-known/webfinger ?resource=acct%3Ajuliet%2540capulet.example%40shopping.example.com &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: shopping.example.com HTTP/1.1 200 OK Content-Type: application/jrd+json { "subject": "acct:juliet%40capulet.example@shopping.example.com", "links": [ { "rel": "http://openid.net/specs/connect/1.0/issuer", "href": "https://server.example.com" } ] } NOTE: It is common for sites to use e-mail addresses as local identifiers for accounts at those sites, even though the domain in the e-mail address one controlled by the site. For instance, the site "example.org" might have a local account named "joe@example.com". As of the time of this writing, a discussion is ongoing among WebFinger contributors about the syntax that should be used when discovering information about such accounts with WebFinger. The current thinking seems to be that such accounts would be represented by quoting the '@' character in the userinfo component of the account identifier when constructing the "acct:" URI representing the account. Such an example is "acct:joe%40example.com@example.org". In a future version of this specification, it is possible that normalization rules will be defined allowing End-Users to input values like "joe@example.com@example.org" to initiate discovery on such accounts. Sakimura, et al. [Page 11] OpenID Connect Discovery 1.0 December 2013 3. OpenID Provider Metadata OpenID Providers have metadata describing their configuration. These OpenID Provider Metadata values are used by OpenID Connect: issuer REQUIRED. URL using the "https" scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the "iss" Claim value in ID Tokens issued from this Issuer. authorization_endpoint REQUIRED. URL of the OP's OAuth 2.0 Authorization Endpoint [OpenID.Core]. token_endpoint URL of the OP's OAuth 2.0 Token Endpoint [OpenID.Core]. This is REQUIRED unless only the Implicit Flow is used. userinfo_endpoint RECOMMENDED. URL of the OP's UserInfo Endpoint [OpenID.Core]. This URL MUST use the "https" scheme and MAY contain port, path, and query parameter components. jwks_uri REQUIRED. URL of the OP's JSON Web Key Set [JWK] document. This contains the signing key(s) the RP uses to validate signatures from the OP. The JWK Set MAY also contain the Server's encryption key(s), which are used by RPs to encrypt requests to the Server. When both signing and encryption keys are made available, a "use" (Key Use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage. Although some algorithms allow the same key to be used for both signatures and encryption, doing so is NOT RECOMMENDED, as it is less secure. The JWK "x5c" parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate. registration_endpoint RECOMMENDED. URL of the OP's Dynamic Client Registration Endpoint [OpenID.Registration]. scopes_supported RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] scope values that this server supports. The server MUST support the "openid" scope value. Servers MAY choose not to advertise some supported scope values even when this parameter is used, although those defined in [OpenID.Core] SHOULD be listed, if supported. Sakimura, et al. [Page 12] OpenID Connect Discovery 1.0 December 2013 response_types_supported REQUIRED. JSON array containing a list of the OAuth 2.0 "response_type" values that this OP supports. Dynamic OpenID Providers MUST support the "code", "id_token", and the "token id_token" Response Type values. response_modes_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 "response_mode" values that this OP supports, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]. If omitted, the default for Dynamic OpenID Providers is "["query", "fragment"]". grant_types_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Type values that this OP supports. Dynamic OpenID Providers MUST support the "authorization_code" and "implicit" Grant Type values and MAY support other Grant Types. If omitted, the default value is "["authorization_code", "implicit"]". acr_values_supported OPTIONAL. JSON array containing a list of the Authentication Context Class References that this OP supports. subject_types_supported REQUIRED. JSON array containing a list of the Subject Identifier types that this OP supports. Valid types include "pairwise" and "public". id_token_signing_alg_values_supported REQUIRED. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. The algorithm "RS256" MUST be included. The value "none" MAY be supported, but MUST NOT be used unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow). id_token_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE encryption algorithms ("alg" values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. id_token_encryption_enc_values_supported OPTIONAL. JSON array containing a list of the JWE encryption algorithms ("enc" values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. userinfo_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS [JWS] signing algorithms ("alg" values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT]. The value "none" MAY be included. Sakimura, et al. [Page 13] OpenID Connect Discovery 1.0 December 2013 userinfo_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE [JWE] encryption algorithms ("alg" values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT]. userinfo_encryption_enc_values_supported OPTIONAL. JSON array containing a list of the JWE encryption algorithms ("enc" values) [JWA] supported by the UserInfo Endpoint to encode the Claims in a JWT [JWT]. request_object_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the OP for the Request Object described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed by value (using the "request" parameter) and when it is passed by reference (using the "request_uri" parameter). Servers SHOULD support "none" and "RS256". request_object_encryption_alg_values_supported OPTIONAL. JSON array containing a list of the JWE encryption algorithms ("alg" values) supported by the OP for the Request Object described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed by value and when it is passed by reference. request_object_encryption_enc_values_supported OPTIONAL. JSON array containing a list of the JWE encryption algorithms ("enc" values) supported by the OP for the Request Object described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed by value and when it is passed by reference. token_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of Client Authentication methods supported by this Token Endpoint. The options are "client_secret_post", "client_secret_basic", "client_secret_jwt", and "private_key_jwt", as described in Section 9 of OpenID Connect Core 1.0 [OpenID.Core]. Other authentication methods MAY be defined by extensions. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749]. token_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the Token Endpoint for the signature on the JWT [JWT] used to authenticate the Client at the Token Endpoint for the "private_key_jwt" and "client_secret_jwt" authentication Sakimura, et al. [Page 14] OpenID Connect Discovery 1.0 December 2013 methods. Servers SHOULD support "RS256". The value "none" MUST NOT be used. display_values_supported OPTIONAL. JSON array containing a list of the "display" parameter values that the OpenID Provider supports. These values are described in Section 3.1.2.1 of OpenID Connect Core 1.0 [OpenID.Core]. claim_types_supported OPTIONAL. JSON array containing a list of the Claim Types that the OpenID Provider supports. These Claim Types are described in Section 5.6 of OpenID Connect Core 1.0 [OpenID.Core]. Values defined by this specification are "normal", "aggregated", and "distributed". If omitted, the implementation supports only "normal" Claims. claims_supported RECOMMENDED. JSON array containing a list of the Claim Names of the Claims that the OpenID Provider MAY be able to supply values for. Note that for privacy or other reasons, this might not be an exhaustive list. service_documentation OPTIONAL. URL of a page containing human- readable information that developers might want or need to know when using the OpenID Provider. In particular, if the OpenID Provider does not support Dynamic Client Registration, then information on how to register Clients needs to be provided in this documentation. claims_locales_supported OPTIONAL. Languages and scripts supported for values in Claims being returned, represented as a JSON array of BCP47 [RFC5646] language tag values. Not all languages and scripts are necessarily supported for all Claim values. ui_locales_supported OPTIONAL. Languages and scripts supported for the user interface, represented as a JSON array of BCP47 [RFC5646] language tag values. claims_parameter_supported OPTIONAL. Boolean value specifying whether the OP supports use of the "claims" parameter, with "true" indicating support. If omitted, the default value is "false". request_parameter_supported OPTIONAL. Boolean value specifying whether the OP supports use of the "request" parameter, with "true" indicating support. If omitted, the default value is "false". Sakimura, et al. [Page 15] OpenID Connect Discovery 1.0 December 2013 request_uri_parameter_supported OPTIONAL. Boolean value specifying whether the OP supports use of the "request_uri" parameter, with "true" indicating support. If omitted, the default value is "true". require_request_uri_registration OPTIONAL. Boolean value specifying whether the OP requires any "request_uri" values used to be pre- registered using the "request_uris" registration parameter. Pre- registration is REQUIRED when the value is "true". If omitted, the default value is "false". op_policy_uri OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about the OP's requirements on how the Relying Party can use the data provided by the OP. The registration process SHOULD display this URL to the person registering the Client if it is given. op_tos_uri OPTIONAL. URL that the OpenID Provider provides to the person registering the Client to read about OpenID Provider's terms of service. The registration process SHOULD display this URL to the person registering the Client if it is given. Additional OpenID Provider Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Session Management 1.0 [OpenID.Session]. Sakimura, et al. [Page 16] OpenID Connect Discovery 1.0 December 2013 4. Obtaining OpenID Provider Configuration Information Using the Issuer location discovered as described in Section 2 or by other means, the OpenID Provider's configuration information can be retrieved. OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string "/.well-known/openid-configuration" to the Issuer. The syntax and semantics of ".well-known" are defined in RFC 5785 [RFC5785] and apply to the Issuer value when it contains no path component. "openid-configuration" MUST point to a JSON document compliant with this specification and MUST be returned using the "application/json" content type. 4.1. OpenID Provider Configuration Request An OpenID Provider Configuration Document MUST be queried using an HTTP "GET" request at the previously specified path. The RP would make the following request to the Issuer "https://example.com" to obtain its Configuration information, since the Issuer contains no path component: GET /.well-known/openid-configuration HTTP/1.1 Host: example.com If the Issuer value contains a path component, any terminating "/" MUST be removed before appending "/.well-known/openid-configuration". The RP would make the following request to the Issuer "https://example.com/issuer1" to obtain its Configuration information, since the Issuer contains a path component: GET /issuer1/.well-known/openid-configuration HTTP/1.1 Host: example.com Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations. This use of ".well-known" is for supporting multiple issuers per host; unlike its use in RFC 5785 [RFC5785], it does not provide general information about the host. 4.2. OpenID Provider Configuration Response The response is a set of Claims about the OpenID Provider's configuration, including all necessary endpoints and public key Sakimura, et al. [Page 17] OpenID Connect Discovery 1.0 December 2013 location information. A successful response MUST use the 200 OK HTTP status code and return a JSON object using the "application/json" content type that contains a set of Claims as its members that are a subset of the Metadata values defined in Section 3. Other Claims MAY also be returned. Claims that return multiple values are represented as JSON arrays. Claims with zero elements MUST be omitted from the response. An error response uses the applicable HTTP status code value. The following is a non-normative example response: HTTP/1.1 200 OK Content-Type: application/json { "issuer": "https://server.example.com", "authorization_endpoint": "https://server.example.com/connect/authorize", "token_endpoint": "https://server.example.com/connect/token", "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"], "token_endpoint_auth_signing_alg_values_supported": ["RS256", "ES256"], "userinfo_endpoint": "https://server.example.com/connect/userinfo", "check_session_iframe": "https://server.example.com/connect/check_session", "end_session_endpoint": "https://server.example.com/connect/end_session", "jwks_uri": "https://server.example.com/jwks.json", "registration_endpoint": "https://server.example.com/connect/register", "scopes_supported": ["openid", "profile", "email", "address", "phone", "offline_access"], "response_types_supported": ["code", "code id_token", "id_token", "token id_token"], "acr_values_supported": ["urn:mace:incommon:iap:silver", "urn:mace:incommon:iap:bronze"], "subject_types_supported": ["public", "pairwise"], "userinfo_signing_alg_values_supported": Sakimura, et al. [Page 18] OpenID Connect Discovery 1.0 December 2013 ["RS256", "ES256", "HS256"], "userinfo_encryption_alg_values_supported": ["RSA1_5", "A128KW"], "userinfo_encryption_enc_values_supported": ["A128CBC-HS256", "A128GCM"], "id_token_signing_alg_values_supported": ["RS256", "ES256", "HS256"], "id_token_encryption_alg_values_supported": ["RSA1_5", "A128KW"], "id_token_encryption_enc_values_supported": ["A128CBC-HS256", "A128GCM"], "request_object_signing_alg_values_supported": ["none", "RS256", "ES256"], "display_values_supported": ["page", "popup"], "claim_types_supported": ["normal", "distributed"], "claims_supported": ["sub", "iss", "auth_time", "acr", "name", "given_name", "family_name", "nickname", "profile", "picture", "website", "email", "email_verified", "locale", "zoneinfo", "http://example.info/claims/groups"], "claims_parameter_supported": true, "service_documentation": "http://server.example.com/connect/service_documentation.html", "ui_locales_supported": ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"] } 4.3. OpenID Provider Configuration 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. The "issuer" value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the "iss" Claim value in ID Tokens issued from this Issuer. Sakimura, et al. [Page 19] OpenID Connect Discovery 1.0 December 2013 5. String Operations Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the member names in the provider configuration response might be compared to specific member names such as "issuer". Comparing Unicode strings, however, has significant security implications. Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below: 1. Remove any JSON applied escaping to produce an array of Unicode code points. 2. Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against. 3. Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison. Sakimura, et al. [Page 20] OpenID Connect Discovery 1.0 December 2013 6. Implementation Considerations This specification defines features used by both Relying Parties and OpenID Providers that choose to implement Discovery. All of these Relying Parties and OpenID Providers MUST implement the features that are listed in this specification as being "REQUIRED" or are described with a "MUST". No other implementation considerations for implementations of Discovery are defined by this specification. 6.1. Pre-Final IETF Specifications Implementers should be aware that this specification uses several IETF specifications that are not yet final specifications. Those specifications are: o JSON Web Token (JWT) draft -13 [JWT] o JSON Web Signature (JWS) draft -18 [JWS] o JSON Web Encryption (JWE) draft -18 [JWE] o JSON Web Key (JWK) draft -18 [JWK] o JSON Web Algorithms draft -18 [JWA] o The 'acct' URI Scheme draft -06 [I-D.ietf-appsawg-acct-uri] While every effort will be made to prevent breaking changes to these specifications, should they occur, OpenID Connect implementations should continue to use the specifically referenced draft versions above in preference to the final versions, unless using a possible future OpenID Connect profile or specification that updates some or all of these references. Sakimura, et al. [Page 21] OpenID Connect Discovery 1.0 December 2013 7. Security Considerations 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. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] is the most widely deployed version, and will give the broadest interoperability. To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection. Whenever TLS is used, a TLS server certificate check MUST be performed, per RFC 6125 [RFC6125]. Sakimura, et al. [Page 22] OpenID Connect Discovery 1.0 December 2013 8. IANA Considerations 8.1. Well-Known URI Registry This specification registers the well-known URI defined in Section 4 in the IANA Well-Known URI registry defined in RFC 5785 [RFC5785]. 8.1.1. Registry Contents o URI suffix: "openid-configuration" o Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net o Specification document: Section 4 of this document o Related information: (none) Sakimura, et al. [Page 23] OpenID Connect Discovery 1.0 December 2013 9. References 9.1. Normative References [I-D.ietf-appsawg-acct-uri] Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf-appsawg-acct-uri-06 (work in progress), July 2013. [JWA] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-json-web-algorithms (work in progress), November 2013. [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web Encryption (JWE)", draft-ietf-jose-json-web-encryption (work in progress), November 2013. [JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-key (work in progress), November 2013. [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", draft-ietf-jose-json-web-signature (work in progress), November 2013. [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", draft-ietf-oauth-json-web-token (work in progress), November 2013. [OAuth.Responses] de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, "OAuth 2.0 Multiple Response Type Encoding Practices", December 2013. [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", December 2013. [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0", December 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Sakimura, et al. [Page 24] OpenID Connect Discovery 1.0 December 2013 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. [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, March 2011. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, September 2013. [USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode Normalization Forms", Unicode Standard Annex 15, 09 2009. 9.2. Informative References [OpenID.Session] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, "OpenID Connect Session Management 1.0", December 2013. [XRI_Syntax_2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier (XRI) Syntax V2.0", November 2005. Sakimura, et al. [Page 25] OpenID Connect Discovery 1.0 December 2013 Appendix A. Acknowledgements The OpenID Community would like to thank the following people for their contributions to this specification: Andrew Arnott (andarno@microsoft.com), Microsoft Dirk Balfanz (balfanz@google.com), Google Casper Biering (cb@peercraft.com), Peercraft John Bradley (ve7jtb@ve7jtb.com), Ping Identity Johnny Bufu (jbufu@janrain.com), Janrain Brian Campbell (bcampbell@pingidentity.com), Ping Identity Blaine Cook (romeda@gmail.com), Independent Breno de Medeiros (breno@google.com), Google Pamela Dingle (pdingle@pingidentity.com), Ping Identity Vladimir Dzhuvinov (vladimir@nimbusds.com), Nimbus Directory Services George Fletcher (george.fletcher@corp.aol.com), AOL Dick Hardt (dick.hardt@gmail.com), Independent Roland Hedberg (roland.hedberg@adm.umu.se), University of Umea Edmund Jay (ejay@mgi1.com), Illumila Michael B. Jones (mbj@microsoft.com), Microsoft Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom Nov Matake (nov@matake.jp), Independent Chuck Mortimore (cmortimore@salesforce.com), Salesforce Anthony Nadalin (tonynad@microsoft.com), Microsoft Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom John Panzer (jpanzer@google.com), Google Sakimura, et al. [Page 26] OpenID Connect Discovery 1.0 December 2013 Justin Richer (jricher@mitre.org), MITRE Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd. Owen Shepherd (owen.shepherd@e43.eu), Independent Andreas Aekre Solberg (andreas.solberg@uninett.no), UNINET Kick Willemse (k.willemse@evidos.nl), Evidos B.V. Sakimura, et al. [Page 27] OpenID Connect Discovery 1.0 December 2013 Appendix B. Notices Copyright (c) 2013 The OpenID Foundation. The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non- infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification. Sakimura, et al. [Page 28] OpenID Connect Discovery 1.0 December 2013 Appendix C. Document History [[ To be removed from the final specification ]] -20 o Applied Discovery review comments from George Fletcher and Torsten Lodderstedt. o Incorporated terms defined by the JWT specification. o Applied proofreading corrections by Michael B. Jones. -19 o Harmonized statements about functionality that servers must support with Server MTI statements in Core. o Fixed #889 - Added "response_modes_supported". o Fixed #899 - Removed urn:ietf:params:oauth:grant-type:jwt-bearer. o Added Pre-Final IETF Specifications section. -18 o Fixed #868 - Clarified when "alg":"none" can and cannot be used. o Replaced uses of the OpenID Connect Messages and OpenID Connect Standard specifications with OpenID Connect Core. o Fixed #885 - Removed normative Session Management definitions. When Session Management is supported, the Session Management discovery parameters defined in that specification are used. -17 o Required that the OpenID Provider configuration information be returned using the "application/json" content type. o Updated the acct: URI reference to draft-ietf-appsawg-acct-uri-05. o Updated normative text so that e-mail addresses use the acct: scheme. o Added an example for the acct: scheme. Sakimura, et al. [Page 29] OpenID Connect Discovery 1.0 December 2013 o Fixed #856 - Updated normative text to clarify that no input normalization is performed when the input contains an explicit scheme such as "acct" that matches the RFC 3986 "scheme ":" path-rootless" syntax. o Fixed #859 - Added IMPORTANT NOTE TO READERS about the terminology definitions being a normative part of the specification. -16 o Removed the "version" discovery element. o Added a note about the future possibility of acct: URIs like "acct:joe%40example.com@example.org" when e-mail addresses are used as local account identifiers at sites. o Stated that the JWS Compact Serialization and the JWE Compact Serialization are always used for JWS and JWE data structures. -15 o Fixed #820 - Removed assumption that Clients that want encrypted responses also sign requests. -14 o Fixed #801 - Removed "schema" and "id" parameters to UserInfo Endpoint. -13 o Added Security Considerations section about TLS version requirements and usage. o Removed language about supporting other transport-layer mechanisms with equivalent security to TLS. o State that when any validations 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. o Change from Content-Type application/json to application/jrd+json, tracking the change made in WebFinger. o Fixed #768 - Added required "version" value to example response. o Fixed #771 - Added required "x509_url" value to example response. Sakimura, et al. [Page 30] OpenID Connect Discovery 1.0 December 2013 o Fixed #769 - Added Claim Type identifiers and definition. o Fixed #770 - Added "claims_locales_supported" and "ui_locales_supported". o Fixed #781 - Added "require_request_uri_registration" discovery parameter. o Fixed #772 - Added "op_policy_url" and "op_tos_url". o Fixed #782 - Changed uses of "_url" in identifiers to "_uri". o Fixed #703 - Added the PKIX JWK key type for X.509 certificates and consolidated the "x509_uri", "x509_encryption_uri", and "jwk_encryption_uri" parameters into a combined "jwk_uri" parameter. o Fixed #786 - Changed the name of "jwk_uri" to "jwks_uri". o Moved OP metadata list to its own section. o Added the "grant_types_supported" discovery parameter. o Added the "claims_parameter_supported", "request_parameter_supported", and "request_uri_parameter_supported" discovery parameters. o Fixed #788 - Renamed "OpenID Request Object" to "Request Object". o Use legal "acr" values in examples. -12 o Made the OpenID Foundation Artifact Binding Working Group the change controller for the values registered with IANA. o Added "display_values_supported", "claim_types_supported", and "claims_supported" discovery elements, fixing issue #656. o Added Implementation Considerations section. o Fixed #656 - Changed "token_endpoint_auth_type" to "token_endpoint_auth_method" and "token_endpoint_auth_types_supported" to "token_endpoint_auth_methods_supported". o Fixed #697 - Added "service_documentation" to enable OPs not supporting dynamic registration to say how to register clients. Sakimura, et al. [Page 31] OpenID Connect Discovery 1.0 December 2013 o Fixed #698 - Inconsistent use of articles. o Fixed #628 - Defined REQUIRED, RECOMMENDED, and OPTIONAL discovery elements. o Naming consistency changes. Renamed "check_session_iframe_url" to "check_session_iframe" and "end_session_endpoint_url" back to "end_session_endpoint". o Fixed #705 - Switched from using Simple Web Discovery to WebFinger. This also means that Identifiers using e-mail address syntax are prefixed by the "acct:" scheme when passed as "resource" parameters to WebFinger. -11 o Fixed #687 - Inconsistency between "user_id" and "prn" claims. The fix changed these names: user_id -> sub, user_id_types_supported -> subject_types_supported, user_id_type -> subject_type, and prn -> sub. o Renamed "acrs_supported" to "acr_values_supported" for naming consistency. o Fixed #676 Allow port number to be specified for e-mail syntax identifiers. o Improved the fix for #625 Scheme extraction. o Clarified that "jwk_url" and "jwk_encryption_url" refer to documents containing JWK Sets - not single JWK keys. -10 o Fixed #621 Changed Identifier definition o Fixed #625 Scheme extraction o Fixed #652 Identifier normalization o Fixed #640 Added check_session_endpoint and end_session_endpoint o Fixed #627 Configuration response must be 200 OK o updated OAuth reference o Clarify the use of .well-known as part of a path for multi-tenant Sakimura, et al. [Page 32] OpenID Connect Discovery 1.0 December 2013 o Fixes #665 Add client_secret_jwt to token_endpoint_auth_algs_supported o Fixed #614 - Discovery - 3.2 Distinguishing between signature and integrity parameters for HMAC algorithms. This fix tracks the parameter changes made to the JWE spec in draft-ietf-jose-json-web-encryption-06. It deletes the parameters {userinfo,id_token}_encrypted_response_int. It replaces the parameters {userinfo,id_token,request_object,token_endpoint}_algs_supported with {userinfo,id_token,request_object,token_endpoint}_signing_alg _values_supported and {userinfo,id_token,request_object,token_endp oint}_encryption_{alg,enc}_values_supported. o Fixed #666 - JWS signature validation vs. verification. o Removed section on Redirection, since it was removed from Simple Web Discovery in favor of the "simple-web-discovery" domain prefix. o Referenced OAuth 2.0 RFC -- RFC 6749. -09 o Removed Check ID Endpoint, per issue #570 o Added PAPE Reference to the Informative References, per issue #574 o Added "id_token" response type as being MTI for OpenID Providers o Changed default OpenID Request Object signing algorithm to RS256, per issue #571 o Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token) -08 o Remove the no path component restriction from issuer, per issue #513 o Updated Notices o Updated References -07 Sakimura, et al. [Page 33] OpenID Connect Discovery 1.0 December 2013 o Rename iso29115_supported to acrs_supported o Rename jwk_document to jwk_url o specify full email address to be used for the principal parameter o Added token_endpoint_auth_types_supported for list of Token Endpoint authentication types o Added token_endpoint_auth_algs_supported for Token Endpoint supported authentication algorithms o Added 'pairwise' and 'public' to supported identifier types o Added valid signature and encryption algorithms for OpenID Request Object o Added URLs for JWK and X509 encryption keys o Use RFC 6125 to verify TLS endpoints o Removed fallback mechanism when discovery endpoint is unreachable o Removed Account URI scheme o Changed 'contact' to 'contacts', 'redirect_uri' to 'redirect_uris' o Added section about string comparison rules needed o Allows extensions to identifier normalization via specifications o Clarifies the host in a URL o Update John Bradley email and affiliation for Implementer's Draft o Change flows_supported to response_types_supported o Register openid-configuration .well-known path in IANA Considerations o Corrected instances of x509_url_encryption to x509_encryption_url and jwk_url_encryption to jwk_encryption_url -06 o Changed Check Session Endpoint to Check ID Endpoint to match Basic. Sakimura, et al. [Page 34] OpenID Connect Discovery 1.0 December 2013 o Changed certs_url to x509_url to match registration and JWE format. -05 o Ticket #46 Added text to 3.3 o Deleted duplicate check session endpoint from 4.2 o Ticket #40 Added clarification of issuer url to 4.2 o Ticket #39 Cleaned up issuer examples and added verification text. -04 o Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard". o Numerous cleanups, including updating references. -03 o Corrected examples. -02 o Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call. -01 o Incorporate working group decisions from 5-Jul-11 spec call. o Consistency and cleanup pass, including removing unused references. -00 o Initial version based upon former openid-connect-swd-1_0 spec. Sakimura, et al. [Page 35] OpenID Connect Discovery 1.0 December 2013 Authors' Addresses Nat Sakimura Nomura Research Institute, Ltd. Email: n-sakimura@nri.co.jp URI: http://nat.sakimura.org/ John Bradley Ping Identity Email: ve7jtb@ve7jtb.com URI: http://www.thread-safe.com/ Michael B. Jones Microsoft Email: mbj@microsoft.com URI: http://self-issued.info/ Edmund Jay Illumila Email: ejay@mgi1.com Sakimura, et al. [Page 36]