draft-ietf-oauth-dyn-reg-management-07.txt   draft-ietf-oauth-dyn-reg-management-08.txt 
OAuth Working Group J. Richer OAuth Working Group J. Richer
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Experimental M. Jones Intended status: Experimental M. Jones
Expires: July 19, 2015 Microsoft Expires: July 31, 2015 Microsoft
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
January 15, 2015 January 27, 2015
OAuth 2.0 Dynamic Client Registration Management Protocol OAuth 2.0 Dynamic Client Registration Management Protocol
draft-ietf-oauth-dyn-reg-management-07 draft-ietf-oauth-dyn-reg-management-08
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 July 19, 2015. This Internet-Draft will expire on July 31, 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 5, line 51 skipping to change at page 5, line 51
The client configuration endpoint MUST require transport-layer The client configuration endpoint MUST require transport-layer
security. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and MAY security. 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].
Operations on this endpoint are switched through the use of different Operations on this endpoint are switched through the use of different
HTTP methods [RFC2616]. If an authorization server does not support HTTP methods [RFC7231]. If an authorization server does not support
a particular method on the client configuration endpoint, it MUST a particular method on the client configuration endpoint, it MUST
respond with the appropriate error code. respond with the appropriate error code.
2.1. Client Read Request 2.1. Client Read Request
To read the current configuration of the client on the authorization To read the current configuration of the client on the authorization
server, the client makes an HTTP GET request to the client server, the client makes an HTTP GET request to the client
configuration endpoint, authenticating with its registration access configuration endpoint, authenticating with its registration access
token. token.
skipping to change at page 13, line 15 skipping to change at page 13, line 15
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), August 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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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
(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.
[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
(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.
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
skipping to change at page 16, line 19 skipping to change at page 16, line 19
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 ]]
-08
o Updated HTTP RFC reference.
-07 -07
o Editorial clarifications due to document shepherd feedback. o Editorial clarifications due to document shepherd feedback.
-06 -06
o Removed TLS 1.0. o Removed TLS 1.0.
o Moved several explanatory sections to the appendix. o Moved several explanatory sections to the appendix.
 End of changes. 8 change blocks. 
9 lines changed or deleted 12 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/