[Openid-specs-ab] Issue #2135: [Federation] Metadata policy: The space-separated list of strings exception should apply only to the "scope" oauth_client metadata parameter (openid/connect)

[Vladimir Dzhuvinov]

New issue 2135: [Federation] Metadata policy: The space-separated list of strings exception should apply only to the "scope" oauth_client metadata parameter
https://bitbucket.org/openid/connect/issues/2135/federation-metadata-policy-the-space

Vladimir Dzhuvinov:

This is a proposal to narrow the scope of the “treat space-separated list of strings as JSON array” exception to apply only to the  `scope` OAuth client metadata parameter in RFC 7591 and not be generally applicable. Declaring this exception to be generally applicable to metadata values can have unintended consequences, when processing metadata parameters for which a Federation library doesn’t have knowledge of the underlying parameter syntax, and may end up breaking the principle of deterministic operation of  `metadata_policy`. I think we learned the lesson of the `scope` encoding in metadata and should discourage that in the new Federation spec.

[https://openid.bitbucket.io/connect/openid-federation-1\_0.html#section-6.1.1-9](https://openid.bitbucket.io/connect/openid-federation-1_0.html#section-6.1.1-9)

> Note that when a metadata parameter is defined as a space-separated list of strings, like `scope` in \[[RFC7591](https://openid.bitbucket.io/connect/openid-federation-1_0.html#RFC7591)\], the `subset_of`, `superset_of` and `default` operator values are still expressed as lists of strings. This language from \[[RFC6749](https://openid.bitbucket.io/connect/openid-federation-1_0.html#RFC6749)\] also applies to metadata parameters for which values can be expressed as a space-separated lists of strings: "If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope."

‌