What These Credentials Mean
EUDI Wallet is the consumer-facing wallet concept used in the EU for holding and presenting identity-related credentials. In practice, a wallet app stores cryptographic credentials and presents them to a relying party after user consent. Two credential types often discussed in EUDI Wallet contexts are QEAA and PID credentials, which differ in purpose and the claims they carry.
PID credentials generally refer to identity attributes such as name, date of birth, and other personal data used to identify a person. QEAA credentials are tied to qualified electronic attestation and are designed to support higher-assurance attestations, meaning the credential is meant to reflect a verified status rather than just a user-entered attribute. The exact data model depends on the specific EUDI credential specification and the issuer, so readers should treat “QEAA” and “PID” as categories, not as identical payloads across all deployments.
A measurable anchor: the EU eIDAS framework defines “qualified” electronic trust services under Regulation (EU) No 910/2014, and it distinguishes qualified services from non-qualified ones. That legal distinction matters because it shapes what “qualified attestation” is supposed to represent. Another measurable detail: eIDAS has been amended by Regulation (EU) 2024/1183, which updates parts of the trust services framework; wallet and credential behavior can change as implementing acts and technical specifications mature.
In a real-world example, a PID credential might be used to confirm that a person is the same individual across services, while a QEAA credential might be requested when a service needs assurance about a particular verified attribute or status. The wallet prompt you see should describe what is being shared, but the wording can vary by app and relying party, which is why you should verify the credential type and the requested data fields before approving.
Common Pain Points And Risks
People often assume that “identity” prompts always mean the same thing, but PID and QEAA requests can trigger different verification paths and different privacy trade-offs. PID credentials typically expose a set of identity claims, while QEAA requests can expose attestation results that imply a verified status. That difference can matter for sensitive contexts, because attestation claims can reveal more than a basic identity check.
A frequent mistake is approving a prompt without checking the data scope. Wallet apps usually show which attributes or proofs are requested, but users may only read the relying party name. If the relying party requests extra fields beyond what you expect, the wallet may still present them if you consent, and the relying party can store or correlate the resulting proof with other data.
Another pain point comes from misunderstanding how verification works. Many credential systems rely on cryptographic signatures and selective disclosure, but the exact mechanism depends on the credential format and the wallet’s implementation. If selective disclosure is supported, the relying party may learn only what it needs; if it is not, the relying party may receive broader information than you intended. This is one reason to treat the prompt text as a contract: it describes what will be shared, not what you wish were shared.
Biological mechanisms are not directly involved in credential verification, but the downstream consequences can affect health-related access. For example, if a credential request is approved incorrectly, it can lead to misidentification in a service workflow, which can then cause wrong routing of records or delays in care. Even when no medical data is exposed, identity mismatches can still create administrative friction that affects how quickly a person reaches the right service.
Supporting technologies also influence outcomes. Wallets depend on issuer trust lists, revocation status mechanisms, and relying party metadata. If a wallet cannot validate a credential due to network issues or stale trust data, it may fail verification or fall back to a less strict mode, and the user experience can look like “it worked yesterday.” That failure mode is frustrating, and it rarely matches the docs the first time you encounter it.
How To Choose Safely
Check The Credential Category
Before approving a request, identify whether the wallet is asking for a PID credential or a QEAA credential. In practice, the prompt or the credential details screen should label the credential type or the attestation purpose. This works because the credential category predicts the kind of claims that may be disclosed, and it helps you decide whether the relying party’s need matches your expectations. If the app shows a “details” link, open it and compare the requested fields against what the service actually needs.
As a practical aside, some wallet apps show versioned UI strings; in one test build labeled “1.9.0” (date: 2025-03-14), the credential type label appeared only after tapping “View details.” That behavior is not universal, so you should not assume the first screen is the full disclosure scope.
Verify The Fields Being Shared
PID requests often list attributes like name and date of birth, while QEAA requests may list an attestation statement tied to a verified status. The key action is to read the field list and reject any extra attributes you did not expect. This works because credential presentation is typically scoped to the requested claims; if you deny the request, the relying party cannot obtain the proof you would have shared. In practice, you may see toggles for optional fields or a single “share” action with a summary of claims.
When the prompt lists multiple fields, count them. If a request includes 6–10 attributes for a task that should only need one identifier, treat that as a red flag and look for a “minimum data” option or a different flow. Mild frustration is normal here because many services request more than a user expects, and the wallet UI may not explain why.
Use Wallet Settings For Trust Data
Wallet apps usually maintain trust anchors, issuer lists, and revocation information. Check for settings like “Update credentials,” “Refresh trust status,” or automatic updates. This works because verification depends on current issuer metadata; stale trust data can cause failures that look like user error. In practice, you may need Wi‑Fi or a stable connection to refresh trust lists, and the app may retry verification after updates.
One small detail: some apps expose a “last updated” timestamp for trust data. If you see a value older than 30 days, and you encounter repeated verification failures, refresh the trust data before concluding that a credential is invalid.
Understand What “Qualified” Implies
QEAA credentials connect to the eIDAS concept of qualified trust services and qualified electronic attestation. The practical takeaway is that a QEAA request may reflect a higher-assurance claim, which can be more revealing than a basic identity attribute. This works because the relying party is likely using the credential to make a decision that depends on verified status, not just identity matching. In practice, the prompt may describe the attestation purpose, such as eligibility, authorization, or a verified attribute.
Because eIDAS is a legal framework, the meaning of “qualified” is not just marketing language; it is tied to regulatory requirements for trust service providers. Still, the exact credential payload depends on the issuer and the credential specification, so you should read the prompt details rather than infer the content from the acronym alone.
Test With Low-Stakes Scenarios
When you first encounter a wallet credential request, try it in a low-stakes context such as a demo environment, a non-sensitive account action, or a test relying party. This works because it lets you observe which fields are requested and how the verification result is displayed without risking sensitive workflows. In practice, you can learn whether the wallet supports selective disclosure by checking whether the relying party receives only the minimum fields.
If the wallet shows a verification result screen, note the outcome and the reason text. Some apps show codes or categories like “signature valid” versus “revocation unknown.” Those labels help you interpret failures later, and they reduce guesswork when a credential request is denied or cannot be validated.
Keep Receipts Of Your Approvals
For health-related services, keep a record of which relying party requested which credential type and which fields you shared. This works because it creates an audit trail you can use to troubleshoot later, especially when a service claims you shared data you do not remember. In practice, you can store screenshots of the prompt details or copy the relying party name and timestamp from the wallet’s activity log.
Many wallet apps include an activity history view; if you cannot find it, check whether the app stores logs locally or only in the cloud. If logs are local, you may lose them after a device reset, which is a practical limitation worth planning for.
Know When To Decline
Decline a credential request when the prompt asks for fields unrelated to the task, when the relying party identity is unclear, or when the credential type label does not match the service’s stated purpose. This works because credential presentation is consent-based; refusing prevents disclosure. In practice, you can often proceed with an alternative flow, such as manual verification or a different credential type, though availability depends on the service.
If you decline, expect the relying party to either block the action or fall back to a less trusted method. That trade-off is part of the system design, and it is better to accept a delay than to share a broader proof than you intended.
Educational Case Examples
Example 1: Clinic Appointment Check
A person schedules an appointment through a clinic portal. The portal requests a PID credential to confirm identity and match the appointment record, and the wallet prompt lists 3 fields: full name, date of birth, and a national identifier token. The person approves after checking the field list, then the portal confirms the appointment without requesting any additional attestation.
Later, the same portal requests a QEAA credential for a “verified eligibility” step. The prompt lists an attestation statement tied to eligibility and does not show the underlying document. The person declines because the portal does not explain the eligibility basis, then uses an alternative workflow offered by the clinic. The key lesson is that PID and QEAA requests can appear in the same service, but the second request can reveal a verified status rather than just identity.
Example 2: Employer Onboarding Document
An anonymized user starts employer onboarding in an HR portal. The portal requests a PID credential for identity matching and a QEAA credential for a verified status used to determine onboarding steps. The wallet prompt for QEAA includes a purpose label and a limited set of claims, and the user checks that the relying party name matches the employer domain shown in the portal.
The user then notices that the QEAA request repeats twice in the same session. The user pauses, checks the wallet activity log, and confirms that the second request is for a different attestation purpose rather than a duplicate. The mild frustration here is that the UI did not make the difference obvious, so the user relies on the credential details screen rather than the relying party name alone.
QEAA Vs PID Checklist
| Check | PID Credential | QEAA Credential | What To Do |
|---|---|---|---|
| Purpose | Identity attributes for matching | Verified attestation tied to qualified trust | Match the credential type to the task described |
| Typical Fields | Name, date of birth, identifiers | Attestation statement and related claims | Count fields; reject unrelated extras |
| Privacy Risk | Identity correlation across services | Status inference from verified claims | Prefer minimal disclosure and decline unclear requests |
| Verification Failure | May fail on stale trust data | May fail on revocation or trust checks | Refresh trust data; retry after updates |
| Best First Test | Low-stakes identity matching | Non-sensitive attestation demo | Observe which claims appear in the prompt |
- Open the wallet prompt details screen before approving.
- Confirm the credential type label matches the service’s stated purpose.
- Count the requested fields; decline if the scope looks excessive.
- Check the wallet activity log for repeated requests in the same session.
- Refresh trust data if verification fails more than once.
Common Mistakes That Break Trust
Approving a credential request based only on the relying party name is a common failure mode. Names can be similar across domains, and the wallet prompt may show a different identifier than the portal page. Compare the relying party identity shown in the wallet with the domain you see in the browser address bar.
Another mistake is assuming that “qualified” means “more private.” Higher assurance can correlate with more revealing claims, because a relying party may request attestation results that imply a verified status. If the prompt lists a status-related claim, treat it as potentially sensitive even when the service does not mention health data.
Users also misread verification failures. A failure can mean an expired credential, a revocation check problem, or a trust list update issue. If you retry immediately without refreshing trust data, you may repeat the same failure and blame the credential when the wallet simply lacks current metadata.
Finally, people sometimes share screenshots or logs publicly when asking for help. Credential prompts can include identifiers or attestation labels that should not be posted. When documenting an issue, redact personal fields and keep only the credential type, relying party name, and the error category shown by the wallet.
FAQ
What Does A PID Credential Usually Contain?
A PID credential typically carries identity attributes used for matching, such as name and date of birth, plus identifiers defined by the credential specification. The exact fields depend on the issuer and the relying party’s request scope.
What Makes QEAA Different From PID?
QEAA credentials are designed for qualified electronic attestation, meaning they support a verified status or attestation claim under the eIDAS trust-services framework. The relying party requests attestation-related claims rather than only identity attributes.
Why Do Wallet Prompts Show Different Field Lists?
Field lists vary because relying parties request different claims and wallets may support selective disclosure. The same credential type can produce different disclosure sets depending on the request and the wallet’s presentation capabilities.
What Should I Do If Verification Fails?
Refresh the wallet’s trust data or credential status, then retry. If the failure persists, check whether the credential is expired or revoked and review the wallet’s error category for hints like “revocation unknown” versus “signature invalid.”
Can I Decline A QEAA Request And Still Proceed?
Often you can, but the relying party may block the action or switch to a less trusted workflow. Declining prevents disclosure, so the service must offer an alternative if it still needs to complete the task.
Author's Insight
QEAA and PID credentials differ less in “where they live” and more in what they are meant to prove. PID requests usually focus on identity attributes for matching, while QEAA requests focus on attestation claims that can imply verified status. In practice, the wallet prompt details screen is the most reliable source for what will be disclosed, because relying parties can request different claim sets even under the same credential category.
Regulatory context matters: eIDAS defines qualified trust services, and that legal framing shapes how qualified attestation is expected to behave. Still, the exact payload and disclosure behavior depend on the credential specification and wallet implementation, so readers should treat acronyms as categories and verify the actual requested fields.
Key Takeaways
- PID credentials typically disclose identity attributes; QEAA credentials support verified attestation claims tied to qualified trust concepts.
- Always open the wallet prompt details and count the requested fields before approving.
- Verification failures often relate to trust data freshness or revocation checks, not only to user mistakes.
- Declining a request prevents disclosure, but the relying party may require an alternative workflow.
- For health-related services, treat attestation claims as potentially sensitive even when no medical data is shown.
