draft-ietf-oauth-dyn-reg-management-09.txt   draft-ietf-oauth-dyn-reg-management-10.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: August 13, 2015 Microsoft Expires: September 24, 2015 Microsoft
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
February 9, 2015 March 23, 2015
OAuth 2.0 Dynamic Client Registration Management Protocol OAuth 2.0 Dynamic Client Registration Management Protocol
draft-ietf-oauth-dyn-reg-management-09 draft-ietf-oauth-dyn-reg-management-10
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 August 13, 2015. This Internet-Draft will expire on September 24, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
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. Normative References . . . . . . . . . . . . . . . . . . . . 13 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 2, line 45 skipping to change at page 2, line 46
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
registered with the server. registered with the server.
This specification extends the core registration specification by This specification extends the core registration specification by
defining a set of methods for management of dynamic OAuth 2.0 client defining a set of methods for management of dynamic OAuth 2.0 client
registrations beyond those defined in the core registration registrations beyond those defined in the core registration
specification. specification. In some situations, the registered metadata of a
client can change over time, either by modification at the
authorization server or by a change in the client software itself.
This specification provides methods for the current registration
state of a client to be queried at the authorization server, methods
for the registration of a client to be updated at the authorization
server, and methods for the client to be unregistered from the
authorization server.
1.1. Notational Conventions 1.1. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
(B) Optionally, the client or developer is issued a software (B) Optionally, the client or developer is issued a software
statement for use with the client registration endpoint. The statement for use with the client registration endpoint. The
method by which the software statement is issued to the client or method by which the software statement is issued to the client or
developer is out of scope for this specification. developer is out of scope for this specification.
(C) The client or developer calls the client registration endpoint (C) The client or developer calls the client registration endpoint
with its desired registration metadata, optionally including the with its desired registration metadata, optionally including the
initial access token from (A) if one is required by the initial access token from (A) if one is required by the
authorization server. authorization server.
(D) The authorization server registers the client and returns the (D) The authorization server registers the client and returns:
client's registered metadata, a client identifier that is unique
at the server, a set of client credentials such as a client secret * the client's registered metadata,
if applicable for this client, a URI pointing to the client
configuration endpoint, and a registration access token to be used * a client identifier that is unique at the server,
when calling the client configuration endpoint.
* a set of client credentials such as a client secret, if
applicable for this client,
* a URI pointing to the client configuration endpoint, and
* a registration access token to be used when calling the client
configuration endpoint.
(E) The client or developer optionally calls the client (E) The client or developer optionally calls the client
configuration endpoint with a read or update request using the configuration endpoint with a read or update request using the
registration access token issued in (D). An update request registration access token issued in (D). An update request
contains all of the client's registered metadata. contains all of the client's registered metadata.
(F) The authorization server responds with the client's current (F) The authorization server responds with the client's current
configuration, potentially including a new registration access configuration, potentially including a new registration access
token and a new set of client credentials such as a client secret token and a new set of client credentials such as a client secret
if applicable for this client. If a new registration access token if applicable for this client. If a new registration access token
skipping to change at page 5, line 42 skipping to change at page 5, line 49
The client configuration endpoint is an OAuth 2.0 protected resource The client configuration endpoint is an OAuth 2.0 protected resource
that is provisioned by the server to facilitate viewing, updating, that is provisioned by the server to facilitate viewing, updating,
and deleting a client's registered information. The location of this and deleting a client's registered information. The location of this
endpoint is communicated to the client through the endpoint is communicated to the client through the
"registration_client_uri" member of the client information response, "registration_client_uri" member of the client information response,
as specified in Section 3. The client MUST use its registration as specified in Section 3. The client MUST use its registration
access token in all calls to this endpoint as an OAuth 2.0 Bearer access token in all calls to this endpoint as an OAuth 2.0 Bearer
Token [RFC6750]. Token [RFC6750].
The client configuration endpoint MUST require transport-layer The client configuration endpoint MUST be protected by a transport-
security. The server MUST support TLS 1.2 RFC 5246 [RFC5246] and MAY layer security mechanism, as described in Section 5.
support additional transport-layer mechanisms meeting its security
requirements. When using TLS, the client MUST perform a TLS/SSL
server certificate check, per RFC 6125 [RFC6125]. Implementation
security considerations can be found in Recommendations for Secure
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 [RFC7231]. 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
skipping to change at page 9, line 43 skipping to change at page 9, line 43
If the server does not support the delete method, the server MUST If the server does not support the delete method, the server MUST
respond with an HTTP 405 Not Supported. respond with an HTTP 405 Not Supported.
If the registration access token used to make this request is not If the registration access token used to make this request is not
valid, the server MUST respond with an error as described in OAuth valid, the server MUST respond with an error as described in OAuth
Bearer Token Usage [RFC6750]. Bearer Token Usage [RFC6750].
If the client does not exist on this server, the server MUST respond If the client does not exist on this server, the server MUST respond
with HTTP 401 Unauthorized and the registration access token used to with HTTP 401 Unauthorized and the registration access token used to
make this request SHOULD be immediately revoked. make this request SHOULD be immediately revoked, if possible.
If the client is not allowed to delete itself, the server MUST If the client is not allowed to delete itself, the server MUST
respond with HTTP 403 Forbidden. respond with HTTP 403 Forbidden.
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
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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. 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. Privacy Considerations
This specification poses no additional privacy considerations beyond
those described in the core OAuth 2.0 Dynamic Client Registration
[OAuth.Registration] specification.
7. 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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
skipping to change at page 16, line 19 skipping to change at page 16, line 23
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 ]]
-10
o Updated author information.
o Updated TLS information, imported from Dynamic Registration core.
o Expanded introduction.
o Reformatted diagram text.
o Added privacy considerations section.
-09 -09
o Updated author information. o Updated author information.
-08 -08
o Updated HTTP RFC reference. o Updated HTTP RFC reference.
-07 -07
skipping to change at page 17, line 32 skipping to change at page 18, line 4
Justin Richer (editor) Justin Richer (editor)
Email: ietf@justin.richer.org Email: ietf@justin.richer.org
Michael B. Jones Michael B. Jones
Microsoft Microsoft
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
John Bradley John Bradley
Ping Identity Ping Identity
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
Maciej Machulak Maciej Machulak
Newcastle University Newcastle University
Email: m.p.machulak@ncl.ac.uk Email: maciej.machulak@gmail.com
URI: http://ncl.ac.uk/
 End of changes. 14 change blocks. 
23 lines changed or deleted 50 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/