All claims should be in a scope

[Travis Spencer]

OpenID Connect core sets forth the notion that a scope values that group together certain claims, as shown in the following diagram:

The identity assurance draft, however, does not follow this model. Instead, it defines a number of claims (section 3) which are not grouped into a scope value. I have understood that the rationale is to force clients to only ask for the minimum set of information about the user that it requires. Consequently, it is more private by design. I understand and support that goal; however, it should be done in a way that aligns with existing president.

For this reason, new scope values should be defined in the assurance draft spec that contain one claim, simply. Where plausible, that scope may contain multiple claims, but I’ve understood that the grouping of multiple claims into a single scope value is contrived and unfitting. This is fine, but, if so, then at least the new claims should be defined to map directly to a scope value by the same name.

[Tom Jones]

why? Doesn’t seem to be any useful purpose.

[Michael Jones]

We discussed this on the 24-Oct-19 working group call. Scopes are simply a shorthand for a “claims” requests, as a convenience for implementers. But the “claims” request parameter has always been there to achieve finer-grained claims requests. It’s unnecessary to add scopes for all potential claims, as the “claims” parameter can be used to request them.

We will close this issue shortly unless further discussion results in a different conclusion by the working group.

[Travis Spencer]

I’m sorry I missed that call, Mike. I’m not in the habit of joining. In any event, let me share some more of the rationale for this.

Another reason that including these claims in a scope (even if one-to-one between a claim name and a scope value with the same name) is for administrative simplicity. If all claims are in a scope, then an administrator only needs to assign scopes to a client, not scopes AND the claims that aren’t grouped into a scope. This divergence has the practical affect of requiring changes to some products (like ours, honestly) that have adopted an administrative workflow based on this existing scope/claims grouping model. So, this divergence will require product changes that effect at least our product and potentially others.

Let me turn it around: what is the harm of doing this? I think the consequences for not doing it are:

• More administration in the OP

• Divergence from the existing model and precedent which may lead to confusion

  • Product updates to support claims in a new way.

The issues of accepting this suggestion are:

• A scope that is not used at run-time by an RP in most cases (because it will usually use the more-fine-grained claims request param)
• Existing implementations of this spec will have to be updated to support these new scope values

Is there some other pro or con of doing it or not doing it? If not, then I think the benefits of doing it outweigh the issues caused by actually accepting this modification.

[Torsten Lodderstedt]

transferred to https://bitbucket.org/openid/ekyc-ida/issues/1118/all-claims-should-be-in-a-scope