draft-ietf-oauth-dyn-reg-management-04.txt   draft-ietf-oauth-dyn-reg-management-05.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: February 6, 2015 Microsoft Expires: February 27, 2015 Microsoft
J. Bradley J. Bradley
Ping Identity Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
P. Hunt August 26, 2014
Oracle Corporation
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-04 draft-ietf-oauth-dyn-reg-management-05
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. 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
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 February 6, 2015. This Internet-Draft will expire on February 27, 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
skipping to change at page 6, line 37 skipping to change at page 6, line 37
configuration endpoint. The client credentials can be rotated configuration endpoint. The client credentials can be rotated
through the use of the client update method on the client through the use of the client update method on the client
configuration endpoint. The client credentials cannot be used for configuration endpoint. The client credentials cannot be used for
authentication at the client registration endpoint or at the authentication at the client registration endpoint or at the
client configuration endpoint. client configuration endpoint.
1.4.1. Credential Rotation 1.4.1. Credential Rotation
The Authorization Server MAY rotate the client's registration access The Authorization Server MAY rotate the client's registration access
token and/or client credentials (such as a "client_secret") token and/or client credentials (such as a "client_secret")
throughout the lifetime of the client. The client can discovery that throughout the lifetime of the client. The client can discover that
these values have changed by reading the client information response these values have changed by reading the client information response
returned from either a read or update request to the client returned from either a read or update request to the client
configuration endpoint. The client's current registration access configuration endpoint. The client's current registration access
token and client credentials (if applicable) MUST be included in this token and client credentials (if applicable) MUST be included in this
response. response.
The registration access token SHOULD be rotated only in response to The registration access token SHOULD be rotated only in response to
an update request to the client configuration endpoint, at which an update request to the client configuration endpoint, at which
point the new registration access token is returned to the client and point the new registration access token is returned to the client and
the old registration access token SHOULD be discarded by both the old registration access token SHOULD be discarded by both
skipping to change at page 9, line 18 skipping to change at page 9, line 18
parameters as top- level members of that JSON object. parameters as top- level members of that JSON object.
This request MUST include all client metadata fields as returned to This request MUST include all client metadata fields as returned to
the client from a previous registration, read, or update operation. the client from a previous registration, read, or update operation.
The client MUST NOT include the "registration_access_token", The client MUST NOT include the "registration_access_token",
"registration_client_uri", "client_secret_expires_at", or "registration_client_uri", "client_secret_expires_at", or
"client_id_issued_at" fields described in Section 3.1. "client_id_issued_at" fields described in Section 3.1.
Valid values of client metadata fields in this request MUST replace, Valid values of client metadata fields in this request MUST replace,
not augment, the values previously associated with this client. not augment, the values previously associated with this client.
Omitted fields MUST be treated as null or empty values by the server. Omitted fields MUST be treated as null or empty values by the server,
indicating the client's request to delete them from the client's
registration. The authorization server MAY ignore any null or empty
value in the request just as any other value.
The client MUST include its "client_id" field in the request, and it The client MUST include its "client_id" field in the request, and it
MUST be the same as its currently-issued client identifier. If the MUST be the same as its currently-issued client identifier. If the
client includes the "client_secret" field in the request, the value client includes the "client_secret" field in the request, the value
of this field MUST match the currently-issued client secret for that of this field MUST match the currently-issued client secret for that
client. The client MUST NOT be allowed to overwrite its existing client. The client MUST NOT be allowed to overwrite its existing
client secret with its own chosen value. client secret with its own chosen value.
For all metadata fields, the authorization server MAY replace any For all metadata fields, the authorization server MAY replace any
invalid values with suitable default values, and it MUST return any invalid values with suitable default values, and it MUST return any
skipping to change at page 11, line 32 skipping to change at page 11, line 32
A successful delete action will invalidate the "client_id", A successful delete action will invalidate the "client_id",
"client_secret", and "registration_access_token" for this client, "client_secret", and "registration_access_token" for this client,
thereby preventing the "client_id" from being used at either the thereby preventing the "client_id" from being used at either the
authorization endpoint or token endpoint of the authorization server. authorization endpoint or token endpoint of the authorization server.
The authorization server SHOULD immediately invalidate all existing The authorization server SHOULD immediately invalidate all existing
authorization grants and currently-active tokens associated with this authorization grants and currently-active tokens associated with this
client. client.
If a client has been successfully deprovisioned, the authorization If a client has been successfully deprovisioned, the authorization
server responds with an HTTP 204 No Content message. server MUST responsd with an HTTP 204 No Content message.
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
skipping to change at page 13, line 42 skipping to change at page 13, line 42
"jwks_uri": "https://client.example.org/my_public_keys.jwks" "jwks_uri": "https://client.example.org/my_public_keys.jwks"
} }
4. IANA Considerations 4. IANA Considerations
This specification makes no requests of IANA. This specification makes no requests of IANA.
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 or updating the
client's registration information. Were that the case, a new client's registration information. Were that the case, a new
registration would be required, thereby generating a new client 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 an update operation on the rotated when the developer or client does a read or update operation
client's client configuration endpoint. As the registration access on the client's client configuration endpoint. As the registration
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 the client configuration endpoint is an OAuth 2.0 protected Since the client configuration endpoint is an OAuth 2.0 protected
resource, it SHOULD have some rate limiting on failures to prevent resource, it SHOULD have some rate limiting on failures to prevent
the registration access token from being disclosed though repeated the registration access token from being disclosed though repeated
access attempts. access attempts.
skipping to change at page 15, line 14 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 ]]
-05
o Removed Phil Hunt from authors list, per request.
o Applied various minor editorial changes from working group
comments.
-04 -04
o Re-released with no changes other than to the version number so o Incorrect XML uploaded for -03
that the correct XML source is released with the compiled output.
-03 -03
o Changed draft to be Experimental instead of Standards Track. 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
skipping to change at page 16, line 14 skipping to change at line 699
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: m.p.machulak@ncl.ac.uk
URI: http://ncl.ac.uk/ URI: http://ncl.ac.uk/
Phil Hunt
Oracle Corporation
Email: phil.hunt@yahoo.com
 End of changes. 13 change blocks. 
16 lines changed or deleted 23 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/