TOC 
DraftN. Sakimura
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 March 6, 2013


OpenID Connect Dynamic Client Registration 1.0 - draft 15

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 REST-like manner.

This specification describes how an OpenID Client can obtain the necessary Client Credentials required by the OpenID Connect protocol suite.



Table of Contents

1.  Introduction
    1.1.  Requirements Notation and Conventions
    1.2.  Terminology
2.  Client Metadata
3.  Client Registration
    3.1.  Client Registration Request
    3.2.  Client Registration Response
    3.3.  Client Registration Error Response
4.  Client Read
    4.1.  Client Read Request
    4.2.  Client Read Response
    4.3.  Client Read Error Response
5.  "sector_identifier_uri" Validation
6.  String Operations
7.  Validation
8.  Implementation Considerations
9.  Security Considerations
    9.1.  TLS Requirements
10.  IANA Considerations
11.  References
    11.1.  Normative References
    11.2.  Informative References
Appendix A.  Acknowledgements
Appendix B.  Notices
Appendix C.  Document History
§  Authors' Addresses




 TOC 

1.  Introduction

In order for an OpenID Connect Client to utilize OpenID services for a user, the Client needs to register with the OpenID Provider to acquire a Client ID and shared secret. This document describes how a new Client can register with the provider, and how a Client already in possession of a client_id can retrieve updated registration information.

The Client Registration Endpoint may be co-resident with the Token Endpoint as an optimization in some deployments.

Note: This specification will likely be modified to use the OAuth Dynamic Client Registration Protocol (Richer, J., Bradley, J., Jones, M., and M. Machulak, “OAuth Dynamic Client Registration Protocol,” February 2013.) [I‑D.ietf‑oauth‑dyn‑reg] once the OAuth registration draft is stable. While currently self-contained, this specification intentionally uses the same syntax and identifiers as the current version of the OAuth registration draft as of the time that this specification was last updated.



 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,” March 2013.) [OpenID.Messages].

This specification defines the following additional terms:

Client Registration Endpoint
OAuth 2.0 Protected Resource through which a Client can request a new registration.
Client Configuration Endpoint
The OAuth 2.0 Endpoint through which a specific Client can manage its registration information, provided by the Authorization Server to the Client. This URL for this endpoint is communicated to the Client by the Authorization Server in the Client Registration Response.
Registration Access Token
OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint that is used by the Client to authenticate itself during update operations. This token is associated with a particular Client.


 TOC 

2.  Client Metadata

Clients have metadata associated with their unique Client Identifier at the Authorization Server. These can range from human-facing display strings, such as a Client name, to items that impact the security of the protocol, such as the list of valid redirect URIs.

Client Metadata values used by OpenID Connect are:

access_token
OPTIONAL. Access Token obtained out of band to authorize the registrant. This parameter MUST NOT be sent if the Access Token is sent in the HTTP Authorization header as described in Section 7.1 of OAuth 2.0 (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) [RFC6749]. Access Tokens sent in the authorization header must be bearer tokens [RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.).
redirect_uris
REQUIRED. Array of redirect URIs values used in the Authorization Code and Implicit grant types. One of the these registered redirect URI values MUST match the Scheme, Host, and Path segments of the redirect_uri parameter value used in each Authorization Request.
response_types
OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type values that the Client is declaring that it will restrict itself to using. If omitted, the default is that the Client will use only the code response type.
grant_types
OPTIONAL. JSON array containing a list of the OAuth 2.0 grant types that the Client is declaring that it will restrict itself to using. The grant type values used by OpenID Connect are: The following table lists the correspondence between response_type values that the Client will use and grant_type values that MUST be included in the registered grant_types list:
  • code: authorization_code
  • id_token: implicit
  • token id_token: implicit
  • code id_token: authorization_code, implicit
  • code token: authorization_code, implicit
  • code token id_token: authorization_code, implicit
