TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 E. Jay
 Illumila
 December 6, 2012


OpenID Connect Discovery 1.0 - draft 10

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.



Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
    1.2.  Terminology
2.  Provider Discovery
    2.1.  Identifier Normalization
        2.1.1.  User input Identifier Types
        2.1.2.  E-Mail Address look alike relative references
        2.1.3.  Any other strings
    2.2.  Non-Normative Examples
        2.2.1.  User input that look like an E-Mail Address
        2.2.2.  URL
        2.2.3.  Hostname & Port
3.  Provider Configuration Information
    3.1.  Provider Configuration Request
    3.2.  Provider Configuration Response
    3.3.  Provider Configuration Validation
4.  String Operations
5.  IANA Considerations
6.  Security Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
§  Authors' Addresses




 TOC 

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 (Jones, M. and Y. Goland, “Simple Web Discovery,” November 2012.) [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.



 TOC 

1.1.  Requirements Notation and Conventions

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

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



 TOC 

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 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749], and the terms defined by OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.) [OpenID.Messages]. This specification also defines the following terms:

Principal
An Entity that is the target of a request in Simple Web Discovery.
Identifier
String that uniquely characterize an entity in a specific environment with defined boundary conditions in which entities exist and interact
Note: this document defines various kinds of Identifiers, designed for use in different contexts. Examples includes https URLs and email addresses.


 TOC 

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 Configuration Information).

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 (Jones, M. and Y. Goland, “Simple Web Discovery,” November 2012.) [SWD]:

Service TypeURI
OpenID Connect Issuer http://openid.net/specs/connect/1.0/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 (Jones, M. and Y. Goland, “Simple Web Discovery,” November 2012.) [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 (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].

What MUST be returned in the response is the issuer. This includes URI scheme, HOST, and OPTIONALLY, port.



 TOC 

2.1.  Identifier Normalization

The purpose of normalization is to extract a normalized principal and host from the user input Identifier. This is then used as input to SWD to discover the issuer.

The user input Identifier SHOULD be URL or URI relative reference defined in RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]. The user input Identifier MUST include the authority component to be supported by this specification.

Note: URI relative reference includes a string that looks like an email 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 (Resnick, P., Ed., “Internet Message Format,” October 2008.) [RFC5322].

The Identifier normalization rules MAY be extended by additional specifications to enable other identifier types such as telephone numbers or XRIs (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.) [XRI_Syntax_2.0] to also be used.



 TOC 

2.1.1.  User input Identifier Types

A user input Identifier can be categorized into the following types that requires different normalization process.

  1. User input Identifiers starting with the XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.) [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 URI relative references.

Note: The user input Identifier may be in the form of username@host. For the user, it is an email. However, it is also a valid URI relative reference, and this specification treats it as a relative reference to exclude various extra strings allowed in addr-spec of RFC 5322 (Resnick, P., Ed., “Internet Message Format,” October 2008.) [RFC5322].



 TOC 

2.1.2.  E-Mail Address look alike relative references

User input Identifiers using e-mail address look alike syntax MUST conform to the Authority component of RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986] with userinfo and host but without port.

In this case, the SWD principal value is the entire authority component, and the SWD host value is the host.



 TOC 

2.1.3.  Any other strings

A string of any other types are interpreted as either URL or relative reference and is normalized according to the following rules:



 TOC 

2.2.  Non-Normative Examples



 TOC 

2.2.1.  User input that look like an E-Mail Address

To find the issuer for the given e-mail address looking user input, joe@example.com, the SWD parameters are as follows:

SWD ParameterValue
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 (with line wraps for display purposes only):

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"]
}


 TOC 

2.2.2.  URL

To find the issuer for the given URL, https://example.com/joe, the SWD parameters are as follows:

SWD ParameterValue
principal https://example.com/joe
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 (with line wraps for display purposes only):

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"]
}


 TOC 

2.2.3.  Hostname & Port

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 SWD parameters are as follows:

SWD ParameterValue
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 (with line wraps for display purposes only):

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"]
}


 TOC 

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 (Provider Discovery) 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 (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.) [RFC5785] and apply to issuer when it contains no path component. 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 (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] and/or TLS 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) and MAY support other transport layer security mechanisms of equivalent security.



 TOC 

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

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

Path components are allowed to support multiple issuers per host. This is required in some multi-tenant hosting configurations. Any .well-known in addition to the one specified in RFC 5785 (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.) [RFC5785] are for issuer configuration and not general information about the host.



 TOC 

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 the 200 OK response code and a plain text JSON object that contains a set 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.



