[Openid-specs-ab] Issue #1589: Proposal for supporting "client discovery" in OIDC / OAuth2 (openid/connect)

[Tobias Looker]

New issue 1589: Proposal for supporting "client discovery" in OIDC / OAuth2
https://bitbucket.org/openid/connect/issues/1589/proposal-for-supporting-client-discovery

Tobias Looker:

**Background**

The client\_id parameter in OIDC and OAuth2 is used by the client to identify itself to the AS. The assumption is in most cases that this ID is allocated by the AS via a registration process supported by the AS, relevant extract from the RFC below

```
The authorization server issues the registered client a client
identifier -- a unique string representing the registration
information provided by the client.  The client identifier is not a
secret; it is exposed to the resource owner and MUST NOT be used
alone for client authentication.  The client identifier is unique to
the authorization server.
```

In industry the predominant pattern used is for the AS to assign client id’s to clients via an out of band registration process. 

To support a more dynamic relationship between clients and AS’s, dynamic client registration was standardised first in OpenID then back ported to OAuth2 later. However this model has some challenges/downsides including

1. How to appropriately limit registration requests
2. Requires a pre-flight request by the client to AS to register before making an authorisation request
3. Can require the client to manage state with various AS’s, e.g which the client is registered with and if so whats its client id

More recently via the OpenID federation specification, the concept of “automatic registration” has emerged where the client provides a resolvable identifier such as a URL that the AS can resolve to fetch the clients metadata but in a specific process designed primarily to serve its use cases.

**Proposal**

The intent of this issue is to discuss whether generalising the “automatic registration” mode or mechanism currently defined in the openid federation spec is worth considering for other usecases.

If so I believe its best framed as a new concept for clients and I’d offer the term “client discovery” as the way to describe it. The intent would be to describe a way that a client can make it self discoverable to an OP/AS in the same way an OP/AS makes it self discoverable to a client today with openid discovery.

The crux of the proposal would be for a new request parameter `client_discovery` to be supported on the authorise request that when processed by a supporting OP/AS would indicate that the `client_id` value supplied is infact a URL that should be resolved to obtain the clients metadata, instead of trying to make sense of the value amongst existing registered clients.

An example request might look like

```
  HTTP/1.1 302 Found
  Location: https://server.example.com/authorize?
    response_type=code
    &scope=openid%20profile%20email
    &client_id=https%3A%2F%2Fclient.example.org
    &client_discovery=true
    &state=af0ifjsldkj
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
```

Where the AS/OP would execute the following request to obtain the clients metadata

```
GET /.well-known/client-metadata HTTP/1.1
  Host: client.example.org
```

Which would return a JSON based object containing the registration parameters described in OpenID Dynamic Client registration.

There would potentially also be caching considerations for the client metadata that could be added \(e.g HTTP request caching\) to limit how often an AS/OP needs to actually resolve the clients ID.

**Why**

There are several applications within the OIDC4SSI ecosystem that would benefit from an alternative mechanism to dynamic client registration being defined that does not suffer the same tradeoffs as listed above.

Note - SIOP does also reference the federation spec for this feature currently, so by separating this would perhaps help to clarify the generalised usage of the feature for other applications.