draft-ietf-oauth-dyn-reg-08.txt   draft-ietf-oauth-dyn-reg-09.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: September 19, 2013 Ping Identity Expires: September 30, 2013 Ping Identity
M.B. Jones M.B. Jones
Microsoft Microsoft
M. Machulak M. Machulak
Newcastle University Newcastle University
March 18, 2013 March 29, 2013
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-08 draft-ietf-oauth-dyn-reg-09
Abstract Abstract
This specification defines an endpoint and protocol for dynamic This specification defines an endpoint and protocol for dynamic
registration of OAuth 2.0 Clients at an Authorization Server and registration of OAuth 2.0 Clients at an Authorization Server and
methods for the dynamically registered client to manage its methods for the dynamically registered client to manage its
registration. registration.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 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 September 19, 2013. This Internet-Draft will expire on September 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 4 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Relationship Between Grant Types and Response Types . . . 7 2.1. Relationship Between Grant Types and Response Types . . . 7
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 7 2.2. Human Readable Client Metadata . . . . . . . . . . . . . 7
3.1. Client Registration Request . . . . . . . . . . . . . . . 8 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 9
3.2. Client Registration Response . . . . . . . . . . . . . . 9 3.1. Client Registration Request . . . . . . . . . . . . . . . 9
4. Client Configuration Endpoint . . . . . . . . . . . . . . . . 9 3.2. Client Registration Response . . . . . . . . . . . . . . 10
4.1. Forming the Client Configuration Endpoint URL . . . . . . 10 4. Client Configuration Endpoint . . . . . . . . . . . . . . . . 10
4.2. Client Read Request . . . . . . . . . . . . . . . . . . . 10 4.1. Forming the Client Configuration Endpoint URL . . . . . . 11
4.3. Client Update Request . . . . . . . . . . . . . . . . . . 11 4.2. Client Read Request . . . . . . . . . . . . . . . . . . . 11
4.4. Client Delete Request . . . . . . . . . . . . . . . . . . 12 4.3. Client Update Request . . . . . . . . . . . . . . . . . . 12
5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Client Delete Request . . . . . . . . . . . . . . . . . . 14
5.1. Client Information Response . . . . . . . . . . . . . . . 14 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Client Registration Error Response . . . . . . . . . . . 15 5.1. Client Information Response . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.2. Client Registration Error Response . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Normative References . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Document History . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Document History . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
In some use-case scenarios, it is desirable or necessary to allow In some use-case scenarios, it is desirable or necessary to allow
OAuth 2.0 clients to obtain authorization from an OAuth 2.0 OAuth 2.0 clients to obtain authorization from an OAuth 2.0
authorization server without requiring the two parties to interact authorization server without requiring the two parties to interact
beforehand. Nevertheless, in order for the authorization server to beforehand. Nevertheless, in order for the authorization server to
accurately and securely represent to end-users which client is accurately and securely represent to end-users which client is
seeking authorization to access the end-user's resources, a method seeking authorization to access the end-user's resources, a method
for automatic and unique registration of clients is needed. The for automatic and unique registration of clients is needed. The
skipping to change at page 4, line 37 skipping to change at page 4, line 37
redirect_uris redirect_uris
RECOMMENDED. Array of redirect URIs for use in the Authorization RECOMMENDED. Array of redirect URIs for use in the Authorization
Code and Implicit grant types. An Authorization Server SHOULD Code and Implicit grant types. An Authorization Server SHOULD
require registration of valid redirect URIs for all clients that require registration of valid redirect URIs for all clients that
use these grant types in order to protect against token and use these grant types in order to protect against token and
credential theft attacks. credential theft attacks.
client_name client_name
RECOMMENDED. Human-readable name of the Client to be presented to RECOMMENDED. Human-readable name of the Client to be presented to
the user. If omitted, the Authorization Server MAY display to the the user. If omitted, the Authorization Server MAY display to the
user the raw "client_id" value instead. user the raw "client_id" value instead. The value of this field
MAY be internationalized as described in Human Readable Client
Metadata (Section 2.2).
client_uri client_uri
RECOMMENDED. URL of the homepage of the Client. If present, the RECOMMENDED. URL of the homepage of the Client. If present, the
server SHOULD display this URL to the end user in a clickable server SHOULD display this URL to the end user in a clickable
fashion. fashion. The value of this field MAY be internationalized as
described in Human Readable Client Metadata (Section 2.2).
logo_uri logo_uri
OPTIONAL. URL that references a logo for the Client. If present, OPTIONAL. URL that references a logo for the Client. If present,
the server SHOULD display this image to the end user during the server SHOULD display this image to the end user during
approval. approval.The value of this field MAY be internationalized as
described in Human Readable Client Metadata (Section 2.2).
contacts contacts
OPTIONAL. Array of email addresses for people responsible for OPTIONAL. Array of email addresses for people responsible for
this Client. The Authorization Server MAY make these addresses this Client. The Authorization Server MAY make these addresses
available to end users for support requests for the Client. An available to end users for support requests for the Client. An
Authorization Server MAY use these email addresses as identifiers Authorization Server MAY use these email addresses as identifiers
for an administrative page for this client. for an administrative page for this client.
tos_uri tos_uri
OPTIONAL. URL that points to a human-readable Terms of Service OPTIONAL. URL that points to a human-readable Terms of Service
for the Client. The Authorization Server SHOULD display this URL for the Client. The Authorization Server SHOULD display this URL
to the End-User if it is given. to the End-User if it is given. The value of this field MAY be
internationalized as described in Human Readable Client Metadata
(Section 2.2).
token_endpoint_auth_method token_endpoint_auth_method
OPTIONAL. The requested authentication type for the Token OPTIONAL. The requested authentication type for the Token
Endpoint. Valid values are: Endpoint. Valid values are:
* "none": this is a public client as defined in OAuth 2.0 and * "none": this is a public client as defined in OAuth 2.0 and
does not have a client secret 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
skipping to change at page 6, line 49 skipping to change at page 7, line 7
response type extensions to OAuth 2.0. The extension process is response type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5, and the value of this described in OAuth 2.0 Section 2.5, and the value of this
parameter MUST be the same as the value of the "response_type" parameter MUST be the same as the value of the "response_type"
parameter passed to the Authorization Endpoint defined in the parameter passed to the Authorization Endpoint defined in the
extension. extension.
policy_uri policy_uri
OPTIONAL. A URL location that the Client provides to the End-User OPTIONAL. A URL location that the Client provides to the End-User
to read about the how the profile data will be used. The to read about the how the profile data will be used. The
Authorization Server SHOULD display this URL to the End-User if it Authorization Server SHOULD display this URL to the End-User if it
is given. is given. The value of this field MAY be internationalized as
described in Human Readable Client Metadata (Section 2.2).
jwks_uri jwks_uri
OPTIONAL. URL for the Client's JSON Web Key Set [JWK] document OPTIONAL. URL for the Client's JSON Web Key Set [JWK] document
that is used for signing requests, such as requests to the Token that is used for signing requests, such as requests to the Token
Endpoint using the "private_key_jwt" assertion client credential. Endpoint using the "private_key_jwt" assertion client credential.
The keys MAY also be used for higher level protocols that require The keys MAY also be used for higher level protocols that require
signing or encryption. signing or encryption.
2.1. Relationship Between Grant Types and Response Types 2.1. Relationship Between Grant Types and Response Types
skipping to change at page 7, line 38 skipping to change at page 7, line 45
| | value includes: | | | value includes: |
+-----------------------------------------------+-------------------+ +-----------------------------------------------+-------------------+
| authorization_code | code | | authorization_code | code |
| implicit | token | | implicit | token |
| password | (none) | | password | (none) |
| client_credentials | (none) | | client_credentials | (none) |
| refresh_token | (none) | | refresh_token | (none) |
| urn:ietf:params:oauth:grant-type:jwt-bearer | (none) | | urn:ietf:params:oauth:grant-type:jwt-bearer | (none) |
+-----------------------------------------------+-------------------+ +-----------------------------------------------+-------------------+
Extensions and profiles of this specification that introduce new Extensions and profiles of this document that introduce new values to
values to either the "grant_types" or "response_types" parameter MUST either the "grant_types" or "response_types" parameter MUST document
document all correspondences between the parameter types. all correspondences between the parameter types.
2.2. Human Readable Client Metadata
Human-readable Client Metadata values and Client Metadata values that
reference human-readable values MAY be represented in multiple
languages and scripts. For example, the values of fields such as
"client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri"
might have multiple locale-specific values in some Client
registrations.
To specify the languages and scripts, BCP47 [RFC5646] language tags
are added to Client Metadata member names, delimited by a #
character. Since JSON member names are case sensitive, it is
RECOMMENDED that language tag values used in Claim Names be spelled
using the character case with which they are registered in the IANA
Language Subtag Registry [IANA.Language]. In particular, normally
language names are spelled with lowercase characters, region names
are spelled with uppercase characters, and languages are spelled with
mixed case characters. However, since BCP47 language tag values are
case insensitive, implementations SHOULD interpret the language tag
values supplied in a case insensitive manner. Per the
recommendations in BCP47, language tag values used in Metadata member
names should only be as specific as necessary. For instance, using
"fr" might be sufficient in many contexts, rather than "fr-CA" or
"fr-FR".
For example, a Client could represent its name in English as
""client_name#en": "My Client"" and its name in Japanese as
""client_name#ja-Jpan-JP":
"クライアント名"" within
the same registration request. The Authorization Server MAY display
any or all of these names to the Resource Owner during the
authorization step, choosing which name to display based on system
configuration, user preferences or other factors.
If any human-readable field is sent without a language tag, parties
using it MUST NOT make any assumptions about the language, character
set, or script of the string value, and the string value MUST be used
as-is wherever it is presented in a user interface. To facilitate
interoperability, it is RECOMMENDED that clients and servers use a
human-readable field without any language tags in addition to any
language-specific fields, and it is RECOMMENDED that any human-
readable fields sent without language tags contain values suitable
for display on a wide variety of systems.
Implementer's Note: Many JSON libraries make it possible to reference
members of a JSON object as members of an Object construct in the
native programming environment of the library. However, while the
"#" character is a valid character inside of a JSON object's member
names, it is not a valid character for use in an object member name
in many programming environments. Therefore, implementations will
need to use alternative access forms for these claims. For instance,
in JavaScript, if one parses the JSON as follows, "var j =
JSON.parse(json);", then the member "client_name#en-us" can be
accessed using the JavaScript syntax "j["client_name#en-us"]".
3. Client Registration Endpoint 3. Client Registration Endpoint
The Client Registration Endpoint is an OAuth 2.0 Endpoint defined in The Client Registration Endpoint is an OAuth 2.0 Endpoint defined in
this document that is designed to allow a Client to register itself this document that is designed to allow a Client to register itself
with the Authorization Server. The Client Registration Endpoint MUST with the Authorization Server. The Client Registration Endpoint MUST
accept HTTP POST messages with request parameters encoded in the accept HTTP POST messages with request parameters encoded in the
entity body using the "application/json" format. The Client entity body using the "application/json" format. The Client
Registration Endpoint MUST be protected by a transport-layer security Registration Endpoint MUST be protected by a transport-layer security
mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246] and mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246] and
skipping to change at page 18, line 7 skipping to change at page 19, line 14
If a Client is deprovisioned from a server, any outstanding If a Client is deprovisioned from a server, any outstanding
Registration Access Tokens for that client MUST be invalidated at the Registration Access Tokens for that client MUST be invalidated at the
same time. Otherwise, this can lead to an inconsistent state wherein same time. Otherwise, this can lead to an inconsistent state wherein
a Client could make requests to the Client Configuration Endpoint a Client could make requests to the Client Configuration Endpoint
where the authentication would succeed but the action would fail where the authentication would succeed but the action would fail
because the Client is no longer valid. because the Client is no longer valid.
8. Normative References 8. Normative References
[IANA.Language]
Internet Assigned Numbers Authority (IANA), "Language
Subtag Registry", 2005.
[JWK] Jones, M.B., "JSON Web Key (JWK)", May 2012. [JWK] Jones, M.B., "JSON Web Key (JWK)", May 2012.
[OAuth.JWT] [OAuth.JWT]
Jones, M.B., Campbell, B., and C. Mortimore, "JSON Web Jones, M.B., Campbell, B., and C. Mortimore, "JSON Web
Token (JWT) Bearer Token Profiles for OAuth 2.0", draft- Token (JWT) Bearer Token Profiles for OAuth 2.0", draft-
ietf-oauth-jwt-bearer (work in progress), December 2012. ietf-oauth-jwt-bearer (work in progress), December 2012.
[OAuth.SAML2] [OAuth.SAML2]
Campbell, B. and C. Mortimore, "JSON Web Token (JWT) Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
Bearer Token Profiles for OAuth 2.0", draft-ietf-oauth- Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer
saml2-bearer (work in progress), December 2012. (work in progress), November 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[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.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 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
skipping to change at page 19, line 16 skipping to change at page 20, line 31
their input to this document. In particular, the following their input to this document. In particular, the following
individuals have been instrumental in their review and contribution individuals have been instrumental in their review and contribution
to various versions of this document: Amanda Anganes, Tim Bray, to various versions of this document: Amanda Anganes, Tim Bray,
Domenico Catalano, George Fletcher, Torsten Lodderstedt, Eve Maler, Domenico Catalano, George Fletcher, Torsten Lodderstedt, Eve Maler,
Thomas Hardjono, Nat Sakimura, and Christian Scholz. Thomas Hardjono, Nat Sakimura, and Christian Scholz.
Appendix B. Document History Appendix B. 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 ]]
-09
o Added method of internationalization for Client Metadata values
o Fixed SAML reference
-08 -08
o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and
x509_encryption_uri into a single jwks_uri parameter x509_encryption_uri into a single jwks_uri parameter
o Renamed grant_type to grant_types since it's a plural value o Renamed grant_type to grant_types since it's a plural value
o Formalized name of "OAuth 2.0" throughout document o Formalized name of "OAuth 2.0" throughout document
o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example
 End of changes. 15 change blocks. 
32 lines changed or deleted 107 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/