Draft N. Sakimura NRI J. Bradley Independent M. Jones Microsoft E. Jay Illumila April 10, 2012 OpenID Connect Discovery 1.0 - draft 08 Abstract OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and RESTful manner. This specification provides a mechanism for the OpenID Connect Client to discover the user's OpenID Provider as well as the necessary endpoints used by the OpenID Connect protocol suite. Sakimura, et al. [Page 1] OpenID Connect Discovery 1.0 - draft 08 April 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Provider Discovery . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Identifier Normalization . . . . . . . . . . . . . . . . . 4 2.1.1. Identifier Type . . . . . . . . . . . . . . . . . . . 5 2.1.2. E-Mail Address . . . . . . . . . . . . . . . . . . . . 5 2.1.3. URL . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Non-Normative Examples . . . . . . . . . . . . . . . . . . 6 2.2.1. E-Mail Address . . . . . . . . . . . . . . . . . . . . 6 2.2.2. URL . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Hostname & Port . . . . . . . . . . . . . . . . . . . 7 2.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 7 3. Provider Configuration Information . . . . . . . . . . . . . . 9 3.1. Provider Configuration Request . . . . . . . . . . . . . . 9 3.2. Provider Configuration Response . . . . . . . . . . . . . 9 3.3. Provider Configuration Verification . . . . . . . . . . . 14 4. String Operations . . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 Appendix B. Notices . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Document History . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Sakimura, et al. [Page 2] OpenID Connect Discovery 1.0 - draft 08 April 2012 1. Introduction In order for an OpenID Client to utilize OpenID Connect services for a user, the Client needs to know where the OpenID Provider is. OpenID Connect uses Simple Web Discovery [SWD] to locate the OpenID Provider for an End-User. Once an OpenID Provider is identified, the endpoint and other configuration information for that OP is retrieved from a well-known location as a JSON document. 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]. Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. 1.2. Terminology This specification uses the terms "Access Token", "Refresh Token", "Authorization Code", "Authorization Grant", "Authorization Server", "Authorization Endpoint", "Client", "Client Identifier", "Client Secret", "Protected Resource", "Resource Owner", "Resource Server", and "Token Endpoint" defined by OAuth 2.0 [OAuth2.0], and the terms defined by OpenID Connect Messages 1.0 [OpenID.Messages]. This specification also defines the following terms: Principal An Entity that is the target of a request in Simple Web Discovery. Identifier An Identifier is either an "http" or "https" URI (commonly referred to as a "URL" within this document), or an account URI. This document defines various kinds of Identifiers, designed for use in different contexts. Sakimura, et al. [Page 3] OpenID Connect Discovery 1.0 - draft 08 April 2012 2. Provider Discovery OpenID Provider discovery is optional; if a Relying Party knows the OP information through an out-of-band mechanism, they can skip this step and proceed to Section 3. Provider discovery requires the following information to make a discovery request: Principal Identifier of the target End-User who is the subject of the discovery request Host Server where a Simple Web Discovery service is hosted Service URI identifying the type of service whose location is requested OpenID Connect uses the following discoverable service in Simple Web Discovery [SWD]: +----------------------+--------------------------------------------+ | Service 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 Client or Relying Party. The Client applies the normalization rules to the Identifier to extract the principal and host. Then it makes a HTTPS request to the host's Simple Web Discovery [SWD] endpoint with the "principal" and "service" parameters to obtain the location of the requested service. The Client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. What MUST be returned in the response is the "issuer". This includes URI scheme, HOST, and OPTIONALLY, port. 2.1. Identifier Normalization The purpose of normalization is to extract a normalized principal and host from the user input. This is then used as input to SWD to discover the "issuer". The user Identifier SHOULD be one of the following: Sakimura, et al. [Page 4] OpenID Connect Discovery 1.0 - draft 08 April 2012 o E-Mail address o URL 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. URLs without a "host" portion are not supported by this specification. 2.1.1. Identifier Type 1. 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. Any Identifier that contains the '@' character in any position other than the first position MUST be treated as an e-mail address. 3. All other Identifiers MUST be treated as URLs. URLs containing the '@' character must escape any '@' characters so that they are represented as %40. 2.1.2. E-Mail Address Identifiers using e-mail address syntax MUST conform to the "addr- spec" syntax of RFC 5322 [RFC5322] and MUST NOT contain any syntax designated by that specification as being obsolete. If the Identifier is an e-mail address, the SWD principal value is the entire e-mail address and the SWD host value is the "domain" portion of the "addr-spec". 2.1.3. URL A URL Identifier is normalized according to the following rules: o If the URL does not have an RFC 3986 [RFC3986] "scheme" portion, the "https" scheme is prefixed to the URL, with the "scheme" portion being separated from the "authority" portion by a "://" delimiter string. o If the URL contains a fragment portion, it MUST be stripped off together with the fragment delimiter character "#". o The resulting URL is used as the SWD principal. The SWD host value is extracted from the "authority" portion of the URL, as Sakimura, et al. [Page 5] OpenID Connect Discovery 1.0 - draft 08 April 2012 defined by RFC 3986 [RFC3986], by concatenating the "host" and "port" portions of the URL, separating them with a colon (':') character. See Section 2.2.3 (Section 2.2.3) for a non-normative example. 2.2. Non-Normative Examples 2.2.1. E-Mail Address To find the "issuer" for the given e-mail address, "joe@example.com", the SWD parameters are as follows: +---------------+--------------------------------------------+ | SWD Parameter | Value | +---------------+--------------------------------------------+ | principal | joe@example.com | | | | | host | example.com | | | | | service | http://openid.net/specs/connect/1.0/issuer | +---------------+--------------------------------------------+ Following the SWD specification, the Client would make the following request to get the discovery information: GET /.well-known/simple-web-discovery?principal=joe%40example.com&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] } 2.2.2. URL To find the "issuer" for the given URL, "https://example.com/joe", the SWD parameters are as follows: +---------------+--------------------------------------------+ | SWD Parameter | Value | +---------------+--------------------------------------------+ | principal | https://example.com/joe | | | | | host | example.com | | | | Sakimura, et al. [Page 6] OpenID Connect Discovery 1.0 - draft 08 April 2012 | service | http://openid.net/specs/connect/1.0/issuer | +---------------+--------------------------------------------+ Following the SWD specification, the Client would make the following request to get the discovery information: GET /.well-known/simple-web-discovery?principal=https%3A%2F%2Fexample.com%2Fjoe&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] } 2.2.3. Hostname & Port To find the "issuer" for the given hostname, "example.com:8080", the SWD parameters are as follows: +---------------+--------------------------------------------+ | SWD Parameter | Value | +---------------+--------------------------------------------+ | principal | https://example.com:8080/ | | | | | host | example.com:8080 | | | | | service | http://openid.net/specs/connect/1.0/issuer | +---------------+--------------------------------------------+ Following the SWD specification, the Client would make the following request to get the discovery information: GET /.well-known/simple-web-discovery?principal=https%3A%2F%2Fexample.com%3A8080%2F&service=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/json { "locations":["https://server.example.com"] } 2.3. Redirection In cases where the SWD request is to be handled at a host or location other than the one derived from the End-User's Identifier, the host Sakimura, et al. [Page 7] OpenID Connect Discovery 1.0 - draft 08 April 2012 will return a JSON object containing the new location. (Support for service redirection is a required feature of Simple Web Discovery [SWD].) To enable service level redirection, a SWD server MAY return a 200 OK to an HTTPS request with a content type of application/json (or whatever other content type has been negotiated) that contains a JSON object that contains a member pair whose name is the string "SWD_service_redirect" whose value is a JSON object with a member pair whose name is "location" and whose value is a string that encodes a URI. Optionally the JSON object value of "SWD_service_redirect" MAY also contain a member whose name is "expires" and whose value is a JSON number that encodes an integer. The "location" member identifies the URI that the caller MUST redirect all SWD requests for that domain to until the "expires" time is met. SWD requests for the redirected domain MUST be constructed by taking the URI returned in the "location" and using it as the base URI to which the SWD form arguments are then added as query parameters. The location URI MUST NOT include a query component. GET /.well-known/simple-web-discovery?principal=joe%40example.com&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.com HTTP/1.1 200 OK Content-Type: application/json { "SWD_service_redirect": { "location":"https://example.net/swd_server" } } GET /swd_server?principal=joe%40example.com&service=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer HTTP/1.1 Host: example.net HTTP/1.1 200 OK Content-Type: application/json { "locations":["https://server.example.com"] } Sakimura, et al. [Page 8] OpenID Connect Discovery 1.0 - draft 08 April 2012 3. Provider Configuration Information This step is optional. The OpenID Provider endpoints and configuration information may be obtained out-of-band. Using the "issuer" discovered in Section 2 or through direct configuration, the OpenID Provider's configuration can be retrieved. OpenID Providers 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]. "openid-configuration" MUST point to a JSON document compliant with this specification. OpenID Providers MUST support receiving SWD requests via TLS 1.2 RFC 5246 [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support other transport layer security mechanisms of equivalent security. 3.1. Provider Configuration Request An OpenID Provider Configuration Document MUST be queried using an HTTPS GET request at the previously specified path. The Client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. The Client would make the following request to the "issuer" to get the Configuration information, if 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 Client would make the following request to the "issuer" to get the Configuration information, if the "issuer" string were "https://example.com/issuer1" GET /issuer1/.well-known/openid-configuration HTTP/1.1 Host: example.com 3.2. Provider Configuration Response The response is a set of Claims about the OpenID Provider's configuration, including all necessary endpoints, supported scopes, and public key location information. The response MUST return a plain text JSON object that contains a set Sakimura, et al. [Page 9] OpenID Connect Discovery 1.0 - draft 08 April 2012 of Claims that are a subset of those defined below. Claims that return multiple values are JSON arrays. Claims with 0 elements must be omitted from the response. Other Claims MAY also be returned. +----------------------------------+--------+-----------------------+ | Claim | Type | Description | +----------------------------------+--------+-----------------------+ | version | string | Version of the | | | | provider response. | | | | "3.0" is the default. | | | | | | issuer | string | The https: URL with | | | | no query or fragment | | | | component that the OP | | | | asserts as its Issuer | | | | Identifier | | | | | | authorization_endpoint | string | URL of the OP's | | | | Authentication and | | | | Authorization | | | | Endpoint | | | | [OpenID.Messages] | | | | | | token_endpoint | string | URL of the OP's OAuth | | | | 2.0 Token Endpoint | | | | [OpenID.Messages] | | | | | | userinfo_endpoint | string | URL of the OP's | | | | UserInfo Endpoint | | | | [OpenID.Messages] | | | | | | check_id_endpoint | string | URL of the OP's Check | | | | ID Endpoint | | | | [OpenID.Messages] | | | | | | refresh_session_endpoint | string | URL of the OP's | | | | Refresh Session | | | | Endpoint | | | | [OpenID.Session] | | | | | | end_session_endpoint | string | URL of the OP's End | | | | Session Endpoint | | | | [OpenID.Session] | | | | | Sakimura, et al. [Page 10] OpenID Connect Discovery 1.0 - draft 08 April 2012 | jwk_url | string | URL of the OP's JSON | | | | Web Key [JWK] | | | | document. Server's | | | | signing Key | | | | | | jwk_encryption_url | string | URL of the OP's JSON | | | | Web Key [JWK] | | | | document. Server's | | | | Encryption Key, if | | | | not present, its | | | | value is the same as | | | | the URL provided by | | | | "jwk_url" | | | | | | x509_url | string | URL of the OP's X.509 | | | | certificates in PEM | | | | format. | | | | | | x509_encryption_url | string | URL of the OP's X.509 | | | | certificates in PEM | | | | format. Server's | | | | Encryption Key, if | | | | not present its value | | | | is the same as the | | | | URL provided by | | | | "x509_url" | | | | | | registration_endpoint | string | URL of the OP's | | | | Dynamic Client | | | | Registration Endpoint | | | | [OpenID.Registration] | | | | | | scopes_supported | array | A JSON array | | | | containing a list of | | | | the OAuth 2.0 | | | | [OAuth2.0] scope | | | | values that this | | | | server supports. The | | | | server MUST support | | | | the "openid" scope | | | | value. | | | | | Sakimura, et al. [Page 11] OpenID Connect Discovery 1.0 - draft 08 April 2012 | response_types_supported | array | A JSON array | | | | containing a list of | | | | the OAuth 2.0 | | | | "response_type" that | | | | this server supports. | | | | The server MUST | | | | support the "code" | | | | "response_type". | | | | | | acrs_supported | array | A JSON array | | | | containing a list of | | | | the Authentication | | | | Context Class | | | | References that this | | | | server supports. | | | | | | user_id_types_supported | array | A JSON array | | | | containing a list of | | | | the user identifier | | | | types that this | | | | server supports. | | | | Valid types include | | | | "pairwise" and | | | | "public". | | | | | | userinfo_algs_supported | array | A JSON array | | | | containing a list of | | | | the JWS and JWE | | | | signing and | | | | encryption algorithms | | | | [JWA] supported by | | | | the UserInfo Endpoint | | | | to encode the JWT | | | | [JWT]. | | | | | | id_token_algs_supported | array | A JSON array | | | | containing a list of | | | | the JWS and JWE | | | | signing and | | | | encryption algorithms | | | | [JWA] supported by | | | | the Authorization | | | | Server for the ID | | | | Token to encode the | | | | JWT [JWT]. | | | | | Sakimura, et al. [Page 12] OpenID Connect Discovery 1.0 - draft 08 April 2012 | request_object_algs_supported | array | A JSON array | | | | containing a list of | | | | the JWS and JWE | | | | signing and | | | | encryption algorithms | | | | [JWA] supported by | | | | the Authorization | | | | Server for the OpenID | | | | Request Object | | | | described in Section | | | | 2.1.2.1 of OpenID | | | | Connect Messages 1.0 | | | | [OpenID.Messages] to | | | | encode the JWT [JWT]. | | | | Servers SHOULD | | | | support "HS256". | | | | | | token_endpoint_auth_types_suppor | array | A JSON array | | ted | | containing a list of | | | | authentication types | | | | supported by this | | | | Token Endpoint. The | | | | options are | | | | "client_secret_post", | | | | "client_secret_basic" | | | | ,"client_secret_jwt", | | | | and | | | | "private_key_jwt", a | | | | sdescribed in Section | | | | 2.2.1 of OpenID | | | | Connect Messages 1.0 | | | | [OpenID.Messages]. | | | | Other Authentication | | | | types may be defined | | | | by extension. If | | | | unspecified or | | | | omitted, the default | | | | is | | | | "client_secret_basic | | | | "HTTP Basic | | | | Authentication Schem | | | | eas specified in | | | | section 2.3.1 of | | | | OAuth 2.0 [OAuth2.0] | | | | . | | | | | Sakimura, et al. [Page 13] OpenID Connect Discovery 1.0 - draft 08 April 2012 | token_endpoint_auth_algs_support | array | A JSON array | | ed | | containing a list of | | | | the JWS signing | | | | algorithms [JWA] | | | | supported by the | | | | Token Endpoint for | | | | the "private_key_jwt" | | | | method to encode the | | | | JWT [JWT]. Servers | | | | SHOULD support | | | | "RS256". | +----------------------------------+--------+-----------------------+ Table 1: Reserved Claim Definitions Example response: { "authorization_endpoint": "https://server.example.com/connect/authorize", "issuer" : "https://server.example.com", "token_endpoint": "https://server.example.com/connect/token", "token_endpoint_auth_types_supported": ["client_secret_basic", "private_key_jwt"], "userinfo_endpoint": "https://server.example.com/connect/user", "check_id_endpoint": "https://server.example.com/connect/check_id", "refresh_session_endpoint": "https://server.example.com/connect/refresh_session", "end_session_endpoint": "https://server.example.com/connect/end_session", "jwk_url": "https://server.example.com/jwk.json", "registration_endpoint": "https://server.example.com/connect/register", "scopes_supported": ["openid", "profile", "email", "address", "phone"], "response_types_supported": ["code", "code id_token", "token id_token"], "acrs_supported": ["1","2","http://id.incommon.org/assurance/bronze"], "user_id_types_supported": ["public", "pairwise"], "userinfo_algs_supported": ["HS256", "RS256", "A128CBC", "A128KW", "RSA1_5"], "id_token_algs_supported": ["HS256", "RS256", "A128CBC", "A128KW", "RSA1_5"], "request_object_algs_supported": ["HS256", "RS256", "A128CBC", "A128KW", "RSA1_5"] } 3.3. Provider Configuration Verification If the configuration response contains the "issuer" element, the value MUST exactly match the "issuer" for the URL that was directly used to retrieve the configuration. Since the discovery process allows for multiple levels of redirection (Section 2.3), this "issuer" URL may be different from the one originally used to begin the discovery process. Sakimura, et al. [Page 14] OpenID Connect Discovery 1.0 - draft 08 April 2012 4. 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. In several places, this specification uses space delimited lists of strings. In all such cases, only the ASCII space character (0x20) MAY be used for this purpose. Sakimura, et al. [Page 15] OpenID Connect Discovery 1.0 - draft 08 April 2012 5. IANA Considerations Per RFC 5785 [RFC5785], the following registration is requested: URI suffix openid-configuration Change controller OpenID Foundation Specification document This document Sakimura, et al. [Page 16] OpenID Connect Discovery 1.0 - draft 08 April 2012 6. Security Considerations TBD Sakimura, et al. [Page 17] OpenID Connect Discovery 1.0 - draft 08 April 2012 7. References 7.1. Normative References [JWA] Jones, M., "JSON Web Algorithms", March 2012. [JWE] Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web Encryption (JWE)", March 2012. [JWK] Jones, M., "JSON Web Key (JWK)", March 2012. [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature", March 2012. [JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, "JSON Web Token", March 2012. [OAuth2.0] Hammer, E., Ed., Recordon, D., and D. Hardt, "OAuth 2.0 Authorization Protocol", March 2012. [OpenID.Messages] Sakimura, N., Recordon, D., Bradley, J., de Medeiros, B., Jones, M., and E. Jay, "OpenID Connect Messages 1.0", April 2012. [OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0", April 2012. [OpenID.Session] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, "OpenID Connect Session Management 1.0", April 2012. [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. [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. Sakimura, et al. [Page 18] OpenID Connect Discovery 1.0 - draft 08 April 2012 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [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. [SWD] Jones, M. and Y. Goland, "Simple Web Discovery", December 2011. [USA15] Davis, M., Whistler, K., and M. Duerst, "Unicode Normalization Forms", Unicode Standard Annex 15, 09 2009. 7.2. Informative References [XRI_Syntax_2.0] Reed, D. and D. McAlpin, "Extensible Resource Identifier (XRI) Syntax V2.0", November 2005. Sakimura, et al. [Page 19] OpenID Connect Discovery 1.0 - draft 08 April 2012 Appendix A. Acknowledgements Sakimura, et al. [Page 20] OpenID Connect Discovery 1.0 - draft 08 April 2012 Appendix B. Notices Copyright (c) 2012 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 21] OpenID Connect Discovery 1.0 - draft 08 April 2012 Appendix C. Document History [[ To be removed from the final specification ]] -08 o Remove the no path component restriction from issuer, per issue #513 o Updated Notices o Updated References -07 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 Sakimura, et al. [Page 22] OpenID Connect Discovery 1.0 - draft 08 April 2012 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. 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. Sakimura, et al. [Page 23] OpenID Connect Discovery 1.0 - draft 08 April 2012 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 24] OpenID Connect Discovery 1.0 - draft 08 April 2012 Authors' Addresses Nat Sakimura Nomura Research Institute, Ltd. Email: n-sakimura@nri.co.jp John Bradley Independent Email: ve7jtb@ve7jtb.com Michael B. Jones Microsoft Email: mbj@microsoft.com Edmund Jay Illumila Email: ejay@mgi1.com Sakimura, et al. [Page 25]