italia / eudi-wallet-it-docs

Italian EUDI Wallet Technical Specifications
Creative Commons Zero v1.0 Universal
56 stars 20 forks source link

[Presentation] mapping credentials and user attributes with OAuth 2.0 scopes #152

Open peppelinux opened 1 year ago

peppelinux commented 1 year ago

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

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

name credential type attribute set notes
pid PersonIdentificationData given_name family_name birthdate place_of_birth unique_id eIDAS minimum data set
given_name PersonIdentificationData given_name --
family_name PersonIdentificationData family_name --
birthdate PersonIdentificationData birthdate --
place_of_birth PersonIdentificationData place_of_birth --
unique_id PersonIdentificationData unique_id --
tax_id_code PersonIdentificationData or *HealthCard tax_id_code tax_id_code is optional in the Italian domestic PID
gender *PersonIdentificationData gender --
portrait *PersonIdentificationDataPortrait portrait encoded in base64
adulthood PersonIdentificationDataAge age_over_18 the adult age may vary in different countries. Each Wallet Instance evaluates the adulthood within their national regulation and provide the data accordingly. For instance, in the US, being of age for driving, voting, and purchasing alcohol are all different (16, 18, and 21, respectively). See age_over_NN defined below.
age_over_16 PersonIdentificationDataAge age_over_16 --
age_over_18 PersonIdentificationDataAge age_over_18 --
age_over_21 PersonIdentificationDataAge age_over_21 --
age_in_years PersonIdentificationDataAge age_in_years --
birth_year PersonIdentificationDataAge birth_year --
healthcard *HealthCard PersonIdentificationData given_name family_name birthdate place_of_birth tax_id_code blood_group healthcard_unique_id --
nationality *PersonNationalityData nationality one or more credentials, issued by different issuers, containing the nationality attributes and its value according to ISO 3166 country code
org.iso.18013.5.1 *MobileDrivingLicense See ISO 18013-5 --
delivery *PersonDeliveryAddress PersonIdentificationData given_name family_name resident_address resident_country resident_state resident_city resident_postal_code resident_street resident_house_number email phone_number --
email *PersonDeliveryAddress email email_verified any credential that contains a verified email address and that credentials is verifiable and its issuer trustworthy
phone_number *PersonDeliveryAddress phone_number phone_number_verified any credential that contains a verified telephone_number that is verifiable and its issuer trustworthy
id_token See SIOPv2 for anonymous authentications with pseudonyms
affiliation_$ *PersonAffiliationData organization_name organization_unique_id affiliation_entitlements email phone_number the placeholder $ must be replaced with any credential organization identifier, eg: affiliation_foocorp or affiliation_bananaholding . entitlements is Json Array. Each affiliation credential may extends this data model
peppelinux commented 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:

selfissued commented 1 year ago

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.

peppelinux commented 1 year ago

@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

peppelinux commented 1 year ago

See also https://github.com/openid/OpenID4VP/pull/44#issuecomment-1784244964

tlodderstedt commented 10 months ago

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:

c00kiemon5ter commented 10 months ago

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.

tlodderstedt commented 10 months ago

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

surfnet-niels commented 10 months ago

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

tlodderstedt commented 10 months ago

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.