Open CDR-Register-Stream opened 3 years ago
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_signingalg? 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_responseenc 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.
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:
This last sentence:
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
token_endpoint_auth_signing_alg
?id_token_signed_response_alg
,id_token_encrypted_response_alg
andid_token_encrypted_response_enc
and why?This issue has been raised to encourage collaboration and collate feedback.