An EU Wallet Request Says “Verify the User”: Does It Need PID, EAA, or QEAA?
Compare person-identification data, ordinary electronic attestations and qualified attestations by claim, issuer, status and relying-party evidence before scoping a wallet project.
Signals to watch
- The relying party names the exact identification fact or attribute needed for one transaction
- The request distinguishes a PID provider from an ordinary or qualified attestation provider
- The team can state which credential status, issuer and disclosed claim its verifier must check
“Verify the user” is not a credential specification. Use person-identification data (PID) when the transaction must establish who the person is. Use an electronic attestation of attributes (EAA) when it must authenticate a stated attribute. Ask whether a qualified electronic attestation of attributes (QEAA) is required only after the relying party names the attribute, acceptable issuer class and legal or policy reason for qualified status.
This distinction matters to a digital identity platform partner manager reviewing authorised banking, travel, education, age-assurance and trust-service Telegram groups. The commercial Signal is not “we need the EU wallet”; it is a relying party that names one claim, an issuer route and a test date. Seeing that request a day late can mean missing the partner-selection call while the buyer assumes three different credential objects are one interchangeable identity check.
An illustrative, incomplete group fragment might read:
“Need EU wallet verification for student rental. Want name, over-18 and student status. Partner says it should all be qualified?”
This is a composite example, not a real request, customer or result. The legal relying party, Member State, user population, issuer, accepted wallet, exact attributes, data-minimisation decision, qualified-status requirement, verifier, test environment and production policy are unknown.
Start with three questions, not three acronyms
The amended eIDAS framework in Regulation (EU) 2024/1183 separates person-identification data from electronic attestations of attributes. The Architecture and Reference Framework then describes how those credential types participate in wallet issuance and presentation.
For the composite rental flow, ask three independent questions:
- Must the service establish the person’s identity for the rental account?
- Must it authenticate an age threshold without collecting a full date of birth?
- Must it authenticate current student status, and which issuer is acceptable?
The first question can lead to PID. The second and third lead to attribute attestations. None of the answers determines by itself whether an attestation must be qualified. That decision needs an applicable legal requirement or an explicit relying-party policy that identifies which qualified provider and credential it will accept.
PID answers “who is presenting?”
The Regulation defines person-identification data as a set of data issued in accordance with Union or national law that enables identity to be established. In a wallet transaction, PID is therefore not a generic profile record or a collection of every fact known about the user. It is an identity object from a recognised PID provider under the framework.
For discovery, record the exact identity data requested, the PID provider, the Member State or applicable issuing context, the wallet environment and the relying party’s purpose. If the business decision needs only a stable account match, do not silently add address, birth date and nationality. Each added field changes the disclosure request.
A verified PID presentation can support that the presented identity data came through the expected credential and verification path. It does not prove student status, driving entitlement, professional membership, creditworthiness or the truth of a later self-declared profile field.
EAA answers “does an issuer attest this attribute?”
An electronic attestation of attributes is electronic evidence that allows attributes to be authenticated. The attribute may be a threshold such as “over 18,” a qualification, a licence, an organisational role or another stated property. The useful unit is the claim actually requested, not the document name the buyer happens to use.
For each EAA request, write down:
- the attribute or predicate, such as
age_over_18 = true; - the issuer that vouches for it and the issuer class the relying party accepts;
- the credential validity and status evidence to be checked;
- the minimum data the user is asked to disclose; and
- the relying-party action supported by a valid result.
An age predicate and student status can be delivered as two attestations even when the user presents them in one wallet session. A university may be an acceptable source for enrolment status while being irrelevant to legal identity. Conversely, a PID provider does not become the source of every attribute merely because its credential identifies the holder.
QEAA changes the issuer and qualified requirements—not the claim’s scope
A qualified electronic attestation of attributes is an attestation issued by a qualified trust service provider and meeting the qualified requirements of the eIDAS framework. “Qualified” is therefore a defined status, not a synonym for accurate, government-issued or high priority.
The comparison that a partner manager needs is concrete:
| Credential object | What it supports | Issuer question | Verification limit |
|---|---|---|---|
| PID | Establishing the identity represented by the disclosed person-identification data | Which recognised PID provider issued it under the applicable framework? | It does not authenticate unrelated qualifications or entitlements |
| EAA | Authenticating the attribute or predicate contained in the attestation | Which attestation provider issued it, and does the relying party accept that issuer? | It says nothing about attributes outside the credential |
| QEAA | Authenticating the contained attribute under qualified-provider and qualified-attestation requirements | Is the issuer a qualified trust service provider for this service and is qualified status required? | Qualified status does not turn one attribute into a complete identity or eligibility decision |
If a procurement note says “all credentials must be qualified,” ask which transaction rule requires that status and how the relying party will identify an acceptable qualified provider. Do not downgrade an ordinary EAA as “unverified” merely because it is not qualified. Its issuer, technical verification and acceptance policy still need to be assessed on their own terms.
One presentation can carry several claims without merging them
Commission Implementing Regulation (EU) 2024/2977 lays down rules for PID and EAA protocols and interfaces used with European Digital Identity Wallets. The implementation details matter, but a successful presentation must still be read claim by claim.
Return to the student-rental fragment. The relying party could request PID for account identity, an age-over-18 attestation for the age rule and a student-status attestation for the rate. The verifier should retain which credential supplied each claim, who issued it, its status result, what the user disclosed and the timestamp. The rental application then applies its policy separately.
Three invalid shortcuts disappear when that evidence is kept:
- valid PID does not imply the user is currently a student;
- a valid student-status EAA does not establish every identity field; and
- a QEAA for one attribute does not prove eligibility rules outside that attribute.
The EUDI Wallet relying-party trust-chain map explains how the wallet provider, issuer, wallet unit, verifier and relying party connect. Use that when the owner of a trust link is missing. This comparison is narrower: it decides what claim object should travel through that chain.
A partner opportunity is ready when the claim object is named
Before accepting a referral or estimating integration work, require a one-row record for each claim:
[Relying party]requests[PID field / attribute / predicate]from[acceptable issuer or issuer class]for[transaction]; it requires[ordinary / qualified / unresolved]status because[rule or policy], and[verifier owner]will test it on[date].
Unknown national availability, production issuer participation and final legal interpretation should remain unknown. A reference-wallet demonstration proves one test path, not that the target credential is available to every user or acceptable to every relying party.
The FAPI 2.0 versus OAuth comparison helps when the same banking project also confuses application programming interface (API) authorisation profiles. An API profile does not determine whether the wallet claim is PID, EAA or QEAA.
TOP Prospect can join incomplete credential, issuer and test-date fragments from Telegram groups the user intentionally connects, preserve the original messages and rank the combined candidate for a partner manager to inspect. It cannot read private chats, issue or qualify credentials, register a relying party, perform legal interpretation, contact the author or approve a user. The product access boundary applies only to opportunity discovery.
The practical comparison is simple: PID establishes identity; EAA authenticates a stated attribute; QEAA adds qualified-provider and qualified-attestation requirements. The relying party still has to name the claim and the decision it will make from that claim.
FAQ
What is PID in the EUDI Wallet framework?
It is person-identification data issued under the applicable Union or national framework that enables a person’s identity to be established. It is not a catch-all record of every user attribute.
What is an EAA?
It is an electronic attestation used to authenticate a stated attribute or predicate, such as an age threshold, qualification or entitlement.
What makes a QEAA different?
A QEAA is issued by a qualified trust service provider and meets the framework’s qualified requirements. That status does not expand the attestation beyond its contained attribute.
Can a valid credential prove facts it does not contain?
No. Verification supports the issuer, status and disclosed claim covered by the credential. Other attributes and the final business decision need separate evidence and policy.
Frequently asked questions
What is person-identification data in the EUDI Wallet framework?
Person-identification data, or PID, is data issued in accordance with Union or national law that enables the identity of a natural or legal person, or a natural person representing another person, to be established.
What is an electronic attestation of attributes?
An electronic attestation of attributes is an attestation in electronic form that allows attributes to be authenticated. The attribute might concern age, a qualification, an entitlement or another stated property.
What makes a QEAA different from an ordinary EAA?
A qualified electronic attestation of attributes is issued by a qualified trust service provider and must meet the qualified requirements in the amended eIDAS framework. Qualified status does not expand the credential beyond the attributes it actually contains.
Can a relying party use a valid credential to infer facts that were not disclosed?
No. Verification supports the credential, issuer, status and disclosed claim covered by the presentation. It does not prove a different attribute, a later event or the relying party’s complete business decision.
Sources and further reading
- Regulation (EU) 2024/1183 establishing the European Digital Identity Framework, 30 April 2024
- Commission Implementing Regulation (EU) 2024/2977 on person-identification data and electronic attestations of attributes, 28 November 2024
- European Digital Identity Wallet Architecture and Reference Framework, accessed 10 August 2026
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
