draft-ietf-oauth-dyn-reg-25.txt   draft-ietf-oauth-dyn-reg-26.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track M. Jones Intended status: Standards Track M. Jones
Expires: September 24, 2015 Microsoft Expires: September 25, 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
March 23, 2015 March 24, 2015
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-25 draft-ietf-oauth-dyn-reg-26
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 September 24, 2015. This Internet-Draft will expire on September 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 11 2.2. Human-Readable Client Metadata . . . . . . . . . . . . . 11
2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12 2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13
3.1. Client Registration Request . . . . . . . . . . . . . . . 14 3.1. Client Registration Request . . . . . . . . . . . . . . . 14
3.1.1. Client Registration Request Using a Software 3.1.1. Client Registration Request Using a Software
Statement . . . . . . . . . . . . . . . . . . . . . . 16 Statement . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Client Information Response . . . . . . . . . . . . . 17 3.2.1. Client Information Response . . . . . . . . . . . . . 17
3.2.2. Client Registration Error Response . . . . . . . . . 19 3.2.2. Client Registration Error Response . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. OAuth Dynamic Registration Client Metadata Registry . . . 21 4.1. OAuth Dynamic Client Registration Metadata Registry . . . 21
4.1.1. Registration Template . . . . . . . . . . . . . . . . 21 4.1.1. Registration Template . . . . . . . . . . . . . . . . 21
4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22 4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22
4.2. OAuth Token Endpoint Authentication Methods Registry . . 24 4.2. OAuth Token Endpoint Authentication Methods Registry . . 24
4.2.1. Registration Template . . . . . . . . . . . . . . . . 25 4.2.1. Registration Template . . . . . . . . . . . . . . . . 25
4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 25 4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 31 7.2. Informative References . . . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 20 skipping to change at page 3, line 20
A.3.2. Registration by the Developer . . . . . . . . . . . . 32 A.3.2. Registration by the Developer . . . . . . . . . . . . 32
A.4. Client ID per Client Instance or per Client Software . . 32 A.4. Client ID per Client Instance or per Client Software . . 32
A.4.1. Client ID per Client Software Instance . . . . . . . 32 A.4.1. Client ID per Client Software Instance . . . . . . . 32
A.4.2. Client ID Shared Among All Instances of Client A.4.2. Client ID Shared Among All Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . 33 Software . . . . . . . . . . . . . . . . . . . . . . 33
A.5. Stateful or Stateless Registration . . . . . . . . . . . 33 A.5. Stateful or Stateless Registration . . . . . . . . . . . 33
A.5.1. Stateful Client Registration . . . . . . . . . . . . 33 A.5.1. Stateful Client Registration . . . . . . . . . . . . 33
A.5.2. Stateless Client Registration . . . . . . . . . . . . 33 A.5.2. Stateless Client Registration . . . . . . . . . . . . 33
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33
Appendix C. Document History . . . . . . . . . . . . . . . . . . 34 Appendix C. Document History . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0 In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0
authorization server, the client needs specific information to authorization server, the client needs specific information to
interact with the server, including an OAuth 2.0 client identifier to interact with the server, including an OAuth 2.0 client identifier to
use at that server. This specification describes how an OAuth 2.0 use at that server. This specification describes how an OAuth 2.0
client can be dynamically registered with an authorization server to client can be dynamically registered with an authorization server to
obtain this information. obtain this information.
skipping to change at page 21, line 7 skipping to change at page 21, line 7
{ {
"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."
} }
4. IANA Considerations 4. IANA Considerations
4.1. OAuth Dynamic Registration Client Metadata Registry 4.1. OAuth Dynamic Client Registration Metadata Registry
This specification establishes the OAuth Dynamic Registration Client This specification establishes the OAuth Dynamic Client Registration
Metadata registry. Metadata registry.
OAuth registration client metadata names and descriptions are OAuth registration client metadata names and descriptions are
registered with a Specification Required ([RFC5226]) after a two-week registered with a Specification Required ([RFC5226]) after a two-week
review period on the oauth-ext-review@ietf.org mailing list, on the review period on the oauth-ext-review@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of names prior to publication, the Designated Expert(s) allocation of names prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published.
Registration requests must be sent to the oauth-ext-review@ietf.org Registration requests sent to the mailing list for review should use
mailing list for review and comment, with an appropriate subject an appropriate subject (e.g., "Request to register OAuth Dynamic
(e.g., "Request to register OAuth Dynamic Registration Client Client Registration Metadata name: example").
Metadata name: example").
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.
skipping to change at page 34, line 12 skipping to change at page 34, line 12
to various versions of this document: Amanda Anganes, Derek Atkins, to various versions of this document: Amanda Anganes, Derek Atkins,
Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov,
George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten
Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat
Sakimura, Christian Scholz, and Hannes Tschofenig. Sakimura, Christian Scholz, and Hannes Tschofenig.
Appendix C. Document History Appendix C. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-26
o Used consistent registry name.
-25 -25
o Updated author information. o Updated author information.
o Clarified registry contents. o Clarified registry contents.
o Added forward pointer to IANA from metadata section. o Added forward pointer to IANA from metadata section.
o Clarified how to silently ignore errors. o Clarified how to silently ignore errors.
o Reformatted diagram text. o Reformatted diagram text.
-24 -24
 End of changes. 10 change blocks. 
12 lines changed or deleted 15 lines changed or added

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