Federation: Metadata policy: Current spec requires JSON object parsing which keeps the ordering of its members

[Vladimir Dzhuvinov]

Section 4.2 - Policy type combinations says this about value which implies that when parsing the JSON object for a policy metadata the order of the members must be kept in order to know which policy operations appear before value and which after it:

https://openid.net/specs/openid-connect-federation-1_0.html#rfc.section.4.2

Can be combined with one_of, subset_of and superset_of. Here the order matters. If value appear in a superiors policy statement then the others MUST be ignored. If value are defined by the subordinate then it MUST be a subset of subset_of, superset of superset_of and one of one_of.

This somewhat contradicts the JSON RFC which says

https://tools.ietf.org/html/rfc7159

An object is an unordered collection of zero or more name/value
pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array.

Here I see two possible solutions:

1. Add a note to implementers to use such JSON object parsing that the ordering of the members is preserved.
2. Modify the spec for combinations with value so that the validation / the actions taken need not rely on the ordering of the statements for a given parameter. The action of value is to force the parameter to be set to some value, which makes any other statements about the parameter redundant. My suggestion therefore is to simplify the spec and say that value must not be combined with other policy types, i.e. raise an error if this condition is detected.

‌

[Michael Jones]

I agree that we should not depend upon non-standard JSON parsing behaviors. Roland, how do you think we should resolve this?

[Roland Hedberg]

I like Vlad’s 2nd proposal.

[Roland Hedberg]

The ordering of the members in a policy metadata object should not depend in the order of the members.

The text you refer to talks about policy metadata objects from a trust chain which is by definition ordered.

There is no rules in the specification for combinations of policies in one metadata policy statement right now. There probably should be.