draft-ietf-oauth-dyn-reg-29.txt   draft-ietf-oauth-dyn-reg-30.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: November 6, 2015 Microsoft Expires: November 29, 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
May 5, 2015 May 28, 2015
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-29 draft-ietf-oauth-dyn-reg-30
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 November 6, 2015. This Internet-Draft will expire on November 29, 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 6
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 6 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Relationship between Grant Types and Response Types . . . 11 2.1. Relationship between Grant Types and Response Types . . . 11
2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 11 2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 12
2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12 2.3. Software Statement . . . . . . . . . . . . . . . . . . . 13
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 14 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 14
3.1. Client Registration Request . . . . . . . . . . . . . . . 14 3.1. Client Registration Request . . . . . . . . . . . . . . . 15
3.1.1. Client Registration Request Using a Software 3.1.1. Client Registration Request Using a Software
Statement . . . . . . . . . . . . . . . . . . . . . . 16 Statement . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Client Information Response . . . . . . . . . . . . . 17 3.2.1. Client Information Response . . . . . . . . . . . . . 18
3.2.2. Client Registration Error Response . . . . . . . . . 19 3.2.2. Client Registration Error Response . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
4.1. OAuth Dynamic Client Registration Metadata Registry . . . 21 4.1. OAuth Dynamic Client Registration Metadata Registry . . . 22
4.1.1. Registration Template . . . . . . . . . . . . . . . . 22 4.1.1. Registration Template . . . . . . . . . . . . . . . . 23
4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22 4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 23
4.2. OAuth Token Endpoint Authentication Methods Registry . . 25 4.2. OAuth Token Endpoint Authentication Methods Registry . . 26
4.2.1. Registration Template . . . . . . . . . . . . . . . . 25 4.2.1. Registration Template . . . . . . . . . . . . . . . . 26
4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 26 4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 32 7.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 33
A.1. Open versus Protected Dynamic Client Registration . . . . 32 A.1. Open versus Protected Dynamic Client Registration . . . . 33
A.1.1. Open Dynamic Client Registration . . . . . . . . . . 32 A.1.1. Open Dynamic Client Registration . . . . . . . . . . 33
A.1.2. Protected Dynamic Client Registration . . . . . . . . 32 A.1.2. Protected Dynamic Client Registration . . . . . . . . 33
A.2. Registration Without or With Software Statements . . . . 33 A.2. Registration Without or With Software Statements . . . . 34
A.2.1. Registration Without a Software Statement . . . . . . 33 A.2.1. Registration Without a Software Statement . . . . . . 34
A.2.2. Registration With a Software Statement . . . . . . . 33 A.2.2. Registration With a Software Statement . . . . . . . 34
A.3. Registration by the Client or Developer . . . . . . . . . 33 A.3. Registration by the Client or Developer . . . . . . . . . 34
A.3.1. Registration by the Client . . . . . . . . . . . . . 33 A.3.1. Registration by the Client . . . . . . . . . . . . . 34
A.3.2. Registration by the Developer . . . . . . . . . . . . 33 A.3.2. Registration by the Developer . . . . . . . . . . . . 34
A.4. Client ID per Client Instance or per Client Software . . 33 A.4. Client ID per Client Instance or per Client Software . . 34
A.4.1. Client ID per Client Software Instance . . . . . . . 34 A.4.1. Client ID per Client Software Instance . . . . . . . 34
A.4.2. Client ID Shared Among All Instances of Client A.4.2. Client ID Shared Among All Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . 34 Software . . . . . . . . . . . . . . . . . . . . . . 35
A.5. Stateful or Stateless Registration . . . . . . . . . . . 34 A.5. Stateful or Stateless Registration . . . . . . . . . . . 35
A.5.1. Stateful Client Registration . . . . . . . . . . . . 34 A.5.1. Stateful Client Registration . . . . . . . . . . . . 35
A.5.2. Stateless Client Registration . . . . . . . . . . . . 34 A.5.2. Stateless Client Registration . . . . . . . . . . . . 35
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 35 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 35
Appendix C. Document History . . . . . . . . . . . . . . . . . . 35 Appendix C. Document History . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0 In order for an OAuth 2.0 [RFC6749] 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 22 skipping to change at page 4, line 22
are case sensitive. are case sensitive.
1.2. Terminology 1.2. Terminology
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) [RFC7519].
This specification defines the following terms: This specification defines the following terms:
Client Software Client Software
Software implementing an OAuth 2.0 client. Software implementing an OAuth 2.0 client.
Client Instance Client Instance
A deployed instance of a piece of client software. A deployed instance of a piece of client software.
Client Developer Client Developer
The person or organization that builds a client software package The person or organization that builds a client software package
and prepares it for distribution. At the time of building the and prepares it for distribution. At the time of building the
client, the developer is often not aware of who the deploying client, the developer is often not aware of who the deploying
service provider organizations will be. Client developers will service provider organizations will be. Client developers will
need to use dynamic registration when they are unable to predict need to use dynamic registration when they are unable to predict
aspects of the software, such as the deployment URLs, at compile aspects of the software, such as the deployment URLs, at compile
time. For instance, this can occur when the software API time. For instance, this can occur when the software API
publisher and the deploying organization are not the same. 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
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.
skipping to change at page 5, line 36 skipping to change at page 5, line 42
The organization that defines a particular web accessible API that The organization that defines a particular web accessible API that
may be deployed in one or more deployment environments. A may be deployed in one or more deployment environments. A
publisher may be any standards body, commercial, public, private, publisher may be any standards body, commercial, public, private,
or open source organization that is responsible for publishing and or open source organization that is responsible for publishing and
distributing software and API specifications that may be protected distributing software and API specifications that may be protected
via OAuth 2.0. In some cases, a software API publisher and a via OAuth 2.0. In some cases, a software API publisher and a
client developer may be the same organization. At the time of client developer may be the same organization. At the time of
publication of a web accessible API, the software publisher often publication of a web accessible API, the software publisher often
does not have a prior relationship with the deploying does not have a prior relationship with the deploying
organizations. organizations.
Software Statement Software Statement
Digitally signed or MACed JSON Web Token (JWT) [JWT] that asserts Digitally signed or MACed JSON Web Token (JWT) [RFC7519] that
metadata values about the client software. In some cases, a asserts metadata values about the client software. In some cases,
software statement will be issued directly by the client a 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
authorization server as part of a client registration request. authorization server as part of a client registration request.
1.3. Protocol Flow 1.3. Protocol Flow
+--------(A)- Initial Access Token (OPTIONAL) +--------(A)- Initial Access Token (OPTIONAL)
| |
| +----(B)- Software Statement (OPTIONAL) | +----(B)- Software Statement (OPTIONAL)
| | | |
v v v v
+-----------+ +---------------+ +-----------+ +---------------+
| |--(C)- Client Registration Request -->| Client | | |--(C)- Client Registration Request -->| Client |
| Client or | | Registration | | Client or | | Registration |
| Developer |<-(D)- Client Information Response ---| Endpoint | | Developer |<-(D)- Client Information Response ---| Endpoint |
| | or Client Error Response +---------------+ | | or Client Error Response +---------------+
skipping to change at page 7, line 24 skipping to change at page 7, line 36
[RFC7159] representations. [RFC7159] representations.
redirect_uris redirect_uris
Array of redirection URI strings for use in redirect-based flows Array of redirection URI strings for use in redirect-based flows
such as the authorization code and implicit flows. As required by such as the authorization code and implicit flows. As required by
Section 2 of OAuth 2.0 [RFC6749], clients using flows with Section 2 of OAuth 2.0 [RFC6749], clients using flows with
redirection MUST register their redirection URI values. redirection MUST register their redirection URI values.
Authorization servers that support dynamic registration for Authorization servers that support dynamic registration for
redirect-based flows MUST implement support for this metadata redirect-based flows MUST implement support for this metadata
value. value.
token_endpoint_auth_method token_endpoint_auth_method
String indicator of the requested authentication method for the String indicator of the requested authentication method for the
token endpoint. Values defined by this specification are: token endpoint. 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 4.2. Authentication Methods Registry established in Section 4.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 type strings that the client can use at Array of OAuth 2.0 grant type strings that the client can use at
the token endpoint. These grant types are defined as follows: the token endpoint. These 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 4.2 Section 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 [RFC7523].
* "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]. [RFC7522].
If the token endpoint is used in the grant type, the value of this If the token endpoint is used in the grant type, the value of this
parameter MUST be the same as the value of the "grant_type" parameter MUST be the same as the value of the "grant_type"
parameter passed to the token endpoint defined in the grant type parameter passed to the token endpoint defined in the grant type
definition. Authorization servers MAY allow for other values as definition. Authorization servers MAY allow for other values as
defined in the grant type extension process described in OAuth 2.0 defined in the grant type extension process described in OAuth 2.0
Section 2.5. If omitted, the default behavior is that the client Section 2.5. If omitted, the default behavior is that the client
will use only the "authorization_code" Grant Type. will use only the "authorization_code" Grant Type.
response_types response_types
Array of the OAuth 2.0 response type strings that the client can Array of the OAuth 2.0 response type strings that the client can
use at the authorization endpoint. These response types are use at the authorization endpoint. These response types are
defined as follows: 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 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.
skipping to change at page 8, line 37 skipping to change at page 9, line 15
* "token": The implicit response described in OAuth 2.0 * "token": The implicit response described in OAuth 2.0
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 string name of the client to be presented to the Human-readable string name of the client to be presented to the
end-user during authorization. If omitted, the authorization end-user during authorization. If omitted, the authorization
server MAY display the raw "client_id" value to the end-user server MAY display the raw "client_id" value to the end-user
instead. It is RECOMMENDED that clients always send this field. instead. It is RECOMMENDED that clients always send this field.
The value of this field MAY be internationalized, as described in The value of this field MAY be internationalized, as described in
Section 2.2. Section 2.2.
client_uri client_uri
URL string of a web page providing information about the client. URL string of a web page providing information about the client.
If present, the server SHOULD display this URL to the end-user in If present, the server SHOULD display this URL to the end-user in
a clickable fashion. It is RECOMMENDED that clients always send a 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 string that references a logo for the client. If present, the URL string that references a logo for the client. If present, the
server SHOULD display this image to the end-user during approval. server SHOULD display this image to the end-user during approval.
The value of this field MUST point to a valid image file. The The value of this field MUST point to a valid image file. The
value of this field MAY be internationalized, as described in value of this field MAY be internationalized, as described in
Section 2.2. Section 2.2.
scope scope
String containing a space separated list of scope values (as String containing a space separated list of scope values (as
described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client
can use when requesting access tokens. The semantics of values in can use when requesting access tokens. The semantics of values in
this list is service specific. If omitted, an authorization this list is service specific. If omitted, an authorization
server MAY register a client with a default set of scopes. server MAY register a 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 contact addresses available to end-users for server MAY make these contact addresses available to end-users for
support requests for the client. See Section 6 for information on support requests for the client. See Section 6 for information on
Privacy Considerations. Privacy Considerations.
tos_uri tos_uri
URL string that points to a human-readable terms of service URL string that points to a human-readable terms of service
document for the client that describes a contractual relationship document for the client that describes a contractual relationship
between the end-user and the client that the end-user accepts when between the end-user and the client that the end-user accepts when
authorizing the client. The authorization server SHOULD display authorizing the client. The authorization server SHOULD display
this URL to the end-user if it is provided. The value of this 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 field MUST point to a valid web page. The value of this field MAY
be internationalized, as described in Section 2.2. be internationalized, as described in Section 2.2.
policy_uri policy_uri
URL string that points to a human-readable privacy policy document URL string that points to a human-readable privacy policy document
that describes how the deployment organization collects, uses, that describes how the deployment organization collects, uses,
retains, and discloses personal data. The authorization server retains, and discloses personal data. The authorization server
SHOULD display this URL to the end-user if it is provided. The 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 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. this field MAY be internationalized, as described in Section 2.2.
jwks_uri jwks_uri
URL string referencing the client's JSON Web Key Set [JWK] URL string referencing the client's JSON Web Key Set [RFC7517]
document, which contains the client's public keys. The value of document, which contains the client's public keys. The value of
this field MUST point to a valid JWK Set document. These keys can this field MUST point to a valid JWK Set document. These keys can
be used by higher level protocols that use signing or encryption. be used by higher level protocols that use signing or encryption.
For instance, these keys might be used by some applications for For instance, these keys might be used by some applications for
validating signed requests made to the token endpoint when using validating signed requests made to the token endpoint when using
JWTs for client authentication [OAuth.JWT]. Use of this parameter JWTs for client authentication [RFC7523]. Use of this parameter
is preferred over the "jwks" parameter, as it allows for easier is preferred over the "jwks" parameter, as it allows for easier
key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both key rotation. 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.
jwks jwks
Client's JSON Web Key Set [JWK] document value, which contains the Client's JSON Web Key Set [RFC7517] document value, which contains
client's public keys. The value of this field MUST be a JSON the 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
A unique identifier string (e.g. a UUID) assigned by the client A unique identifier string (e.g. a UUID) assigned by the client
developer or software publisher used by registration endpoints to developer or software publisher used by registration endpoints to
identify the client software to be dynamically registered. Unlike identify the client software to be dynamically registered. Unlike
"client_id", which is issued by the authorization server and "client_id", which is issued by the authorization server and
SHOULD vary between instances, the "software_id" SHOULD remain the SHOULD vary between instances, the "software_id" SHOULD remain the
same for all instances of the client software. The "software_id" same for all instances of the client software. The "software_id"
SHOULD remain the same across multiple updates or versions of the SHOULD remain the same across multiple updates or versions of the
same piece of software. The value of this field is not intended same piece of software. The value of this field is not intended
to be human-readable and is usually opaque to the client and to be human-readable and is usually opaque to the client and
skipping to change at page 12, line 49 skipping to change at page 13, line 38
names, it is not a valid character for use in an object member name names, it is not a valid character for use in an object member name
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 as a workaround the member "client_name#en- JSON.parse(json);", then as a workaround the member "client_name#en-
us" can be accessed using the JavaScript syntax "j["client_name#en- us" can be accessed using the JavaScript syntax "j["client_name#en-
us"]". 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) [RFC7519] 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 in 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 [RFC7515] and MUST contain an "iss"
claim denoting the party attesting to the claims in the software (issuer) claim denoting the party attesting to the claims in the
statement. It is RECOMMENDED that software statements be digitally software statement. It is RECOMMENDED that software statements be
signed using the "RS256" signature algorithm, although particular digitally signed using the "RS256" signature algorithm, although
applications MAY specify the use of different algorithms. It is particular applications MAY specify the use of different algorithms.
RECOMMENDED that software statements contain the "software_id" claim It is RECOMMENDED that software statements contain the "software_id"
to allow authorization servers to correlate different instances of claim to allow authorization servers to correlate different instances
software using the same software statement. of software using the same software statement.
For example, a software statement could contain the following claims: For example, a software statement could contain the following claims:
{ {
"software_id": "4NRB1-0XZABZI9E6-5SM3R", "software_id": "4NRB1-0XZABZI9E6-5SM3R",
"client_name": "Example Statement-based Client", "client_name": "Example Statement-based Client",
"client_uri": "https://client.example.net/" "client_uri": "https://client.example.net/"
} }
The following non-normative example JWT includes these claims and has The following non-normative example JWT includes these claims and has
skipping to change at page 24, line 5 skipping to change at page 25, line 5
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 referencing the client's JSON Web o Client Metadata Description: URL referencing the client's JSON Web
Key Set [JWK] document representing the client's public keys Key Set [RFC7517] 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: Client's JSON Web Key Set [JWK] o Client Metadata Description: Client's JSON Web Key Set [RFC7517]
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 30, line 46 skipping to change at page 31, line 46
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", <http://www.iana.org/assignments/ Subtag Registry", <http://www.iana.org/assignments/
language-subtag-registry>. language-subtag-registry>.
[JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key (work in progress), January 2015.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), January 2015.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in
progress), January 2015.
[OAuth.JWT]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer (work
in progress), November 2014.
[OAuth.SAML2]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-saml2-bearer (work
in progress), November 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.
[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 32, line 5 skipping to change at page 32, line 29
[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.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014. Points", BCP 100, RFC 7120, January 2014.
[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.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, May 2015.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, May 2015.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, May 2015.
[RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security
Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0
Client Authentication and Authorization Grants", RFC 7522,
May 2015.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, May 2015.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, May 2015.
7.2. Informative References 7.2. Informative References
[I-D.hardjono-oauth-umacore] [I-D.hardjono-oauth-umacore]
Hardjono, T., Maler, E., Machulak, M., and D. Catalano, Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
"User-Managed Access (UMA) Profile of OAuth 2.0", draft- "User-Managed Access (UMA) Profile of OAuth 2.0", draft-
skipping to change at page 35, line 21 skipping to change at page 36, 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 ]]
-30
o Updated JOSE, JWT, and OAuth Assertion draft references to final
RFC numbers.
-29 -29
o Descrbed more possible client responses to the metadata fields o Descrbed more possible client responses to the metadata fields
returned by the server being different than those requested. returned by the server being different than those requested.
o Added RFC 7120/BCP 100 references. o Added RFC 7120/BCP 100 references.
o Added RFC 7525/BCP 195 reference to replace draft reference. o Added RFC 7525/BCP 195 reference to replace draft reference.
-28 -28
o Clarified all client metadata as JSON arrays, strings, or numbers. o Clarified all client metadata as JSON arrays, strings, or numbers.
skipping to change at page 39, line 4 skipping to change at page 39, line 48
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
 End of changes. 54 change blocks. 
87 lines changed or deleted 114 lines changed or added

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