Interoperability concerns with older deployments

[MichaelFraser1999]

This document is written with the intention of allowing an RP to indicate a support for a range of values for certain parameters. This is fine for deployments that understand this document however, especially in the case of openid federation, the chance of encountering a deployment that has not yet implemented support for the metadata defined in this document is non-zero. This could lead to some complications:

Example 1
An RP defines id_token_signing_alg_values_supported as [ES256, PS256] to be FAPI2 compliant. It can support either and as such does not specify a value for id_token_signed_response_alg. The default for id_token_signed_response_alg if not specified however is RS256. A openid provider deployment that does not understand this document would default to a value not supported by the RP (inadvertently as it does not understand how to process the values indicating otherwise).

Example 2
An RP defines userinfo_signing_alg_values_supported as [ES256, PS256]. Once again, it can support either and does not specify a value for userinfo_signed_response_alg. In this case the default behaviour for an openid provider that does not understand this document is to not sign the ID Token at all and return the raw JSON.

In order to mitigate this scenario, I would suggest we recommend deployments making use of the values in this document still set the singular version of the claim to ensure interoperability with older deployments. It could also be taken as an indication of preference yet highlighting that they can do other options if needed.

[MichaelFraser1999]

Raised #3 as some suggested text to resolve this

[panva]

For the sake of having everything in one place, linking my comments on the mailing list archive