draft-ietf-oauth-dyn-reg-13.txt   draft-ietf-oauth-dyn-reg-14.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: January 03, 2014 Ping Identity Expires: January 30, 2014 Ping Identity
M. Jones M. Jones
Microsoft Microsoft
M. Machulak M. Machulak
Newcastle University Newcastle University
July 02, 2013 July 29, 2013
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-13 draft-ietf-oauth-dyn-reg-14
Abstract Abstract
This specification defines an endpoint and protocol for dynamic This specification defines an endpoint and protocol for dynamic
registration of OAuth 2.0 clients at an authorization server and registration of OAuth 2.0 clients at an authorization server and
methods for the dynamically registered client to manage its methods for the dynamically registered client to manage its
registration through an OAuth 2.0 protected web API. registration through an OAuth 2.0 protected web API.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 January 03, 2014. This Internet-Draft will expire on January 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Registration Tokens and Client Credentials . . . . . . . 6 1.4. Registration Tokens and Client Credentials . . . . . . . 6
1.4.1. Credential Rotation . . . . . . . . . . . . . . . . . 7 1.4.1. Credential Rotation . . . . . . . . . . . . . . . . . 7
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Relationship Between Grant Types and Response Types . . . 10 2.1. Relationship Between Grant Types and Response Types . . . 11
2.2. Human Readable Client Metadata . . . . . . . . . . . . . 11 2.2. Human Readable Client Metadata . . . . . . . . . . . . . 11
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 12 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13
3.1. Client Registration Request . . . . . . . . . . . . . . . 13 3.1. Client Registration Request . . . . . . . . . . . . . . . 13
3.2. Client Registration Response . . . . . . . . . . . . . . 15 3.2. Client Registration Response . . . . . . . . . . . . . . 15
4. Client Configuration Endpoint . . . . . . . . . . . . . . . . 15 4. Client Configuration Endpoint . . . . . . . . . . . . . . . . 15
4.1. Forming the Client Configuration Endpoint URL . . . . . . 15 4.1. Forming the Client Configuration Endpoint URL . . . . . . 16
4.2. Client Read Request . . . . . . . . . . . . . . . . . . . 16 4.2. Client Read Request . . . . . . . . . . . . . . . . . . . 16
4.3. Client Update Request . . . . . . . . . . . . . . . . . . 17 4.3. Client Update Request . . . . . . . . . . . . . . . . . . 17
4.4. Client Delete Request . . . . . . . . . . . . . . . . . . 19 4.4. Client Delete Request . . . . . . . . . . . . . . . . . . 19
5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Client Information Response . . . . . . . . . . . . . . . 20 5.1. Client Information Response . . . . . . . . . . . . . . . 20
5.2. Client Registration Error Response . . . . . . . . . . . 21 5.2. Client Registration Error Response . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6.1. OAuth Token Endpoint Authentication Methods Registry . . 22 6.1. OAuth Token Endpoint Authentication Methods Registry . . 23
6.1.1. Registration Template . . . . . . . . . . . . . . . . 23 6.1.1. Registration Template . . . . . . . . . . . . . . . . 24
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 23 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Normative References . . . . . . . . . . . . . . . . . . . . 26 8. Normative References . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28
Appendix B. Client Lifecycle Examples . . . . . . . . . . . . . 27 Appendix B. Client Lifecycle Examples . . . . . . . . . . . . . 28
B.1. Open Registration . . . . . . . . . . . . . . . . . . . . 28 B.1. Open Registration . . . . . . . . . . . . . . . . . . . . 29
B.2. Protected Registration . . . . . . . . . . . . . . . . . 29 B.2. Protected Registration . . . . . . . . . . . . . . . . . 30
B.3. Developer Automation . . . . . . . . . . . . . . . . . . 30 B.3. Developer Automation . . . . . . . . . . . . . . . . . . 31
Appendix C. Document History . . . . . . . . . . . . . . . . . . 32 Appendix C. Document History . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
In some use-case scenarios, it is desirable or necessary to allow In some use-case scenarios, it is desirable or necessary to allow
OAuth 2.0 clients to obtain authorization from an OAuth 2.0 OAuth 2.0 clients to obtain authorization from an OAuth 2.0
authorization server without requiring the two parties to interact authorization server without requiring the two parties to interact
beforehand. Nevertheless, for the authorization server to accurately beforehand. Nevertheless, for the authorization server to accurately
and securely represent to end-users which client is seeking and securely represent to end-users which client is seeking
authorization to access the end-user's resources, a method for authorization to access the end-user's resources, a method for
automatic and unique registration of clients is needed. The OAuth automatic and unique registration of clients is needed. The OAuth
skipping to change at page 7, line 9 skipping to change at page 7, line 9
configuration endpoint. The client credentials can be rotated configuration endpoint. The client credentials can be rotated
through the use of the client read and update methods on the through the use of the client read and update methods on the
client configuration endpoint. The client credentials can not be client configuration endpoint. The client credentials can not be
used for authentication at the client registration endpoint or at used for authentication at the client registration endpoint or at
the client configuration endpoint. the 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 is informed of the throughout the lifetime of the client. The client can discovery that
changed values changing by making either read or update requests to these values have changed by reading the client information response
the client configuration endpoint, and the new values of the returned from either a read or update request to the client
registration access token and the client credentials will be included configuration endpoint. The client's current registration access
in the client information response. token and client credentials (if applicable) MUST be included in this
response.
The registration access token SHOULD be rotated only in response to a The registration access token SHOULD be rotated only in response to a
read or update request to the client configuration endpoint, at which read or 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
parties. If the registration access token to expire or be rotated parties. If the registration access token to expire or be rotated
outside of such requests, the client or developer may be locked out outside of such requests, the client or developer may be locked out
of managing the client's configuration. of managing the client's configuration.
2. Client Metadata 2. Client Metadata
skipping to change at page 10, line 35 skipping to change at page 10, line 35
response type extensions to OAuth 2.0. The extension process is response type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5. If the authorization endpoint described in OAuth 2.0 Section 2.5. If the authorization endpoint
is used by the grant type, the value of this parameter MUST be the is used by the grant type, the value of this parameter MUST be the
same as the value of the "response_type" parameter passed to the same as the value of the "response_type" parameter passed to the
authorization endpoint defined in the extension. authorization endpoint defined in the extension.
jwks_uri jwks_uri
URL for the Client's JSON Web Key Set [JWK] document representing URL for the Client's JSON Web Key Set [JWK] document representing
the client's public keys. The value of this field MUST point to a the client's public keys. The value of this field MUST point to a
valid JWK Set. These keys MAY be used for higher level protocols valid JWK Set. These keys MAY be used for higher level protocols
that require signing or encryption. that require signing or encryption.
software_id
A identifier for the software that comprises a client. Unlike
"client_id", which is issued by the authorization server and
generally varies between instances, the "software_id" is asserted
by the client software and is intended to be shared between all
copies of the client software. The value for this field MAY be a
UUID [RFC4122]. The identifier SHOULD NOT change when software
version changes or when a new installation instance is detected.
Authorization servers MUST treat this field as self-asserted by
the client and MUST NOT make any trusted decisions on the value of
this field alone.
software_version
A version identifier for the software that comprises a client.
The value of this field is a string that is intended to be
compared using string equality matching. The value of the
"software_version" SHOULD change on any update to the client
software. Authorization servers MUST treat this field as self-
asserted by the client and MUST NOT make any trusted decisions on
the value of this field alone.
2.1. Relationship Between Grant Types and Response Types 2.1. Relationship Between Grant Types and Response Types
The "grant_types" and "response_types" values described above are The "grant_types" and "response_types" values described above are
partially orthogonal, as they refer to arguments passed to different partially orthogonal, as they refer to arguments passed to different
endpoints in the OAuth protocol. However, they are related in that endpoints in the OAuth protocol. However, they are related in that
the "grant_types" available to a client influence the the "grant_types" available to a client influence the
"response_types" that the client is allowed to use, and vice versa. "response_types" that the client is allowed to use, and vice versa.
For instance, a "grant_types" value that includes For instance, a "grant_types" value that includes
"authorization_code" implies a "response_types" value that includes "authorization_code" implies a "response_types" value that includes
skipping to change at page 12, line 33 skipping to change at page 13, line 9
in many programming environments. Therefore, implementations will in many programming environments. Therefore, implementations will
need to use alternative access forms for these claims. For instance, need to use alternative access forms for these claims. For instance,
in JavaScript, if one parses the JSON as follows, "var j = in JavaScript, if one parses the JSON as follows, "var j =
JSON.parse(json);", then the member "client_name#en-us" can be JSON.parse(json);", then the member "client_name#en-us" can be
accessed using the JavaScript syntax "j["client_name#en-us"]". accessed using the JavaScript syntax "j["client_name#en-us"]".
3. Client Registration Endpoint 3. Client Registration Endpoint
The client registration endpoint is an OAuth 2.0 endpoint defined in The client registration endpoint is an OAuth 2.0 endpoint defined in
this document that is designed to allow a client to be registered this document that is designed to allow a client to be registered
with the authorization server. The client registration Endpoint MUST with the authorization server. The client registration endpoint MUST
accept HTTP POST messages with request parameters encoded in the accept HTTP POST messages with request parameters encoded in the
entity body using the "application/json" format. The client entity body using the "application/json" format. The client
registration endpoint MUST be protected by a transport-layer security registration endpoint MUST be protected by a transport-layer security
mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246] and mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246] and
/or TLS 1.0 [RFC2246] and MAY support additional transport-layer /or TLS 1.0 [RFC2246] and MAY support additional transport-layer
mechanisms meeting its security requirements. When using TLS, the mechanisms meeting its security requirements. When using TLS, the
Client MUST perform a TLS/SSL server certificate check, per RFC 6125 Client MUST perform a TLS/SSL server certificate check, per RFC 6125
[RFC6125]. [RFC6125].
The client registration endpoint MAY be an OAuth 2.0 protected The client registration endpoint MAY be an OAuth 2.0 protected
skipping to change at page 17, line 16 skipping to change at page 17, line 16
content type of "application/json" and a payload as described in content type of "application/json" and a payload as described in
Client Information Response (Section 5.1). Some values in the Client Information Response (Section 5.1). Some values in the
response, including the "client_secret" and response, including the "client_secret" and
"registration_access_token", MAY be different from those in the "registration_access_token", MAY be different from those in the
initial registration response. If the authorization server includes initial registration response. If the authorization server includes
a new client secret and/or registration access token in its response, a new client secret and/or registration access token in its response,
the client MUST immediately discard its previous client secret and/or the client MUST immediately discard its previous client secret and/or
registration access token. The value of the "client_id" MUST NOT registration access token. The value of the "client_id" MUST NOT
change from the initial registration response. change from the initial registration response.
If the registration access token used to make this request is not
valid, the server MUST respond with an error as described in OAuth
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 the client does not have permission to read its record, the server If the client does not have permission to read its record, the server
MUST return an HTTP 403 Forbidden. MUST return an HTTP 403 Forbidden.
4.3. Client Update Request 4.3. Client Update Request
This operation updates a previously-registered client with new This operation updates a previously-registered client with new
skipping to change at page 18, line 47 skipping to change at page 19, line 5
HTTP 200 OK Message with content type "application/json" and a HTTP 200 OK Message with content type "application/json" and a
payload as described in Client Information Response (Section 5.1). payload as described in Client Information Response (Section 5.1).
Some values in the response, including the "client_secret" and Some values in the response, including the "client_secret" and
r"egistration_access_token", MAY be different from those in the r"egistration_access_token", MAY be different from those in the
initial registration response. If the authorization server includes initial registration response. If the authorization server includes
a new client secret and/or registration access token in its response, a new client secret and/or registration access token in its response,
the client MUST immediately discard its previous client secret and/or the client MUST immediately discard its previous client secret and/or
registration access token. The value of the "client_id" MUST NOT registration access token. The value of the "client_id" MUST NOT
change from the initial registration response. change from the initial registration response.
If the registration access token used to make this request is not
valid, the server MUST respond with an error as described in OAuth
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 the client is not allowed to update its records, the server MUST If the client is not allowed to update its records, the server MUST
respond with HTTP 403 Forbidden. respond with HTTP 403 Forbidden.
If the client attempts to set an invalid metadata field and the If the client attempts to set an invalid metadata field and the
authorization server does not set a default value, the authorization authorization server does not set a default value, the authorization
server responds with an error as described in Client Registration server responds with an error as described in Client Registration
skipping to change at page 19, line 41 skipping to change at page 20, line 5
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 responds 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
valid, the server MUST respond with an error as described in OAuth
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 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
skipping to change at page 20, line 20 skipping to change at page 20, line 33
In response to certain requests from the client to either the client In response to certain requests from the client to either the client
registration endpoint or the client configuration endpoint as registration endpoint or the client configuration endpoint as
described in this specification, the authorization server sends the described in this specification, the authorization server sends the
following response bodies. following response bodies.
5.1. Client Information Response 5.1. Client Information Response
The response contains the client identifier as well as the client The response contains the client identifier as well as the client
secret, if the client is a confidential client. The response also secret, if the client is a confidential client. The response also
contains the fully qualified URL to the client configuration endpoint contains the fully qualified URL of the client configuration endpoint
for this specific client that the client may use to obtain and update for this specific client that the client may use to obtain and update
information about itself. The response also contains a registration information about itself. The response also contains a registration
access token that is to be used by the client to perform subsequent access token that is to be used by the client to perform subsequent
operations at the client configuration endpoint. operations at the client configuration endpoint.
client_id client_id
REQUIRED. The unique client identifier, MUST NOT be currently REQUIRED. The unique client identifier, MUST NOT be currently
valid for any other registered client. valid for any other registered client.
client_secret client_secret
OPTIONAL. The client secret. If issued, this MUST be unique for OPTIONAL. The client secret. If issued, this MUST be unique for
each "client_id". This value is used by confidential clients to each "client_id". This value is used by confidential clients to
authenticate to the token endpoint as described in OAuth 2.0 authenticate to the token endpoint as described in OAuth 2.0
Section 2.3.1. [RFC6749] Section 2.3.1.
client_id_issued_at client_id_issued_at
OPTIONAL. Time at which the Client Identifier was issued. The OPTIONAL. Time at which the Client Identifier was issued. The
time is represented as the number of seconds from time is represented as the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time. 1970-01-01T0:0:0Z as measured in UTC until the date/time.
client_secret_expires_at client_secret_expires_at
REQUIRED if "client_secret" is issued. Time at which the REQUIRED if "client_secret" is issued. Time at which the
"client_secret" will expire or 0 if it will not expire. The time "client_secret" will expire or 0 if it will not expire. The time
is represented as the number of seconds from 1970-01-01T0:0:0Z as is represented as the number of seconds from 1970-01-01T0:0:0Z as
measured in UTC until the date/time. measured in UTC until the date/time.
registration_access_token registration_access_token
REQUIRED. Access token that is used at the client configuration REQUIRED. Access token that is used at the client configuration
endpoint to perform subsequent operations upon the client endpoint to perform subsequent operations upon the client
registration. registration.
registration_client_uri registration_client_uri
skipping to change at page 24, line 39 skipping to change at page 25, line 30
access attempts. access attempts.
For clients that use redirect-based grant types such as For clients that use redirect-based grant types such as
"authorization_code" and "implicit", authorization servers SHOULD "authorization_code" and "implicit", authorization servers SHOULD
require clients to register their "redirect_uris". Requiring clients require clients to register their "redirect_uris". Requiring clients
to do so can help mitigate attacks where rogue actors inject and to do so can help mitigate attacks where rogue actors inject and
impersonate a validly registered client and intercept its impersonate a validly registered client and intercept its
authorization code or tokens through an invalid redirect URI. authorization code or tokens through an invalid redirect URI.
The authorization server MUST treat all client metadata as self- The authorization server MUST treat all client metadata as self-
asserted. A rogue client might use the name and logo for the asserted. For instance, a rogue client might use the name and logo
legitimate client, which it is trying to impersonate. An for the legitimate client which it is trying to impersonate.
authorization server needs to take steps to mitigate this phishing Additionally, a rogue client might try to use the software identifier
risk, since the logo could confuse users into thinking they're or software version of a legitimate client to attempt to associate
logging in to the legitimate client. For instance, an authorization itself on the authorization server instances of the legitimate
server could warn if the domain/site of the logo doesn't match the client. To counteract this, an authorization server needs to take
domain/site of redirect URIs. An authorization server can also steps to mitigate this phishing risk by looking at the entire
present warning messages to end users about untrusted clients in all registration request and client configuration. For instance, an
cases, especially if such clients have been recently registered and authorization server could warn if the domain/site of the logo
have not been trusted by any users at the authorization server doesn't match the domain/site of redirect URIs. An authorization
server could also refuse registration from a known software
identifier that is requesting different redirect URIs or a different
client homepage uri. An authorization server can also present
warning messages to end users about dynamically registered clients in
all cases, especially if such clients have been recently registered
or have not been trusted by any users at the authorization server
before. before.
In a situation where the authorization server is supporting open In a situation where the authorization server is supporting open
client registration, it must be extremely careful with any URL client registration, it must be extremely careful with any URL
provided by the client that will be displayed to the user (e.g. provided by the client that will be displayed to the user (e.g.
"logo_uri", "tos_uri", "client_uri", and "policy_uri"). For "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For
instance, a rogue client could specify a registration request with a instance, a rogue client could specify a registration request with a
reference to a drive-by download in the "policy_uri". The reference to a drive-by download in the "policy_uri". The
authorization server SHOULD check to see if the "logo_uri", authorization server SHOULD check to see if the "logo_uri",
"tos_uri", "client_uri", and "policy_uri" have the same host and "tos_uri", "client_uri", and "policy_uri" have the same host and
skipping to change at page 27, line 9 skipping to change at page 28, line 5
[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.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[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.
skipping to change at page 32, line 12 skipping to change at page 33, line 12
i. If the client is deprovisioned, the developer's deployment system i. If the client is deprovisioned, the developer's deployment system
can send an HTTP DELETE request to the "registration_client_uri" can send an HTTP DELETE request to the "registration_client_uri"
with the "registration_access_token" as its authorization. This with the "registration_access_token" as its authorization. This
will effectively deprovision the client from the authorization will effectively deprovision the client from the authorization
server and prevent any instances of the client from functioning. server and prevent any instances of the client from functioning.
Appendix C. Document History Appendix C. 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 ]]
-14
o Added software_id and software_version metadata fields
o Added direct references to RFC6750 errors in read/update/delete
methods
-13 -13
o Fixed broken example text in registration request and in delete o Fixed broken example text in registration request and in delete
request request
o Added security discussion of separating clients of different grant o Added security discussion of separating clients of different grant
types types
o Fixed error reference to point to RFC6750 instead of RFC6749 o Fixed error reference to point to RFC6750 instead of RFC6749
o Clarified that servers must respond to all requests to o Clarified that servers must respond to all requests to
configuration endpoint, even if it's just an error code configuration endpoint, even if it's just an error code
o Lowercased all Terms to conform to style used in RFC6750 o Lowercased all Terms to conform to style used in RFC6750
 End of changes. 20 change blocks. 
39 lines changed or deleted 88 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/