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.

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

[Takahiko Kawasaki]

I submitted a similar proposal to OpenID Connect for Identity Assurance 1.0 just now.

• [eKYC-IDA Issue 1342] verified_claims_alias

‌

[Giuseppe De Marco]

Starting from this https://bitbucket.org/openid/connect/issues/1938/openid4vp-relying-party-presentation

I find this issue very interesting.

My starting point is to satisfy the requirement to apply a policy on a authz request by filtering the VCs or individual user attributes contained in them, where a policy or a signed metadata about the verifier is made available thanks to a trusted third party, accreditation authority, etc.

I find your warning interesting, and I add that different scopes without a unique namespace that contextualize them could lead to collisions, and consequently to security problems. And this scares me a little :-)

considering also this: https://bitbucket.org/openid/connect/issues/1814/what-metadata-goes-into-client_metadata I have proposed `presentation_definition_scope_alias` where for example I put a simple idea here, using the presentation_definition id defined here https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#section-5.2-5

{
  "presentation_definition_scope_alias": {
     "idcard": "id card credential",
     "scope-id": "presentation-definition-id"
  }
}

I admit that using as IDs strings with spaces chars scares me a little, anyway this idea maps scopes with presentation definition entries.

However I’m in favour of not using scope if we decide that scope has a traditional value that should be preserved and not inflated in the wallet ecosystems. then my proposal could change in this way

"presentation_definition_aliases_supported": {
  "com.example.healthCardCredential_presentation": "presentation-definition-id-of-that-hcc"
}

WDYT @Takahiko Kawasaki ?

[Takahiko Kawasaki]

@Giuseppe De Marco I’m glad if you feel the idea of presentation_definition_aliases_supported is better than scope. BTW, I'm not sure I understand your point. Is presentation-definition-id-of-that-hcc in your example another alias? That is, the alias com.example.healthCardCredential_presentation is pointing to another alias presentation-definition-id-of-that-hcc, and presentation-definition-id-of-that-hcc needs to be resolved in some other way, right?

[Kristina Yasuda]

However, it does not seem desirable that all these kinds of aliases go into the scope request 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.

Can you please elaborate why it is not desirable? and how those have been badly affected? I think I can guess, but I do not want to assume.

On one hand, I have not yet seen an implementation that uses scopes - only presentation_definition or presentation_definition_uri, probably because very few are reusing existing AS/OPs for presentation, unlike Issuance. but this might change as we are also seeing cloud wallets starting to be built more.

On the other hand, because there is a below clause in the 4VP, usage of scopes parameter in 4VP is not free-flowing and is “scoped”. not sure it prevents the abuse you are trying to prevent, but it is what differentiates its use from the use of scopes in other specifications from what I understand.

Such a scope value MUST be an alias for a well-defined Presentation Definition that will be referred to in the presentation_submission response parameter.

‌

[Takahiko Kawasaki]

For example, Brazilian Open Finance strictly restricts the set of scopes that can be specified in Dynamic Client Registration requests. Casual use of the “scope” parameter whose purpose is different from the original intended usage can easily conflict with such standards that decently use the “scope” parameter for the original intended purposes. Using “scope” as shortcuts for verifiable presentation definitions won’t work with Brazilian Open Finance’s dynamic client registration without implementing workarounds.

cf. “Implementer’s note about Open Banking Brasil”

[Roland Hedberg]

I support Takahiko’s proposal of using new request parameters instead of using scope

As I see it scopes as defined in the initial documents was something that was globally usable. We all know that when that met reality it wasn’t enough. Just about every project defined their own scopes that where specific for their usage.

Now the proposal is to go one step further and to allow every entity to defined their own scope set. IMHO that is going one step too far.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VP