Notes on metadata policy operators

[Gabriel Zachmann]

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.

• value: Why can it only be combined with essential? I think it should be possible to combine with all value checks, e.g. one IA might set a one_of policy value check and another IA/TA sets a value, this could still work perfectly fine.
• add: Combination with superset_of: I don't think we should have the requirement that the values from add MUST be a superset of superset_of. Only after add is done the result MUST be a superset of the values in superset_of.  I'd argue we could just strip the stated requirement, since the consistency with value checks is checked anyway later.
• default: Merging: Personally, I would like to have the possibility to merge default in the sense that superiors overwrite subordinate policies. This would enable a national federation to set another default than an intra-national-fed. Since default is rather weak (it's just a default, if the value is something else it's still fine) - I don't feel like a "conflict" between different IAs, is something critical/incompatible)
• superset_of: Combination with add: See above
• essential: Merging: The spec states that "If a Superior has specified essential=true, then a Subordinate MUST NOT change that." It's not completely clear to me what the meaning of 'MUST NOT change' is:

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.

[Michael Jones]

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

• I would be OK with a rule that says that value can be merged with one_of provided that the value value is in the one_of set of values. (Although since it would result in additional code, I’d want to be convinced that this is a worthwhile addition.)
• I can see the argument that add can be combined with superset_of provided that the result satisfies the superset_of.
• I disagree with default being used to override another default. This would violate the “Equal Opportunity“ principal at https://openid.bitbucket.io/connect/openid-federation-1_0.html#name-principles.
• For essential, I tend to favor your interpretation (a) - that it’s not an error if both true and false values are in the chain, but that if anywhere in the chain, the value true occurs then the result of the merge is true. Although my read of the spec currently is that it specifies (b).

Thanks again!

[Gabriel Zachmann]

On value:
- one_of was just an example, I would say value can be combined with all value checks, i.e. one_of, subset_of, superset_of, if the value from value is valid for those parameters. I don’t think that this would (generally) result in additional code, since the value check must be done anyways.
The exception might be subset_of: here we must make sure that only the value check part of this operator is done, not the value modifier part, i.e. implementations must explicitly check that the value from value is a subset of subset_of before/instead of applying the subset_of operator. For one_of and superset_of I would argue that no additional consistency check is required, since applying the operator already does the check (and does not modify the value).
So I would say combining value with one_of and superset_of should not be a problem, and not require additional code; I can see that it would be reasonable to not allow combination with subset_of, because of the additionally needed code, however, it also feels a bit inconsistent to me.
- I also currently do not see reasons against combining it with default, also no code is needed for that, value will be applied first, then default does nothing.

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.

‌

[Mark Haine]

Closed due to federation content migration to Github. Replacement issue is at https://github.com/openid/federation/issues/11