< draft-ietf-oauth-dyn-reg-23.txt   draft-ietf-oauth-dyn-reg-24.txt >
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track M. Jones Intended status: Standards Track M. Jones
Expires: August 13, 2015 Microsoft Expires: August 24, 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
February 9, 2015 February 20, 2015
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-23 draft-ietf-oauth-dyn-reg-24
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. The resulting registration responses return a client server. 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
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 August 13, 2015. This Internet-Draft will expire on August 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 6 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Relationship between Grant Types and Response Types . . . 10 2.1. Relationship between Grant Types and Response Types . . . 10
2.2. Human Readable Client Metadata . . . . . . . . . . . . . 11 2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 11
2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12 2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13
3.1. Client Registration Request . . . . . . . . . . . . . . . 14 3.1. Client Registration Request . . . . . . . . . . . . . . . 14
3.1.1. Client Registration Request Using a Software 3.1.1. Client Registration Request Using a Software
Statement . . . . . . . . . . . . . . . . . . . . . . 15 Statement . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Client Information Response . . . . . . . . . . . . . 16 3.2.1. Client Information Response . . . . . . . . . . . . . 17
3.2.2. Client Registration Error Response . . . . . . . . . 18 3.2.2. Client Registration Error Response . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. OAuth Dynamic Registration Client Metadata Registry . . . 20 4.1. OAuth Dynamic Registration Client Metadata Registry . . . 21
4.1.1. Registration Template . . . . . . . . . . . . . . . . 20 4.1.1. Registration Template . . . . . . . . . . . . . . . . 21
4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22
4.2. OAuth Token Endpoint Authentication Methods Registry . . 23 4.2. OAuth Token Endpoint Authentication Methods Registry . . 24
4.2.1. Registration Template . . . . . . . . . . . . . . . . 24 4.2.1. Registration Template . . . . . . . . . . . . . . . . 25
4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 24 4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 31
A.1. Open versus Protected Dynamic Client Registration . . . . 29 A.1. Open versus Protected Dynamic Client Registration . . . . 31
A.1.1. Open Dynamic Client Registration . . . . . . . . . . 30 A.1.1. Open Dynamic Client Registration . . . . . . . . . . 31
A.1.2. Protected Dynamic Client Registration . . . . . . . . 30 A.1.2. Protected Dynamic Client Registration . . . . . . . . 31
A.2. Registration Without or With Software Statements . . . . 30 A.2. Registration Without or With Software Statements . . . . 32
A.2.1. Registration Without a Software Statement . . . . . . 30 A.2.1. Registration Without a Software Statement . . . . . . 32
A.2.2. Registration With a Software Statement . . . . . . . 30 A.2.2. Registration With a Software Statement . . . . . . . 32
A.3. Registration by the Client or Developer . . . . . . . . . 30 A.3. Registration by the Client or Developer . . . . . . . . . 32
A.3.1. Registration by the Client . . . . . . . . . . . . . 30 A.3.1. Registration by the Client . . . . . . . . . . . . . 32
A.3.2. Registration by the Developer . . . . . . . . . . . . 31 A.3.2. Registration by the Developer . . . . . . . . . . . . 32
A.4. Client ID per Client Instance or per Client Software . . 31 A.4. Client ID per Client Instance or per Client Software . . 32
A.4.1. Client ID per Client Software Instance . . . . . . . 31 A.4.1. Client ID per Client Software Instance . . . . . . . 32
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 . . . . . . . . . . . . . . . . . . . . . . 33
A.5. Stateful or Stateless Registration . . . . . . . . . . . 31 A.5. Stateful or Stateless Registration . . . . . . . . . . . 33
A.5.1. Stateful Client Registration . . . . . . . . . . . . 31 A.5.1. Stateful Client Registration . . . . . . . . . . . . 33
A.5.2. Stateless Client Registration . . . . . . . . . . . . 32 A.5.2. Stateless Client Registration . . . . . . . . . . . . 33
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33
Appendix C. Document History . . . . . . . . . . . . . . . . . . 32 Appendix C. Document History . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 4, line 26
This specification uses the terms "access token", "authorization This specification uses the terms "access token", "authorization
code", "authorization endpoint", "authorization grant", code", "authorization endpoint", "authorization grant",
"authorization server", "client", "client identifier", "client "authorization server", "client", "client identifier", "client
secret", "grant type", "protected resource", "redirection URI", secret", "grant type", "protected resource", "redirection URI",
"refresh token", "resource owner", "resource server", "response "refresh token", "resource owner", "resource server", "response
type", and "token endpoint" defined by OAuth 2.0 [RFC6749] and uses type", and "token endpoint" defined by OAuth 2.0 [RFC6749] and uses
the term "Claim" defined by JSON Web Token (JWT) [JWT]. the term "Claim" defined by JSON Web Token (JWT) [JWT].
This specification defines the following terms: This specification defines the following terms:
Client Developer
The person or organization that builds a client software package
and prepares it for distribution.
Client Instance
A deployed instance of a piece of client software.
Client Software Client Software
Software implementing an OAuth 2.0 client. Software implementing an OAuth 2.0 client.
Client Instance
A deployed instance of a piece of client software.
Client Developer
The person or organization that builds a client software package
and prepares it for distribution. At the time of building the
client, the developer is often not aware of who the deploying
service provider organizations will be. Client developers will
need to use dynamic registration when they are unable to predict
aspects of the software, such as the deployment URLs, at compile
time. For instance, this can occur when the software API
publisher and the deploying organization are not the same.
Client Registration Endpoint Client Registration Endpoint
OAuth 2.0 endpoint through which a client can be registered at an OAuth 2.0 endpoint through which a client can be registered at an
authorization server. The means by which the URL for this authorization server. The means by which the URL for this
endpoint is obtained are out of scope for this specification. endpoint is obtained are out of scope for this specification.
Initial Access Token Initial Access Token
OAuth 2.0 access token optionally issued by an authorization OAuth 2.0 access token optionally issued by an authorization
server to a developer or client and used to authorize calls to the server to a developer or client and used to authorize calls to the
client registration endpoint. The type and format of this token client registration endpoint. The type and format of this token
are likely service-specific and are out of scope for this are likely service-specific and are out of scope for this
specification. The means by which the authorization server issues specification. The means by which the authorization server issues
skipping to change at page 4, line 47 skipping to change at page 5, line 4
Initial Access Token Initial Access Token
OAuth 2.0 access token optionally issued by an authorization OAuth 2.0 access token optionally issued by an authorization
server to a developer or client and used to authorize calls to the server to a developer or client and used to authorize calls to the
client registration endpoint. The type and format of this token client registration endpoint. The type and format of this token
are likely service-specific and are out of scope for this are likely service-specific and are out of scope for this
specification. The means by which the authorization server issues specification. The means by which the authorization server issues
this token as well as the means by which the registration endpoint this token as well as the means by which the registration endpoint
validates this token are out of scope for this specification. Use validates this token are out of scope for this specification. Use
of an initial access token is required when the authorization of an initial access token is required when the authorization
server limits the parties that can register a client. server limits the parties that can register a client.
Deployment Organization Deployment Organization
An administrative security domain under which a software API is An administrative security domain under which a software API
deployed and protected by an OAuth 2.0 framework. In simple cloud (service) is deployed and protected by an OAuth 2.0 framework. In
deployments, the software API publisher and the deployment some OAuth scenarios, the deployment organization and the software
organization may be the same. In other scenarios, a software API publisher are the same. In these cases, the deploying
publisher may be working with many different deployment organization will often have a close relationship with client
organizations. software developers. In many other cases, the definer of the
service may be an independent third-party publisher or a standards
organization. When working to a published specification for an
API, the client software developer is unable to have a prior
relationship with the potentially many deployment organizations
deploying the software API (service).
Software API Deployment Software API Deployment
A deployed instance of a software API that is protected by OAuth A deployed instance of a software API that is protected by OAuth
2.0 in a particular deployment organization domain. For any 2.0 (a protected resource) in a particular deployment organization
particular software API, there may be one or more deployments. A domain. For any particular software API, there may be one or more
software API deployment typically has an associated OAuth 2.0 deployments. A software API deployment typically has an
authorization server as well as a client registration endpoint. associated OAuth 2.0 authorization server as well as a client
The means by which endpoints are obtained are out of scope for registration endpoint. The means by which endpoints are obtained
this specification. are out of scope for this specification.
Software API Publisher Software API Publisher
The organization that defines a particular web accessible API that The organization that defines a particular web accessible API that
may deployed in one or more deployment environments. A publisher may be deployed in one or more deployment environments. A
may be any commercial, public, private, or open source publisher may be any standards body, commercial, public, private,
organization that is responsible for publishing and distributing or open source organization that is responsible for publishing and
software that may be protected via OAuth 2.0. In some cases a distributing software and API specifications that may be protected
software API publisher and a client developer may be the same via OAuth 2.0. In some cases, a software API publisher and a
organization. client developer may be the same organization. At the time of
publication of a web accessible API, the software publisher often
does not have a prior relationship with the deploying
organizations.
Software Statement Software Statement
Digitally signed or MACed JSON Web Token (JWT) [JWT] that asserts Digitally signed or MACed JSON Web Token (JWT) [JWT] that asserts
metadata values about the client software. In some cases, a metadata values about the client software. In some cases, a
software statement will be issued directly by the client software statement will be issued directly by the client
developer. In other cases, a software statement will be issued by developer. In other cases, a software statement will be issued by
a third party organization for use by the client developer. In a third party organization for use by the client developer. In
both cases, the trust relationship the authorization server has both cases, the trust relationship the authorization server has
with the issuer of the software statement is intended to be used with the issuer of the software statement is intended to be used
as an input to the evaluation of whether the registration request as an input to the evaluation of whether the registration request
is accepted. A software statement can be presented to an is accepted. A software statement can be presented to an
skipping to change at page 8, line 20 skipping to change at page 8, line 33
Section 4.2. Section 4.2.
If the authorization endpoint is used by the grant type, the value If the authorization endpoint is used by the grant type, the value
of this parameter MUST be the same as the value of the of this parameter MUST be the same as the value of the
"response_type" parameter passed to the authorization endpoint "response_type" parameter passed to the authorization endpoint
defined in the grant type definition. Authorization servers MAY defined in the grant type definition. Authorization servers MAY
allow for other values as defined in the grant type extension allow for other values as defined in the grant type extension
process is described in OAuth 2.0 Section 2.5. If omitted, the process is described in OAuth 2.0 Section 2.5. 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 end-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 end-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 contact addresses available to end-users for
requests for the client. support requests for the client. See Section 6 for information on
Privacy Considerations.
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 the client that describes a contractual relationship between the
end-user and the client that the end-user accepts when authorizing 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 provided. The value of this field MUST 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 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 policy_uri
URL that points to a human-readable privacy policy document that URL that points to a human-readable privacy policy document that
skipping to change at page 9, line 37 skipping to change at page 10, line 4
jwks jwks
Client's JSON Web Key Set [JWK] document value, which contains the Client's JSON Web Key Set [JWK] document value, which contains the
client's public keys. The value of this field MUST be a JSON client's public keys. The value of this field MUST be a JSON
object containing a valid JWK Set. These keys can be used by object containing a valid JWK Set. These keys can be used by
higher level protocols that use signing or encryption. This higher level protocols that use signing or encryption. This
parameter is intended to be used by clients that cannot use the parameter is intended to be used by clients that cannot use the
"jwks_uri" parameter, such as native clients that cannot host "jwks_uri" parameter, such as native clients that cannot host
public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both
be present in the same request or response. be present in the same request or response.
software_id software_id
Identifier for the software that comprises a client. Unlike A unique identifier (e.g. a UUID) assigned by the client developer
"client_id", which is issued by the authorization server and may or software publisher used by registration endpoints to identify
vary between instances, the "software_id" is asserted by the the client software to be dynamically registered. Unlike
client software on behalf of the software developer and is "client_id", which is issued by the authorization server and
intended to be shared among all instances of the client software. SHOULD vary between instances, the "software_id" SHOULD remain the
The identifier SHOULD NOT change when software version changes or same for all instances of the client software. The "software_id"
when a new installation occurs. SHOULD remain the same across multiple updates or versions of the
same piece of software. The value of this field is not intended
to be human-readable and is usually opaque to the client and
authorization server.
software_version software_version
Version identifier for the software that comprises a client. The A version identifier for the client software identified by
value of this field is a string that is intended to be compared "software_id". The value of the "software_version" SHOULD change
using string equality matching. The value of the on any update to the client software identified by the same
"software_version" SHOULD change on any update to the client "software_id". The value of this field is a string that is
software. intended to be compared using string equality matching. The value
of this field is not intended to be human readable and is usually
opaque to the client and authorization server.
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.
Client metadata values can either be communicated directly in the Client metadata values can either be communicated directly in the
body of a registration request, as described in Section 3.1, or body of a registration request, as described in Section 3.1, or
included as claims in a software statement, as described in included as claims in a software statement, as described in
Section 2.3, or a mixture of both. If the same client metadata name Section 2.3, or a mixture of both. If the same client metadata name
is present in both locations and the software statement is trusted by is present in both locations and the software statement is trusted by
skipping to change at page 11, line 5 skipping to change at page 11, line 22
| client_credentials | (none) | | client_credentials | (none) |
| refresh_token | (none) | | refresh_token | (none) |
| urn:ietf:params:oauth:grant-type:jwt-bearer | (none) | | urn:ietf:params:oauth:grant-type:jwt-bearer | (none) |
| urn:ietf:params:oauth:grant-type:saml2-bearer | (none) | | urn:ietf:params:oauth:grant-type:saml2-bearer | (none) |
+-----------------------------------------------+-------------------+ +-----------------------------------------------+-------------------+
Extensions and profiles of this document that introduce new values to Extensions and profiles of this document that introduce new values to
either the "grant_types" or "response_types" parameter MUST document either the "grant_types" or "response_types" parameter MUST document
all correspondences between these two parameter types. all correspondences between these two parameter types.
2.2. Human Readable Client Metadata 2.2. Human-Readable Client Metadata
Human-readable client metadata values and client metadata values that Human-readable client metadata values and client metadata values that
reference human-readable values MAY be represented in multiple reference human-readable values MAY be represented in multiple
languages and scripts. For example, the values of fields such as languages and scripts. For example, the values of fields such as
"client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri" "client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri"
might have multiple locale-specific values in some client might have multiple locale-specific values in some client
registrations to facilitate use in different locations. registrations to facilitate use in different locations.
To specify the languages and scripts, BCP47 [RFC5646] language tags To specify the languages and scripts, BCP47 [RFC5646] language tags
are added to client metadata member names, delimited by a # are added to client metadata member names, delimited by a #
skipping to change at page 13, line 30 skipping to change at page 13, line 46
required in this case, are beyond the scope of this specification. required in this case, are beyond the scope of this specification.
3. Client Registration Endpoint 3. Client Registration Endpoint
The client registration endpoint is an OAuth 2.0 endpoint defined in The client registration endpoint is an OAuth 2.0 endpoint defined in
this document that is designed to allow a client to be registered this document that is designed to allow a client to be registered
with the authorization server. The client registration endpoint MUST with the authorization server. The client registration endpoint MUST
accept HTTP POST messages with request parameters encoded in the accept HTTP POST messages with request parameters encoded in the
entity body using the "application/json" format. The client entity body using the "application/json" format. The client
registration endpoint MUST be protected by a transport-layer security registration endpoint MUST be protected by a transport-layer security
mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246] and mechanism, as described in Section 5.
MAY support additional transport-layer mechanisms meeting its
security requirements. When using TLS, the client MUST perform a
TLS/SSL server certificate check, per RFC 6125 [RFC6125].
Implementation security considerations can be found in
Recommendations for Secure Use of TLS and DTLS [TLS.BCP].
The client registration endpoint MAY be an OAuth 2.0 protected The client registration endpoint MAY be an OAuth 2.0 protected
resource and accept an initial access token in the form of an OAuth resource and accept an initial access token in the form of an OAuth
2.0 [RFC6749] access token to limit registration to only previously 2.0 [RFC6749] access token to limit registration to only previously
authorized parties. The method by which the initial access token is authorized parties. The method by which the initial access token is
obtained by the client or developer is generally out-of-band and is obtained by the client or developer is generally out-of-band and is
out of scope for this specification. The method by which the initial out of scope for this specification. The method by which the initial
access token is verified and validated by the client registration access token is verified and validated by the client registration
endpoint is out of scope for this specification. endpoint is out of scope for this specification.
skipping to change at page 16, line 8 skipping to change at page 17, line 6
precedence over those conveyed using plain JSON elements. precedence over those conveyed using plain JSON elements.
Software statements are included in the requesting JSON object using Software statements are included in the requesting JSON object using
this OPTIONAL member: this OPTIONAL member:
software_statement software_statement
A software statement containing client metadata values about the A software statement containing client metadata values about the
client software as claims. client software as claims.
In the following example, some registration parameters are conveyed In the following example, some registration parameters are conveyed
as claims in a software statement from the example in the Section 2.3 as claims in a software statement from the example in Section 2.3,
section, while some values specific to the client instance are while some values specific to the client instance are conveyed as
conveyed as regular parameters (with line wraps within values for regular parameters (with line wraps within values for display
display purposes only): purposes only):
POST /register HTTP/1.1 POST /register HTTP/1.1
Content-Type: application/json Content-Type: application/json
Accept: application/json Accept: application/json
Host: server.example.com Host: server.example.com
{ {
"redirect_uris":[ "redirect_uris":[
"https://client.example.org/callback", "https://client.example.org/callback",
"https://client.example.org/callback2" "https://client.example.org/callback2"
skipping to change at page 25, line 9 skipping to change at page 26, line 9
Since requests to the client registration endpoint result in the Since requests to the client registration endpoint result in the
transmission of clear-text credentials (in the HTTP request and transmission of clear-text credentials (in the HTTP request and
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 MAY support additional transport-layer mechanisms [RFC5246] and MAY support additional transport-layer mechanisms
meeting its security requirements. When using TLS, the client MUST meeting its security requirements. When using TLS, the client MUST
perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125].
Implementation security considerations can be found in Implementation security considerations can be found in
Recommendations for Secure Use of TLS and DTLS [TLS.BCP]. Recommendations for Secure Use of TLS and DTLS
[I-D.ietf-uta-tls-bcp].
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 redirection 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 Additionally, in order to prevent hijacking of the return values of
the redirection, registered redirection URI values MUST be one of: the redirection, registered redirection URI values MUST be one of:
skipping to change at page 26, line 5 skipping to change at page 27, line 6
Since different OAuth 2.0 grant types have different security and Since different OAuth 2.0 grant types have different security and
usage parameters, an authorization server MAY require separate usage parameters, an authorization server MAY require separate
registrations for a piece of software to support multiple grant registrations for a piece of software to support multiple grant
types. For instance, an authorization server might require that all types. For instance, an authorization server might require that all
clients using the "authorization_code" grant type make use of a clients using the "authorization_code" grant type make use of a
client secret for the "token_endpoint_auth_method", but any clients client secret for the "token_endpoint_auth_method", but any clients
using the "implicit" grant type do not use any authentication at the using the "implicit" grant type do not use any authentication at the
token endpoint. In such a situation, a server MAY disallow clients token endpoint. In such a situation, a server MAY disallow clients
from registering for both the "authorization_code" and "implicit" from registering for both the "authorization_code" and "implicit"
grant types simultaneously. Similarly, the "authorization_code" grant types simultaneously. Similarly, the "authorization_code"
grant type is used to represent access on behalf of an end user, but grant type is used to represent access on behalf of an end-user, but
the "client_credentials" grant type represents access on behalf of the "client_credentials" grant type represents access on behalf of
the client itself. For security reasons, an authorization server the client itself. For security reasons, an authorization server
could require that different scopes be used for these different use could require that different scopes be used for these different use
cases, and as a consequence it MAY disallow these two grant types cases, and as a consequence it MAY disallow these two grant types
from being registered together by the same client. In all of these from being registered together by the same client. In all of these
cases, the authorization server would respond with an cases, the authorization server would respond with an
"invalid_client_metadata" error response. "invalid_client_metadata" error response.
Unless used as a claim in a software statement, the authorization Unless used as a claim in a software statement, the authorization
server MUST treat all client metadata as self-asserted. For server MUST treat all client metadata as self-asserted. For
skipping to change at page 26, line 27 skipping to change at page 27, line 28
client that it is trying to impersonate. Additionally, a rogue client that it is trying to impersonate. Additionally, a rogue
client might try to use the software identifier or software version client might try to use the software identifier or software version
of a legitimate client to attempt to associate itself on the of a legitimate client to attempt to associate itself on the
authorization server with instances of the legitimate client. To authorization server with instances of the legitimate client. To
counteract this, an authorization server needs to take steps to counteract this, an authorization server needs to take steps to
mitigate this risk by looking at the entire registration request and mitigate this risk by looking at the entire registration request and
client configuration. For instance, an authorization server could client configuration. For instance, an authorization server could
issue a warning if the domain/site of the logo doesn't match the issue a warning if the domain/site of the logo doesn't match the
domain/site of redirection URIs. An authorization server could also domain/site of redirection URIs. An authorization server could also
refuse registration requests from a known software identifier that is refuse registration requests from a known software identifier that is
requesting different redirection URIs or a different client homepage requesting different redirection URIs or a different client URI. An
URI. An authorization server can also present warning messages to authorization server can also present warning messages to end-users
end users about dynamically registered clients in all cases, about dynamically registered clients in all cases, especially if such
especially if such clients have been recently registered or have not clients have been recently registered or have not been trusted by any
been trusted by any users at the authorization server before. users at the authorization server before.
In a situation where the authorization server is supporting open In a situation where the authorization server is supporting open
client registration, it must be extremely careful with any URL client registration, it must be extremely careful with any URL
provided by the client that will be displayed to the user (e.g. provided by the client that will be displayed to the user (e.g.
"logo_uri", "tos_uri", "client_uri", and "policy_uri"). For "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For
instance, a rogue client could specify a registration request with a instance, a rogue client could specify a registration request with a
reference to a drive-by download in the "policy_uri". The reference to a drive-by download in the "policy_uri". The
authorization server SHOULD check to see if the "logo_uri", authorization server SHOULD check to see if the "logo_uri",
"tos_uri", "client_uri", and "policy_uri" have the same host and "tos_uri", "client_uri", and "policy_uri" have the same host and
scheme as the those defined in the array of "redirect_uris" and that scheme as the those defined in the array of "redirect_uris" and that
skipping to change at page 27, line 47 skipping to change at page 28, line 48
client. client.
6. Privacy Considerations 6. Privacy Considerations
As the protocol described in this specification deals almost As the protocol described in this specification deals almost
exclusively with information about software and not about people, exclusively with information about software and not about people,
there are very few privacy concerns for its use. The notable there are very few privacy concerns for its use. The notable
exception is the "contacts" field as defined in Client Metadata exception is the "contacts" field as defined in Client Metadata
(Section 2), which contains contact information for the developers or (Section 2), which contains contact information for the developers or
other parties responsible for the client software. These values are other parties responsible for the client software. These values are
intended to be displayed to end users and will be available to the intended to be displayed to end-users and will be available to the
administrators of the authorization server. As such, the developer administrators of the authorization server. As such, the developer
may wish to provide an email address or other contact information may wish to provide an email address or other contact information
expressly dedicated to the purpose of supporting the client instead expressly dedicated to the purpose of supporting the client instead
of using their personal or professional addresses. Alternatively, of using their personal or professional addresses. Alternatively,
the developer may wish to provide a collective email address for the the developer may wish to provide a collective email address for the
client to allow for continuing contact and support of the client client to allow for continuing contact and support of the client
software after the developer moves on and someone else takes over software after the developer moves on and someone else takes over
that responsibility. that responsibility.
In general, the metadata for a client, such as the client name and
software identifier, are common across all instances of a piece of
client software and therefore pose no privacy issues for end-users.
Client identifiers, on the other hand, are often unique to a specific
instance of a client. For clients such as web sites that are used by
many users, there may not be significant privacy concerns regarding
the client identifier, but for clients such as native applications
that are installed on a single end-user's device, the client
identifier could be uniquely tracked during OAuth 2.0 transactions
and its use tied to that single end-user. However, as the client
software still needs to be authorized by a resource owner through an
OAuth 2.0 authorization grant, this type of tracking can occur
whether or not the client identifier is unique by correlating the
authenticated resource owner with the requesting client identifier.
Note that clients are forbidden by this specification from creating
their own client identifier. If the client were able to do so, an
individual client instance could be tracked across multiple colluding
authorization servers, leading to privacy and security issues.
Additionally, client identifiers are generally issued uniquely per
registration request, even for the same instance of software. In
this way, an application could marginally improve privacy by
registering multiple times and appearing to be completely separate
applications. However, this technique does incur significant
usability cost in the form of requiring multiple authorizations per
resource owner and is therefore unlikely to be used in practice.
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)", draft-ietf-jose-json-web- [JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key (work in progress), July 2014. key (work in progress), January 2015.
[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), January 2015.
[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), January 2015.
[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), July 2014. in progress), November 2015.
[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), July 2014. in progress), November 2015.
[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.
[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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 29, line 27 skipping to change at page 31, line 12
[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] [I-D.hardjono-oauth-umacore]
Hardjono, T., "User-Managed Access (UMA) Profile of OAuth Hardjono, T., "User-Managed Access (UMA) Profile of OAuth
2.0", draft-hardjono-oauth-umacore-10 (work in progress), 2.0", draft-hardjono-oauth-umacore-10 (work in progress),
July 2014. July 2014.
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-09 (work in progress), February 2015.
[OAuth.Registration.Management] [OAuth.Registration.Management]
Richer, J., Jones, M., Bradley, J., and M. Machulak, Richer, J., Jones, M., Bradley, J., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Management "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), August 2014. progress), February 2015.
[OpenID.Registration] [OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Dynamic Client Registration 1.0", February 2014. Dynamic Client Registration 1.0", November 2014.
[TLS.BCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", November
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
A.1.1. Open Dynamic Client Registration A.1.1. Open Dynamic Client Registration
Authorization servers that support open registration allow Authorization servers that support open registration allow
registrations to be made with no initial access token. This allows registrations to be made with no initial access token. This allows
all client software to register with the authorization server. all client software to register with the authorization server.
A.1.2. Protected Dynamic Client Registration A.1.2. Protected Dynamic Client Registration
Authorization servers that support protected registration require Authorization servers that support protected registration require
that an initial access token be used when making registration that an initial access token be used when making registration
skipping to change at page 32, line 30 skipping to change at page 34, line 12
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 ]]
-24
o Clarified some party definitions.
o Clarified the opaqueness of software_id and software_statement.
o Created a forward pointer to the Security Considerations section
for TLS requirements on the registration endpoint.
o Added a forward pointer to the Privacy Considerations section for
the contacts field.
o Wrote privacy considerations about client_id tracking.
-23 -23
o Updated author information. o Updated author information.
-22 -22
o Reorganized registration response sections. o Reorganized registration response sections.
o Addressed shepherd comments. o Addressed shepherd comments.
o Added concrete JWK set to example. o Added concrete JWK set to example.
 End of changes. 39 change blocks. 
111 lines changed or deleted 167 lines changed or added

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