OpenID4VP: presentation_definition_alias
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.
Comments (7)
-
reporter -
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 thatscope
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 ?
-
reporter @Giuseppe De Marco I’m glad if you feel the idea of
presentation_definition_aliases_supported
is better thanscope
. BTW, I'm not sure I understand your point. Ispresentation-definition-id-of-that-hcc
in your example another alias? That is, the aliascom.example.healthCardCredential_presentation
is pointing to another aliaspresentation-definition-id-of-that-hcc
, andpresentation-definition-id-of-that-hcc
needs to be resolved in some other way, right? -
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 thescopes_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
orpresentation_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.
-
reporter 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.
-
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.
-
- changed status to resolved
Migrated to GitHub
- Log in to comment
I submitted a similar proposal to OpenID Connect for Identity Assurance 1.0 just now.