EUDI Wallet & eIDAS 2.0 Glossary | What is inside the wallet (pt. 3)
Last updated: 21 August 2026
EUDI basics, made simple. The contents of the wallet in 3 minutes.
This glossary defines what an EUDI Wallet actually holds: the government-issued identity dataset every wallet starts with (PID), the three kinds of attestation that can be added on top of it (EAA, QEAA and PuB-EAA), and the two mechanisms that shape what actually leaves the wallet: selective disclosure and combined presentation.
Each entry starts with a plain-language definition and adds the practical and legal detail underneath.
EUDI Wallet & eIDAS 2.0 Glossary: Who does what in the ecosystem (pt. 1) covered the demand side: the wallet, PID, relying parties, intermediaries and verifiers. EUDI Wallet & eIDAS 2.0 Glossary: Who issues, who provides, who guarantees (pt. 2) covered the supply side: issuers, holders, wallet providers and trust services.
Part 3 opens the wallet itself.
What does PID actually contain?
The core identity dataset the state puts in your wallet. Who does what in the ecosystem (pt. 1) defined PID as a role in the ecosystem; this entry looks at the data itself.
Who does what in the ecosystem (pt. 1)
In practice: Person Identification Data carries the attributes that identify a person rather than describe them: current family name, current given name, date of birth and a unique identifier, with further attributes such as place of birth or nationality depending on the issuing Member State. The PID Rulebook defines the common baseline; national schemes add on top of it.
That boundary is what matters when designing a flow. PID answers "who is this person". It does not answer "does this person hold a licence", "is this person a director of that company", or "what is this person's address today". Those answers come from attestations, and they may not be present in the wallet at all.
PID is also why the wallet works cross-border without bilateral arrangements: the dataset and its formats are harmonised by implementing rules, so a PID issued in one Member State is readable by a relying party in another.
Who this applies to: Every relying party building an onboarding flow. PID is the baseline you can assume is present, and the limit of what you can assume is present.
Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 3(3) (definition) and Article 5a, as amended by Regulation (EU) 2024/1183; dataset and formats in Commission Implementing Regulation (EU) 2024/2977.
What is an electronic attestation of attributes (EAA)?
A signed statement about you that is not your core identity: your diploma, your professional licence, your membership, your account. It cannot be denied legal effect just for being electronic.
In practice: The EAA is the general category. A trust service provider issues it, signs it cryptographically, and the holder keeps it in the wallet alongside PID.
The important property is what an EAA is not. eIDAS guarantees that an attestation cannot be denied legal effect or admissibility as evidence solely because it is in electronic form. It does not guarantee that any given EAA satisfies a requirement that a specific regime imposes on the evidence itself.
That is why the ecosystem has three tiers rather than one. If a process needs the same legal weight as a paper certificate, a plain EAA is not enough.
Authologic operates as a non-qualified trust service provider issuing electronic attestations of attributes, supervised by the Polish Minister of Digital Affairs.
Related: Who issues, who provides, who guarantees (pt. 2) defines the two tiers of trust service provider behind these attestations. An EAA can be issued by a non-qualified provider; the qualified tier is the next entry.
Who this applies to: Any organisation whose documents could live in a wallet as verifiable data rather than a PDF, and any relying party deciding what tier a given check requires.
Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 3(44) (definition) and Article 45b (legal effects), within Section 9 on electronic attestations of attributes, Articles 45b to 45h, as amended by Regulation (EU) 2024/1183.
What is a qualified electronic attestation of attributes (QEAA)?
An EAA issued by a qualified trust service provider under supervision, carrying the legal weight of the paper equivalent. The qualified tier of attestations, in the same way a qualified electronic signature (QES) - the signature type carrying the legal weight of a handwritten one - is the qualified tier of signatures.
In practice: A QEAA is issued by a QTSP, meets the requirements in Annex V, and carries the legal effect of a lawfully issued attestation in paper form. The provider operates under conformity assessment, national supervision and the liability regime that comes with qualified status.
For regulated onboarding this is the tier that changes what a relying party can rely on. Under the AMLR, qualified trust services are one of the recognised verification pathways, alongside notified eID schemes at substantial or high assurance - the two upper tiers eIDAS defines for electronic identification - and the wallet itself. A QEAA carrying verified identity attributes can therefore do work in customer due diligence that a plain EAA cannot - see How Will the EUDI Wallet Change KYC?.
The trade-off is availability. Qualified status is demanding to hold, so the supply of QEAAs will be thinner than the supply of EAAs for some time, and unevenly distributed across Member States and attribute types.
Who this applies to: Compliance teams deciding which tier a process legally requires, and issuers weighing whether their attestations need qualified status to be useful.
Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 3(45) (definition), Article 45d (requirements) and Annex V, as amended by Regulation (EU) 2024/1183; recognition under AMLR: Regulation (EU) 2024/1624, Article 22(6).
What is a public body attestation of attributes (PuB-EAA)?
An attestation issued by, or on behalf of, the public body that actually holds the data - the register, the ministry, the authority. Not a qualified trust service, but issued by a body the Member State must hold to an equivalent level of reliability.
In practice: The PuB-EAA exists because of a gap. Public bodies hold the most reliable data in the system - vehicle registers, tax records, professional registers - but requiring every authority to become a QTSP would have stalled the ecosystem. eIDAS therefore creates a third route: an attestation issued by or on behalf of a public sector body responsible for an authentic source, meeting the requirements in Annex VII. Article 45f obliges the Member State to ensure that such a body reaches a level of reliability and trustworthiness equivalent to that of a qualified trust service provider.
The term carrying the weight here is authentic source: the register or repository recognised as holding the original, authoritative record of an attribute. A PuB-EAA is trusted because of where the data comes from, not because of who audited the issuer.
For relying parties the practical consequence is that the strongest attestation for a given attribute may not come from a commercial provider at all. It may come from the state body that owns the register - the same logic that separates government credentials from document images.
Who this applies to: Public sector bodies planning to issue into wallets, and relying parties mapping which attributes they can source at the highest tier.
Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 3(46) (definition), Article 3(47) (authentic source), Article 45f (requirements) and Annex VII, as amended by Regulation (EU) 2024/1183.
What is the difference between EAA, QEAA and PuB-EAA?
All three are signed statements about a person's attributes, carried in the same wallet and verified the same way. They differ in who issues them and what legal weight the regulation attaches to the result.
In practice: The distinction is not technical. All three use the same credential formats and travel through the same infrastructure. What differs is the regime behind the issuer.
Attestation | Issued by | Legal weight |
|---|---|---|
EAA | Any trust service provider, qualified or not | Cannot be denied legal effect solely for being electronic |
QEAA | A qualified trust service provider, under supervision and liability | Legal effect of the paper equivalent |
PuB-EAA | A public sector body responsible for an authentic source, or an entity acting on its behalf | Issuer held to a level of reliability equivalent to a qualified trust service provider |
The question to ask about a flow is therefore not "does the wallet support this attribute" but "at which tier is this attribute available, and does my regime require that tier". Those are different questions, and the second one is the one that fails audits.
Who this applies to: Anyone specifying requirements for a wallet-based process: compliance, legal, and the architects who implement what they decide.
Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 45b (legal effects), Article 45d with Annex V, and Article 45f with Annex VII, as amended by Regulation (EU) 2024/1183.
What is selective disclosure?
Sharing one attribute without revealing the rest. Proving you are over 18 without showing your date of birth, your name or your document number.
In practice: Selective disclosure is a required capability of the wallet, not an optional privacy feature a provider may add. The wallet must let the holder present only the attributes a relying party has asked for, and the relying party may only ask for what is necessary and proportionate for the service.
It works because credentials are built so that individual attributes can be revealed and verified on their own, without breaking the issuer's signature over the whole credential. For some checks - age being the standard example - the wallet can go further and present a proof that a condition is met without disclosing the underlying value at all.
The consequence for relying parties is that data minimisation stops being a policy statement and becomes a design constraint. Under the registration rules described in Who does what in the ecosystem (pt. 1), the scope of data an organisation intends to request is declared in advance, and the wallet can check a request against that registered purpose and inform the user when it goes beyond it.
Who this applies to: Every relying party designing a request, and every product team that has been collecting whole documents because the interface made it easy.
Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 5a(4)(a), which requires the wallet to ensure that selective disclosure of data is possible, and Article 5b (relying party obligations), as amended by Regulation (EU) 2024/1183; registration and declared data scope in Commission Implementing Regulation (EU) 2025/848.
What is combined presentation?
Requesting attributes from more than one credential in a single interaction. Person Identification Data for identity and a separate attestation for a professional licence, presented together rather than in two flows.
In practice: Selective disclosure narrows what leaves the wallet. Combined presentation widens where it comes from. A relying party can ask for attributes held in different credentials, issued by different issuers, and receive them in one response that the wallet assembles.
This matters because attributes rarely sit in one place. Identity comes from the state, a professional qualification from a chamber or a regulator, an account relationship from a bank. Without combined presentation each of those is a separate round trip, and users drop out somewhere between them.
The constraint from the previous entry still applies. Whatever is combined has to stay within the scope the relying party has registered, and each attribute is still released selectively rather than as a whole credential.
Related: The tiers of attestation that can be combined are defined above; the roles of the issuers behind them are in Who issues, who provides, who guarantees (pt. 2).
Who this applies to: Relying parties whose checks need more than identity - regulated onboarding, professional verification, or age combined with residency.
Legal basis: Regulation (EU) No 910/2014 (eIDAS), Article 5a(4)(a), which requires the wallet to let the user select, combine and present person identification data in combination with electronic attestations of attributes while ensuring selective disclosure, and Article 5a(16)(b), which requires that presenting attributes together avoids unnecessary identification of the user; as amended by Regulation (EU) 2024/1183. Technical requirements in Annex 2 of the Architecture and Reference Framework, Topic 18.
The series so far.
How do PID, attestations and disclosure fit together?
A wallet arrives with PID: the state's answer to who this person is. Everything else is added as an attestation - a plain EAA where the legal weight of the issuer does not matter, a QEAA where it does, a PuB-EAA where the authoritative record sits with a public body. When a relying party makes a request, selective disclosure determines how much of any of it actually leaves the wallet, and combined presentation determines how many credentials it can draw on at once.
The roles behind each step are defined in the earlier parts: who issues, who provides the wallet and who guarantees the trust services in Who issues, who provides, who guarantees (pt. 2); who reads the data - relying party, verifier, intermediary - in Who does what in the ecosystem (pt. 1).
Part 4 will cover what gives a credential its legal weight: assurance levels, and the tiers of electronic signature and seal from SES to QES.
For the infrastructure vocabulary - orchestration, routing, fallback - see the Identity Orchestration Glossary: Routing, Fallback and eID-Native Architecture.
To test your own setup against all of it, see the EUDI Wallet Readiness Checklist and Are you ready for July 2027? A 32-question SCA & AMLR readiness checklist.
Changelog
- 21 August 2026 - Initial publication (7 entries).
Share article
Press Contacts
Jarek Sygitowicz
jaroslaw.sygitowicz@authologic.comAuthologic
contact@authologic.com
