[Federation] metadata policy - relying party, claim "scope"

[Giuseppe De Marco]

In the RP’s metadata the claim “scope” is defined in https://www.rfc-editor.org/rfc/rfc7591, Section 2 Client Metadata, as `String containing a space-separated list of scope values (as described in Section 3.3 of OAuth 2.0 [RFC6749])`

the best way to define a policy on the RP’s allowed claims is not defining a string but, instead, as it is an array of strings, as defined below:

      "scope": {
        "superset_of": ["openid"],
        "subset_of": ["openid", "offline_access"]
    },

Unfortunately this strategy may create an exception in the implementation that cannot apply array operators to a string value (scope).

do we have to specify a special implementation indication for this single claim (and for all those that expose a space-separated list of strings as a single string ), or do we have some alternative?

[Vladimir Dzhuvinov]

Good catch.

Would you post a link to the Python impl that you both have for this? To inform our decision how to approach this.

BTW we also have the OP metadata scopes_supported, using the same format.

Some brainstorming here:

How about defining a new op, e.g. split_string , to signal that the string must be split for the check?

"scope": {
        "split_string": true,
        "superset_of": ["openid"],
        "subset_of": ["openid", "offline_access"]
},

‌

[Giuseppe De Marco]

1. Python impl: we just don’t have the exception because the metadata_policy doesn’t set it as a voluntary claim ^_^'
2. split_string is a good proposal, will it work only for the scope claim? Do we have another parameter that acts like the RP’s scope claim?

‌

[Giuseppe De Marco]

note also that, in OIDC dynamic client registration we don’t have any explicit definition of the parameter scopes
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata

at the same time in OIDC Discovery the claim scopes_supported is, instead, a JSON Array
https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

if we don’t have any proposal or any better alternative, it seems that adding “split_string”, and apparently for this claim only (scope), is the best solution

[Vladimir Dzhuvinov]

Oh, true, the OP metadata scopes is a JSON array, what a mess

The client metadata scopes comes from the more general OAuth 2.0 spec:

https://www.rfc-editor.org/rfc/rfc7591#section-2

scope
String containing a space-separated list of scope values (as
described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client
can use when requesting access tokens. The semantics of values in
this list are service specific. If omitted, an authorization
server MAY register a client with a default set of scopes.

I +1 the split string approach. This is explicit and will not require a “hack”.

The split string must not affect the metadata parameter that gets output by the combined policy, because it will break the client metadata. Hence a split_string_for_check sounds like a more precise name, but it’s longer. What do you think about the naming?

[Vladimir Dzhuvinov]

This issue is related with #1843 and thus are probably best resolved together.

https://bitbucket.org/openid/connect/issues/1843/

[Giuseppe De Marco]

Fixed here
https://bitbucket.org/openid/connect/pull-requests/458#Lopenid-connect-federation-1_0.xmlF1477T1502

this was already satisfied by the text but unfortunately lost due to a regression pointing to grant_types rather than scopes

[Giuseppe De Marco]

Closed by PR 458