All claims should be in a scope

Issue #1118 resolved
Travis Spencer created an issue

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.

Comments (13)

  1. 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.

  2. Travis Spencer reporter

    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.

  3. Takahiko Kawasaki

    I have no strong opinion to agree or disagree with the suggestion. However, if such scopes were defined, I imagine the mapping would look like the following.

    Scope Verified Claims
    verified:profile name and other claims defined in OIDC Core 1.0 Section 5.4, plus place_of_birth, nationalities, birth_family_name, birth_given_name, birth_middle_name, salutation and title (which are defined in IDA Section 3.1).
    verified:email email and email_verified
    verified:address address
    verified:phone phone_number and phone_number_verified

    : may be problematic for some implementations, though.

    BTW, Vladimir has raised Issue #1148 for the same topic.

  4. Vladimir Dzhuvinov

    Thanks for linking the issue, I wasn’t aware they were related.

    My proposal was to simply allow the definition of scope values for which an RP can request a set of claims in a given trust framework. For example trust-xyz:profile . The intent of that being to simplify the request construction for developers (no claims parameter).

    I’m not sure if that makes sense from an application and general IdA perspective.

  5. Torsten Lodderstedt

    I’m pretty sure it’s hard to impossible to come up with useful scope definitions as part of OIDC4IDA for various reasons. The verification claim has several different fields and it is up to the RP to decide which fields to request. Some RPs might only need the trust framework attestation, some may additionally require the time of verification, others may require evidence as well. I don’t see how this could fit into a manageable set of scopes. Moreover, the spec does not define identifiers for trust frameworks, verification methods and identity documents.

    If we take a look onto Taka’s examples of verified:profile. It does not identify a certain trust framework, which is key to legal compliance, and it could only refer to a pre-defined set of verification-fields, in the same way it refers to a pre-defined set of claims.

    As expressed on the list (, I think scopes only make sense as pre-defined alias on the level of a particular RP in a particular deployment.

  6. Log in to comment