One document matched: draft-ietf-oauth-dyn-reg-16.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-oauth-dyn-reg-16"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc tocdepth='3' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc strict='yes' ?>
<?rfc notedraftinprogress='yes' ?>
<front>
<title abbrev="OAuth Dynamic Registration Core">OAuth 2.0 Dynamic Client Registration Core Protocol</title>
<author fullname="Justin Richer" initials="J" surname="Richer">
<organization>The MITRE Corporation</organization>
<address>
<email>jricher@mitre.org</email>
</address>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>ve7jtb@ve7jtb.com</email>
</address>
</author>
<author fullname="Maciej Machulak" initials="M" surname="Machulak">
<organization>Newcastle University</organization>
<address>
<email>m.p.machulak@ncl.ac.uk</email>
<uri>http://ncl.ac.uk/</uri>
</address>
</author>
<author fullname="Phil Hunt" initials="P" surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<date day="6" month="February" year="2014"/>
<area>Security</area>
<workgroup>OAuth Working Group</workgroup>
<abstract>
<t>
This specification defines mechanisms used to dynamically register
OAuth 2.0 clients at authorization servers.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
In order for an OAuth 2.0 client to utilize
an OAuth 2.0 authorization server,
the client needs specific information to interact with the server,
including an OAuth 2.0 Client ID to use at that server.
This specification describes how an OAuth 2.0 client
can be dynamically registered with an authorization server
to obtain this information.
</t>
<t>
As part of the registration process, this specification also defines
a mechanism for the client to present the authorization server with a
set of metadata, such as a set of valid redirection URIs.
This metadata can either be communicated in a self-asserted fashion
or as a set of metadata called a software statement, which can be signed;
in the case of a signed software statement, the signer is vouching for
the validity of the data about the client.
</t>
<t>
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.
</t>
<section anchor="Notation" title="Notational Conventions">
<t>The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
<t>Unless otherwise noted, all the protocol parameter names and values
are case sensitive.</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>
This specification uses the terms "Access Token", "Refresh Token",
"Authorization Code", "Authorization Grant", "Authorization Server",
"Authorization Endpoint", "Client", "Client Identifier", "Client
Secret", "Protected Resource", "Resource Owner", "Resource Server",
"Response Type", and
"Token Endpoint" defined by <xref target="RFC6749">OAuth 2.0</xref>
and uses the term "Claim"
defined by <xref target="JWT">JSON Web Token (JWT)</xref>.
</t>
<t>
This specification defines the following terms:
</t>
<t>
<list style="hanging">
<t hangText="Client Developer">The person or organization that
builds a client software package and prepares it for distribution.
A client developer obtains a software statement from a software
publisher, or self-generates one for the purposes of facilitating
client registration.</t>
<t hangText="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.
</t>
<t hangText="Client Software">
Software implementing an OAuth 2.0 client.
</t>
<t hangText="Client Registration Endpoint">OAuth 2.0 endpoint
through which a client can be registered at an authorization
server. The means by which the URL for this endpoint is obtained
are out of scope for this specification.</t>
<t hangText="Initial Access Token">OAuth 2.0 access token
optionally issued by an Authorization Server and used to authorize
calls to the client registration endpoint. The type and format of
this token are likely service-specific and are out of scope for
this specification. The means by which the authorization server
issues this token as well as the means by which the registration
endpoint validates this token are out of scope for this
specification.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Software API Publisher">The organization that defines
a particular web accessible API that may deployed in one or more
deployment 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 statements
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.</t>
<t hangText="Software Statement">
A JSON Web Token (JWT) <xref target="JWT"/> that asserts
metadata values about the client software.
The JWT MUST be signed and contain an <spanx style="verb">iss</spanx> (issuer)
claim if its metadata values are being attested to by the issuer;
if the metadata values are not being attested to,
the JWT MAY be unsigned.
This can be used by the registration system to
qualify clients for eligibility to register.
It may also be accepted by some authorization servers
directly as a Client ID value, without prior registration.
</t>
</list>
</t>
</section>
<section anchor="ProtocolFlow" title="Protocol Flow">
<figure>
<preamble/>
<artwork><![CDATA[
+--------(A)- Initial Access Token (OPTIONAL)
|
| +----(B)- Software Statement (OPTIONAL)
| |
v v
+-----------+ +---------------+
| |--(C)- Client Registration Request -->| Client |
| Client or | | Registration |
| Developer |<-(D)- Client Information Response ---| Endpoint |
| | +---------------+
+-----------+
]]></artwork>
<postamble>Figure 1: Abstract Dynamic Client Registration Flow</postamble>
</figure>
<t>The abstract OAuth 2.0 client dynamic registration flow illustrated
in Figure 1 describes the interaction between the client or developer
and the endpoint defined in this specification. This figure does not
demonstrate error conditions. This flow includes the following
steps:</t>
<t>
<list style="hanging">
<t hangText="(A)">Optionally, the client
or developer is issued an initial access token giving access to the
client registration endpoint. The method by which the initial
access token is issued to the client or developer is out of scope
for this specification.</t>
<t hangText="(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.
</t>
<t hangText="(C)">The client or developer
calls the client registration endpoint with its desired
registration metadata, optionally including the initial access
token from (A) if one is required by the authorization server.</t>
<t hangText="(D)">The authorization server
registers the client and returns the client's registered metadata,
a client identifier that is unique at the server, a set of client
credentials such as a client secret if applicable for this client,
and possibly other values.</t>
</list>
</t>
</section>
</section>
<section anchor="ClientMetadata" title="Client Metadata">
<t>
Clients have a set of metadata values associated with their
unique client identifier at an authorization server, such as the list
of valid redirect URIs.
</t>
<t>The client metadata values are used in two ways:</t>
<t>
<list style="symbols">
<t>
as input values to registration requests, and
</t>
<t>
as output values in registration responses.
</t>
</list>
</t>
<t>
These client metadata values are defined by this specification:
</t>
<t>
<list style="hanging">
<t hangText="redirect_uris">Array of
redirect URIs for use in redirect-based flows such as the
authorization code and implicit grant types. It is RECOMMENDED that
clients using these flows register this parameter, and an
authorization server SHOULD require registration of valid redirect
URIs for all clients that use these grant types to protect against
token and credential theft attacks.</t>
<t hangText="token_endpoint_auth_method">The
requested authentication method for the token endpoint. Values
defined by this specification are:
<list style="symbols">
<t><spanx style="verb">none</spanx>: The client is a public
client as defined in OAuth 2.0 and does not have a client
secret.</t>
<t><spanx style="verb">client_secret_post</spanx>: The client
uses the HTTP POST parameters defined in OAuth 2.0 section
2.3.1.</t>
<t><spanx style="verb">client_secret_basic</spanx>: the client
uses HTTP Basic defined in OAuth 2.0 section 2.3.1</t>
</list>
Additional values can be defined via the IANA OAuth Token
Endpoint Authentication Methods Registry <xref
target="TEAMRegistry"/>. Absolute URIs can also be used as values
for this parameter without being registered. If unspecified or
omitted, the default is <spanx style="verb">client_secret_basic</spanx>,
denoting HTTP Basic Authentication Scheme as specified in Section
2.3.1 of OAuth 2.0.</t>
<t hangText="grant_types">Array of OAuth 2.0
grant types that the Client may use. These grant types are defined
as follows:
<list style="symbols">
<t><spanx style="verb">authorization_code</spanx>: The
Authorization Code Grant described in OAuth 2.0 Section 4.1</t>
<t><spanx style="verb">implicit</spanx>: The Implicit Grant
described in OAuth 2.0 Section 4.2</t>
<t><spanx style="verb">password</spanx>: The Resource Owner
Password Credentials Grant described in OAuth 2.0 Section
4.3</t>
<t><spanx style="verb">client_credentials</spanx>: The Client
Credentials Grant described in OAuth 2.0 Section 4.4</t>
<t><spanx style="verb">refresh_token</spanx>: The Refresh Token
Grant described in OAuth 2.0 Section 6.</t>
<t><spanx style="verb">urn:ietf:params:oauth:grant-type:jwt-bearer</spanx>:
The JWT Bearer Grant defined in <xref target="OAuth.JWT">OAuth
JWT Bearer Token Profiles</xref>.</t>
<t><spanx style="verb">urn:ietf:params:oauth:grant-type:saml2-bearer</spanx>:
The SAML 2 Bearer Grant defined in <xref
target="OAuth.SAML2">OAuth SAML 2 Bearer Token
Profiles</xref>.</t>
</list>
Authorization Servers MAY allow for other values as defined
in 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 in
the grant type, the value of this parameter MUST be the same as the
value of the <spanx style="verb">grant_type</spanx> parameter passed
to the token endpoint defined in the extension.</t>
<t hangText="response_types">Array of the
OAuth 2.0 response types that the Client may use. These response
types are defined as follows:
<list style="symbols">
<t><spanx style="verb">code</spanx>: The Authorization Code
response described in OAuth 2.0 Section 4.1.</t>
<t><spanx style="verb">token</spanx>: The Implicit response
described in OAuth 2.0 Section 4.2.</t>
</list>
Authorization servers MAY allow for other values as defined
in response type extensions to OAuth 2.0. The extension process is
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 same
as the value of the <spanx style="verb">response_type</spanx>
parameter passed to the authorization endpoint defined in the
extension.</t>
</list>
</t>
<t>
Authorization servers MUST accept all fields in this list.
Extensions and profiles of this specification MAY expand this list.
For instance, the <xref target="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.
</t>
<t>
Client metadata values can either be communicated directly in
the body of a registration request,
as described in <xref target="RegistrationRequest"/>,
or included as claims in a software statement,
as described in <xref target="SoftwareStatement"/>.
If the same client metadata name is present in both locations,
the value in the software statement SHOULD take precedence.
</t>
<section anchor="GrantTypesAndResponseTypes"
title="Relationship between Grant Types and Response Types">
<t>The <spanx style="verb">grant_types</spanx> and <spanx
style="verb">response_types</spanx> values described above are
partially orthogonal, as they refer to arguments passed to different
endpoints in the OAuth protocol. However, they are related in that the
<spanx style="verb">grant_types</spanx> available to a client
influence the <spanx style="verb">response_types</spanx> that the
client is allowed to use, and vice versa. For instance, a <spanx
style="verb">grant_types</spanx> value that includes <spanx
style="verb">authorization_code</spanx> implies a <spanx style="verb">response_types</spanx>
value that includes <spanx style="verb">code</spanx>, as both values
are defined as part of the OAuth 2.0 authorization code grant. As
such, a server supporting these fields SHOULD take steps to ensure
that a client cannot register itself into an inconsistent state.</t>
<t>The correlation between the two fields is listed in the table
below.</t>
<texttable>
<ttcol>grant_types value includes:</ttcol>
<ttcol>response_types value includes:</ttcol>
<c>authorization_code</c>
<c>code</c>
<c>implicit</c>
<c>token</c>
<c>password</c>
<c>(none)</c>
<c>client_credentials</c>
<c>(none)</c>
<c>refresh_token</c>
<c>(none)</c>
<c>urn:ietf:params:oauth:grant-type:jwt-bearer</c>
<c>(none)</c>
<c>urn:ietf:params:oauth:grant-type:saml2-bearer</c>
<c>(none)</c>
</texttable>
<t>Extensions and profiles of this document that introduce new values
to either the <spanx style="verb">grant_types</spanx> or <spanx
style="verb">response_types</spanx> parameter MUST document all
correspondences between these two parameter types.</t>
</section>
</section>
<section anchor="SoftwareStatement" title="Software Statement">
<t>
A Software Statement is a JSON Web Token (JWT)
<xref target="JWT"/> that asserts
metadata values about the client software.
The JWT MUST be signed and contain an <spanx style="verb">iss</spanx> (issuer)
claim if its metadata values are being attested to by the issuer;
if the metadata values are not being attested to,
the JWT MAY be unsigned.
This can be used by the registration system to
qualify clients for eligibility to register.
It may also be accepted by some authorization servers
directly as a Client ID value, without prior registration.
</t>
<t>
To obtain a software statement, a client developer may generate a
client specific JWT, or a client developer may register
with a software API publisher to obtain a software statement.
The statement is typically distributed with all copies of
a client application.
</t>
<t>
The criteria by which authorization servers determine whether to
trust and utilize the information in a software statement is
beyond the scope of this specification.
</t>
<t>
If the authorization server determines that the claims in
a software statement uniquely identify a piece of software,
the same Client ID value MAY be returned for all
dynamic registrations using that software statement.
However, authorization servers MAY alternatively return
a unique Client ID value for each dynamic registration
of a piece of software.
</t>
<t>
In some cases, authorization servers MAY choose to accept
a software statement value directly as a Client ID
in an authorization request,
without a prior dynamic client registration
having been performed.
The circumstances under which an authorization server
would do so, and the specific software statement
characteristics required in this case, are
beyond the scope of this specification.
</t>
</section>
<section anchor="RegistrationEndpoint"
title="Client Registration Endpoint">
<t>The client registration endpoint is an OAuth 2.0 endpoint defined in
this document that is designed to allow a client to be registered with
the authorization server. The client registration endpoint MUST accept
HTTP POST messages with request parameters encoded in the entity body
using the <spanx style="verb">application/json</spanx> format. The
client registration endpoint MUST be protected by a transport-layer
security mechanism, and the server MUST support TLS 1.2 <xref
target="RFC5246">RFC 5246</xref> and/or TLS 1.0 <xref target="RFC2246"/>
and MAY support additional transport-layer mechanisms meeting its
security requirements. When using TLS, the Client MUST perform a TLS/SSL
server certificate check, per <xref target="RFC6125">RFC
6125</xref>.</t>
<t>The client registration endpoint MAY be an OAuth 2.0 protected
resource and accept an initial access token in the form of an <xref
target="RFC6749">OAuth 2.0 </xref> access token to limit registration to
only previously authorized parties. The method by which the initial
access token is obtained by the registrant is generally out-of-band and
is out of scope for this specification. The method by which the initial
access token is verified and validated by the client registration
endpoint is out of scope for this specification.</t>
<t>To support open registration and facilitate wider interoperability,
the client registration endpoint SHOULD allow initial registration
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
otherwise limited to prevent a denial-of-service attack on the client
registration endpoint.</t>
<t>The client registration endpoint MUST ignore all parameters it does
not understand.</t>
<section anchor="RegistrationRequest"
title="Client Registration Request">
<t>This operation registers a new client to the authorization server.
The authorization server assigns this client a unique client
identifier, optionally assigns a client secret, and associates the
metadata given in the request with the issued client identifier. The
request includes any client metadata parameters being specified
for the client during the registration. The authorization
server MAY provision default values for any items omitted in the
client metadata.</t>
<t>
Client metadata values may also be provided in a software statement,
as described in <xref target="SoftwareStatement"/>.
Software statements are included in registration requests
using this registration parameter:
<list style="hanging">
<t hangText="software_statement">
A software statement containing client metadata values
about the client software as claims.
</t>
</list>
</t>
<t>To register, the client or developer sends an HTTP POST to the
client registration endpoint with a content type of <spanx
style="verb">application/json</spanx>. The HTTP Entity Payload is a
<xref target="RFC4627">JSON</xref> document consisting of a JSON
object and all parameters as top-level members of that JSON
object.</t>
<t>For example, if the server supports open registration (with no
initial access token), the client could send the following
registration request to the client registration endpoint:</t>
<figure>
<preamble>
The following is a non-normative example request
not using an initial access token
(with line wraps within values for display purposes only):
</preamble>
<artwork><![CDATA[
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
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"
}
]]></artwork>
</figure>
<t>Alternatively, if the server supports authorized registration, the
developer or the client will be provisioned with an initial access
token (the method by which the initial access token is obtained is out
of scope for this specification). The developer or client sends the
following authorized registration request to the client registration
endpoint. Note that the initial access token sent in this example as
an OAuth 2.0 Bearer Token <xref target="RFC6750"/>, but any OAuth
2.0 token type could be used by an authorization server.</t>
<figure>
<preamble>
The following is a non-normative example request
using an initial access token
(with line wraps within values for display purposes only):
</preamble>
<artwork><![CDATA[
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"
}
]]></artwork>
</figure>
<figure>
<preamble>
In the following example, some registration parameters
are conveyed as claims in a software statement
(with line wraps within values for display purposes only):
</preamble>
<artwork><![CDATA[
POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
{
"redirect_uris":[
"https://client.example.org/callback",
"https://client.example.org/callback2"
],
"software_statement":"eyJhbGciOiJFUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
J9l-ZhwP[...omitted for brevity...]",
"extension_parameter":"foo"
}
]]></artwork>
</figure>
</section>
<section anchor="RegistrationResponse"
title="Client Registration Response">
<t>Upon successful registration, the authorization server generates a
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
server responds with an HTTP 201 Created code and a body of type
<spanx style="verb">application/json</spanx> with content
as described in <xref target="ClientInfoResponse"/>.</t>
<t>Upon an unsuccessful registration, the authorization server
responds with an error,
as described in <xref target="ClientRegistrationError"/>.</t>
</section>
</section>
<section anchor="Responses" title="Responses">
<t>
The following responses are sent in response to registration requests.
</t>
<section anchor="ClientInfoResponse"
title="Client Information Response">
<t>The response contains the client identifier as well as the client
secret, if the client is a confidential client. The response MAY
contain additional fields as specified by extensions to this
specification.</t>
<t>
<list style="hanging">
<t hangText="client_id">
REQUIRED.
Unique client identifier.
It MUST NOT be currently valid for any other distinct registered client.
It MAY be the same as the Client ID value used by other instances of this client,
provided that the Redirection URI values
and potentially other values dictated by authorization server policy
are the same for all instances.
</t>
<t hangText="client_secret">OPTIONAL. The client secret.
If issued, this MUST be unique for each <spanx style="verb">client_id</spanx>.
This value is used by confidential clients to authenticate to the
token endpoint as described in <xref target="RFC6749">OAuth
2.0</xref> Section 2.3.1.</t>
<t hangText="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.</t>
<t hangText="client_secret_expires_at">REQUIRED if <spanx
style="verb">client_secret</spanx> is issued. Time at which the
<spanx style="verb">client_secret</spanx> 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.</t>
</list>
</t>
<t>Additionally, the Authorization Server MUST return all registered
metadata 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.</t>
<t>The response is an <spanx style="verb">application/json</spanx>
document with all parameters as top-level members of a <xref
target="RFC4627">JSON object</xref>.</t>
<t>
If a software statement was used as part of the registration,
its value SHOULD be returned in the response
and its value MUST be returned if the authorization server
supports registration management operations <xref target="OAuth.Registration.Management"/>
that would require its presence in subsequent operations.
Client metadata elements used from the software statement
MUST also be returned directly as top-level
client metadata values in the registration response
(possibly with different values, since the values requested
and the values used may differ).
</t>
<figure>
<preamble>Following is a non-normative example response:</preamble>
<artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"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"
}
]]></artwork>
</figure>
</section>
<section anchor="ClientRegistrationError"
title="Client Registration Error Response">
<t>When an OAuth 2.0 error condition occurs, such as the client
presenting an invalid initial access token, the authorization server
returns an error response appropriate to the OAuth 2.0 token type.</t>
<t>When a registration error condition occurs, the authorization
server returns an HTTP 400 status code (unless otherwise specified)
with content type <spanx style="verb">application/json</spanx>
consisting of a <xref target="RFC4627">JSON object</xref> describing
the error in the response body.</t>
<t>The JSON object contains two members:</t>
<t>
<list style="hanging">
<t hangText="error">Single ASCII error code string.</t>
<t hangText="error_description">Human-readable ASCII text
description of the error used for debugging.</t>
</list>
</t>
<t>This specification defines the following error codes:</t>
<t>
<list style="hanging">
<t hangText="invalid_redirect_uri">The value of one or
more <spanx style="verb">redirect_uris</spanx> is invalid.</t>
<t hangText="invalid_client_metadata">The value of one of
the client metadata 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.</t>
<t hangText="invalid_software_statement">
The software statement presented is invalid.
</t>
<t hangText="unapproved_software_statement">
The software statement presented is not approved
for use with this authorization server.
</t>
</list>
</t>
<figure>
<preamble>Following is a non-normative example of an error response
(with line wraps for display purposes only):</preamble>
<artwork><![CDATA[
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_redirect_uri",
"error_description":"The redirect URI http://sketchy.example.com
is not allowed for this server."
}
]]></artwork>
</figure>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="MetadataRegistry"
title="OAuth Registration Client Metadata Registry">
<t>
This specification establishes
the OAuth Registration Client Metadata registry.
</t>
<t>
OAuth registration client metadata values
are registered with a Specification Required (<xref
target="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.
</t>
<t>Registration requests must be sent to the oauth-ext-review@ietf.org
mailing list for review and comment, with an appropriate subject
(e.g., "Request to register OAuth Registration Client Metadata name:
example").</t>
<t>Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request
successful.</t>
<t>IANA must only accept registry updates from the Designated
Expert(s) and should direct all requests for registration to the
review mailing list.</t>
<section anchor="MetadataTemplate" title="Registration Template">
<t>
<list style="hanging">
<t hangText="Client Metadata Name:">The
name requested (e.g., "example"). This name is case sensitive.
Names that match other registered names in a case insensitive
manner SHOULD NOT be accepted.</t>
<t hangText='Client Metadata Description:'>
<vspace />
Brief description of the metadata value (e.g., "Example description").
</t>
<t hangText="Change controller:">For Standards Track
RFCs, state "IETF". For others, give the name of the responsible
party. Other details (e.g., postal address, email address, home
page URI) may also be included.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section anchor="MetadataContents" title="Initial Registry Contents">
<t>
The initial contents of the OAuth Registration Client Metadata
registry are:
</t>
<t>
<?rfc subcompact="yes"?>
<list style="symbols">
<t>Client Metadata Name: <spanx
style="verb">redirect_uris</spanx></t>
<t>
Client Metadata Description:
Array of redirect URIs for use in redirect-based flows
</t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this document ]]</t>
</list>
</t>
<t>
<list style="symbols">
<t>Client Metadata Name: <spanx
style="verb">token_endpoint_auth_method</spanx></t>
<t>
Client Metadata Description:
Requested authentication method for the token endpoint
</t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this document ]]</t>
</list>
</t>
<t>
<list style="symbols">
<t>Client Metadata Name: <spanx
style="verb">grant_types</spanx></t>
<t>
Client Metadata Description:
Array of OAuth 2.0 grant types that the Client may use
</t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this document ]]</t>
</list>
</t>
<t>
<list style="symbols">
<t>Client Metadata Name: <spanx
style="verb">response_types</spanx></t>
<t>
Client Metadata Description:
Array of the OAuth 2.0 response types that the Client may use
</t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this document ]]</t>
</list>
</t>
</section>
<?rfc subcompact="no"?>
</section>
<section anchor="TEAMRegistry"
title="OAuth Token Endpoint Authentication Methods Registry">
<t>This specification establishes the OAuth Token Endpoint
Authentication Methods registry.</t>
<t>Additional values for use as <spanx style="verb">token_endpoint_auth_method</spanx>
metadata values are registered with a Specification Required (<xref
target="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.</t>
<t>Registration requests must be sent to the oauth-ext-review@ietf.org
mailing list for review and comment, with an appropriate subject
(e.g., "Request to register token_endpoint_auth_method value:
example").</t>
<t>Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request
successful.</t>
<t>IANA must only accept registry updates from the Designated
Expert(s) and should direct all requests for registration to the
review mailing list.</t>
<section anchor="TEAMTemplate" title="Registration Template">
<t>
<list style="hanging">
<t
hangText="Token Endpoint Authorization Method Name:">The
name requested (e.g., "example"). This name is case sensitive.
Names that match other registered names in a case insensitive
manner SHOULD NOT be accepted.</t>
<t hangText="Change controller:">For Standards Track
RFCs, state "IETF". For others, give the name of the responsible
party. Other details (e.g., postal address, email address, home
page URI) may also be included.</t>
<t hangText="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.</t>
</list>
</t>
</section>
<section anchor="TEAMContents" title="Initial Registry Contents">
<t>
The initial contents of the OAuth Token Endpoint Authentication Methods
registry are:
</t>
<t>
<?rfc subcompact="yes"?>
<list style="symbols">
<t>Token Endpoint Authorization Method Name: <spanx
style="verb">none</spanx></t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this document ]]</t>
</list>
</t>
<t>
<list style="symbols">
<t>Token Endpoint Authorization Method Name: <spanx
style="verb">client_secret_post</spanx></t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this document ]]</t>
</list>
</t>
<t>
<list style="symbols">
<t>Token Endpoint Authorization Method Name: <spanx
style="verb">client_secret_basic</spanx></t>
<t>Change controller: IESG</t>
<t>Specification document(s): [[ this document ]]</t>
</list>
</t>
</section>
<?rfc subcompact="no"?>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>Since requests to the client registration endpoint result in the
transmission of clear-text credentials (in the HTTP request and
response), the Authorization Server MUST require the use of a
transport-layer security mechanism when sending requests to the
registration endpoint. The server MUST support TLS 1.2 <xref
target="RFC5246">RFC 5246</xref> and/or TLS 1.0 <xref target="RFC2246"/>
and MAY support additional transport-layer mechanisms meeting its
security requirements. When using TLS, the Client MUST perform a TLS/SSL
server certificate check, per <xref target="RFC6125">RFC
6125</xref>.</t>
<t>For clients that use redirect-based grant types such as <spanx
style="verb">authorization_code</spanx> and <spanx style="verb">implicit</spanx>,
authorization servers SHOULD require clients to register their <spanx
style="verb">redirect_uris</spanx>. Requiring clients to do so can help
mitigate attacks where rogue actors inject and impersonate a validly
registered client and intercept its authorization code or tokens through
an invalid redirect URI.</t>
<t>Public clients MAY register with an authorization server using this
protocol, if the authorization server's policy allows them. Public
clients use a <spanx style="verb">none</spanx> value for the <spanx
style="verb">token_endpoint_auth_method</spanx> metadata field and are
generally used with the <spanx style="verb">implicit</spanx> grant type.
Often these clients will be short-lived in-browser applications
requesting access to a user's resources and access is tied to a user's
active session at the authorization server. Since 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 is loaded.
Additionally, such clients may not have ample opportunity to unregister
themselves using the delete action before the browser closes. To avoid
the resulting proliferation of dead client identifiers, an authorization
server MAY decide to expire registrations for existing clients meeting
certain criteria after a period of time has elapsed.</t>
<t>Since different OAuth 2.0 grant types have different security and
usage parameters, an authorization server MAY require separate
registrations for a piece of software to support multiple grant types.
For instance, an authorization server might require that all clients
using the <spanx style="verb">authorization_code</spanx> grant type make
use of a client secret for the <spanx style="verb">token_endpoint_auth_method</spanx>,
but any clients using the <spanx style="verb">implicit</spanx> grant
type do not use any authentication at the token endpoint. In such a
situation, a server MAY disallow clients from registering for both the
<spanx style="verb">authorization_code</spanx> and <spanx style="verb">implicit</spanx>
grant types simultaneously. Similarly, the <spanx style="verb">authorization_code</spanx>
grant type is used to represent access on behalf of an end user, but the
<spanx style="verb">client_credentials</spanx> grant type represents
access on behalf of the client itself. For security reasons, an
authorization server could require that different scopes be used for
these different use cases, and as a consequence it MAY disallow these
two grant types from being registered together by the same client. In
all of these cases, the authorization server would respond with an
<spanx style="verb">invalid_client_metadata</spanx> error response.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.6750.xml'?>
<reference anchor="JWT">
<front>
<title>JSON Web Token (JWT)</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>ve7jtb@ve7jtb.com</email>
<uri>http://www.thread-safe.com/</uri>
</address>
</author>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute</organization>
<address>
<email>n-sakimura@nri.co.jp</email>
<uri>http://nat.sakimura.org/</uri>
</address>
</author>
<date day="20" month="January" year="2014" />
</front>
<seriesInfo value="draft-ietf-oauth-json-web-token" name="Internet-Draft"/>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token" type="HTML" />
</reference>
<reference anchor="OAuth.JWT">
<front>
<title abbrev="OAuth JWT Assertion Profiles">JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Michael B. Jones" surname="Jones" initials="M.B."> <!-- role="editor" -->
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>brian.d.campbell@gmail.com</email>
</address>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="Salesforce">Salesforce</organization>
<address>
<email>cmortimore@salesforce.com</email>
</address>
</author>
<date day="" month="December" year="2013" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-oauth-jwt-bearer"/>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer"
type="HTML"/>
</reference>
<reference anchor="OAuth.SAML2">
<front>
<title abbrev="OAuth SAML Assertion Profiles">SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Brian Campbell" initials="B." surname="Campbell">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>brian.d.campbell@gmail.com</email>
</address>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="Salesforce">Salesforce.com</organization>
<address>
<email>cmortimore@salesforce.com</email>
</address>
</author>
<author fullname="Michael B. Jones" surname="Jones" initials="M.B.">
<organization>Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<date day="9" month="December" year="2013" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-oauth-saml2-bearer"/>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer"
type="HTML"/>
</reference>
<reference anchor="OAuth.Registration.Management">
<front>
<title abbrev="OAuth Dynamic Registration Management">OAuth 2.0 Dynamic Client Registration Management Protocol</title>
<author fullname="Justin Richer" initials="J" surname="Richer">
<organization>The MITRE Corporation</organization>
<address>
<email>jricher@mitre.org</email>
</address>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>ve7jtb@ve7jtb.com</email>
</address>
</author>
<author fullname="Maciej Machulak" initials="M" surname="Machulak">
<organization>Newcastle University</organization>
<address>
<email>m.p.machulak@ncl.ac.uk</email>
<uri>http://ncl.ac.uk/</uri>
</address>
</author>
<author fullname="Phil Hunt" initials="P" surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<date day="6" month="February" year="2014"/>
</front>
<seriesInfo value="draft-ietf-oauth-dyn-reg-management" name="Internet-Draft"/>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management" type="HTML" />
</reference>
</references>
<references title="Informative References">
<reference anchor="OAuth.Registration.Metadata">
<front>
<title abbrev="OAuth Dynamic Registration Metadata">OAuth 2.0 Dynamic Client Registration Metadata</title>
<author fullname="Justin Richer" initials="J" surname="Richer">
<organization>The MITRE Corporation</organization>
<address>
<email>jricher@mitre.org</email>
</address>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri>
</address>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
<address>
<email>ve7jtb@ve7jtb.com</email>
</address>
</author>
<author fullname="Maciej Machulak" initials="M" surname="Machulak">
<organization>Newcastle University</organization>
<address>
<email>m.p.machulak@ncl.ac.uk</email>
<uri>http://ncl.ac.uk/</uri>
</address>
</author>
<author fullname="Phil Hunt" initials="P" surname="Hunt">
<organization>Oracle Corporation</organization>
<address>
<email>phil.hunt@yahoo.com</email>
</address>
</author>
<date day="6" month="February" year="2014"/>
</front>
<seriesInfo value="draft-ietf-oauth-dyn-reg-metadata" name="Internet-Draft"/>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata" type="HTML" />
</reference>
</references>
<section anchor="UseCases" title="Use Cases">
<t>
This appendix describes different ways that this specification
can be utilized,
including describing some of the choices that may need to be made.
Some of the choices are independent and can be used in combination,
whereas some of the choices are interrelated.
</t>
<section anchor="OpenOrProtected" title="Open versus Protected Dynamic Client Registration">
<section anchor="OpenRegistration" title="Open Dynamic Client Registration">
<t>
Authorization servers that support open registration allow registrations
to be made with no initial access token.
This allows all client software to register with the authorization server.
</t>
</section>
<section anchor="ProtectedRegistration" title="Protected Dynamic Client Registration">
<t>
Authorization servers that support protected registration
require that an initial access token be used
when making registration requests.
While the method by which a client or developer
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.
</t>
</section>
</section>
<section anchor="SoftwareStatementUses" title="Registration Without or With Software Statements">
<section anchor="NoSoftwareStatement" title="Registration Without a Software Statement">
<t>
When a software statement is not used in the registration request,
the authorization server must be willing to use
client metadata values without them being
signed (and thereby attested to) by any authority.
(Note that this choice is independent of the Open versus Protected choice,
and that an initial access token is another possible form of attestation.)
</t>
</section>
<section anchor="WithSoftwareStatement" title="Registration With a Software Statement">
<t>
A software statement can be used in a registration request
to provide attestation for a set of client metadata values
for a piece of client software by an authority.
This can be useful when the authorization server
wants to restrict registration to client software
attested to by a set of authorities
or when it wants to know that multiple registration
requests refer to the same piece of client software.
</t>
</section>
</section>
<section anchor="ByClientOrDeveloper" title="Registration by the Client or the Developer">
<section anchor="ByClient" title="Registration by the Client">
<t>
In some use cases, client software will dynamically register itself
with an authorization server to obtain a Client ID and other
information needed to interact with the authorization server.
In this case, no Client ID for the authorization server is packaged
with the client software.
</t>
</section>
<section anchor="ByDeveloper" title="Registration by the Developer">
<t>
In some cases, the developer
(or development software being used by the developer)
will pre-register the client software with
the authorization server or a set of authorization servers.
In this case, the Client ID value(s) for
the authorization server(s) can be packaged
with the client software.
</t>
</section>
</section>
<section anchor="IDPerInstanceOrSoftware" title="Client ID per Client Instance or per Client Software">
<section anchor="IDPerInstance" title="Client ID per Client Software Instance">
<t>
In some cases, each deployed instance of a piece of client software
will dynamically register and obtain distinct Client ID values.
This can be advantageous, for instance, if the code flow is being used,
as it also enables each client instance to have its own client secret.
This can be useful for native clients, which cannot maintain
the secrecy of a client secret value packaged with the software,
but which may be able to maintain the secrecy of
a per-instance client secret.
</t>
</section>
<section anchor="SharedID" title="Client ID Shared between all Instances of Client Software">
<t>
In some cases, each deployed instance of a piece of client software
will share a common Client ID value.
For instance, this is often the case for native client using
implicit flow, when no client secret is involved.
Particular authorization servers might choose, for instance,
to maintain a mapping between software statement values and
Client ID values, and return the same Client ID value
for all registration requests for a particular piece of software.
The circumstances under which an authorization server
would do so, and the specific software statement
characteristics required in this case, are
beyond the scope of this specification.
</t>
</section>
</section>
<section anchor="StatefulOrStateless" title="Stateful or Stateless Registration">
<section anchor="Stateful" title="Stateful Client Registration">
<t>
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 <xref target="OAuth.Registration.Management"/> specification.
</t>
</section>
<section anchor="Stateless" title="Stateless Client Registration">
<t>
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.
</t>
</section>
</section>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>
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.
</t>
</section>
<section anchor="History" title="Document History">
<t>[[ to be removed by the RFC editor before publication as an RFC ]]</t>
<t>
-16
<list style="symbols">
<t>
Replaced references to draft-jones-oauth-dyn-reg-metadata and draft-jones-oauth-dyn-reg-management
with draft-ietf-oauth-dyn-reg-metadata and draft-ietf-oauth-dyn-reg-management.
</t>
<t>
Addressed review comments by Phil Hunt and Tony Nadalin.
</t>
</list>
</t>
<t>
-15
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
<t>
Created the IANA
OAuth Registration Client Metadata registry
for registering Client Metadata values.
</t>
<t>
Defined Client Instance term and stated that
multiple instances can use the same Client ID value
under certain circumstances.
</t>
<t>
Rewrote the introduction.
</t>
<t>
Rewrote the Use Cases appendix.
</t>
</list>
</t>
<t>-14</t>
<t><list style="symbols">
<t>Added software_id and software_version metadata fields</t>
<t>Added direct references to RFC6750 errors in read/update/delete
methods</t>
</list></t>
<t>-13</t>
<t><list style="symbols">
<t>Fixed broken example text in registration request and in delete
request</t>
<t>Added security discussion of separating clients of different
grant types</t>
<t>Fixed error reference to point to RFC6750 instead of RFC6749</t>
<t>Clarified that servers must respond to all requests to
configuration endpoint, even if it's just an error code</t>
<t>Lowercased all Terms to conform to style used in RFC6750</t>
</list></t>
<t>-12</t>
<t><list style="symbols">
<t>Improved definition of Initial Access Token</t>
<t>Changed developer registration scenario to have the Initial
Access Token gotten through a normal OAuth 2.0 flow</t>
<t>Moved non-normative client lifecycle examples to appendix</t>
<t>Marked differentiating between auth servers as out of scope</t>
<t>Added protocol flow diagram</t>
<t>Added credential rotation discussion</t>
<t>Called out Client Registration Endpoint as an OAuth 2.0 Protected
Resource</t>
<t>Cleaned up several pieces of text</t>
</list></t>
<t>-11</t>
<t><list style="symbols">
<t>Added localized text to registration request and response
examples.</t>
<t>Removed <spanx style="verb">client_secret_jwt</spanx> and <spanx
style="verb">private_key_jwt</spanx>.</t>
<t>Clarified <spanx style="verb">tos_uri</spanx> and <spanx
style="verb">policy_uri</spanx> definitions.</t>
<t>Added the OAuth Token Endpoint Authentication Methods registry
for registering <spanx style="verb">token_endpoint_auth_method</spanx>
metadata values.</t>
<t>Removed uses of non-ASCII characters, per RFC formatting
rules.</t>
<t>Changed <spanx style="verb">expires_at</spanx> to <spanx
style="verb">client_secret_expires_at</spanx> and <spanx
style="verb">issued_at</spanx> to <spanx style="verb">client_id_issued_at</spanx>
for greater clarity.</t>
<t>Added explanatory text for different credentials (Initial Access
Token, Registration Access Token, Client Credentials) and what
they're used for.</t>
<t>Added Client Lifecycle discussion and examples.</t>
<t>Defined Initial Access Token in Terminology section.</t>
</list></t>
<t>-10</t>
<t><list style="symbols">
<t>Added language to point out that scope values are
service-specific</t>
<t>Clarified normative language around client metadata</t>
<t>Added extensibility to token_endpoint_auth_method using absolute
URIs</t>
<t>Added security consideration about registering redirect URIs</t>
<t>Changed erroneous 403 responses to 401's with notes about token
handling</t>
<t>Added example for initial registration credential</t>
</list></t>
<t>-09</t>
<t><list style="symbols">
<t>Added method of internationalization for Client Metadata
values</t>
<t>Fixed SAML reference</t>
</list></t>
<t>-08</t>
<t><list style="symbols">
<t>Collapsed jwk_uri, jwk_encryption_uri, x509_uri, and
x509_encryption_uri into a single jwks_uri parameter</t>
<t>Renamed grant_type to grant_types since it's a plural value</t>
<t>Formalized name of "OAuth 2.0" throughout document</t>
<t>Added JWT Bearer Assertion and SAML 2 Bearer Assertion to example
grant types</t>
<t>Added response_types parameter and explanatory text on its use
with and relationship to grant_types</t>
</list></t>
<t>-07</t>
<t><list style="symbols">
<t>Changed registration_access_url to registration_client_uri</t>
<t>Fixed missing text in 5.1</t>
<t>Added Pragma: no-cache to examples</t>
<t>Changed "no such client" error to 403</t>
<t>Renamed Client Registration Access Endpoint to Client
Configuration Endpoint</t>
<t>Changed all the parameter names containing "_url" to instead use
"_uri"</t>
<t>Updated example text for forming Client Configuration Endpoint
URL</t>
</list></t>
<t>-06</t>
<t><list style="symbols">
<t>Removed secret_rotation as a client-initiated action, including
removing client secret rotation endpoint and parameters.</t>
<t>Changed _links structure to single value
registration_access_url.</t>
<t>Collapsed create/update/read responses into client info
response.</t>
<t>Changed return code of create action to 201.</t>
<t>Added section to describe suggested generation and composition of
Client Registration Access URL.</t>
<t>Added clarifying text to PUT and POST requests to specify JSON in
the body.</t>
<t>Added Editor's Note to DELETE operation about its inclusion.</t>
<t>Added Editor's Note to registration_access_url about alternate
syntax proposals.</t>
</list></t>
<t>-05</t>
<t><list style="symbols">
<t>changed redirect_uri and contact to lists instead of space
delimited strings</t>
<t>removed operation parameter</t>
<t>added _links structure</t>
<t>made client update management more RESTful</t>
<t>split endpoint into three parts</t>
<t>changed input to JSON from form-encoded</t>
<t>added READ and DELETE operations</t>
<t>removed Requirements section</t>
<t>changed token_endpoint_auth_type back to
token_endpoint_auth_method to match OIDC who changed to match us</t>
</list></t>
<t>-04</t>
<t><list style="symbols">
<t>removed default_acr, too undefined in the general OAuth2 case</t>
<t>removed default_max_auth_age, since there's no mechanism for
supplying a non-default max_auth_age in OAuth2</t>
<t>clarified signing and encryption URLs</t>
<t>changed token_endpoint_auth_method to token_endpoint_auth_type to
match OIDC</t>
</list></t>
<t>-03</t>
<t><list style="symbols">
<t>added scope and grant_type claims</t>
<t>fixed various typos and changed wording for better clarity</t>
<t>endpoint now returns the full set of client information</t>
<t>operations on client_update allow for three actions on metadata:
leave existing value, clear existing value, replace existing value
with new value</t>
</list></t>
<t>-02</t>
<t><list style="symbols">
<t>Reorganized contributors and references</t>
<t>Moved OAuth references to RFC</t>
<t>Reorganized model/protocol sections for clarity</t>
<t>Changed terminology to "client register" instead of "client
associate"</t>
<t>Specified that client_id must match across all subsequent
requests</t>
<t>Fixed RFC2XML formatting, especially on lists</t>
</list></t>
<t>-01</t>
<t><list style="symbols">
<t>Merged UMA and OpenID Connect registrations into a single
document</t>
<t>Changed to form-parameter inputs to endpoint</t>
<t>Removed pull-based registration</t>
</list></t>
<t>-00</t>
<t><list style="symbols">
<t>Imported original UMA draft specification</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:52:12 |