Required Attributes In Sharing
EUDI Wallet flows aim to share only the attributes a relying party needs for a specific purpose, rather than sending a full identity record. In practice, that means the wallet can produce a proof that covers a narrow claim, such as “over 18” or “address is in country X,” without disclosing the entire birth date, full address, or document number.
This design follows data minimization principles used across EU privacy law. The technical mechanism typically relies on selective disclosure and verifiable credentials, so the relying party receives a cryptographically verifiable statement about particular fields. The wallet decides which attributes to disclose based on what the relying party requests and what the user approves.
For a concrete example, a pharmacy portal that only needs age verification should not receive your full date of birth. If the portal requests a proof of age, the wallet can respond with a derived claim that satisfies the policy while keeping the rest of the identity data inside the wallet.
One practical detail: many wallet interfaces show a “requested attributes” list before you confirm. If you see a long list of fields for a simple task, that mismatch is a signal to pause and read the request carefully, even if the screen uses polite wording.
Common Pain Points And Dependencies
People often assume that “digital identity” automatically means “privacy by default.” That assumption breaks when the relying party requests more attributes than the task requires, or when the wallet is configured to respond with broader data than necessary.
Another frequent misunderstanding involves consent. Consent is not a magic privacy shield; it only covers what you actually approve. If a relying party’s request includes extra fields, the wallet can still show them to you, and your approval can still lead to disclosure.
Selective disclosure depends on supporting technologies working together: verifiable credentials or similar credential formats, cryptographic proof generation in the wallet, and a relying-party policy that describes which attributes are needed. If any part of the chain falls back to a less private mode, the wallet may transmit more data than you expected.
There is also a user-interface dependency. Wallets can differ in how they present attribute names, whether they group fields, and how clearly they explain derived claims. I have seen attribute labels that look generic (for example, “personal data”) while the underlying request includes multiple fields; the UI translation layer matters, and it rarely gets tested by end users.
Finally, attribute minimization does not remove all metadata leakage. Even when the wallet shares only required fields, the relying party may still learn that you used the service at a certain time, through a certain channel, and possibly with a certain wallet instance. Those details are not “attributes” in the same sense, but they still affect privacy.
What To Do When Sharing
Check The Attribute Request
Before approving, read the exact list of requested attributes and derived claims. If the request asks for a full date of birth when the service only needs age verification, stop and look for an alternative flow such as “age over threshold” or “proof of eligibility” that uses fewer fields.
In many wallets, the attribute list appears after you select the service and before you confirm. Treat that screen as the authoritative disclosure plan. If the wallet shows a version indicator or policy label, note it; in one test flow I reviewed on a wallet build dated 2025-03, the policy label helped explain why a field was requested.
Prefer Derived Claims Over Raw Fields
Derived claims reduce exposure by replacing raw data with a statement that satisfies a rule. Examples include “over 18,” “resides in member state,” or “credential is valid for purpose X.” When the relying party supports these claims, the wallet can avoid sending the underlying raw values.
If the service offers multiple verification options, choose the one that matches the minimum requirement. A common pattern is that the “age check” option requests fewer fields than “identity verification,” even when both end up confirming your eligibility.
Review Wallet Consent And Settings
Wallet apps often include settings for consent behavior, such as whether to remember approvals for a limited time or to require confirmation each time. If you enable “remember,” you may reduce friction but increase the chance that you approve a broader request than you intended.
Check for toggles related to “share less data,” “show details,” or “confirm each request.” If your wallet supports a debug or audit view, use it to inspect what was actually shared. I once saw a wallet log entry referencing a credential schema name; that schema name made it clear which fields were involved, even when the UI summary was vague.
Verify The Relying Party Policy
When possible, confirm that the relying party is asking for attributes that match the stated purpose. A portal that claims to do “age verification” should not need your full address. If the service provides a privacy notice or data protection statement, compare the described data categories with the attribute request you see in the wallet.
For regulated services, the policy should align with legal requirements. If the request looks broader than the legal basis would justify, you can decline and use an alternative method, such as contacting support or using a different verification channel.
Case Examples With Realistic Constraints
Age Check With Minimal Disclosure
A user signs into an online service that sells age-restricted products. The service requests a proof that the user is over a threshold age. The wallet responds with a derived claim and does not disclose the full date of birth.
In the wallet confirmation screen, the user sees “Age over 18” rather than “Date of birth.” The relying party still learns that the proof is valid and that the user meets the threshold, but it does not receive the raw birth date. The user declines if the service also requests additional fields like full address, because those fields do not match the stated age requirement.
Address Proof For A Utility Signup
A user applies for a utility account and needs proof of residence. The relying party requests an attribute representing the country of residence and a validity window for the credential. The wallet shares only those required attributes.
In this scenario, the user notices that the relying party requests “residence country” rather than the full street address. The wallet confirmation shows a short list of attributes, and the user approves. If the relying party instead requested the full address and the user only needs country-level eligibility, the user can decline and ask the service whether a less data-intensive proof exists.
Checklist For Attribute Minimization
| Step | What To Look For | Good Sign | Red Flag |
|---|---|---|---|
| 1. Purpose | Service states the reason for verification | Purpose matches the requested claim (age, eligibility, residence) | Purpose is vague while the request includes many identity fields |
| 2. Attribute List | Wallet shows the exact fields to disclose | Short list with derived claims when possible | Long list of raw fields for a narrow task |
| 3. Confirmation Scope | Whether approval is one-time or remembered | One-time confirmation for sensitive requests | “Remember approval” enabled without clear limits |
| 4. Outcome | Relying party receives only what it needs | Service works even when you decline extra fields | Service refuses to proceed unless you share more than necessary |
If you want a quick decision rule: approve only when the attribute list matches the stated purpose and the list stays short. When the wallet UI hides details behind generic labels, you may need to look for an “expand details” option or decline.
Common Mistakes That Break Minimization
One mistake involves approving the first prompt without reading the attribute list. Many wallet screens show the disclosure plan in a compact form, and users who tap quickly can approve extra fields that the relying party requested.
A second mistake involves enabling “remember my choice” for convenience. If the relying party later changes the request to include additional attributes, a remembered approval can still lead to broader disclosure than you intended. This is a mild annoyance until it becomes a privacy problem.
A third mistake is assuming that “credential sharing” always means “no raw data.” Some flows can fall back to less private methods when the relying party does not support selective disclosure. In those cases, the wallet may send more data than the derived-claim ideal.
A fourth mistake is ignoring the difference between attributes and metadata. Even when only required attributes are shared, the relying party can still log timing and session context. If you are trying to reduce tracking, you still need to consider browser and network behavior, not only wallet claims.
FAQ
What Does “Only Required Attributes” Mean?
It means the relying party receives a proof or credential response that covers specific requested fields for a specific purpose, rather than receiving a full set of identity data.
Can A Relying Party Request More Than Needed?
Yes. The relying party can request a broader set of attributes, and the wallet will typically show that request so you can approve or decline.
Do Derived Claims Replace Raw Data Every Time?
Not always. Derived claims depend on the relying party’s support for selective disclosure and the wallet’s ability to generate the needed proofs for that request.
Does Consent Mean The Wallet Shares Everything?
Consent usually covers the specific attributes shown in the wallet confirmation screen. If the screen lists extra fields, approving that screen authorizes disclosure of those fields.
What Should I Check If The Attribute List Looks Long?
Compare the attribute list to the stated purpose, look for an option that uses a derived claim, and check whether the wallet offers “expand details” or a one-time confirmation mode.
Author's Insight
EUDI-style “only required attributes” relies on a chain of constraints: the relying party must request a narrow set of fields, the wallet must generate proofs that satisfy that request, and the user interface must clearly display what will be disclosed. When any link in that chain is weak, users can end up sharing more data than the purpose suggests.
Because wallet implementations vary, readers should treat the wallet confirmation screen as the most direct evidence of what will be shared. If the UI hides details or labels fields too generically, the safest action is to decline and seek a less data-intensive verification path.
I cannot verify a specific wallet’s behavior from here, so the practical approach is to test with a low-risk service, observe the attribute list, and then adjust wallet settings before using identity sharing for higher-stakes applications.
Key Takeaways
- “Only required attributes” works when the relying party requests narrow claims and the wallet can generate selective proofs.
- Use the wallet confirmation screen as your disclosure checklist; approve only when the attribute list matches the stated purpose.
- Derived claims reduce exposure, but they depend on relying-party support and proof compatibility.
- Consent and remembered approvals can lead to broader sharing than you expect, so review wallet settings for confirmation scope.
- Even with minimal attributes, metadata like time and session context can still be logged by the relying party.
