Privacy-Preserving Identity: Selective Disclosure and Zero-Knowledge Proofs with DIDs

Introduction

The promise of decentralized identity isn't just about who controls the data: it's about minimizing what data is shared in the first place. Traditional identity verification forces an all-or-nothing approach: show your driver's license to prove your age, and you also reveal your name, address, and license number. Privacy-preserving DID techniques break this pattern, letting you prove exactly what's needed and nothing more.

The Data Minimization Principle

Every piece of personal data shared is a liability, both for the person sharing it and for the organization receiving it. Data minimization isn't just a privacy ideal; it's a regulatory requirement under GDPR (Article 5(1)(c), which requires personal data be "adequate, relevant and limited to what is necessary"), a security best practice, and increasingly a competitive advantage.

The question DID-based systems answer: How do you verify a claim about someone without collecting their personal data?

Selective Disclosure

Selective disclosure allows a credential holder to reveal only specific fields from a Verifiable Credential, keeping the rest hidden from the verifier.

SD-JWT (Selective Disclosure JSON Web Tokens)

SD-JWT (standardized in November 2025 as RFC 9901) is one of the most practical approaches. The issuer creates a JWT where individual claims are hashed and salted:

1. Issuance: The issuer creates the credential with all claims, but each disclosable claim is replaced with a hash. The actual values are provided separately as "disclosures."
2. Storage: The holder stores the JWT and all disclosures.
3. Presentation: The holder sends the JWT plus only the disclosures they choose to reveal. The verifier can confirm the revealed claims match the hashes in the JWT but learns nothing about the hidden claims.

For example, a credential containing name, date of birth, address, and nationality can be presented with only nationality revealed. The verifier sees a valid credential from a trusted issuer with a single visible claim.

mDL (Mobile Driver's License) Approach

The ISO/IEC 18013-5:2021 standard for mobile driver's licenses implements selective disclosure at the protocol level. Each data element (name, age, address, photo) can be independently disclosed. This standard is already being deployed by governments and is compatible with DID-based issuance.

Zero-Knowledge Proofs

Zero-knowledge proofs (ZKPs) go further than selective disclosure. Instead of revealing a claim's value, you prove a property of the claim without revealing the value itself.

Practical Examples

• Age verification: Prove you're over 21 without revealing your birth date. The proof confirms the mathematical relationship between your birth date and the current date without exposing the date itself.
• Income threshold: Prove your salary exceeds a minimum for a rental application without revealing the exact amount.
• Membership proof: Prove you belong to a set (e.g., licensed professionals in a jurisdiction) without revealing which specific member you are.
• Range proofs: Prove a value falls within a range (credit score above 700, account balance above a threshold) without disclosing the precise number.

ZKP Approaches for Credentials

BBS+ Signatures: A signature scheme specifically designed for selective disclosure and ZKP over signed attributes. The issuer signs a set of attributes, and the holder can derive proofs over subsets of those attributes without the verifier being able to link presentations back to the original signature.

Key properties:

• Unlinkability: Multiple presentations from the same credential can't be correlated
• Selective disclosure: Any subset of attributes can be revealed
• Proof of possession: A verifier confirms the holder possessed a valid issuer signature, without that signature itself being revealed. (True predicate or range proofs, e.g. proving "over 21", are not part of the base BBS scheme; they require additional zero-knowledge machinery layered on top, so many deployments instead have the issuer pre-compute a discrete claim like over18: true that is then selectively disclosed.)

zk-SNARKs/zk-STARKs: More general-purpose ZKP systems that can prove arbitrary computations. These are more computationally intensive but can express complex verification logic. A zk-SNARK could prove that a credential satisfies a compound policy (e.g., "over 21 AND resident of Texas AND has valid insurance") without revealing any of the underlying data.

Combining ZKPs with Bitcoin-Anchored DIDs

The architecture layers cleanly:

1. Bitcoin layer: Anchors the DIDs of issuers and holders, providing tamper-proof key management.
2. Credential layer: Issuers create credentials using ZKP-compatible signature schemes (BBS+).
3. Presentation layer: Holders generate zero-knowledge proofs from their credentials.
4. Verification layer: Verifiers check the proof, resolve the issuer's DID via Bitcoin, and confirm the issuer's key signed the original credential, all without learning the hidden data.

Privacy Considerations Beyond Cryptography

Cryptographic privacy is necessary but not sufficient:

• Correlation: If a holder uses the same DID for every interaction, verifiers can correlate activity. Use pairwise DIDs (a unique DID per relationship) to prevent this.
• Timing: If a credential is issued at a known time and presented shortly after, the timing can be revealing. Batch issuance and delayed presentation mitigate this.
• Metadata: Transport-layer metadata (IP addresses, request timing) can leak information even when the credential content is private. Use Tor or similar network-level privacy tools for sensitive presentations.

Conclusion

Privacy-preserving identity isn't a future aspiration: the cryptographic tools exist today. Selective disclosure with SD-JWT is now a finalized IETF standard (RFC 9901). BBS+ signatures enable unlinkable, selectively disclosable credentials. ZKPs can prove complex statements without revealing data. These techniques work with any DID method, Bitcoin-anchored or otherwise. The challenge now is adoption, tooling maturity, and making these capabilities accessible to developers who aren't cryptographers.