draft-ietf-oauth-dyn-reg-15.txt   draft-ietf-oauth-dyn-reg-16.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: August 1, 2014 Microsoft Expires: August 10, 2014 Microsoft
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
January 28, 2014 P. Hunt
Oracle Corporation
February 6, 2014
OAuth 2.0 Dynamic Client Registration Core Protocol OAuth 2.0 Dynamic Client Registration Core Protocol
draft-ietf-oauth-dyn-reg-15 draft-ietf-oauth-dyn-reg-16
Abstract Abstract
This specification defines mechanisms used to dynamically register This specification defines mechanisms used to dynamically register
OAuth 2.0 clients at authorization servers. OAuth 2.0 clients at authorization servers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 38
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 1, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Relationship between Grant Types and Response Types . . . 9 2.1. Relationship between Grant Types and Response Types . . . 9
3. Software Statement . . . . . . . . . . . . . . . . . . . . . . 9 3. Software Statement . . . . . . . . . . . . . . . . . . . . . . 10
4. Client Registration Endpoint . . . . . . . . . . . . . . . . . 10 4. Client Registration Endpoint . . . . . . . . . . . . . . . . . 10
4.1. Client Registration Request . . . . . . . . . . . . . . . 11 4.1. Client Registration Request . . . . . . . . . . . . . . . 11
4.2. Client Registration Response . . . . . . . . . . . . . . . 13 4.2. Client Registration Response . . . . . . . . . . . . . . . 13
5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Client Information Response . . . . . . . . . . . . . . . 13 5.1. Client Information Response . . . . . . . . . . . . . . . 13
5.2. Client Registration Error Response . . . . . . . . . . . . 15 5.2. Client Registration Error Response . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. OAuth Registration Client Metadata Registry . . . . . . . 16 6.1. OAuth Registration Client Metadata Registry . . . . . . . 16
6.1.1. Registration Template . . . . . . . . . . . . . . . . 17 6.1.1. Registration Template . . . . . . . . . . . . . . . . 17
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 17 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 17
skipping to change at page 2, line 37 skipping to change at page 3, line 35
6.2.1. Registration Template . . . . . . . . . . . . . . . . 18 6.2.1. Registration Template . . . . . . . . . . . . . . . . 18
6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 19 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Open versus Protected Dynamic Client Registration . . . . 22 A.1. Open versus Protected Dynamic Client Registration . . . . 22
A.1.1. Open Dynamic Client Registration . . . . . . . . . . . 22 A.1.1. Open Dynamic Client Registration . . . . . . . . . . . 22
A.1.2. Protected Dynamic Client Registration . . . . . . . . 22 A.1.2. Protected Dynamic Client Registration . . . . . . . . 22
A.2. Registration without or with Software Statements . . . . . 22 A.2. Registration Without or With Software Statements . . . . . 22
A.2.1. Registration without a Software Statement . . . . . . 22 A.2.1. Registration Without a Software Statement . . . . . . 22
A.2.2. Registration with a Software Statement . . . . . . . . 22 A.2.2. Registration With a Software Statement . . . . . . . . 22
A.3. Registration by the Client or the Developer . . . . . . . 23 A.3. Registration by the Client or the Developer . . . . . . . 23
A.3.1. Registration by the Client . . . . . . . . . . . . . . 23 A.3.1. Registration by the Client . . . . . . . . . . . . . . 23
A.3.2. Registration by the Developer . . . . . . . . . . . . 23 A.3.2. Registration by the Developer . . . . . . . . . . . . 23
A.4. Client ID per Client Instance or per Client Software . . . 23 A.4. Client ID per Client Instance or per Client Software . . . 23
A.4.1. Client ID per Client Software Instance . . . . . . . . 23 A.4.1. Client ID per Client Software Instance . . . . . . . . 23
A.4.2. Client ID Shared between all Instances of Client A.4.2. Client ID Shared between all Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . . 23 Software . . . . . . . . . . . . . . . . . . . . . . . 23
A.5. Stateful or Stateless Registration . . . . . . . . . . . . 23 A.5. Stateful or Stateless Registration . . . . . . . . . . . . 23
A.5.1. Stateful Client Registration . . . . . . . . . . . . . 24 A.5.1. Stateful Client Registration . . . . . . . . . . . . . 24
A.5.2. Stateless Client Registration . . . . . . . . . . . . 24 A.5.2. Stateless Client Registration . . . . . . . . . . . . 24
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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 ID to use at interact with the server, including an OAuth 2.0 Client ID to use at
that server. This specification describes how an OAuth 2.0 client that server. This specification describes how an OAuth 2.0 client
can be dynamically registered with an authorization server to obtain can be dynamically registered with an authorization server to obtain
this information. this information.
As part of the registration process, this specification also defines As part of the registration process, this specification also defines
a mechanism for the client to present the authorization server with a a mechanism for the client to present the authorization server with a
set of metadata, such as a set of valid redirection URIs. This set of metadata, such as a set of valid redirection URIs. This
metadata can either be communicated in a self-asserted fashion or as metadata can either be communicated in a self-asserted fashion or as
a set of signed metadata called a software statement; in the case of a set of metadata called a software statement, which can be signed;
a software statement, the signer is vouching for the validity of the in the case of a signed software statement, the signer is vouching
data about the client. for the validity of the data about the client.
The mechanisms defined in this specification can be used either for a The mechanisms defined in this specification can be used either for a
client to dynamically register itself with authorization servers or client to dynamically register itself with authorization servers or
for a client developer to programmatically register the client with for a client developer to programmatically register the client with
authorization servers. authorization servers.
1.1. Notational Conventions 1.1. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
skipping to change at page 4, line 49 skipping to change at page 4, line 49
"Authorization Code", "Authorization Grant", "Authorization Server", "Authorization Code", "Authorization Grant", "Authorization Server",
"Authorization Endpoint", "Client", "Client Identifier", "Client "Authorization Endpoint", "Client", "Client Identifier", "Client
Secret", "Protected Resource", "Resource Owner", "Resource Server", Secret", "Protected Resource", "Resource Owner", "Resource Server",
"Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749] "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749]
and uses the term "Claim" defined by JSON Web Token (JWT) [JWT]. and uses 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 Client Developer The person or organization that builds a client
software package and prepares it for distribution. A client software package and prepares it for distribution. A client
developer obtains a software assertion from a software publisher, developer obtains a software statement from a software publisher,
or self-generates one for the purposes of facilitating client or self-generates one for the purposes of facilitating client
registration. registration.
Client Instance A deployed instance of a piece of client software. Client Instance A deployed instance of a piece of client software.
Multiple instances of the same piece of client software MAY use Multiple instances of the same piece of client software MAY use
the same Client ID value at an authorization server, provided that the same Client ID value at an authorization server, provided that
the Redirection URI values and potentially other values dictated the Redirection URI values and potentially other values dictated
by authorization server policy are the same for all instances. by authorization server policy are the same for all instances.
Client Software Software implementing an OAuth 2.0 client. Client Software Software implementing an OAuth 2.0 client.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
deployments. A software API deployment typically has an deployments. A software API deployment typically has an
associated OAuth 2.0 authorization server endpoint as well as a associated OAuth 2.0 authorization server endpoint as well as a
client registration endpoint. The means by which endpoints are client registration endpoint. The means by which endpoints are
obtained (discovery) are out of scope for this specification. obtained (discovery) are out of scope for this specification.
Software API Publisher The organization that defines a particular Software API Publisher The organization that defines a particular
web accessible API that may deployed in one or more deployment web accessible API that may deployed in one or more deployment
environments. A publisher may be any commercial, public, private, environments. A publisher may be any 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 that may be protected via OAuth 2.0. A distributing software that may be protected via OAuth 2.0. A
software API publisher may issue software assertions which client software API publisher may issue software statements which client
developers use to distribute with their software to facilitate developers use to distribute with their software to facilitate
registration. In some cases a software API publisher and a client registration. In some cases a software API publisher and a client
developer may be the same organization. developer may be the same organization.
Software Statement A signed JSON Web Token (JWT) [JWT] that asserts Software Statement A JSON Web Token (JWT) [JWT] that asserts
metadata values about the client software. This may be used by metadata values about the client software. The JWT MUST be signed
and contain an "iss" (issuer) claim if its metadata values are
being attested to by the issuer; if the metadata values are not
being attested to, the JWT MAY be unsigned. This can be used by
the registration system to qualify clients for eligibility to the registration system to qualify clients for eligibility to
register. To obtain a software statement, a client developer may register. It may also be accepted by some authorization servers
generate a client specific assertion, or a client developer may directly as a Client ID value, without prior registration.
register with a software API publisher to obtain a software
assertion. The statement is distributed with all copies of a
client application and may be used during the registration
process.
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 |
skipping to change at page 7, line 16 skipping to change at page 7, line 16
client's registered metadata, a client identifier that is unique client's registered metadata, a client identifier that is unique
at the server, a set of client credentials such as a client secret at the server, a set of client credentials such as a client secret
if applicable for this client, and possibly other values. if applicable for this client, and possibly other values.
2. Client Metadata 2. Client Metadata
Clients have a set of metadata values associated with their unique Clients have a set of metadata values associated with their unique
client identifier at an authorization server, such as the list of client identifier at an authorization server, such as the list of
valid redirect URIs. valid redirect URIs.
The Client Metadata values are used in two ways: The client metadata values are used in two ways:
o as input values to registration requests, and o as input values to registration requests, and
o as output values in registration responses. o as output values in registration responses.
Client Metadata values can either be communicated directly in the These client metadata values are defined by this specification:
body of a registration request, as described in Section 4.1, or
included as claims in a software statement, as described in
Section 3.
These Client Metadata values are defined by this specification:
redirect_uris Array of redirect URIs for use in redirect-based flows redirect_uris Array of redirect URIs for use in redirect-based flows
such as the authorization code and implicit grant types. It is such as the authorization code and implicit grant types. It is
RECOMMENDED that clients using these flows register this RECOMMENDED that clients using these flows register this
parameter, and an authorization server SHOULD require registration parameter, and an authorization server SHOULD require registration
of valid redirect URIs for all clients that use these grant types of valid redirect URIs for all clients that use these grant types
to protect against token and credential theft attacks. to protect against token and credential theft attacks.
token_endpoint_auth_method The requested authentication method for token_endpoint_auth_method The requested authentication method for
the token endpoint. Values defined by this specification are: the token endpoint. Values defined by this specification are:
skipping to change at page 9, line 14 skipping to change at page 9, line 12
same as the value of the "response_type" parameter passed to the same as the value of the "response_type" parameter passed to the
authorization endpoint defined in the extension. authorization endpoint defined in the extension.
Authorization servers MUST accept all fields in this list. Authorization servers MUST accept all fields in this list.
Extensions and profiles of this specification MAY expand this list. Extensions and profiles of this specification MAY expand this list.
For instance, the [OAuth.Registration.Metadata] specification defines For instance, the [OAuth.Registration.Metadata] specification defines
additional client metadata values. The authorization server MUST additional client metadata values. The authorization server MUST
ignore any client metadata values sent by the Client that it does not ignore any client metadata values sent by the Client that it does not
understand. understand.
Client metadata values can either be communicated directly in the
body of a registration request, as described in Section 4.1, or
included as claims in a software statement, as described in
Section 3. If the same client metadata name is present in both
locations, the value in the software statement SHOULD take
precedence.
2.1. Relationship between Grant Types and Response Types 2.1. Relationship between Grant Types and Response Types
The "grant_types" and "response_types" values described above are The "grant_types" and "response_types" values described above are
partially orthogonal, as they refer to arguments passed to different partially orthogonal, as they refer to arguments passed to different
endpoints in the OAuth protocol. However, they are related in that endpoints in the OAuth protocol. However, they are related in that
the "grant_types" available to a client influence the the "grant_types" available to a client influence the
"response_types" that the client is allowed to use, and vice versa. "response_types" that the client is allowed to use, and vice versa.
For instance, a "grant_types" value that includes For instance, a "grant_types" value that includes
"authorization_code" implies a "response_types" value that includes "authorization_code" implies a "response_types" value that includes
"code", as both values are defined as part of the OAuth 2.0 "code", as both values are defined as part of the OAuth 2.0
skipping to change at page 9, line 49 skipping to change at page 10, line 7
| 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.
3. Software Statement 3. Software Statement
A Software Statement is a signed JSON Web Token (JWT) [JWT] that A Software Statement is a JSON Web Token (JWT) [JWT] that asserts
asserts metadata values about the client software. This may be used metadata values about the client software. The JWT MUST be signed
by the registration system to qualify clients for eligibility to and contain an "iss" (issuer) claim if its metadata values are being
register. To obtain a software statement, a client developer may attested to by the issuer; if the metadata values are not being
generate a client specific assertion, or a client developer may attested to, the JWT MAY be unsigned. This can be used by the
register with a software API publisher to obtain a software registration system to qualify clients for eligibility to register.
assertion. The statement is distributed with all copies of a client It may also be accepted by some authorization servers directly as a
application and may be used during the registration process. Client ID value, without prior registration.
To obtain a software statement, a client developer may generate a
client specific JWT, or a client developer may register with a
software API publisher to obtain a software statement. The statement
is typically distributed with all copies of a client application.
The criteria by which authorization servers determine whether to The criteria by which authorization servers determine whether to
trust and utilize the information in a software statement is beyond trust and utilize the information in a software statement is beyond
the scope of this specification. the scope of this specification.
If the authorization server determines that the claims in a software If the authorization server determines that the claims in a software
statement uniquely identify a piece of software, the same Client ID statement uniquely identify a piece of software, the same Client ID
value MAY be returned for all dynamic registrations using that value MAY be returned for all dynamic registrations using that
software statement. software statement. However, authorization servers MAY alternatively
return a unique Client ID value for each dynamic registration of a
piece of software.
In some cases, authorization servers MAY choose to accept a software In some cases, authorization servers MAY choose to accept a software
statement value directly as a Client ID in an authorization request, statement value directly as a Client ID in an authorization request,
without a prior dynamic client registration having been performed. without a prior dynamic client registration having been performed.
The circumstances under which an authorization server would do so, The circumstances under which an authorization server would do so,
and the specific software statement characteristics required in this and the specific software statement characteristics required in this
case, are beyond the scope of this specification. case, are beyond the scope of this specification.
4. Client Registration Endpoint 4. Client Registration Endpoint
skipping to change at page 13, line 38 skipping to change at page 13, line 38
new client identifier for the client. This client identifier MUST be new client identifier for the client. This client identifier MUST be
unique at the server and MUST NOT be in use by any other client. The unique at the server and MUST NOT be in use by any other client. The
server responds with an HTTP 201 Created code and a body of type server responds with an HTTP 201 Created code and a body of type
"application/json" with content as described in Section 5.1. "application/json" with content as described in Section 5.1.
Upon an unsuccessful registration, the authorization server responds Upon an unsuccessful registration, the authorization server responds
with an error, as described in Section 5.2. with an error, as described in Section 5.2.
5. Responses 5. Responses
In response to certain requests from the client to either the client The following responses are sent in response to registration
registration endpoint as described in this specification, the requests.
authorization server sends the following response bodies.
5.1. Client Information Response 5.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 REQUIRED. Unique client identifier. It MUST NOT be client_id REQUIRED. Unique client identifier. It MUST NOT be
currently valid for any other distinct registered client. It MAY currently valid for any other distinct registered client. It MAY
skipping to change at page 14, line 37 skipping to change at page 14, line 37
metadata about this client, including any fields provisioned by the metadata about this client, including any fields provisioned by the
authorization server itself. The authorization server MAY reject or authorization server itself. The authorization server MAY reject or
replace any of the client's requested metadata values submitted replace any of the client's requested metadata values submitted
during the registration or update requests and substitute them with during the registration or update requests and substitute them with
suitable values. suitable values.
The response is an "application/json" document with all parameters as The response is an "application/json" document with all parameters as
top-level members of a JSON object [RFC4627]. top-level members of a JSON object [RFC4627].
If a software statement was used as part of the registration, its If a software statement was used as part of the registration, its
value SHOULD be returned in the response. Client metadata elements value SHOULD be returned in the response and its value MUST be
used from the software statement SHOULD also be returned directly as returned if the authorization server supports registration management
top-level client metadata values in the registration response. operations [OAuth.Registration.Management] that would require its
presence in subsequent operations. Client metadata elements used
from the software statement MUST also be returned directly as top-
level client metadata values in the registration response (possibly
with different values, since the values requested and the values used
may differ).
Following is a non-normative example response: Following is a non-normative example response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Cache-Control: no-store Cache-Control: no-store
Pragma: no-cache Pragma: no-cache
{ {
"client_id":"s6BhdRkqt3", "client_id":"s6BhdRkqt3",
skipping to change at page 20, line 48 skipping to change at page 20, line 48
[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), January 2014. progress), January 2014.
[OAuth.JWT] [OAuth.JWT]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer (work Authorization Grants", draft-ietf-oauth-jwt-bearer (work
in progress), December 2013. in progress), December 2013.
[OAuth.Registration.Management]
Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
Hunt, "OAuth 2.0 Dynamic Client Registration Management
Protocol", draft-ietf-oauth-dyn-reg-management (work in
progress), February 2014.
[OAuth.SAML2] [OAuth.SAML2]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-saml2-bearer (work Authorization Grants", draft-ietf-oauth-saml2-bearer (work
in progress), December 2013. in progress), December 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
skipping to change at page 21, line 37 skipping to change at page 21, line 43
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012. RFC 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.
8.2. Informative References 8.2. Informative References
[OAuth.Registration.Management]
Richer, J., Jones, M., Bradley, J., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Management
Protocol", draft-jones-oauth-dyn-reg-management (work in
progress), January 2014.
[OAuth.Registration.Metadata] [OAuth.Registration.Metadata]
Richer, J., Jones, M., Bradley, J., and M. Machulak, Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
"OAuth 2.0 Dynamic Client Registration Metadata", Hunt, "OAuth 2.0 Dynamic Client Registration Metadata",
draft-jones-oauth-dyn-reg-metadata (work in progress), draft-ietf-oauth-dyn-reg-metadata (work in progress),
January 2014. February 2014.
Appendix A. Use Cases Appendix A. Use Cases
This appendix describes different ways that this specification can be This appendix describes different ways that this specification can be
utilized, including describing some of the choices that may need to utilized, including describing some of the choices that may need to
be made. Some of the choices are independent and can be used in be made. Some of the choices are independent and can be used in
combination, whereas some of the choices are interrelated. combination, whereas some of the choices are interrelated.
A.1. Open versus Protected Dynamic Client Registration A.1. Open versus Protected Dynamic Client Registration
skipping to change at page 22, line 31 skipping to change at page 22, line 31
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
requests. While the method by which a client or developer receives requests. While the method by which a client or developer receives
this initial access token and the method by which the authorization this initial access token and the method by which the authorization
server validates this initial access token are out of scope for this server validates this initial access token are out of scope for this
specification, a common approach is for the developer to use a manual specification, a common approach is for the developer to use a manual
pre-registration portal at the authorization server that issues an pre-registration portal at the authorization server that issues an
initial access token to the developer. initial access token to the developer.
A.2. Registration without or with Software Statements A.2. Registration Without or With Software Statements
A.2.1. Registration without a Software Statement A.2.1. Registration Without a Software Statement
When a software statement is not used in the registration request, When a software statement is not used in the registration request,
the authorization server must be willing to use client metadata the authorization server must be willing to use client metadata
values without them being signed (and thereby attested to) by any values without them being signed (and thereby attested to) by any
authority. (Note that this choice is independent of the Open versus authority. (Note that this choice is independent of the Open versus
Protected choice, and that an initial access token is another Protected choice, and that an initial access token is another
possible form of attestation.) possible form of attestation.)
A.2.2. Registration with a Software Statement A.2.2. Registration With a Software Statement
A software statement can be used in a registration request to provide A software statement can be used in a registration request to provide
attestation for a set of client metadata values for a piece of client attestation for a set of client metadata values for a piece of client
software by an authority. This can be useful when the authorization software by an authority. This can be useful when the authorization
server wants to restrict registration to client software attested to server wants to restrict registration to client software attested to
by a set of authorities or when it wants to know that multiple by a set of authorities or when it wants to know that multiple
registration requests refer to the same piece of client software. registration requests refer to the same piece of client software.
A.3. Registration by the Client or the Developer A.3. Registration by the Client or the Developer
skipping to change at page 24, line 40 skipping to change at page 24, line 40
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 ]]
-15 -16
o Replaced references to draft-jones-oauth-dyn-reg-metadata and
draft-jones-oauth-dyn-reg-management with
draft-ietf-oauth-dyn-reg-metadata and
draft-ietf-oauth-dyn-reg-management.
o Addressed review comments by Phil Hunt and Tony Nadalin.
-15
o Partitioned the Dynamic Client Registration specification into o Partitioned the Dynamic Client Registration specification into
core, metadata, and management specifications. This built on work core, metadata, and management specifications. This built on work
first published as draft-richer-oauth-dyn-reg-core-00 and first published as draft-richer-oauth-dyn-reg-core-00 and
draft-richer-oauth-dyn-reg-management-00. draft-richer-oauth-dyn-reg-management-00.
o Added the ability to use Software Statements. This built on work o Added the ability to use Software Statements. This built on work
first published as draft-hunt-oauth-software-statement-00 and first published as draft-hunt-oauth-software-statement-00 and
draft-hunt-oauth-client-association-00. draft-hunt-oauth-client-association-00.
o Created the IANA OAuth Registration Client Metadata registry for o Created the IANA OAuth Registration Client Metadata registry for
skipping to change at line 1298 skipping to change at page 30, line 28
John Bradley John Bradley
Ping Identity Ping Identity
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
Maciej Machulak Maciej Machulak
Newcastle University Newcastle University
Email: m.p.machulak@ncl.ac.uk Email: m.p.machulak@ncl.ac.uk
URI: http://ncl.ac.uk/ URI: http://ncl.ac.uk/
Phil Hunt
Oracle Corporation
Email: phil.hunt@yahoo.com
 End of changes. 27 change blocks. 
57 lines changed or deleted 79 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/