ClaimTypeDescription
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] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.)
token_endpoint string URL of the OP's OAuth 2.0 Token Endpoint [OpenID.Messages] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.)
userinfo_endpoint string URL of the OP's UserInfo Endpoint [OpenID.Messages] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.)
refresh_session_endpoint string URL of the OP's Refresh Session Endpoint [OpenID.Session] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” December 2012.)
check_session_endpoint string URL of an OP endpoint that provides a page to support cross-origin communications for session state information with the RP client, using the HTML5 postMessage API. The page is loaded from an invisible iframe embedded in an RP page so that it can run in the OP's security context.[OpenID.Session] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” December 2012.)
end_session_endpoint string URL of the OP's endpoint that initiates the user logout [OpenID.Session] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” December 2012.)
jwk_url string URL of the OP's JSON Web Key (Jones, M., “JSON Web Key (JWK),” November 2012.) [JWK] document. Server's signing Key
jwk_encryption_url string URL of the OP's JSON Web Key (Jones, M., “JSON Web Key (JWK),” November 2012.) [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] (Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2012.)
scopes_supported array A JSON array containing a list of the OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749] scope values that this server supports. The server MUST support the openid scope value.
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, id_token, and the token id_token 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_signing_alg_values_supported array A JSON array containing a list of the JWS [JWS] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” November 2012.) signing algorithms (alg values) [JWA] (Jones, M., “JSON Web Algorithms,” November 2012.) supported by the UserInfo Endpoint to encode the claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.).
userinfo_encryption_alg_values_supported array A JSON array containing a list of the JWE [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” November 2012.) encryption algorithms (alg values) [JWA] (Jones, M., “JSON Web Algorithms,” November 2012.) supported by the UserInfo Endpoint to encode the claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.).
userinfo_encryption_enc_values_supported array A JSON array containing a list of the JWE encryption algorithms (enc values) [JWA] (Jones, M., “JSON Web Algorithms,” November 2012.) supported by the UserInfo Endpoint to encode the claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.).
id_token_signing_alg_values_supported array A JSON array containing a list of the JWS signing algorithms (alg values) supported by the Authorization Server for the ID Token to encode the claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.).
id_token_encryption_alg_values_supported array A JSON array containing a list of the JWE encryption algorithms (alg values) supported by the Authorization Server for the ID Token to encode the claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.).
id_token_encryption_enc_values_supported array A JSON array containing a list of the JWE encryption algorithms (enc values) supported by the Authorization Server for the ID Token to encode the claims in a JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.).
request_object_signing_alg_values_supported array A JSON array containing a list of the JWS signing algorithms (alg values) supported by the Authorization Server for the OpenID Request Object described in Section 2.1.2.1 of OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.) [OpenID.Messages]. Servers SHOULD support none and RS256.
request_object_encryption_alg_values_supported array A JSON array containing a list of the JWE encryption algorithms (alg values) supported by the Authorization Server for the OpenID Request Object described in Section 2.1.2.1 of OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.) [OpenID.Messages].
request_object_encryption_enc_values_supported array A JSON array containing a list of the JWE encryption algorithms (enc values) supported by the Authorization Server for the OpenID Request Object described in Section 2.1.2.1 of OpenID Connect Messages (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.) [OpenID.Messages].
token_endpoint_auth_types_supported array A JSON array 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, as described in Section 2.2.1 of OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.) [OpenID.Messages]. Other authentication types may be defined by extension. If unspecified or omitted, the default is client_secret_basic -- the HTTP Basic Authentication Scheme as specified in Section 2.3.1 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749].
token_endpoint_auth_signing_alg_values_supported array A JSON array containing a list of the JWS signing algorithms (alg values) supported by the Token Endpoint for the private_key_jwt and client_secret_jwt methods to encode the JWT [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.). 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"],
 "token_endpoint_alg_values_supported":
   ["RS256", "ES256"],
 "userinfo_endpoint":
   "https://server.example.com/connect/user",
 "refresh_session_endpoint":
   "https://server.example.com/connect/refresh_session",
 "check_session_endpoint":
   "https://server.example.com/connect/check_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_signing_alg_values_supported":
   ["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"]
 }



 TOC 

3.3.  Provider Configuration Validation

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, this issuer URL may be different from the one originally used to begin the discovery process.



 TOC 

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 (Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.) [USA15] MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against.
  3. Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison.

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



 TOC 

5.  IANA Considerations

Per RFC 5785 (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.) [RFC5785], the following registration is requested:

URI suffix
openid-configuration
Change controller
OpenID Foundation
Specification document
This document



 TOC 

6.  Security Considerations

TBD



 TOC 

7.  References



 TOC 

7.1. Normative References

[JWA] Jones, M., “JSON Web Algorithms,” November 2012.
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” November 2012.
[JWK] Jones, M., “JSON Web Key (JWK),” November 2012.
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature,” November 2012.
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token,” November 2012.
[OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” December 2012.
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, “OpenID Connect Dynamic Client Registration 1.0,” December 2012.
[OpenID.Session] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” December 2012.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (TXT).
[RFC5322] Resnick, P., Ed., “Internet Message Format,” RFC 5322, October 2008 (TXT, HTML, XML).
[RFC5785] Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” RFC 5785, April 2010 (TXT).
[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 (TXT).
[RFC6749] Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
[SWD] Jones, M. and Y. Goland, “Simple Web Discovery,” November 2012.
[USA15] Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.


 TOC 

7.2. Informative References

[XRI_Syntax_2.0] Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005 (HTML, PDF).


 TOC 

Appendix A.  Acknowledgements



 TOC 

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.



 TOC 

Appendix C.  Document History

[[ To be removed from the final specification ]]

-10

-09

-08

-07

-06

-05

-04

-03

-02

-01

-00



 TOC 

Authors' Addresses

  Nat Sakimura
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com
  
  Michael B. Jones
  Microsoft
Email:  mbj@microsoft.com
  
  Edmund Jay
  Illumila
Email:  ejay@mgi1.com