Policy Operators: allow combiniation of value with other operators if values dont conflict

[zachmann]

This PR is related to #11

While this might need more discussion, I think the value policy operator can be combined with other policy operators (originating from other intermediates), if they don't conflict.

[selfissued]

This was discussed on the 9-Oct-24 Federation editors' call. We'd like to get @rohe's view on this proposal.

[rohe]

I can't see that this allows us to do something that we can't do today.
On the other hand it adds complexity to the code.

[selfissued]

@zachmann can you please respond to @rohe's assessment of the situation? Thanks.

[selfissued]

We discussed this on the 23-Oct-24 Federation editors' call. We plan to close this in a week if no response is received.

[zachmann]

Sorry for the delayed response, I've fallen sick after my vacation.

In my opinion this does not (necessarily) add complexity to the code. The value operator sets the value, after that the other operators are applied according to their rules. I only intended to allow combining them, there is no special handling needed.

The benefit of this would be to allow authorities to set policy checks while one authority sets a value. As I see it, currently value is more or less unusable in a slightly complex federation, as soon as some one else also wants to define a policy on this parameter (unless it's coincidentally the same rule).
But I don't see the reason to fail if authority A says value: ES512 and authority B one_of: [ES256, ES512]

[rohe]

Is authority A higher up (closer to the TA) in the trust chain compared to B ?

[zachmann]

Does it matter? I think according to 6.1.1 Equal Opportunity it should not matter, if A or B is higher up.

[rohe]

What we have right now in the specification is the rule that an intermediate can not specify a policy that is less restrictive than the combined policy for its superiors in the trust chain.
What you @zachmann want, seems to be that the check for "less restrictive" should be done after the subordinates policy has been applied.
That is, is the resulting policy after the application of the subordinates policy "less restrictive" than if it was not applied? If so the subordinates policy according to you should be allowed.
Correct ?

This is quite a change in my mind.

[zachmann]

What we have right now in the specification is the rule that an intermediate can not specify a policy that is less restrictive than the combined policy for its superiors in the trust chain.

That's surprising for me (or might have misunderstood your comment). I always assumed it would not matter; it also does not seem logical for me. It should not be expected from an entity to know the superior policies. I always assumed the idea was that each federation entity can have their own independent policies.

If the superior policy would be one_of: [ES256, ES512] and the subordinate specifies one_of: [ES256, ES512, RS256], this should work without problems, even thought it's more permissive. Those will just be merged by the rules in the spec (intersection) and the result will be one_of: [ES256, ES512].

Of course the policy of an intermediate cannot result in something more permissive. If that would be the case it cannot be merged; but the policy itself can be more permissive, and will be adjusted in the merging process.

However, in this case I'm talking about the combination of different policy operators. Still I dont see why we should forbid this:
authority A says value: ES512 and authority B one_of: [ES256, ES512], nevertheless if A is on top of B or the other way round.

[vdzhuvinov]

I did a first pass over the PR, without analysing the individual combinations yet.

At present, every policy operator is specced according to a template, with the allowed combinations going into the "Combination with other operators in a metadata parameter policy:" sections.

The current operator combination rules primarily define which operators may be put together for a given metadata parameter, within the policy of a single entity. Which rules, by extension, also hold for the case when the operators are found in statements along the trust chain.

Policy architects are likely to read the current combination rules (and the proposed PR changes) as a description of which operators may be put together in a single policy statement. This PR however is primarily intended to spec combinations that may appear when policy statements in a trust chain get merged.

To illustrate, the PR combination of value and default doesn't make much sense within a single policy statement.

[zachmann]

Yes, that's right this PR is targeted only for the combinations that may appear when policy statements are merged; not for within a single entity statement.

I also wondered how it is currently intended and if it makes sense to differentiate between those cases. (Or if the merging case shouldn't be explicitly considered, and a simple note about it would be enough.)

[selfissued]

@vdzhuvinov, would it make sense for you to add a sentence or two to the draft explaining the above intent about operator combinations?

[vdzhuvinov]

@vdzhuvinov, would it make sense for you to add a sentence or two to the draft explaining the above intent about operator combinations?

I created a separate ticket for this, because it's related to the section that describes the general working of the metadata policies:

#129

[selfissued]

In my view, we should be evaluating changes to the policy language logic in terms whether they make the code to apply them simpler or more complex. Another lens to apply is whether the changes introduce or remove special cases.

One measure of simplicity is implementation complexity. The more "if" statements there are to satisfy special cases in the language, the worse off we are.

I'd be curious to hear people's evaluations of these proposed policy language changes from those perspectives. Thanks.

[Razumain]

Just for the note. I have written about this a long time ago.

I propose that there is a much simpler and fault tolerant way to approach policy processing that pretty much avoids all problems with the simplest of implementation logic.

Current approach:

• Having rules to be checked regarding what policies that can be combined and what policy values that are in conflic.
• Processing policies in a certain order to ensure consistency.

This is hard and complex, and does not guarantee a successful and uniform result in case you are using a custom policy.

Alternative suggested approach:

• Process all policy rules 2 times:
  • On first pass. Implement all value changing operations of each policy.
    • After this pass, no more changes are allowed to the metadata value
  • On second pass. Check consistency between each policy rule and the changed metadata value

It may feel redundant to process all policy rules 2 times, but from a logical standpoint, it is so much easier. If not each policy rule is consistent with the end result, you have a failure.

The only order or rules you need to apply is during the first pass (value modifiers). Here you need to apply rules like "value" and "default" in a logical order.

[vdzhuvinov]

@zachmann The Nimbus SDK implemented the proposed new combinations, after which we ran a thorough suite of about 3700 test vectors, including edge cases. No issues were found. These combos (plus three other changes that I intend to propose) will allow the policy language to work without faults even in dynamic federations, where the superior or subordinate policies may not be known in advance by the policy designers.

The test vectors can be downloaded here, with explanations:

https://connect2id.com/blog/metadata-policy-test-vectors-openid-federation

[selfissued]

This is incorporated into #177 . We will close this shortly unless reasons to keep it open are identified.