[Federation] Policy language: disambiguation about one_of and essential operators

[Pasquale Barbaro]

from https://openid.net/specs/openid-connect-federation-1_0.html, section 5.1.2:

It is not clear as it is right now.
The specs for essential operator say: "if essential is missing an operator, it is treated as if set to false"
and the specs for one_of say "the presence of metadata parameter becomes optional when the directive occurs in conjunction with an essential set to false"
So it almost seems to me that: if I don’t put the essential operator, and thus it is condidered as set to "false" and at the same time i put the one_of operator, the essential is considered as "false" and so the presence of parameter should be optional.

In my opinion it should be specified that one_of change its behavior only if you explicitely use "essential: false" along with it.

[Michael Jones]

As discussed on the 17-Feb-23 Federation Editors' call, we think that the right fix for this is to remove the clause “The presence of the metadata parameter becomes optional when the directive occurs in conjunction with an essential set to false.”

@Roland Hedberg notes that other similar text should also be removed.

[Michael Jones]

The language to be removed also occurs in the descriptions of subset_of and `superset_of`.

[Giuseppe De Marco]

the PR below solves this Issues
https://bitbucket.org/openid/connect/pull-requests/458

[Vladimir Dzhuvinov]

I would like to propose the following:

When essential is false or defaults to false (by being omitted) and the metadata parameter is missing, then the one_of , subset_of and superset_of checks do not apply.

When essential is true , then the metadata parameter must be both present and it compliant with any one_of , subset_of and superset_of checks.

This will remove, as Pasquale has noticed, the internal contradiction between essential and the set checks in the current policy language, which says the that a metadata parameter becomes optional when essential is omitted, but then the set checks (e.g. one_of ) read that the value must be “such and such”.

The following two id_token_encrypted_response_alg policies thus become equivalent, and mean that only when id_token_encrypted_response_alg is present it must comply with the subset_of check:

"id_token_encrypted_response_alg": {
  "subset_of": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW"]
}

"id_token_encrypted_response_alg": {
  "essential": false,
  "subset_of": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW"]
}

And this id_token_encrypted_response_alg policy means that the metadata value MUST be present and MUST comply with the subset_of check:

"id_token_encrypted_response_alg": {
  "essential": true,
  "subset_of": ["RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW"]
}

Because Mike asked, the extra language for the one_of et all was introduced to address https://bitbucket.org/openid/connect/issues/1753/federation-expand-definition-of-the

[Pasquale Barbaro]

@Vladimir Dzhuvinov I think your proposal is good and it would remove ambiguity and contraddictions. Thanks for the policy examples (the last one should have “essential”: true but I think it’s just a typo)

[Vladimir Dzhuvinov]

@Pasquale Barbaro Thanks, I corrected the typo.

At a mini meeting at c2id we concluded that keeping the operators single-purpose makes them way easier to code. The one_of / subset_of / superset_of with the special essential:false behaviour in draft 27 turns out to be quite messy to implement, and will result in spaghetti code.

‌

[Giuseppe De Marco]

Closed by PR 458