draft-ietf-oauth-dyn-reg-management-02.txt   draft-ietf-oauth-dyn-reg-management-03.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: Experimental M. Jones
Expires: January 4, 2015 Microsoft Expires: February 6, 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
July 3, 2014 August 5, 2014
OAuth 2.0 Dynamic Client Registration Management Protocol OAuth 2.0 Dynamic Client Registration Management Protocol
draft-ietf-oauth-dyn-reg-management-02 draft-ietf-oauth-dyn-reg-management-03
Abstract Abstract
This specification defines methods for management of dynamic OAuth This specification defines methods for management of dynamic OAuth
2.0 client registrations for use cases in which the properties of a 2.0 client registrations for use cases in which the properties of a
registered client may need to be changed during the lifetime of the registered client may need to be changed during the lifetime of the
client. Only some authorization servers supporting dynamic client client. Only some authorization servers supporting dynamic client
registration will support these management methods. registration will support these management methods.
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.
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 January 4, 2015. This Internet-Draft will expire on February 6, 2015.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Registration Tokens and Client Credentials . . . . . . . . 5 1.4. Registration Tokens and Client Credentials . . . . . . . 5
1.4.1. Credential Rotation . . . . . . . . . . . . . . . . . 6 1.4.1. Credential Rotation . . . . . . . . . . . . . . . . . 6
2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 7 2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 7
2.1. Forming the Client Configuration Endpoint URL . . . . . . 7 2.1. Forming the Client Configuration Endpoint URL . . . . . . 7
2.2. Client Read Request . . . . . . . . . . . . . . . . . . . 8 2.2. Client Read Request . . . . . . . . . . . . . . . . . . . 8
2.3. Client Update Request . . . . . . . . . . . . . . . . . . 8 2.3. Client Update Request . . . . . . . . . . . . . . . . . . 8
2.4. Client Delete Request . . . . . . . . . . . . . . . . . . 11 2.4. Client Delete Request . . . . . . . . . . . . . . . . . . 11
3. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Client Information Response . . . . . . . . . . . . . . . 12 3.1. Client Information Response . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Normative References . . . . . . . . . . . . . . . . . . . . . 14 6. Normative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14
Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
In order for an OAuth 2.0 client to utilize an OAuth 2.0 In order for an OAuth 2.0 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. The OAuth 2.0 Dynamic Client Registration use at that server. The OAuth 2.0 Dynamic Client Registration
Protocol [OAuth.Registration] specification describes how an OAuth Protocol [OAuth.Registration] specification describes how an OAuth
2.0 client can be dynamically registered with an authorization server 2.0 client can be dynamically registered with an authorization server
to obtain this information and how metadata about the client can be to obtain this information and how metadata about the client can be
skipping to change at page 7, line 40 skipping to change at page 7, line 38
MUST NOT construct this URL from component pieces. MUST NOT construct this URL from component pieces.
Depending on deployment characteristics, the client configuration Depending on deployment characteristics, the client configuration
endpoint URL may take any number of forms. It is RECOMMENDED that endpoint URL may take any number of forms. It is RECOMMENDED that
this endpoint URL be formed through the use of a server-constructed this endpoint URL be formed through the use of a server-constructed
URL string which combines the client registration endpoint's URL and URL string which combines the client registration endpoint's URL and
the issued "client_id" for this client, with the latter as either a the issued "client_id" for this client, with the latter as either a
path parameter or a query parameter. For example, a client with the path parameter or a query parameter. For example, a client with the
client identifier "s6BhdRkqt3" could be given a client configuration client identifier "s6BhdRkqt3" could be given a client configuration
endpoint URL of "https://server.example.com/register/s6BhdRkqt3" endpoint URL of "https://server.example.com/register/s6BhdRkqt3"
(path parameter) or of (path parameter) or of "https://server.example.com/
"https://server.example.com/register?client_id=s6BhdRkqt3" (query register?client_id=s6BhdRkqt3" (query parameter). In both of these
parameter). In both of these cases, the client simply uses the URL cases, the client simply uses the URL as given by the authorization
as given by the authorization server. server.
These common patterns can help the server to more easily determine These common patterns can help the server to more easily determine
the client to which the request pertains, which MUST be matched the client to which the request pertains, which MUST be matched
against the client to which the registration access token was issued. against the client to which the registration access token was issued.
If desired, the server MAY simply return the client registration If desired, the server MAY simply return the client registration
endpoint URL as the client configuration endpoint URL and change endpoint URL as the client configuration endpoint URL and change
behavior based on the authentication context provided by the behavior based on the authentication context provided by the
registration access token. registration access token.
2.2. Client Read Request 2.2. Client Read Request
skipping to change at page 14, line 30 skipping to change at page 14, line 28
because the client is no longer valid. To prevent accidental because the client is no longer valid. To prevent accidental
disclosure from such an erroneous situation, the authorization server disclosure from such an erroneous situation, the authorization server
MUST treat all such requests as if the registration access token was MUST treat all such requests as if the registration access token was
invalid (by returning an HTTP 401 Unauthorized error, as described). invalid (by returning an HTTP 401 Unauthorized error, as described).
6. Normative References 6. Normative References
[OAuth.Registration] [OAuth.Registration]
Richer, J., Jones, M., Bradley, J., Machulak, M., and P. Richer, J., Jones, M., Bradley, J., Machulak, M., and P.
Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
draft-ietf-oauth-dyn-reg (work in progress), July 2014. draft-ietf-oauth-dyn-reg (work in progress), August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
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.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors thank the OAuth Working Group, the User-Managed Access The authors thank the OAuth Working Group, the User-Managed Access
skipping to change at page 15, line 21 skipping to change at page 15, line 14
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 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 ]]
-03
o Changed draft to be Experimental instead of Standards Track.
-02 -02
o Added more context information to the abstract. o Added more context information to the abstract.
-01 -01
o Addressed issues that arose from last call comments on o Addressed issues that arose from last call comments on draft-ietf-
draft-ietf-oauth-dyn-reg and draft-ietf-oauth-dyn-reg-metadata. oauth-dyn-reg and draft-ietf-oauth-dyn-reg-metadata.
-00 -00
o Created from draft-jones-oauth-dyn-reg-management-00. o Created from draft-jones-oauth-dyn-reg-management-00.
Authors' Addresses Authors' Addresses
Justin Richer Justin Richer
The MITRE Corporation The MITRE Corporation
 End of changes. 11 change blocks. 
34 lines changed or deleted 38 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/