draft-ietf-oauth-dyn-reg-18.txt   draft-ietf-oauth-dyn-reg-19.txt 
OAuth Working Group J. Richer OAuth Working Group J. Richer
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Standards Track M. Jones Intended status: Standards Track M. Jones
Expires: January 4, 2015 Microsoft Expires: February 6, 2015 Microsoft
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
July 3, 2014 August 5, 2014
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-18 draft-ietf-oauth-dyn-reg-19
Abstract Abstract
This specification defines mechanisms for dynamically registering This specification defines mechanisms for dynamically registering
OAuth 2.0 clients with authorization servers. Registration requests OAuth 2.0 clients with authorization servers. Registration requests
send a set of desired client metadata values to the authorization send a set of desired client metadata values to the authorization
server and the resulting registration responses return a client server and the resulting registration responses return a client
identifier to use at the authorization server and the client metadata identifier to use at the authorization server and the client metadata
values registered for the client. The client can then use this values registered for the client. The client can then use this
registration information to communicate with the authorization server registration information to communicate with the authorization server
using the OAuth 2.0 protocol. This specification also defines a set using the OAuth 2.0 protocol. This specification also defines a set
of common client metadata fields and values for clients to use during of common client metadata fields and values for clients to use during
registration. registration.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2015. This Internet-Draft will expire on February 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 3, line 7 skipping to change at page 2, line 22
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Relationship between Grant Types and Response Types . . . 11 2.1. Relationship between Grant Types and Response Types . . . 10
2.2. Human Readable Client Metadata . . . . . . . . . . . . . . 12 2.2. Human Readable Client Metadata . . . . . . . . . . . . . 10
2.3. Software Statement . . . . . . . . . . . . . . . . . . . . 13 2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12
3. Client Registration Endpoint . . . . . . . . . . . . . . . . . 14 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 12
3.1. Client Registration Request . . . . . . . . . . . . . . . 14 3.1. Client Registration Request . . . . . . . . . . . . . . . 13
3.2. Client Registration Response . . . . . . . . . . . . . . . 17 3.2. Client Registration Response . . . . . . . . . . . . . . 16
4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Client Information Response . . . . . . . . . . . . . . . 17 4.1. Client Information Response . . . . . . . . . . . . . . . 16
4.2. Client Registration Error Response . . . . . . . . . . . . 18 4.2. Client Registration Error Response . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1. OAuth Dynamic Registration Client Metadata Registry . . . 20 5.1. OAuth Dynamic Registration Client Metadata Registry . . . 19
5.1.1. Registration Template . . . . . . . . . . . . . . . . 21 5.1.1. Registration Template . . . . . . . . . . . . . . . . 20
5.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 5.1.2. Initial Registry Contents . . . . . . . . . . . . . . 20
5.2. OAuth Token Endpoint Authentication Methods Registry . . . 24 5.2. OAuth Token Endpoint Authentication Methods Registry . . 22
5.2.1. Registration Template . . . . . . . . . . . . . . . . 24 5.2.1. Registration Template . . . . . . . . . . . . . . . . 23
5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 25 5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 28
A.1. Open versus Protected Dynamic Client Registration . . . . 29 A.1. Open versus Protected Dynamic Client Registration . . . . 28
A.1.1. Open Dynamic Client Registration . . . . . . . . . . . 29 A.1.1. Open Dynamic Client Registration . . . . . . . . . . 28
A.1.2. Protected Dynamic Client Registration . . . . . . . . 29 A.1.2. Protected Dynamic Client Registration . . . . . . . . 29
A.2. Registration Without or With Software Statements . . . . . 30 A.2. Registration Without or With Software Statements . . . . 29
A.2.1. Registration Without a Software Statement . . . . . . 30 A.2.1. Registration Without a Software Statement . . . . . . 29
A.2.2. Registration With a Software Statement . . . . . . . . 30 A.2.2. Registration With a Software Statement . . . . . . . 29
A.3. Registration by the Client or Developer . . . . . . . . . 30 A.3. Registration by the Client or Developer . . . . . . . . . 29
A.3.1. Registration by the Client . . . . . . . . . . . . . . 30 A.3.1. Registration by the Client . . . . . . . . . . . . . 29
A.3.2. Registration by the Developer . . . . . . . . . . . . 30 A.3.2. Registration by the Developer . . . . . . . . . . . . 29
A.4. Client ID per Client Instance or per Client Software . . . 30 A.4. Client ID per Client Instance or per Client Software . . 30
A.4.1. Client ID per Client Software Instance . . . . . . . . 30 A.4.1. Client ID per Client Software Instance . . . . . . . 30
A.4.2. Client ID Shared Among All Instances of Client A.4.2. Client ID Shared Among All Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . . 31 Software . . . . . . . . . . . . . . . . . . . . . . 30
A.5. Stateful or Stateless Registration . . . . . . . . . . . . 31 A.5. Stateful or Stateless Registration . . . . . . . . . . . 30
A.5.1. Stateful Client Registration . . . . . . . . . . . . . 31 A.5.1. Stateful Client Registration . . . . . . . . . . . . 30
A.5.2. Stateless Client Registration . . . . . . . . . . . . 31 A.5.2. Stateless Client Registration . . . . . . . . . . . . 30
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Appendix C. Document History . . . . . . . . . . . . . . . . . . 32 Appendix C. Document History . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
In order for an OAuth 2.0 client to utilize an OAuth 2.0 In order for an OAuth 2.0 client to utilize an OAuth 2.0
authorization server, the client needs specific information to authorization server, the client needs specific information to
interact with the server, including an OAuth 2.0 client identifier to interact with the server, including an OAuth 2.0 client identifier to
use at that server. This specification describes how an OAuth 2.0 use at that server. This specification describes how an OAuth 2.0
client can be dynamically registered with an authorization server to client can be dynamically registered with an authorization server to
obtain this information. obtain this information.
skipping to change at page 4, line 26 skipping to change at page 3, line 40
set of metadata, such as a set of valid redirection URIs. This set of metadata, such as a set of valid redirection URIs. This
metadata can either be communicated in a self-asserted fashion or as metadata can either be communicated in a self-asserted fashion or as
a set of metadata called a software statement, which is digitally a set of metadata called a software statement, which is digitally
signed or MACed; in the case of a software statement, the issuer is signed or MACed; in the case of a software statement, the issuer is
vouching for the validity of the data about the client. vouching for the validity of the data about the client.
Traditionally, registration of a client with an authorization server Traditionally, registration of a client with an authorization server
is performed manually. The mechanisms defined in this specification is performed manually. The mechanisms defined in this specification
can be used either for a client to dynamically register itself with can be used either for a client to dynamically register itself with
authorization servers or for a client developer to programmatically authorization servers or for a client developer to programmatically
register the client with authorization servers. register the client with authorization servers. Multiple
applications using OAuth 2.0 have previously developed mechanisms for
accomplishing such registrations. This specficiation generalizes the
registration mechanisms defined by the OpenID Connect Dynamic Client
Registration 1.0 [OpenID.Registration] specification and used by the
User Managed Access (UMA) Profile of OAuth 2.0
[I-D.hardjono-oauth-umacore] specification in a way that is
compatible with both, while being applicable to a wider set of OAuth
2.0 use cases.
1.1. Notational Conventions 1.1. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
skipping to change at page 7, line 4 skipping to change at page 6, line 14
The abstract OAuth 2.0 client dynamic registration flow illustrated The abstract OAuth 2.0 client dynamic registration flow illustrated
in Figure 1 describes the interaction between the client or developer in Figure 1 describes the interaction between the client or developer
and the endpoint defined in this specification. This figure does not and the endpoint defined in this specification. This figure does not
demonstrate error conditions. This flow includes the following demonstrate error conditions. This flow includes the following
steps: steps:
(A) Optionally, the client or developer is issued an initial access (A) Optionally, the client or developer is issued an initial access
token giving access to the client registration endpoint. The token giving access to the client registration endpoint. The
method by which the initial access token is issued to the client method by which the initial access token is issued to the client
or developer is out of scope for this specification. or developer is out of scope for this specification.
(B) Optionally, the client or developer is issued a software (B) Optionally, the client or developer is issued a software
statement for use with the client registration endpoint. The statement for use with the client registration endpoint. The
method by which the software statement is issued to the client or method by which the software statement is issued to the client or
developer is out of scope for this specification. developer is out of scope for this specification.
(C) The client or developer calls the client registration endpoint (C) The client or developer calls the client registration endpoint
with its desired registration metadata, optionally including the with the client's desired registration metadata, optionally
initial access token from (A) if one is required by the including the initial access token from (A) if one is required by
authorization server. the authorization server.
(D) The authorization server registers the client and returns the (D) The authorization server registers the client and returns the
client's registered metadata, a client identifier that is unique client's registered metadata, a client identifier that is unique
at the server, a set of client credentials such as a client secret at the server, a set of client credentials such as a client secret
if applicable for this client, and possibly other values. if applicable for this client, and possibly other values.
2. Client Metadata 2. Client Metadata
Clients have a set of metadata values associated with their client Clients have a set of metadata values associated with their client
identifier at an authorization server, such as the list of valid identifier at an authorization server, such as the list of valid
redirection URIs or a display name. redirection URIs or a display name.
skipping to change at page 7, line 29 skipping to change at page 6, line 36
2. Client Metadata 2. Client Metadata
Clients have a set of metadata values associated with their client Clients have a set of metadata values associated with their client
identifier at an authorization server, such as the list of valid identifier at an authorization server, such as the list of valid
redirection URIs or a display name. redirection URIs or a display name.
The client metadata values are used in two ways: The client metadata values are used in two ways:
o as input values to registration requests, and o as input values to registration requests, and
o as output values in registration responses. o as output values in registration responses.
The following client metadata fields are defined by this The following client metadata fields are defined by this
specification. The implementation and use of all client metadata specification. The implementation and use of all client metadata
fields is OPTIONAL, other than "redirect_uris". fields is OPTIONAL, unless stated otherwise.
redirect_uris redirect_uris
Array of redirection URIs for use in redirect-based flows such as Array of redirection URI values for use in redirect-based flows
the authorization code and implicit flows. As required by Section such as the authorization code and implicit flows. As required by
2 of OAuth 2.0 [RFC6749], clients using flows with redirection Section 2 of OAuth 2.0 [RFC6749], clients using flows with
MUST register their redirection URI values. Authorization servers redirection MUST register their redirection URI values.
MUST implement support for this metadata value. Authorization servers that support dynamic registration for
redirect-based flows MUST implement support for this metadata
value.
token_endpoint_auth_method token_endpoint_auth_method
The requested authentication method for the token endpoint. The requested authentication method for the token endpoint.
Values defined by this specification are: Values defined by this specification are:
* "none": The client is a public client as defined in OAuth 2.0 * "none": The client is a public client as defined in OAuth 2.0
and does not have a client secret. and does not have a client secret.
* "client_secret_post": The client uses the HTTP POST parameters * "client_secret_post": The client uses the HTTP POST parameters
defined in OAuth 2.0 section 2.3.1. defined in OAuth 2.0 section 2.3.1.
* "client_secret_basic": the client uses HTTP Basic defined in * "client_secret_basic": the client uses HTTP Basic defined in
OAuth 2.0 section 2.3.1 OAuth 2.0 section 2.3.1
Additional values can be defined via the IANA OAuth Token Endpoint Additional values can be defined via the IANA OAuth Token Endpoint
Authentication Methods Registry established in Section 5.2. Authentication Methods Registry established in Section 5.2.
Absolute URIs can also be used as values for this parameter Absolute URIs can also be used as values for this parameter
without being registered. If unspecified or omitted, the default without being registered. If unspecified or omitted, the default
is "client_secret_basic", denoting HTTP Basic Authentication is "client_secret_basic", denoting HTTP Basic Authentication
Scheme as specified in Section 2.3.1 of OAuth 2.0. Scheme as specified in Section 2.3.1 of OAuth 2.0.
grant_types grant_types
Array of OAuth 2.0 grant types that the client may use. These Array of OAuth 2.0 grant types that the client may use. These
grant types are defined as follows: grant types are defined as follows:
* "authorization_code": The Authorization Code Grant described in * "authorization_code": The Authorization Code Grant described in
OAuth 2.0 Section 4.1 OAuth 2.0 Section 4.1
* "implicit": The Implicit Grant described in OAuth 2.0
* "implicit": The Implicit Grant described in OAuth 2.0 Section Section 4.2
4.2
* "password": The Resource Owner Password Credentials Grant * "password": The Resource Owner Password Credentials Grant
described in OAuth 2.0 Section 4.3 described in OAuth 2.0 Section 4.3
* "client_credentials": The Client Credentials Grant described in * "client_credentials": The Client Credentials Grant described in
OAuth 2.0 Section 4.4 OAuth 2.0 Section 4.4
* "refresh_token": The Refresh Token Grant described in OAuth 2.0 * "refresh_token": The Refresh Token Grant described in OAuth 2.0
Section 6. Section 6.
* "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer * "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer
Grant defined in OAuth JWT Bearer Token Profiles [OAuth.JWT]. Grant defined in OAuth JWT Bearer Token Profiles [OAuth.JWT].
* "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2 * "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2
Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles
[OAuth.SAML2]. [OAuth.SAML2].
Authorization Servers MAY allow for other values as defined in Authorization Servers MAY allow for other values as defined in
grant type extensions to OAuth 2.0. The extension process is grant type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5. If the token endpoint is used described in OAuth 2.0 Section 2.5. If the token endpoint is used
in the grant type, the value of this parameter MUST be the same as in the grant type, the value of this parameter MUST be the same as
the value of the "grant_type" parameter passed to the token the value of the "grant_type" parameter passed to the token
endpoint defined in the extension. If omitted, the default is endpoint defined in the extension. If omitted, the default is
skipping to change at page 8, line 48 skipping to change at page 7, line 47
Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles
[OAuth.SAML2]. [OAuth.SAML2].
Authorization Servers MAY allow for other values as defined in Authorization Servers MAY allow for other values as defined in
grant type extensions to OAuth 2.0. The extension process is grant type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5. If the token endpoint is used described in OAuth 2.0 Section 2.5. If the token endpoint is used
in the grant type, the value of this parameter MUST be the same as in the grant type, the value of this parameter MUST be the same as
the value of the "grant_type" parameter passed to the token the value of the "grant_type" parameter passed to the token
endpoint defined in the extension. If omitted, the default is endpoint defined in the extension. If omitted, the default is
that the client will use only the "authorization_code" Grant Type. that the client will use only the "authorization_code" Grant Type.
application_type
OPTIONAL. Kind of the application. The default, if omitted, is
"web". The defined values are "native" or "web".
response_types response_types
Array of the OAuth 2.0 response types that the client may use. Array of the OAuth 2.0 response types that the client may use.
These response types are defined as follows: These response types are defined as follows:
* "code": The Authorization Code response described in OAuth 2.0 * "code": The Authorization Code response described in OAuth 2.0
Section 4.1. Section 4.1.
* "token": The Implicit response described in OAuth 2.0
* "token": The Implicit response described in OAuth 2.0 Section Section 4.2.
4.2.
Authorization servers MAY allow for other values as defined in Authorization servers MAY allow for other values as defined in
response type extensions to OAuth 2.0. The extension process is response type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5. If the authorization endpoint described in OAuth 2.0 Section 2.5. If the authorization endpoint
is used by the grant type, the value of this parameter MUST be the is used by the grant type, the value of this parameter MUST be the
same as the value of the "response_type" parameter passed to the same as the value of the "response_type" parameter passed to the
authorization endpoint defined in the extension. If omitted, the authorization endpoint defined in the extension. If omitted, the
default is that the client will use only the "code" response type. default is that the client will use only the "code" response type.
client_name client_name
Human-readable name of the client to be presented to the user Human-readable name of the client to be presented to the user
during authorization. If omitted, the authorization server MAY during authorization. If omitted, the authorization server MAY
display the raw "client_id" value to the user instead. It is display the raw "client_id" value to the user instead. It is
RECOMMENDED that clients always send this field. The value of RECOMMENDED that clients always send this field. The value of
this field MAY be internationalized, as described in Section 2.2. this field MAY be internationalized, as described in Section 2.2.
client_uri client_uri
URL of a Web page providing information about the client. If URL of a web page providing information about the client. If
present, the server SHOULD display this URL to the end user in a present, the server SHOULD display this URL to the end user in a
clickable fashion. It is RECOMMENDED that clients always send clickable fashion. It is RECOMMENDED that clients always send
this field. The value of this field MUST point to a valid web this field. The value of this field MUST point to a valid web
page. The value of this field MAY be internationalized, as page. The value of this field MAY be internationalized, as
described in Section 2.2. described in Section 2.2.
logo_uri logo_uri
URL that references a logo for the client. If present, the server URL that references a logo for the client. If present, the server
SHOULD display this image to the end user during approval. The SHOULD display this image to the end user during approval. The
value of this field MUST point to a valid image file. The value value of this field MUST point to a valid image file. The value
of this field MAY be internationalized, as described in of this field MAY be internationalized, as described in
Section 2.2. Section 2.2.
scope scope
Space separated list of scope values (as described in Section 3.3 Space separated list of scope values (as described in Section 3.3
of OAuth 2.0 [RFC6749]) that the client can use when requesting of OAuth 2.0 [RFC6749]) that the client can use when requesting
access tokens. The semantics of values in this list is service access tokens. The semantics of values in this list is service
specific. If omitted, an authorization server MAY register a specific. If omitted, an authorization server MAY register a
client with a default set of scopes. client with a default set of scopes.
contacts contacts
Array of strings representing ways to contact people responsible Array of strings representing ways to contact people responsible
for this client, typically email addresses. The authorization for this client, typically email addresses. The authorization
server MAY make these addresses available to end users for support server MAY make these addresses available to end users for support
requests for the client. requests for the client.
tos_uri tos_uri
URL that points to a human-readable Terms of Service document for URL that points to a human-readable terms of service document for
the client that describes a contractual relationship between the
end-user and the client that the end-user accepts when authorizing
the client. The authorization server SHOULD display this URL to the client. The authorization server SHOULD display this URL to
the end-user if it is given. The Terms of Service usually the end-user if it is provided. The value of this field MUST
describe a contractual relationship between the end-user and the point to a valid web page. The value of this field MAY be
client that the end-user accepts when authorizing the client. The
value of this field MUST point to a valid web page. The value of
this field MAY be internationalized, as described in Section 2.2.
policy_uri
URL that points to a human-readable Policy document for the
client. The authorization server SHOULD display this URL to the
end-user if it is given. The policy usually describes how an end-
user's data will be used by the client. The value of this field
MUST point to a valid web page. The value of this field MAY be
internationalized, as described in Section 2.2. internationalized, as described in Section 2.2.
policy_uri
URL that points to a human-readable privacy policy document that
describes how the deployment organization collects, uses, retains,
and discloses personal data. The authorization server SHOULD
display this URL to the end-user if it is provided. The value of
this field MUST point to a valid web page. The value of this
field MAY be internationalized, as described in Section 2.2.
jwks_uri jwks_uri
URL of the client's JSON Web Key Set [JWK] document containing the URL referencing the client's JSON Web Key Set [JWK] document,
client's public keys. The value of this field MUST point to a which contains the client's public keys. The value of this field
valid JWK Set document. These keys can be used by higher level MUST point to a valid JWK Set document. These keys can be used by
protocols that use signing or encryption. higher level protocols that use signing or encryption. For
instance, these keys might be used by some applications for
validating signed requests made to the token endpoint when using
JWTs for client authentication [OAuth.JWT]. Use of this parameter
is preferred over the "jwks" parameter, as it allows for easier
key rotation. The "jwks_uri" and "jwks" parameters MUST NOT be
used together.
jwks jwks
JSON Web Key Set [JWK] value containing the client's public keys. Client's JSON Web Key Set [JWK] document value, which contains the
The value of this field MUST be a JSON object containing a valid client's public keys. The value of this field MUST be a JSON
JWK Set. These keys can be used by higher level protocols that use object containing a valid JWK Set. These keys can be used by
signing or encryption. This parameter is intended to be used by higher level protocols that use signing or encryption. This
clients that cannot use the "jwks_uri" parameter. For instance, a parameter is intended to be used by clients that cannot use the
native application might not have a location to host the contents "jwks_uri" parameter, such as native clients that cannot host
of the JWK Set that would be reachable by the authorization public URLs. The "jwks_uri" and "jwks" parameters MUST NOT be
server. The "jwks_uri" and "jwks" parameters MUST NOT be used used together.
together.
software_id software_id
Identifier for the software that comprises a client. Unlike Identifier for the software that comprises a client. Unlike
"client_id", which is issued by the authorization server and may "client_id", which is issued by the authorization server and may
vary between instances, the "software_id" is asserted by the vary between instances, the "software_id" is asserted by the
client software on behalf of the software developer and is client software on behalf of the software developer and is
intended to be shared among all instances of the client software. intended to be shared among all instances of the client software.
The identifier SHOULD NOT change when software version changes or The identifier SHOULD NOT change when software version changes or
when a new installation occurs. when a new installation occurs.
software_version software_version
Version identifier for the software that comprises a client. The Version identifier for the software that comprises a client. The
value of this field is a string that is intended to be compared value of this field is a string that is intended to be compared
using string equality matching. The value of the using string equality matching. The value of the
"software_version" SHOULD change on any update to the client "software_version" SHOULD change on any update to the client
software. software.
Extensions and profiles of this specification MAY expand this list. Extensions and profiles of this specification MAY expand this list.
The authorization server MUST ignore any client metadata values sent The authorization server MUST ignore any client metadata values sent
by the client that it does not understand. by the client that it does not understand.
skipping to change at page 13, line 22 skipping to change at page 12, line 11
in many programming environments. Therefore, implementations will in many programming environments. Therefore, implementations will
need to use alternative access forms for these claims. For instance, need to use alternative access forms for these claims. For instance,
in JavaScript, if one parses the JSON as follows, "var j = in JavaScript, if one parses the JSON as follows, "var j =
JSON.parse(json);", then the member "client_name#en-us" can be JSON.parse(json);", then the member "client_name#en-us" can be
accessed using the JavaScript syntax "j["client_name#en-us"]". accessed using the JavaScript syntax "j["client_name#en-us"]".
2.3. Software Statement 2.3. Software Statement
A software statement is a JSON Web Token (JWT) [JWT] that asserts A software statement is a JSON Web Token (JWT) [JWT] that asserts
metadata values about the client software as a bundle. A set of metadata values about the client software as a bundle. A set of
claims that can be used in a software statement are defined claims that can be used in a software statement are defined in
Section 2. When presented to the authorization server as part of a Section 2. When presented to the authorization server as part of a
client registration request, the software statement MUST be digitally client registration request, the software statement MUST be digitally
signed or MACed using JWS [JWS] and MUST contain an "iss" (issuer) signed or MACed using JWS [JWS] and MUST contain an "iss" (issuer)
claim denoting the party attesting to the claims in the software claim denoting the party attesting to the claims in the software
statement. It is RECOMMENDED that software statements be digitally statement. It is RECOMMENDED that software statements be digitally
signed using the "RS256" signature algorithm, although particular signed using the "RS256" signature algorithm, although particular
applications MAY specify the use of different algorithms. applications MAY specify the use of different algorithms.
The means by which a client or developer obtains a software statement The means by which a client or developer obtains a software statement
are outside the scope of this specification. Some common methods are outside the scope of this specification. Some common methods
skipping to change at page 14, line 39 skipping to change at page 13, line 25
the client registration endpoint SHOULD allow registration requests the client registration endpoint SHOULD allow registration requests
with no authorization (which is to say, with no initial access token with no authorization (which is to say, with no initial access token
in the request). These requests MAY be rate-limited or otherwise in the request). These requests MAY be rate-limited or otherwise
limited to prevent a denial-of-service attack on the client limited to prevent a denial-of-service attack on the client
registration endpoint. registration endpoint.
3.1. Client Registration Request 3.1. Client Registration Request
This operation registers a client with the authorization server. The This operation registers a client with the authorization server. The
authorization server assigns this client a unique client identifier, authorization server assigns this client a unique client identifier,
optionally assigns a client secret, and associates the metadata given optionally assigns a client secret, and associates the metadata
in the request with the issued client identifier. The request provided in the request with the issued client identifier. The
includes any client metadata parameters being specified for the request includes any client metadata parameters being specified for
client during the registration. The authorization server MAY the client during the registration. The authorization server MAY
provision default values for any items omitted in the client provision default values for any items omitted in the client
metadata. metadata.
To register, the client or developer sends an HTTP POST to the client To register, the client or developer sends an HTTP POST to the client
registration endpoint with a content type of "application/json". The registration endpoint with a content type of "application/json". The
HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON
object and all requested client metadata values as top-level members object and all requested client metadata values as top-level members
of that JSON object. of that JSON object.
Client metadata values may also be provided in a software statement, Client metadata values may also be provided in a software statement,
skipping to change at page 17, line 32 skipping to change at page 16, line 32
The response contains the client identifier as well as the client The response contains the client identifier as well as the client
secret, if the client is a confidential client. The response MAY secret, if the client is a confidential client. The response MAY
contain additional fields as specified by extensions to this contain additional fields as specified by extensions to this
specification. specification.
client_id client_id
REQUIRED. OAuth 2.0 client identifier. It SHOULD NOT be REQUIRED. OAuth 2.0 client identifier. It SHOULD NOT be
currently valid for any other registered client, though an currently valid for any other registered client, though an
authorization server MAY issue the same client identifier to authorization server MAY issue the same client identifier to
multiple instances of a registered client, at its discretion. multiple instances of a registered client, at its discretion.
client_secret client_secret
OPTIONAL. OAuth 2.0 client secret. If issued, this MUST be OPTIONAL. OAuth 2.0 client secret. If issued, this MUST be
unique for each "client_id". This value is used by confidential unique for each "client_id". This value is used by confidential
clients to authenticate to the token endpoint as described in clients to authenticate to the token endpoint as described in
OAuth 2.0 [RFC6749] Section 2.3.1. OAuth 2.0 [RFC6749] Section 2.3.1.
client_id_issued_at client_id_issued_at
OPTIONAL. Time at which the client identifier was issued. The OPTIONAL. Time at which the client identifier was issued. The
time is represented as the number of seconds from 1970-01- time is represented as the number of seconds from
01T0:0:0Z as measured in UTC until the date/time. 1970-01-01T0:0:0Z as measured in UTC until the date/time.
client_secret_expires_at client_secret_expires_at
REQUIRED if "client_secret" is issued. Time at which the client REQUIRED if "client_secret" is issued. Time at which the client
secret will expire or 0 if it will not expire. The time is secret will expire or 0 if it will not expire. The time is
represented as the number of seconds from 1970-01-01T0:0:0Z as represented as the number of seconds from 1970-01-01T0:0:0Z as
measured in UTC until the date/time. measured in UTC until the date/time.
Additionally, the authorization server MUST return all registered Additionally, the authorization server MUST return all registered
metadata about this client, including any fields provisioned by the metadata about this client, including any fields provisioned by the
authorization server itself. The authorization server MAY reject or authorization server itself. The authorization server MAY reject or
replace any of the client's requested metadata values submitted replace any of the client's requested metadata values submitted
skipping to change at page 21, line 17 skipping to change at page 20, line 17
Client Metadata Name: Client Metadata Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner SHOULD NOT be accepted.
Client Metadata Description: Client Metadata Description:
Brief description of the metadata value (e.g., "Example Brief description of the metadata value (e.g., "Example
description"). description").
Change controller: Change controller:
For Standards Track RFCs, state "IETF". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification document(s): Specification document(s):
Reference to the document(s) that specify the token endpoint Reference to the document(s) that specify the token endpoint
authorization method, preferably including a URI that can be used authorization method, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required. relevant sections may also be included but is not required.
5.1.2. Initial Registry Contents 5.1.2. Initial Registry Contents
skipping to change at page 23, line 4 skipping to change at page 21, line 49
o Client Metadata Description: URL that points to a human-readable o Client Metadata Description: URL that points to a human-readable
Terms of Service document for the client Terms of Service document for the client
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "policy_uri" o Client Metadata Name: "policy_uri"
o Client Metadata Description: URL that points to a human-readable o Client Metadata Description: URL that points to a human-readable
Policy document for the client Policy document for the client
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "jwks_uri" o Client Metadata Name: "jwks_uri"
o Client Metadata Description: URL for the client's JSON Web Key Set o Client Metadata Description: URL referencing the client's JSON Web
[JWK] document representing the client's public keys Key Set [JWK] document representing the client's public keys
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "jwks" o Client Metadata Name: "jwks"
o Client Metadata Description: The client's JSON Web Key Set [JWK] o Client Metadata Description: Client's JSON Web Key Set [JWK]
document representing the client's public keys document representing the client's public keys
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "software_id" o Client Metadata Name: "software_id"
o Client Metadata Description: Identifier for the software that o Client Metadata Description: Identifier for the software that
comprises a client comprises a client
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
skipping to change at page 24, line 41 skipping to change at page 23, line 36
list. list.
5.2.1. Registration Template 5.2.1. Registration Template
Token Endpoint Authorization Method Name: Token Endpoint Authorization Method Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner SHOULD NOT be accepted.
Change controller: Change controller:
For Standards Track RFCs, state "IETF". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification document(s): Specification document(s):
Reference to the document(s) that specify the token endpoint Reference to the document(s) that specify the token endpoint
authorization method, preferably including a URI that can be used authorization method, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required. relevant sections may also be included but is not required.
5.2.2. Initial Registry Contents 5.2.2. Initial Registry Contents
skipping to change at page 25, line 36 skipping to change at page 24, line 28
response), the authorization server MUST require the use of a response), the authorization server MUST require the use of a
transport-layer security mechanism when sending requests to the transport-layer security mechanism when sending requests to the
registration endpoint. The server MUST support TLS 1.2 RFC 5246 registration endpoint. The server MUST support TLS 1.2 RFC 5246
[RFC5246] and/or TLS 1.0 [RFC2246] and MAY support additional [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support additional
transport-layer mechanisms meeting its security requirements. When transport-layer mechanisms meeting its security requirements. When
using TLS, the client MUST perform a TLS/SSL server certificate using TLS, the client MUST perform a TLS/SSL server certificate
check, per RFC 6125 [RFC6125]. check, per RFC 6125 [RFC6125].
For clients that use redirect-based grant types such as For clients that use redirect-based grant types such as
"authorization_code" and "implicit", authorization servers MUST "authorization_code" and "implicit", authorization servers MUST
require clients to register their "redirect_uri" values. This can require clients to register their redirection URI values. This can
help mitigate attacks where rogue actors inject and impersonate a help mitigate attacks where rogue actors inject and impersonate a
validly registered client and intercept its authorization code or validly registered client and intercept its authorization code or
tokens through an invalid redirection URI or open redirector. tokens through an invalid redirection URI or open redirector.
Additionally, in order to prevent hijacking of the return values of
the redirection, registered redirection URI values MUST be one of:
o A remote web site protected by TLS (e.g.,
https://client.example.com/oauth_redirect)
o A web site hosted on the local machine using an HTTP URI (e.g.,
http://localhost:8080/oauth_redirect)
o A non-HTTP application-specific URL that is available only to the
client application (e.g., exampleapp://oauth_redirect)
Public clients MAY register with an authorization server using this Public clients MAY register with an authorization server using this
protocol, if the authorization server's policy allows them. Public protocol, if the authorization server's policy allows them. Public
clients use a "none" value for the "token_endpoint_auth_method" clients use a "none" value for the "token_endpoint_auth_method"
metadata field and are generally used with the "implicit" grant type. metadata field and are generally used with the "implicit" grant type.
Often these clients will be short-lived in-browser applications Often these clients will be short-lived in-browser applications
requesting access to a user's resources and access is tied to a requesting access to a user's resources and access is tied to a
user's active session at the authorization server. Since such user's active session at the authorization server. Since such
clients often do not have long-term storage, it's possible that such clients often do not have long-term storage, it's possible that such
clients would need to re-register every time the browser application clients would need to re-register every time the browser application
skipping to change at page 28, line 13 skipping to change at page 27, line 13
client. client.
7. References 7. References
7.1. Normative References 7.1. Normative References
[IANA.Language] [IANA.Language]
Internet Assigned Numbers Authority (IANA), "Language Internet Assigned Numbers Authority (IANA), "Language
Subtag Registry", 2005. Subtag Registry", 2005.
[JWK] Jones, M., "JSON Web Key (JWK)", [JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
draft-ietf-jose-json-web-key (work in progress), key (work in progress), July 2014.
July 2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), July 2014. in progress), July 2014.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in (JWT)", draft-ietf-oauth-json-web-token (work in
progress), July 2014. progress), July 2014.
[OAuth.JWT] [OAuth.JWT]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer (work Authorization Grants", draft-ietf-oauth-jwt-bearer (work
in progress), April 2014. in progress), July 2014.
[OAuth.SAML2] [OAuth.SAML2]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-saml2-bearer (work Authorization Grants", draft-ietf-oauth-saml2-bearer (work
in progress), April 2014. in progress), July 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
skipping to change at page 29, line 11 skipping to change at page 28, line 11
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
RFC 6749, October 2012. 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012. Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
7.2. Informative References 7.2. Informative References
[I-D.hardjono-oauth-umacore]
Hardjono, T., "User-Managed Access (UMA) Profile of OAuth
2.0", draft-hardjono-oauth-umacore-10 (work in progress),
July 2014.
[OAuth.Registration.Management] [OAuth.Registration.Management]
Richer, J., Jones, M., Bradley, J., Machulak, M., and P. Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
Hunt, "OAuth 2.0 Dynamic Client Registration Management Hunt, "OAuth 2.0 Dynamic Client Registration Management
Protocol", draft-ietf-oauth-dyn-reg-management (work in Protocol", draft-ietf-oauth-dyn-reg-management (work in
progress), July 2014. progress), August 2014.
[OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Dynamic Client Registration 1.0", February 2014.
Appendix A. Use Cases Appendix A. Use Cases
This appendix describes different ways that this specification can be This appendix describes different ways that this specification can be
utilized, including describing some of the choices that may need to utilized, including describing some of the choices that may need to
be made. Some of the choices are independent and can be used in be made. Some of the choices are independent and can be used in
combination, whereas some of the choices are interrelated. combination, whereas some of the choices are interrelated.
A.1. Open versus Protected Dynamic Client Registration A.1. Open versus Protected Dynamic Client Registration
skipping to change at page 32, line 15 skipping to change at page 31, line 23
to various versions of this document: Amanda Anganes, Derek Atkins, to various versions of this document: Amanda Anganes, Derek Atkins,
Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov,
George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten
Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat
Sakimura, Christian Scholz, and Hannes Tschofenig. Sakimura, Christian Scholz, and Hannes Tschofenig.
Appendix C. Document History Appendix C. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-19
o Added informative references to the OpenID Connect Dynamic Client
Registration and UMA specifications in the introduction.
o Clarified the "jwks" and "jwks_uri" descriptions and included an
example situation in which they might be used.
o Removed "application_type".
o Added redirection URI usage restrictions to the Security
Considerations section, based on the client type.
o Expanded the "tos_uri" and "policy_uri" descriptions.
-18 -18
o Corrected an example HTTP response status code to be 201 Created. o Corrected an example HTTP response status code to be 201 Created.
o Said more about who issues and uses initial access tokens and o Said more about who issues and uses initial access tokens and
software statements. software statements.
o Stated that the use of an initial access token is required when o Stated that the use of an initial access token is required when
the authorization server limits the parties that can register a the authorization server limits the parties that can register a
client. client.
o Stated that the implementation and use of all client metadata o Stated that the implementation and use of all client metadata
fields is OPTIONAL, other than "redirect_uris", which MUST be used fields is OPTIONAL, other than "redirect_uris", which MUST be used
for redirect-based flows and implemented to fulfill the for redirect-based flows and implemented to fulfill the
requirement in Section 2 of OAuth 2.0. requirement in Section 2 of OAuth 2.0.
o Added the "application_type" metadata value, which had somehow o Added the "application_type" metadata value, which had somehow
been omitted. been omitted.
o Added missing default metadata values, which had somehow been o Added missing default metadata values, which had somehow been
omitted. omitted.
o Clarified that the "software_id" is ultimately asserted by the o Clarified that the "software_id" is ultimately asserted by the
client developer. client developer.
o Clarified that the "error" member is required in error responses, o Clarified that the "error" member is required in error responses,
"error_description" member is optional, and other members may be "error_description" member is optional, and other members may be
present. present.
o Added security consideration about registrations with duplicate o Added security consideration about registrations with duplicate
"software_id" and "software_version" values. "software_id" and "software_version" values.
-17 -17
o Merged draft-ietf-oauth-dyn-reg-metadata back into this document. o Merged draft-ietf-oauth-dyn-reg-metadata back into this document.
o Removed "Core" from the document title. o Removed "Core" from the document title.
o Explicitly state that all metadata members are optional. o Explicitly state that all metadata members are optional.
o Clarified language around software statements for use in o Clarified language around software statements for use in
registration context. registration context.
o Clarified that software statements need to be digitally signed or o Clarified that software statements need to be digitally signed or
MACed. MACed.
o Added a "jwks" metadata parameter to parallel the "jwks_uri" o Added a "jwks" metadata parameter to parallel the "jwks_uri"
parameter. parameter.
o Removed normative language from terminology. o Removed normative language from terminology.
o Expanded abstract and introduction. o Expanded abstract and introduction.
o Addressed review comments from several working group members. o Addressed review comments from several working group members.
-16 -16
o Replaced references to draft-jones-oauth-dyn-reg-metadata and o Replaced references to draft-jones-oauth-dyn-reg-metadata and
draft-jones-oauth-dyn-reg-management with draft-jones-oauth-dyn-reg-management with draft-ietf-oauth-dyn-
draft-ietf-oauth-dyn-reg-metadata and reg-metadata and draft-ietf-oauth-dyn-reg-management.
draft-ietf-oauth-dyn-reg-management.
o Addressed review comments by Phil Hunt and Tony Nadalin. o Addressed review comments by Phil Hunt and Tony Nadalin.
-15 -15
o Partitioned the Dynamic Client Registration specification into o Partitioned the Dynamic Client Registration specification into
core, metadata, and management specifications. This built on work core, metadata, and management specifications. This built on work
first published as draft-richer-oauth-dyn-reg-core-00 and first published as draft-richer-oauth-dyn-reg-core-00 and draft-
draft-richer-oauth-dyn-reg-management-00. richer-oauth-dyn-reg-management-00.
o Added the ability to use Software Statements. This built on work o Added the ability to use Software Statements. This built on work
first published as draft-hunt-oauth-software-statement-00 and first published as draft-hunt-oauth-software-statement-00 and
draft-hunt-oauth-client-association-00. draft-hunt-oauth-client-association-00.
o Created the IANA OAuth Registration Client Metadata registry for o Created the IANA OAuth Registration Client Metadata registry for
registering Client Metadata values. registering Client Metadata values.
o Defined Client Instance term and stated that multiple instances o Defined Client Instance term and stated that multiple instances
can use the same client identifier value under certain can use the same client identifier value under certain
circumstances. circumstances.
o Rewrote the introduction. o Rewrote the introduction.
o Rewrote the Use Cases appendix. o Rewrote the Use Cases appendix.
-14 -14
o Added software_id and software_version metadata fields o Added software_id and software_version metadata fields
o Added direct references to RFC6750 errors in read/update/delete o Added direct references to RFC6750 errors in read/update/delete
methods methods
-13 -13
o Fixed broken example text in registration request and in delete o Fixed broken example text in registration request and in delete
request request
o Added security discussion of separating clients of different grant o Added security discussion of separating clients of different grant
types types
o Fixed error reference to point to RFC6750 instead of RFC6749 o Fixed error reference to point to RFC6750 instead of RFC6749
o Clarified that servers must respond to all requests to o Clarified that servers must respond to all requests to
configuration endpoint, even if it's just an error code configuration endpoint, even if it's just an error code
o Lowercased all Terms to conform to style used in RFC6750 o Lowercased all Terms to conform to style used in RFC6750
-12 -12
o Improved definition of Initial Access Token o Improved definition of Initial Access Token
o Changed developer registration scenario to have the Initial Access o Changed developer registration scenario to have the Initial Access
Token gotten through a normal OAuth 2.0 flow Token gotten through a normal OAuth 2.0 flow
o Moved non-normative client lifecycle examples to appendix o Moved non-normative client lifecycle examples to appendix
o Marked differentiating between auth servers as out of scope o Marked differentiating between auth servers as out of scope
o Added protocol flow diagram o Added protocol flow diagram
o Added credential rotation discussion o Added credential rotation discussion
o Called out Client Registration Endpoint as an OAuth 2.0 Protected o Called out Client Registration Endpoint as an OAuth 2.0 Protected
Resource Resource
o Cleaned up several pieces of text o Cleaned up several pieces of text
-11 -11
o Added localized text to registration request and response o Added localized text to registration request and response
examples. examples.
o Removed "client_secret_jwt" and "private_key_jwt". o Removed "client_secret_jwt" and "private_key_jwt".
o Clarified "tos_uri" and "policy_uri" definitions. o Clarified "tos_uri" and "policy_uri" definitions.
o Added the OAuth Token Endpoint Authentication Methods registry for o Added the OAuth Token Endpoint Authentication Methods registry for
registering "token_endpoint_auth_method" metadata values. registering "token_endpoint_auth_method" metadata values.
o Removed uses of non-ASCII characters, per RFC formatting rules. o Removed uses of non-ASCII characters, per RFC formatting rules.
o Changed "expires_at" to "client_secret_expires_at" and "issued_at" o Changed "expires_at" to "client_secret_expires_at" and "issued_at"
to "client_id_issued_at" for greater clarity. to "client_id_issued_at" for greater clarity.
o Added explanatory text for different credentials (Initial Access o Added explanatory text for different credentials (Initial Access
Token, Registration Access Token, Client Credentials) and what Token, Registration Access Token, Client Credentials) and what
they're used for. they're used for.
o Added Client Lifecycle discussion and examples. o Added Client Lifecycle discussion and examples.
o Defined Initial Access Token in Terminology section. o Defined Initial Access Token in Terminology section.
-10 -10
o Added language to point out that scope values are service-specific o Added language to point out that scope values are service-specific
o Clarified normative language around client metadata o Clarified normative language around client metadata
o Added extensibility to token_endpoint_auth_method using absolute o Added extensibility to token_endpoint_auth_method using absolute
URIs URIs
o Added security consideration about registering redirect URIs o Added security consideration about registering redirect URIs
o Changed erroneous 403 responses to 401's with notes about token o Changed erroneous 403 responses to 401's with notes about token
handling handling
o Added example for initial registration credential o Added example for initial registration credential
-09 -09
o Added method of internationalization for Client Metadata values o Added method of internationalization for Client Metadata values
o Fixed SAML reference o Fixed SAML reference
-08 -08
o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and
x509_encryption_uri into a single jwks_uri parameter x509_encryption_uri into a single jwks_uri parameter
o Renamed grant_type to grant_types since it's a plural value o Renamed grant_type to grant_types since it's a plural value
o Formalized name of "OAuth 2.0" throughout document o Formalized name of "OAuth 2.0" throughout document
o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example
grant types grant types
o Added response_types parameter and explanatory text on its use o Added response_types parameter and explanatory text on its use
with and relationship to grant_types with and relationship to grant_types
-07 -07
o Changed registration_access_url to registration_client_uri o Changed registration_access_url to registration_client_uri
o Fixed missing text in 5.1 o Fixed missing text in 5.1
o Added Pragma: no-cache to examples o Added Pragma: no-cache to examples
o Changed "no such client" error to 403 o Changed "no such client" error to 403
o Renamed Client Registration Access Endpoint to Client o Renamed Client Registration Access Endpoint to Client
Configuration Endpoint Configuration Endpoint
o Changed all the parameter names containing "_url" to instead use o Changed all the parameter names containing "_url" to instead use
"_uri" "_uri"
o Updated example text for forming Client Configuration Endpoint URL o Updated example text for forming Client Configuration Endpoint URL
-06 -06
o Removed secret_rotation as a client-initiated action, including o Removed secret_rotation as a client-initiated action, including
removing client secret rotation endpoint and parameters. removing client secret rotation endpoint and parameters.
o Changed _links structure to single value registration_access_url. o Changed _links structure to single value registration_access_url.
o Collapsed create/update/read responses into client info response. o Collapsed create/update/read responses into client info response.
o Changed return code of create action to 201. o Changed return code of create action to 201.
o Added section to describe suggested generation and composition of o Added section to describe suggested generation and composition of
Client Registration Access URL. Client Registration Access URL.
o Added clarifying text to PUT and POST requests to specify JSON in o Added clarifying text to PUT and POST requests to specify JSON in
the body. the body.
o Added Editor's Note to DELETE operation about its inclusion. o Added Editor's Note to DELETE operation about its inclusion.
o Added Editor's Note to registration_access_url about alternate o Added Editor's Note to registration_access_url about alternate
syntax proposals. syntax proposals.
-05 -05
o changed redirect_uri and contact to lists instead of space o changed redirect_uri and contact to lists instead of space
delimited strings delimited strings
o removed operation parameter o removed operation parameter
o added _links structure o added _links structure
o made client update management more RESTful o made client update management more RESTful
o split endpoint into three parts o split endpoint into three parts
o changed input to JSON from form-encoded o changed input to JSON from form-encoded
o added READ and DELETE operations o added READ and DELETE operations
o removed Requirements section o removed Requirements section
o changed token_endpoint_auth_type back to o changed token_endpoint_auth_type back to
token_endpoint_auth_method to match OIDC who changed to match us token_endpoint_auth_method to match OIDC who changed to match us
-04 -04
o removed default_acr, too undefined in the general OAuth2 case o removed default_acr, too undefined in the general OAuth2 case
o removed default_max_auth_age, since there's no mechanism for o removed default_max_auth_age, since there's no mechanism for
supplying a non-default max_auth_age in OAuth2 supplying a non-default max_auth_age in OAuth2
o clarified signing and encryption URLs o clarified signing and encryption URLs
o changed token_endpoint_auth_method to token_endpoint_auth_type to o changed token_endpoint_auth_method to token_endpoint_auth_type to
match OIDC match OIDC
-03 -03
o added scope and grant_type claims o added scope and grant_type claims
o fixed various typos and changed wording for better clarity o fixed various typos and changed wording for better clarity
o endpoint now returns the full set of client information o endpoint now returns the full set of client information
o operations on client_update allow for three actions on metadata: o operations on client_update allow for three actions on metadata:
leave existing value, clear existing value, replace existing value leave existing value, clear existing value, replace existing value
with new value with new value
-02 -02
o Reorganized contributors and references o Reorganized contributors and references
o Moved OAuth references to RFC o Moved OAuth references to RFC
o Reorganized model/protocol sections for clarity o Reorganized model/protocol sections for clarity
o Changed terminology to "client register" instead of "client o Changed terminology to "client register" instead of "client
associate" associate"
o Specified that client_id must match across all subsequent requests o Specified that client_id must match across all subsequent requests
o Fixed RFC2XML formatting, especially on lists o Fixed RFC2XML formatting, especially on lists
-01 -01
o Merged UMA and OpenID Connect registrations into a single document o Merged UMA and OpenID Connect registrations into a single document
o Changed to form-parameter inputs to endpoint o Changed to form-parameter inputs to endpoint
o Removed pull-based registration o Removed pull-based registration
-00 -00
o Imported original UMA draft specification o Imported original UMA draft specification
Authors' Addresses Authors' Addresses
Justin Richer Justin Richer
The MITRE Corporation The MITRE Corporation
 End of changes. 143 change blocks. 
232 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/