Feedback 180: Signing/Encryption algorithm negotiation use cases need to be explicitly defined

[CDR-Register-Stream]

Issue #79 moved the request_object_signing_alg response from optional to mandatory in order to explicitly inform the ADR what signing algorithm is to be used for request objects.

Further work is required to determine alignment to upstream standards and ensure appropriateness for each of the different negotiation types.

OpenID Connect Dynamic Client Registration 1.0 states the following:

request_object_signing_alg
OPTIONAL. JWS [JWS] alg algorithm [JWA] that MUST be used for signing Request Objects sent to the OP. All Request Objects from this Client MUST be rejected, if not signed with this algorithm. Request Objects are described in Section 6.1 of OpenID Connect Core 1.0 [OpenID.Core]. This algorithm MUST be 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 RS256. The value none MAY be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used.

This last sentence:

The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used.

raises the question, is the behaviour defined by issuer #79 appropriate?

The following questions needs to be discussed and outcomes defined to ensure signing negotiation is well defined

1. Should we be aligning to the OpenID Connect Dynamic Client Registration 1.0 specification?
2. Should this behaviour align for the field token_endpoint_auth_signing_alg?
3. How does the negotiation pattern differ for id_token_signed_response_alg, id_token_encrypted_response_alg and id_token_encrypted_response_enc and why?

This issue has been raised to encourage collaboration and collate feedback.

[anzbankau]

Thanks for raising this and the opportunity to provide further feedback.

In response to the questions posed:
1. Should we be aligning to the OpenID Connect Dynamic Client Registration 1.0 specification?
Yes, we support this as the best approach. This will also provide more flexibility to ADRs to use any algorithm (ES256 or PS256) if the field is left unspecified.

2. Should this behaviour align for the field token_endpoint_auth_signing_alg?
Yes both the fields have the same behaviour. But in the standards token_endpoint_auth_signing_alg field is a mandatory field in the DCR request.

3. How does the negotiation pattern differ for id_token_signed_response_alg, id_token_encrypted_response_alg and id_token_encrypted_response_enc and why?
As per underlying standard id_token_signed_response_alg, if not passed will be defaulted to RS256.
id_token_encrypted_response_alg and id_token_encrypted_response_enc are mandatory.

[CDR-Register-Stream]

#169 should also be covered in this review