Consider new policy operator - intersects

[Stefan Santesson]

I just throw this in the mix in case you find this worth to adress.

While going through the policies we would like to apply I ran into a problem.

For cases like supported acr values, no one of the current operators seems to do the job. What I would need is a Value check that I choose to call “intersects” with the following meaning:

Holds an Array of values. If the metadata parameter is present at least one of its values MUST be one of those listed in the operator values.

Example: I like to require that at least one of the acr values [“loa3“, “loa4”,”eidas-substantial”,”eidas-high”] must be included. Additional acr outside of this list may be included.

We consider including this as an additional custom operator, but perhaps more implementers have a similar need. Thus offering it here for consideration.

[Michael Jones]

Would the one_of operator fill this need or is there a crucial difference?

[Stefan Santesson]

No. The one_of can only handle cases where the metadata consists of a single value. In my case the metadata could contain multiple values.

[Michael Jones]

subset_of computes interactions of sets of values. Combining that with essential to make sure that the resulting set is non-empty seems like it might do what you want. If not, what are the differences that your use cases need?

[Stefan Santesson]

No unfortunately this does not do what I want/need. 

Example: OP declares support of acr_values_supported set to["loa2", "loa3", "local-3"]

What we want now is to make sure (do a value check) that this set of values contains either “loa3" or "eidas-substantial". But we do NOT want to limit the values that are set in metadata. The rationale here is that we want to make sure that the OP is capable of offering at least one of these acr to all RP in the federation, but we don't want to limit e.g. voluntary use of the lower lever loa2 or locally defined acr if agreed upon between peers.

Using subset_of = ["loa3", "eidas-substantial"] will modify the metadata of the OP resulting in: acr_values_supported =["loa3"]

Using intersects = ["loa3", "eidas-substantial"] will not modify any values of the OP and will allow the OP metadata to remain as it was declared: acr_values_supported = ["loa2", "loa3", "local-3"]

‌

However, if the OP declared acr_values_supported set to["loa2", "local-3"] then subset_of combined with essential would indeed produce the same result as intersects as they would both conclude that the OP does not meet the requirements.

[Stefan Santesson]

After implementing this I have to change my mind regarding my prior statement that this operator can’t be merged in any meaningful way. 

This policy operator should be merged with the same logic as subset_of. That is, the merged policy operator is the intersection of the operators to be merged. 

This ensures that the result of applying the merged operator is within the boundary of both merged policy operators.

[Michael Jones]

Hi Stefan. It was great to sit down with you in person last week at TIIME. I’m going through the open issues in light of our discussions there.

There wasn’t consensus to add this operator during our discussions there. As noted then, the operator set can be extended if needed without changes to the specification.

Are you OK with us closing this issue on that basis?

[Stefan Santesson]

I’m fine with you closing this. I still think it is a missing logic and I think there are valid use-cases that this operator solves, that can’t be solved using the current operators.
I think it will be useful in particular for acr policy. E.g. you have to support one of {x, y, z} but you may also support any value outside of this group.

But since we can’t find consensus about it, I have to let this go and define it as a custom rule instead.

[Michael Jones]

Closing, per Stefan's comment.

[Stefan Santesson]

Actually. I have a final proposal before you close this.
The behaviour proposed here is actually what I think would be a better function for the operator “one_of”.

I personally would find it more useful to have “one_of” saying that the metadata must contain one of these values, than the current usage. If the target metadata parameter is single valued, the current logic would be retained, if the parameter is multivalued, the current logic isn’t very useful.

Just a thought. But probably too big change and too late.