<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Connect
Dynamic Client Registration 1.0 - draft 15</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect
Dynamic Client Registration 1.0 - draft 15">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">N. Sakimura</td></tr>
<tr><td class="header"> </td><td class="header">NRI</td></tr>
<tr><td class="header"> </td><td class="header">J. Bradley</td></tr>
<tr><td class="header"> </td><td class="header">Ping Identity</td></tr>
<tr><td class="header"> </td><td class="header">M. Jones</td></tr>
<tr><td class="header"> </td><td class="header">Microsoft</td></tr>
<tr><td class="header"> </td><td class="header">February 5, 2013</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect
Dynamic Client Registration 1.0 - draft 15</h1>
<h3>Abstract</h3>
<p>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It allows Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and
REST-like manner.
</p>
<p>This specification describes how an OpenID Client can obtain the necessary
client credentials required by the OpenID Connect protocol suite.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#Introduction">1.</a>
Introduction<br />
<a href="#rnc">1.1.</a>
Requirements Notation and Conventions<br />
<a href="#terminology">1.2.</a>
Terminology<br />
<a href="#ClientRegistration">2.</a>
Client Registration<br />
<a href="#ClientRegistrationRequest">2.1.</a>
Client Registration Request<br />
<a href="#ClientRegistrationResponse">2.2.</a>
Client Registration Response<br />
<a href="#ClientUpdate">3.</a>
Client Update<br />
<a href="#ClientUpdateRequest">3.1.</a>
Client Update Request<br />
<a href="#ClientUpdateResponse">3.2.</a>
Client Update Response<br />
<a href="#ErrorResponse">4.</a>
Client Registration Endpoint Error Response<br />
<a href="#sector.identifier.url.validation">5.</a>
"sector_identifier_url" Validation<br />
<a href="#stringops">6.</a>
String Operations<br />
<a href="#Validation">7.</a>
Validation<br />
<a href="#ImplementationConsiderations">8.</a>
Implementation Considerations<br />
<a href="#Security">9.</a>
Security Considerations<br />
<a href="#TLS_requirements">9.1.</a>
TLS Requirements<br />
<a href="#IANA">10.</a>
IANA Considerations<br />
<a href="#rfc.references1">11.</a>
References<br />
<a href="#rfc.references1">11.1.</a>
Normative References<br />
<a href="#rfc.references2">11.2.</a>
Informative References<br />
<a href="#Acknowledgements">Appendix A.</a>
Acknowledgements<br />
<a href="#Notices">Appendix B.</a>
Notices<br />
<a href="#History">Appendix C.</a>
Document History<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="Introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>In order for an OpenID Connect Client to utilize OpenID services for
a user, the Client needs to register with the OpenID Provider to acquire
a Client ID and shared secret. This document describes how a new Client
can register with the provider, and how a Client already in possession
of a <tt>client_id</tt> can retrieve updated registration information.
</p>
<p>The Client Registration Endpoint may be co-resident with the token
endpoint as an optimization in some deployments.
</p>
<p>
Note: This specification will likely be modified to use the
<a class='info' href='#I-D.ietf-oauth-dyn-reg'>OAuth Dynamic Client Registration Protocol<span> (</span><span class='info'>Richer, J., Bradley, J., Jones, M., and M. Machulak, “OAuth Dynamic Client Registration Protocol,” January 2013.</span><span>)</span></a> [I‑D.ietf‑oauth‑dyn‑reg]
once the OAuth registration draft is stable.
While currently self-contained, this specification intentionally uses
the same syntax and identifiers as the current version of the
OAuth registration draft as of the time that this specification was last updated.
</p>
<a name="rnc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Requirements Notation and Conventions</h3>
<p>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 <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<p>Throughout this document, values are quoted to indicate that they are
to be taken literally. When using these values in protocol messages, the
quotes MUST NOT be used as part of the value.
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
Terminology</h3>
<p>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
<a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> [RFC6749],
and the terms defined by
<a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>This specification defines the following additional terms:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Client Registration Endpoint</dt>
<dd>
OAuth 2.0 Protected Resource through which a Client can request
a new registration and manage the metadata associated with it.
</dd>
<dt>Registration Access Token</dt>
<dd>
OAuth 2.0 Bearer Token issued by the Authorization Server
through the Client Registration Endpoint that is used by the Client
to authenticate itself during update operations.
</dd>
</dl></blockquote>
<a name="ClientRegistration"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Client Registration</h3>
<p>The Client Registration Endpoint is an
OAuth 2.0 Protected Resource through which a Client can request
a new registration and manage the metadata associated with it.
The OpenID Provider may require an Access Token that is
provisioned out-of-band (in a manner that is out of scope for
this specification) in order to restrict registration requests
to only authorized Clients.
</p>
<p>In order to support open registration, the Client
Registration Endpoint SHOULD accept registration requests without OAuth 2.0
Access Tokens.
If an Access Token is required for Client registration, the Client Registration Endpoint
MUST be able to accept Access Tokens in the manner described in the
<a class='info' href='#RFC6750'>OAuth 2.0 Bearer Token Usage<span> (</span><span class='info'>Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a> [RFC6750]
specification.
</p>
<a name="ClientRegistrationRequest"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Client Registration Request</h3>
<p>To register a new client to the Authorization Server, the client
sends HTTP POST messages to the Client Registration Endpoint with the
parameters described below, which is called Client Metadata.
They are encoded in the entity body as UTF-8 strings
using the <tt>application/x-www-form-urlencoded</tt>
format. 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
Authorization Server MAY provision default values for any items
omitted in the Client Metadata.
</p>
<p></p>
<blockquote class="text"><dl>
<dt>redirect_uris</dt>
<dd>REQUIRED.
Space-delimited list of redirect URIs.
One of the URL MUST match the Scheme, Host, and Path segments of the
<tt>redirect_uri</tt> in the authorization request.
</dd>
<dt>application_type</dt>
<dd>OPTIONAL.
Kind of the application.
The default if not specified is
<tt>web</tt>. The defined values are
<tt>native</tt>
or <tt>web</tt>.
Web clients MUST only register URLs using the <tt>https:</tt> scheme as
<tt>redirect_uris</tt>;
they MAY NOT use <tt>localhost</tt> as the hostname.
Native clients MUST only register <tt>redirect_uris</tt> using custom
URI schemes or URLs using the <tt>http:</tt> scheme with
<tt>localhost</tt> as the hostname.
Authorization Servers may place additional constraints on Native clients.
The Authorization server MUST verify that all the registered
<tt>redirect_uris</tt> conform to the constraints.
This prevents sharing a Client ID across different types of Clients.
</dd>
<dt>access_token</dt>
<dd>OPTIONAL.
Access Token obtained
out of band to authorize the registrant.
This parameter
MUST NOT be sent if the Access Token is sent in the HTTP
Authorization header as described in Section 7.1 of <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> [RFC6749]. Access Tokens sent in the
authorization header must be bearer tokens <a class='info' href='#RFC6750'>[RFC6750]<span> (</span><span class='info'>Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>.
</dd>
<dt>contacts</dt>
<dd>OPTIONAL.
Space delimited list of e-mail
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.
</dd>
<dt>client_name</dt>
<dd>OPTIONAL.
Name of the Client
to be presented to the user. If desired, representation of
this claim in different languages and scripts is obtained
by applying the rules set in
Section 2.1.1.1.3 ("claims" member) of
<a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.</span><span>)</span></a> [OpenID.Messages].
</dd>
<dt>logo_url</dt>
<dd>OPTIONAL.
URL that references a logo for the
Client application.
</dd>
<dt>token_endpoint_auth_method</dt>
<dd>OPTIONAL.
Requested authentication method for the Token Endpoint.
The options are
<tt>client_secret_post</tt>,
<tt>client_secret_basic</tt>,
<tt>client_secret_jwt</tt>,
and <tt>private_key_jwt</tt>, as described in
Section 2.2.1 of <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.</span><span>)</span></a> [OpenID.Messages].
Other Authentication methods may be defined by extension. If unspecified or
omitted, the default is <tt>client_secret_basic</tt> HTTP Basic Authentication
Scheme as specified in
Section 2.3.1 of <a class='info' href='#RFC6749'>OAuth 2.0<span> (</span><span class='info'>Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> [RFC6749].
</dd>
<dt>policy_url</dt>
<dd>OPTIONAL.
URL location that the Relying
Party Client provides to the End-User to read about the how the
profile data will be used. The OpenID Provider SHOULD display this
URL to the End-User if it is given.
</dd>
<dt>tos_url</dt>
<dd>OPTIONAL.
URL location that the Relying
Party Client provides to the End-User to read about
the Relying Party's terms of service.
The OpenID Provider SHOULD display this
URL to the End-User if it is given.
</dd>
<dt>jwk_url</dt>
<dd>OPTIONAL.
URL for the Client's
JSON Web Key Set <a class='info' href='#JWK'>[JWK]<span> (</span><span class='info'>Jones, M., “JSON Web Key (JWK),” December 2012.</span><span>)</span></a> document
containing key(s) that are used for
signing Token Endpoint Requests and OpenID Request Objects.
If <tt>jwk_encryption_url</tt> is not
provided it is also used to encrypt
the ID Token and User Info Endpoint Responses to the Client.
If the Client registers both <tt>x509_url</tt>
and <tt>jwk_url</tt>,
the keys contained in both formats SHOULD be the same.
</dd>
<dt>jwk_encryption_url</dt>
<dd>OPTIONAL.
URL for the Client's
JSON Web Key Set <a class='info' href='#JWK'>[JWK]<span> (</span><span class='info'>Jones, M., “JSON Web Key (JWK),” December 2012.</span><span>)</span></a> document
containing key(s) that are used to encrypt
the ID Token and User Info Endpoint Responses to the Client.
If the Client registers both <tt>jwk_encryption_url</tt>
and <tt>x509_encryption_url</tt>,
the keys contained in both formats SHOULD be the same.
</dd>
<dt>x509_url</dt>
<dd>OPTIONAL.
URL for the Client's PEM encoded X.509
Certificate or Certificate chain
that is used for
signing Token Endpoint Requests and OpenID Request Objects.
If <tt>x509_encryption_url</tt> is not
provided, <tt>x509_url</tt>
it is also used to encrypt
the ID Token and User Info Endpoint Responses to the Client.
If the Client registers both <tt>x509_url</tt>
and <tt>jwk_url</tt>,
the keys contained in both formats SHOULD be the same.
</dd>
<dt>x509_encryption_url</dt>
<dd>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 <tt>jwk_encryption_url</tt>
and <tt>x509_encryption_url</tt>,
the keys contained in both formats SHOULD be the same.
</dd>
<dt>sector_identifier_url</dt>
<dd>OPTIONAL.
URL using the <tt>https:</tt> scheme to be used in
calculating Pseudonymous Identifiers by the OP. The URL references a
file with a single JSON array of <tt>redirect_uri</tt> values.
Please see <a class='info' href='#sector.identifier.url.validation'>Section 5<span> (</span><span class='info'>"sector_identifier_url" Validation</span><span>)</span></a>.
</dd>
<dt>subject_type</dt>
<dd>OPTIONAL.
<tt>subject_type</tt> requested for
responses to this <tt>client_id</tt>. The
<tt>subject_types_supported</tt> element of discovery
contains a list of the supported <tt>subject_type</tt>
values for this server. Valid types include
<tt>pairwise</tt> and
<tt>public</tt>.
</dd>
<dt>request_object_signing_alg</dt>
<dd>OPTIONAL.
<a class='info' href='#JWS'>JWS<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” December 2012.</span><span>)</span></a> [JWS] <tt>alg</tt>
algorithm <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> that MUST be required by the Authorization Server.
The valid values are listed in
Section 3.1 of <a class='info' href='#JWA'>JWA<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> [JWA].
All OpenID Request Objects from
this <tt>client_id</tt> MUST be rejected if not signed by this algorithm.
Servers SHOULD support <tt>RS256</tt>.
</dd>
<dt>userinfo_signed_response_alg</dt>
<dd>OPTIONAL.
JWS <tt>alg</tt>
algorithm <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> required for UserInfo responses.
The valid values are listed in
Section 3.1 of <a class='info' href='#JWA'>JWA<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> [JWA].
If this is specified the response will be
<a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.</span><span>)</span></a> [JWT] serialized, and signed using JWS.
</dd>
<dt>userinfo_encrypted_response_alg</dt>
<dd>OPTIONAL.
<a class='info' href='#JWE'>JWE<span> (</span><span class='info'>Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” December 2012.</span><span>)</span></a> [JWE] <tt>alg</tt>
algorithm <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> required for encrypting UserInfo responses.
The valid values are listed in
Section 4.1 of <a class='info' href='#JWA'>JWA<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> [JWA].
If this is requested in combination with signing the response
will be signed then encrypted. If this is specified the response will be
<a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.</span><span>)</span></a> [JWT] serialized, and encrypted using JWE.
</dd>
<dt>userinfo_encrypted_response_enc</dt>
<dd>OPTIONAL.
JWE <tt>enc</tt>
algorithm <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> required for symmetric encryption of UserInfo responses.
The valid values are listed in
Section 4.2 <a class='info' href='#JWA'>JWA<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> [JWA].
If <tt>"userinfo_encrypted_response_alg"</tt> is specified
the default for this value is <tt>A128CBC+HS256</tt>.
If this is requested in combination with signing the response
will be signed then encrypted. If this is specified the response will be
<a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.</span><span>)</span></a> [JWT] serialized, and encrypted using JWE.
</dd>
<dt>id_token_signed_response_alg</dt>
<dd>OPTIONAL.
JWS <tt>alg</tt>
algorithm <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> required for the ID Token issued to this
<tt>client_id</tt>.
The valid values are listed in
Section 3.1 of <a class='info' href='#JWA'>JWA<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> [JWA],
with the exception of <tt>none</tt>,
which MAY NOT be used as the ID Token <tt>alg</tt> value.
The default if not specified is <tt>RS256</tt>.
The public key for validating the signature is provided by retrieving the
document from the
<tt>jwk_url</tt> element or the <tt>x509_url</tt>
element from discovery.
</dd>
<dt>id_token_encrypted_response_alg</dt>
<dd>OPTIONAL.
JWE <tt>alg</tt>
algorithm <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> required for encrypting the ID Token issued to this <tt>client_id</tt>.
The valid values are listed in
Section 4.1 of <a class='info' href='#JWA'>JWA<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> [JWA].
If this is requested the response will be signed then encrypted.
The default if not specified is no encryption.
</dd>
<dt>id_token_encrypted_response_enc</dt>
<dd>OPTIONAL.
JWE <tt>enc</tt>
algorithm <a class='info' href='#JWA'>[JWA]<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> required for symmetric encryption of the ID Token
issued to this <tt>client_id</tt>.
The valid values are listed in
Section 4.2 of <a class='info' href='#JWA'>JWA<span> (</span><span class='info'>Jones, M., “JSON Web Algorithms (JWA),” December 2012.</span><span>)</span></a> [JWA].
If <tt>"id_token_encrypted_response_alg"</tt> is specified
the default for this value is <tt>A128CBC+HS256</tt>.
If this is requested in combination with signing the response
will be signed then encrypted. If this is specified the response will be
<a class='info' href='#JWT'>JWT<span> (</span><span class='info'>Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” December 2012.</span><span>)</span></a> [JWT] serialized, and encrypted using JWE.
</dd>
<dt>default_max_age</dt>
<dd>OPTIONAL.
Default max authentication age
that specifies that the End-User must be actively authenticated if
any present authentication is older than the specified
number of seconds represented as an integer.
(The <tt>max_age</tt> request parameter
corresponds to the OpenID 2.0
PAPE <tt>max_auth_age</tt>
request parameter.) The <tt>max_age</tt> claim in the
request object overrides this default value.
</dd>
<dt>require_auth_time</dt>
<dd>OPTIONAL.
Boolean value specifying whether the <tt>auth_time</tt>
claim in the <tt>id_token</tt> is REQUIRED.
It is REQUIRED when the value is <tt>true</tt>.
The <tt>auth_time</tt> claim request
in the request object overrides this setting.
</dd>
<dt>default_acr</dt>
<dd>OPTIONAL.
Default authentication context class reference value.
String that
specifies the default value that the Authorization Server must use
for processing requests from this client. The
<tt>acr_values_supported</tt> element of discovery
contains a list of the supported <tt>acr</tt>
values for this server.
The <tt>acr</tt> claim in the
request object overrides this default value.
</dd>
<dt>initiate_login_uri</dt>
<dd>OPTIONAL.
URI using the <tt>https:</tt> scheme that the authorization server can call
to initiate a login at the client.
The URI MUST accept requests via both GET and POST.
The client MUST understand the
<tt>login_hint</tt> and <tt>iss</tt> parameters and
SHOULD support the <tt>target_link_uri</tt> parameter.
</dd>
<dt>post_logout_redirect_url</dt>
<dd>OPTIONAL.
URL supplied by the RP to request that the user be redirected to this location
after a logout has been performed, as specified in
<a class='info' href='#OpenID.Session'>OpenID Connect Session Management 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “OpenID Connect Session Management 1.0,” January 2013.</span><span>)</span></a> [OpenID.Session].
</dd>
</dl></blockquote><p>
For example, a client could send the
following registration request to the Client Registration
Endpoint:
</p>
<p>
<p>Following is a non-normative example request
(with line wraps for display purposes only):
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /connect/register HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...
application_type=web
&redirect_uris=https://client.example.org/callback
%20https://client.example.org/callback2
&client_name=My%20Example%20
&client_name%23ja-Jpan-JP=
%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%90%8D
&logo_url=https://client.example.org/logo.png
&subject_type=pairwise
§or_identifier_url=
https://othercompany.com/file_of_redirect_uris.json
&token_endpoint_auth_method=client_secret_basic
&jwk_url=https://client.example.org/my_rsa_public_key.jwk
&userinfo_encrypted_response_alg=RSA1_5
&userinfo_encrypted_response_enc=A128CBC+HS256
</pre></div>
<a name="ClientRegistrationResponse"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Client Registration Response</h3>
<p>Upon successful registration, the Client Registration Endpoint
returns the newly-created Client Identifier and, if applicable, a
Client Secret, along with 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 field values and substitute them with suitable values. If
this happens, the Authorization Server MUST include these fields in
the response to the client.
</p>
<p>
The response also contains a Registration Access Token that is
used by the client to perform subsequent operations upon
the resulting client registration.
</p>
<p>All of the response items are returned as a <a class='info' href='#RFC4627'>JSON document<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] with the following fields as
top-level members of the root JSON object.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>REQUIRED. Unique Client identifier.
It MUST NOT be currently valid for any other registered
Client.
</dd>
<dt>client_secret</dt>
<dd>OPTIONAL. Client secret.
This MUST be unique for each <tt>client_id</tt>.
This value is used by confidential clients to authenticate to the
Token Endpoint as described in OAuth 2.0 Section 2.3.1.
It is not required for
clients selecting a <tt>token_endpoint_auth_method</tt> of
<tt>private_key_jwt</tt>.
</dd>
<dt>registration_access_token</dt>
<dd>REQUIRED.
Access Token that is
used by the client to perform subsequent operations upon
the resulting client registration.
</dd>
<dt>issued_at</dt>
<dd>OPTIONAL.
Time when the Client Identifier was issued.
The timestamp value MUST be a positive integer.
The time is represented as the number of
seconds since 1970-01-01T0:0:0Z as measured in UTC.
</dd>
<dt>expires_at</dt>
<dd>OPTIONAL.
Time at which the <tt>client_secret</tt> will expire
or 0 if it will not expire.
The time is represented as the number of
seconds since 1970-01-01T0:0:0Z as measured in UTC.
</dd>
</dl></blockquote>
<p>
<p>Following is a non-normative example response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"client_id": "s6BhdRkqt3",
"client_secret":
"cf136dc3c1fd9153029bb9c6cc9ecead
918bad9887fce6c93f31185e5885805d",
"registration_access_token":
"this.is.an.access.token.value.ffx83",
"token_endpoint_auth_method":
"client_secret_basic",
"expires_at":2893276800,
"application_type": "web",
"redirect_uris":
"https://client.example.org/callback
https://client.example.org/callback2",
"client_name": "My Example",
"client_name#ja-Jpan-JP":
"クライアント名",
"logo_url": "https://client.example.org/logo.png",
"subject_type": "pairwise",
"sector_identifier_url":
"https://othercompany.com/file_of_redirect_uris.json",
"jwk_url": "https://client.example.org/my_rsa_public_key.jwk",
"userinfo_encrypted_response_alg": "RSA1_5",
"userinfo_encrypted_response_enc": "A128CBC+HS256"
}
</pre></div>
<a name="ClientUpdate"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Client Update</h3>
<p>This operation updates a previously-registered client with new
metadata at the Authorization Server.
</p>
<a name="ClientUpdateRequest"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Client Update Request</h3>
<p>The request is sent to the Registration Endpoint
with the parameters described in Client Metadata
encoded in the entity body using the
<tt>application/x-www-form-urlencoded</tt>
format.
</p>
<p>Parameters sent with this request are the same as for the registration
request except for the <tt>access_token</tt>,
which MUST be the <tt>registration_access_token</tt>
value received in the registration request and the addition of
a <tt>client_id</tt> parameter, which MUST contain the
<tt>client_id</tt> value received in the registration request.
The presence of the <tt>client_id</tt> syntactically
distinguishes client update requests from client registration requests.
All Client Metadata values, other than the Client ID and
Registration Access Token are replaced by this operation.
</p>
<p>For example, a client could send the following request to the
Client Registration Endpoint to update the client registration in the
above example:
</p>
<p>Following is a non-normative example request (with line
wraps for display purposes only):
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /connect/register HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: server.example.com
Authorization: Bearer this.is.an.access.token.value.ffx83
client_id=s6BhdRkqt3
&application_type=web
&redirect_uris=https://client.example.org/callback
%20https://client.example.org/alt
&client_name=My%20New%20Example%20
&client_name%23ja-Jpan-JP=
%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%90%8D
&logo_url=https://client.example.org/newlogo.png
&subject_type=pairwise
§or_identifier_url=
https://othercompany.com/file_of_redirect_uris.json
&token_endpoint_auth_method=client_secret_basic
&jwk_url=https://client.example.org/my_rsa_public_key.jwk
&userinfo_encrypted_response_alg=RSA1_5
&userinfo_encrypted_response_enc=A128CBC+HS256
</pre></div>
<a name="ClientUpdateResponse"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Client Update Response</h3>
<p>Upon successful update, the Client Registration Endpoint returns
the Client ID, along with all current 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 field values and substitute them suitable values.
If this happens, the Authorization Server MUST include these fields in
the response to the client.
</p>
<p>The Authorization Server MUST NOT include the Client Secret or
Request Access Token in this response.
</p>
<p>These fields are returned in a <a class='info' href='#RFC4627'>JSON
Document<span> (</span><span class='info'>Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.</span><span>)</span></a> [RFC4627] as top-level members of the root JSON object.
</p>
<p>
<p>Following is a non-normative example response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"client_id": "s6BhdRkqt3",
"token_endpoint_auth_method":
"client_secret_basic",
"application_type": "web",
"redirect_uris":
"https://client.example.org/callback
https://client.example.org/alt",
"client_name": "My New Example",
"client_name#ja-Jpan-JP":
"クライアント名",
"logo_url": "https://client.example.org/newlogo.png",
"subject_type": "pairwise",
"sector_identifier_url":
"https://othercompany.com/file_of_redirect_uris.json",
"jwk_url": "https://client.example.org/my_rsa_public_key.jwk",
"userinfo_encrypted_response_alg": "RSA1_5",
"userinfo_encrypted_response_enc": "A128CBC+HS256"
}
</pre></div>
<a name="ErrorResponse"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Client Registration Endpoint Error Response</h3>
<p>When an OAuth error condition occurs, the Client Registration Endpoint returns
an Error Response as defined in Section 3 of
the <a class='info' href='#RFC6750'>OAuth 2.0 Bearer Token Usage<span> (</span><span class='info'>Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a> [RFC6750] specification.
</p>
<p>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.
</p>
<p>The JSON object contains two members:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>error_code</dt>
<dd>Error code.
</dd>
<dt>error_description</dt>
<dd>Additional text description of the error for debugging.
</dd>
</dl></blockquote>
<p>This specification defines the following error codes:
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>invalid_client_id</dt>
<dd>Value of <tt>client_id</tt> is invalid.
</dd>
<dt>invalid_redirect_uri</dt>
<dd>Value of one or more <tt>redirect_uris</tt> is invalid.
</dd>
<dt>invalid_configuration_parameter</dt>
<dd>Value of one of the configuration parameters is invalid.
</dd>
</dl></blockquote>
<p>
<p>Following is a non-normative example of an error response:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error_code": "invalid_client_id",
"error_description": "The value of the client_id parameter is invalid."
}
</pre></div>
<a name="sector.identifier.url.validation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
"sector_identifier_url" Validation</h3>
<p>Providers who use pairwise <tt>sub</tt> (subject) values SHOULD support this element.
</p>
<p>It provides a way for a group of websites under a single administrative control
to have consistent pairwise <tt>sub</tt> values independent of the individual domain names.
It also provides a way for Clients to change <tt>redirect_uri</tt> domains without having to
reregister all of their users.
</p>
<p>This is further described in
Section 2.4.1 of <a class='info' href='#OpenID.Messages'>OpenID Connect Messages 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” January 2013.</span><span>)</span></a> [OpenID.Messages].
</p>
<p>The value of the <tt>sector_identifier_url</tt>
must be a URL using the <tt>https:</tt> scheme that references
a JSON file containing an array containing <tt>redirect_uri</tt> values.
</p>
<p>The values of the registered <tt>redirect_uris</tt>
must be included in the elements of the array,
or registration MUST fail.
</p>
<p></p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /connect/sector_identifier.js HTTP/1.1
Accept: application/json
Host: client.example.org
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
[ "https://client.example.org/callback",
"https://client.example.org/callback2",
"https://client.other_company.example.net/callback" ]
</pre></div><p>
</p>
<a name="stringops"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
String Operations</h3>
<p>
Processing some OpenID Connect messages requires comparing
values in the messages to known values. For example, the
member names in the Client registration response might be
compared to specific member names such as <tt>client_id</tt>. Comparing Unicode strings,
however, has significant security implications.
</p>
<p>
Therefore, comparisons between JSON strings and other Unicode
strings MUST be performed as specified below:
</p>
<ol class="text">
<li>
Remove any JSON applied escaping to produce an array of
Unicode code points.
</li>
<li>
<a class='info' href='#USA15'>Unicode Normalization<span> (</span><span class='info'>Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” 09 2009.</span><span>)</span></a> [USA15] MUST NOT
be applied at any point to either the JSON string or to
the string it is to be compared against.
</li>
<li>
Comparisons between the two strings MUST be performed as a
Unicode code point to code point equality comparison.
</li>
</ol><p>
</p>
<p>
In several places, this specification uses space delimited
lists of strings. In all such cases, only the ASCII space
character (0x20) MAY be used for this purpose.
</p>
<a name="Validation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.
Validation</h3>
<p>
If any of the validation procedures defined in this specification fail, any operations requiring
the information that failed to correctly validate MUST be aborted and
the information that failed to validate MUST NOT be used.
</p>
<a name="ImplementationConsiderations"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.
Implementation Considerations</h3>
<p>
This specification defines features used by both Relying Parties and
OpenID Providers that choose to implement Dynamic Client Registration.
All of these Relying Parties and OpenID Providers
MUST implement the features that are listed
in this specification as being "REQUIRED" or are described with a "MUST".
No other implementation considerations for implementations of
Dynamic Client Registration are defined by this specification.
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.
Security Considerations</h3>
<p>Since requests to the Client Registration Endpoint result in the
transmission of clear-text credentials (in the HTTP request and
response),
all communiucation with the Registration Endpoint MUST utilize TLS.
See <a class='info' href='#TLS_requirements'>Section 9.1<span> (</span><span class='info'>TLS Requirements</span><span>)</span></a> for more information on using TLS.
</p>
<p>
A rogue RP might use the logo for the legitimate RP, which it
is trying to impersonate. An OP 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 OP could also warn if the domain/site of the logo
doesn't match the domain/site of redirect URIs. An OP 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 OP before, and want to use the logo feature.
</p>
<p>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. <tt>logo_url</tt> and
<tt>policy_url</tt>). A rogue Client could
specify a registration request with a reference to a drive-by download in the
<tt>policy_url</tt>. The Authorization Server should check to see if the
<tt>logo_url</tt> and <tt>policy_url</tt> have the
same host as the hosts defined in the array of <tt>redirect_uris</tt>.
</p>
<a name="TLS_requirements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.9.1"></a><h3>9.1.
TLS Requirements</h3>
<p>
Implementations MUST support TLS.
Which version(s) ought to be implemented will vary over
time, and depend on the widespread deployment and known
security vulnerabilities at the time of implementation.
At the time of this writing,
TLS version 1.2 <a class='info' href='#RFC5246'>[RFC5246]<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a>
is the most recent version, but has very limited actual
deployment, and might not be readily available in
implementation toolkits.
TLS version 1.0 <a class='info' href='#RFC2246'>[RFC2246]<span> (</span><span class='info'>Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.</span><span>)</span></a>
is the most widely deployed version, and will give the
broadest interoperability.
</p>
<p>
To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS
with a ciphersuite that provides confidentiality and
integrity protection.
</p>
<p>
Whenever TLS is used, a TLS server certificate check
MUST be performed, per <a class='info' href='#RFC6125'>RFC 6125<span> (</span><span class='info'>Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.</span><span>)</span></a> [RFC6125].
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.
IANA Considerations</h3>
<p>This document makes no requests of IANA.
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>11.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="JWA">[JWA]</a></td>
<td class="author-text">Jones, M., “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms">JSON Web Algorithms (JWA)</a>,” draft-ietf-jose-json-web-algorithms (work in progress), December 2012 (<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="JWE">[JWE]</a></td>
<td class="author-text">Jones, M., Rescorla, E., and J. Hildebrand, “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption">JSON Web Encryption (JWE)</a>,” draft-ietf-jose-json-web-encryption (work in progress), December 2012 (<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="JWK">[JWK]</a></td>
<td class="author-text">Jones, M., “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-key">JSON Web Key (JWK)</a>,” draft-ietf-jose-json-web-key (work in progress), December 2012 (<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-key">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature">JSON Web Signature (JWS)</a>,” draft-ietf-jose-json-web-signature (work in progress), December 2012 (<a href="http://tools.ietf.org/html/draft-ietf-jose-json-web-signature">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
<td class="author-text">Jones, M., Bradley, J., and N. Sakimura, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token">JSON Web Token (JWT)</a>,” draft-ietf-oauth-json-web-token (work in progress), December 2012 (<a href="http://tools.ietf.org/html/draft-ietf-oauth-json-web-token">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Messages">[OpenID.Messages]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “<a href="http://openid.net/specs/openid-connect-messages-1_0.html">OpenID Connect Messages 1.0</a>,” January 2013.</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Session">[OpenID.Session]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and N. Agarwal, “<a href="http://openid.net/specs/openid-connect-session-1_0.html">OpenID Connect Session Management 1.0</a>,” January 2013.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2246">[RFC2246]</a></td>
<td class="author-text"><a href="mailto:tdierks@certicom.com">Dierks, T.</a> and <a href="mailto:callen@certicom.com">C. Allen</a>, “<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>,” RFC 2246, January 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2246.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4627">[RFC4627]</a></td>
<td class="author-text">Crockford, D., “<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>,” RFC 4627, July 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4627.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5246">[RFC5246]</a></td>
<td class="author-text">Dierks, T. and E. Rescorla, “<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>,” RFC 5246, August 2008 (<a href="http://www.rfc-editor.org/rfc/rfc5246.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6125">[RFC6125]</a></td>
<td class="author-text">Saint-Andre, P. and J. Hodges, “<a href="http://tools.ietf.org/html/rfc6125">Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>,” RFC 6125, March 2011 (<a href="http://www.rfc-editor.org/rfc/rfc6125.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6749">[RFC6749]</a></td>
<td class="author-text">Hardt, D., “<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>,” RFC 6749, October 2012 (<a href="http://www.rfc-editor.org/rfc/rfc6749.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6750">[RFC6750]</a></td>
<td class="author-text">Jones, M. and D. Hardt, “<a href="http://tools.ietf.org/html/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>,” RFC 6750, October 2012 (<a href="http://www.rfc-editor.org/rfc/rfc6750.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="USA15">[USA15]</a></td>
<td class="author-text"><a href="mailto:markdavis@google.com">Davis, M.</a>, <a href="mailto:ken@unicode.org">Whistler, K.</a>, and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>11.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.ietf-oauth-dyn-reg">[I-D.ietf-oauth-dyn-reg]</a></td>
<td class="author-text">Richer, J., Bradley, J., Jones, M., and M. Machulak, “<a href="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-04">OAuth Dynamic Client Registration Protocol</a>,” draft-ietf-oauth-dyn-reg-04 (work in progress), January 2013 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-oauth-dyn-reg-04.txt">TXT</a>).</td></tr>
</table>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Acknowledgements</h3>
<p>The OpenID Community would like to thank the following
people for the work they have done in the drafting and editing of this
specification.
</p>
<p></p>
<blockquote class="text">
<p>Amanda Anganes (aanganes@mitre.org), Mitre
</p>
<p>John Bradley (ve7jtb@ve7jtb.com), Ping Identity
</p>
<p>Brian Campbell (bcampbell@pingidentity.com), Ping Identity
</p>
<p>Vladimir Dzhuvinov (vladimir@nimbusds.com), NimbusDS
</p>
<p>Roland Hedberg (roland.hedberg@adm.umu.se), Independent
</p>
<p>Edmund Jay (ejay@mgi1.com), Illumila
</p>
<p>Michael B. Jones (mbj@microsoft.com), Microsoft
</p>
<p>Justin Richer (jricher@mitre.org), Mitre
</p>
<p>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.
</p>
</blockquote>
<a name="Notices"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B.
Notices</h3>
<p>Copyright (c) 2013 The OpenID Foundation.
</p>
<p>
The OpenID Foundation (OIDF) grants to any Contributor, developer,
implementer, or other interested party a non-exclusive, royalty free,
worldwide copyright license to reproduce, prepare derivative works from,
distribute, perform and display, this Implementers Draft or
Final Specification solely for the purposes of (i) developing
specifications, and (ii) implementing Implementers Drafts and
Final Specifications based on such documents, provided that attribution
be made to the OIDF as the source of the material, but that such attribution
does not indicate an endorsement by the OIDF.
</p>
<p>
The technology described in this specification was
made available from contributions from various sources,
including members of the OpenID Foundation and others.
Although the OpenID Foundation has taken steps to help ensure
that the technology is available for distribution, it takes
no position regarding the validity or scope of any intellectual
property or other rights that might be claimed to pertain to
the implementation or use of the technology described in
this specification or the extent to which any license under
such rights might or might not be available; neither does it
represent that it has made any independent effort to identify
any such rights. The OpenID Foundation and the contributors
to this specification make no (and hereby expressly disclaim any)
warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for
a particular purpose, or title, related to this specification,
and the entire risk as to implementing this specification is
assumed by the implementer. The OpenID Intellectual
Property Rights policy requires contributors to offer
a patent promise not to assert certain patent claims against
other contributors and against implementers. The OpenID Foundation invites
any interested party to bring to its attention any copyrights,
patents, patent applications, or other proprietary rights
that may cover technology that may be required to practice
this specification.
</p>
<a name="History"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.C"></a><h3>Appendix C.
Document History</h3>
<p>[[ To be removed from the final specification ]]
</p>
<p>-15
</p>
<ul class="text">
<li>
Fixed #708 - Registration access token requirement.
</li>
<li>
Fixed #734 - Invalid JSON in examples.
</li>
<li>
Fixed #736 - Client Update Operation Response: expires_at should be removed from example.
</li>
<li>
Fixed #735 - Require expires_at value in Client Register response.
</li>
<li>
Added Security Considerations section about TLS version requirements and usage.
</li>
<li>
State that when any validations fail, any operations requiring
the information that failed to correctly validate MUST be aborted and
the information that failed to validate MUST NOT be used.
</li>
<li>
Fixed #746 - Deleted the <tt>operation</tt> parameter.
</li>
<li>
Fixed #745 - Deleted the <tt>rotate_secret</tt> operation.
</li>
<li>
Changed the Japanese client name to make it sound more natural.
</li>
<li>
Added optional <tt>issued_at</tt> response value.
</li>
<li>
Added client update example.
</li>
<li>
Fixed #727 - Deleted invalid_client_secret error.
</li>
</ul><p>
</p>
<p>-14
</p>
<ul class="text">
<li>
Changed the syntax of some elements to match the syntax used in the
OAuth Dynamic Client Registration draft. Specifically,
changed <tt>type</tt> to <tt>operation</tt>,
changed <tt>associate</tt> to <tt>register</tt>, and
changed <tt>application_name</tt> to <tt>client_name</tt>.
Also changed the responses of <tt>client_register</tt>
and <tt>client_update</tt> to include full
client information instead of just the Client ID.
</li>
<li>
Added Implementation Considerations section.
</li>
<li>
Fixed #656 - Changed
<tt>token_endpoint_auth_type</tt> to
<tt>token_endpoint_auth_method</tt> and
<tt>token_endpoint_auth_types_supported</tt> to
<tt>token_endpoint_auth_methods_supported</tt>.
</li>
<li>
Fixed #698 - Inconsistent use of articles.
</li>
<li>
Deleted <tt>javascript_origin_uris</tt>, which is no longer present in Session.
</li>
<li>
Reference and provide note to implementers about
<a class='info' href='#I-D.ietf-oauth-dyn-reg'>OAuth Dynamic Client Registration Protocol<span> (</span><span class='info'>Richer, J., Bradley, J., Jones, M., and M. Machulak, “OAuth Dynamic Client Registration Protocol,” January 2013.</span><span>)</span></a> [I‑D.ietf‑oauth‑dyn‑reg].
</li>
<li>
Changed token_endpoint_auth_method example result value from
"client_secret_basic client_secret_post" to "client_secret_basic"
since the definition requires the value to be a single method.
</li>
</ul><p>
</p>
<p>-13
</p>
<ul class="text">
<li>
Fixed #687 - Inconsistency between <tt>user_id</tt>
and <tt>prn</tt> claims. The fix changed these names:
user_id -> sub, user_id_types_supported -> subject_types_supported,
user_id_type -> subject_type, and prn -> sub.
</li>
<li>
Renamed <tt>acrs_supported</tt> to
<tt>acr_values_supported</tt> for naming consistency.
</li>
<li>
Fixed #685 - The policy URL should be different from the terms-of-service URL.
A new <tt>tos_url</tt> registration parameter was added.
</li>
<li>
Clarified that <tt>jwk_url</tt> and
<tt>jwk_encryption_url</tt> refer to
documents containing JWK Sets - not single JWK keys.
</li>
<li>Re #601 add initiate_login_uri for unsolicited request
</li>
</ul>
<p>-12</p>
<ul class="text">
<li>Made application_type REQUIRED and added an explanation about redirect_uris registration
</li>
<li>Section 2.1 clarification that updates replace all parameters previously set.
</li>
<li>Section 2.3 add rotate_secret to invalid client_id error
</li>
<li>Added registration_access_token for updating and made client secret optional
</li>
<li>added registration_access_token to example response
</li>
<li>removed client_id from request as the client_id is implicit in the access token for updates
</li>
<li>Changed redirect_uris from RECOMMENDED for code and REQUIRED for implicit to REQUIRED
</li>
<li>Changed 2.1 to only allow access_token as a parameter if type is rotate_secret
</li>
<li>Fixed reference in application_name and added example of ja-Hani-JP encoded name.
</li>
<li>Made application_type OPTIONAL with web as the default
</li>
<li>Fixes #642 - Registration separates application errors from bearer.
</li>
<li>Updated references to OAuth and Bearer to reflect current drafts
</li>
<li>Fix typo error_description
</li>
<li>Re #642 change error to error_code in 2.3 example
</li>
<li>
Fixed #614 - Discovery - 3.2 Distinguishing between signature and integrity parameters for HMAC algorithms.
This fix tracks the parameter changes made to the JWE spec in draft-ietf-jose-json-web-encryption-06.
It deletes the parameters {userinfo,id_token}_encrypted_response_int.
It replaces the parameters {userinfo,id_token,request_object,token_endpoint}_algs_supported
with {userinfo,id_token,request_object,token_endpoint}_signing_alg_values_supported
and {userinfo,id_token,request_object,token_endpoint}_encryption_{alg,enc}_values_supported.
</li>
<li>
Fixed #673 - Registration 2.1: Rename require_signed_request_object to request_object_alg.
The actual change was to rename
require_signed_request_object to request_object_signing_alg,
following the naming convention used in the resolution to issue #614.
</li>
<li>Fixed #666 - JWS signature validation vs. verification.
</li>
<li>Referenced OAuth 2.0 RFCs -- RFC 6749 and RFC 6750.
</li>
<li>Fixed #674 - Description of require_auth_time.
</li>
</ul>
<p>-11</p>
<ul class="text">
<li>Made <tt>rotate_secret</tt> a separate registration
request type and stop client secret changing with every response, per issue #363
</li>
<li>Changed default ID Token signing algorithm to RS256, per issue #571
</li>
<li>Changed client.example.com to client.example.org, per issue #251
</li>
<li>Added text for authz to the registration endpoint, per issue #587
</li>
<li>Use standards track version of JSON Web Token spec
(draft-ietf-oauth-json-web-token)
</li>
</ul>
<p>-10</p>
<ul class="text">
<li>Split encrypted response configurations into separate parameters for alg, enc, int
</li>
<li>Removed extra "s" from signed response parameter names
</li>
<li>Add reference to JWA
</li>
<li>Updated Notices
</li>
<li>Updated References
</li>
</ul>
<p>-09</p>
<ul class="text">
<li>Removed erroneous spanx declarations from example
</li>
<li>Fixed example in Sec 2.2 to show expires_at
</li>
<li>Fixed Sec 2.1.1 to clarify it is the registration server doing the certificate check
</li>
<li>Fixed Sec 2.1.1 example to include http portion of response
</li>
<li>Fixed #542 Sec 2.1 userinfo_signed_response_algs fixed to say signature. Clarify response is signed.
</li>
<li>Fixed Sec 2.1 userinfo_encrypted_response_algs Clarify response is JWE containing JWT
</li>
<li>Fixes #529 Sec 2.3 Clarify error response is Bearer and fix example
</li>
<li>Add default_max_age registration parameter
</li>
<li>Add default_acr registration parameter
</li>
<li>Add require_auth_time registration parameter
</li>
</ul>
<p>-08</p>
<ul class="text">
<li>Replaced token_endpoint with a defined term Token Endpoint [OAuth 2.0]
</li>
<li>Added policy_url parameter
</li>
<li>Renamed expires_in but expires_at
</li>
<li>Registration Endpoint can be OAuth Protected
</li>
<li>Added parameters for requiring encryption and/or signing of OpenID Request Object, UserInfo and ID Token
</li>
<li>Added token_endpoint_auth_type and list of valid authentication types
</li>
<li>Added JWK and X509 URLs for signature and encryption
</li>
<li>Added user_id_type
</li>
<li>Changed sector_identifier to sector_identifier_url and added URL verification
</li>
<li>Use RFC 6125 to verify TLS endpoints
</li>
<li>Changed 'contact' to 'contacts', 'redirect_uri' to 'redirect_uris'
</li>
<li>Changed redirect_uris to RECOMMENDED for code flow and REQUIRED for implicit flow Clients
</li>
<li>Removed js_origin_uri
</li>
<li>Added section about string comparison rules needed
</li>
<li>Clarified redirect_uris matching
</li>
<li>Update John Bradley email and affiliation for Implementer's Draft
</li>
</ul>
<p>-07</p>
<ul class="text">
<li>Changed request from posting a JSON object to being HTTP
Form encoded.
</li>
<li>Added x509_url to support optional encryption.
</li>
</ul>
<p>-06 </p>
<ul class="text">
<li>Changes associated with renaming "Lite" to "Basic Client" and
replacing "Core" and "Framework" with "Messages" and "Standard".
</li>
<li>Numerous cleanups, including updating references.
</li>
</ul>
<p>-05 </p>
<ul class="text">
<li>Changed <tt>redirect_url</tt> to <tt>redirect_uri</tt> and <tt>js_origin_url</tt>
to <tt>js_origin_uri</tt>.
</li>
</ul>
<p>-04 </p>
<ul class="text">
<li>Correct issues raised by Johnny Bufu and discussed on the
7-Jul-11 working group call.
</li>
</ul>
<p>-03 </p>
<ul class="text">
<li>Incorporate working group decisions from 5-Jul-11 spec call.
</li>
<li>Consistency and cleanup pass, including removing unused
references.
</li>
</ul>
<p>-02 </p>
<ul class="text">
<li>Incorporate working group decisions from 23-Jun-11 spec call.
</li>
</ul>
<p>-01 </p>
<ul class="text">
<li>Initial version.
</li>
</ul>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Nat Sakimura</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Nomura Research Institute, Ltd.</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:n-sakimura@nri.co.jp">n-sakimura@nri.co.jp</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">John Bradley</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ping Identity</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Michael B. Jones</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td></tr>
</table>
</body></html>