{ "slug": "prove-age-without-sharing-identity", "title": "Can you prove your age without handing over your identity?", "searchTitle": "Private age proofs: verifiable credentials and selective disclosure", "category": "Identity and privacy", "accent": "#bdb0f4", "diagram": "disclosure", "interactive": "disclosure", "summary": "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.", "why": "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.", "overlap": "The current catalogue explains soulbound tokens and public-chain privacy. This article follows a private credential presentation and distinguishes a signed age flag from proving a condition about a hidden birth date.", "related": [ "soulbound-tokens", "eip-712-typed-data", "ethereum-rpc-privacy" ], "sections": [ { "id": "question", "heading": "Begin with the question the service needs answered", "sourceIds": [ "vc" ], "paragraphs": [ "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." ] }, { "id": "selective", "heading": "Choosing fields is different from proving a new condition", "sourceIds": [ "bbs", "vc" ], "paragraphs": [ "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." ] }, { "id": "metadata", "heading": "A small proof can still leave a trail", "sourceIds": [ "bbs", "status" ], "paragraphs": [ "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." ] }, { "id": "blockchain", "heading": "A private credential need not become a public token", "sourceIds": [ "vc" ], "paragraphs": [ "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." ] }, { "id": "request", "heading": "Read a proof request as a request for information", "sourceIds": [ "vc", "bbs" ], "paragraphs": [ "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." ] } ], "example": { "title": "One eligibility check, two different disclosures", "paragraphs": [ "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." ] }, "table": { "headers": [ "Approach", "What the service can learn", "Important limit" ], "rows": [ [ "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" ] ] }, "checklist": [ "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." ], "figure": { "title": "Prove the condition. Keep the extra details.", "caption": "A fictional selective-disclosure example using an issuer-signed age flag. It is not a live identity check or a demonstration of arbitrary range proofs.", "description": "A credential has five example fields. Only the age-at-least-18 field travels through a proof to a service; name, address, birth date and document number stay with the holder." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "b7c035aeee767954c7572ddea0fca80835f8a936f8797a0baf897da2f7460980", "status": "verified by separate automated source review", "sources": [ { "id": "vc", "title": "Verifiable Credentials Data Model v2.0", "publisher": "W3C", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "locator": "Ecosystem Overview; Trust Model; Privacy Considerations", "scope": "Issuer, holder and verifier roles; privacy and trust limits. A data model is not a universal acceptance rule.", "retrieval": { "id": "vc", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "finalUrl": "https://www.w3.org/TR/vc-data-model-2.0/", "retrievedAt": "2026-10-02T21:37:36.177438+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/vc.source", "sha256": "a9196a3d0b6601356c4e127bad24f8c7f2c17f6ed22e41b35755a910104156f8", "text": "evidence/vc.txt", "textSha256": "aaf9d9fb66b3f91ca5e2d78dd80b25653a107d99b65fdf887fc048ac26a9df6e" } }, { "id": "bbs", "title": "Data Integrity BBS Cryptosuites v1.0", "publisher": "W3C", "url": "https://www.w3.org/TR/vc-di-bbs/", "locator": "Introduction; Selective Disclosure; Privacy Considerations", "scope": "Candidate Recommendation Draft dated 10 September 2026. A selective-disclosure mechanism, not universal wallet support or arbitrary range-proof support.", "retrieval": { "id": "bbs", "url": "https://www.w3.org/TR/vc-di-bbs/", "finalUrl": "https://www.w3.org/TR/vc-di-bbs/", "retrievedAt": "2026-10-02T21:37:36.297880+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/bbs.source", "sha256": "b61fcd72506d689095ddbf001d338c81e137724584373e00dae65a3a30a441f5", "text": "evidence/bbs.txt", "textSha256": "2d3cea02f34b461ce612061164e6b038747842144327259d65f7f5c8a1c18ae5" } }, { "id": "status", "title": "Bitstring Status List v1.0", "publisher": "W3C", "url": "https://www.w3.org/TR/vc-bitstring-status-list/", "locator": "Privacy Considerations; Herd Privacy", "scope": "Status checking and correlation considerations, not a promise that a deployment is private.", "retrieval": { "id": "status", "url": "https://www.w3.org/TR/vc-bitstring-status-list/", "finalUrl": "https://www.w3.org/TR/vc-bitstring-status-list/", "retrievedAt": "2026-10-02T21:37:36.298080+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/status.source", "sha256": "3cdf3358a09f3b02f2a97e5dac13cf2b63115c2db1260bf7b7c236d8702924ec", "text": "evidence/status.txt", "textSha256": "36b9a134f731590654d3073ca30e1738dede4cbfb2b82af55a9f979bcd304c67" } } ], "canonical": "https://degreesofsatoshi.com/guides/prove-age-without-sharing-identity/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "b7c035aeee767954c7572ddea0fca80835f8a936f8797a0baf897da2f7460980" } }