Data Minimization in Identity: Selective Disclosure and Zero-Knowledge Proofs with DIDs

Introduction

Decentralized identity is not only about who controls the data. It is also about how little data you share. With a traditional identity document, you often must show all of the data or none of it. If you show a physical driver's license to prove your age, you also show your name, address, and license number. The techniques in this post let you show only the data that a verifier needs.

The Data Minimization Principle

Each item of personal data that you share is a risk for you and for the organization that gets it. In the EU, data minimization is a legal requirement. GDPR Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary" for the purposes of their use. Data minimization is also a security practice: data that you do not collect cannot leak from your systems.

DID-based systems try to solve this problem. A verifier must check a claim about a person. But the verifier must not collect more personal data than necessary.

Selective Disclosure

With selective disclosure, a credential holder shows only some fields of a Verifiable Credential. The verifier does not see the other fields.

SD-JWT (Selective Disclosure JSON Web Tokens)

The IETF published SD-JWT as a Standards Track RFC, RFC 9901, in November 2025. SD-JWT uses salts, hashes, and a standard JWT signature, so it needs no new signature scheme. The issuer makes a JWT in which a salted hash replaces each disclosable claim:

1. Issuance: The issuer puts a hash of each disclosable claim into the JWT, not the claim itself. The issuer gives the claim values to the holder separately, as "Disclosures".
2. Storage: The holder stores the JWT and all Disclosures.
3. Presentation: The holder sends the JWT and only the Disclosures that the holder selects. The verifier makes sure that each disclosed claim matches a hash in the JWT. The verifier does not learn the values of the other claims. An issuer can add decoy digests to hide the number of claims (RFC 9901, Section 4.2.5).

For example, a credential can contain a name, a date of birth, an address, and a nationality. The holder can show only the nationality. The verifier sees a valid credential from a trusted issuer with one visible claim.

SD-JWT has a limit. Each presentation of one credential contains the same issuer signature, so verifiers can link presentations of that credential. RFC 9901 describes batch issuance as a mitigation: the holder gets many copies of the credential and uses a different copy for each verifier. Batch issuance does not help if the issuer and the verifier collude (RFC 9901, Section 10.1).

