Closed OIDF-automation closed 3 months ago
I submitted a similar proposal to OpenID Connect for Identity Assurance 1.0 just now.
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 @{557058:5ac0eada-9199-4cf8-a9b7-ced6b4d483a1} ?
@{557058:245bbbf8-3623-466b-9e2f-a9fa2f30c0ee} 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?
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
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.
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.
It seems to me that this issue is quite outdated and that the related PR was also closed. The proposal described in this issue appears so far from the current direction of openid4vp that I voluntarily decide to close it, leaving up to the authors or any other contributor to re-open it if of interest and with any actionable arguments
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1841
Original Reporter: authlete-taka
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
orpresentation_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.
In addition, a side effect of this approach is that it enables implementations to publish supported mappings in their discovery documents like below.
Abusing the
scope
request parameter damages the original usage of the parameter. Thescope
parameter in OpenID Connect Dynamic Client Registration 1.0 and thescopes_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 thescope
parameter and thescopes_supported
metadata without good answers. In my humble opinion, not only OpenID4VP but also other specifications should stop abusing thescope
parameter.