draft-ietf-oauth-dyn-reg-21.txt   draft-ietf-oauth-dyn-reg-22.txt 
OAuth Working Group J. Richer OAuth Working Group J. Richer
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Standards Track M. Jones Intended status: Standards Track M. Jones
Expires: June 4, 2015 Microsoft Expires: July 19, 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
December 1, 2014 January 15, 2015
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-21 draft-ietf-oauth-dyn-reg-22
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 June 4, 2015. This Internet-Draft will expire on July 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Client Registration Response . . . . . . . . . . . . . . 16 3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1. Client Information Response . . . . . . . . . . . . . 16
4.1. Client Information Response . . . . . . . . . . . . . . . 17 3.2.2. Client Registration Error Response . . . . . . . . . 18
4.2. Client Registration Error Response . . . . . . . . . . . 18 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4.1. OAuth Dynamic Registration Client Metadata Registry . . . 20
5.1. OAuth Dynamic Registration Client Metadata Registry . . . 20 4.1.1. Registration Template . . . . . . . . . . . . . . . . 20
5.1.1. Registration Template . . . . . . . . . . . . . . . . 20 4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21
5.1.2. Initial Registry Contents . . . . . . . . . . . . . . 21 4.2. OAuth Token Endpoint Authentication Methods Registry . . 23
5.2. OAuth Token Endpoint Authentication Methods Registry . . 23 4.2.1. Registration Template . . . . . . . . . . . . . . . . 24
5.2.1. Registration Template . . . . . . . . . . . . . . . . 24 4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 24
5.2.2. Initial Registry Contents . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 7.2. Informative References . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 29
A.1. Open versus Protected Dynamic Client Registration . . . . 29 A.1. Open versus Protected Dynamic Client Registration . . . . 29
A.1.1. Open Dynamic Client Registration . . . . . . . . . . 30 A.1.1. Open Dynamic Client Registration . . . . . . . . . . 30
A.1.2. Protected Dynamic Client Registration . . . . . . . . 30 A.1.2. Protected Dynamic Client Registration . . . . . . . . 30
A.2. Registration Without or With Software Statements . . . . 30 A.2. Registration Without or With Software Statements . . . . 30
A.2.1. Registration Without a Software Statement . . . . . . 30 A.2.1. Registration Without a Software Statement . . . . . . 30
A.2.2. Registration With a Software Statement . . . . . . . 30 A.2.2. Registration With a Software Statement . . . . . . . 30
A.3. Registration by the Client or Developer . . . . . . . . . 30 A.3. Registration by the Client or Developer . . . . . . . . . 30
A.3.1. Registration by the Client . . . . . . . . . . . . . 30 A.3.1. Registration by the Client . . . . . . . . . . . . . 30
A.3.2. Registration by the Developer . . . . . . . . . . . . 31 A.3.2. Registration by the Developer . . . . . . . . . . . . 31
A.4. Client ID per Client Instance or per Client Software . . 31 A.4. Client ID per Client Instance or per Client Software . . 31
A.4.1. Client ID per Client Software Instance . . . . . . . 31 A.4.1. Client ID per Client Software Instance . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 5, line 25 skipping to change at page 5, line 25
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 deployed in one or more deployment environments. A publisher
may be any commercial, public, private, or open source may be any commercial, public, private, or open source
organization that is responsible for publishing and distributing organization that is responsible for publishing and distributing
software that may be protected via OAuth 2.0. In some cases a software that may be protected via OAuth 2.0. In some cases a
software API publisher and a client developer may be the same software API publisher and a client developer may be the same
organization. organization.
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 organization or software statement will be issued directly by the client
developer that creates the client software. In other cases, a developer. In other cases, a software statement will be issued by
software statement will be issued by a third party organization a third party organization for use by the client developer. In
for use by the organization or developer that creates the client both cases, the trust relationship the authorization server has
software. In both cases, the trust relationship the authorization with the issuer of the software statement is intended to be used
server has with the issuer of the software statement is intended as an input to the evaluation of whether the registration request
to be used as an input to the evaluation of whether the is accepted. A software statement can be presented to an
registration request is accepted. A software statement can be authorization server as part of a client registration request.
presented to an 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 +---------------+
+-----------+ +-----------+
Figure 1: Abstract Dynamic Client Registration Flow Figure 1: Abstract Dynamic Client Registration Flow
The abstract OAuth 2.0 client dynamic registration flow illustrated The abstract OAuth 2.0 client dynamic registration flow illustrated
in Figure 1 describes the interaction between the client or developer in Figure 1 describes the interaction between the client or developer
and the endpoint defined in this specification. This figure does not and the endpoint defined in this specification. This figure does not
demonstrate error conditions. This flow includes the following demonstrate error conditions. This flow includes the following
steps: steps:
(A) Optionally, the client or developer is issued an initial access (A) Optionally, the client or developer is issued an initial access
skipping to change at page 6, line 27 skipping to change at page 6, line 27
developer is out of scope for this specification. developer is out of scope for this specification.
(C) The client or developer calls the client registration endpoint (C) The client or developer calls the client registration endpoint
with the client's desired registration metadata, optionally with the client's desired registration metadata, optionally
including the initial access token from (A) if one is required by including the initial access token from (A) if one is required by
the authorization server. the authorization server.
(D) The authorization server registers the client and returns the (D) The authorization server registers the client and returns the
client's registered metadata, a client identifier that is unique client's registered metadata, a client identifier that is unique
at the server, a set of client credentials such as a client secret at the server, a set of client credentials such as a client secret
if applicable for this client, and possibly other values. if applicable for this client, and possibly other values.
Examples of different configurations and usages are included in
Appendix A.
2. Client Metadata 2. Client Metadata
Registered clients have a set of metadata values associated with Registered clients have a set of metadata values associated with
their client identifier at an authorization server, such as the list their client identifier at an authorization server, such as the list
of valid redirection URIs or a display name. of valid redirection URIs or a display name.
These client metadata values are used in two ways: These client metadata values are used in two ways:
o as input values to registration requests, and o as input values to registration requests, and
o as output values in registration responses. o as output values in registration responses.
skipping to change at page 7, line 15 skipping to change at page 7, line 18
Values defined by this specification are: Values defined by this specification are:
* "none": The client is a public client as defined in OAuth 2.0 * "none": The client is a public client as defined in OAuth 2.0
and does not have a client secret. and does not have a client secret.
* "client_secret_post": The client uses the HTTP POST parameters * "client_secret_post": The client uses the HTTP POST parameters
defined in OAuth 2.0 section 2.3.1. defined in OAuth 2.0 section 2.3.1.
* "client_secret_basic": the client uses HTTP Basic defined in * "client_secret_basic": the client uses HTTP Basic defined in
OAuth 2.0 section 2.3.1 OAuth 2.0 section 2.3.1
Additional values can be defined via the IANA OAuth Token Endpoint Additional values can be defined via the IANA OAuth Token Endpoint
Authentication Methods Registry established in Section 5.2. Authentication Methods Registry established in Section 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 types that the client may use. These Array of OAuth 2.0 grant types that the client may use. These
grant types are defined as follows: grant types are defined as follows:
* "authorization_code": The Authorization Code Grant described in * "authorization_code": The Authorization Code Grant described in
OAuth 2.0 Section 4.1 OAuth 2.0 Section 4.1
skipping to change at page 15, line 9 skipping to change at page 15, line 9
Alternatively, if the server supports authorized registration, the Alternatively, if the server supports authorized registration, the
developer or the client will be provisioned with an initial access developer or the client will be provisioned with an initial access
token. (The method by which the initial access token is obtained is token. (The method by which the initial access token is obtained is
out of scope for this specification.) The developer or client sends out of scope for this specification.) The developer or client sends
the following authorized registration request to the client the following authorized registration request to the client
registration endpoint. Note that the initial access token sent in registration endpoint. Note that the initial access token sent in
this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth
2.0 token type could be used by an authorization server. 2.0 token type could be used by an authorization server.
The following is a non-normative example request using an initial The following is a non-normative example request using an initial
access token (with line wraps within values for display purposes access token and registering a JWK set by value (with line wraps
only): within values for display 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
Authorization: Bearer ey23f2.adfj230.af32-developer321 Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: server.example.com Host: server.example.com
{ {
"redirect_uris":["https://client.example.org/callback", "redirect_uris":["https://client.example.org/callback",
"https://client.example.org/callback2"], "https://client.example.org/callback2"],
"client_name":"My Example Client", "client_name":"My Example Client",
"client_name#ja-Jpan-JP": "client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method":"client_secret_basic", "token_endpoint_auth_method":"client_secret_basic",
"policy_uri":"https://client.example.org/policy.html", "policy_uri":"https://client.example.org/policy.html",
"jwks":{"keys":[{...omitted for brevity...}]}, "jwks":{"keys":[{
"e": "AQAB",
"n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p
RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe
2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve
qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ",
"kty": "RSA"
}]},
"example_extension_parameter": "example_value" "example_extension_parameter": "example_value"
} }
3.1.1. Client Registration Request Using a Software Statement 3.1.1. Client Registration Request Using a Software Statement
In addition to JSON elements, client metadata values MAY also be In addition to JSON elements, client metadata values MAY also be
provided in a software statement, as described in Section 2.3. The provided in a software statement, as described in Section 2.3. The
authorization server MAY ignore the software statement if it does not authorization server MAY ignore the software statement if it does not
support this feature. If the server supports software statements, support this feature. If the server supports software statements,
client metadata values conveyed in the software statement MUST take client metadata values conveyed in the software statement MUST take
skipping to change at page 16, line 35 skipping to change at page 16, line 37
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA", IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
"scope":"read write", "scope":"read write",
"example_extension_parameter":"example_value" "example_extension_parameter":"example_value"
} }
3.2. Client Registration Response 3.2. Responses
Upon a successful registration request, the authorization server Upon a successful registration request, the authorization server
returns a client identifier for the client. The server responds with returns a client identifier for the client. The server responds with
an HTTP 201 Created code and a body of type "application/json" with an HTTP 201 Created code and a body of type "application/json" with
content as described in Section 4.1. content as described in Section 3.2.1.
Upon an unsuccessful registration request, the authorization server Upon an unsuccessful registration request, the authorization server
responds with an error, as described in Section 4.2. responds with an error, as described in Section 3.2.2.
4. Responses
The following responses are sent in response to registration
requests.
4.1. Client Information Response 3.2.1. Client Information Response
The response contains the client identifier as well as the client The response contains the client identifier as well as the client
secret, if the client is a confidential client. The response MAY secret, if the client is a confidential client. The response MAY
contain additional fields as specified by extensions to this contain additional fields as specified by extensions to this
specification. specification.
client_id client_id
REQUIRED. OAuth 2.0 client identifier. It SHOULD NOT be REQUIRED. OAuth 2.0 client identifier. It SHOULD NOT be
currently valid for any other registered client, though an currently valid for any other registered client, though an
authorization server MAY issue the same client identifier to authorization server MAY issue the same client identifier to
skipping to change at page 18, line 30 skipping to change at page 18, line 30
"grant_types": ["authorization_code", "refresh_token"], "grant_types": ["authorization_code", "refresh_token"],
"client_name":"My Example Client", "client_name":"My Example Client",
"client_name#ja-Jpan-JP": "client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"token_endpoint_auth_method":"client_secret_basic", "token_endpoint_auth_method":"client_secret_basic",
"logo_uri":"https://client.example.org/logo.png", "logo_uri":"https://client.example.org/logo.png",
"jwks_uri":"https://client.example.org/my_public_keys.jwks", "jwks_uri":"https://client.example.org/my_public_keys.jwks",
"example_extension_parameter": "example_value" "example_extension_parameter": "example_value"
} }
4.2. Client Registration Error Response 3.2.2. Client Registration Error Response
When an OAuth 2.0 error condition occurs, such as the client When an OAuth 2.0 error condition occurs, such as the client
presenting an invalid initial access token, the authorization server presenting an invalid initial access token, the authorization server
returns an error response appropriate to the OAuth 2.0 token type. returns an error response appropriate to the OAuth 2.0 token type.
When a registration error condition occurs, the authorization server When a registration error condition occurs, the authorization server
returns an HTTP 400 status code (unless otherwise specified) with returns an HTTP 400 status code (unless otherwise specified) with
content type "application/json" consisting of a JSON object [RFC7159] content type "application/json" consisting of a JSON object [RFC7159]
describing the error in the response body. describing the error in the response body.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Cache-Control: no-store Cache-Control: no-store
Pragma: no-cache Pragma: no-cache
{ {
"error": "invalid_client_metadata", "error": "invalid_client_metadata",
"error_description": "The grant type 'authorization_code' must be "error_description": "The grant type 'authorization_code' must be
registered along with the response type 'code' but found only registered along with the response type 'code' but found only
'implicit' instead." 'implicit' instead."
} }
5. IANA Considerations 4. IANA Considerations
5.1. OAuth Dynamic Registration Client Metadata Registry 4.1. OAuth Dynamic Registration Client Metadata Registry
This specification establishes the OAuth Dynamic Registration Client This specification establishes the OAuth Dynamic Registration Client
Metadata registry. Metadata registry.
OAuth registration client metadata values are registered with a OAuth registration client metadata values are registered with a
Specification Required ([RFC5226]) after a two-week review period on Specification Required ([RFC5226]) after a two-week review period on
the oauth-ext-review@ietf.org mailing list, on the advice of one or the oauth-ext-review@ietf.org mailing list, on the advice of one or
more Designated Experts. However, to allow for the allocation of more Designated Experts. However, to allow for the allocation of
values prior to publication, the Designated Expert(s) may approve values prior to publication, the Designated Expert(s) may approve
registration once they are satisfied that such a specification will registration once they are satisfied that such a specification will
skipping to change at page 20, line 35 skipping to change at page 20, line 35
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s) IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
5.1.1. Registration Template 4.1.1. Registration Template
Client Metadata Name: Client Metadata Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner SHOULD NOT be accepted.
Client Metadata Description: Client Metadata Description:
Brief description of the metadata value (e.g., "Example Brief description of the metadata value (e.g., "Example
description"). description").
skipping to change at page 21, line 10 skipping to change at page 21, line 10
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification document(s): Specification document(s):
Reference to the document(s) that specify the token endpoint Reference to the document(s) that specify the token endpoint
authorization method, preferably including a URI that can be used authorization method, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required. relevant sections may also be included but is not required.
5.1.2. Initial Registry Contents 4.1.2. Initial Registry Contents
The initial contents of the OAuth Dynamic Registration Client The initial contents of the OAuth Dynamic Registration Client
Metadata registry are: Metadata registry are:
o Client Metadata Name: "redirect_uris" o Client Metadata Name: "redirect_uris"
o Client Metadata Description: Array of redirection URIs for use in o Client Metadata Description: Array of redirection URIs for use in
redirect-based flows redirect-based flows
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 23, line 31 skipping to change at page 23, line 31
was issued was issued
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "client_secret_expires_at" o Client Metadata Name: "client_secret_expires_at"
o Client Metadata Description: Time at which the client secret will o Client Metadata Description: Time at which the client secret will
expire expire
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
5.2. OAuth Token Endpoint Authentication Methods Registry 4.2. OAuth Token Endpoint Authentication Methods Registry
This specification establishes the OAuth Token Endpoint This specification establishes the OAuth Token Endpoint
Authentication Methods registry. Authentication Methods registry.
Additional values for use as "token_endpoint_auth_method" metadata Additional values for use as "token_endpoint_auth_method" metadata
values are registered with a Specification Required ([RFC5226]) after values are registered with a Specification Required ([RFC5226]) after
a two-week review period on the oauth-ext-review@ietf.org mailing a two-week review period on the oauth-ext-review@ietf.org mailing
list, on the advice of one or more Designated Experts. However, to list, on the advice of one or more Designated Experts. However, to
allow for the allocation of values prior to publication, the allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied Designated Expert(s) may approve registration once they are satisfied
skipping to change at page 24, line 11 skipping to change at page 24, line 11
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s) IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
5.2.1. Registration Template 4.2.1. Registration Template
Token Endpoint Authorization Method Name: Token Endpoint Authorization Method Name:
The name requested (e.g., "example"). This name is case The name requested (e.g., "example"). This name is case
sensitive. Names that match other registered names in a case sensitive. Names that match other registered names in a case
insensitive manner SHOULD NOT be accepted. insensitive manner SHOULD NOT be accepted.
Change controller: Change controller:
For Standards Track RFCs, state "IESG". For others, give the name For Standards Track RFCs, state "IESG". For others, give the name
of the responsible party. Other details (e.g., postal address, of the responsible party. Other details (e.g., postal address,
email address, home page URI) may also be included. email address, home page URI) may also be included.
Specification document(s): Specification document(s):
Reference to the document(s) that specify the token endpoint Reference to the document(s) that specify the token endpoint
authorization method, preferably including a URI that can be used authorization method, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required. relevant sections may also be included but is not required.
5.2.2. Initial Registry Contents 4.2.2. Initial Registry Contents
The initial contents of the OAuth Token Endpoint Authentication The initial contents of the OAuth Token Endpoint Authentication
Methods registry are: Methods registry are:
o Token Endpoint Authorization Method Name: "none" o Token Endpoint Authorization Method Name: "none"
o Change controller: IESG o Change controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
o Token Endpoint Authorization Method Name: "client_secret_post" o Token Endpoint Authorization Method Name: "client_secret_post"
o Change controller: IESG o Change controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
o Token Endpoint Authorization Method Name: "client_secret_basic" o Token Endpoint Authorization Method Name: "client_secret_basic"
o Change controller: IESG o Change controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
6. Security Considerations 5. Security Considerations
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
skipping to change at page 27, line 36 skipping to change at page 27, line 36
Since a client identifier is a public value that can be used to Since a client identifier is a public value that can be used to
impersonate a client at the authorization endpoint, an authorization impersonate a client at the authorization endpoint, an authorization
server that decides to issue the same client identifier to multiple server that decides to issue the same client identifier to multiple
instances of a registered client needs to be very particular about instances of a registered client needs to be very particular about
the circumstances under which this occurs. For instance, the the circumstances under which this occurs. For instance, the
authorization server can limit a given client identifier to clients authorization server can limit a given client identifier to clients
using the same redirect-based flow and the same redirection URIs. An using the same redirect-based flow and the same redirection URIs. An
authorization server SHOULD NOT issue the same client secret to authorization server SHOULD NOT issue the same client secret to
multiple instances of a registered client, even if they are issued multiple instances of a registered client, even if they are issued
the same client identifier, or else the client secret could be the same client identifier, or else the client secret could be
leaked, allowing malicious imposters to impersonate a confidential leaked, allowing malicious impostors to impersonate a confidential
client. client.
7. 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.
8. References 7. References
8.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), July 2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
skipping to change at page 29, line 20 skipping to change at page 29, line 20
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012. 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012. Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
8.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.
[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
skipping to change at page 32, line 30 skipping to change at page 32, line 30
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 ]]
-22
o Reorganized registration response sections.
o Addressed shepherd comments.
o Added concrete JWK set to example.
-21 -21
o Applied minor editorial fixes. o Applied minor editorial fixes.
o Added software statement examples. o Added software statement examples.
o Moved software statement request details to sub-section. o Moved software statement request details to sub-section.
o Clarified that a server MAY ignore the software statement (just as o Clarified that a server MAY ignore the software statement (just as
it MAY ignore other metadata values). it MAY ignore other metadata values).
o Removed TLS 1.0. o Removed TLS 1.0.
o Added privacy considerations around "contacts" field. o Added privacy considerations around "contacts" field.
o Marked software_id as RECOMMENDED inside of a software statement. o Marked software_id as RECOMMENDED inside of a software statement.
 End of changes. 33 change blocks. 
60 lines changed or deleted 71 lines changed or added

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