Skip to content

Trust in the EUDI Wallet Ecosystem

Introduction

Trust between participating parties is a fundamental prerequisite for a functioning EUDI Wallet ecosystem. This section provides a comprehensive overview of how trust is established, what distinguishes different attestation types, and how to determine which attestation type is appropriate for specific use cases.

The eIDAS 2.0 framework deliberately provides different levels of trust services to match different real-world needs. Understanding these trust models is essential for selecting the appropriate attestation type and avoiding unnecessary effort and costs.

Key principle

The appropriate attestation type is the lowest level that sufficiently meets the legal and practical requirements of the use case.

How Trust Is Established

Trust in the EUDI Wallet ecosystem is established through different mechanisms depending on the attestation type and the relationship between parties.

Uniform Issuer Identity Assurance

All issuers—whether issuing PID, EAA, QEAA, or PubEAA—are identified at the same cryptographic security level via Access Certificates issued by a Registrar.

Access Certificates:

  • Bind the legal identity of the issuer
  • Define the issuer's technical role in the ecosystem
  • Enable secure interaction with Wallets and Relying Parties

Access Certificates do not define:

  • Evidentiary value of the issued attestation
  • Qualification status of the issuer
  • Authorization to issue specific attributes

Authentication vs. Authorization

Identity assurance answers who an issuer is. Trust models answer whether a specific attestation should be relied upon.

Trust Models by Attestation Type

Attestation Type Primary Trust Anchor Authorization Logic Liability
PID Member State certification National law mandate Member State
EAA Accepted rulebook / scheme Explicit via governance Contractual / scheme-based
QEAA QTSP qualification + EU Trusted List Implicit via regulation Statutory (QTSP)
PubEAA Public mandate + certified attributes + EU Trusted List Explicit via public law Public authority

Trust and Liability

Understanding liability allocation is crucial when choosing an attestation type:

EAA (Electronic Attestation of Attributes)

  • Liability: Based on contractual arrangements, scheme rules, and general civil law
  • Risk allocation: Shared between issuer and relying party according to scheme governance
  • Recourse: Through contractual and civil law mechanisms
  • Insurance: Not mandated, but may be required by scheme rules

QEAA (Qualified Electronic Attestation of Attributes)

  • Liability: Statutory liability regime under eIDAS
  • Risk allocation: QTSP assumes significant liability for damages caused by non-compliance
  • Recourse: Direct statutory claims against the QTSP
  • Insurance: Mandatory professional liability insurance required for QTSPs

PubEAA (Public Electronic Attestation of Attributes)

  • Liability: Public law liability of the issuing authority
  • Risk allocation: The public body responsible for the authentic source bears liability
  • Recourse: Administrative and public law remedies
  • Insurance: Government liability frameworks apply

PID (Personal Identification Data)

  • Liability: Member State responsibility under eIDAS
  • Risk allocation: The notifying Member State is liable for the proper functioning
  • Recourse: Through national and EU legal mechanisms
  • Insurance: Covered by state liability frameworks

Common Misconceptions

"Only QEAA are legally safe"

Incorrect. QEAA provide higher evidentiary value only where this is legally or practically required. EAAs are explicitly designed by eIDAS to cover the vast majority of use cases and are fully valid trust instruments.

"EAA issuers are not trustworthy because they are not on the EU Trusted List"

Incorrect. Access Certificates identify the entity with which the Wallet is interacting, but they do not sign credentials. For EAA, trust is established via accepted rulebooks that the Relying Party must accept to consume the attestation and gain trust in it. The difference between EAA and QEAA lies in the trust model, not in the cryptographic security or identity verification of the issuer.

"Qualification equals better security"

Incorrect. Technical security mechanisms (cryptography, key management, revocation) are similar across all attestation types. Qualification primarily adds conformity assessment, supervision, and statutory liability—not inherently stronger technical security.

"Public bodies should always use PubEAA"

Incorrect. Public bodies can issue EAAs for attributes that do not require document-equivalent evidentiary value. PubEAA is specifically for cases where the attestation should have the same legal effect as a paper original.

Choosing the Right Attestation Type

Quick Decision Guide

There are several key factors to consider when choosing an attestation type for a given use case:

Question Motivation
Who is the issuer of the credential? certain rights and obligations for public bodies, responsible for an authentic source, e.g., to issue PubEAA and provide register information
Required evidentiary value of the credential? for document-equivalent requirements, QEAA or PubEAA may be legally required
Existing trust / acceptance structure? can be used for EAA verification, independent of eIDAS trust lists, e.g., credit scores
Cross-border scenario, unknown acceptance conditions? central eIDAS trust mechanisms for QEAA / PubEAA may be used, e.g., language certificates from certified schools
Should issuance be under control of a public body? other parties may issue credentials by verifying attributes against the authentic source (if on Minimum List of Attributes)

The requirements for EAA, QEAA, and PubEAA can be compared concisely as follows:

