[Openid-specs-ab] Issue #1163: Federation: Metadata policy: Current spec requires JSON object parsing which keeps the ordering of its members (openid/connect)

Vladimir Dzhuvinov 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
https://bitbucket.org/openid/connect/issues/1163/federation-metadata-policy-current-spec

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](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](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.

‌




More information about the Openid-specs-ab mailing list