[Openid-specs-ab] Issue #1163: Federation: Metadata policy: Current spec requires JSON object parsing which keeps the ordering of its members (openid/connect)
issues-reply at bitbucket.org
Thu Apr 2 15:57:59 UTC 2020
New issue 1163: Federation: Metadata policy: Current spec requires JSON object parsing which keeps the ordering of its members
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:
> 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
> 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.
More information about the Openid-specs-ab