Requirement EAA QEAA PubEAA PID (for comparison)
Evidentual value Trust structures of the issuer Like written document Like written document Like notified eID-system
Issuer All, regularly a trust service provider Only a QTSP Only authentic sources from a public authority or its representative PID-Provider
Certification required? No Yes including re-certification Yes, only initial Yes, EUDI-Wallet certification (Art 5c eIDAS)
Issuing from not self administered sources possible? Yes Yes No Yes (can differ from national eID-operator)
Sector of issued attestations Private and Public Private and Public Only Public Only Public
Possibility of using a service provider to issue in its own name? Yes No Yes Yes
Issuance only in EUDIW compatible formats and protocols? Yes Yes Yes Yes
User identification required? At the discretion of the issuer Yes Yes Yes (level of assurance high)
Attribute verification and linking to the user required? At the discretion of the issuer Yes Yes Yes (level of assurance high)
Rules for the structure of the attestation? At the discretion of the issuer Yes, annex V eIDAS Yes, annex VII eIDAS Yes, via implementing act
Rules for ensuring integrity and authenticity of the attestation? At the discretion of the issuer Yes, qualified electronic signature/seal Yes, qualified electronic signature/seal Yes
Revocation required? At the discretion of the issuer Yes, (excluding short time attestations) at the user's request, if the proof becomes inaccurate or if there is a possibility of compromise Yes, (excluding short time attestations) at the user's request, if the proof becomes inaccurate or if there is a possibility of compromise Yes, at the user's request, if the proof becomes inaccurate or if there is a possibility of compromise
Obligation to fulfil attestation scheme? At the discretion of the issuer Yes Yes Yes (PID-Rulebook)
Functional separation of EAA service required? No Yes No No
Logical separation of the data and prohibition of combining EAA with other user data? Yes Yes Yes Yes
Supervision by an authority? Yes ex-post, only if trust service provider Yes, ex-ante No Yes, ex-ante by EUDI-Wallet supervisory authority
NIS2-obligation? Yes as important entity, only if trust service provider Yes as essential entity No, except obligation from another category Yes regurlarly as critical infrastructure
Obligation for accessibility? Yes, only if trust service provider Yes Yes Yes
Special obligation for incident reporting Yes, only if trust service provider Yes No Yes, via EUDI-Wallet mechanisms
General technical and organizational requirements for service operation? Yes ex-post, only if trust service provider according to Art 19a eIDAS and implementing act (EU) 2025/2160 Yes, according to Art 24 eIDAS and concretizing implementing acts Yes, analogue to Art 24 eIDAS Ja, specific requirements of Art 24 eIDAS
Special civil law liability for culpable breach of duty? Yes, only if trust service provider Yes, additionally culpable violation is presumed No Via EUDI-Wallet mechanisms according to Art 11 eIDAS
Attribute in attribute catalog of EU-Commission? Only if based on an authentic source from a public authority Only if based on an authentic source from a public authority Yes No, but EU trusted list for PID-Provider und PID-Rulebook
Attribute in catalog of attribute schemes of EU-Commission? Yes, but only if relevant Yes, regularly Yes No, but EU-trusted list for PID-Provider and PID-Rulebook
Sources for validation of the attestation If applicable via catalog of attribute schemes, otherwise through information made available by the issuer EU trusted list + if applicable. Catolog of attribute schemes EU trusted list + EU trusted list for PubEAA issuers + catalog of attribute schemes EU trusted list for PID-Provider + PID-Rulebook

Detailed Decision Criteria

The differences and reasons for issuing EAA, QEAA, and PubEAA described in detail above provide the following decision-making aid for anyone who, as a potential issuer of attribute certificates, is wondering which of the three types they should issue.

Basic Rule EAA

  • Especially if trust structures are already in place
  • If the legal basis allows the EAA to provide the proof (e.g., mdl)
  • Existing and accepted private and public law proofs are to be transferred to the EUDI wallet
  • The proofs are to be issued in a cost-effective, flexible, and customizable manner

Exception: QEAA

  • If, in exceptional cases, no adequate trust structure is available or can be established for the attestation to be issued
  • If the attestation is intended for use abroad and the acceptance rules applicable there are unknown, and it is unclear whether the existing (national) trust structures will be sufficient there
  • The relying parties expressly request QEAA for legal or risk-based reasons. Instead of issuing QEAA, an attempt can also be made to address these reasons and enable the issuance of EAA

Speciality for public sector authentic sources: PubEAA

  • The requirements for issuing a QEAA are met
  • In addition, the highest possible degree of decision-making autonomy should be exercised, and key decisions regarding the issuance should be made within the public administration

The following table helps through key questions to identify the most suitable credentials for specific use case:

Key Question EAA QEAA PubEAA
Existing acceptance relationship? ✅ — —
Accepted today without originals? ✅ — —
Previously required in original form? — ✅ ✅
Regulatory demand for document equivalence? — ✅ ✅
Cross-border use with unknown acceptance? — ✅ ✅
Issuer is authentic source? ✅ — ✅
Issued in issuer's own name? ✅ — ✅
Public body responsible for authentic
source wants to keep most possible control?		 — — ✅

Principle of Proportionality

The existence of QEAA does not imply that EAA are insufficient. Choose the lowest attestation type that meets your requirements. Anything beyond that is voluntary over-compliance with additional cost and complexity.

Next Steps

Based on your use case, proceed to the detailed requirements for each attestation type:

If you have decided to issue an EAA, see the design guidance:

For technical details on trust validation mechanisms, see: