Request-Provided Claim Values Support

[milux]

This is a feature suggestion for support of claims that are copied from the user's request.
The main idea behind this feature is to bind specific, (server side) preconfigured dynamic attributes into issued tokens, whereas the values of these attributes are defined upon request by the client.

Typical use cases include:

• fingerprints of short-lived TLS certificates used for communication among clients
• ephemeral or short-lived public keys that are to be bound to the client identity

PR to follow.

[bellebaum]

An alternative implementation using the claims request defined by OpenID Connect has been implemented in version 1.2.0 .
This should take care of the above use cases. If the need for further extensions arises, feel free to open a new issue.
Closing.

[schanzen]

Note that for the purposes of the OP, the claims request parameter is not useful.
The issue being that the client credentials authorization flow with JWTs does not need an authorization request and thus has no way of providing the parameter.
Also, this requires the use of OIDC (scope includes openid) which also does not apply in the use case.

[bellebaum]

Correct, which is why we deviate from the OIDC core spec as follows:

• The claims parameter can be used at both the /authorize and /token endpoints.
• Besides id_token and userinfo (the latter not yet implemented), the request parameter has an additional access_token claims sink, allowing to request claim values within the access token. This makes usage without OIDC possible.

This behaviour is documented in this expired RFC draft, which our README links to. The configuration options are described in our Wiki.

A comparison to the proposed changes by @milux :

• The current approach relies mostly on existing code due to its similarities to standardized OIDC behaviour, which means less maintenance for different methods achieving essentially the same goal.
• The current approach is already well documented, even if in an expired draft.
• @milux `s approach had the added benefit of protecting the integrity of the requested values due to their inclusion in the JWT Bearer. This would have allowed to relay the Authentication requests via third parties. After talking to @milux it became clear this was not a concern for the use case.
• The above draft also defines claims sinks like *, meaning "to be included in all applicable claims sinks", which can be quite useful.

[bellebaum]

@schanzen Are there any plans for an alternative, more standards based solution (even if just emerging) or can we close this issue again for the time being?

[schanzen]

We should do this using the client assertion (JWT). Using a query parameter is specifically violating the standard:

The 
authorization server MUST ignore
   unrecognized request parameters.  Request and response parameters
   MUST NOT be included more than once.

[bellebaum]

This requirement seems more like a statement to allow for backwards compatibility of future revisions, in that additional parameters introduced in such revisions should not break older Auth Servers which do not recognize them.

In other words: unrecognized request parameters would refer to parameters unknown to the server, not the spec.

A bit off-topic, but the second sentence might pose a problem in other ways, as it is repeated for both the Authorization- and Token endpoints. RFC 8707 however states:

Multiple "resource" parameters MAY be
      used to indicate that the requested token is intended to be used
      at multiple resources.

[schanzen]

Ok. Well. LGTM in general. We can always change it to a property in the JWT if necessary later.