Field guide 03 · Identity and privacy
Can you prove your age without handing over your identity?
A service may need to know that you meet an age threshold without needing your name, address or full birth date. Digital credentials can support that narrower disclosure, but the issuer, proof format and service all have to support it. A “verified” badge alone does not tell you what was shared.
Prove the condition. Keep the extra details.
01
Begin with the question the service needs answered
Suppose a fictional service requires users to be at least 18. A photograph of an identity document may reveal much more: full name, birth date, document number and address. The useful design question is whether the service can receive reliable evidence of the age condition while receiving fewer personal details.
There are three roles. An issuer makes a claim, a holder keeps the credential, and a verifier checks a presentation of it. A school, government agency or other organization might act as an issuer, but the verifier must decide which issuers it trusts for the particular claim.
Cryptographic verification can show that a claim came from a certain signing key and was not changed in the protected message. It cannot make an issuer’s factual mistake true. Acceptance therefore needs both a valid proof and an appropriate source of the claim.
Source notes: W3C · vc
02
Choosing fields is different from proving a new condition
Some credential formats let the holder reveal selected signed claims and keep other claims hidden. This is selective disclosure. For example, if an issuer has signed an “age at least 18” claim, a supporting wallet can present that claim without also revealing a signed postal address.
That is different from taking a credential that contains only a birth date and proving a mathematical condition about the hidden date. Such a proof needs a mechanism that supports the condition. Do not assume every product advertising private proofs can do arbitrary comparisons.
The W3C’s BBS specification describes ways to disclose selected information while generating fresh proofs that need not reveal they came from the same credential. The version retrieved for this article is a Candidate Recommendation Draft dated 10 September 2026. That is work in progress, not a claim that every credential wallet implements it or that every verifier accepts it.
03
A small proof can still leave a trail
Keeping your name out of a presentation helps, but privacy also depends on the surrounding request. A repeated identifier, a rare combination of attributes, the account you are signed into or the timing of a request can connect activity across services.
A verifier may also need to check whether a credential has been revoked or suspended. A status design that contacts the issuer with a uniquely identifying query can reveal use patterns. The W3C Bitstring Status List design addresses status information in shared lists and discusses correlation risks; using a list does not remove every way to track a person.
Ask what the verifier logs, whether the issuer learns each presentation, and whether the same identifier is reused. The privacy of the proof and the privacy of the whole service are related questions, but they are not interchangeable.
Source notes: W3C · bbs / W3C · status
04
A private credential need not become a public token
The W3C credential model does not require publishing your identity document or each presentation to a public blockchain. The systems used to discover issuer information or check status can vary. Putting a personal identifier on a public chain is a separate design decision with separate consequences.
If a wallet offers to mint a credential as a token, ask why that public record is needed. Can it connect your eligibility check to a payment address? Can the same task be completed with a presentation shared only with the intended verifier? A public token and a private proof solve different problems.
Likewise, proving age does not necessarily prove that one person has only one account. A system trying to prevent duplicate registrations needs an additional design for that goal. Sharing less personal information does not remove the need to define exactly what is being proven.
Source notes: W3C · vc
05
Read a proof request as a request for information
Before approving, look for the service identity, the exact claims requested and the purpose shown. If the request asks for a full birth date when the service describes only an age threshold, the mismatch deserves an explanation. You can decline while you find out whether a narrower presentation is supported.
A useful consent screen distinguishes what will be revealed from what remains hidden and what metadata accompanies the presentation. It should also explain what happens if the credential is expired or unavailable, without implying that the reader has done something wrong.
The practical aim is modest and valuable: disclose what the task needs, understand what else travels with it, and keep a record of what you agreed to share.
Worked example · fictional
One eligibility check, two different disclosures
A fictional credential contains five fields: name, address, birth date, document number and an issuer-signed “18 or older” claim. The example service accepts that issuer and needs only the last claim.
Presenting all five fields exposes four unnecessary fields for this task. Presenting the supported age claim exposes one of the five example fields. That count is not a privacy score: issuer information, proof metadata and network activity may still be visible.
If the credential does not contain the age claim and the wallet cannot generate an accepted proof about the birth date, selecting a checkbox cannot create that capability. The service and credential format must support the narrower route.
| Approach | What the service can learn | Important limit |
|---|---|---|
| Full document image | The visible document fields | May disclose more than the task needs |
| Selected signed age claim | The age flag and presentation metadata | Requires a signed claim and compatible proof |
| Proof about a hidden birth date | A supported age condition and proof metadata | Requires a suitable proof system; not universal |
Try the idea
How much does this service need to see?
The fictional service needs a supported, issuer-signed “18 or older” claim. Select the fields you would disclose.
18 or older: yes
The age claim is included. Four other example fields remain hidden.
The count excludes issuer information and other proof or network metadata. It is not a privacy score. This example uses an already signed age flag.
This is a fictional teaching example. It does not connect to a wallet, create a proof or send a payment.
Use what you learned
What to check
- Check which issuer the service accepts and why.
- Read the exact claims and identifiers requested.
- Ask how status checks and repeated presentations affect privacy.
- Keep public wallet addresses separate from identity proofs unless linking them is needed and understood.
Why this may matter for years
Age checks and digital credentials create a recurring privacy question: how can someone demonstrate eligibility while sharing less? The need is durable even if particular wallet products or legal requirements change.
This is an editorial judgment about lasting usefulness, not measured search demand or a forecast of adoption.
Evidence and scope
These primary sources were retrieved and saved with content hashes. Specifications describe mechanisms; provider documentation describes a particular implementation. Neither is a certification of a product. The examples and checklists apply those mechanisms to fictional situations and practical questions.
Primary-source comparison completed by a separate automated reviewer on 2026-10-02. This is AI-authored content with automated verification; no human or expert approval is claimed.
- Verifiable Credentials Data Model v2.0 ↗
W3C · Ecosystem Overview; Trust Model; Privacy Considerations
Issuer, holder and verifier roles; privacy and trust limits. A data model is not a universal acceptance rule.
Retrieval details
2026-10-02T21:37:36.177438+00:00 · HTTP 200
SHA-256 a9196a3d0b6601356c4e127bad24f8c7f2c17f6ed22e41b35755a910104156f8
- Data Integrity BBS Cryptosuites v1.0 ↗
W3C · Introduction; Selective Disclosure; Privacy Considerations
Candidate Recommendation Draft dated 10 September 2026. A selective-disclosure mechanism, not universal wallet support or arbitrary range-proof support.
Retrieval details
2026-10-02T21:37:36.297880+00:00 · HTTP 200
SHA-256 b61fcd72506d689095ddbf001d338c81e137724584373e00dae65a3a30a441f5
- Bitstring Status List v1.0 ↗
W3C · Privacy Considerations; Herd Privacy
Status checking and correlation considerations, not a promise that a deployment is private.
Retrieval details
2026-10-02T21:37:36.298080+00:00 · HTTP 200
SHA-256 3cdf3358a09f3b02f2a97e5dac13cf2b63115c2db1260bf7b7c236d8702924ec