EUDI Wallet Sharing Basics
EUDI Wallet is a user-facing app concept under the European Union’s European Digital Identity framework, designed to hold digital credentials and share them with services that need proof. The sharing flow usually starts when a verifier (a website, app, or in-person system) asks for specific claims, such as “age over 18” or “address verified,” and the wallet decides what to disclose. In many deployments, the wallet does not hand over the whole credential; it releases selected data elements tied to a cryptographic proof.
Under the EU eIDAS framework, digital identity and trust services rely on defined legal and technical rules for issuing and verifying electronic credentials. On the technical side, credential formats and proofs often align with W3C Verifiable Credentials and related cryptography patterns, which describe how a credential can be verified without exposing unnecessary details. You may see sharing triggered by a QR code, a deep link, or a browser-to-wallet handoff that passes a request for specific attributes.
One practical example: a pharmacy app may request proof that you meet a regulatory requirement, such as being of legal age. The wallet can respond with a proof that the claim is true, while withholding the exact birth date. Another example: a university portal might ask for enrollment status; the wallet can share a “currently enrolled” attestation rather than a full transcript.
Because the wallet is the user’s interface, the key question becomes what the wallet shows you before you approve sharing. The best systems present the requested claims in plain language, show the verifier identity, and record consent so you can revoke or review later. Some wallets also support offline or delayed verification, which changes how quickly you see results and how much network data gets sent.
Common Sharing Pain Points
People often assume that sharing a credential means “sending a document.” In many designs, the wallet generates a proof for the requested claims, and the verifier checks that proof against the issuer’s trust anchors. If you treat it like email forwarding, you may miss the difference between disclosing raw data and disclosing cryptographic evidence.
A second pain point is hidden dependencies. Wallet sharing depends on at least four moving parts: the credential issuer (who created the credential), the wallet app (who stores and selects claims), the verifier (who requests claims), and the trust infrastructure (who signs and how verifiers trust those signatures). If any one part is misconfigured, the verifier may reject the proof even when the credential is valid.
Third, consent screens can be misleading when they show generic wording. Some interfaces list “personal data” without mapping it to specific claims, which makes it harder to judge what you’re releasing. This is where privacy expectations collide with user interface design, and it’s also where people click through quickly—frankly, most people skip the details.
Fourth, linkability risks can appear even when selective disclosure exists. If a verifier requests the same set of claims repeatedly, or if the wallet uses identifiers that remain stable across sessions, the verifier can correlate visits. Standards can support privacy-preserving proofs, but wallet and verifier implementations decide how identifiers are generated and whether they rotate.
Finally, credential lifecycle issues create confusion. Credentials can expire, be revoked, or be replaced by updated attestations. A wallet may still display an old credential, but the verifier will reject it if revocation status or validity windows no longer match. I’ve seen this in other credential systems where the UI shows “valid” until the verifier checks status—then the flow fails with a generic error.
How To Share Safely
Check The Request Details
Before approving, read the claim list the wallet shows. Look for the exact attribute names and whether the verifier asks for raw values (like full address) or derived claims (like “address verified”). If the screen only says “share identity,” stop and request clarification from the service or use an alternative flow. A practical habit: compare the request against what the service actually needs for the task.
In some wallets, you can tap a “details” view that shows which credential types are involved and whether selective disclosure is active. If you see a toggle for “share full credential” versus “share minimum required,” choose the minimum option. On a recent test build of a wallet prototype I reviewed (version 0.9.x, not a production release), the details view made it obvious that the verifier was requesting both name and date of birth, which most people would not want to disclose for a simple “age over” check.
Use Verified Verifier Identity
Wallets typically show the verifier’s name and sometimes its domain or organization identifier. Only approve when the verifier identity matches the service you intended to use. If you’re scanning a QR code, confirm the destination domain in the wallet handoff screen rather than trusting the QR alone.
For online flows, check whether the request originates from the expected site and whether the wallet shows a secure connection indicator. For in-person flows, ask staff to show the verifier branding on the device screen. This reduces the risk of a “lookalike” verifier that requests broader claims than needed.
Prefer Selective Disclosure Proofs
When a wallet supports it, selective disclosure should reduce data exposure. The verifier should receive only the claims it requested, backed by cryptographic proofs. If the wallet offers a choice between sharing a full credential and sharing specific claims, choose the claim-level option.
Realistic outcome: for an age requirement, you may disclose only a boolean-like claim (“over 18”) rather than the exact birth date. For address verification, you may disclose that an address is within a region or that it matches a verified record, while withholding street-level details. The exact behavior depends on the credential schema and the wallet’s proof capabilities.
Review Consent And Revocation
After sharing, check whether the wallet records the consent and whether you can revoke it. Some systems support “consent receipts” that show what was shared and when, which helps you spot unexpected disclosures. If a credential expires or is revoked, the wallet should reflect that status, but verifiers may still reject proofs if they require fresh revocation checks.
Practical numbers vary by deployment, but revocation checks often add network latency. If a verifier times out, you may see a failure even though the credential is otherwise valid. If you hit repeated failures, try again later or switch networks, since some revocation endpoints may be temporarily unreachable.
Educational Case Examples
Scenario 1: Age Check At A Retail Pharmacy. A user opens a pharmacy app and scans a QR code at checkout. The wallet shows a request for “age over 18” and “pharmacy customer status.” The user approves only the age claim and declines customer status because it is unrelated to the purchase. The verifier accepts the proof and completes the transaction without receiving the user’s birth date.
Scenario 2: University Enrollment Verification. A student needs to prove enrollment for a benefits portal. The verifier requests “currently enrolled” and “program start year.” The wallet shares a derived claim for current enrollment and a limited attribute for the start year, while withholding the full student identifier. The portal later requests additional documents; the wallet can share a separate credential type, but the student notices that one credential has expired and updates it before reattempting.
Sharing Checklist And Tradeoffs
| Decision Point | What To Look For | Privacy Tradeoff | What To Do |
|---|---|---|---|
| Claim scope | Specific attributes vs “full identity” | Broader scope increases linkability | Choose minimum required claims |
| Verifier identity | Expected organization name/domain | Wrong verifier can over-collect data | Verify the handoff screen before approving |
| Proof type | Selective disclosure vs raw data | Raw values expose more than needed | Prefer claim-level proofs when offered |
| Credential status | Expiration and revocation checks | Stale credentials fail verification | Update credentials before retrying |
Step-by-step checklist:
- Confirm the verifier name and domain shown in the wallet handoff screen.
- Read the requested claims and decline anything unrelated to the task.
- Prefer selective disclosure options that share derived claims rather than raw values.
- Approve only after you see which credential type(s) the wallet will use.
- After the flow, check the wallet’s consent history if it offers one.
- If verification fails, check credential expiry and try again with a fresh credential set.
Common Mistakes That Break Trust
One mistake is approving a request without mapping it to a real need. If a service asks for full identity details when it only needs a yes/no eligibility claim, the wallet may still allow it, and the user may not notice. Another mistake is assuming that “share once” means “no further tracking.” Verifiers can still correlate sessions through network identifiers, timing, or repeated claim sets.
A third mistake is ignoring credential freshness. Users may keep old credentials in the wallet and assume they remain valid. Verifiers often check validity windows and revocation status, so a proof can fail even when the wallet UI looks fine.
A fourth mistake is treating QR codes as harmless. QR codes can encode requests that appear legitimate but target a different verifier endpoint. The wallet’s handoff screen should show the destination, and users should rely on that screen rather than the printed label.
A fifth mistake is confusing consent with data deletion. Even when a wallet supports selective disclosure, the verifier may store proof metadata or logs under its own retention policies. Those policies sit outside the wallet’s control, so users should check the service’s privacy notice when available.
FAQ
What Claims Can A Wallet Share?
Wallets share credential claims defined by the credential schema and the verifier’s request, such as age thresholds, verified attributes, or status attestations. The wallet decides which claims it can prove and which it can disclose using selective disclosure.
Does Sharing Send My Full Credential?
Many credential sharing designs transmit only the requested claims plus a cryptographic proof. Some deployments may still share more data than expected if the verifier requests raw fields or if the credential type lacks selective disclosure support.
How Does A Verifier Check Authenticity?
The verifier validates the proof against issuer signatures and trust anchors defined by the trust framework. If the credential is expired or revoked, the verifier rejects the proof even when the wallet still displays the credential.
Can I Revoke A Shared Credential?
Revocation depends on the credential and the issuer’s revocation mechanism. Wallet consent can sometimes be reviewed or withdrawn, but the verifier’s already-collected proof data may remain in its logs according to its retention rules.
Why Would A Proof Fail After Approval?
Common causes include credential expiry, revocation status not reachable at the time of verification, verifier-side configuration issues, or timeouts during network calls. The wallet may show approval while the verifier later rejects the proof.
Author's Insight
EUDI Wallet sharing rests on a clear separation of roles: issuers create credentials, wallets select and prove claims, and verifiers validate proofs using trust rules. The privacy outcome depends less on the concept and more on implementation choices such as selective disclosure support, identifier rotation, and how consent screens map to actual claims. Standards like eIDAS and W3C Verifiable Credentials describe mechanisms, but they do not force every wallet and verifier to behave identically. Readers should treat the wallet’s claim list and verifier identity display as the primary source of truth before approving a request.
Where evidence is limited, the safest approach is to test with low-risk credentials first, then observe what the verifier receives and what the wallet logs. If a service repeatedly requests broader data than expected, that pattern often signals a mis-scoped request rather than a wallet limitation.
Key Takeaways
- EUDI Wallet sharing typically releases requested claims backed by cryptographic proofs rather than sending entire documents.
- Trust depends on multiple components: issuer, wallet, verifier, and trust infrastructure, so failures can occur even after approval.
- Privacy hinges on claim scope, verifier identity checks, and how identifiers behave across sessions.
- Use the wallet’s consent details to decline unrelated claims and watch for credential expiry or revocation-related failures.
