selfissued
commented
1 month ago This is a duplicate of https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp, which @Razumain states is not a Federation issue. We decided to close this one on the 29-Jul-24 working group call.
I posted this issue at https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp
I think this was posted in the right place, as the solution proposed below is not changing the OpenID federation specification. Instead it suggests an extension to the RP (and Oauth client metadata) to enhance policy expression for these entity types. On Michael's suggestion, I copy the issue here in case there is a discussion on the issue in this context.
OpenID Federation opens up the possibility for federation entities to publish one metadata record that is consumed by multiple peer entities.
For this to work properly, the federation entity need to be able to publish capabilities that can match more than one peer endpoint.
Unfortunately, the RP (and OAuth client) metadata parameters were not designed with this federated scenario in mind.
Example:
If an RP can support several different token_endpoint_auth_method options, it can still only signal a single value in its metadata.
If an RP can accept both RS256 as well as ES256 signatures from the OP, depending on what type of signature key the OP has, it can still only signal one option in id_token_signed_response_alg.
We have explored many ideas on how to solve this and we would like to offer the latest idea for consideration.
In this proposal, the way to fix this is NOT by doing anything in the OID fed document (more than identifying the solution). Instead the proposal is to do a metadata extension document for OpenID federation saying the following:
Proposal: Each metadata parameter name that provides a single value, where the RP/Client which to provide a list of acceptable values in the order of preference, that metadata parameter name can be extended by the string "[]". This forms the name of a companion metadata parameter with an array of values.
Example 1:
Example 2:
The semantics of these declarations are that the original parameter name is used by all legacy peers and is treated according to standard. Peers that suppor the metadata parameter array extension MAY use the corresponding parameter with the "[]" name extension to learn about the client/RP capabilities in the order of preference. If used, the array extension parameter overrides the original parameter.