OpenID Connect
Dynamic Client Registration 1.0 - draft 13

Abstract

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
RESTful manner.

This specification describes how an OpenID Client can obtain the necessary
client credentials required by the OpenID Connect protocol suite.

1.
Introduction

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.

2.
Client Registration Endpoint

The Client Registration Endpoint is an OAuth 2.0 Protected Resource that returns registration information for
the Client to configure itself for the OpenID Provider.
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.

2.1.
Client Registration and Client Update Request

Client Update Requests replace all previous parameters set for a
client_id.

Clients MUST send requests encoded as a POST with the following
parameters added to the HTTP request entity-body using
"application/x-www-form-urlencoded" format:

type

REQUIRED. Values are client_associate
(for new registrations), rotate_secret
to request rotation of the client_secret, and
client_update (for updating parameters of an existing
client_id). If rotate_secret is used
no optional parameters other than access_token
may be included in the request.

redirect_uris

REQUIRED.
A 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.

application_type

OPTIONAL. The default if not specified is
web. The defined values are
native
or web. Web clients MUST only register https: Scheme
redirect_uris that do not use localhost as the hostname.
Native clients MUST only register redirect_uris using custom
URI schemes or http: scheme URI using localhost as the hostname. Authorization
Servers may place additional constraints on Native such as not supporting the token
response_type. 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. A 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.

tos_url

OPTIONAL. A 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.

jwk_url

OPTIONAL. URL for the Client's
JSON Web Key Set [JWK] (Jones, M., “JSON Web Key (JWK),” December 2012.) 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.

jwk_encryption_url

OPTIONAL. URL for the Client's
JSON Web Key Set [JWK] (Jones, M., “JSON Web Key (JWK),” December 2012.) 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.

x509_url

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.

x509_encryption_url

OPTIONAL. URL for the Client's PEM encoded X.509
Certificate or Certificate chain
that is used to encrypt
the ID Token and User Info Endpoint Responses to the Client.
If the Client registers both jwk_encryption_url
and x509_encryption_url,
the keys contained in both formats SHOULD be the same.

OPTIONAL. The 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. (default max authentication age):
Type: Integer
- Specifies that the End-User must be actively authenticated if
any present authentication is older than the specified
number of seconds. (The 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.

require_auth_time

OPTIONAL. (require auth_time claim):
Type: Logical
- If the value is true, then the auth_time
claim in the id_token is REQUIRED.
The returned Claim Value is the number of seconds from
1970-01-01T0:0:0Z as measured in UTC until the date/time that the
End-User authentication occurred. (The auth_time Claim semantically
corresponds to the OpenID 2.0 PAPE auth_time response parameter.)
The auth_time claim request in the request object overrides this setting.

default_acr

OPTIONAL. (default authentication context class reference):
Type: String
- Specifies the default value that the Authorization server must use
for processing requests from this client. The
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.

The Client Registration Endpoint is an OAuth 2.0 Protected Resource that
may require an Access Token for client_associate
requests in order to restrict registration requests
to only authorized Clients.

For client_update
requests the registration_access_token is used as the
Access Token to restrict update access to only the registered client.

2.1.1.
sector_identifier_url Validation

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.

3.
String Operations

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.

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.

Appendix A.
Acknowledgements

Appendix B.
Notices

Copyright (c) 2012 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.

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.

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.

-11

Made rotate_secret a separate registration
request type and stop client secret changing with every response, per issue #363

Changed default ID Token signing algorithm to RS256, per issue #571

Changed client.example.com to client.example.org, per issue #251

Added text for authz to the registration endpoint, per issue #587

Use standards track version of JSON Web Token spec
(draft-ietf-oauth-json-web-token)