If omitted, the default is that the Client will use only the authorization_code grant type.
application_type
OPTIONAL. Kind of the application. The default if not specified is web. The defined values are native or web. Web Clients using the OAuth implicit grant type MUST only register URLs using the https scheme as redirect_uris; they MAY NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers may place additional constraints on Native Clients. The Authorization Server MUST verify that all the registered redirect_uris conform to these constraints. This prevents sharing a Client ID across different types of Clients.
contacts
OPTIONAL. Array of e-mail addresses of people responsible for this Client. This may be used by some providers to enable a Web user interface to modify the Client information.
client_name
OPTIONAL. Name of the Client to be presented to the user. If desired, representation of this Claim in different languages and scripts is obtained by applying the rules set in Section 2.1.1.1.3 ("claims" member) 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,” March 2013.) [OpenID.Messages].
logo_uri
OPTIONAL. URL that references a logo for the Client application.
token_endpoint_auth_method
OPTIONAL. Requested authentication method for the 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,” March 2013.) [OpenID.Messages]. Other Authentication methods may be defined by extension. If unspecified or omitted, the default is client_secret_basic 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].
policy_uri
OPTIONAL. URL that the Relying Party Client provides to the End-User to read about the how the profile data will be used. The OpenID Provider SHOULD display this URL to the End-User if it is given.
tos_uri
OPTIONAL. URL that the Relying Party Client provides to the End-User to read about the Relying Party's terms of service. The OpenID Provider SHOULD display this URL to the End-User if it is given.
jwks_uri
OPTIONAL. URL for the Client's JSON Web Key Set [JWK] (Jones, M., “JSON Web Key (JWK),” December 2012.) document containing key(s) that are used for signing requests to the OP. The JWK Set MAY also contain the Client's encryption keys(s) that are used by the OP to encrypt the responses to the Client. When both signing and encryption keys are made available, a use (Key Use) parameter value is REQUIRED for all keys in the document to indicate each key's intended usage.
sector_identifier_uri
OPTIONAL. URL using the https scheme to be used in calculating Pseudonymous Identifiers by the OP. The URL references a file with a single JSON array of redirect_uri values. Please see Section 5 ("sector_identifier_uri" Validation). Providers that use pairwise sub (subject) values SHOULD provide a sector_identifier_uri.
subject_type
OPTIONAL. subject_type requested for responses to this client_id. The subject_types_supported element of discovery contains a list of the supported subject_type values for this server. Valid types include pairwise and public.
request_object_signing_alg
OPTIONAL. JWS (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012.) [JWS] alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) that MUST be required by the Authorization Server. The valid values are listed in Section 3.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. All Request Objects from this client_id MUST be rejected if not signed by this algorithm. Servers SHOULD support RS256.
userinfo_signed_response_alg
OPTIONAL. JWS alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for UserInfo Responses. The valid values are listed in Section 3.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and signed using JWS.
userinfo_encrypted_response_alg
OPTIONAL. JWE (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2012.) [JWE] alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for encrypting UserInfo Responses. The valid values are listed in Section 4.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If this is requested in combination with signing the response will be signed then encrypted. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and encrypted using JWE.
userinfo_encrypted_response_enc
OPTIONAL. JWE enc algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for symmetric encryption of UserInfo Responses. The valid values are listed in Section 4.2 JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If userinfo_encrypted_response_alg is specified the default for this value is A128CBC+HS256. If this is requested in combination with signing the response will be signed then encrypted. If this is specified the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and encrypted using JWE.
id_token_signed_response_alg
OPTIONAL. JWS alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for the ID Token issued to this client_id. The valid values are listed in Section 3.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA], with the exception of none, which MAY NOT be used as the ID Token alg value. The default if not specified is RS256. The public key for validating the signature is provided by retrieving the JWK Set referenced by the jwks_uri element from Discovery.
id_token_encrypted_response_alg
OPTIONAL. JWE alg algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for encrypting the ID Token issued to this client_id. The valid values are listed in Section 4.1 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If this is requested, the response will be signed then encrypted. The default, if not specified, is no encryption.
id_token_encrypted_response_enc
OPTIONAL. JWE enc algorithm [JWA] (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) required for symmetric encryption of the ID Token issued to this client_id. The valid values are listed in Section 4.2 of JWA (Jones, M., “JSON Web Algorithms (JWA),” December 2012.) [JWA]. If id_token_encrypted_response_alg is specified, the default for this parameter is A128CBC+HS256. If this is requested in combination with signing, the response will be signed then encrypted. If this is specified, the response will be JWT (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.) [JWT] serialized, and encrypted using JWE.
default_max_age
OPTIONAL. Default Maximum Authentication Age. Specifies that the End-User must be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value.
require_auth_time
OPTIONAL. Boolean value specifying whether the auth_time Claim in the id_token is REQUIRED. It is REQUIRED when the value is true. The auth_time Claim request in the Request Object overrides this setting.
default_acr_values
OPTIONAL. Default requested Authentication Context Class Reference values. Array of strings that specifies the default acr values that the Authorization Server MUST use for processing requests from this Client. The acr_values_supported discovery element contains a list of the supported acr values supported by this server. Values specified in the acr_values request parameter or an acr Claim request override these default values.
initiate_login_uri
OPTIONAL. URI using the https scheme that the Authorization Server can call to initiate a login at the Client. The URI MUST accept requests via both GET and POST. The Client MUST understand the login_hint and iss parameters and SHOULD support the target_link_uri parameter.
post_logout_redirect_uri
OPTIONAL. URL supplied by the RP to request that the user be redirected to this location after a logout has been performed, as specified in OpenID Connect Session Management 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” March 2013.) [OpenID.Session].
request_uris
OPTIONAL. Array of request_uri values that are pre-registered by the Client for use at the Authorization Server. Servers MAY cache the contents of the files referenced by these URIs and not retrieve them at the time they are used in a request. OPs can require that request_uri values used be pre-registered with the require_request_uri_registration discovery parameter.
If the contents of the request file could ever change, these URI values SHOULD include the base64url encoded SHA-256 hash value of the file contents referenced by the URI as the value of the URI fragment. If the fragment value used for a URI changes, that signals the server that its cached value for that URI with the old fragment value is no longer valid.



 TOC 

