draft-ietf-oauth-dyn-reg-05.txt   draft-ietf-oauth-dyn-reg-06.txt 
Network 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: August 10, 2013 Ping Identity Expires: August 19, 2013 Ping Identity
M. Jones M. Jones
Microsoft Microsoft
M. Machulak M. Machulak
Newcastle University Newcastle University
February 6, 2013 February 15, 2013
OAuth Dynamic Client Registration Protocol OAuth Dynamic Client Registration Protocol
draft-ietf-oauth-dyn-reg-05 draft-ietf-oauth-dyn-reg-06
Abstract Abstract
This specification defines an endpoint and protocol for dynamic This specification defines an endpoint and protocol for dynamic
registration of OAuth Clients at an Authorization Server. registration of OAuth Clients at an Authorization Server.
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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 10, 2013. This Internet-Draft will expire on August 19, 2013.
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 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 4 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 4
3. Client Registration Endpoint . . . . . . . . . . . . . . . . . 7 3. Client Registration Endpoint . . . . . . . . . . . . . . . . . 7
3.1. Client Registration Request . . . . . . . . . . . . . . . 8 3.1. Client Registration Request . . . . . . . . . . . . . . . 8
3.2. Client Registration Response . . . . . . . . . . . . . . . 8 3.2. Client Registration Response . . . . . . . . . . . . . . . 9
3.3. Client Registration Error Response . . . . . . . . . . . . 10 4. Client Registration Access Endpoint . . . . . . . . . . . . . 9
4. Client Update Endpoint . . . . . . . . . . . . . . . . . . . . 11 4.1. Forming the Client Registration Access Endpoint URL . . . 9
4.1. Client Update Request . . . . . . . . . . . . . . . . . . 12 4.2. Client Read Request . . . . . . . . . . . . . . . . . . . 10
4.2. Client Read Request . . . . . . . . . . . . . . . . . . . 12 4.3. Client Update Request . . . . . . . . . . . . . . . . . . 10
4.3. Client Update or Read Response . . . . . . . . . . . . . . 13 4.4. Client Delete Request . . . . . . . . . . . . . . . . . . 12
4.4. Client Delete Request . . . . . . . . . . . . . . . . . . 14 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Client Secret Rotation . . . . . . . . . . . . . . . . . . . . 15 5.1. Client Information Response . . . . . . . . . . . . . . . 13
5.1. Rotate Secret Request . . . . . . . . . . . . . . . . . . 15 5.2. Client Registration Error Response . . . . . . . . . . . . 15
5.2. Rotate Secret Response . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . . 17
9. Document History . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
10. Normative References . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Document History . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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 clients to obtain authorization from an OAuth authorization OAuth clients to obtain authorization from an OAuth authorization
server without requiring the two parties to interact before hand. server without requiring the two parties to interact before hand.
Nevertheless, in order for the authorization server to accurately and Nevertheless, in order for the authorization server to accurately and
securely represent to end-users which client is seeking authorization securely represent to end-users which client is seeking authorization
to access the end-user's resources, a method for automatic and unique to access the end-user's resources, a method for automatic and unique
skipping to change at page 3, line 25 skipping to change at page 3, line 25
the Authorization Server is initialized, or how a given client is the Authorization Server is initialized, or how a given client is
assigned a unique Client Identifier. Historically, this has happened assigned a unique Client Identifier. Historically, this has happened
out-of-band from the OAuth protocol. This draft provides a mechanism out-of-band from the OAuth protocol. This draft provides a mechanism
for a client to register itself with the Authorization Server, which for a client to register itself with the Authorization Server, which
can be used to dynamically provision a Client Identifier, and can be used to dynamically provision a Client Identifier, and
optionally a Client Secret. optionally a Client Secret.
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 display name and icon to be presented to set of metadata, such as a display name and icon to be presented to
the user during the authorization step. This draft provides a method the user during the authorization step. This draft also provides a
for the client to register and update this information over time. mechanism for the Client to read and update this information after
the initial registration action.
1.1. Notational Conventions 1.1. Notational Conventions
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
skipping to change at page 3, line 48 skipping to change at page 3, line 49
This specification uses the terms "Access Token", "Refresh Token", This specification uses the terms "Access Token", "Refresh Token",
"Authorization Code", "Authorization Grant", "Authorization Server", "Authorization Code", "Authorization Grant", "Authorization Server",
"Authorization Endpoint", "Client", "Client Identifier", "Client "Authorization Endpoint", "Client", "Client Identifier", "Client
Secret", "Protected Resource", "Resource Owner", "Resource Server", Secret", "Protected Resource", "Resource Owner", "Resource Server",
and "Token Endpoint" defined by OAuth 2.0 [RFC6749]. and "Token Endpoint" defined by OAuth 2.0 [RFC6749].
This specification defines the following additional terms: This specification defines the following additional terms:
o Client Registration Endpoint: The OAuth 2.0 Endpoint through which o Client Registration Endpoint: The OAuth 2.0 Endpoint through which
a Client can request new registration. a Client can request new registration. The means of the Client
obtaining the URL for this endpoint are out of scope for this
o Client Update Endpoint: The OAuth 2.0 Endpoint through which a specification.
specific Client can manage its registration information, provided
by the Authorization Server to the Client.
o Client Secret Rotation Endpoint: The OAuth 2.0 Endpoint through o Client Registration Access Endpoint: The OAuth 2.0 Endpoint
which a specific Client can request refreshes of its Client Secret through which a specific Client can manage its registration
and Registration Access Token. information, provided by the Authorization Server to the Client.
This URL for this endpoint is communicated to the client by the
Authorization Server in the Client Information Response.
o Registration Access Token: An OAuth 2.0 Bearer Token issued by the o Registration Access Token: An OAuth 2.0 Bearer Token issued by the
Authorization Server through the Client Registration Endpoint Authorization Server through the Client Registration Endpoint
which is used by the Client to authenticate itself during update which is used by the Client to authenticate itself during read,
and secret rotation operations. This token is associated with a update, and delete operations. This token is associated with a
particular Client. particular Client.
2. Client Metadata 2. Client Metadata
Clients generally have an array of metadata associated with their Clients generally have an array of metadata associated with their
unique Client Identifier at the Authorization Server. These can unique Client Identifier at the Authorization Server. These can
range from human-facing display strings, such as a client name, to range from human-facing display strings, such as a client name, to
items that impact the security of the protocol, such as the list of items that impact the security of the protocol, such as the list of
valid redirect URIs. valid redirect URIs.
skipping to change at page 4, line 38 skipping to change at page 4, line 40
[[ Editor's note: normative language in the table below is meant to [[ Editor's note: normative language in the table below is meant to
apply to the *client* when sending the request. The paragraph above apply to the *client* when sending the request. The paragraph above
is meant to say that the server must at least accept all parameters is meant to say that the server must at least accept all parameters
and not fail with an error at an unknown parameter, especially if and not fail with an error at an unknown parameter, especially if
it's in the list below. Also, extensions need to explicitly call out it's in the list below. Also, extensions need to explicitly call out
if they're not going to do something with one of these basic if they're not going to do something with one of these basic
parameters instead of just ignoring their existence. This is meant parameters instead of just ignoring their existence. This is meant
to be the *minimum set* of parameters for interoperability. ]] to be the *minimum set* of parameters for interoperability. ]]
redirect_uris redirect_uris
RECOMMENDED. A list of redirect URIs for use in the Authorization RECOMMENDED. Array of redirect URIs for use in the Authorization
Code and Implicit grant types. An Authorization Server SHOULD Code and Implicit grant types. An Authorization Server SHOULD
require registration of valid redirect URIs for all clients that require registration of valid redirect URIs for all clients that
use these grant types in order to protect against token and use these grant types in order to protect against token and
credential theft attacks. credential theft attacks.
client_name client_name
RECOMMENDED. Human-readable name of the Client to be presented to RECOMMENDED. Human-readable name of the Client to be presented to
the user. If omitted, the Authorization Server MAY display to the the user. If omitted, the Authorization Server MAY display to the
user the raw "client_id" value instead. user the raw "client_id" value instead.
skipping to change at page 5, line 16 skipping to change at page 5, line 16
RECOMMENDED. URL of the homepage of the Client. If present, the RECOMMENDED. URL of the homepage of the Client. If present, the
server SHOULD display this URL to the end user in a clickable server SHOULD display this URL to the end user in a clickable
fashion. fashion.
logo_url logo_url
OPTIONAL. URL that references a logo for the Client. If present, OPTIONAL. URL that references a logo for the Client. If present,
the server SHOULD display this image to the end user during the server SHOULD display this image to the end user during
approval. approval.
contacts contacts
OPTIONAL. List of email addresses for people responsible for this OPTIONAL. Array of email addresses for people responsible for
Client. The Authorization Server MAY make these addresses this Client. The Authorization Server MAY make these addresses
available to end users for support requests for the Client. An available to end users for support requests for the Client. An
Authorization Server MAY use these email addresses as identifiers Authorization Server MAY use these email addresses as identifiers
for an administrative page for this client. for an administrative page for this client.
tos_url tos_url
OPTIONAL. URL that points to a human-readable Terms of Service OPTIONAL. URL that points to a human-readable Terms of Service
for the Client. The Authorization Server SHOULD display this URL for the Client. The Authorization Server SHOULD display this URL
to the End-User if it is given. to the End-User if it is given.
token_endpoint_auth_method token_endpoint_auth_method
skipping to change at page 6, line 6 skipping to change at page 6, line 6
* "private_key_jwt": the client uses the JWT Assertion profile * "private_key_jwt": the client uses the JWT Assertion profile
with its own private key with its own private key
Other authentication methods may be defined by extension. If Other authentication methods may be defined by extension. If
unspecified or omitted, the default is "client_secret_basic", unspecified or omitted, the default is "client_secret_basic",
denoting HTTP Basic Authentication Scheme as specified in Section denoting HTTP Basic Authentication Scheme as specified in Section
2.3.1 of OAuth 2.0. 2.3.1 of OAuth 2.0.
scope scope
OPTIONAL. Space separated list of scopes (as described in OAuth OPTIONAL. Space separated list of scope values (as described in
2.0 Section 3.3 [RFC6749]) that the client will be allowed to OAuth 2.0 Section 3.3 [RFC6749]) that the client is declaring that
request tokens for. If omitted, an Authorization Server MAY it may use when requesting access tokens. If omitted, an
register a Client with a default set of allowed scopes. Authorization Server MAY register a Client with a default set of
scopes.
grant_type grant_type
OPTIONAL. List of grant types that a client may use. These grant OPTIONAL. Array of grant types that a client may use. These
types are defined as follows: grant types are defined as follows:
* "authorization_code": The Authorization Code Grant described in * "authorization_code": The Authorization Code Grant described in
OAuth2 Section 4.1. OAuth2 Section 4.1.
* "implicit": The Implicit Grant described in OAuth2 Section 4.2. * "implicit": The Implicit Grant described in OAuth2 Section 4.2.
* "password": The Resource Owner Password Credentials Grant * "password": The Resource Owner Password Credentials Grant
described in OAuth2 Section 4.3 described in OAuth2 Section 4.3
* "client_credentials": The Client Credentials Grant described in * "client_credentials": The Client Credentials Grant described in
skipping to change at page 7, line 49 skipping to change at page 7, line 50
In order to support open registration and facilitate wider In order to support open registration and facilitate wider
interoperability, the Client Registration Endpoint SHOULD allow interoperability, the Client Registration Endpoint SHOULD allow
initial registration requests with no authentication. These requests initial registration requests with no authentication. These requests
MAY be rate-limited or otherwise limited to prevent a denial-of- MAY be rate-limited or otherwise limited to prevent a denial-of-
service attack on the Client Registration Endpoint. service attack on the Client Registration Endpoint.
In order to facilitate registered clients updating their information, In order to facilitate registered clients updating their information,
the Client Registration Endpoint issues a Request Access Token for the Client Registration Endpoint issues a Request Access Token for
clients to securely identify themselves in future connections to the clients to securely identify themselves in future connections to the
Client Update Endpoint. As such, the Client Update Endpoint MUST Client Registration Access Endpoint (Section 4). As such, the Client
accept requests with OAuth 2.0 Bearer Tokens [RFC6750] for these Registration Access Endpoint MUST accept requests with OAuth 2.0
operations, whether or not the initial registration call requires Bearer Tokens [RFC6750] for these operations, whether or not the
authentication of some form. initial registration call requires authentication of some form.
The Client Registration Endpoint MUST ignore all parameters it does The Client Registration Endpoint MUST ignore all parameters it does
not understand. not understand.
3.1. Client Registration Request 3.1. Client Registration Request
This operation registers a new Client to the Authorization Server. This operation registers a new Client to the Authorization Server.
The Authorization Server assigns this client a unique Client The Authorization Server assigns this client a unique Client
Identifier, optionally assigns a Client Secret, and associates the Identifier, optionally assigns a Client Secret, and associates the
metadata given in the request with the issued Client Identifier. The metadata given in the request with the issued Client Identifier. The
request includes any parameters described in Client Metadata request includes any parameters described in Client Metadata
(Section 2) that the client wishes to specify for itself during the (Section 2) that the client wishes to specify for itself during the
registration. The Authorization Server MAY provision default values registration. The Authorization Server MAY provision default values
for any items omitted in the Client Metadata. for any items omitted in the Client Metadata.
The Client sends an HTTP POST to the Client Registration Endpoint The Client sends an HTTP POST to the Client Registration Endpoint
with a content type of "application/json" and all parameters as top- with a content type of "application/json". The HTTP Entity Payload
level members of a JSON object. is a JSON [RFC4627] document consisting of a JSON object and all
parameters as top- level members of that JSON object.
For example, a client could send the following registration request For example, a client could send the following registration request
to the Client Registration Endpoint: to the Client Registration Endpoint:
Following is a non-normative example request (with line wraps for Following is a non-normative example request (with line wraps for
display purposes only): display purposes only):
POST /register HTTP/1.1 POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json Accept: application/json
Host: server.example.com Host: server.example.com
{ {
"redirect_uris":["https://client.example.org/callback", "redirect_uris":["https://client.example.org/callback",
"https://client.example.org/callback2"] "https://client.example.org/callback2"]
"client_name":"My Example Client", "client_name":"My Example Client",
"token_endpoint_auth_method":"client_secret_basic", "token_endpoint_auth_method":"client_secret_basic",
"scope":"read write dolphin", "scope":"read write dolphin",
"logo_url":"https://client.example.org/logo.png", "logo_url":"https://client.example.org/logo.png",
"jwk_url":"https://client.example.org/my_rsa_public_key.jwk" "jwk_url":"https://client.example.org/my_rsa_public_key.jwk"
} }
3.2. Client Registration Response 3.2. Client Registration Response
Upon successful registration, the Client Registration Endpoint Upon successful registration, the Authorization Server generates a
returns the newly-created Client Identifier and, if applicable, a new Client Identifier for the client. This Client Identifier MUST be
Client Secret. unique at the server and MUST NOT be in use by any other client. The
server responds with an HTTP 201 Created code and a body of type
Additionally, the Authorization Server SHOULD return all registered "application/json" with content described in Client Information
metadata (Section 2) about this client, including any fields Response (Section 5.1).
provisioned by the Authorization Server itself. The Authorization
Server MAY reject or replace any of the client's requested metadata
values submitted during the registration request and substitute them
with suitable values. If the Authorization Server performs any such
substitutions to the requested values, it MUST return these values in
the response.
The response contains a "_links" structure which contains fully
qualified URLs to the Client Update Endpoint and the Client Secret
Rotation Endpoint for this specific client. The response also
contains a Registration Access Token that is to be used by the client
to perform subsequent operations at the Client Update Endpoint and
the Client Secret Rotation Endpoint.
The response is an "application/json" document with the following
parameters in addition to any applicable client metadata fields as
top-level members of a JSON object [RFC4627] .
client_id
REQUIRED. The unique Client identifier, MUST NOT be currently
valid for any other registered Client.
client_secret
OPTIONAL. The Client secret. If issued, this MUST be unique for
each "client_id". This value is used by confidential clients to
authenticate to the Token Endpoint as described in OAuth 2.0
Section 2.3.1.
registration_access_token
REQUIRED. The Access token to be used by the client to perform
actions on the Client Update Endpoint and the Client Secret
Rotation Endpoint.
issued_at
OPTIONAL. Specifies the timestamp when the Client Identifier was
issued. The timestamp value MUST be a positive integer. The
value is expressed in the number of seconds since January 1, 1970
00:00:00 GMT.
expires_at
REQUIRED if "client_secret" is issued. The number of seconds from
1970-01-01T0:0:0Z as measured in UTC that the "client_secret" will
expire or "0" if it does not expire. See RFC 3339 [RFC3339] for
details regarding date/times in general and UTC in particular.
_links
REQUIRED. A JSON object that contains references to the Client
Update Endpoint and Client Secret Rotation Endpoint, via the
following members:
self REQUIRED. A JSON object that contains the member href which
contains the fully qualified URL of the Client Update Endpoint
for this client. This MAY be constructed using a URL Template
of the Client Registration Endpoint with the issued client_id.
rotate_secret REQUIRED. A JSON object that contains the member
href which contains the fully qualified URL of the Client
Secret Rotation Endpoint for this client. This MAY be
constructed using a URL Template of the Client Registration
Endpoint with the issued client_id.
Following is a non-normative example response: Upon an unsuccessful registration, the Authorization Server responds
HTTP/1.1 200 OK with an error as described in Client Registration Error
Content-Type: application/json (Section 5.2).
Cache-Control: no-store
{ 4. Client Registration Access Endpoint
_links: {
"self": {
"href":
"https://server.example.com/register/s6BhdRkqt3"
},
"rotate_secret": {
"href":
"https://server.example.com/register/rotate_secret/s6BhdRkqt3"
}
"redirect_uris":["https://client.example.org/callback",
"https://client.example.org/callback2"]
"client_id":"s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"scope": "read write dolphin",
"grant_type": ["authorization_code", "refresh_token"]
"token_endpoint_auth_method": "client_secret_basic",
"logo_url": "https://client.example.org/logo.png",
"jwk_url": "https://client.example.org/my_rsa_public_key.jwk",
"registration_access_token": "reg-23410913-abewfq.123483",
"expires_at":2893276800
}
3.3. Client Registration Error Response The Client Registration Access Endpoint is an OAuth 2.0 protected
endpoint that is provisioned by the server for a specific client to
be able to view and update its registered information. The Client
MUST include its Registration Access Token in all calls to this
endpoint as an OAuth 2.0 Bearer Token [RFC6750].
When an OAuth error condition occurs, the Client Registration Operations on this endpoint are switched through the use of different
Endpoint returns an Error Response as defined in Section 5.2 of the HTTP methods [RFC2616].
OAuth 2.0 specification.
When a registration error condition occurs, the Client Registration 4.1. Forming the Client Registration Access Endpoint URL
Endpoint returns a HTTP 400 status code including a JSON object
[RFC4627] describing the error in the response body.
The JSON object contains two members: The Authorization Server MUST provide the client with the fully
qualified URL in the "registration_access_url" element of the Client
Information Response (Section 5.1). The Authorization Server MUST
NOT expect the client to construct or discover this URL on its own.
The Client MUST use the URL as given by the server and MUST NOT
construct this URL from component pieces.
error Depending on deployment characteristics, the Client Registration
The error code, a single ASCII string. Access Endpoint URL may take any number of forms. It is RECOMMENDED
that this endpoint URL be formed through the use of a server-
constructed URL string which combines the Client Registration
Endpoint's URL and the issued client_id for this Client, with the
latter as either a path parameter
(https://server.example.com/register/client_id) or a query parameter
(https://server.example.com/register/?update=client_id). These
common patterns can help the Server to more easily determine the
client to which the request pertains, which MUST be matched against
the client to which the Registration Access Token was issued. If
desired, the server MAY simply return the Client Registration
Endpoint URL as the Client Registration Access Endpoint URL and
change behavior based on the authentication context provided by the
Registration Access Token.
error_description 4.2. Client Read Request
The additional text description of the error for debugging.
This specification defines the following error codes: In order to read the current configuration of the Client on the
Authorization Server, the Client makes an HTTP GET request to the
Client Registration Access Endpoint, authenticating with its
Registration Access Token.
invalid_redirect_uri Following is a non-normative example request (with line wraps for
The value of one or more "redirect_uris" is invalid. display purposes only):
GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
invalid_client_metadata Upon successful read of the information for a currently active
The value of one of the client metadata (Section 2) fields is Client, the Authorization Server responds with an HTTP 200 OK with
invalid and the server has rejected this request. Note that an content type of "application/json" and a payload as described in
Authorization server MAY choose to substitute a valid value for Client Information Response (Section 5.1).
any requested parameter of a client's metadata.
Following is a non-normative example of an error response (with line If the client does not exist on this server, the server MUST return
wraps for display purposes only): an HTTP 404 Not Found. [[ Editor's note: If the client doesn't exist,
HTTP/1.1 400 Bad Request then the Refresh Access Token shouldn't be valid, making this kind of
Content-Type: application/json error a 403 at the auth layer instead. How best to call this
Cache-Control: no-store inconsistency out? ]]
{ 4.3. Client Update Request
"error":"invalid_redirect_uri",
"error_description":"The redirect URI of http://sketchy.example.com
is not allowed for this server."
}
4. Client Update Endpoint This operation updates a previously-registered client with new
metadata at the Authorization Server. This request is authenticated
by the Registration Access Token issued to the client.
The Client Update Endpoint is an OAuth 2.0 protected endpoint that is The Client sends an HTTP PUT to the Client Registration Access
provisioned by the server for a specific client to be able to view Endpoint with a content type of "application/json". The HTTP Entity
and update its registered information. It is RECOMMENDED that this Payload is a JSON [RFC4627] document consisting of a JSON object and
endpoint URL be formed through the use of a URL template which all parameters as top- level members of that JSON object.
combines the Client Registration Endpoint and the issued client_id
for this client, either as a path parameter
(https://server.example.com/register/client_id) or as a query
parameter (https://server.example.com/register/?update=client_id).
The Authorization Server MUST provide the client with the fully
qualified URL in the _links structure described in section 3 and MUST
NOT require the client to construct this URL on its own.
The Authorization Server MUST be able to determine the appropriate This request MUST include all fields described in Client Metadata
client_id from the context of the request without requiring the (Section 2) as returned to the Client from a previous register, read,
Client to explicitly send its own "client_id" in the request. or update operation. The Client MUST NOT include the
"registration_access_token", "registration_access_url", "expires_at",
or "issued_at" fields described in Client Information Response
(Section 5.1).
Operations on this endpoint are switched through the use of specific Valid values of Client Metadata fields in this request MUST replace,
HTTP verbs. not augment, the values previously associated with this Client.
4.1. Client Update Request Omitted fields MUST be treated as null or empty values by the server.
This operation updates a previously-registered client with new The Client MUST include its client_id field in the request, and it
metadata at the Authorization Server. This request is authenticated MUST be the same as its currently-issued Client Identifier. If the
by the Registration Access Token issued to the client. client includes its client_secret in the request, then it MUST match
the currently-issued client_secret for that Client. The client MUST
NOT be allowed to overwrite its existing client_secret with its own
value.
The Client makes an HTTP PUT request to the Client Update Endpoint For all metadata fields, the Authorization Server MAY replace any
with a content type of "application/json". This request MAY include invalid values with suitable default values, and it MUST return any
any fields described in Client Metadata (Section 2). If included in such fields to the Client in the response.
the request, valid values of Client Metadata fields in this request
MUST replace, not augment, the values previously associated with this
Client. Any fields with the value of a JSON "null" in Client
Metadata MUST be taken as a request to clear any existing value of
that field. Omitted values in the Client Metadata MUST remain
unchanged by the Authorization Server. The Authorization Server MAY
replace any invalid values with suitable values, and it MUST return
any such fields to the Client in the response.
For example, a client could send the following request to the Client For example, a client could send the following request to the Client
Registration Endpoint to update the client registration in the above Registration Endpoint to update the client registration in the above
example: example:
Following is a non-normative example request (with line wraps for Following is a non-normative example request (with line wraps for
display purposes only): display purposes only):
PUT /register/s6BhdRkqt3 HTTP/1.1 PUT /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json Accept: application/json
Host: server.example.com Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483 Authorization: Bearer reg-23410913-abewfq.123483
{ {
"client_id":"s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"redirect_uri":["https://client.example.org/callback", "redirect_uri":["https://client.example.org/callback",
"https://client.example.org/alt"], "https://client.example.org/alt"],
"scope": "read write dolphin",
"grant_type": ["authorization_code", "refresh_token"]
"token_endpoint_auth_method": "client_secret_basic",
"jwk_url": "https://client.example.org/my_rsa_public_key.jwk"
"client_name":"My New Example", "client_name":"My New Example",
"logo_url":"https://client.example.org/newlogo.png" "logo_url":"https://client.example.org/newlogo.png"
} }
4.2. Client Read Request Upon successful update, the Authorization Server responds with an
HTTP 200 OK Message with content type "applicaiton/json" and a
In order to read the current configuration of the Client on the payload as described in Client Information Response (Section 5.1).
Authorization Server, the Client makes an HTTP GET request to the The Authorization Server MAY include a new Client Secret and/or
Client Update Endpoint with the Registration Access Token. Registration Access Token in its response. If so, the Client MUST
immediately discard its previous Client Secret and/or Registration
Following is a non-normative example request (with line wraps for Access Token.
display purposes only):
GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
4.3. Client Update or Read Response
Upon successful update or read operation, the Client Update Endpoint
returns the Client ID. Additionally, the Authorization Server SHOULD
return all registered metadata (Section 2) about this client,
including any fields provisioned by the Authorization Server itself.
The Authorization Server MAY reject or replace any of the client's
requested metadata values submitted during an update request and
substitute them with suitable values. If the Authorization Server
performs any such substitutions to the requested values, it MUST
return these values in the response.
The Authorization Server MUST NOT include the Client Secret or
Request Access Token in this response.
The response is a JSON Document [RFC4627] with the following fields
as well as any applicable client metadata as top-level members of a
JSON object.
client_id
REQUIRED. The unique Client identifier, MUST equal the value of
the client_id returned in the original client_register request.
_links
REQUIRED. A JSON object that contains references to the Client
Update Endpoint and Client Secret Rotation Endpoint, via the
following members:
self REQUIRED. A JSON object that contains the member href which
contains the fully qualified URL of the Client Update Endpoint
for this client. This MAY be constructed using a URL Template
of the Client Registration Endpoint with the issued client_id.
rotate_secret REQUIRED. A JSON object that contains the member If the Client does not exist on this server, the server MUST return
href which contains the fully qualified URL of the Client an HTTP 404 Not Found. [[ Editor's note: If the client doesn't exist,
Secret Rotation Endpoint for this client. This MAY be then the Refresh Access Token shouldn't be valid, making this kind of
constructed using a URL Template of the Client Registration error a 403 at the auth layer instead. How best to call this
Endpoint with the issued client_id. inconsistency out? ]]
Following is a non-normative example response: If the Client is not allowed to update its records, the server MUST
HTTP/1.1 200 OK respond with HTTP 403 Forbidden.
Content-Type: application/json
Cache-Control: no-store
{ If the Client attempts to set an invalid metadata field and the
_links: { Authorization Server does not set a default value, the Authorization
"self": { Server responds with an error as described in Client Registration
"href": "https://server.example.com/register/s6BhdRkqt3" Error Response (Section 5.2).
},
"rotate_secret": {
"href": "https://server.example.com/register/s6BhdRkqt3/secret"
}
"client_id": "s6BhdRkqt3",
"client_name": "My New Example",
"redirect_uri": ["https://client.example.org/callback",
"https://client.example.org/alt"]
"scope": "read write dolphin",
"grant_type": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"logo_url": "https://client.example.org/newlogo.png",
"jwk_url": "https://client.example.org/my_rsa_public_key.jwk",
}
4.4. Client Delete Request 4.4. Client Delete Request
[[ Editor's note: The utility and nature of this function are still
under active discussion. This is a proposed set of functionality
that a server MAY choose to implement, else give a 405 response to
any client that tries, if it can't support it. ]]
In order to deprovision itself on the Authorization Server, the In order to deprovision itself on the Authorization Server, the
Client makes an HTTP DELETE request to the Client Update Endpoint Client makes an HTTP DELETE request to the Client Registration Access
with the Registration Access Token. This request is authenticated by Endpoint. This request is authenticated by the Registration Access
the Registration Access Token issued to the client. Token issued to the client.
Following is a non-normative example request (with line wraps for Following is a non-normative example request (with line wraps for
display purposes only): display purposes only):
DELETE /register/s6BhdRkqt3 HTTP/1.1 DELETE /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json Accept: application/json
Host: server.example.com Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483 Authorization: Bearer reg-23410913-abewfq.123483
If a client has been successfully deprovisioned, the Authorization A successful delete action will invalidate the client_id,
client_secret, and registration_access_token for this client, thereby
preventing the client_id from being used at either the Authorization
Endpoint or Token Endpoint of the Authorization Server. The
Authorization Server SHOULD immediately invalidate all existing
authorization grants and currently-active tokens associated with this
Client.
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.
Following is a non-normative example response: If there is no such client, the server responds with an HTTP 404 Not
HTTP/1.1 204 No Content Found. [[ Editor's note: This is an inconsistent state and shouldn't
Cache-Control: no-store happen. See discussion about the Registration Access Token validity
above. ]]
5. Client Secret Rotation If the client is not allowed to delete itself, the server responds
with HTTP 403 Forbidden.
The Client Secret Rotation Endpoint is an OAuth 2.0 protected If the server does not support the delete method, it responds with an
endpoint that is provisioned by the server for a specific client to HTTP 405 Not Supported.
be able to request rotation of its Registration Access Token and, if
it has one, Client Secret. It is RECOMMENDED that this endpoint URL
be formed through the use of a URL template which combines the Client
Registration Endpoint and the issued client_id for this client,
either as a path parameter
(https://server.example.com/register/rotate_secret/client_id) or as a
query parameter
(https://server.example.com/register/?rotate_secret=client_id). The
Authorization Server MUST provide the client with the fully qualified
URL in the _links structure described in section 3, and MUST NOT
require the Client to construct this URL on its own.
The Authorization Server MUST be able to determine the appropriate Following is a non-normative example response:
client_id from the context of the request without requiring the HTTP/1.1 204 No Content
Client to explicitly send its own "client_id" in the request. Cache-Control: no-store
5.1. Rotate Secret Request 5. Responses
This operation allows the client to rotate its current Registration In response to certain requests from the Client to either the Client
Access Token as well as its Client Secret, if it has one. The client Registration Endpoint or the Client Registration Access Endpoint as
sends an HTTP POST with its current Registration Access Token. This described in this specification, the Authorization Server sends the
request is authenticated by the Registration Access Token issued to following response bodies.
the client.
Following is a non-normative example request (with line wraps for 5.1. Client Information Response
display purposes only):
POST /register/rotate_secret/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
5.2. Rotate Secret Response The response contains the following fields:
Upon successful rotation of the Registration Access Token, and , as well as a Client Secret if this client is a confidential client.
optionally the Client Secret, the Client Registration Endpoint The response also contains the fully qualified URL to the Client
returns a JSON document [RFC4627] with the following fields as top- Registration Access Endpoint for this specific client that the client
level members of the root JSON object. This response MUST NOT may use to obtain and update information about itself. The response
include any other client metadata. also contains a Registration Access Token that is to be used by the
client to perform subsequent operations at the Client Registration
Access Endpoint.
client_id client_id
REQUIRED. The unique Client identifier, MUST match the client_id REQUIRED. The unique Client identifier, MUST NOT be currently
issued in the original registration request. valid for any other registered Client.
client_secret client_secret
REQUIRED if the server initially issued this Client a Client OPTIONAL. The Client secret. If issued, this MUST be unique for
Secret, otherwise the server MUST NOT return a value. The value each "client_id". This value is used by confidential clients to
MUST be unique for each "client_id". authenticate to the Token Endpoint as described in OAuth 2.0
Section 2.3.1.
expires_at
REQUIRED if "client_secret" is issued. The number of seconds from
1970-01-01T0:0:0Z as measured in UTC that the "client_secret" will
expire or "0" if it does not expire. See RFC 3339 [RFC3339] for
details regarding date/times in general and UTC in particular.
issued_at
OPTIONAL. Specifies the timestamp when the Client Identifier was
issued. The timestamp value MUST be a positive integer. The
value is expressed in the number of seconds since January 1, 1970
00:00:00 GMT.
registration_access_token registration_access_token
REQUIRED. The Access token to be used by the client to perform REQUIRED. The Access token to be used by the client to perform
subsequent "client_update" and "rotate_secret" requests. actions on the Client Registration Access Endpoint.
issued_at registration_access_url
OPTIONAL. Specifies the timestamp when the identifier was issued. REQUIRED. The fully qualified URL of the Client Registration
The timestamp value MUST be a positive integer. The value is Access Endpoint for this client. The Client MUST use this URL as
expressed in the number of seconds since January 1, 1970 00:00:00 given when communicating with the Client Registration Access
GMT. Endpoint. [[ Editor's note: The syntax for this parameter is still
under active discussion. There have been several alternative
proposals to a flat URL here, including a structure based on HAL
for JSON and a structure based on JSON-LD. ]]
expires_at Additionally, the Authorization Server MUST return all registered
REQUIRED if the server issues a Client Secret. The number of metadata (Section 2) about this client, including any fields
seconds from 1970-01-01T0:0:0Z as measured in UTC that the provisioned by the Authorization Server itself. The Authorization
"client_secret" will expire or "0" if they do not expire. See RFC Server MAY reject or replace any of the client's requested metadata
3339 [RFC3339] for details regarding date/times in general and UTC values submitted during the registration or update requests and
in particular. substitute them with suitable values.
The response is an "application/json" document with all parameters as
top-level members of a JSON object [RFC4627] .
Following is a non-normative example response: Following is a non-normative example response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Cache-Control: no-store Cache-Control: no-store
{ {
"registration_access_token": "reg-23410913-abewfq.123483",
"registration_access_url":
"https://server.example.com/register/s6BhdRkqt3",
"client_id":"s6BhdRkqt3", "client_id":"s6BhdRkqt3",
"client_secret": "7fce6c93f31185e5885805d", "client_secret": "cf136dc3c1fc93f31185e5885805d",
"registration_access_token": "reg-02348913-oieqer.983421",
"expires_at":2893276800 "expires_at":2893276800
"redirect_uris":["https://client.example.org/callback",
"https://client.example.org/callback2"]
"scope": "read write dolphin",
"grant_type": ["authorization_code", "refresh_token"]
"token_endpoint_auth_method": "client_secret_basic",
"logo_url": "https://client.example.org/logo.png",
"jwk_url": "https://client.example.org/my_rsa_public_key.jwk"
} }
The Authorization Server SHOULD discard and invalidate the Request 5.2. Client Registration Error Response
Access Token and the Client Secret associated with this Client after
successful completion of this request. When an OAuth error condition occurs, such as the client presenting
an invalid Registration Access Token, the Authorization Server
returns an Error Response as defined in Section 5.2 of the OAuth 2.0
specification.
When a registration error condition occurs, the Authorization Server
returns an HTTP 400 status code with content type "application/json"
consisting of a JSON object [RFC4627] describing the error in the
response body.
The JSON object contains two members:
error
The error code, a single ASCII string.
error_description
A human-readable text description of the error for debugging.
This specification defines the following error codes:
invalid_redirect_uri
The value of one or more "redirect_uris" is invalid.
invalid_client_metadata
The value of one of the client metadata (Section 2) fields is
invalid and the server has rejected this request. Note that an
Authorization server MAY choose to substitute a valid value for
any requested parameter of a client's metadata.
invalid_client_id
Value of "client_id" is invalid.
Following is a non-normative example of an error response (with line
wraps for display purposes only):
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_redirect_uri",
"error_description":"The redirect URI of http://sketchy.example.com
is not allowed for this server."
}
6. IANA Considerations 6. IANA Considerations
This document makes no requests of IANA. This document makes no requests of IANA.
7. Security Considerations 7. Security Considerations
[[ Editor's note: Following are some security considerations taken [[ Editor's note: Following are some security considerations taken
from the UMA and OpenID Connect source drafts. These need to be from the UMA and OpenID Connect source drafts. These need to be
massaged into a properly generic set of considerations. ]] massaged into a properly generic set of considerations. ]]
skipping to change at page 17, line 48 skipping to change at page 17, line 32
registration request with a reference to a drive-by download in the registration request with a reference to a drive-by download in the
"policy_url". The Authorization Server should check to see if the "policy_url". The Authorization Server should check to see if the
"logo_url" and "policy_url" have the same host as the hosts defined "logo_url" and "policy_url" have the same host as the hosts defined
in the array of "redirect_uris". in the array of "redirect_uris".
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 Client could be left in a situation this token were to expire, a Client could be left in a situation
where it has no means of updating itself and must register itself where it has no means of updating itself and must register itself
anew. As the Registration Access Tokens are long-term credentials, anew. As the Registration Access Tokens are long-term credentials,
they MUST be protected by the Client as a secret. [[ Editor's note: and since the Registration Access Token is a Bearer token and acts as
with the right error codes returned from client_update, the AS could the sole authentication for use at the Client Registration Access
force the Client to call rotate_secret before going forward, Endpoint, it MUST be protected by the Client as described in OAuth
lessening the window for abuse of a leaked registration token. ]] 2.0 Bearer [RFC6750].
Since the Registration Access Token is a Bearer token and acts as the
sole authentication for use at the Client Update Endpoint, it MUST be
protected by the Client as described in OAuth 2.0 Bearer [RFC6750].
8. Acknowledgments If a Client is deprovisioned from a server, any outstanding
Registration Access Tokens for that client MUST be invalidated at the
same time. Otherwise, this can lead to an inconsistent state wherein
a Client could make requests to the Client Registration Access
Endpoint where the authentication would succeed but the action would
fail because the Client is no longer valid.
8. Normative References
[JWK] Jones, M., "JSON Web Key (JWK)", May 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
Appendix A. Acknowledgments
The authors thank the OAuth Working Group, the User-Managed Access The authors thank the OAuth Working Group, the User-Managed Access
Working Group, and the OpenID Connect Working Group participants for Working Group, and the OpenID Connect Working Group participants for
their input to this document. In particular, the following their input to this document. In particular, the following
individuals have been instrumental in their review and contribution individuals have been instrumental in their review and contribution
to various versions of this document: Torsten Lodderstedt, Eve Maler, to various versions of this document: Amanda Anganes, Tim Bray,
Thomas Hardjono, Christian Scholz, Nat Sakimura, George Fletcher, Domenico Catalano, George Fletcher, Torsten Lodderstedt, Eve Maler,
Amanda Anganes, and Domenico Catalano. Thomas Hardjono, Nat Sakimura, and Christian Scholz.
9. Document History Appendix B. Document History
[[ to be removed by RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
- 05 -06
o Removed secret_rotation as a client-initiated action, including
removing client secret rotation endpoint and parameters.
o Changed _links structure to single value registration_access_url.
o Collapsed create/update/read responses into client info response.
o Changed return code of create action to 201.
o Added section to describe suggested generation and composition of
Client Registration Access URL.
o Added clarifying text to PUT and POST requests to specify JSON in
the body.
o Added Editor's Note to DELETE operation about its inclusion.
o Added Editor's Note to registration_access_url about alternate
syntax proposals.
-05
o changed redirect_uri and contact to lists instead of space o changed redirect_uri and contact to lists instead of space
delimited strings delimited strings
o removed operation parameter o removed operation parameter
o added _links structure o added _links structure
o made client update management more RESTful o made client update management more RESTful
skipping to change at page 18, line 44 skipping to change at page 19, line 44
o changed input to JSON from form-encoded o changed input to JSON from form-encoded
o added READ and DELETE operations o added READ and DELETE operations
o removed Requirements section o removed Requirements section
o changed token_endpoint_auth_type back to o changed token_endpoint_auth_type back to
token_endpoint_auth_method to match OIDC who changed to match us token_endpoint_auth_method to match OIDC who changed to match us
- 04 -04
o removed default_acr, too undefined in the general OAuth2 case o removed default_acr, too undefined in the general OAuth2 case
o removed default_max_auth_age, since there's no mechanism for o removed default_max_auth_age, since there's no mechanism for
supplying a non-default max_auth_age in OAuth2 supplying a non-default max_auth_age in OAuth2
o clarified signing and encryption URLs o clarified signing and encryption URLs
o changed token_endpoint_auth_method to token_endpoint_auth_type to o changed token_endpoint_auth_method to token_endpoint_auth_type to
match OIDC match OIDC
- 03 -03
o added scope and grant_type claims o added scope and grant_type claims
o fixed various typos and changed wording for better clarity o fixed various typos and changed wording for better clarity
o endpoint now returns the full set of client information o endpoint now returns the full set of client information
o operations on client_update allow for three actions on metadata: o operations on client_update allow for three actions on metadata:
leave existing value, clear existing value, replace existing value leave existing value, clear existing value, replace existing value
with new value with new value
- 02 -02
o Reorganized contributors and references o Reorganized contributors and references
o Moved OAuth references to RFC o Moved OAuth references to RFC
o Reorganized model/protocol sections for clarity o Reorganized model/protocol sections for clarity
o Changed terminology to "client register" instead of "client o Changed terminology to "client register" instead of "client
associate" associate"
o Specified that client_id must match across all subsequent requests o Specified that client_id must match across all subsequent requests
o Fixed RFC2XML formatting, especially on lists o Fixed RFC2XML formatting, especially on lists
- 01 -01
o Merged UMA and OpenID Connect registrations into a single document o Merged UMA and OpenID Connect registrations into a single document
o Changed to form-paramter inputs to endpoint o Changed to form-paramter inputs to endpoint
o Removed pull-based registration o Removed pull-based registration
- 00 -00
o Imported original UMA draft specification o Imported original UMA draft specification
10. Normative References
[JWK] Jones, M., "JSON Web Key (JWK)", May 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
Authors' Addresses Authors' Addresses
Justin Richer (editor) Justin Richer (editor)
The MITRE Corporation The MITRE Corporation
Phone: Phone:
Fax: Fax:
Email: jricher@mitre.org Email: jricher@mitre.org
URI: URI:
 End of changes. 80 change blocks. 
387 lines changed or deleted 372 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/