One document matched: draft-ietf-oauth-dyn-reg-01.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-01" 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='no' ?>
<?rfc notedraftinprogress='yes' ?>
<front>
<title abbrev="oauth-dyn-reg">OAuth Dynamic Client Registration
Protocol</title>
<author fullname="Justin Richer" initials="J" role="editor"
surname="Richer">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>jricher@mitre.org</email>
<uri></uri>
</address>
</author>
<author fullname="Thomas Hardjono" initials="T" surname="Hardjono">
<organization>MIT</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>hardjono@mit.edu</email>
<uri></uri>
</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="Eve Maler" initials="E" surname="Maler">
<organization>XMLgrrl.com</organization>
<address>
<email>eve@xmlgrrl.com</email>
<uri>http://www.xmlgrrl.com</uri>
</address>
</author>
<author fullname="Christian Scholz" initials="C" surname="Scholz">
<organization>COM.lounge GmbH</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.</organization>
<address>
<email>n-sakimura@nri.co.jp</email>
</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="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
<address>
<email>mbj@microsoft.com</email>
</address>
</author>
<date day="5" month="November" year="2012" />
<abstract>
<t>This specification proposes an OAuth Dynamic Client Registration
protocol.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In some use-case scenarios, it is desirable or necessary to allow
OAuth clients to obtain authorization from an OAuth authorization server
without the two parties having previously interacted. Nevertheless, in
order for the authorization server to accurately represent to end-users
which client is seeking authorization to access the end-user's
resources, a method for automatic and unique registration of clients is
needed. The OAuth2 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
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.</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 meta information, such as a display name and icon to be presented
to the user during the authorization step. This draft provides a method
for the client to register and update this information over time.</t>
<section 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"></xref>.</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",
and "Token Endpoint" defined by <xref target="OAuth2.0">OAuth
2.0</xref>.</t>
<t>This specification defines the following additional terms:</t>
<t><list style="symbols">
<t>Client Registration Endpoint: The OAuth 2.0 Endpoint through
which a Client can request new registration and manage the
metadata associated with it.</t>
<t>Registration Access Token: An OAuth 2.0 Bearer Token issued by
the Authorization Server through the Client Registration Endpoint
which is used by the Client to authenticate itself during update
and secret rotation operations.</t>
</list></t>
</section>
<section title="Requirements">
<t>[[ Following are proposed requirements for dynamic client
registration. This section is intended for discussion and will likely
be removed in the final draft. ]]</t>
<section title="The client needs to be uniquely identifiable by the authorization server">
<t>In order for an authorization server to do proper user-delegated
authorization and prevent unauthorized access it must be able to
identify clients uniquely. As is done today in OAuth, the client
identifier (and optional secret) should thus be issued by the
authorization server and not simply accepted as proposed by the
client.</t>
</section>
<section title="The authorization server must collect metadata about a client for later user interaction">
<t>In order for the authorization server to describe a client to an
end-user in an authorization step it needs information about the
client. This can be the client name at a minimum, but today servers
usually request at least a description, a homepage URL, and an icon
when doing manual registration.</t>
</section>
<section title="The authorization server should have the option of strongly authenticating the client and its metadata">
<t>In order to prevent spoofing of clients and enable dynamic
building of strong trust relationships, the authorization server
should have the option to verify the provided information. This
might be solved using message signature verification.</t>
</section>
<section title="Dynamic client registration must be possible from both web-server applications and applications with other capabilities and limitations, such as native applications">
<t>Each instance of a native application (that is, the specific
instance running on each device) that is installed and run by the
same user may need the option of getting a unique client identifier.
In this case, there are implications around gathering and displaying
enough information to ensure that the end-user is delegating
authorization to the intended application. The registration protocol
should be simple and flexible enough to allow for multiple types of
applications.</t>
</section>
<section title="Transaction integrity must be ensured">
<t>When a client sends information to a server endpoint, it might
take time for this data to propagate through big server
installations that spread across various data centers. Care needs to
be taken that subsequent interactions with the user after the
registration process, such as an authorization request, show the
correct data.</t>
</section>
</section>
</section>
<section 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 register itself 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/x-www-form-urlencoded</spanx>
format. The Client Registration Endpoint MUST be protected by 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"></xref> 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 Endpoint defines three operations that a client can take on it,
switched by the "operation" parameter:</t>
<t><list style="symbols">
<t>client_associate: generate a new Client Identifier (and
optionally a Client Secret) and associate it with the set of
presented <xref target="client-metadata">metadata</xref></t>
<t>client_update: update the <xref
target="client-metadata">metadata</xref> associated with a Client
Identifier</t>
<t>rotate_secret: issue a new Registration Access Token and, if
applicable, a Client Secret for a Client</t>
</list></t>
<t>In order to facilitate registered clients updating their information,
the Client Registration Endpoint issues a request_access_token for
clients to securely identify themselves in future connections. As such,
the Endpoint MUST accept requests with <xref target="OAuth.Bearer">OAuth
2.0 Bearer Tokens</xref> for these operations. </t>
<t>In order to support open registration and facilitate wider
interoperability, the Client Registration Endpoint SHOULD allow
client_associate requests with no further authentication. These requests
MAY be rate-limited to prevent a denial-of-service attack on the Client
Registration Endpoint.</t>
<t>In addition, the Client Registration Endpoint MAY accept an initial
authorization credential in the form of an <xref target="OAuth2.0">OAuth
2.0 </xref> access token in order to limit registration to only
previously authorized parties. The method by which this access token is
obtained by the registrant is generally out-of-band and is out of scope
of this specification.</t>
<t>These two aspects, operation selection and client authentication, are
represented by two parameters common to all operations:</t>
<t><list style="hanging">
<t hangText="operation">REQUIRED. Values are <spanx style="verb">client_associate</spanx>
(for new registrations), <spanx style="verb">rotate_secret</spanx>
to request rotation of the <spanx style="verb">client_secret</spanx>,
and <spanx style="verb">client_update</spanx> (for updating
parameters of an existing <spanx style="verb">client_id</spanx>).</t>
<t hangText="access_token">OPTIONAL. An OAuth2 Bearer token used to
access the Client Registration Endpoint, as defined in OAuth2
Bearer. This parameter MUST NOT be sent if the Access Token is sent
in the HTTP Authorization header as described in Section 7.1 of
<xref target="OAuth2.0">OAuth 2.0</xref>. Access Tokens sent in the
authorization header must be <xref target="OAuth.Bearer">OAuth 2.0
Bearer Tokens</xref>.</t>
</list>Each operation takes a different parameter set, and all
operations are described below.</t>
<t>The Client Registration Endpoint MUST ignore all parameters it does
not understand.</t>
<section title="Client Association 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 the two parameters described above as well as any
parameters described in <xref target="client-metadata">Client
Metadata</xref>.</t>
<t><list style="hanging">
<t hangText="operation">REQUIRED, MUST have the value <spanx
style="verb">client_associate</spanx></t>
<t hangText="access_token">OPTIONAL, used to restrict new client
registration</t>
<t hangText="redirect_uris"><vspace blankLines="0" />REQUIRED </t>
<t hangText="client_name">RECOMMENDED</t>
<t hangText="client_url"><vspace />RECOMMENDED</t>
<t hangText="logo_url">OPTIONAL</t>
<t hangText="contacts">OPTIONAL</t>
<t hangText="tos_url">OPTIONAL</t>
<t hangText="token_endpoint_auth_method">OPTIONAL</t>
<t hangText="policy_url">OPTIONAL</t>
<t hangText="jwk_url">OPTIONAL</t>
<t hangText="jwk_encryption_url">OPTIONAL</t>
<t hangText="x509_url">OPTIONAL</t>
<t hangText="x509_encryption_url">OPTIONAL</t>
<t hangText="require_signed_request_object">OPTIONAL</t>
<t hangText="default_max_age">OPTIONAL</t>
<t hangText="default_acr">OPTIONAL</t>
</list>For example, a client could send the following registration
request to the Client Registration Endpoint:<figure>
<preamble>Following is a non-normative example request (with line
wraps for display purposes only):</preamble>
<artwork><![CDATA[POST /register HTTP/1.1
Accept: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X
operation=client_associate
&redirect_uris=https://client.example.org/callback
%20https://client.example.org/callback2
&client_name=My%20Example%20
&logo_url=https://client.example.org/logo.png
&token_endpoint_auth_type=client_secret_basic
&jwk_url=https://client.example.org/my_rsa_public_key.jwk
]]></artwork>
</figure></t>
</section>
<section title="Client Association Response">
<t>Upon successful association, the Client Registration Endpoint
returns the newly-created Client Identifier and, optionally, a Client
Secret. The response also contains a Registration Access Token that is
to be used by the client to perform subsequent operations at this
endpoint. These items are returned as a JSON document with the
following fields as top-level members of the root JSON object.</t>
<t><list style="hanging">
<t hangText="client_id">REQUIRED. The unique Client identifier,
MUST NOT be currently valid for any other registered Client.</t>
<t hangText="client_secret">OPTIONAL. The Client secret. This MUST
be unique for each <spanx style="verb">client_id</spanx>. This
value us used by confidential clients. It is not required for
clients selecting a token_endpoint_auth_type of <spanx
style="verb">private_key_jwt</spanx></t>
<t hangText="registration_access_token">REQUIRED The Access token
to be used by the client to perform <spanx style="verb">client_update</spanx>
and <spanx style="verb">rotate_secret</spanx> requests.</t>
<t hangText="issued_at"><vspace />OPTIONAL. Specifies the
timestamp when the identifier was issued. The timestamp value MUST
be a positive integer. The value is expressed in the number of
seconds since January 1, 1970 00:00:00 GMT.</t>
<t hangText="expires_at">OPTIONAL. The number of seconds from
1970-01-01T0:0:0Z as measured in UTC that the <spanx style="verb">client_secret</spanx>
will expire or <spanx style="verb">0</spanx> if they do not
expire. See <xref target="RFC3339">RFC 3339</xref> for details
regarding date/times in general and UTC in particular.</t>
</list></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
{
"client_id":"s6BhdRkqt3",
"client_secret":
"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d",
"registration_access_token": "this.is.a.access.token.value.ffx83",
"expires_at":2893276800
}]]></artwork>
</figure>
</section>
<section title="Client Update Request">
<t>This operation updates a previously-registered client with new
metadata at the Authorization Server. This request MUST be protected
by the Registration Authorization Token associated with the Client
Identifier. This request MAY include any fields described in <xref
target="client-metadata">Client Metadata</xref>. The values of Client
Metadata fields in this request MUST replace (not augment) the values
previously associated with this client_identifier. Empty values in
Client Metadata SHOULD be taken as a request to clear any existing
value of that field.</t>
<t><list style="hanging">
<t hangText="operation">REQUIRED, MUST have the value <spanx
style="verb">client_update</spanx></t>
<t hangText="access_token">REQUIRED, unless presented in the
Authorization Header as in <xref target="OAuth.Bearer">OAuth2
Bearer</xref>. The Registration Access Token that was issued
during the client_associate step, or previous client_update or
rotate_secret calls.</t>
<t hangText="redirect_uris"><vspace blankLines="0" />REQUIRED</t>
<t hangText="client_name">RECOMMENDED</t>
<t hangText="client_url"><vspace />RECOMMENDED</t>
<t hangText="logo_url">OPTIONAL</t>
<t hangText="contacts">OPTIONAL</t>
<t hangText="tos_url">OPTIONAL</t>
<t hangText="token_endpoint_auth_method">OPTIONAL</t>
<t hangText="policy_url">OPTIONAL</t>
<t hangText="jwk_url">OPTIONAL</t>
<t hangText="jwk_encryption_url">OPTIONAL</t>
<t hangText="x509_url">OPTIONAL</t>
<t hangText="x509_encryption_url">OPTIONAL</t>
<t hangText="require_signed_request_object">OPTIONAL</t>
<t hangText="default_max_age">OPTIONAL</t>
<t hangText="default_acr">OPTIONAL</t>
</list>For example, a client could send the following registration
request to the Client Registration Endpoint:<figure>
<preamble>Following is a non-normative example request (with line
wraps for display purposes only):</preamble>
<artwork><![CDATA[POST /register HTTP/1.1
Accept: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X
operation=client_update
&redirect_uris=https://client.example.org/callback
%20https://client.example.org/callback2
&client_name=My%20Example%20
&logo_url=https://client.example.org/logo.png
&token_endpoint_auth_type=client_secret_basic
&jwk_url=https://client.example.org/my_rsa_public_key.jwk
]]></artwork>
</figure></t>
</section>
<section title="Client Update Response">
<t>Upon successful update, the Client Registration Endpoint returns a
JSON document with the following fields as top-level members of the
root JSON object.<list style="hanging">
<t hangText="client_id">REQUIRED. The unique Client identifier,
MUST NOT be currently valid for any other registered Client.</t>
</list></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
{
"client_id":"s6BhdRkqt3",
}]]></artwork>
</figure>
<t>[[ Editor's note: should this return the entire client data object,
for confirmation and review, including any fields that may have been
asserted by the AS? ]]</t>
</section>
<section title="Rotate Secret Request">
<t>This operation allows the client to rotate its current Client
Secret, if it has one. If the client has not been issued a Client
Secret, this operation is an error. [[ Editor's note: could this
request be used to rotate the Registration Access Token, even when
there's not a client_secret? Should something else be used to rotate
the token independently? This is an open issue. ]]</t>
<t><list style="hanging">
<t hangText="operation">REQUIRED. MUST have the value
rotate_secret</t>
<t hangText="access_token">REQUIRED. The Registration Access Token
that was issued during the client_associate step, or previous
client_update or rotate_secret calls.</t>
</list><figure>
<preamble>Following is a non-normative example request (with line
wraps for display purposes only):</preamble>
<artwork><![CDATA[POST /register HTTP/1.1
Accept: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ... fQ.8Gj_-sj ... _X
operation=rotate_secret
]]></artwork>
</figure></t>
</section>
<section title="Rotate Secret Response">
<t>Upon successful rotation of the client secret, the Client
Registration Endpoint returns a JSON document with the following
fields as top-level members of the root JSON object.<list
style="hanging">
<t hangText="client_id">REQUIRED. The unique Client identifier,
MUST NOT be currently valid for any other registered Client.</t>
<t hangText="client_secret">REQUIRED. The Client secret. This MUST
be unique for each <spanx style="verb">client_id</spanx>.</t>
<t hangText="registration_access_token">REQUIRED The Access token
to be used by the client to perform subsequent <spanx
style="verb">client_update</spanx> and <spanx style="verb">rotate_secret</spanx>
requests.</t>
<t hangText="issued_at"><vspace />OPTIONAL. Specifies the
timestamp when the identifier was issued. The timestamp value MUST
be a positive integer. The value is expressed in the number of
seconds since January 1, 1970 00:00:00 GMT.</t>
<t hangText="expires_at">OPTIONAL. The number of seconds from
1970-01-01T0:0:0Z as measured in UTC that the <spanx style="verb">client_secret</spanx>
will expire or <spanx style="verb">0</spanx> if they do not
expire. See <xref target="RFC3339">RFC 3339</xref> for details
regarding date/times in general and UTC in particular.</t>
</list><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
{
"client_id":"s6BhdRkqt3",
"client_secret":
"cf136dc3c1fd9153029bb9c6cc9ecead918bad9887fce6c93f31185e5885805d",
"registration_access_token": "this.is.a.access.token.value.ffx83",
"expires_at":2893276800
}]]></artwork>
</figure></t>
</section>
<section title="Client Registration Error Response">
<t>When an OAuth error condition occurs, the Client Registration
Endpoint returns an Error Response as defined in Section 5.2 of the
OAuth 2.0 specification.</t>
<t>When a registration error condition occurs, the Client Registration
Endpoint returns a HTTP 400 status code including a JSON object
describing the error in the response body.</t>
<t>The JSON object contains two members:</t>
<t><list style="hanging">
<t hangText="error">The error code, a single ASCII string.</t>
<t hangText="error_description">The additional text description of
the error for debugging.</t>
</list></t>
<t>This specification defines the following error codes:</t>
<t><list style="hanging">
<t hangText="invalid_operation">The value of <spanx style="verb">operation</spanx>
is invalid or not supported.</t>
<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
<xref target="client-metadata">client metadata</xref> fields is
invalid.</t>
</list></t>
<t><figure>
<preamble>Following is a non-normative example of an error
response:</preamble>
<artwork><![CDATA[HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_operation",
"error_description":"The value of the operation parameter must be one of client_associate, rotate_secret or client_update."
}]]></artwork>
</figure></t>
</section>
</section>
<section anchor="client-metadata" title="Client Metadata">
<t>Clients generally have an array of metadata associated with their
unique Client Identifier at the Authorization Server. These can range
from human-facing display strings, such as a client name, to items that
impact the security of the protocol,</t>
<t>Extensions and profiles of this specification MAY expand this list,
but MUST at least accept all parameters on this list. The Authorization
Server MUST ignore any additional parameters sent by the Client that it
does not understand.</t>
<t><list style="hanging">
<t hangText="redirect_uris"><vspace blankLines="0" />REQUIRED A
space-delimited list of redirect URIs.</t>
<t hangText="client_name">RECOMMENDED. Human-readable name of the
Client to be presented to the user.</t>
<t hangText="client_url"><vspace />RECOMMENDED. This field contains
the URL of the homepage of the client.</t>
<t hangText="logo_url">OPTIONAL. A URL that references a logo for
the Client application. If present, the server SHOULD display this
image to the end user during approval.</t>
<t hangText="contacts">OPTIONAL. Space delimited list of email
addresses for people allowed to administer the information for this
Client. This is used by some providers to enable a web UI to modify
the Client information.</t>
<t hangText="tos_url">OPTIONAL. URL that points to a human-readable
Terms of Service for the Client. The Authorization Server SHOULD
display this URL to the End-User if it is given.</t>
<t hangText="token_endpoint_auth_method">OPTIONAL. The requested
authentication type for the Token Endpoint. The options are <spanx
style="verb">client_secret_post</spanx>, <spanx style="verb">client_secret_basic</spanx>,
<spanx style="verb">client_secret_jwt</spanx>, and <spanx
style="verb">private_key_jwt</spanx>. Other Authentication methods
may be defined by extension. If unspecified or omitted, the default
is <spanx style="verb">client_secret_basic</spanx> HTTP Basic
Authentication Scheme as specified in Section 2.3.1 of <xref
target="OAuth2.0">OAuth 2.0</xref>. [[ this list of terms needs to
be expanded and fully defined, especially in reference to signed-jwt
client authentication ]]</t>
<t hangText="policy_url">OPTIONAL. A URL location that the Client
provides to the End-User to read about the how the profile data will
be used. The Authorization Server SHOULD display this URL to the
End-User if it is given.</t>
<t hangText="jwk_url">OPTIONAL. URL for the Client's <xref
target="JWK">JSON Web Key</xref> document that is used for signing
Token Endpoint Requests. If jwk_encryption_url is not provided, the
key at jwk_url is also used as the key to encrypt responses to the
Client. If the Client registers both <spanx style="verb">x509_url</spanx>
and <spanx style="verb">jwk_url</spanx>, the keys contained in both
formats MUST be the same.</t>
<t hangText="jwk_encryption_url">OPTIONAL. URL for the Client's
<xref target="JWK">JSON Web Key</xref> that is used to encrypt any
responses to the Client. If the Client registers both <spanx
style="verb">jwk_encryption_url</spanx> and <spanx style="verb">x509_encryption_url</spanx>,
the keys contained in both formats MUST be the same.</t>
<t hangText="x509_url">OPTIONAL. URL for the Client's PEM encoded
X.509 Certificate or Certificate chain that is used for signing
Token Endpoint Requests. If <spanx style="verb">x509_encryption_url</spanx>
is not provided, <spanx style="verb">x509_url</spanx> it is also
used to encrypt responses to the Client. If the Client registers
both <spanx style="verb">x509_url</spanx> and <spanx style="verb">jwk_url</spanx>,
the keys contained in both formats MUST be the same.</t>
<t hangText="x509_encryption_url">OPTIONAL. URL for the Client's PEM
encoded X.509 Certificate or Certificate chain that is used to
encrypt the ID Token and User Info Endpoint Responses to the Client.
If the Client registers both <spanx style="verb">jwk_encryption_url</spanx>
and <spanx style="verb">x509_encryption_url</spanx>, the keys
contained in both formats SHOULD be the same.</t>
<t hangText="require_signed_request_object">OPTIONAL. The <xref
target="JWS">JWS</xref> <spanx style="verb">alg</spanx> <xref
target="JWA">algorithm</xref> that MUST be required by the
Authorization Server. The valid values are listed in Section 3.1 of
<xref target="JWA">JWA</xref>. Servers SHOULD support <spanx
style="verb">RS256</spanx>.</t>
<t hangText="default_max_age">OPTIONAL. (default max authentication
age): Type: Integer - Specifies that the End-User must be actively
authenticated if any present authentication is older than the
specified number of seconds. (The <spanx style="verb">max_age</spanx>
request parameter corresponds to the OpenID 2.0 PAPE <spanx
style="verb">max_auth_age</spanx> request parameter.) The <spanx
style="verb">max_age</spanx> claim in the request object overrides
this default value.</t>
<t hangText="default_acr">OPTIONAL. (default authentication context
class reference): Type: String - Specifies the default value that
the Authorization server must use for processing requests from this
client. The <spanx style="verb">acrs_supported</spanx> element of
discovery contains a list of the supported <spanx style="verb">acr</spanx>
values for this server. The <spanx style="verb">acr</spanx> claim in
the request object overrides this default value.</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no requests of IANA.</t>
</section>
<section title="Security Considerations">
<t>[[ Editor's note: Following are some security considerations taken
whole from the UMA and OpenID Connect source drafts. ]] <list
style="symbols">
<t>No client authentication: The server should treat unsigned pushed
client metadata as self-asserted.</t>
<t>Weak client authentication: The server should treat unsigned
pulled client metadata as self-asserted unless the domain of the
client matches the client metadata URL and the URL is well-known and
trusted.</t>
<t>Strong client authentication: The server should treat signed
client metadata (pushed or pulled) and a signed metadata URL as
self-asserted unless it can verify the signature as being from a
trusted source.</t>
</list></t>
<t>Since requests to the Client Registration Endpoint result in the
transmission of clear-text credentials (in the HTTP request and
response), the 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"></xref> 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>Requests to the Registration Endpoint for <spanx style="verb">client_update</spanx>
MUST have some rate limiting on failures to prevent the Client secret
from being disclosed though repeated access attempts.</t>
<t>A rogue RP might use the logo for the legitimate RP, which it is
trying to impersonate. An IdP needs to take steps to mitigate this
phishing risk, since the logo could confuse users into thinking they're
logging in to the legitimate RP. An IdP could also warn if the
domain/site of the logo doesn't match the domain/site of redirect URIs.
An IdP can also make warnings against untrusted RPs in all cases,
especially if they're dynamically registered, have not been trusted by
any users at the IdP before, and want to use the logo feature.</t>
<t>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. <spanx
style="verb">logo_url</spanx> and <spanx style="verb">policy_url</spanx>).
A rogue Client could specify a registration request with a reference to
a drive-by download in the <spanx style="verb">policy_url</spanx>. The
Authorization Server should check to see if the <spanx style="verb">logo_url</spanx>
and <spanx style="verb">policy_url</spanx> have the same host as the
hosts defined in the array of <spanx style="verb">redirect_uris</spanx>.</t>
</section>
<section title="Acknowledgments">
<t>The authors thank the User-Managed Access Work Group and the OpenID
Connect Working Group participants for their input to this document.</t>
</section>
<section title="Document History">
<t>[[ to be removed by RFC editor before publication as an RFC ]]</t>
<t>- 01</t>
<t><list style="symbols">
<t>Merged UMA and OpenID Connect registrations into a single
document</t>
<t>Changed to form-paramter 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>
</middle>
<back>
<references title="Normative References">
<reference anchor="OAuth-Sig"
target="http://www.ietf.org/mail-archive/web/oauth/current/msg03893.html">
<front>
<title>OAuth Signature proposals</title>
<author initials="D." surname="Balfanz">
<organization>IETF</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="hostmeta"
target="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hammer-hostmeta-13.xml">
<front>
<title>Web Host Metadata</title>
<author initials="E." surname="Hammer-Lahav">
<organization>Yahoo!</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="JSON" target="http://tools.ietf.org/html/rfc4627">
<front>
<title>The application/json Media Type for JavaScript Object
Notation (JSON)</title>
<author initials="D." surname="Crockford">
<organization>JSON.org</organization>
</author>
<date year="2006" />
</front>
</reference>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml' ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125"?>
<reference anchor="USA15">
<front>
<title>Unicode Normalization Forms</title>
<author fullname="Mark Davis" initials="M." surname="Davis">
<address>
<email>markdavis@google.com</email>
</address>
</author>
<author fullname="Ken Whistler" initials="K." surname="Whistler">
<address>
<email>ken@unicode.org</email>
</address>
</author>
<author fullname="Martin Dürst" initials="M."
surname="Dürst"></author>
<date day="03" month="09" year="2009" />
</front>
<seriesInfo name="Unicode Standard Annex" value="15" />
</reference>
<reference anchor="OpenID.Messages">
<front>
<title>OpenID Connect Messages 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="Breno de Medeiros" initials="B."
surname="de Medeiros">
<organization abbrev="Google">Google</organization>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="Salesforce">Salesforce</organization>
</author>
<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization abbrev="Illumila">Illumila</organization>
</author>
<date day="25" month="May" year="2012" />
</front>
<format target="http://openid.net/specs/openid-connect-messages-1_0.html"
type="HTML" />
</reference>
<reference anchor="OpenID.Session">
<front>
<title>OpenID Connect Session Management 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="Breno de Medeiros" initials="B."
surname="de Medeiros">
<organization abbrev="Google">Google</organization>
</author>
<author fullname="Naveen Agarwal" initials="N." surname="Agarwal">
<organization abbrev="Google">Google</organization>
</author>
<date day="2" month="August" year="2012" />
</front>
<format target="http://openid.net/specs/openid-connect-session-1_0.html"
type="HTML" />
</reference>
<reference anchor="JWA">
<front>
<title>JSON Web Algorithms</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<date day="12" month="May" year="2012" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms"
type="HTML" />
</reference>
<reference anchor="JWT">
<front>
<title>JSON Web Token</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization>Ping Identity</organization>
</author>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.</organization>
</author>
<date day="22" month="May" year="2012" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token"
type="HTML" />
</reference>
<reference anchor="JWS">
<front>
<title>JSON Web Signature</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization>Ping Identity</organization>
</author>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.</organization>
</author>
<date day="12" month="May" year="2012" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature"
type="HTML" />
</reference>
<reference anchor="JWE">
<front>
<title>JSON Web Encryption (JWE)</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization>Microsoft</organization>
</author>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Joe Hildebrand" initials="J." surname="Hildebrand">
<organization>Cisco Systems, Inc.</organization>
</author>
<date day="12" month="May" year="2012" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption"
type="HTML" />
</reference>
<reference anchor="JWK">
<front>
<title>JSON Web Key (JWK)</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization>Microsoft</organization>
</author>
<date day="12" month="May" year="2012" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-jose-json-web-key"
type="HTML" />
</reference>
<reference anchor="OAuth2.0">
<front>
<title>OAuth 2.0 Authorization Protocol</title>
<author fullname="Dick Hardt" initials="D." surname="Hardt">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<date day="31" month="July" year="2012" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-v2"
type="HTML" />
</reference>
<reference anchor="OAuth.Bearer">
<front>
<title>OAuth 2.0 Protocol: Bearer Tokens</title>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="Dick Hardt" initials="D." surname="Hardt">
<organization>Independent</organization>
</author>
<date day="1" month="Aug" year="2012" />
</front>
<format target="http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer"
type="HTML" />
</reference>
</references>
<references title="Non-Normative References">
<reference anchor="UMA-Core"
target="http://tools.ietf.org/id/draft-hardjono-oauth-umacore-04.txt">
<front>
<title>UMA Requirements</title>
<author initials="C." surname="Scholz">
<organization>Kantara Initiative</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="UMA-UC"
target="http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases">
<front>
<title>UMA Explained</title>
<author initials="H." surname="Akram">
<organization>Kantara Initiative</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="UMA-Reqs"
target="http://kantarainitiative.org/confluence/display/uma/UMA+Requirements">
<front>
<title>UMA Requirements</title>
<author initials="E." surname="Maler">
<organization>Kantara Initiative</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:30:45 |