3.  Client Registration

The Client Registration Endpoint is an OAuth 2.0 Protected Resource through which a Client can request a new registration and manage the Metadata associated with it. The OpenID Provider may require an Access Token that is provisioned out-of-band (in a manner that is out of scope for this specification) in order to restrict registration requests to only authorized Clients.

In order to support open registration, the Client Registration Endpoint SHOULD accept registration requests without OAuth 2.0 Access Tokens. These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the Client Registration Endpoint. If an Access Token is required for Client registration, the Client Registration Endpoint MUST be able to accept Access Tokens in the manner described in the OAuth 2.0 Bearer Token Usage (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) [RFC6750] specification.



 TOC 

3.1.  Client Registration Request

To register a new Client to the Authorization Server, the Client sends an HTTP POST message to the Client Registration Endpoint with any parameters described in Client Metadata (Client Metadata) that the Client wishes to specify for itself during the registration. The Authorization Server assigns this Client a unique Client Identifier, optionally assigns a Client Secret, and associates the Metadata given in the request with the issued Client Identifier. The Authorization Server MAY provision default values for any items omitted in the Client Metadata.

The Client sends an HTTP POST to the Client Registration Endpoint with a content type of application/json and all parameters as top-level members of a JSON object.

For example, a Client could send the following registration request to the Client Registration Endpoint:

The following is a non-normative example request (with line breaks within values for display purposes only):

  POST /connect/register HTTP/1.1
  Content-Type: application/json
  Accept: application/json
  Host: server.example.com
  Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...

  {
   "application_type": "web",
   "redirect_uris":
     ["https://client.example.org/callback",
      "https://client.example.org/callback2"],
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
   "logo_uri": "https://client.example.org/logo.png",
   "subject_type": "pairwise",
   "sector_identifier_uri":
     "https://other.example.net/file_of_redirect_uris.json",
   "token_endpoint_auth_method": "client_secret_basic",
   "jwks_uri": "https://client.example.org/my_rsa_public_key.jwks",
   "userinfo_encrypted_response_alg": "RSA1_5",
   "userinfo_encrypted_response_enc": "A128CBC+HS256",
   "contacts": ["ve7jtb@example.org", "mary@example.org"],
   "request_uris":
     ["https://client.example.org/rf.txt
       #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
  }


 TOC 

3.2.  Client Registration Response

Upon successful registration, the Client Registration Endpoint returns the newly-created Client Identifier and, if applicable, a Client Secret, along with all registered Metadata about this Client, including any fields provisioned by the Authorization Server itself. The Authorization Server MAY reject or replace any of the Client's requested field values and substitute them with suitable values. If this happens, the Authorization Server MUST include these fields in the response to the Client.

The response also contains a Registration Access Token that is used by the Client to perform subsequent operations upon the resulting Client registration.

All of the response items are returned as a JSON document (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627] with the following fields as top-level members of the root JSON object.

client_id
REQUIRED. Unique Client identifier. It MUST NOT be currently valid for any other registered Client.
client_secret
OPTIONAL. Client secret. This MUST be unique for each client_id. This value is used by Confidential Clients to authenticate to the Token Endpoint as described in OAuth 2.0 Section 2.3.1. It is not required for Clients selecting a token_endpoint_auth_method of private_key_jwt.
registration_access_token
REQUIRED. Access Token that is used by the Client to perform subsequent operations upon the resulting Client registration.
registration_client_uri
REQUIRED. Location where the Access Token can be used to perform subsequent operations upon the resulting Client registration.
issued_at
OPTIONAL. Time when the Client Identifier was issued. The timestamp value MUST be a positive integer. The time is represented as the number of seconds since 1970-01-01T0:0:0Z as measured in UTC.
expires_at
OPTIONAL. Time at which the client_secret will expire or 0 if it will not expire. The time is represented as the number of seconds since 1970-01-01T0:0:0Z as measured in UTC.

The following is a non-normative example response (with line breaks within values for display purposes only):

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
   "client_id": "s6BhdRkqt3",
   "client_secret":
     "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
   "expires_at": 1577858400,
   "registration_access_token":
     "this.is.an.access.token.value.ffx83",
   "registration_client_uri":
     "https://server.example.com/connect/register?client_id=s6BhdRkqt3",
   "token_endpoint_auth_method":
     "client_secret_basic",
   "application_type": "web",
   "redirect_uris":
     ["https://client.example.org/callback"
      "https://client.example.org/callback2"],
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
   "logo_uri": "https://client.example.org/logo.png",
   "subject_type": "pairwise",
   "sector_identifier_uri":
     "https://other.example.net/file_of_redirect_uris.json",
   "jwks_uri": "https://client.example.org/my_rsa_public_key.jwks",
   "userinfo_encrypted_response_alg": "RSA1_5",
   "userinfo_encrypted_response_enc": "A128CBC+HS256",
   "contacts": ["ve7jtb@example.org", "mary@example.org"],
   "request_uris":
     ["https://client.example.org/rf.txt
       #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
  }


 TOC 

3.3.  Client Registration Error Response

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

When a registration error condition occurs, the Client Registration Endpoint returns a HTTP 400 status code including a JSON object describing the error in the response body.

The JSON object contains two members:

error_code
Error code.
error_description
Additional text description of the error for debugging.

This specification defines the following error codes:

invalid_redirect_uri
The value of one or more redirect_uris is invalid.
invalid_client_metadata
The value of one of the Client Metadata (Client Metadata) fields is invalid and the server has rejected this request. Note that an Authorization Server MAY choose to substitute a valid value for any requested parameter of a Client's Metadata.

The following is a non-normative example error response:

  HTTP/1.1 400 Bad Request
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
   "error_code": "invalid_redirect_uri",
   "error_description": "The value of one or more redirect_uris are invalid."
  }


 TOC 

