verified_claims_alias

[Takahiko Kawasaki]

An idea to map particular scope values to particular complex request structures is sometimes proposed and actually mentioned in standard specifications. The following are examples.

• verified_claims (OpenID Connect for Identity Assurance 1.0)
• authorization_details (OpenID for Verifiable Credential Issuance)
• presentation_definition (OpenID for Verifiable Presentations)

However, it does not seem desirable that all these kinds of aliases go into the scope request parameter.

I think it is better to define a new separate parameter that is dedicated to an alias. For example, in the case of verified_claims, verified_claims_alias or verified_claims_shortcut could be defined as a new parameter.

If this kind of approach is taken, a verified_claims request can be written like below.

{
  "id_token": {
    "verified_claims_alias": "jp_oidf_ida_2022_high"
  },
  "userinfo": {
    "verified_claims_alias": "jp_oidf_ida_2022_medium"
  }
}

In addition, a side effect of this approach is that it enables implementations to publish supported mappings in their discovery documents like below.

"verified_claims_aliases_supported": {
  "jp_oidf_ida_2022_high": {
    "verification": {
      "trust_framework": {
        "value": "jp_aml"
      },
      "...": "..."
    }
  }
}

This approach is being proposed with the following issue in mind:

• [eKYC-IDA Issue 1339] Create profiles of the OIDC4IDA spec

Abusing the scope request parameter damages the original usage of the parameter. The scope parameter in OpenID Connect Dynamic Client Registration 1.0 and the scopes_supported server metadata in OpenID Connect Discovery 1.0 have been badly affected. The Dynamic Scope approach adopted by some open banking ecosystems also has an impact on the scope parameter and the scopes_supported metadata without good answers. In my humble opinion, standard specifications should stop abusing the scope parameter.

See also:

• [Connect Issue 1841] OpenID4VP: presentation_definition_alias

‌