draft-ietf-oauth-dyn-reg-14.txt   draft-ietf-oauth-dyn-reg-15.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Intended status: Standards Track J. Bradley Intended status: Standards Track M. Jones
Expires: January 30, 2014 Ping Identity Expires: August 1, 2014 Microsoft
M. Jones J. Bradley
Microsoft Ping Identity
M. Machulak M. Machulak
Newcastle University Newcastle University
July 29, 2013 January 28, 2014
OAuth 2.0 Dynamic Client Registration Protocol OAuth 2.0 Dynamic Client Registration Core Protocol
draft-ietf-oauth-dyn-reg-14 draft-ietf-oauth-dyn-reg-15
Abstract Abstract
This specification defines an endpoint and protocol for dynamic This specification defines mechanisms used to dynamically register
registration of OAuth 2.0 clients at an authorization server and OAuth 2.0 clients at authorization servers.
methods for the dynamically registered client to manage its
registration through an OAuth 2.0 protected web API.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 30, 2014. This Internet-Draft will expire on August 1, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Registration Tokens and Client Credentials . . . . . . . 6 2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Credential Rotation . . . . . . . . . . . . . . . . . 7 2.1. Relationship between Grant Types and Response Types . . . 9
2. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 7 3. Software Statement . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Relationship Between Grant Types and Response Types . . . 11 4. Client Registration Endpoint . . . . . . . . . . . . . . . . . 10
2.2. Human Readable Client Metadata . . . . . . . . . . . . . 11 4.1. Client Registration Request . . . . . . . . . . . . . . . 11
3. Client Registration Endpoint . . . . . . . . . . . . . . . . 13 4.2. Client Registration Response . . . . . . . . . . . . . . . 13
3.1. Client Registration Request . . . . . . . . . . . . . . . 13 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Client Registration Response . . . . . . . . . . . . . . 15 5.1. Client Information Response . . . . . . . . . . . . . . . 13
4. Client Configuration Endpoint . . . . . . . . . . . . . . . . 15 5.2. Client Registration Error Response . . . . . . . . . . . . 15
4.1. Forming the Client Configuration Endpoint URL . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
4.2. Client Read Request . . . . . . . . . . . . . . . . . . . 16 6.1. OAuth Registration Client Metadata Registry . . . . . . . 16
4.3. Client Update Request . . . . . . . . . . . . . . . . . . 17 6.1.1. Registration Template . . . . . . . . . . . . . . . . 17
4.4. Client Delete Request . . . . . . . . . . . . . . . . . . 19 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 17
5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. OAuth Token Endpoint Authentication Methods Registry . . . 18
5.1. Client Information Response . . . . . . . . . . . . . . . 20 6.2.1. Registration Template . . . . . . . . . . . . . . . . 18
5.2. Client Registration Error Response . . . . . . . . . . . 22 6.2.2. Initial Registry Contents . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. OAuth Token Endpoint Authentication Methods Registry . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1.1. Registration Template . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . . 22
8. Normative References . . . . . . . . . . . . . . . . . . . . 27 A.1. Open versus Protected Dynamic Client Registration . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 28 A.1.1. Open Dynamic Client Registration . . . . . . . . . . . 22
Appendix B. Client Lifecycle Examples . . . . . . . . . . . . . 28 A.1.2. Protected Dynamic Client Registration . . . . . . . . 22
B.1. Open Registration . . . . . . . . . . . . . . . . . . . . 29 A.2. Registration without or with Software Statements . . . . . 22
B.2. Protected Registration . . . . . . . . . . . . . . . . . 30 A.2.1. Registration without a Software Statement . . . . . . 22
B.3. Developer Automation . . . . . . . . . . . . . . . . . . 31 A.2.2. Registration with a Software Statement . . . . . . . . 22
Appendix C. Document History . . . . . . . . . . . . . . . . . . 33 A.3. Registration by the Client or the Developer . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 A.3.1. Registration by the Client . . . . . . . . . . . . . . 23
A.3.2. Registration by the Developer . . . . . . . . . . . . 23
A.4. Client ID per Client Instance or per Client Software . . . 23
A.4.1. Client ID per Client Software Instance . . . . . . . . 23
A.4.2. Client ID Shared between all Instances of Client
Software . . . . . . . . . . . . . . . . . . . . . . . 23
A.5. Stateful or Stateless Registration . . . . . . . . . . . . 23
A.5.1. Stateful Client Registration . . . . . . . . . . . . . 24
A.5.2. Stateless Client Registration . . . . . . . . . . . . 24
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 24
Appendix C. Document History . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
In some use-case scenarios, it is desirable or necessary to allow In order for an OAuth 2.0 client to utilize an OAuth 2.0
OAuth 2.0 clients to obtain authorization from an OAuth 2.0 authorization server, the client needs specific information to
authorization server without requiring the two parties to interact interact with the server, including an OAuth 2.0 Client ID to use at
beforehand. Nevertheless, for the authorization server to accurately that server. This specification describes how an OAuth 2.0 client
and securely represent to end-users which client is seeking can be dynamically registered with an authorization server to obtain
authorization to access the end-user's resources, a method for this information.
automatic and unique registration of clients is needed. The OAuth
2.0 authorization framework does not define how the relationship
between the client and the authorization server is initialized, or
how a given client is assigned a unique client identifier.
Historically, this has happened out-of-band from the OAuth 2.0
protocol. This draft provides a mechanism for a client to register
itself with the authorization server, which can be used to
dynamically provision a client identifier, and optionally a client
secret. Additionally, the mechanisms in this draft may can be used
by a client developer to register the client with the authorization
server in a programmatic fashion.
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 set of valid redirection URIs. This
the user during the authorization step. This draft also provides a metadata can either be communicated in a self-asserted fashion or as
mechanism for the client to read and update this information after a set of signed metadata called a software statement; in the case of
the initial registration action. This draft protects these actions a software statement, the signer is vouching for the validity of the
through the use of an OAuth 2.0 bearer access token that is issued to data about the client.
the client during registration explicitly for this purpose.
The mechanisms defined in this specification can be used either for a
client to dynamically register itself with authorization servers or
for a client developer to programmatically register the client with
authorization servers.
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.
1.2. Terminology 1.2. Terminology
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]. "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749]
and uses the term "Claim" defined by JSON Web Token (JWT) [JWT].
This specification defines the following additional terms: This specification defines the following terms:
Client Developer The person or organization that builds a client
software package and prepares it for distribution. A client
developer obtains a software assertion from a software publisher,
or self-generates one for the purposes of facilitating client
registration.
Client Instance A deployed instance of a piece of client software.
Multiple instances of the same piece of client software MAY use
the same Client ID value at an authorization server, provided that
the Redirection URI values and potentially other values dictated
by authorization server policy are the same for all instances.
Client Software Software implementing an OAuth 2.0 client.
Client Registration Endpoint OAuth 2.0 endpoint through which a Client Registration Endpoint OAuth 2.0 endpoint through which a
client can be registered at an authorization server. The means by client can be registered at an authorization server. The means by
which the URL for this endpoint are obtained are out of scope for which the URL for this endpoint is obtained are out of scope for
this specification. this specification.
Client Configuration Endpoint OAuth 2.0 endpoint through which
registration information for a registered client can be managed.
This URL for this endpoint is returned by the authorization server
in the client information response.
Registration Access Token OAuth 2.0 bearer token issued by the
authorization server through the client registration endpoint that
is used to authenticate the caller when accessing the client's
registration information at the client configuration endpoint.
This access token is associated with a particular registered
client.
Initial Access Token OAuth 2.0 access token optionally issued by an Initial Access Token OAuth 2.0 access token optionally issued by an
Authorization Server and used to authorize calls to the client Authorization Server and used to authorize calls to the client
registration endpoint. The type and format of this token are registration endpoint. The type and format of this token are
likely service-specific and are out of scope for this likely service-specific and are out of scope for this
specification. The means by which the authorization server issues specification. The means by which the authorization server issues
this token as well as the means by which the registration endpoint this token as well as the means by which the registration endpoint
validates this token are out of scope for this specification. validates this token are out of scope for this specification.
1.3. Protocol Flow Deployment Organization An administrative security domain under
which, a software API is deployed and protected by an OAuth 2.0
framework. In simple cloud deployments, the software API
publisher and the deployment organization may be the same. In
other scenarios, a software publisher may be working with many
different deployment organizations.
(preamble) Software API Deployment A deployment instance of a software API that
is protected by OAuth 2.0 in a particular deployment organization
domain. For any particular software API, there may be one or more
deployments. A software API deployment typically has an
associated OAuth 2.0 authorization server endpoint as well as a
client registration endpoint. The means by which endpoints are
obtained (discovery) are out of scope for this specification.
+--------(A)- Initial Access Token Software API Publisher The organization that defines a particular
| web accessible API that may deployed in one or more deployment
v environments. A publisher may be any commercial, public, private,
or open source organization that is responsible for publishing and
distributing software that may be protected via OAuth 2.0. A
software API publisher may issue software assertions which client
developers use to distribute with their software to facilitate
registration. In some cases a software API publisher and a client
developer may be the same organization.
Software Statement A signed JSON Web Token (JWT) [JWT] that asserts
metadata values about the client software. This may be used by
the registration system to qualify clients for eligibility to
register. To obtain a software statement, a client developer may
generate a client specific assertion, or a client developer may
register with a software API publisher to obtain a software
assertion. The statement is distributed with all copies of a
client application and may be used during the registration
process.
1.3. Protocol Flow
+--------(A)- Initial Access Token (OPTIONAL)
|
| +----(B)- Software Statement (OPTIONAL)
| |
v v
+-----------+ +---------------+ +-----------+ +---------------+
| |--(B)- Client Registration Request -->| Client | | |--(C)- Client Registration Request -->| Client |
| | | Registration | | Client or | | Registration |
| |<-(C)- Client Information Response ---| Endpoint | | Developer |<-(D)- Client Information Response ---| Endpoint |
| | +---------------+
| |
| | +---------------+ | | +---------------+
| Client or |--(D)- Read or Update Request ------->| | +-----------+
| Developer | | |
| |<-(E)- Client Information Response ---| Client |
| | | Configuration |
| | | Endpoint |
| | | |
| |--(F)- Delete Request --------------->| |
| | | |
| |<-(G)- Delete Confirmation -----------| |
+-----------+ +---------------+
Figure 1: Abstract Protocol Flow Figure 1: Abstract Dynamic Client Registration Flow
The abstract OAuth 2.0 Client dynamic registration flow illustrated
The abstract OAuth 2.0 client dynamic registration flow illustrated
in Figure 1 describes the interaction between the client or developer in Figure 1 describes the interaction between the client or developer
and the two endpoints defined in this specification. This figure and the endpoint defined in this specification. This figure does not
does not demonstrate error conditions. This flow includes the demonstrate error conditions. This flow includes the following
following steps: steps:
(A) (A) Optionally, the client or developer is issued an initial access
Optionally, the client or developer is issued an initial access token giving access to the client registration endpoint. The
token for use with the client registration endpoint. The method method by which the initial access token is issued to the client
by which the initial access token is issued to the client or or developer is out of scope for this specification.
(B) Optionally, the client or developer is issued a software
statement for use with the client registration endpoint. The
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.
(B)
The client or developer calls the client registration endpoint (C) The client or developer calls the client registration endpoint
with its desired registration metadata, optionally including the with its desired registration metadata, optionally including the
initial access token from (A) if one is required by the initial access token from (A) if one is required by the
authorization server. authorization server.
(C)
The authorization server registers the client and returns the (D) The authorization server registers the client and returns the
client's registered metadata, a client identifier that is unique client's registered metadata, a client identifier that is unique
at the server, a set of client credentials such as a client secret at the server, a set of client credentials such as a client secret
if applicable for this client, a URI pointing to the client if applicable for this client, and possibly other values.
configuration endpoint, and a registration access token to be used
when calling the client configuration endpoint.
(D)
The client or developer optionally calls the client configuration
endpoint with a read or update request using the registration
access token issued in (C). An update request contains all of the
client's registered metadata.
(E)
The authorization server responds with the client's current
configuration, potentially including a new registration access
token and a new set of client credentials such as a client secret
if applicable for this client. If a new registration access token
is issued, it replaces the token issued in (C) for all subsequent
calls to the client configuration endpoint.
(F)
The client or developer optionally calls the client configuration
endpoint with a delete request using the registration access token
issued in (C).
(G)
The authorization server deprovisions the client and responds with
a confirmation that the deletion has taken place.
Further discussion of possible example lifecycles are found in the
Appendix to this specification, Client Lifecycle Examples
(Appendix B).
1.4. Registration Tokens and Client Credentials
Throughout the course of the dynamic registration protocol, there are
three different classes of credentials in play, each with different
properties and targets.
o The initial access token is optionally used by the client or
developer at the registration endpoint. This is an OAuth 2.0
token that is used to authorize the initial client registration
request. The content, structure, generation, and validation of
this token are out of scope for this specification. The
authorization server can use this token to verify that the
presenter is allowed to dynamically register new clients. This
token may be shared between multiple instances of a client to
allow them to each register separately, thereby letting the
authorization server use this token to tie multiple instances of
registered clients (each with their own distinct client
identifier) back to the party to whom the initial access token was
issued, usually an application developer. This token should be
used only at the client registration endpoint.
o The registration access token is used by the client or developer
at the client configuration endpoint and represents the holder's
authorization to manage the registration of a client. This is an
OAuth 2.0 bearer token that is issued from the client registration
endpoint in response to a client registration request and is
returned in a client information response. The registration
access token is uniquely bound to the client identifier and is
required to be presented with all calls to the client
configuration endpoint. The registration access token should be
protected and should not be shared between instances of a client
(otherwise, one instance could change or delete registration
values for all instances of the client). The registration access
token can be rotated through the use of the client read and update
methods on the client configuration endpoint. The registration
access token should be used only at the client configuration
endpoint.
o The client credentials (such as "client_secret") are optional
depending on the type of client and are used to retrieve OAuth
tokens. Client credentials are most often bound to particular
instances of a client and should not be shared between instances.
Note that since not all types of clients have client credentials,
they cannot be used to manage client registrations at the client
configuration endpoint. The client credentials can be rotated
through the use of the client read and update methods on the
client configuration endpoint. The client credentials can not be
used for authentication at the client registration endpoint or at
the client configuration endpoint.
1.4.1. Credential Rotation
The Authorization Server MAY rotate the client's registration access
token and/or client credentials (such as a "client_secret")
throughout the lifetime of the client. The client can discovery that
these values have changed by reading the client information response
returned from either a read or update request to the client
configuration endpoint. The client's current registration access
token and client credentials (if applicable) MUST be included in this
response.
The registration access token SHOULD be rotated only in response to a
read or update request to the client configuration endpoint, at which
point the new registration access token is returned to the client and
the old registration access token SHOULD be discarded by both
parties. If the registration access token to expire or be rotated
outside of such requests, the client or developer may be locked out
of managing the client's configuration.
2. Client Metadata 2. Client Metadata
Clients generally have an array of metadata associated with their Clients have a set of metadata values associated with their unique
unique client identifier at the authorization server. These can client identifier at an authorization server, such as the list of
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
valid redirect URIs. valid redirect URIs.
The client metadata values serve two parallel purposes in the overall The Client Metadata values are used in two ways:
OAuth 2.0 dynamic client registration protocol:
o the client requesting its desired values for each parameter to the o as input values to registration requests, and
authorization server in a register (Section 3.1) or update
(Section 4.3) request, and
o the authorization server informing the client of the current
values of each parameter that the client has been registered to
use through a client information response (Section 5.1).
An authorization server MAY override any value that a client requests o as output values in registration responses.
during the registration process (including any omitted values) and
replace the requested value with a default at the server's
discretion. The authorization server SHOULD provide documentation
for any fields that it requires to be filled in by the client or to
have particular values or formats. An authorization server MAY
ignore the values provided by the client for any field in this list.
Extensions and profiles of this specification MAY expand this list, Client Metadata values can either be communicated directly in the
and authorization servers MUST accept all fields in this list. The body of a registration request, as described in Section 4.1, or
authorization server MUST ignore any additional parameters sent by included as claims in a software statement, as described in
the Client that it does not understand. Section 3.
redirect_uris These Client Metadata values are defined by this specification:
Array of redirect URIs for use in redirect-based flows such as the
authorization code and implicit grant types. It is RECOMMENDED redirect_uris Array of redirect URIs for use in redirect-based flows
that clients using these flows register this parameter, and an such as the authorization code and implicit grant types. It is
authorization server SHOULD require registration of valid redirect RECOMMENDED that clients using these flows register this
URIs for all clients that use these grant types to protect against parameter, and an authorization server SHOULD require registration
token and credential theft attacks. of valid redirect URIs for all clients that use these grant types
client_name to protect against token and credential theft attacks.
Human-readable name of the client to be presented to the user. If
omitted, the authorization server MAY display the raw "client_id" token_endpoint_auth_method The requested authentication method for
value to the user instead. It is RECOMMENDED that clients always the token endpoint. Values defined by this specification are:
send this field. The value of this field MAY be internationalized
as described in Human Readable Client Metadata (Section 2.2).
client_uri
URL of the homepage of the client. If present, the server SHOULD
display this URL to the end user in a clickable fashion. It is
RECOMMENDED that clients always send this field. The value of
this field MUST point to a valid web page. The value of this
field MAY be internationalized as described in Human Readable
Client Metadata (Section 2.2).
logo_uri
URL that references a logo for the client. If present, the server
SHOULD display this image to the end user during approval. The
value of this field MUST point to a valid image file. The value
of this field MAY be internationalized as described in Human
Readable Client Metadata (Section 2.2).
contacts
Array of email addresses for people responsible for this client.
The authorization server MAY make these addresses available to end
users for support requests for the client. An authorization
server MAY use these email addresses as identifiers for an
administrative page for this client.
tos_uri
URL that points to a human-readable Terms of Service document for
the client. The Authorization Server SHOULD display this URL to
the end-user if it is given. The Terms of Service usually
describe a contractual relationship between the end-user and the
client that the end-user accepts when authorizing the client. The
value of this field MUST point to a valid web page. The value of
this field MAY be internationalized as described in Human Readable
Client Metadata (Section 2.2).
policy_uri
URL that points to a human-readable Policy document for the
client. The authorization server SHOULD display this URL to the
end-user if it is given. The policy usually describes how an end-
user's data will be used by the client. The value of this field
MUST point to a valid web page. The value of this field MAY be
internationalized as described in Human Readable Client Metadata
(Section 2.2).
token_endpoint_auth_method
The requested authentication method for the token endpoint.
Values defined by this specification are:
* "none": The client is a public client as defined in OAuth 2.0 * "none": The client is a public client as defined in OAuth 2.0
and does not have a client secret. and does not have a client secret.
* "client_secret_post": The client uses the HTTP POST parameters * "client_secret_post": The client uses the HTTP POST parameters
defined in OAuth 2.0 section 2.3.1. defined in OAuth 2.0 section 2.3.1.
* "client_secret_basic": the client uses HTTP Basic defined in * "client_secret_basic": the client uses HTTP Basic defined in
OAuth 2.0 section 2.3.1 OAuth 2.0 section 2.3.1
Additional values can be defined via the IANA OAuth Token Endpoint Additional values can be defined via the IANA OAuth Token Endpoint
Authentication Methods Registry Section 6.1. Absolute URIs can Authentication Methods Registry Section 6.2. Absolute URIs can
also be used as values for this parameter without being also be used as values for this parameter without being
registered. If unspecified or omitted, the default is registered. If unspecified or omitted, the default is
"client_secret_basic", denoting HTTP Basic Authentication Scheme "client_secret_basic", denoting HTTP Basic Authentication Scheme
as specified in Section 2.3.1 of OAuth 2.0. as specified in Section 2.3.1 of OAuth 2.0.
scope
Space separated list of scope values (as described in OAuth 2.0 grant_types Array of OAuth 2.0 grant types that the Client may use.
Section 3.3 [RFC6749]) that the client can use when requesting These grant types are defined as follows:
access tokens. The semantics of values in this list is service
specific. If omitted, an authorization server MAY register a
Client with a default set of scopes.
grant_types
Array of OAuth 2.0 grant types that the Client may use. These
grant types are defined as follows:
* "authorization_code": The Authorization Code Grant described in * "authorization_code": The Authorization Code Grant described in
OAuth 2.0 Section 4.1 OAuth 2.0 Section 4.1
* "implicit": The Implicit Grant described in OAuth 2.0
Section 4.2 * "implicit": The Implicit Grant described in OAuth 2.0 Section
4.2
* "password": The Resource Owner Password Credentials Grant * "password": The Resource Owner Password Credentials Grant
described in OAuth 2.0 Section 4.3 described in OAuth 2.0 Section 4.3
* "client_credentials": The Client Credentials Grant described in * "client_credentials": The Client Credentials Grant described in
OAuth 2.0 Section 4.4 OAuth 2.0 Section 4.4
* "refresh_token": The Refresh Token Grant described in OAuth 2.0 * "refresh_token": The Refresh Token Grant described in OAuth 2.0
Section 6. Section 6.
* "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer * "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer
Grant defined in OAuth JWT Bearer Token Profiles [OAuth.JWT]. Grant defined in OAuth JWT Bearer Token Profiles [OAuth.JWT].
* "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2 * "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2
Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles
[OAuth.SAML2]. [OAuth.SAML2].
Authorization Servers MAY allow for other values as defined in Authorization Servers MAY allow for other values as defined in
grant type extensions to OAuth 2.0. The extension process is grant type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5. If the token endpoint is used described in OAuth 2.0 Section 2.5. If the token endpoint is used
skipping to change at page 10, line 15 skipping to change at page 8, line 38
* "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2 * "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2
Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles Bearer Grant defined in OAuth SAML 2 Bearer Token Profiles
[OAuth.SAML2]. [OAuth.SAML2].
Authorization Servers MAY allow for other values as defined in Authorization Servers MAY allow for other values as defined in
grant type extensions to OAuth 2.0. The extension process is grant type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5. If the token endpoint is used described in OAuth 2.0 Section 2.5. If the token endpoint is used
in the grant type, the value of this parameter MUST be the same as in the grant type, the value of this parameter MUST be the same as
the value of the "grant_type" parameter passed to the token the value of the "grant_type" parameter passed to the token
endpoint defined in the extension. endpoint defined in the extension.
response_types
Array of the OAuth 2.0 response types that the Client may use. response_types Array of the OAuth 2.0 response types that the Client
These response types are defined as follows: may use. These response types are defined as follows:
* "code": The Authorization Code response described in OAuth 2.0 * "code": The Authorization Code response described in OAuth 2.0
Section 4.1. Section 4.1.
* "token": The Implicit response described in OAuth 2.0
Section 4.2. * "token": The Implicit response described in OAuth 2.0 Section
4.2.
Authorization servers MAY allow for other values as defined in Authorization servers MAY allow for other values as defined in
response type extensions to OAuth 2.0. The extension process is response type extensions to OAuth 2.0. The extension process is
described in OAuth 2.0 Section 2.5. If the authorization endpoint described in OAuth 2.0 Section 2.5. If the authorization endpoint
is used by the grant type, the value of this parameter MUST be the is used by the grant type, the value of this parameter MUST be the
same as the value of the "response_type" parameter passed to the same as the value of the "response_type" parameter passed to the
authorization endpoint defined in the extension. authorization endpoint defined in the extension.
jwks_uri
URL for the Client's JSON Web Key Set [JWK] document representing
the client's public keys. The value of this field MUST point to a
valid JWK Set. These keys MAY be used for higher level protocols
that require signing or encryption.
software_id
A identifier for the software that comprises a client. Unlike
"client_id", which is issued by the authorization server and
generally varies between instances, the "software_id" is asserted
by the client software and is intended to be shared between all
copies of the client software. The value for this field MAY be a
UUID [RFC4122]. The identifier SHOULD NOT change when software
version changes or when a new installation instance is detected.
Authorization servers MUST treat this field as self-asserted by
the client and MUST NOT make any trusted decisions on the value of
this field alone.
software_version
A version identifier for the software that comprises a client.
The value of this field is a string that is intended to be
compared using string equality matching. The value of the
"software_version" SHOULD change on any update to the client
software. Authorization servers MUST treat this field as self-
asserted by the client and MUST NOT make any trusted decisions on
the value of this field alone.
2.1. Relationship Between Grant Types and Response Types Authorization servers MUST accept all fields in this list.
Extensions and profiles of this specification MAY expand this list.
For instance, the [OAuth.Registration.Metadata] specification defines
additional client metadata values. The authorization server MUST
ignore any client metadata values sent by the Client that it does not
understand.
2.1. Relationship between Grant Types and Response Types
The "grant_types" and "response_types" values described above are The "grant_types" and "response_types" values described above are
partially orthogonal, as they refer to arguments passed to different partially orthogonal, as they refer to arguments passed to different
endpoints in the OAuth protocol. However, they are related in that endpoints in the OAuth protocol. However, they are related in that
the "grant_types" available to a client influence the the "grant_types" available to a client influence the
"response_types" that the client is allowed to use, and vice versa. "response_types" that the client is allowed to use, and vice versa.
For instance, a "grant_types" value that includes For instance, a "grant_types" value that includes
"authorization_code" implies a "response_types" value that includes "authorization_code" implies a "response_types" value that includes
"code", as both values are defined as part of the OAuth 2.0 "code", as both values are defined as part of the OAuth 2.0
authorization code grant. As such, a server supporting these fields authorization code grant. As such, a server supporting these fields
SHOULD take steps to ensure that a client cannot register itself into SHOULD take steps to ensure that a client cannot register itself into
an inconsistent state. an inconsistent state.
The correlation between the two fields is listed in the table below. The correlation between the two fields is listed in the table below.
+-------------------------------------------------+-----------------+ +-----------------------------------------------+-------------------+
| grant_types value includes: | response_types | | grant_types value includes: | response_types |
| | value includes: | | | value includes: |
+-------------------------------------------------+-----------------+ +-----------------------------------------------+-------------------+
| authorization_code | code | | authorization_code | code |
| implicit | token | | implicit | token |
| password | (none) | | password | (none) |
| client_credentials | (none) | | client_credentials | (none) |
| refresh_token | (none) | | refresh_token | (none) |
| urn:ietf:params:oauth:grant-type:jwt-bearer | (none) | | urn:ietf:params:oauth:grant-type:jwt-bearer | (none) |
| urn:ietf:params:oauth:grant-type:saml2-bearer | (none) | | urn:ietf:params:oauth:grant-type:saml2-bearer | (none) |
+-------------------------------------------------+-----------------+ +-----------------------------------------------+-------------------+
Extensions and profiles of this document that introduce new values to Extensions and profiles of this document that introduce new values to
either the "grant_types" or "response_types" parameter MUST document either the "grant_types" or "response_types" parameter MUST document
all correspondences between these two parameter types. all correspondences between these two parameter types.
2.2. Human Readable Client Metadata 3. Software Statement
Human-readable client metadata values and client metadata values that
reference human-readable values MAY be represented in multiple
languages and scripts. For example, the values of fields such as
"client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri"
might have multiple locale-specific values in some client
registrations.
To specify the languages and scripts, BCP47 [RFC5646] language tags A Software Statement is a signed JSON Web Token (JWT) [JWT] that
are added to client metadata member names, delimited by a # asserts metadata values about the client software. This may be used
character. Since JSON member names are case sensitive, it is by the registration system to qualify clients for eligibility to
RECOMMENDED that language tag values used in Claim Names be spelled register. To obtain a software statement, a client developer may
using the character case with which they are registered in the IANA generate a client specific assertion, or a client developer may
Language Subtag Registry [IANA.Language]. In particular, normally register with a software API publisher to obtain a software
language names are spelled with lowercase characters, region names assertion. The statement is distributed with all copies of a client
are spelled with uppercase characters, and languages are spelled with application and may be used during the registration process.
mixed case characters. However, since BCP47 language tag values are
case insensitive, implementations SHOULD interpret the language tag
values supplied in a case insensitive manner. Per the
recommendations in BCP47, language tag values used in metadata member
names should only be as specific as necessary. For instance, using
"fr" might be sufficient in many contexts, rather than "fr-CA" or
"fr-FR".
For example, a client could represent its name in English as The criteria by which authorization servers determine whether to
""client_name#en": "My Client"" and its name in Japanese as trust and utilize the information in a software statement is beyond
""client_name#ja-Jpan-JP": the scope of this specification.
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"" within the same
registration request. The authorization server MAY display any or
all of these names to the resource owner during the authorization
step, choosing which name to display based on system configuration,
user preferences or other factors.
If any human-readable field is sent without a language tag, parties If the authorization server determines that the claims in a software
using it MUST NOT make any assumptions about the language, character statement uniquely identify a piece of software, the same Client ID
set, or script of the string value, and the string value MUST be used value MAY be returned for all dynamic registrations using that
as-is wherever it is presented in a user interface. To facilitate software statement.
interoperability, it is RECOMMENDED that clients and servers use a
human-readable field without any language tags in addition to any
language-specific fields, and it is RECOMMENDED that any human-
readable fields sent without language tags contain values suitable
for display on a wide variety of systems.
Implementer's Note: Many JSON libraries make it possible to reference In some cases, authorization servers MAY choose to accept a software
members of a JSON object as members of an object construct in the statement value directly as a Client ID in an authorization request,
native programming environment of the library. However, while the without a prior dynamic client registration having been performed.
"#" character is a valid character inside of a JSON object's member The circumstances under which an authorization server would do so,
names, it is not a valid character for use in an object member name and the specific software statement characteristics required in this
in many programming environments. Therefore, implementations will case, are beyond the scope of this specification.
need to use alternative access forms for these claims. For instance,
in JavaScript, if one parses the JSON as follows, "var j =
JSON.parse(json);", then the member "client_name#en-us" can be
accessed using the JavaScript syntax "j["client_name#en-us"]".
3. Client Registration Endpoint 4. Client Registration Endpoint
The client registration endpoint is an OAuth 2.0 endpoint defined in The client registration endpoint is an OAuth 2.0 endpoint defined in
this document that is designed to allow a client to be registered this document that is designed to allow a client to be registered
with the authorization server. The client registration endpoint MUST with the authorization server. The client registration endpoint MUST
accept HTTP POST messages with request parameters encoded in the accept HTTP POST messages with request parameters encoded in the
entity body using the "application/json" format. The client entity body using the "application/json" format. The client
registration endpoint MUST be protected by a transport-layer security registration endpoint MUST be protected by a transport-layer security
mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246] and mechanism, and the server MUST support TLS 1.2 RFC 5246 [RFC5246]
/or TLS 1.0 [RFC2246] and MAY support additional transport-layer and/or TLS 1.0 [RFC2246] and MAY support additional transport-layer
mechanisms meeting its security requirements. When using TLS, the mechanisms meeting its security requirements. When using TLS, the
Client MUST perform a TLS/SSL server certificate check, per RFC 6125 Client MUST perform a TLS/SSL server certificate check, per RFC 6125
[RFC6125]. [RFC6125].
The client registration endpoint MAY be an OAuth 2.0 protected The client registration endpoint MAY be an OAuth 2.0 protected
resource and accept an initial access token in the form of an OAuth resource and accept an initial access token in the form of an OAuth
2.0 [RFC6749] access token to limit registration to only previously 2.0 [RFC6749] access token to limit registration to only previously
authorized parties. The method by which the initial access token is authorized parties. The method by which the initial access token is
obtained by the registrant is generally out-of-band and is out of obtained by the registrant is generally out-of-band and is out of
scope for this specification. The method by which the initial access scope for this specification. The method by which the initial access
token is verified and validated by the client registration endpoint token is verified and validated by the client registration endpoint
is out of scope for this specification. is out of scope for this specification.
To support open registration and facilitate wider interoperability, To support open registration and facilitate wider interoperability,
the client registration endpoint SHOULD allow initial registration the client registration endpoint SHOULD allow initial registration
requests with no authorization (which is to say, with no OAuth 2.0 requests with no authorization (which is to say, with no OAuth 2.0
access token in the request). These requests MAY be rate-limited or access token in the request). These requests MAY be rate-limited or
otherwise limited to prevent a denial-of-service attack on the client otherwise limited to prevent a denial-of-service attack on the client
registration endpoint. registration endpoint.
To allow the registrant to manage the client's information, the
client registration endpoint issues a request access token as an
OAuth 2.0 Bearer Token [RFC6750] to securely authorize calls to the
client configuration endpoint (Section 4).
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 4.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 client metadata parameters being specified for
(Section 2) that the client wishes to specify for itself during the the client during the registration. The authorization server MAY
registration. The authorization server MAY provision default values provision default values for any items omitted in the client
for any items omitted in the client metadata. metadata.
Client metadata values may also be provided in a software statement,
as described in Section 3. Software statements are included in
registration requests using this registration parameter:
software_statement A software statement containing client metadata
values about the client software as claims.
To register, the client or developer sends an HTTP POST to the client To register, the client or developer sends an HTTP POST to the client
registration endpoint with a content type of "application/json". The registration endpoint with a content type of "application/json". The
HTTP Entity Payload is a JSON [RFC4627] document consisting of a JSON HTTP Entity Payload is a JSON [RFC4627] document consisting of a JSON
object and all parameters as top-level members of that JSON object. object and all parameters as top-level members of that JSON object.
For example, if the server supports open registration (with no For example, if the server supports open registration (with no
initial access token), the client could send the following initial access token), the client could send the following
registration request to the client registration endpoint: registration request to the client registration endpoint:
Following is a non-normative example request (with line wraps for The following is a non-normative example request not using an initial
display purposes only): access token (with line wraps within values for display purposes
only):
POST /register HTTP/1.1 POST /register HTTP/1.1
Content-Type: application/json 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/callback2"], "https://client.example.org/callback",
"client_name":"My Example Client", "https://client.example.org/callback2"],
"client_name#ja-Jpan-JP": "token_endpoint_auth_method":"client_secret_basic",
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", "example_extension_parameter": "example_value"
"token_endpoint_auth_method":"client_secret_basic", }
"scope":"read write dolphin",
"logo_uri":"https://client.example.org/logo.png",
"jwks_uri":"https://client.example.org/my_public_keys.jwks"
}
Alternatively, if the server supports authorized registration, the Alternatively, if the server supports authorized registration, the
developer or the client will be provisioned with an initial access developer or the client will be provisioned with an initial access
token (the method by which the initial access token is obtained is token (the method by which the initial access token is obtained is
out of scope for this specification). The developer or client sends out of scope for this specification). The developer or client sends
the following authorized registration request to the client the following authorized registration request to the client
registration endpoint. Note that the initial access token sent in registration endpoint. Note that the initial access token sent in
this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth
2.0 token type could be used by an authorization server: 2.0 token type could be used by an authorization server.
Following is a non-normative example request (with line wraps for The following is a non-normative example request using an initial
access token (with line wraps within values for display purposes
only):
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: server.example.com
{
"redirect_uris":["https://client.example.org/callback",
"https://client.example.org/callback2"],
"token_endpoint_auth_method":"client_secret_basic",
"example_extension_parameter": "example_value"
}
In the following example, some registration parameters are conveyed
as claims in a software statement (with line wraps within values for
display purposes only): display purposes only):
POST /register HTTP/1.1 POST /register HTTP/1.1
Content-Type: application/json Content-Type: application/json
Accept: application/json Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321 Host: server.example.com
Host: server.example.com
{ {
"redirect_uris":["https://client.example.org/callback", "redirect_uris":[
"https://client.example.org/callback2"], "https://client.example.org/callback",
"client_name":"My Example Client", "https://client.example.org/callback2"
"client_name#ja-Jpan-JP": ],
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D", "software_statement":"eyJhbGciOiJFUzI1NiJ9.
"token_endpoint_auth_method":"client_secret_basic", eyJpc3Mi[...omitted for brevity...].
"scope":"read write dolphin", J9l-ZhwP[...omitted for brevity...]",
"logo_uri":"https://client.example.org/logo.png", "extension_parameter":"foo"
"jwks_uri":"https://client.example.org/my_public_keys.jwks" }
}
3.2. Client Registration Response 4.2. Client Registration Response
Upon successful registration, the authorization server generates a Upon successful registration, the authorization server generates a
new client identifier for the client. This client identifier MUST be new client identifier for the client. This client identifier MUST be
unique at the server and MUST NOT be in use by any other client. The 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 server responds with an HTTP 201 Created code and a body of type
"application/json" with content described in Client Information "application/json" with content as described in Section 5.1.
Response (Section 5.1).
Upon an unsuccessful registration, the authorization server responds Upon an unsuccessful registration, the authorization server responds
with an error as described in Client Registration Error with an error, as described in Section 5.2.
(Section 5.2).
4. Client Configuration Endpoint
The client configuration endpoint is an OAuth 2.0 protected resource
that is provisioned by the server to facilitate viewing, updating,
and deleting a client's registered information. The location of this
endpoint is communicated to the client through the
"registration_client_uri" member of the Client Information Response
(Section 5.1). The client MUST use its registration access token in
all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].
Operations on this endpoint are switched through the use of different
HTTP methods [RFC2616]. If an authorization server does not support
a particular method on the client configuration endpoint, it MUST
respond with the appropriate error code.
4.1. Forming the Client Configuration Endpoint URL
The authorization server MUST provide the client with the fully
qualified URL in the "registration_client_uri" 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.
Depending on deployment characteristics, the client configuration
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 or a query parameter. For example, a client with the
client identifier "s6BhdRkqt3" could be given a client configuration
endpoint URL of "https://server.example.com/register/s6BhdRkqt3"
(path parameter) or of "https://server.example.com/
register?client_id=s6BhdRkqt3" (query parameter). In both of these
cases, the client simply uses the URL as given by the authorization
server.
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 configuration endpoint URL and change
behavior based on the authentication context provided by the
registration access token.
4.2. Client Read Request
To read the current configuration of the client on the authorization
server, the client makes an HTTP GET request to the client
configuration endpoint, authenticating with its registration access
token.
Following is a non-normative example request (with line wraps for
display purposes only):
GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
Upon successful read of the information for a currently active
client, the authorization server responds with an HTTP 200 OK with
content type of "application/json" and a payload as described in
Client Information Response (Section 5.1). Some values in the
response, including the "client_secret" and
"registration_access_token", MAY be different from those in the
initial registration response. If the authorization server includes
a new client secret and/or registration access token in its response,
the client MUST immediately discard its previous client secret and/or
registration access token. The value of the "client_id" MUST NOT
change from the initial registration response.
If the registration access token used to make this request is not
valid, the server MUST respond with an error as described in OAuth
Bearer Token Usage [RFC6750].
If the client does not exist on this server, the server MUST respond
with HTTP 401 Unauthorized and the registration access token used to
make this request SHOULD be immediately revoked.
If the client does not have permission to read its record, the server
MUST return an HTTP 403 Forbidden.
4.3. Client Update Request
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 sends an HTTP PUT to the client configuration endpoint
with a content type of "application/json". The HTTP entity payload
is a JSON [RFC4627] document consisting of a JSON object and all
parameters as top- level members of that JSON object.
This request MUST include all fields described in Client Metadata
(Section 2) as returned to the client from a previous register, read,
or update operation. The client MUST NOT include the
"registration_access_token", "registration_client_uri",
"client_secret_expires_at", or "client_id_issued_at" fields described
in Client Information Response (Section 5.1).
Valid values of client metadata fields in this request MUST replace,
not augment, the values previously associated with this client.
Omitted fields MUST be treated as null or empty values by the server.
The client MUST include its "client_id" field in the request, and it 5. Responses
MUST be the same as its currently-issued client identifier. If the
client includes the "client_secret" field in the request, the value
of this field 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 chosen value.
For all metadata fields, the authorization server MAY replace any In response to certain requests from the client to either the client
invalid values with suitable default values, and it MUST return any registration endpoint as described in this specification, the
such fields to the client in the response. authorization server sends the following response bodies.
For example, a client could send the following request to the client 5.1. Client Information Response
registration endpoint to update the client registration in the above
example with new information:
Following is a non-normative example request (with line wraps for The response contains the client identifier as well as the client
display purposes only): secret, if the client is a confidential client. The response MAY
contain additional fields as specified by extensions to this
specification.
PUT /register/s6BhdRkqt3 HTTP/1.1 client_id REQUIRED. Unique client identifier. It MUST NOT be
Accept: application/json currently valid for any other distinct registered client. It MAY
Host: server.example.com be the same as the Client ID value used by other instances of this
Authorization: Bearer reg-23410913-abewfq.123483 client, provided that the Redirection URI values and potentially
other values dictated by authorization server policy are the same
for all instances.
{ client_secret OPTIONAL. The client secret. If issued, this MUST be
"client_id":"s6BhdRkqt3", unique for each "client_id". This value is used by confidential
"client_secret": "cf136dc3c1fc93f31185e5885805d", clients to authenticate to the token endpoint as described in
"redirect_uris":["https://client.example.org/callback", OAuth 2.0 [RFC6749] Section 2.3.1.
"https://client.example.org/alt"],
"scope": "read write dolphin",
"grant_types": ["authorization_code", "refresh_token"]
"token_endpoint_auth_method": "client_secret_basic",
"jwks_uri": "https://client.example.org/my_public_keys.jwks"
"client_name":"My New Example",
"client_name#fr":"Mon Nouvel Exemple",
"logo_uri":"https://client.example.org/newlogo.png"
"logo_uri#fr":"https://client.example.org/fr/newlogo.png"
}
Upon successful update, the authorization server responds with an client_id_issued_at OPTIONAL. Time at which the Client Identifier
HTTP 200 OK Message with content type "application/json" and a was issued. The time is represented as the number of seconds from
payload as described in Client Information Response (Section 5.1). 1970-01-01T0:0:0Z as measured in UTC until the date/time.
Some values in the response, including the "client_secret" and
r"egistration_access_token", MAY be different from those in the
initial registration response. If the authorization server includes
a new client secret and/or registration access token in its response,
the client MUST immediately discard its previous client secret and/or
registration access token. The value of the "client_id" MUST NOT
change from the initial registration response.
If the registration access token used to make this request is not client_secret_expires_at REQUIRED if "client_secret" is issued.
valid, the server MUST respond with an error as described in OAuth Time at which the "client_secret" will expire or 0 if it will not
Bearer Token Usage [RFC6750]. expire. The time is represented as the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time.
If the client does not exist on this server, the server MUST respond Additionally, the Authorization Server MUST return all registered
with HTTP 401 Unauthorized, and the registration access token used to metadata about this client, including any fields provisioned by the
make this request SHOULD be immediately revoked. authorization server itself. The authorization server MAY reject or
replace any of the client's requested metadata values submitted
during the registration or update requests and substitute them with
suitable values.
If the client is not allowed to update its records, the server MUST The response is an "application/json" document with all parameters as
respond with HTTP 403 Forbidden. top-level members of a JSON object [RFC4627].
If the client attempts to set an invalid metadata field and the If a software statement was used as part of the registration, its
authorization server does not set a default value, the authorization value SHOULD be returned in the response. Client metadata elements
server responds with an error as described in Client Registration used from the software statement SHOULD also be returned directly as
Error Response (Section 5.2). top-level client metadata values in the registration response.
4.4. Client Delete Request Following is a non-normative example response:
To deprovision itself on the authorization server, the client makes HTTP/1.1 200 OK
an HTTP DELETE request to the client configuration endpoint. This Content-Type: application/json
request is authenticated by the registration access token issued to Cache-Control: no-store
the client. Pragma: no-cache
Following is a non-normative example request (with line wraps for {
display purposes only): "client_id":"s6BhdRkqt3",
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"client_id_issued_at":2893256800,
"client_secret_expires_at":2893276800,
"redirect_uris":[
"https://client.example.org/callback",
"https://client.example.org/callback2"],
"grant_types": ["authorization_code", "refresh_token"],
"token_endpoint_auth_method": "client_secret_basic",
"example_extension_parameter": "example_value"
}
DELETE /register/s6BhdRkqt3 HTTP/1.1 5.2. Client Registration Error Response
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
A successful delete action will invalidate the "client_id", When an OAuth 2.0 error condition occurs, such as the client
"client_secret", and "registration_access_token" for this client, presenting an invalid initial access token, the authorization server
thereby preventing the "client_id" from being used at either the returns an error response appropriate to the OAuth 2.0 token type.
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 When a registration error condition occurs, the authorization server
server responds with an HTTP 204 No Content message. returns an HTTP 400 status code (unless otherwise specified) with
content type "application/json" consisting of a JSON object [RFC4627]
describing the error in the response body.
If the server does not support the delete method, the server MUST The JSON object contains two members:
respond with an HTTP 405 Not Supported.
If the registration access token used to make this request is not error Single ASCII error code string.
valid, the server MUST respond with an error as described in OAuth
Bearer Token Usage [RFC6750].
If the client does not exist on this server, the server MUST respond error_description Human-readable ASCII text description of the error
with HTTP 401 Unauthorized and the registration access token used to used for debugging.
make this request SHOULD be immediately revoked.
If the client is not allowed to delete itself, the server MUST This specification defines the following error codes:
respond with HTTP 403 Forbidden.
Following is a non-normative example response: invalid_redirect_uri The value of one or more "redirect_uris" is
invalid.
HTTP/1.1 204 No Content invalid_client_metadata The value of one of the client metadata
Cache-Control: no-store fields is invalid and the server has rejected this request. Note
Pragma: no-cache that an Authorization server MAY choose to substitute a valid
value for any requested parameter of a client's metadata.
5. Responses invalid_software_statement The software statement presented is
invalid.
In response to certain requests from the client to either the client unapproved_software_statement The software statement presented is
registration endpoint or the client configuration endpoint as not approved for use with this authorization server.
described in this specification, the authorization server sends the
following response bodies.
5.1. Client Information Response Following is a non-normative example of an error response (with line
wraps for display purposes only):
The response contains the client identifier as well as the client HTTP/1.1 400 Bad Request
secret, if the client is a confidential client. The response also Content-Type: application/json
contains the fully qualified URL of the client configuration endpoint Cache-Control: no-store
for this specific client that the client may use to obtain and update Pragma: no-cache
information about itself. The response also contains a registration
access token that is to be used by the client to perform subsequent
operations at the client configuration endpoint.
client_id {
REQUIRED. The unique client identifier, MUST NOT be currently "error":"invalid_redirect_uri",
valid for any other registered client. "error_description":"The redirect URI http://sketchy.example.com
client_secret is not allowed for this server."
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
[RFC6749] Section 2.3.1.
client_id_issued_at
OPTIONAL. Time at which the Client Identifier was issued. The
time is represented as the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time.
client_secret_expires_at 6. IANA Considerations
REQUIRED if "client_secret" is issued. Time at which the
"client_secret" will expire or 0 if it will not expire. The time
is represented as the number of seconds from 1970-01-01T0:0:0Z as
measured in UTC until the date/time.
registration_access_token
REQUIRED. Access token that is used at the client configuration
endpoint to perform subsequent operations upon the client
registration.
registration_client_uri
REQUIRED. The fully qualified URL of the client configuration
endpoint for this client. The client MUST use this URL as given
when communicating with the client configuration endpoint.
Additionally, the Authorization Server MUST return all registered 6.1. OAuth Registration Client Metadata Registry
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 the registration or update requests and
substitute them with suitable values.
The response is an "application/json" document with all parameters as This specification establishes the OAuth Registration Client Metadata
top-level members of a JSON object [RFC4627]. registry.
Following is a non-normative example response: OAuth registration client metadata values are registered with a
Specification Required ([RFC5226]) after a two-week 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 allocation of
values prior to publication, the Designated Expert(s) may approve
registration once they are satisfied that such a specification will
be published.
HTTP/1.1 200 OK Registration requests must be sent to the oauth-ext-review@ietf.org
Content-Type: application/json mailing list for review and comment, with an appropriate subject
Cache-Control: no-store (e.g., "Request to register OAuth Registration Client Metadata name:
Pragma: no-cache example").
{ Within the review period, the Designated Expert(s) will either
"registration_access_token": "reg-23410913-abewfq.123483", approve or deny the registration request, communicating this decision
"registration_client_uri": to the review list and IANA. Denials should include an explanation
"https://server.example.com/register/s6BhdRkqt3", and, if applicable, suggestions as to how to make the request
"client_id":"s6BhdRkqt3", successful.
"client_secret": "cf136dc3c1fc93f31185e5885805d",
"client_id_issued_at":2893256800
"client_secret_expires_at":2893276800
"client_name":"My Example Client",
"client_name#ja-Jpan-JP":
"\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
"redirect_uris":["https://client.example.org/callback",
"https://client.example.org/callback2"]
"scope": "read write dolphin",
"grant_types": ["authorization_code", "refresh_token"]
"token_endpoint_auth_method": "client_secret_basic",
"logo_uri": "https://client.example.org/logo.png",
"jwks_uri": "https://client.example.org/my_public_keys.jwks"
}
5.2. Client Registration Error Response IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing
list.
When an OAuth 2.0 error condition occurs, such as the client 6.1.1. Registration Template
presenting an invalid registration access token, the authorization
server returns an error response appropriate to the OAuth 2.0 token
type. For the registration access token, which is an OAuth 2.0
bearer token, this error response is defined in Section 3 of OAuth
2.0 Bearer Token Usage [RFC6750].
When a registration error condition occurs, the authorization server Client Metadata Name: The name requested (e.g., "example"). This
returns an HTTP 400 status code (unless otherwise specified) with name is case sensitive. Names that match other registered names
content type "application/json" consisting of a JSON object [RFC4627] in a case insensitive manner SHOULD NOT be accepted.
describing the error in the response body.
The JSON object contains two members: Client Metadata Description:
Brief description of the metadata value (e.g., "Example
description").
error Change controller: For Standards Track RFCs, state "IETF". For
The error code, a single ASCII string. others, give the name of the responsible party. Other details
error_description (e.g., postal address, email address, home page URI) may also be
A human-readable text description of the error for debugging. included.
This specification defines the following error codes: Specification document(s): Reference to the document(s) that specify
the token endpoint authorization method, preferably including a
URI that can be used to retrieve a copy of the document(s). An
indication of the relevant sections may also be included but is
not required.
invalid_redirect_uri 6.1.2. Initial Registry Contents
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
The value of "client_id" does not match the one assigned to this
client.
Following is a non-normative example of an error response (with line The initial contents of the OAuth Registration Client Metadata
wraps for display purposes only): registry are:
HTTP/1.1 400 Bad Request o Client Metadata Name: "redirect_uris"
Content-Type: application/json o Client Metadata Description: Array of redirect URIs for use in
Cache-Control: no-store redirect-based flows
Pragma: no-cache o Change controller: IESG
o Specification document(s): [[ this document ]]
{ o Client Metadata Name: "token_endpoint_auth_method"
"error":"invalid_redirect_uri", o Client Metadata Description: Requested authentication method for
"error_description":"The redirect URI of http://sketchy.example.com the token endpoint
is not allowed for this server." o Change controller: IESG
} o Specification document(s): [[ this document ]]
6. IANA Considerations o Client Metadata Name: "grant_types"
o Client Metadata Description: Array of OAuth 2.0 grant types that
the Client may use
o Change controller: IESG
o Specification document(s): [[ this document ]]
o Client Metadata Name: "response_types"
o Client Metadata Description: Array of the OAuth 2.0 response types
that the Client may use
o Change controller: IESG
o Specification document(s): [[ this document ]]
6.1. OAuth Token Endpoint Authentication Methods Registry 6.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" metadata
values are registered with a Specification Required ([RFC5226]) after values are registered with a Specification Required ([RFC5226]) after
a two-week review period on the oauth-ext-review@ietf.org mailing a two-week review period on the oauth-ext-review@ietf.org mailing
list, on the advice of one or more Designated Experts. However, to list, on the advice of one or more Designated Experts. However, to
allow for the allocation of values prior to publication, the allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied Designated Expert(s) may approve registration once they are satisfied
skipping to change at page 24, line 12 skipping to change at page 18, line 38
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.
IANA must only accept registry updates from the Designated Expert(s) IANA must only accept registry updates from the Designated Expert(s)
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
6.1.1. Registration Template 6.2.1. Registration Template
Token Endpoint Authorization Method name: Token Endpoint Authorization Method Name: The name requested (e.g.,
The name requested (e.g., "example"). This name is case "example"). This name is case sensitive. Names that match other
sensitive. Names that match other registered names in a case registered names in a case insensitive manner SHOULD NOT be
insensitive manner SHOULD NOT be accepted. accepted.
Change controller: Change controller: For Standards Track RFCs, state "IETF". For
For Standards Track RFCs, state "IETF". For others, give the name others, give the name of the responsible party. Other details
of the responsible party. Other details (e.g., postal address, (e.g., postal address, email address, home page URI) may also be
email address, home page URI) may also be included. included.
Specification document(s): Specification document(s): Reference to the document(s) that specify
Reference to the document(s) that specify the token endpoint the token endpoint authorization method, preferably including a
authorization method, preferably including a URI that can be used URI that can be used to retrieve a copy of the document(s). An
to retrieve a copy of the document(s). An indication of the indication of the relevant sections may also be included but is
relevant sections may also be included but is not required. not required.
6.1.2. Initial Registry Contents 6.2.2. Initial Registry Contents
The OAuth Token Endpoint Authentication Methods registry's initial The initial contents of the OAuth Token Endpoint Authentication
contents are: Methods registry are:
o Token Endpoint Authorization Method name: "none" o Token Endpoint Authorization Method Name: "none"
o Change controller: IETF o Change controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
o Token Endpoint Authorization Method name: "client_secret_post" o Token Endpoint Authorization Method Name: "client_secret_post"
o Change controller: IETF o Change controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
o Token Endpoint Authorization Method name: "client_secret_basic" o Token Endpoint Authorization Method Name: "client_secret_basic"
o Change controller: IETF o Change controller: IESG
o Specification document(s): [[ this document ]] o Specification document(s): [[ this document ]]
7. Security Considerations 7. Security Considerations
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/or TLS 1.0 [RFC2246] and MAY support additional [RFC5246] and/or TLS 1.0 [RFC2246] and MAY support additional
transport-layer mechanisms meeting its security requirements. When transport-layer mechanisms meeting its security requirements. When
using TLS, the Client MUST perform a TLS/SSL server certificate using TLS, the Client MUST perform a TLS/SSL server certificate
check, per RFC 6125 [RFC6125]. check, per RFC 6125 [RFC6125].
Since the client configuration endpoint is an OAuth 2.0 protected
resource, it SHOULD have some rate limiting on failures to prevent
the registration access token from being disclosed though repeated
access attempts.
For clients that use redirect-based grant types such as For clients that use redirect-based grant types such as
"authorization_code" and "implicit", authorization servers SHOULD "authorization_code" and "implicit", authorization servers SHOULD
require clients to register their "redirect_uris". Requiring clients require clients to register their "redirect_uris". Requiring clients
to do so can help mitigate attacks where rogue actors inject and to do so can help mitigate attacks where rogue actors inject and
impersonate a validly registered client and intercept its impersonate a validly registered client and intercept its
authorization code or tokens through an invalid redirect URI. authorization code or tokens through an invalid redirect URI.
The authorization server MUST treat all client metadata as self-
asserted. For instance, a rogue client might use the name and logo
for the legitimate client which it is trying to impersonate.
Additionally, a rogue client might try to use the software identifier
or software version of a legitimate client to attempt to associate
itself on the authorization server instances of the legitimate
client. To counteract this, an authorization server needs to take
steps to mitigate this phishing risk by looking at the entire
registration request and client configuration. For instance, an
authorization server could warn if the domain/site of the logo
doesn't match the domain/site of redirect URIs. An authorization
server could also refuse registration from a known software
identifier that is requesting different redirect URIs or a different
client homepage uri. An authorization server can also present
warning messages to end users about dynamically registered clients in
all cases, especially if such clients have been recently registered
or have not been trusted by any users at the authorization server
before.
In a situation where the authorization server is supporting open
client registration, it must be extremely careful with any URL
provided by the client that will be displayed to the user (e.g.
"logo_uri", "tos_uri", "client_uri", and "policy_uri"). For
instance, a rogue client could specify a registration request with a
reference to a drive-by download in the "policy_uri". The
authorization server SHOULD check to see if the "logo_uri",
"tos_uri", "client_uri", and "policy_uri" have the same host and
scheme as the those defined in the array of "redirect_uris" and that
all of these resolve to valid web pages.
While the client secret can expire, the registration access token
should not expire while a client is still actively registered. If
this token were to expire, a developer or client could be left in a
situation where they have no means of retrieving or updating the
client's registration information. Were that the case, a new
registration would be required, thereby generating a new client
identifier. However, to limit the exposure surface of the
registration access token, the registration access token MAY be
rotated when the developer or client does a read or update operation
on the client's client configuration endpoint. As the registration
access tokens are relatively long-term credentials, and since the
registration access token is a Bearer token and acts as the sole
authentication for use at the client configuration endpoint, it MUST
be protected by the developer or client as described in OAuth 2.0
Bearer Token Usage [RFC6750].
If a client is deprovisioned from a server, any outstanding
registration access token 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 configuration endpoint
where the authentication would succeed but the action would fail
because the client is no longer valid. To prevent accidental
disclosure from such an erroneous situation, the authorization server
MUST treat all such requests as if the registration access token was
invalid (by returning an HTTP 401 Unauthorized error, as described).
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's 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
skipping to change at page 27, line 22 skipping to change at page 20, line 32
token endpoint. In such a situation, a server MAY disallow clients token endpoint. In such a situation, a server MAY disallow clients
from registering for both the "authorization_code" and "implicit" from registering for both the "authorization_code" and "implicit"
grant types simultaneously. Similarly, the "authorization_code" grant types simultaneously. Similarly, the "authorization_code"
grant type is used to represent access on behalf of an end user, but grant type is used to represent access on behalf of an end user, but
the "client_credentials" grant type represents access on behalf of the "client_credentials" grant type represents access on behalf of
the client itself. For security reasons, an authorization server the client itself. For security reasons, an authorization server
could require that different scopes be used for these different use could require that different scopes be used for these different use
cases, and as a consequence it MAY disallow these two grant types cases, and as a consequence it MAY disallow these two grant types
from being registered together by the same client. In all of these from being registered together by the same client. In all of these
cases, the authorization server would respond with an cases, the authorization server would respond with an
"invalid_client_metadata" error response (Section 5.2). "invalid_client_metadata" error response.
8. Normative References 8. References
[IANA.Language] 8.1. Normative References
Internet Assigned Numbers Authority (IANA), "Language
Subtag Registry", 2005.
[JWK] Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
key (work in progress), May 2013. (JWT)", draft-ietf-oauth-json-web-token (work in
progress), January 2014.
[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) Bearer Token Profiles for OAuth 2.0", draft-ietf- (JWT) Profile for OAuth 2.0 Client Authentication and
oauth-jwt-bearer (work in progress), March 2013. Authorization Grants", draft-ietf-oauth-jwt-bearer (work
in progress), December 2013.
[OAuth.SAML2] [OAuth.SAML2]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Bearer Assertion Profiles for OAuth 2.0", draft-ietf- Profile for OAuth 2.0 Client Authentication and
oauth-saml2-bearer (work in progress), March 2013. Authorization Grants", draft-ietf-oauth-saml2-bearer (work
in progress), December 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
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",
6749, October 2012. RFC 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.
Appendix A. Acknowledgments 8.2. Informative References
The authors thank the OAuth Working Group, the User-Managed Access [OAuth.Registration.Management]
Working Group, and the OpenID Connect Working Group participants for Richer, J., Jones, M., Bradley, J., and M. Machulak,
their input to this document. In particular, the following "OAuth 2.0 Dynamic Client Registration Management
individuals have been instrumental in their review and contribution Protocol", draft-jones-oauth-dyn-reg-management (work in
to various versions of this document: Amanda Anganes, Derek Atkins, progress), January 2014.
Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov,
George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten
Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Nat Sakimura,
Christian Scholz, and Hannes Tschofenig.
Appendix B. Client Lifecycle Examples [OAuth.Registration.Metadata]
Richer, J., Jones, M., Bradley, J., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Metadata",
draft-jones-oauth-dyn-reg-metadata (work in progress),
January 2014.
In the OAuth 2.0 specification [RFC6749], a client is identified by Appendix A. Use Cases
its own unique Client identifier ("client_id") at each authorization
server that it associates with. Dynamic registration as defined in
this document is one way for a client to get a client identifier and
associate a set of metadata with that identifier. Lack of such a
client identifier is the expected trigger for a client registration
operation.
In many cases, this client identifier is a unique, pairwise This appendix describes different ways that this specification can be
association between a particular running instance of a piece of utilized, including describing some of the choices that may need to
client software and a particular running instance of an authorization be made. Some of the choices are independent and can be used in
server software. In particular: combination, whereas some of the choices are interrelated.
o A single instance of client software (such as a Web server) A.1. Open versus Protected Dynamic Client Registration
talking to multiple authorization servers will need to register
with each authorization server separately, creating a distinct
client identifier with each authorization server. The client can
not make any assumption that the authorization servers are
correlating separate registrations of the client software together
without further profiles and extensions to this specification
document. The means by which a client discovers and
differentiates between multiple authorization servers is out of
scope for this specification.
o Multiple instances of client software (such as a native
application installed on multiple devices simultaneously) talking
to the same authorization server will need to each register with
that authorization server separately, creating a distinct client
identifier for each copy of the application. The authorization
server cannot make any assumption of correlation between these
clients without further specifications, profiles, and extensions
to this specification. The client can not make any assumption
that the authorization server will correlate separate
registrations of the client software together without further
profiles and extensions to this specification document.
A client identifier (and its associated credentials) could also be A.1.1. Open Dynamic Client Registration
shared between multiple instances of a client. Mechanisms for
sharing client identifiers between multiple instances of a piece of
software (either client or authorization server) are outside the
scope of this specification, as it is expected that every successful
registration request (Section 3.1) results in the issuance of a new
client identifier.
There are several patterns of OAuth client registration that dynamic Authorization servers that support open registration allow
registration protocol can enable. The following non-normative registrations to be made with no initial access token. This allows
example lifecycle descriptions are not intended to be an exhaustive all client software to register with the authorization server.
list. It is assumed that the authorization server supports the
dynamic registration protocol and that all necessary discovery steps
(which are out of scope for this specification) have already been
performed.
B.1. Open Registration A.1.2. Protected Dynamic Client Registration
Open registration, with no authorization required on the client
registration endpoint, works as follows:
a. A client needs to get OAuth 2.0 tokens from an authorization Authorization servers that support protected registration require
server, but the client does not have a client identifier for that that an initial access token be used when making registration
authorization server. requests. While the method by which a client or developer receives
b. The client sends an HTTP POST request to the client registration this initial access token and the method by which the authorization
endpoint at the authorization server and includes its metadata. server validates this initial access token are out of scope for this
c. The authorization server issues a client identifier and returns specification, a common approach is for the developer to use a manual
it to the client along with a registration access token and a pre-registration portal at the authorization server that issues an
reference to the client's client configuration endpoint. initial access token to the developer.
d. The client stores the returned response from the authorization
server. At a minimum, it should remember the values of
"client_id", "client_secret" (if present),
"registration_access_token", and "registration_client_uri".
e. The client uses the its "client_id" and "client_secret" (if
provided) to request OAuth 2.0 tokens using any valid OAuth 2.0
flow for which it is authorized.
f. If the client's "client_secret" expires or otherwise stops
working, the client sends an HTTP GET request to the
"registration_client_uri" with the "registration_access_token" as
its authorization. This response will contain the client's
refreshed "client_secret" along with any changed metadata values.
Its "client_id" will remain the same.
g. If the client needs to update its configuration on the
authorization server, it sends an HTTP PUT request to the
"registration_client_uri" with the "registration_access_token" as
its authorization. This response will contain the client's
changed metadata values. Its "client_id" will remain the same.
h. If the client is uninstalled or otherwise deprovisioned, it can
send an HTTP DELETE request to the "registration_client_uri" with
the "registration_access_token" as its authorization. This will
effectively deprovision the client from the authorization server.
B.2. Protected Registration A.2. Registration without or with Software Statements
An authorization server may require an initial access token for A.2.1. Registration without a Software Statement
requests to its registration endpoint. While the method by which a
client receives this initial Access token and the method by which the
authorization server validates this initial access token are out of
scope for this specification, a common approach is for the developer
to use a manual pre-registration portal at the authorization server
that issues an initial access token to the developer. This allows
the developer to package the initial access token with different
instances of the client application. While each copy of the
application would get its own client identifier (and registration
access token), all instances of the application would be tied back to
the developer by their shared use of this initial access token.
a. A developer is creating a client to use an authorization server When a software statement is not used in the registration request,
and knows that instances of the client will dynamically register the authorization server must be willing to use client metadata
at runtime, but that the authorization server requires values without them being signed (and thereby attested to) by any
authorization at the registration endpoint. authority. (Note that this choice is independent of the Open versus
b. The developer visits a manual pre-registration page at the Protected choice, and that an initial access token is another
authorization server and is issued an initial access token in the possible form of attestation.)
form of an OAuth 2.0 Bearer Token [RFC6750].
c. The developer packages that token with all instances of the
client application.
d. The client needs to get OAuth 2.0 tokens from an authorization
server, but the client does not have a client identifier for that
authorization server.
e. The client sends an HTTP POST request to the client registration
endpoint at the authorization server with its metadata, and the
initial access token as its authorization.
f. The authorization server issues a client identifier and returns
it to the client along with a registration access token and a
reference to the client's client configuration endpoint.
g. The client stores the returned response from the authorization
server. At a minimum, it should know the values of "client_id",
"client_secret" (if present), "registration_access_token", and
"registration_client_uri".
h. The client uses the its "client_id" and "client_secret" (if
provided) to request OAuth 2.0 tokens using any supported OAuth
2.0 flow for which this client is authorized.
i. If the client's "client_secret" expires or otherwise stops
working, the client sends an HTTP GET request to the
"registration_client_uri" with the "registration_access_token" as
its authorization. This response will contain the client's
refreshed "client_secret" along with any metadata values
registered to that client, some of which may have changed. Its
"client_id" will remain the same.
j. If the client needs to update its configuration on the
authorization server, it sends an HTTP PUT request to the
"registration_client_uri" with the "registration_access_token" as
its authorization. The response will contain the client's
changed metadata values. Its "client_id" will remain the same.
k. If the client is uninstalled or otherwise deprovisioned, it can
send an HTTP DELETE request to the "registration_client_uri" with
the "registration_access_token" as its authorization. This will
effectively deprovision the client from the Authorization Server.
B.3. Developer Automation A.2.2. Registration with a Software Statement
The dynamic registration protocol can also be used in place of a A software statement can be used in a registration request to provide
manual registration portal, for instance as part of an automated attestation for a set of client metadata values for a piece of client
build and deployment process. In this scenario, the authorization software by an authority. This can be useful when the authorization
server may require an initial access token for requests to its server wants to restrict registration to client software attested to
registration endpoint, as described in Protected Registration by a set of authorities or when it wants to know that multiple
(Appendix B.2). However, here the developer manages the client's registration requests refer to the same piece of client software.
registration instead of the client itself. Therefore, the initial
registration token and registration access token all remain with the
developer. The developer packages the client identifier with the
client as part of the client's build process.
a. A developer is creating a client to use an authorization server A.3. Registration by the Client or the Developer
and knows that instances of the client will not dynamically
register at runtime. A.3.1. Registration by the Client
b. If required for registrations at the authorization server, the
developer performs an OAuth 2.0 authorization of his build In some use cases, client software will dynamically register itself
environment against the authorization server using any valid with an authorization server to obtain a Client ID and other
OAuth 2.0 flow. The authorization server and is issues an information needed to interact with the authorization server. In
initial access token to the developer's build environment in the this case, no Client ID for the authorization server is packaged with
form of an OAuth 2.0 Bearer Token [RFC6750]. the client software.
c. The developer configures his build environment to send an HTTP
POST request to the client registration endpoint at the A.3.2. Registration by the Developer
authorization server with the client's metadata, using the
initial access token obtained the previous step as an OAuth 2.0 In some cases, the developer (or development software being used by
Bearer Token [RFC6750]. the developer) will pre-register the client software with the
d. The authorization server issues a client identifier and returns authorization server or a set of authorization servers. In this
it to the developer along with a registration access token and a case, the Client ID value(s) for the authorization server(s) can be
reference to the client's client configuration endpoint. packaged with the client software.
e. The developer packages the client identifier with the client and
stores the "registration_access_token", and A.4. Client ID per Client Instance or per Client Software
"registration_client_uri" in the deployment system.
f. The client uses the its "client_id" and "client_secret" (if A.4.1. Client ID per Client Software Instance
provided) to request OAuth 2.0 tokens using any supported OAuth
2.0 flow. In some cases, each deployed instance of a piece of client software
g. If the client's "client_secret" expires or otherwise stops will dynamically register and obtain distinct Client ID values. This
working, the developer's deployment system sends an HTTP GET can be advantageous, for instance, if the code flow is being used, as
request to the "registration_client_uri" with the it also enables each client instance to have its own client secret.
"registration_access_token" as its authorization. This response This can be useful for native clients, which cannot maintain the
will contain the client's refreshed "client_secret" along with secrecy of a client secret value packaged with the software, but
any changed metadata values. Its "client_id" will remain the which may be able to maintain the secrecy of a per-instance client
same. These new values will then be packaged and shipped to or secret.
retrieved by instances of the client, if necessary.
h. If the developer needs to update its configuration on the A.4.2. Client ID Shared between all Instances of Client Software
authorization server, the deployment system sends an HTTP PUT
request to the "registration_client_uri" with the In some cases, each deployed instance of a piece of client software
"registration_access_token" as its authorization. This response will share a common Client ID value. For instance, this is often the
will contain the client's changed metadata values. Its case for native client using implicit flow, when no client secret is
"client_id" will remain the same. These new values will then be involved. Particular authorization servers might choose, for
packaged and shipped to or retrieved by instances of the client, instance, to maintain a mapping between software statement values and
if necessary. Client ID values, and return the same Client ID value for all
i. If the client is deprovisioned, the developer's deployment system registration requests for a particular piece of software. The
can send an HTTP DELETE request to the "registration_client_uri" circumstances under which an authorization server would do so, and
with the "registration_access_token" as its authorization. This the specific software statement characteristics required in this
will effectively deprovision the client from the authorization case, are beyond the scope of this specification.
server and prevent any instances of the client from functioning.
A.5. Stateful or Stateless Registration
A.5.1. Stateful Client Registration
In some cases, authorization servers will maintain state about
registered clients, typically indexing this state using the Client ID
value. This state would typically include the client metadata values
associated with the client registration, and possibly other state
specific to the authorization server's implementation. When stateful
registration is used, operations to support retrieving and/or
updating this state may be supported, as described in the
[OAuth.Registration.Management] specification.
A.5.2. Stateless Client Registration
In some cases, authorization servers will be implemented in a manner
the enables them to not maintain any local state about registered
clients. One means of doing this is to encode all the registration
state in the returned Client ID value, and possibly encrypting the
state to the authorization server to maintain the confidentiality and
integrity of the state.
Appendix B. Acknowledgments
The authors thank the OAuth Working Group, the User-Managed Access
Working Group, and the OpenID Connect Working Group participants for
their input to this document. In particular, the following
individuals have been instrumental in their review and contribution
to various versions of this document: Amanda Anganes, Derek Atkins,
Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov,
George Fletcher, Thomas Hardjono, Phil Hunt, William Kim, Torsten
Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat
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 ]]
-15
o Partitioned the Dynamic Client Registration specification into
core, metadata, and management specifications. This built on work
first published as draft-richer-oauth-dyn-reg-core-00 and
draft-richer-oauth-dyn-reg-management-00.
o Added the ability to use Software Statements. This built on work
first published as draft-hunt-oauth-software-statement-00 and
draft-hunt-oauth-client-association-00.
o Created the IANA OAuth Registration Client Metadata registry for
registering Client Metadata values.
o Defined Client Instance term and stated that multiple instances
can use the same Client ID value under certain circumstances.
o Rewrote the introduction.
o Rewrote the Use Cases appendix.
-14 -14
o Added software_id and software_version metadata fields o Added software_id and software_version metadata fields
o Added direct references to RFC6750 errors in read/update/delete o Added direct references to RFC6750 errors in read/update/delete
methods methods
-13 -13
o Fixed broken example text in registration request and in delete o Fixed broken example text in registration request and in delete
request request
o Added security discussion of separating clients of different grant o Added security discussion of separating clients of different grant
types types
o Fixed error reference to point to RFC6750 instead of RFC6749 o Fixed error reference to point to RFC6750 instead of RFC6749
o Clarified that servers must respond to all requests to o Clarified that servers must respond to all requests to
configuration endpoint, even if it's just an error code configuration endpoint, even if it's just an error code
o Lowercased all Terms to conform to style used in RFC6750 o Lowercased all Terms to conform to style used in RFC6750
-12 -12
o Improved definition of Initial Access Token o Improved definition of Initial Access Token
o Changed developer registration scenario to have the Initial Access o Changed developer registration scenario to have the Initial Access
Token gotten through a normal OAuth 2.0 flow Token gotten through a normal OAuth 2.0 flow
o Moved non-normative client lifecycle examples to appendix o Moved non-normative client lifecycle examples to appendix
o Marked differentiating between auth servers as out of scope o Marked differentiating between auth servers as out of scope
o Added protocol flow diagram o Added protocol flow diagram
o Added credential rotation discussion o Added credential rotation discussion
o Called out Client Registration Endpoint as an OAuth 2.0 Protected o Called out Client Registration Endpoint as an OAuth 2.0 Protected
Resource Resource
o Cleaned up several pieces of text o Cleaned up several pieces of text
-11 -11
o Added localized text to registration request and response o Added localized text to registration request and response
examples. examples.
o Removed "client_secret_jwt" and "private_key_jwt". o Removed "client_secret_jwt" and "private_key_jwt".
o Clarified "tos_uri" and "policy_uri" definitions. o Clarified "tos_uri" and "policy_uri" definitions.
o Added the OAuth Token Endpoint Authentication Methods registry for o Added the OAuth Token Endpoint Authentication Methods registry for
registering "token_endpoint_auth_method" metadata values. registering "token_endpoint_auth_method" metadata values.
o Removed uses of non-ASCII characters, per RFC formatting rules. o Removed uses of non-ASCII characters, per RFC formatting rules.
o Changed "expires_at" to "client_secret_expires_at" and "issued_at" o Changed "expires_at" to "client_secret_expires_at" and "issued_at"
to "client_id_issued_at" for greater clarity. to "client_id_issued_at" for greater clarity.
o Added explanatory text for different credentials (Initial Access o Added explanatory text for different credentials (Initial Access
Token, Registration Access Token, Client Credentials) and what Token, Registration Access Token, Client Credentials) and what
they're used for. they're used for.
o Added Client Lifecycle discussion and examples. o Added Client Lifecycle discussion and examples.
o Defined Initial Access Token in Terminology section. o Defined Initial Access Token in Terminology section.
-10 -10
o Added language to point out that scope values are service-specific o Added language to point out that scope values are service-specific
o Clarified normative language around client metadata o Clarified normative language around client metadata
o Added extensibility to token_endpoint_auth_method using absolute o Added extensibility to token_endpoint_auth_method using absolute
URIs URIs
o Added security consideration about registering redirect URIs o Added security consideration about registering redirect URIs
o Changed erroneous 403 responses to 401's with notes about token o Changed erroneous 403 responses to 401's with notes about token
handling handling
o Added example for initial registration credential o Added example for initial registration credential
-09 -09
o Added method of internationalization for Client Metadata values o Added method of internationalization for Client Metadata values
o Fixed SAML reference o Fixed SAML reference
-08 -08
o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and o Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and
x509_encryption_uri into a single jwks_uri parameter x509_encryption_uri into a single jwks_uri parameter
o Renamed grant_type to grant_types since it's a plural value o Renamed grant_type to grant_types since it's a plural value
o Formalized name of "OAuth 2.0" throughout document o Formalized name of "OAuth 2.0" throughout document
o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example o Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example
grant types grant types
o Added response_types parameter and explanatory text on its use o Added response_types parameter and explanatory text on its use
with and relationship to grant_types with and relationship to grant_types
-07 -07
o Changed registration_access_url to registration_client_uri o Changed registration_access_url to registration_client_uri
o Fixed missing text in 5.1 o Fixed missing text in 5.1
o Added Pragma: no-cache to examples o Added Pragma: no-cache to examples
o Changed "no such client" error to 403 o Changed "no such client" error to 403
o Renamed Client Registration Access Endpoint to Client o Renamed Client Registration Access Endpoint to Client
Configuration Endpoint Configuration Endpoint
o Changed all the parameter names containing "_url" to instead use o Changed all the parameter names containing "_url" to instead use
"_uri" "_uri"
o Updated example text for forming Client Configuration Endpoint URL o Updated example text for forming Client Configuration Endpoint URL
-06 -06
o Removed secret_rotation as a client-initiated action, including o Removed secret_rotation as a client-initiated action, including
removing client secret rotation endpoint and parameters. removing client secret rotation endpoint and parameters.
o Changed _links structure to single value registration_access_url. o Changed _links structure to single value registration_access_url.
o Collapsed create/update/read responses into client info response. o Collapsed create/update/read responses into client info response.
o Changed return code of create action to 201. o Changed return code of create action to 201.
o Added section to describe suggested generation and composition of o Added section to describe suggested generation and composition of
Client Registration Access URL. Client Registration Access URL.
o Added clarifying text to PUT and POST requests to specify JSON in o Added clarifying text to PUT and POST requests to specify JSON in
the body. the body.
o Added Editor's Note to DELETE operation about its inclusion. o Added Editor's Note to DELETE operation about its inclusion.
o Added Editor's Note to registration_access_url about alternate o Added Editor's Note to registration_access_url about alternate
syntax proposals. syntax proposals.
-05 -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
o split endpoint into three parts o split endpoint into three parts
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-parameter 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
Authors' Addresses Authors' Addresses
Justin Richer (editor) Justin Richer
The MITRE Corporation The MITRE Corporation
Email: jricher@mitre.org Email: jricher@mitre.org
John Bradley
Ping Identity
Email: ve7jtb@ve7jtb.com
Michael B. Jones Michael B. Jones
Microsoft Microsoft
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
John Bradley
Ping Identity
Email: ve7jtb@ve7jtb.com
Maciej Machulak Maciej Machulak
Newcastle University Newcastle University
Email: m.p.machulak@ncl.ac.uk Email: m.p.machulak@ncl.ac.uk
URI: http://ncl.ac.uk/ URI: http://ncl.ac.uk/
 End of changes. 215 change blocks. 
1060 lines changed or deleted 702 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/