4.  Client Read

This operation retrieves the Client Metadata for a previously registered Client.



 TOC 

4.1.  Client Read Request

To read the current configuration of the Client on the Authorization Server, the Client makes an HTTP GET request to the Client Configuration Endpoint with the Registration Access Token, passing the client_id value as a query parameter.

The following is a non-normative example request:

  GET /connect/register?client_id=s6BhdRkqt3 HTTP/1.1
  Accept: application/json
  Host: server.example.com
  Authorization: Bearer this.is.an.access.token.value.ffx83


 TOC 

4.2.  Client Read Response

Upon a successful read operation, the Authorization Server SHOULD return all registered Metadata (Client Metadata) about this Client, including any fields provisioned by the Authorization Server itself. Some values, including the client_secret value, may have been updated since the initial registration.

The Authorization Server need not include the registration_access_token or registration_client_uri value in this response unless they have been updated.

The response is a JSON Document (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627] with the Client Metadata as top-level members of a JSON object.

The following is a non-normative example response (with line breaks within values for display purposes only):

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache
  {
   "client_id": "s6BhdRkqt3",
   "client_secret":
     "OylyaC56ijpAQ7G5ZZGL7MMQ6Ap6mEeuhSTFVps2N4Q",
   "expires_at": 17514165600,
   "registration_client_uri":
     "https://server.example.com/connect/register?client_id=s6BhdRkqt3",
   "token_endpoint_auth_method":
     "client_secret_basic",
   "application_type": "web",
   "redirect_uris":
     ["https://client.example.org/callback"
      "https://client.example.org/callback2"],
   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",
   "logo_uri": "https://client.example.org/logo.png",
   "subject_type": "pairwise",
   "sector_identifier_uri":
     "https://other.example.net/file_of_redirect_uris.json",
   "jwks_uri": "https://client.example.org/my_rsa_public_key.jwks",
   "userinfo_encrypted_response_alg": "RSA1_5",
   "userinfo_encrypted_response_enc": "A128CBC+HS256",
   "contacts": ["ve7jtb@example.org", "mary@example.org"],
   "request_uris":
     ["https://client.example.org/rf.txt
       #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
  }


 TOC 

4.3.  Client Read Error Response

When a read error condition occurs, the Client Configuration Endpoint returns a HTTP 403 Forbidden status code. This indicates that the Access Token is invalid or the Client record requested is invalid or non-existent. Note that for security reasons, to inhibit brute force attacks, endpoints MUST NOT return 404 Not Found error codes.

The following is a non-normative example error response:

  HTTP/1.1 403 Forbidden
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache


 TOC 

5.  "sector_identifier_uri" Validation

The sector identifier list provides a way for a group of Web sites under single administrative control to have consistent pairwise sub values, independent of their domain names, as described in Section 2.8.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,” March 2013.) [OpenID.Messages]. It also provides a way for Clients to change redirect_uri domains without having to re-register all of their users.

