openid / federation

8 stars 4 forks source link

Notes on metadata policy operators #11

Open OIDF-automation opened 5 months ago

OIDF-automation commented 5 months ago

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2156

Original Reporter: gzachmann

Hi,

while going through the metadata policies operators of the newest spec version and found some things to comment on. I wanted to hear your opinion on them, if those are valid points or might already have been discussed before.

    a) essential is true as soon as any entity in the chain says so, i.e. subordinates cannot overwrite true with false - if they try it does not matter, the chain is still valid
    b) if a subordinate defines essential=false and a superior defined essential=true this MUST result in a policy error.

OIDF-automation commented 5 months ago

Imported from AB/Connect bitbucket - Original Commenter: mbj

Thanks for your thoughts, Gabriel. A few reactions to your suggestions…

Thanks again!

OIDF-automation commented 4 months ago

Imported from AB/Connect bitbucket - Original Commenter: gzachmann

On value:

I can see your point on default overwriting default.

For essential, I originally assumed interpretation (a), but it was not clear to me what the spec currently says, I don’t care too much what it will be in the end, it just should be more clear.

vdzhuvinov commented 19 hours ago

@zachmann Hi Gabriel,

I studied PR https://github.com/openid/federation/pull/111 - "Policy operators: no restrictions when combining add and superset_of".

Every operator definition follows an identical template. This template includes (among other things):

It is correct that if a software doesn't implement the combination checks for add + superset_of the order of applying superset_of after add will enforce the rule nevertheless. The combination spec, as description or result, is still valid however:

add: MAY be combined with subset_of, in which case the values of add MUST be a subset of the values of subset_of.

subset_of: MAY be combined with add, in which case the values of add MUST be a subset of the values of subset_of.

The current combination specs were worded like this to make it easier for policy designers to reason about operators and how they may be combined without having to also consider the order of the operator application. If we remove the conditionals ("... in which case...") this feature will be lost to the reader.

I see two ways going forward:

I'm not in favour of completely removing the normative description, because this will make it more difficult for the reader to figure out the allowed combinations.