Semantics of One-of

[David W Chadwick]

The latest version of OpenID Connect Federation (draft 20, June 14) defines the “one_of” policy operator. However, if more than one value is specified by the trust anchor, and the leaf entity does not specify this metadata claim, then which of the one_of values should be used by the entity that has retrieved the metadata and metadata policies? The example given in the specification uses logo_uri with two values in the policy, and none in the leaf entity, and then lists just one of them in the resulting leaf entity’s metadata. No text defines how this value was chosen.

Suggest add clarifying text that if multiple values remain then the first one from the one_of set should be used. This would then agree with the example.

[Giuseppe De Marco]

Yes, we can do that and thank you for the suggestion!

[David W Chadwick]

Just a final note. This turns the semantics of “one_of” from a set to a sequence.

[Giuseppe De Marco]

The text says

one_of
The value of the parameter MUST be one of the ones listed in this directive.

In the example 5.1.8 Policy Example we have a policy of id_token_signed_response_alg and this claim is not present in the original RP metadata. The final metadata shows one of the mandatory value configured in the policy. Having read the specs we know that the value must be one of the ones, this means that’s is an implementation option decide which will be the final value. The same with logo_uri in the example.

[David W Chadwick]

Whilst we ‘know’ the value must be one of the one-of’s, we do not ‘know’ that it is an implementation option without being told this. So the clarifying text can say ‘which value is chosen is an implementation option’ or words to that effect, then we will ‘know’ it is an implementation’s choice.

[Michael Jones]

This was discussed on the 12-Aug-22 Federation editor's call. We propose to add text saying that it's an implementation choice which of the one-of values to use in any given circumstance.

[Michael Jones]

Giuseppe to create a PR.

[Giuseppe De Marco]

Done here
https://bitbucket.org/openid/connect/pull-requests/273/chore-federation-metadata-policy

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/273