draft-ietf-oauth-dyn-reg-management-12.txt   draft-ietf-oauth-dyn-reg-management-13.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft Internet-Draft
Intended status: Experimental M. Jones Intended status: Experimental M. Jones
Expires: September 25, 2015 Microsoft Expires: October 8, 2015 Microsoft
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
March 24, 2015 April 6, 2015
OAuth 2.0 Dynamic Client Registration Management Protocol OAuth 2.0 Dynamic Client Registration Management Protocol
draft-ietf-oauth-dyn-reg-management-12 draft-ietf-oauth-dyn-reg-management-13
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. Not all authorization servers supporting dynamic client client. Not all 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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 25, 2015. This Internet-Draft will expire on October 8, 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 25 skipping to change at page 2, line 25
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 3
2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5 2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5
2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6 2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6
2.2. Client Update Request . . . . . . . . . . . . . . . . . . 6 2.2. Client Update Request . . . . . . . . . . . . . . . . . . 6
2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9 2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9
3. Client Information Response . . . . . . . . . . . . . . . . . 10 3. Client Information Response . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . 13 7. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14
Appendix B. Registration Tokens and Client Credentials . . . . . 14 Appendix B. Registration Tokens and Client Credentials . . . . . 14
B.1. Credential Rotation . . . . . . . . . . . . . . . . . . . 15 B.1. Credential Rotation . . . . . . . . . . . . . . . . . . . 15
Appendix C. Forming the Client Configuration Endpoint URL . . . 15 Appendix C. Forming the Client Configuration Endpoint URL . . . 15
Appendix D. Document History . . . . . . . . . . . . . . . . . . 16 Appendix D. Document History . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 with that server. The OAuth 2.0 Dynamic Client Registration use with 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 12, line 35 skipping to change at page 12, line 35
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
endpoint. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and MAY endpoint. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and MAY
support additional transport-layer mechanisms meeting its security support additional transport-layer mechanisms meeting its security
requirements. When using TLS, the client MUST perform a TLS/SSL requirements. When using TLS, the client MUST perform a TLS/SSL
server certificate check, per RFC 6125 [RFC6125]. Implementation server certificate check, per RFC 6125 [RFC6125]. Implementation
security considerations can be found in Recommendations for Secure security considerations can be found in Recommendations for Secure
Use of TLS and DTLS [TLS.BCP]. Use of TLS and DTLS [TLS.BCP].
Since the client configuration endpoint is an OAuth 2.0 protected Since possession of the registration access token authorizes the
resource, it SHOULD have some rate limiting on failures to prevent holder to potentially read, modify, or delete a client's registration
the registration access token from being disclosed though repeated (including its credentials such as a client_secret), the registration
access attempts. access token MUST contain sufficient entropy to prevent a random
guessing attack of this token, such as described in [RFC6750]
Section 5.2 and [RFC6819] Section 5.1.4.2.2.
If a client is deprovisioned from a server, any outstanding If a client is deprovisioned from a server, any outstanding
registration access token for that client MUST be invalidated at the registration access token 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. The authorization server MUST because the client is no longer valid. The authorization server MUST
treat all such requests as if the registration access token was 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.
skipping to change at page 13, line 36 skipping to change at page 13, line 36
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
Framework: Bearer Token Usage", RFC 6750, October 2012. Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
January 2013.
[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.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[TLS.BCP] Sheffer, Y., Holz, R., and P. Saint-Andre, [TLS.BCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", November "Recommendations for Secure Use of TLS and DTLS", November
2014. 2014.
skipping to change at page 16, line 23 skipping to change at page 16, line 30
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.
Appendix D. Document History Appendix D. 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 ]]
-13
o Changed rate-limiting suggestion to a complexity requirement.
-12 -12
o Used consistent registry name. o Used consistent registry name.
-11 -11
o Fixed a series of nits from Peter Yee's Gen-ART review. o Fixed a series of nits from Peter Yee's Gen-ART review.
-10 -10
 End of changes. 9 change blocks. 
10 lines changed or deleted 20 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/