[OpenID-Specs-eKYC-IDA] Issue #1342: verified_claims_alias (openid/ekyc-ida)

Wed Mar 1 11:34:47 UTC 2023

New issue 1342: verified_claims_alias
https://bitbucket.org/openid/ekyc-ida/issues/1342/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.

```json
{
  "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.

```json
"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](https://bitbucket.org/openid/ekyc-ida/issues/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.