OpenID Connect Dynamic
Client Registration 1.0 - discussion draft 17Nomura Research Institute, Ltd.n-sakimura@nri.co.jpPing Identityve7jtb@ve7jtb.comMicrosoftmbj@microsoft.comOpenID 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.This specification describes how an OpenID Client can obtain the
necessary client credentials required by the OpenID Connect protocol
suite.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 client_id can retrieve updated
registration information.The Client Registration Endpoint may be co-resident with the token
endpoint as an optimization in some deployments.Note: This specification will likely be modified to use the OAuth Dynamic Client Registration
Protocol 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.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 RFC 2119.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.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 OAuth 2.0, and
the terms defined by OpenID Connect
Messages 1.0.This specification defines the following additional terms:OAuth 2.0 Protected
Resource through which a Client can request new registration and
manage the metadata associated with itOAuth 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 operationsURL of an OAuth Bearer token protected
resource at which the client registration data may be obtained,
updated, and deletedThe Client Registration Endpoint is an OAuth 2.0 Protected Resource
through which a Client can request 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.In order to support open registration, the Client Registration
Endpoint SHOULD accept 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 OAuth 2.0 Bearer Token
Usage specification.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 application/x-www-form-urlencoded
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.[[Editor's Note (Nat): Why do we want it to be in POST params? There are so many of them and it is easier to do it in JSON with Accept: application/json and Content-Type: application/json just like SCIM? There are several advantages on it. (1) You do not have to URL encode the non-ascii strings. (2) it can be easily JWS signed. It is a big change, but if we want to do it, we have to do it now.]] REQUIRED. Space-delimited list of
redirect URIs. One of the URL MUST match the Scheme, Host, and
Path segments of the redirect_uri in
the authorization request.OPTIONAL. Kind of the application.
The default if not specified is web.
The defined values are native or
web. Web clients MUST only register
URLs using the https: scheme as redirect_uris; they MAY NOT use localhost as the hostname. Native clients
MUST only register redirect_uris using
custom URI schemes or URLs using the http:
scheme with localhost as the hostname.
Authorization Servers may place additional constraints on Native
clients. The Authorization server MUST verify that all the
registered redirect_uris conform to
the constraints. This prevents sharing a Client ID across
different types of Clients.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 OAuth 2.0. Access Tokens sent in the
authorization header must be bearer tokens .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.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 OpenID Connect Messages 1.0.OPTIONAL. URL that references a logo for
the Client application.OPTIONAL. Requested
authentication method for the Token Endpoint. The options are
client_secret_post, client_secret_basic, client_secret_jwt,
and private_key_jwt, as described in
Section 2.2.1 of OpenID Connect
Messages 1.0. Other Authentication methods may be defined
by extension. If unspecified or omitted, the default is client_secret_basic HTTP Basic Authentication
Scheme as specified in Section 2.3.1 of OAuth 2.0.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.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.OPTIONAL. URL for the Client's JSON Web Key
Set document containing key(s) that are used
for signing Token Endpoint Requests and OpenID Request Objects. If
jwk_encryption_url 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 x509_url and jwk_url,
the keys contained in both formats SHOULD be the same.OPTIONAL. URL for the Client's
JSON Web Key Set 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 jwk_encryption_url and x509_encryption_url,
the keys contained in both formats SHOULD be the same.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 x509_encryption_url is not provided, x509_url it is also used to encrypt the ID
Token and User Info Endpoint Responses to the Client. If the
Client registers both x509_url and
jwk_url, the keys contained in both
formats SHOULD be the same.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 jwk_encryption_url
and x509_encryption_url, the keys
contained in both formats SHOULD be the same.OPTIONAL. URL using the https: scheme to be used in calculating
Pseudonymous Identifiers by the OP. The URL references a file with
a single JSON array of redirect_uri
values. Please see .OPTIONAL. subject_type
requested for responses to this client_id.
The subject_types_supported element of
discovery contains a list of the supported subject_type
values for this server. Valid types include pairwise
and public.OPTIONAL. JWSalg algorithm
that MUST be required by the Authorization
Server. The valid values are listed in Section 3.1 of JWA. All OpenID Request Objects from this
client_id MUST be rejected if not
signed by this algorithm. Servers SHOULD support RS256.OPTIONAL. JWS alg algorithm required
for UserInfo responses. The valid values are listed in Section 3.1
of JWA. If this is specified the
response will be JWT serialized, and
signed using JWS.OPTIONAL. JWEalg algorithm
required for encrypting UserInfo responses.
The valid values are listed in Section 4.1 of JWA. If this is requested in combination with
signing the response will be signed then encrypted. If this is
specified the response will be JWT
serialized, and encrypted using JWE.OPTIONAL. JWE enc algorithm required
for symmetric encryption of UserInfo responses. The valid values
are listed in Section 4.2 JWA. If "userinfo_encrypted_response_alg" is
specified the default for this value is A128CBC+HS256.
If this is requested in combination with signing the response will
be signed then encrypted. If this is specified the response will
be JWT serialized, and encrypted using
JWE.OPTIONAL. JWS alg algorithm required
for the ID Token issued to this client_id.
The valid values are listed in Section 3.1 of JWA. The default if not specified is RS256. The public key for validating the
signature is provided by retrieving the document from the jwk_url element or the x509_url
element from discovery.OPTIONAL. JWE alg algorithm required
for encrypting the ID Token issued to this client_id.
The valid values are listed in Section 4.1 of JWA. If this is requested the response will be
signed then encrypted. The default if not specified is no
encryption.OPTIONAL. JWE enc algorithm required
for symmetric encryption of the ID Token issued to this client_id. The valid values are listed in
Section 4.2 of JWA. If "id_token_encrypted_response_alg" is
specified the default for this value is A128CBC+HS256.
If this is requested in combination with signing the response will
be signed then encrypted. If this is specified the response will
be JWT serialized, and encrypted using
JWE.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 max_age request parameter corresponds to the
OpenID 2.0 PAPE max_auth_age request
parameter.) The max_age claim in the
request object overrides this default value.OPTIONAL. Boolean value specifying
whether the auth_time claim in the
id_token is REQUIRED. It is REQUIRED
when the value is true. The auth_time claim request in the request object
overrides this setting.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 acr_values_supported
element of discovery contains a list of the supported acr values for this server. The acr claim in the request object overrides
this default value.OPTIONAL. URI using the https: 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
login_hint and iss
parameters and SHOULD support the target_link_uri
parameter.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 OpenID Connect Session Management
1.0.For example, a client could send the
following registration request to the Client Registration
Endpoint: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.The response also contains a Registration Access Token that is to
be used by the client to perform subsequent operations at the Self
URL, which is returned in the same response. All of the response items are returned as a JSON document with the following fields as
top-level members of the root JSON object.REQUIRED. A JSON object with a
member self, which in turn holds a
member href, a Self URL.[[Editor's note: This is a bit pedantic,
but is probably a correct way of doing it in link-rel style.
Other options may be to specify in this spec that the Self URL is
Registration Endpoint URL + ?client_Id=1234. ]]REQUIRED. The unique Client
identifier, MUST NOT be currently valid for any other registered
Client.OPTIONAL. The Client secret.
This MUST be unique for each client_id.
This value is used by confidential clients to authenticate to the
Token Endpoint as described in OAuth 2.0 Section 2.3.1.It is not
required for clients selecting a token_endpoint_auth_method
of private_key_jwt.REQUIRED. The
Access token to be used by the client to perform operations on the
Self URL.OPTIONAL. Specifies the timestamp
when the Client Identifier was issued. The timestamp value MUST be
a positive integer. The value is expressed in the number of
seconds since January 1, 1970 00:00:00 GMT. [[Editor's note: Added
back from oauth-dyn-reg-04]]OPTIONAL. Time at which the
client_secret will expire or 0 if it
will not expire. The time is represented as the number of seconds
from 1970-01-01T0:0:0Z as measured in UTC. See RFC 3339 for details regarding date/times
in general and UTC in particular.The client may request the client URL at the server to obtain the
current registered values about the client. To do so, the client sends
the HTTP GET request to the client URL.The clients sends the HTTP GET request to e client_url
.Upon successful request, the server returns the currently
registered metadata about this client, except the Client Secret or
Request Access Token.This operation updates a previously-registered client with new
metadata at the Authorization Server.The request is sent to the Self URL obtained from the client
registration response with the parameters described in Client Metadata
encoded in the entity body using the application/x-www-form-urlencoded
format.Parameters sent with this request are the same as the registration
request except for access_token,
which is the value received in the registration request.
If included in the request, valid values of Client Metadata fields
in this request MUST replace, not augment, the values previously
associated with this Client. Empty values in Client Metadata MUST be
taken as a request to clear any existing value of that field. Omitted
values in the Client Metadata MUST remain unchanged by the
Authorization Server. The Authorization Server MAY replace any invalid
values with suitable values.For example, a client could send the following request to the
Client Registration Endpoint to update the client registration in the
above example: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.The Authorization Server MUST NOT include the Client Secret or
Request Access Token in this response.These fields are returned in a JSON
Document as top-level members of the root JSON object.This operation allows a client to be de-registered/deleted from the
server.To delete the client from the server, the client sends HTTP DELETE
request to the client URL.Upon the successful request, the server returns a HTTP 200
response.When an OAuth error condition occurs, the Client Registration
Endpoint returns an Error Response as defined in Section 3 of the OAuth 2.0 Bearer Token Usage specification.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.The JSON object contains two members:Error code.Additional text description of the
error for debugging.This specification defines the following error codes:Value of client_id
is invalid.client_secret
provided for the access to the Self URL is not valid for the
provided client_id.Value of one or more redirect_uris is invalid.Value of one of the
configuration parameters is invalid.[[Editor's Note: This clause needs to be updated to read better.]]
Providers who use pairwise sub (subject)
values SHOULD support this element.It provides a way for a group of websites under a single
administrative control to have consistent pairwise sub
values independent of the individual domain names. It also provides a
way for Clients to change redirect_uri
domains without having to reregister all of their users.This is further described in Section 2.4.1 of OpenID Connect Messages 1.0.The value of the sector_identifier_url
must be a URL using the https: scheme that
references a JSON file containing an array containing redirect_uri values.The values of the registered redirect_uris
must be included in the elements of the array, or registration MUST
fail.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 client_id. Comparing Unicode
strings, however, has significant security implications.Therefore, comparisons between JSON strings and other Unicode strings
MUST be performed as specified below: Remove any JSON applied escaping to produce an array of Unicode
code points.Unicode Normalization MUST NOT be
applied at any point to either the JSON string or to the string it
is to be compared against.Comparisons between the two strings MUST be performed as a
Unicode code point to code point equality comparison.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.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.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.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 for more information
on using TLS.Requests to the Registration Endpoint for client_update
MUST have some rate limiting on failures to prevent the Client secret
from being disclosed though repeated access attempts.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.In a situation where the Authorization Server is supporting open
Client registration, it must be extremely careful with any URL provided
by the Client that will be displayed to the user (e.g. logo_url and policy_url).
A rogue Client could specify a registration request with a reference to
a drive-by download in the policy_url. The
Authorization Server should check to see if the logo_url
and policy_url have the same host as the
hosts defined in the array of redirect_uris.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 is the most recent version, but has very limited
actual deployment, and might not be readily available in
implementation toolkits. TLS version 1.0 is
the most widely deployed version, and will give the broadest
interoperability.To protect against information disclosure and tampering,
confidentiality protection MUST be applied using TLS with a
ciphersuite that provides confidentiality and integrity
protection.Whenever TLS is used, a TLS server certificate check MUST be
performed, per RFC 6125.This document makes no requests of IANA.Unicode Normalization Formsmarkdavis@google.comken@unicode.orgOpenID Connect Messages 1.0Nomura Research Institute,
Ltd.Ping IdentityMicrosoftGoogleSalesforceIllumilaOpenID Connect Session Management 1.0Nomura Research Institute,
Ltd.Ping IdentityMicrosoftGoogleGoogleJSON Web Algorithms (JWA)MicrosoftJSON Web Token (JWT)MicrosoftPing IdentityNomura Research Institute,
Ltd.JSON Web Signature (JWS)MicrosoftPing IdentityNomura Research Institute,
Ltd.JSON Web Encryption (JWE)MicrosoftRTFM, Inc.Cisco Systems, Inc.JSON Web Key (JWK)MicrosoftCopyright (c) 2013 The OpenID Foundation.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.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.[[ To be removed from the final specification ]]-17 discussion versionMoved Terminology section out of Introduction to form an
independent section and added several terminology definitions Deleted the operation parameter Deleted the rotate_secretAdded Client Read Request (GET) Added Client Delete Request (DELETE) Added "Self URL"Added _links Added Editor's Notes Changed the Japanese client name to make it sound more
naturalAdded issued_at Added client update example (that seems to be missing many
parameters that were present in the registration request example)
Cleand up the indents -16 Fixed #734 - Invalid JSON in examples.Fixed #736 - Client Update Operation Response: expires_at should
be removed from example.Fixed #735 - Require expires_at value in Client Register
response.Added Security Considerations section about TLS version
requirements and usage.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.-15 Fixed #708 - Registration access token requirement.-14 Changed the syntax of some elements to match the syntax used in
the OAuth Dynamic Client Registration draft. Specifically, changed
type to operation,
changed associate to register, and changed application_name
to client_name. Also changed the
responses of client_register and client_update to include full client
information instead of just the Client ID.Added Implementation Considerations section.Fixed #656 - Changed token_endpoint_auth_type
to token_endpoint_auth_method and token_endpoint_auth_types_supported to token_endpoint_auth_methods_supported.Fixed #698 - Inconsistent use of articles.Deleted javascript_origin_uris, which
is no longer present in Session.Reference and provide note to implementers about OAuth Dynamic Client Registration
Protocol.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.-13 Fixed #687 - Inconsistency between user_id
and prn claims. The fix changed these
names: user_id -> sub, user_id_types_supported ->
subject_types_supported, user_id_type -> subject_type, and prn
-> sub.Renamed acrs_supported to acr_values_supported for naming
consistency.Fixed #685 - The policy URL should be different from the
terms-of-service URL. A new tos_url
registration parameter was added.Clarified that jwk_url and jwk_encryption_url refer to documents
containing JWK Sets - not single JWK keys.Re #601 add initiate_login_uri for unsolicited request-12Made application_type REQUIRED and added an explanation about
redirect_uris registrationSection 2.1 clarification that updates replace all parameters
previously set.Section 2.3 add rotate_secret to invalid client_id errorAdded registration_access_token for updating and made client
secret optionaladded registration_access_token to example responseremoved client_id from request as the client_id is implicit in
the access token for updatesChanged redirect_uris from RECOMMENDED for code and REQUIRED for
implicit to REQUIREDChanged 2.1 to only allow access_token as a parameter if type is
rotate_secretFixed reference in application_name and added example of
ja-Hani-JP encoded name.Made application_type OPTIONAL with web as the defaultFixes #642 - Registration separates application errors from
bearer.Updated references to OAuth and Bearer to reflect current
draftsFix typo error_descriptionRe #642 change error to error_code in 2.3 exampleFixed #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.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.Fixed #666 - JWS signature validation vs. verification.Referenced OAuth 2.0 RFCs -- RFC 6749 and RFC 6750.Fixed #674 - Description of require_auth_time.-11Made rotate_secret a separate
registration request type and stop client secret changing with every
response, per issue #363Changed default ID Token signing algorithm to RS256, per issue
#571Changed client.example.com to client.example.org, per issue
#251Added text for authz to the registration endpoint, per issue
#587Use standards track version of JSON Web Token spec
(draft-ietf-oauth-json-web-token)-10Split encrypted response configurations into separate parameters
for alg, enc, intRemoved extra "s" from signed response parameter namesAdd reference to JWAUpdated NoticesUpdated References-09Removed erroneous spanx declarations from exampleFixed example in Sec 2.2 to show expires_atFixed Sec 2.1.1 to clarify it is the registration server doing
the certificate checkFixed Sec 2.1.1 example to include http portion of responseFixed #542 Sec 2.1 userinfo_signed_response_algs fixed to say
signature. Clarify response is signed.Fixed Sec 2.1 userinfo_encrypted_response_algs Clarify response
is JWE containing JWTFixes #529 Sec 2.3 Clarify error response is Bearer and fix
exampleAdd default_max_age registration parameterAdd default_acr registration parameterAdd require_auth_time registration parameter-08Replaced token_endpoint with a defined term Token Endpoint [OAuth
2.0]Added policy_url parameterRenamed expires_in but expires_atRegistration Endpoint can be OAuth ProtectedAdded parameters for requiring encryption and/or signing of
OpenID Request Object, UserInfo and ID TokenAdded token_endpoint_auth_type and list of valid authentication
typesAdded JWK and X509 URLs for signature and encryptionAdded user_id_typeChanged sector_identifier to sector_identifier_url and added URL
verificationUse RFC 6125 to verify TLS endpointsChanged 'contact' to 'contacts', 'redirect_uri' to
'redirect_uris'Changed redirect_uris to RECOMMENDED for code flow and REQUIRED
for implicit flow ClientsRemoved js_origin_uriAdded section about string comparison rules neededClarified redirect_uris matchingUpdate John Bradley email and affiliation for Implementer's
Draft-07Changed request from posting a JSON object to being HTTP Form
encoded.Added x509_url to support optional encryption.-06 Changes associated with renaming "Lite" to "Basic Client" and
replacing "Core" and "Framework" with "Messages" and "Standard".Numerous cleanups, including updating references.-05 Changed redirect_url to redirect_uri and js_origin_url
to js_origin_uri.-04 Correct issues raised by Johnny Bufu and discussed on the
7-Jul-11 working group call.-03 Incorporate working group decisions from 5-Jul-11 spec call.Consistency and cleanup pass, including removing unused
references.-02 Incorporate working group decisions from 23-Jun-11 spec call.-01 Initial version.