[Openid-specs-ab] Issue #1751: [Federation] Automatic client registration: Add recommendations to prevent stuck clients (openid/connect)

[Vladimir Dzhuvinov]

New issue 1751: [Federation] Automatic client registration: Add recommendations to prevent stuck clients
https://bitbucket.org/openid/connect/issues/1751/federation-automatic-client-registration

Vladimir Dzhuvinov:

The automatic client registration will benefit from guidance to prevent stuck clients due to metadata, policy or multiple resolvable metadata. Stuck clients can potentially occur, because the metadata that an OP creates for the client is not communicated back to the client \(as opposed to dynamic client registration\). For example, for metadata parameters for which the OIDC / OAuth standards don’t define specify a default value, or the default value in the spec is not among the allowed when a federation policy is defined and the policy also has no default value, the RP has no good way to find out what value the parameter was given by the OP.

Example scenario of a stuck client due to undefined default value:

OP metadata:

```json
{
 "token_endpoint_auth_methods_supported":["private_key_jwt"],
 "token_endpoint_auth_signing_alg_values_supported":["RS256","RS512","ES256","ES512"],
 ...
}
```

RP metadata:

```json
{
 "token_endpoint_auth_method":"private_key_jwt"
}
```

OIDC specifies that `token_endpoint_auth_signing_alg` when omitted by the RP has no default value and the OP is free to pick one that it supports \(perhaps guided by the presence of suitable keys in the RP’s jwks\). RPs that use automatic registration have no way to find out what algorithm was picked, so its token request can potentially fail due to an `invalid_client` error.

Ways to prevent this:

1 - The RP can prevent itself from getting stuck by making sure it sets an algorithm in its RP metadata \(which must be supported by the OP\):

```json
{
 "token_endpoint_auth_method":"private_key_jwt",
 "token_endpoint_auth_signing_alg":"ES256"
}
```

2 - The federation operator \(trust anchor\) can prevent RPs from getting stuck by defining a suitable policy which _must_ specify a default value:

```json
"token_endpoint_auth_signing_alg": {
  "default": "RS256",
  "one_of" : ["RS256","ES256"]
}
```

‌

Example scenario of a stuck client with two trust anchors / intermediates that have different policies:

This can occur when two federations with different policies come together.

Trust anchor A policy:

```json
"token_endpoint_auth_signing_alg": {
  "default": "RS256",
  "one_of" : ["RS256","RS512"]
}
```

Trust anchor B policy:

```json
"token_endpoint_auth_signing_alg": {
  "default": "ES256",
  "one_of" : ["ES256","ES512"]
}
```

Here the RP may get stuck in two different ways:

1 - If the RP sets `token_endpoint_auth_signing_alg` in its metadata, e.g. to `RS256`, but the OP picks a trust chain leading to trust anchor B, which requires the `ESxxx` family of algorithms, the auto registration will fail at the policy check step.

2 - If the RP leaves the `token_endpoint_auth_signing_alg` undefined \(to prevent a policy failure\), it will register successfully, but it may still fail at the token endpoint with an `invalid_client` error if the JWT alg is not the expected one.

The way to prevent this:

The RP must use the optional `trust_chain` parameter in the request, to let the OP know which trust anchor it prefers. The `token_endpoint_auth_signing_alg` in its metadata may be left undefined \(to pick the default value\), or specify an alg explicitly.

‌

‌

‌