Privacy-Preserving Verifiable Credential Flow
Prove only what's needed—share cryptographic proofs, never identity documents
The Privacy-Preserving Verifiable Credential Flow reimagines identity verification as proof generation rather than document sharing. An issuer creates a structured credential bound to the holder's public key, with attributes encoded at multiple specificity levels. The holder stores this in a self-sovereign wallet. When a verifier requests a specific attribute, the holder generates a zero-knowledge proof revealing only that attribute—never the full credential. Verification happens offline; the issuer is never contacted during presentation. One-time, peer-wise presentations prevent replay attacks. The result: minimum necessary disclosure is enforced by design, no PII surveillance trail is created, and users retain full control of their identity data.
- Share proofs, not documents
- Bind credentials to the holder's own cryptographic identity
- Verifiers request specific attributes, not full identity records
- Verification must happen offline—no issuer phone-home
- Presentations are one-time and peer-wise to prevent replay
- Minimum necessary disclosure is enforced by protocol design
- Design the credential attribute hierarchyStructure the credential so attributes exist at multiple levels of specificity—for example, 'has a hat' → 'has a red hat' → 'has a red hat from 2023.' This layering allows holders to reveal only what any given context requires without exposing broader information.Pro tipWork backward from the verifier's minimum required information to determine how granular your attribute levels need to be.
- Bind the credential to the holder's DID and public keyIssue the credential such that it can only be presented by the controller of the associated private key. A stolen credential without the corresponding private key is cryptographically useless to any threat actor.WarningChoose a DID method that supports the revocation and recovery requirements your use case demands before issuing any credentials.
- Enable selective disclosure and ZKP encoding in the credential formatUse a credential format that supports zero-knowledge proofs so the holder can prove a specific attribute without exposing any other part of the credential. Align with open standards like the W3C Verifiable Credentials Data Model for cross-verifier interoperability.Pro tipEvaluate formats like SD-JWT or BBS+ signatures depending on your selective disclosure and ZKP performance requirements.
- Store the credential in a holder-controlled walletDeliver the signed credential to the holder's self-sovereign wallet. The holder—not the issuer—now controls when and how individual attributes are presented to any verifier.WarningWallet security becomes the critical control point once the credential is issued; ensure holders understand their key management responsibilities.
- Formulate verifier requests as specific attribute queriesRequire verifiers to define exactly which attribute they need—nothing more. The request format should be machine-readable so the holder's wallet can automatically identify which credential and attribute satisfies the request without manual inspection.Pro tipStandardize request formats so multiple wallet implementations and credential types can interoperate without custom one-off integrations.
- Generate a one-time ZKP presentation scoped to the interactionThe holder's wallet generates a zero-knowledge proof proving possession of the requested attribute, tied to a unique challenge from the verifier so the presentation cannot be captured and replayed elsewhere.Pro tipSupport NFC or QR-based presentation for in-person contexts to keep the experience fast and frictionless for end users.WarningPresentations not tied to a unique per-interaction challenge can be captured and replayed—audit your implementation for this vulnerability before deployment.
- Validate the presentation offline without issuer callbackThe verifier checks the cryptographic proof and verifies the issuer's signature on the credential without contacting the issuer. No surveillance trail, no centralized log of who presented what credential where or when.WarningAny verification stack that pings the issuer on every presentation is building surveillance infrastructure—audit all third-party SDKs for hidden callbacks.
A bar requests only proof that a patron is over 21. The patron's wallet generates a ZKP from their state-issued digital credential, revealing only the age attribute via QR code. The bar validates the proof offline without ever learning the patron's name, address, organ donor status, or any other detail from their driver's license. No record of the visit is created or transmitted anywhere.
A private club requires proof of red hat ownership from 2023. The holder's wallet reads a credential from a trusted issuer and generates a selective disclosure proof revealing only that specific nested attribute. The verifier validates offline, trusts the issuer's cryptographic signature, and grants access without learning anything else about the presenter or contacting the issuer.
A customer who completed identity proofing at Bank A receives a verifiable KYC credential documenting their assurance level. When opening a checking account at Bank B, they present a selective disclosure proof of KYC completion. Bank B validates the credential offline, accepts the attestation within its own risk context, and skips redundant document collection entirely.
Extracted from TFTC, where a digital identity architect walked through the ideal verifiable credential issuance and presentation flow using W3C standards, decentralized identifiers, selective disclosure, and zero-knowledge proofs.