[Openid-specs-ab] Issue #1841: OpenID4VP: presentation_definition_alias (openid/connect)

[Takahiko Kawasaki]

New issue 1841: OpenID4VP: presentation_definition_alias
https://bitbucket.org/openid/connect/issues/1841/openid4vp-presentation_definition_alias

Takahiko Kawasaki:

An idea to map particular `scope` values to particular complex request structures is sometimes proposed and actually mentioned in 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 request parameter that is dedicated to an alias. For example, in the case of `presentation_definition`, `presentation_definition_alias` or `presentation_definition_shortcut` could be defined as a new request parameter.

If this kind of approach is taken, the example in “5.3. Using scope Parameter to Request Verifiable Credentials\(s\)” can be written like below.

```
  GET /authorize?
    response_type=vp_token
    &client_id=https%3A%2F%2Fclient.example.org%2Fcb
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &presentation_definition_alias=com.example.healthCardCredential_presentation
    &nonce=n-0S6_WzA2Mj HTTP/1.1
```

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

```json
"presentation_definition_aliases_supported": {
  "com.example.healthCardCredential_presentation": {
  }
}
```

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, not only OpenID4VP but also other specifications should stop abusing the `scope` parameter.