Should token_endpoint_auth_signing_alg be considered?

[TakahikoKawasaki]

OpenID Connect Dynamic Client Registration 1.0, Section 2. Client Metadata, defines the token_endpoint_auth_signing_alg client metadata as follows.

OPTIONAL. JWS [JWS] alg algorithm [JWA] that MUST be used for signing the JWT [JWT] used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. All Token Requests using these authentication methods from this Client MUST be rejected, if the JWT is not signed with this algorithm. Servers SHOULD support RS256. The value none MUST NOT be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used.

Should server-side implementations of the attest_jwt_client_auth client authentication method take the client metadata into consideration? To be concrete, should server-side implementations reject requests when the Client Attestation PoP JWT is not signed with the algorithm specified by the client metadata if the metadata is set, or may server-side implementations ignore the client metadata when processing the attest_jwt_client_auth client authentication method?

[tplooker]

In general I agree that a piece of metadata like this is useful, the other option which springs to mind is to reuse the token_endpoint_auth_signing_alg metadata property for this auth method instead of defining a new metadata element.

[tplooker]

Which ever metadata element we choose for this purpose it should apply to BOTH the attestation JWT and PoP JWT.

[tplooker]

We would also need to clarify that the signing algorithm used for the attestation JWT and PoP JWT do not need to be the same however both would need to be permitted for the client making the request to the authorization server.

[tplooker]

Considering this more I think it is safer to have a new seperate metadata element for signalling support algorithms for this client authentication mechanism.

[panva]

I believe the re-use of both AS discovery token_endpoint_auth_signing_alg_values_supported and Client token_endpoint_auth_signing_alg is the right way to move forward and needs to be mentioned in the document.

---

token_endpoint_auth_signing_alg_values_supported

JSON array containing a list of the JWS signing algorithms supported by the token endpoint for the signature on the JWT used to authenticate the client at the token endpoint

This fits.

---

token_endpoint_auth_signing_alg

JWS alg algorithm that MUST be used for signing the JWT used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods

This doesn't fit but only needs an updated description.