Open peppelinux opened 1 year ago
This issue aims to define which scopes are enabled during the presentation and MUST be supported by RP and Wallet Solutions. It also aims to define which scopes are required for the issuance of a (Q)EAA, therefore it closes:
I agree with the use of scopes in this manner.
Adulthood is contextual. For instance, in the US, being of age for driving, voting, and purchasing alcohol are all different (16, 18, and 21, respectively). You may want different purpose-specific "adulthood" scopes.
An example for affiliation_$ would help people understand what's intended.
@selfissued I find very interesting your notes about the relativity of the adulthoodness.
ageover$ extended with the evidences you brought. affiliation_example added in the notes
The use of scopes in this PR is compatible with the current definition of scope usage in the OID4VP spec.
Having said that, I prefer the presentation definition way of requesting credential presentations (including selective disclosure).
Reasons:
I think that we should be inclusive and support scopes too. It is a well-known mechanism and much easier to work with than PE. Indeed, scopes are only useful as a coarse-grain mechanism to request a bundle of claims. In a way, scopes act as a category of information type (to which access is requested), thus a bundle. Taking it to the extreme, claims and scopes map one to one; this does not make much sense anymore and is probably abusing the initial intent of scopes. Instead, using PE, one can be much more precise in what they request and expect to get. This can be great for certain scenarios, and will most probably be the way moving forward when strict policies will have been established and require that all data exchange is justified. Additionally, PE acts a point that allows us to extend the request to add in more options to configure other factors than just the expected claims. I think there is a place for both, especially as the ecosystem shifts towards supporting the OID4VC flows.
Please don't forget and don't underestimate the burden created by the need to (in advance) agree on scope values.
I have faced that question when building a huge bank identity ecosystem where supporting new scopes would have meant to extend about a thousand IPDs (OpenID Connect). And operating under GDPR use of coarse grain bundles wasn't an option. Therefore, any new combination of attributes for a new use case would have required the definition and support of a new scope value. Infeasible.
In the end, we came to the conclusion it doesn't really matter whether the developer adds one static string (scope) or another (from her standpoint) static string (claims parameter value), so I think the benefit of scopes is overrated. We went with the OpenID Connect claims parameter only (which is for the context of this discussion is very similar to PE).
I agree with the notion we need both. While I agree the burden to create and agree upon such sets is large, especially in a new ecosystem, I note that in many cases such definitions already exist. The reason for this is that specific combinations of credentials typically support a specific activity or workflow in a sector. Agreeing upon a set and using it creates clearity and improves interoperability. In addition it helps GDPR compliance, as a well understood set of credentials gets faster signoff from legal. As examples of existing scopes have a look at the many OpenID working groups (https://openid.net/wg/) where many have some definition of semantics, including scope definions. Having the ability to reuse the same scopes in the VC ecosystem may help adoption. Even when OpenID is not used, several sectors still have defined semantics which includes groupings of credentials. In the R&E SAML ecosystem for example, such sets have been defined as entity categories, for exmple like this one: https://refeds.org/category/research-and-scholarship
Leveraging existing things to foster adoption seems reasonable to me. I would appreciate if you could share a concrete example.
Other than that I still need to be convinced there is any benefit in using scopes over PE that justifies the additional cost and complexity caused by orchestration and coordination among the ecosystem parties.
While waiting for a simplified Presentation Definition implementation profile for OpenID4VP, within the OpenID DCP WG, we have decided to use OAuth 2.0 scopes within the EUDI WALLET IT trust framework.
The mapping proposal follows with defined maps between the scope values and the user credential attributes sets.
Functional requirements
vp_formats_supported
;Benefits
an important value about using scopes instead of presentation definitions is the comfort of using the federation metadata policies without dealing with nested objects, like the one represented in DiF PE
Use cases
In the real wolrd we have common scenarios where a predefined set of data is the best way to satisfy the requirements of data release. An example is a postal delivery, that within the
scope=delivery
would include all the required data.Notes
these notes are applied for the table below.
Scopes Table
$
must be replaced with any credential organization identifier, eg:affiliation_foocorp
oraffiliation_bananaholding
.entitlements
is Json Array. Each affiliation credential may extends this data model