draft-ietf-oauth-dyn-reg-28.txt   draft-ietf-oauth-dyn-reg-29.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track M. Jones Intended status: Standards Track 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
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
April 21, 2015 May 5, 2015
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-28 draft-ietf-oauth-dyn-reg-29
Abstract Abstract
This specification defines mechanisms for dynamically registering This specification defines mechanisms for dynamically registering
OAuth 2.0 clients with authorization servers. Registration requests OAuth 2.0 clients with authorization servers. Registration requests
send a set of desired client metadata values to the authorization send a set of desired client metadata values to the authorization
server. The resulting registration responses return a client server. The resulting registration responses return a client
identifier to use at the authorization server and the client metadata identifier to use at the authorization server and the client metadata
values registered for the client. The client can then use this values registered for the client. The client can then use this
registration information to communicate with the authorization server registration information to communicate with the authorization server
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 2, line 39 skipping to change at page 2, line 39
2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12 2.3. Software Statement . . . . . . . . . . . . . . . . . . . 12
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 14 3. Client Registration Endpoint . . . . . . . . . . . . . . . . 14
3.1. Client Registration Request . . . . . . . . . . . . . . . 14 3.1. Client Registration Request . . . . . . . . . . . . . . . 14
3.1.1. Client Registration Request Using a Software 3.1.1. Client Registration Request Using a Software
Statement . . . . . . . . . . . . . . . . . . . . . . 16 Statement . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Client Information Response . . . . . . . . . . . . . 17 3.2.1. Client Information Response . . . . . . . . . . . . . 17
3.2.2. Client Registration Error Response . . . . . . . . . 19 3.2.2. Client Registration Error Response . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4.1. OAuth Dynamic Client Registration Metadata Registry . . . 21 4.1. OAuth Dynamic Client Registration Metadata Registry . . . 21
4.1.1. Registration Template . . . . . . . . . . . . . . . . 21 4.1.1. Registration Template . . . . . . . . . . . . . . . . 22
4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22 4.1.2. Initial Registry Contents . . . . . . . . . . . . . . 22
4.2. OAuth Token Endpoint Authentication Methods Registry . . 24 4.2. OAuth Token Endpoint Authentication Methods Registry . . 25
4.2.1. Registration Template . . . . . . . . . . . . . . . . 25 4.2.1. Registration Template . . . . . . . . . . . . . . . . 25
4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 25 4.2.2. Initial Registry Contents . . . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1. Normative References . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . 31 7.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 32
A.1. Open versus Protected Dynamic Client Registration . . . . 32 A.1. Open versus Protected Dynamic Client Registration . . . . 32
A.1.1. Open Dynamic Client Registration . . . . . . . . . . 32 A.1.1. Open Dynamic Client Registration . . . . . . . . . . 32
A.1.2. Protected Dynamic Client Registration . . . . . . . . 32 A.1.2. Protected Dynamic Client Registration . . . . . . . . 32
A.2. Registration Without or With Software Statements . . . . 32 A.2. Registration Without or With Software Statements . . . . 33
A.2.1. Registration Without a Software Statement . . . . . . 32 A.2.1. Registration Without a Software Statement . . . . . . 33
A.2.2. Registration With a Software Statement . . . . . . . 32 A.2.2. Registration With a Software Statement . . . . . . . 33
A.3. Registration by the Client or Developer . . . . . . . . . 32 A.3. Registration by the Client or Developer . . . . . . . . . 33
A.3.1. Registration by the Client . . . . . . . . . . . . . 32 A.3.1. Registration by the Client . . . . . . . . . . . . . 33
A.3.2. Registration by the Developer . . . . . . . . . . . . 33 A.3.2. Registration by the Developer . . . . . . . . . . . . 33
A.4. Client ID per Client Instance or per Client Software . . 33 A.4. Client ID per Client Instance or per Client Software . . 33
A.4.1. Client ID per Client Software Instance . . . . . . . 33 A.4.1. Client ID per Client Software Instance . . . . . . . 34
A.4.2. Client ID Shared Among All Instances of Client A.4.2. Client ID Shared Among All Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . 33 Software . . . . . . . . . . . . . . . . . . . . . . 34
A.5. Stateful or Stateless Registration . . . . . . . . . . . 33 A.5. Stateful or Stateless Registration . . . . . . . . . . . 34
A.5.1. Stateful Client Registration . . . . . . . . . . . . 33 A.5.1. Stateful Client Registration . . . . . . . . . . . . 34
A.5.2. Stateless Client Registration . . . . . . . . . . . . 34 A.5.2. Stateless Client Registration . . . . . . . . . . . . 34
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 35
Appendix C. Document History . . . . . . . . . . . . . . . . . . 34 Appendix C. Document History . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0 In order for an OAuth 2.0 [RFC6749] client to utilize an OAuth 2.0
authorization server, the client needs specific information to authorization server, the client needs specific information to
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. This specification describes how an OAuth 2.0 use at that server. This specification describes how an OAuth 2.0
client can be dynamically registered with an authorization server to client can be dynamically registered with an authorization server to
obtain this information. obtain this information.
skipping to change at page 18, line 36 skipping to change at page 18, line 36
metadata about this client, including any fields provisioned by the metadata about this client, including any fields provisioned by the
authorization server itself. The authorization server MAY reject or authorization server itself. The authorization server MAY reject or
replace any of the client's requested metadata values submitted replace any of the client's requested metadata values submitted
during the registration and substitute them with suitable values. during the registration and substitute them with suitable values.
The client or developer can check the values in the response to The client or developer can check the values in the response to
determine if the registration is sufficient for use (e.g., the determine if the registration is sufficient for use (e.g., the
registered "token_endpoint_auth_method" is supported by the client registered "token_endpoint_auth_method" is supported by the client
software) and determine a course of action appropriate for the client software) and determine a course of action appropriate for the client
software. The response to such a situation is out of scope for this software. The response to such a situation is out of scope for this
specification but could include filing a report with the application specification but could include filing a report with the application
developer or authorization server provider. developer or authorization server provider, attempted re-registration
with different metadata values, or various other methods. For
instance, if the server also supports a registration management
mechanism such as that defined in [OAuth.Registration.Management],
the client or developer could attempt to update the registration with
different metadata values. This process could also be aided by a
service discovery protocol such as [OpenID.Discovery] which can list
a server's capabilities, allowing a client to make a more informed
registration request. The use of any such management or discovery
system is optional and outside the scope of this specification.
The successful registration response uses an HTTP 201 Created status The successful registration response uses an HTTP 201 Created status
code with a body of type "application/json" consisting of a single code with a body of type "application/json" consisting of a single
JSON object [RFC7159] with all parameters as top-level members of the JSON object [RFC7159] with all parameters as top-level members of the
object. object.
If a software statement was used as part of the registration, its If a software statement was used as part of the registration, its
value MUST be returned unmodified in the response along with other value MUST be returned unmodified in the response along with other
metadata using the "software_statement" member name. Client metadata metadata using the "software_statement" member name. Client metadata
elements used from the software statement MUST also be returned elements used from the software statement MUST also be returned
skipping to change at page 21, line 18 skipping to change at page 21, line 35
This specification establishes the OAuth Dynamic Client Registration This specification establishes the OAuth Dynamic Client Registration
Metadata registry. Metadata registry.
OAuth registration client metadata names and descriptions are OAuth registration client metadata names and descriptions are
registered with a Specification Required ([RFC5226]) after a two-week registered with a Specification Required ([RFC5226]) after a two-week
review period on the oauth-ext-review@ietf.org mailing list, on the review period on the oauth-ext-review@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of names prior to publication, the Designated Expert(s) allocation of names prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published, per [RFC7120].
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register OAuth Dynamic an appropriate subject (e.g., "Request to register OAuth Dynamic
Client Registration Metadata name: example"). Client Registration Metadata name: example").
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
skipping to change at page 24, line 41 skipping to change at page 25, line 16
This specification establishes the OAuth Token Endpoint This specification establishes the OAuth Token Endpoint
Authentication Methods registry. Authentication Methods registry.
Additional values for use as "token_endpoint_auth_method" values are Additional values for use as "token_endpoint_auth_method" values are
registered with a Specification Required ([RFC5226]) after a two-week registered with a Specification Required ([RFC5226]) after a two-week
review period on the oauth-ext-review@ietf.org mailing list, on the review period on the oauth-ext-review@ietf.org mailing list, on the
advice of one or more Designated Experts. However, to allow for the advice of one or more Designated Experts. However, to allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
may approve registration once they are satisfied that such a may approve registration once they are satisfied that such a
specification will be published. specification will be published, per [RFC7120].
Registration requests must be sent to the oauth-ext-review@ietf.org Registration requests must be sent to the oauth-ext-review@ietf.org
mailing list for review and comment, with an appropriate subject mailing list for review and comment, with an appropriate subject
(e.g., "Request to register token_endpoint_auth_method value: (e.g., "Request to register token_endpoint_auth_method value:
example"). example").
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
skipping to change at page 26, line 6 skipping to change at page 26, line 33
Since requests to the client registration endpoint result in the Since requests to the client registration 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
registration endpoint. The server MUST support TLS 1.2 RFC 5246 registration endpoint. The server MUST support TLS 1.2 RFC 5246
[RFC5246] and MAY support additional transport-layer mechanisms [RFC5246] and MAY support additional transport-layer mechanisms
meeting its security requirements. When using TLS, the client MUST meeting its security requirements. When using TLS, the client MUST
perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125].
Implementation security considerations can be found in Implementation security considerations can be found in
Recommendations for Secure Use of TLS and DTLS Recommendations for Secure Use of TLS and DTLS [RFC7525].
[I-D.ietf-uta-tls-bcp].
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 MUST "authorization_code" and "implicit", authorization servers MUST
require clients to register their redirection URI values. This can require clients to register their redirection URI values. This can
help mitigate attacks where rogue actors inject and impersonate a help mitigate attacks where rogue actors inject and impersonate a
validly registered client and intercept its authorization code or validly registered client and intercept its authorization code or
tokens through an invalid redirection URI or open redirector. tokens through an invalid redirection URI or open redirector.
Additionally, in order to prevent hijacking of the return values of Additionally, in order to prevent hijacking of the return values of
the redirection, registered redirection URI values MUST be one of: the redirection, registered redirection URI values MUST be one of:
skipping to change at page 30, line 19 skipping to change at page 30, line 43
applications. However, this technique does incur significant applications. However, this technique does incur significant
usability cost in the form of requiring multiple authorizations per usability cost in the form of requiring multiple authorizations per
resource owner and is therefore unlikely to be used in practice. resource owner and is therefore unlikely to be used in practice.
7. References 7. References
7.1. Normative References 7.1. Normative References
[IANA.Language] [IANA.Language]
Internet Assigned Numbers Authority (IANA), "Language Internet Assigned Numbers Authority (IANA), "Language
Subtag Registry", 2005. Subtag Registry", <http://www.iana.org/assignments/
language-subtag-registry>.
[JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- [JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
key (work in progress), January 2015. key (work in progress), January 2015.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature (work Signature (JWS)", draft-ietf-jose-json-web-signature (work
in progress), January 2015. in progress), January 2015.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in (JWT)", draft-ietf-oauth-json-web-token (work in
progress), January 2015. progress), January 2015.
[OAuth.JWT] [OAuth.JWT]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer (work Authorization Grants", draft-ietf-oauth-jwt-bearer (work
in progress), November 2015. in progress), November 2014.
[OAuth.SAML2] [OAuth.SAML2]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-saml2-bearer (work Authorization Grants", draft-ietf-oauth-saml2-bearer (work
in progress), November 2015. in progress), November 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.
[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 31, line 20 skipping to change at page 31, line 46
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.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
[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.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
7.2. Informative References 7.2. Informative References
[I-D.hardjono-oauth-umacore] [I-D.hardjono-oauth-umacore]
Hardjono, T., "User-Managed Access (UMA) Profile of OAuth Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
2.0", draft-hardjono-oauth-umacore-10 (work in progress), "User-Managed Access (UMA) Profile of OAuth 2.0", draft-
July 2014. hardjono-oauth-umacore-13 (work in progress), April 2015.
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-09 (work in progress), February 2015.
[OAuth.Registration.Management] [OAuth.Registration.Management]
Richer, J., Jones, M., Bradley, J., and M. Machulak, Richer, J., Jones, M., Bradley, J., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Management "OAuth 2.0 Dynamic Client Registration Management
Protocol", draft-ietf-oauth-dyn-reg-management (work in Protocol", draft-ietf-oauth-dyn-reg-management (work in
progress), February 2015. progress), May 2015.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
Connect Discovery 1.0", November 2014.
[OpenID.Registration] [OpenID.Registration]
Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Dynamic Client Registration 1.0", November 2014. Dynamic Client Registration 1.0", November 2014.
Appendix A. Use Cases Appendix A. Use Cases
This appendix describes different ways that this specification can be This appendix describes different ways that this specification can be
utilized, including describing some of the choices that may need to utilized, including describing some of the choices that may need to
be made. Some of the choices are independent and can be used in be made. Some of the choices are independent and can be used in
skipping to change at page 34, line 30 skipping to change at page 35, line 21
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 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 ]]
-29
o Descrbed more possible client responses to the metadata fields
returned by the server being different than those requested.
o Added RFC 7120/BCP 100 references.
o Added RFC 7525/BCP 195 reference to replace draft reference.
-28 -28
o Clarified all client metadata as JSON arrays, strings, or numbers. o Clarified all client metadata as JSON arrays, strings, or numbers.
o Expanded security considerations advice around external URLs. o Expanded security considerations advice around external URLs.
o Added text to say what happens if the client doesn't get back the o Added text to say what happens if the client doesn't get back the
registration it expected in the response. registration it expected in the response.
o Added more explicit references to HTTP 201 response from o Added more explicit references to HTTP 201 response from
registration. registration.
o Clarified client version definition. o Clarified client version definition.
o Removed spurious reference to "delete action". o Removed spurious reference to "delete action".
 End of changes. 24 change blocks. 
39 lines changed or deleted 62 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/