mDL (Mobile Driver's License) Approach

The ISO/IEC 18013-5:2021 standard for mobile driver's licenses (mDL) has selective disclosure in its protocol. The mDL holder decides which of the requested data elements to release to the verifier. There is one exception. If the verifier requests the portrait and the holder releases any other data element, the standard requires the holder to release the portrait too. The issuing authority can also add data elements that show less, for example age_over_18. Then the holder does not have to show the date of birth (AAMVA mDL Implementation Guidelines, version 1.6).

Governments issue mDLs today. For example, the US TSA accepts mDLs and other digital IDs at its checkpoints. As of September 2026, its list has more than 20 US states and territories (TSA). The mDL trust model does not use DIDs. A verifier gets the public key of the issuing authority from an IACA root certificate and a Verified Issuer Certificate Authority List (VICAL) (AAMVA guidelines). Like SD-JWT, mDL uses salted hashes, so the same linkability limit applies (RFC 9901, Section 10.1).

Zero-Knowledge Proofs

Zero-knowledge proofs (ZKPs) do more than selective disclosure. With a ZKP, you prove a property of a claim, and you do not show the value of the claim.

Practical Examples

• Age verification: You prove that you are older than 21, and you do not show your birth date. The proof shows the mathematical relation between your birth date and the current date, but not the birth date itself. Frigo and shelat showed ZKPs of this type for ECDSA credentials in the ISO mdoc format. Their method needs no change to issuer processes (Anonymous credentials from ECDSA).
• Income threshold: You prove that your salary is more than a minimum for a rental application. You do not show the exact amount.
• Membership proof: You prove that you are a member of a set, for example the licensed professionals in a jurisdiction. You do not show which member you are.
• Range proof: You prove that a value is in a range. Examples are a credit score above 700 or an account balance above a threshold. You do not show the exact number.

ZKP Approaches for Credentials

BBS signatures: BBS is a signature scheme for selective disclosure and zero-knowledge proofs over signed attributes (IRTF CFRG draft, The BBS Signature Scheme). As of September 2026, the latest revision of that draft is from January 2026, and the draft is expired. The W3C Data Integrity BBS Cryptosuites v1.0 specification uses BBS for Verifiable Credentials. As of September 2026, that specification is a W3C Candidate Recommendation Draft. Some texts use the name "BBS+" for this family of schemes. The current scheme follows Tessaro and Zhu (2023), who made the signature smaller than in earlier variants (CFRG draft).

The issuer signs a set of attributes. The holder makes a proof over a subset of those attributes, and the verifier cannot link the proof to the original signature.

Key properties:

• Unlinkability: Verifiers cannot use the proof values to correlate two proofs from the same credential. This property applies only to the proof value. Disclosed attributes and other data can still link presentations (CFRG draft).
• Selective disclosure: The holder can show any subset of the attributes.
• Proof of possession: A verifier confirms that the holder has a valid issuer signature, but the verifier does not see the signature. The base BBS scheme does not include predicate proofs or range proofs, for example a proof of "older than 21". Such proofs need more zero-knowledge protocols on top of BBS. Thus, some deployments let the issuer calculate a separate claim, for example over18: true, and the holder discloses that claim. The mDL age_over_NN data elements use the same method.

BBS has a deployment cost. It uses new cryptographic primitives, so issuers must change their infrastructure (Anonymous credentials from ECDSA).

zk-SNARKs and zk-STARKs: These are general ZKP systems that can prove statements about general computations. For example, the Groth16 zk-SNARK proves that an arithmetic circuit is satisfiable (Groth, 2016). zk-STARKs need no trusted setup (Ben-Sasson et al., 2018). These systems can express complex verification logic. The tradeoffs are more complex circuits and, for Groth16, a trusted setup that makes a common reference string and a trapdoor.

For example, a zk-SNARK can prove that a credential satisfies a compound policy. An example policy is "older than 21 AND resident of Texas AND has valid insurance". The proof does not show the data behind the policy.

ZKPs with Bitcoin-Anchored DIDs

The architecture has four layers:

1. Bitcoin layer: Bitcoin anchors the DID updates of issuers and holders. This makes the key history tamper-evident.
2. Credential layer: Issuers sign credentials with a scheme that supports ZKPs, for example BBS. BBS uses BLS12-381 keys, not secp256k1 keys (W3C BBS Cryptosuites, Multikey). A btcr2 issuer can add a BLS12-381 verification method to its DID document with an update.
3. Presentation layer: Holders make zero-knowledge proofs from their credentials.
4. Verification layer: A verifier resolves the DID of the issuer with Bitcoin data and gets the issuer key. Then it checks the proof. The proof shows that the issuer key signed the original credential, and the verifier does not learn the hidden data.

Privacy Considerations Beyond Cryptography

Cryptographic privacy is necessary, but it is not sufficient:

• Correlation: If a holder uses one DID for all interactions, verifiers can correlate the activity. Use pairwise DIDs (a different DID for each relationship) to reduce this risk. For more, see Private DID Resolution.
• Time correlation: An issuer can issue a credential at a known time. If the holder presents it soon after, the times can link the two events. Batch issuance and a delay before presentation reduce this risk. For a batch, RFC 9901 requires that the issuer randomize or round time claims such as iat (RFC 9901, Section 10.1).
• Metadata: Transport metadata, for example IP addresses and request times, can show information when the credential content is private. For sensitive presentations, use Tor or a similar network privacy tool.

Conclusion

The cryptographic tools for private identity exist today. SD-JWT is an IETF Standards Track RFC (RFC 9901). BBS signatures give unlinkable proofs and selective disclosure, and the W3C BBS cryptosuite is a Candidate Recommendation Draft as of September 2026. General ZKP systems can prove complex statements and keep the data private. SD-JWT and BBS do not depend on a specific DID method, so a Bitcoin-anchored DID method can use them. The open problems are adoption, tool maturity, and access for developers who are not cryptographers.