search

eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
431 stars 60 forks source link

[Annex 2] Attestation Providers supposed to be trustworthy by default #207

Open peppelinux opened 5 months ago

peppelinux commented 5 months ago

In https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/annexes/annex-2/annex-2-high-level-requirements.md, ISSU_34, we read

PID Providers, QEAA Providers, and PuB-EAA Providers are supposed to be trustworthy by default.

What it is supposed to mean by default in the field of the trust evaluation mechanisms?

Only the trusted list, and therefore the Trust Anchors contained in it, can be considered trustworthy over all (and therefore might be this considered "by-default").

How a Wallet Instance could consider an Attestation Provider trustworthy by default?

AndersTornqvist commented 3 months ago

Proposed response: Thank you for your contribution. It is agreed that this formulation is subjective and unclear. The bullet will be removed or reformulated.

digeorgi commented 1 month ago

Thank you very much for your input. We do agree that the second note should make clearer what is meant by 'trusted by default'. We will reword it to: "PID Providers, QEAA Providers, and PuB-EAA Providers are trusted by other actors in the EUDI Wallet ecosystem to not fraudulently issue attestations (or PIDs) that they are not legally allowed to issue. This trust is warranted since these kinds of providers operate within a regulated framework and are regularly audited. However, non-qualified EAA Providers are unregulated and may not be completely trustworthy. Therefore, before requesting an EAA from a non-qualified EAA Provider, a Wallet Instance may need to verify that that EAA Provider is authorized or registered to issue the type of EAA the Wallet Instance is requesting. Such verification requirements, as well as the mechanisms allowing to do this, may be defined in the applicable Rulebook.

We will also add clarifications to ISSU_07 - ISSU_10 and to OIA_12 – OIA_15 to make clear what the precise responsibilities of Wallet Instances and Relying Party Instances are regarding trust anchor management.