draft-ietf-oauth-dyn-reg-management-14.txt   draft-ietf-oauth-dyn-reg-management-15.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: October 23, 2015 Microsoft Expires: November 6, 2015 Microsoft
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
April 21, 2015 May 5, 2015
OAuth 2.0 Dynamic Client Registration Management Protocol OAuth 2.0 Dynamic Client Registration Management Protocol
draft-ietf-oauth-dyn-reg-management-14 draft-ietf-oauth-dyn-reg-management-15
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 October 23, 2015. This Internet-Draft will expire on November 6, 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 10, line 9 skipping to change at page 10, line 9
Following is a non-normative example response: Following is a non-normative example response:
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Cache-Control: no-store Cache-Control: no-store
Pragma: no-cache Pragma: no-cache
3. Client Information Response 3. Client Information Response
This specification extends the client information response defined in This specification extends the client information response defined in
OAuth 2.0 Client Dynamic Registration [OAuth.Registration], which OAuth 2.0 Client Dynamic Registration [OAuth.Registration], which
states that the response contains the client identifier as well as states that the response contains the client identifier (as well as
the client secret, if the client is a confidential client. When used the client secret if the client is a confidential client). When used
with this specification, the client information response also with this specification, the client information response also
contains the fully qualified URL of the client configuration endpoint contains the fully qualified URL of the client configuration endpoint
(Section 2) for this specific client that the client or developer may (Section 2) for this specific client that the client or developer may
use to manage the client's registration configuration, as well as a use to manage the client's registration configuration, as well as a
registration access token that is to be used by the client or registration access token that is to be used by the client or
developer to perform subsequent operations at the client developer to perform subsequent operations at the client
configuration endpoint. configuration endpoint.
registration_access_token registration_access_token
REQUIRED. Access token string used at the client configuration REQUIRED. Access token string used at the client configuration
skipping to change at page 12, line 11 skipping to change at page 12, line 11
registration endpoint registration endpoint
o Change controller: IESG o Change controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
5. Security Considerations 5. Security Considerations
While the client secret can expire, the registration access token While the client secret can expire, the registration access token
SHOULD NOT expire while a client is still actively registered. If SHOULD NOT expire while a client is still actively registered. If
this token were to expire, a developer or client could be left in a this token were to expire, a developer or client could be left in a
situation where they have no means of retrieving or updating the situation where they have no means of retrieving, updating, or
client's registration information. Were that the case, a new deleting the client's registration information. Were that the case,
registration would be required, thereby generating a new client a new registration would be required, thereby generating a new client
identifier. However, to limit the exposure surface of the identifier. However, to limit the exposure surface of the
registration access token, the registration access token MAY be registration access token, the registration access token MAY be
rotated when the developer or client does a read or update operation rotated when the developer or client does a read or update operation
on the client's client configuration endpoint. As the registration on the client's client configuration endpoint. As the registration
access tokens are relatively long-term credentials, and since the access tokens are relatively long-term credentials, and since the
registration access token is a Bearer token and acts as the sole registration access token is a Bearer token and acts as the sole
authentication for use at the client configuration endpoint, it MUST authentication for use at the client configuration endpoint, it MUST
be protected by the developer or client as described in OAuth 2.0 be protected by the developer or client as described in OAuth 2.0
Bearer Token Usage [RFC6750]. Bearer Token Usage [RFC6750].
Since requests to the client configuration endpoint result in the Since requests to the client configuration endpoint result in the
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 [RFC7525].
Since possession of the registration access token authorizes the Since possession of the registration access token authorizes the
holder to potentially read, modify, or delete a client's registration holder to potentially read, modify, or delete a client's registration
(including its credentials such as a client_secret), the registration (including its credentials such as a client_secret), the registration
access token MUST contain sufficient entropy to prevent a random access token MUST contain sufficient entropy to prevent a random
guessing attack of this token, such as described in [RFC6750] guessing attack of this token, such as described in [RFC6750]
Section 5.2 and [RFC6819] Section 5.1.4.2.2. 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
skipping to change at page 13, line 14 skipping to change at page 13, line 14
6. Privacy Considerations 6. Privacy Considerations
This specification poses no additional privacy considerations beyond This specification poses no additional privacy considerations beyond
those described in the core OAuth 2.0 Dynamic Client Registration those described in the core OAuth 2.0 Dynamic Client Registration
[OAuth.Registration] specification. [OAuth.Registration] specification.
7. Normative References 7. Normative References
[OAuth.Registration] [OAuth.Registration]
Richer, J., Jones, M., Bradley, J., Machulak, M., and P. Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
draft-ietf-oauth-dyn-reg (work in progress), August 2014. draft-ietf-oauth-dyn-reg (work in progress), May 2015.
[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.
[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.
[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
skipping to change at page 13, line 46 skipping to change at page 13, line 46
[RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
January 2013. 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, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", November "Recommendations for Secure Use of Transport Layer
2014. Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
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
Working Group, and the OpenID Connect Working Group participants for Working Group, and the OpenID Connect Working Group participants for
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, 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
skipping to change at page 16, line 30 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 ]]
-15
o Added RFC 7525/BCP 195 reference to replace draft reference.
-14 -14
o Clarified all client metadata as JSON arrays, strings, or numbers. o Clarified all client metadata as JSON arrays, strings, or numbers.
o Clarified experimental nature of the draft. o Clarified experimental nature of the draft.
-13 -13
o Changed rate-limiting suggestion to a complexity requirement. o Changed rate-limiting suggestion to a complexity requirement.
 End of changes. 10 change blocks. 
16 lines changed or deleted 21 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/