draft-ietf-oauth-dyn-reg-24.txt   draft-ietf-oauth-dyn-reg-25.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: August 24, 2015 Microsoft Expires: September 24, 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
February 20, 2015 March 23, 2015
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-24 draft-ietf-oauth-dyn-reg-25
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 August 24, 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
skipping to change at page 3, line 24 skipping to change at page 3, line 24
Software . . . . . . . . . . . . . . . . . . . . . . 33 Software . . . . . . . . . . . . . . . . . . . . . . 33
A.5. Stateful or Stateless Registration . . . . . . . . . . . 33 A.5. Stateful or Stateless Registration . . . . . . . . . . . 33
A.5.1. Stateful Client Registration . . . . . . . . . . . . 33 A.5.1. Stateful Client Registration . . . . . . . . . . . . 33
A.5.2. Stateless Client Registration . . . . . . . . . . . . 33 A.5.2. Stateless Client Registration . . . . . . . . . . . . 33
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33
Appendix C. Document History . . . . . . . . . . . . . . . . . . 34 Appendix C. Document History . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 [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.
As part of the registration process, this specification also defines As part of the registration process, this specification also defines
a mechanism for the client to present the authorization server with a a mechanism for the client to present the authorization server with a
set of metadata, such as a set of valid redirection URIs. This set of metadata, such as a set of valid redirection URIs. This
metadata can either be communicated in a self-asserted fashion or as metadata can either be communicated in a self-asserted fashion or as
skipping to change at page 6, line 36 skipping to change at page 6, line 36
method by which the initial access token is issued to the client method by which the initial access token is issued to the client
or developer is out of scope for this specification. or developer is out of scope for this specification.
(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 the client's desired registration metadata, optionally with the client's desired registration metadata, optionally
including the initial access token from (A) if one is required by including the initial access token from (A) if one is required by
the authorization server. the 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, and possibly other values. * a client identifier that is unique at the server, and
* a set of client credentials such as a client secret, if
applicable for this client.
Examples of different configurations and usages are included in Examples of different configurations and usages are included in
Appendix A. Appendix A.
2. Client Metadata 2. Client Metadata
Registered clients have a set of metadata values associated with Registered clients have a set of metadata values associated with
their client identifier at an authorization server, such as the list their client identifier at an authorization server, such as the list
of valid redirection URIs or a display name. of valid redirection URIs or a display name.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
authorization server. authorization server.
software_version software_version
A version identifier for the client software identified by A version identifier for the client software identified by
"software_id". The value of the "software_version" SHOULD change "software_id". The value of the "software_version" SHOULD change
on any update to the client software identified by the same on any update to the client software identified by the same
"software_id". The value of this field is a string that is "software_id". The value of this field is a string that is
intended to be compared using string equality matching. The value intended to be compared using string equality matching. The value
of this field is not intended to be human readable and is usually of this field is not intended to be human readable and is usually
opaque to the client and authorization server. opaque to the client and authorization server.
Extensions and profiles of this specification MAY expand this list. Extensions and profiles of this specification MAY expand this list
The authorization server MUST ignore any client metadata values sent with metadata names and descriptions registered in accordance with
by the client that it does not understand. the IANA Considerations in Section 4 of this document. The
authorization server MUST ignore any client metadata sent by the
client that it does not understand (for instance, by silently
removing unknown metadata from the client's registration record
during processing).
Client metadata values can either be communicated directly in the Client metadata values can either be communicated directly in the
body of a registration request, as described in Section 3.1, or body of a registration request, as described in Section 3.1, or
included as claims in a software statement, as described in included as claims in a software statement, as described in
Section 2.3, or a mixture of both. If the same client metadata name Section 2.3, or a mixture of both. If the same client metadata name
is present in both locations and the software statement is trusted by is present in both locations and the software statement is trusted by
the authorization server, the value of a claim in the software the authorization server, the value of a claim in the software
statement MUST take precedence. statement MUST take precedence.
2.1. Relationship between Grant Types and Response Types 2.1. Relationship between Grant Types and Response Types
skipping to change at page 13, line 22 skipping to change at page 13, line 29
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ. aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0 zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY 5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
The means by which a client or developer obtains a software statement The means by which a client or developer obtains a software statement
are outside the scope of this specification. Some common methods are outside the scope of this specification. Some common methods
could include a client developer generating a client-specific JWT could include a client developer generating a client-specific JWT by
registering with a software API publisher to obtain a software registering with a software API publisher to obtain a software
statement for a class of clients. The software statement is statement for a class of clients. The software statement is
typically distributed with all instances of a client application. typically distributed with all instances of a client application.
The criteria by which authorization servers determine whether to The criteria by which authorization servers determine whether to
trust and utilize the information in a software statement are beyond trust and utilize the information in a software statement are beyond
the scope of this specification. the scope of this specification.
In some cases, authorization servers MAY choose to accept a software In some cases, authorization servers MAY choose to accept a software
statement value directly as a client identifier in an authorization statement value directly as a client identifier in an authorization
skipping to change at page 21, line 12 skipping to change at page 21, line 12
'implicit' instead." 'implicit' instead."
} }
4. IANA Considerations 4. IANA Considerations
4.1. OAuth Dynamic Registration Client Metadata Registry 4.1. OAuth Dynamic Registration Client Metadata Registry
This specification establishes the OAuth Dynamic Registration Client This specification establishes the OAuth Dynamic Registration Client
Metadata registry. Metadata registry.
OAuth registration client metadata values are registered with a OAuth registration client metadata names and descriptions are
Specification Required ([RFC5226]) after a two-week review period on registered with a Specification Required ([RFC5226]) after a two-week
the oauth-ext-review@ietf.org mailing list, on the advice of one or review period on the oauth-ext-review@ietf.org mailing list, on the
more Designated Experts. However, to allow for the allocation of advice of one or more Designated Experts. However, to allow for the
values prior to publication, the Designated Expert(s) may approve allocation of names prior to publication, the Designated Expert(s)
registration once they are satisfied that such a specification will may approve registration once they are satisfied that such a
be published. specification will be published.
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 OAuth Dynamic Registration Client (e.g., "Request to register OAuth Dynamic Registration Client
Metadata name: example"). 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
skipping to change at page 23, line 10 skipping to change at page 23, line 10
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "logo_uri" o Client Metadata Name: "logo_uri"
o Client Metadata Description: URL that references a logo for the o Client Metadata Description: URL that references a logo for the
client client
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "scope" o Client Metadata Name: "scope"
o Client Metadata Description: Space separated list of scope values o Client Metadata Description: Space separated list of OAuth 2.0
scope values
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
o Client Metadata Name: "contacts" o Client Metadata Name: "contacts"
o Client Metadata Description: Array of strings representing ways to o Client Metadata Description: Array of strings representing ways to
contact people responsible for this client, typically email contact people responsible for this client, typically email
addresses addresses
o Change Controller: IESG o Change Controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
skipping to change at page 24, line 36 skipping to change at page 24, line 37
o Client Metadata Description: Time at which the client secret will o Client Metadata Description: Time at which the client secret will
expire expire
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): [[ this document ]] o Specification Document(s): [[ this document ]]
4.2. OAuth Token Endpoint Authentication Methods Registry 4.2. OAuth Token Endpoint Authentication Methods Registry
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" metadata Additional values for use as "token_endpoint_auth_method" values are
values are registered with a Specification Required ([RFC5226]) after registered with a Specification Required ([RFC5226]) after a two-week
a two-week review period on the oauth-ext-review@ietf.org mailing review period on the oauth-ext-review@ietf.org mailing list, on the
list, on the advice of one or more Designated Experts. However, to advice of one or more Designated Experts. However, to allow for the
allow for the allocation of values prior to publication, the allocation of values prior to publication, the Designated Expert(s)
Designated Expert(s) may approve registration once they are satisfied may approve registration once they are satisfied that such a
that such a specification will be published. specification will be published.
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 35 skipping to change at page 26, line 36
o A non-HTTP application-specific URL that is available only to the o A non-HTTP application-specific URL that is available only to the
client application (e.g., exampleapp://oauth_redirect) client application (e.g., exampleapp://oauth_redirect)
Public clients MAY register with an authorization server using this Public clients MAY register with an authorization server using this
protocol, if the authorization server's policy allows them. Public protocol, if the authorization server's policy allows them. Public
clients use a "none" value for the "token_endpoint_auth_method" clients use a "none" value for the "token_endpoint_auth_method"
metadata field and are generally used with the "implicit" grant type. metadata field and are generally used with the "implicit" grant type.
Often these clients will be short-lived in-browser applications Often these clients will be short-lived in-browser applications
requesting access to a user's resources and access is tied to a requesting access to a user's resources and access is tied to a
user's active session at the authorization server. Since such user's active session at the authorization server. Since such
clients often do not have long-term storage, it's possible that such clients often do not have long-term storage, it is possible that such
clients would need to re-register every time the browser application clients would need to re-register every time the browser application
is loaded. Additionally, such clients may not have ample opportunity is loaded. Additionally, such clients may not have ample opportunity
to unregister themselves using the delete action before the browser to unregister themselves using the delete action before the browser
closes. To avoid the resulting proliferation of dead client closes. To avoid the resulting proliferation of dead client
identifiers, an authorization server MAY decide to expire identifiers, an authorization server MAY decide to expire
registrations for existing clients meeting certain criteria after a registrations for existing clients meeting certain criteria after a
period of time has elapsed. period of time has elapsed.
Since different OAuth 2.0 grant types have different security and Since different OAuth 2.0 grant types have different security and
usage parameters, an authorization server MAY require separate usage parameters, an authorization server MAY require separate
skipping to change at page 34, line 12 skipping to change at page 34, line 12
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 ]]
-25
o Updated author information.
o Clarified registry contents.
o Added forward pointer to IANA from metadata section.
o Clarified how to silently ignore errors.
o Reformatted diagram text.
-24 -24
o Clarified some party definitions. o Clarified some party definitions.
o Clarified the opaqueness of software_id and software_statement. o Clarified the opaqueness of software_id and software_statement.
o Created a forward pointer to the Security Considerations section o Created a forward pointer to the Security Considerations section
for TLS requirements on the registration endpoint. for TLS requirements on the registration endpoint.
o Added a forward pointer to the Privacy Considerations section for o Added a forward pointer to the Privacy Considerations section for
the contacts field. the contacts field.
o Wrote privacy considerations about client_id tracking. o Wrote privacy considerations about client_id tracking.
skipping to change at page 40, line 12 skipping to change at page 40, line 12
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/
Phil Hunt Phil Hunt
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
 End of changes. 14 change blocks. 
31 lines changed or deleted 45 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/