request_authentication_signing_alg_values_supported is missing

[Torsten Lodderstedt]

The federation spec introduces a new metadata parameter “request_authentication_methods_supported“, which includes the value “private_key_jwt” but does not define a corresponding parameter “request_authentication_signing_alg_values_supported” publishing the supported signature algorithms for private_key_jwt.

[Giuseppe De Marco]

In our implementation we adopted the assumption that request_object_signing_alg_values_supported and request_object_encryption_enc_values_supported were adequate to cover this requirement

The RP that makes the request object uses these two definitions to identify the working encoding

[Michael Jones]

I’ll note that https://datatracker.ietf.org/doc/html/rfc8414 has token_endpoint_auth_methods_supported and also defines token_endpoint_auth_signing_alg_values_supported`, rather than relying on request_object_signing_alg_values_supported. Therefore, by analogy, I believe we should define `request_authentication_signing_alg_values_supported`, as Torsten suggests.

I’ll note that the examples include token_endpoint, token_endpoint_auth_methods_supported, and token_endpoint_auth_signing_alg_values_supported. We should verify that these are the correct values and none of them should be corrected to request_authentication_methods_supported or request_object_signing_alg_values_supported.

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/160 .

[Giuseppe De Marco]

The authentication request, if signed, unsigned or encrypted, must be a JWT object. Sincerely I see no reason to add more parameters, are you really sure to add that?

In OIDC core I read

request_object_signing_alg_values_supported
    OPTIONAL. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for Request Objects, which are 
    described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. These algorithms are used both when the Request Object is passed 
    by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support 
    none and RS256.

In OIDC Fed we use the authorization request objects. Why is it necessary to add these two additional claim metadata?

[Michael Jones]

Giuseppe raises a good point that we could use request_object_signing_alg_values_supported for the request object signing algorithm. But if we do that, how would we specify the supported private_key_jwt signing algorithms?

[Giuseppe De Marco]

private_key_jwt (rfc7523) is an authz mechanism for token endpoint. I can't see how private_key_jwt could be used to authz endpoint or any other oidc endpoint. We may protect the introspection endpoint with private_key_jwt but that's oauth2 (or igov profile ..)

In token endpoint private_key_jwt already has its definitions, token_endpoint_auth_signing_alg_values_supported and also encryption alg and enc values.

[Giuseppe De Marco]

Ok Mike, my bad, that's for PAR.

PAR Is a authorization mechanism that can use private_key_jwt.

I'd like to have a single parameter to define the supported authz sign/enc algs, I admit that I'd prefer to simplify and reusing what we already have, without adding any other claim in the As/Op metadata

‌

[Giuseppe De Marco]

@Torsten Lodderstedt in PAR specs I read

The rules for client authentication as defined in [RFC6749] for token

endpoint requests, including the applicable authentication methods,

apply for the PAR endpoint as well.

…

Due to historical reasons there is potential ambiguity regarding the

appropriate audience value to use when employing JWT client assertion

based authentication (defined in Section 2.2 of [RFC7523] with

"private_key_jwt" or "client_secret_jwt" authentication method names

per Section 9 of [OIDC]).

For authz endpoint we have the request object and I don't see the importance to have private_key_jwt also in PAR or, changing point of view, we may say that the request object in authz endpoint Is equivalent to private Key jwt for token endpoint… they only have different parameters names and submission methods. The compositions of their internal claims Is something handly after all …

I mean that we're using a similar auth (jwt) with different names and http submission methods

‌

‌

[Roland Hedberg]

So, this seems to be a question on granularity. Do one want to be able to say that at this endpoint /use case with this type of object I support these algorithms or is it enough to be able to say that for this type of object I support these types of algorithms. Personally I think that excess granularity is not worth the cost.

[Michael Jones]

In other places in the Connect and OAuth specs, we do define distinct *_alg_values_supported metadata parameters for distinct signed objects. Having talked with Roland and Andreas at OSW, about this, I believe should do the same here and merge https://bitbucket.org/openid/connect/pull-requests/160 .

[Giuseppe De Marco]

this can be closed right now, following this PR that has been merged
https://bitbucket.org/openid/connect/pull-requests/160

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/160