The value of the sector_identifier_uri must be a URL using the https scheme that references a JSON file containing an array of redirect_uri values. The values registered in redirect_uris MUST be included in the elements of the array, or registration MUST fail.

The following is a non-normative example request to and reply from a sector_identifier_uri.

  GET https://other.example.net/file_of_redirect_uris.json HTTP/1.1
  Accept: application/json
  Host: client.example.org

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  [ "https://client.example.org/callback",
    "https://client.example.org/callback2",
    "https://client.other_company.example.net/callback" ]


 TOC 

6.  String Operations

Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the member names in the Client registration response might be compared to specific member names such as client_id. 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 

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



 TOC 

8.  Implementation Considerations

This specification defines features used by both Relying Parties and OpenID Providers that choose to implement Dynamic Client Registration. 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 Dynamic Client Registration are defined by this specification.



 TOC 

9.  Security Considerations

Since requests to the Client Registration Endpoint result in the transmission of clear-text credentials (in the HTTP request and response), all communication with the Registration Endpoint MUST utilize TLS. See Section 9.1 (TLS Requirements) for more information on using TLS.

A rogue RP might use the logo for the legitimate RP, which it is trying to impersonate. An OP needs to take steps to mitigate this phishing risk, since the logo could confuse users into thinking they're logging in to the legitimate RP. An OP could also warn if the domain/site of the logo doesn't match the domain/site of redirect URIs. An OP can also make warnings against untrusted RPs in all cases, especially if they're dynamically registered, have not been trusted by any users at the OP before, and want to use the logo feature.

In a situation where the Authorization Server is supporting open Client registration, it must be extremely careful with any URL provided by the Client that will be displayed to the user (e.g. logo_uri and policy_uri). A rogue Client could specify a registration request with a reference to a drive-by download in the policy_uri. The Authorization Server should check to see if the logo_uri and policy_uri have the same host as the hosts defined in the array of redirect_uris.



 TOC 

9.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] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) 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] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) 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 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125].



 TOC 

10.  IANA Considerations

This document makes no requests of IANA.



 TOC 

11.  References



 TOC 

11.1. Normative References

[JWA] Jones, M., “JSON Web Algorithms (JWA),” draft-ietf-jose-json-web-algorithms (work in progress), December 2012 (HTML).
[JWE] Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” draft-ietf-jose-json-web-encryption (work in progress), December 2012 (HTML).
[JWK] Jones, M., “JSON Web Key (JWK),” draft-ietf-jose-json-web-key (work in progress), December 2012 (HTML).
[JWS] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” draft-ietf-jose-json-web-signature (work in progress), December 2012 (HTML).
[JWT] Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” draft-ietf-oauth-json-web-token (work in progress), December 2012 (HTML).
[OAuth.JWT] Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0,” draft-ietf-oauth-jwt-bearer (work in progress), December 2012 (HTML).
[OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” March 2013.
[OpenID.Session] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” March 2013.
[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).
[RFC4627] Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, August 2008 (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).
[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT).
[USA15] Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.


 TOC 

11.2. Informative References

[I-D.ietf-oauth-dyn-reg] Richer, J., Bradley, J., Jones, M., and M. Machulak, “OAuth Dynamic Client Registration Protocol,” draft-ietf-oauth-dyn-reg-07 (work in progress), February 2013 (TXT).


 TOC 

Appendix A.  Acknowledgements

The OpenID Community would like to thank the following people for the work they have done in the drafting and editing of this specification.

Amanda Anganes (aanganes@mitre.org), Mitre

John Bradley (ve7jtb@ve7jtb.com), Ping Identity

Brian Campbell (bcampbell@pingidentity.com), Ping Identity

Vladimir Dzhuvinov (vladimir@nimbusds.com), NimbusDS

Roland Hedberg (roland.hedberg@adm.umu.se), Independent

Edmund Jay (ejay@mgi1.com), Illumila

Michael B. Jones (mbj@microsoft.com), Microsoft

Justin Richer (jricher@mitre.org), Mitre

Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.



 TOC 

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.



 TOC 

Appendix C.  Document History

[[ To be removed from the final specification ]]

-15

-14

-13

-12

-11

-10

-09

-08

-07

-06

-05

-04

-03

-02

-01



 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