Verifiable Credentials and Zero-Knowledge Proofs, Explained

Verifiable credentials, zero-knowledge proofs, and selective disclosure get used almost interchangeably in identity marketing, and that's a problem for anyone actually building on top of them. A verifiable credential is a data format. A zero-knowledge proof is a cryptographic proof technique. Selective disclosure is neither of those by itself, it's what happens when a credential's structure and, often but not always, a zero-knowledge proof combine to let someone share exactly one fact about themselves and nothing else.

The confusion has a real cost. A team evaluating an identity stack ends up asking the wrong question, does it support zero-knowledge proofs, when the question that actually determines what a user experiences is which selective disclosure mechanism sits behind that answer. BBS+ signatures and SD-JWT solve the same problem with different math, and the EU has already picked one of them as the mandatory baseline for every European Digital Identity Wallet due by the end of 2026. This post works through what each term actually means, how they connect, and what to check before adopting any of them.

What Is a Verifiable Credential?

A verifiable credential is a digitally signed claim, structured to a specific data model rather than free-form. The W3C Verifiable Credentials Data Model 2.0 defines the shape: an issuer signs a set of claims about a subject, a holder stores the resulting credential, and a verifier checks the issuer's signature cryptographically instead of calling the issuer back to confirm anything. A university issuing a diploma as a verifiable credential, or a government issuing a driving licence the same way, are both plain examples of the model, the credential itself is the signed artifact, not a PDF or a scanned image of one.

That distinction is what separates a verifiable credential from a document upload. A scanned passport is just an image, anyone with image-editing software can alter it, and a verifier has no cryptographic way to confirm it wasn't. A verifiable credential's signature breaks the moment a single claim inside it is changed, so tampering is detectable rather than merely discouraged. The holder also controls where a credential goes and when it's presented, a property closer to self sovereign identity than to a centralized identity database a business queries on demand. This is the same standard behind the mobile driver's licence work the OpenID Foundation is pushing in the US, covered in more depth in our piece on standardizing mDLs as verifiable credentials, and it's the data model Hypersign's own Verifiable Credentials platform issues KYC results as, rather than storing a raw document per check.

What Is a Zero-Knowledge Proof?

A zero-knowledge proof is a cryptographic technique that lets one party prove a statement is true to another party without revealing anything beyond the truth of that statement. The canonical framing is proving you know a password without ever saying the password out loud, applied to identity, it becomes proving you're over 18 without revealing your date of birth, or proving your income clears a threshold without revealing the exact figure.

Most practical implementations, zk-SNARKs among them, build on decades of cryptographic research into interactive and non-interactive proof systems, and the field has moved fast enough that what counted as a research topic a few years ago now ships in production identity and payments infrastructure. The important distinction for this post is what a zero-knowledge proof adds on top of a verifiable credential: a credential on its own can reveal a field as-is, name, document number, gender. A zero-knowledge proof lets you reveal only the outcome of a computation over a field, greater-than, equals, matches, without the underlying value ever being transmitted at all. Some systems also describe this family of techniques as zero-knowledge encryption, though that term is less precise than "zero-knowledge proof" and worth treating as a marketing synonym rather than a distinct primitive.

Selective Disclosure: Verifiable Credentials Meet ZK Proofs

Selective disclosure is what you get when a verifiable credential's field-level structure and, optionally, a zero-knowledge proof's computation-hiding property combine to let a holder share exactly what a verifier needs and nothing else. It has two distinct levels, and conflating them is where most of the confusion in this space starts.

The first level is field-level selective disclosure: a credential holds several attributes, name, document number, gender, nationality, and the holder discloses only some of them as-is. No zero-knowledge proof is required for this, cryptographic schemes like BBS+ let a single signed credential support many different partial disclosures without a proof of a computed statement anywhere in the flow. The second level adds a zero-knowledge proof on top: instead of disclosing the date-of-birth field itself, the holder proves a predicate over it, age is greater than or equal to 18, without disclosing the field. This is why selective disclosure and zero-knowledge proofs get treated as synonyms in casual usage even though they're not, a system built on selective disclosure verifiable credentials can implement either level, or both in the same consent flow, depending on what a specific request needs.

BBS+ vs SD-JWT: Two Ways to Do Selective Disclosure

Two specifications currently do the technical work of selective disclosure, and they solve it with different cryptography rather than being two names for the same mechanism.

The BBS Cryptosuite specification describes a signature scheme built for unlinkable disclosure from the ground up, one signed credential, many cryptographically independent partial proofs, which is also the foundation anonymous credentials schemes build on. RFC 9901, formally adopted by the IETF as Selective Disclosure for JSON Web Tokens, takes a simpler route: an issuer hashes each disclosable claim at issuance, and a holder reveals the cleartext of only what a verifier asked for. Neither is strictly better, SD-JWT is easier to bolt onto existing JWT infrastructure and is the format the EUDI Wallet ecosystem is converging on, while BBS+ is the more cryptographically mature scheme for unlinkable, zero-knowledge-compatible disclosure. A stack built to interoperate with both, rather than betting on one exclusively, is in a stronger position as EU adoption timelines firm up.

A Zero-Knowledge Age Proof: Selective Disclosure in Practice

The clearest worked example of where these pieces meet is age verification. A platform sets a minimum-age requirement, 18, and instead of asking a user to upload a government ID showing an exact birthdate, the user's verifiable credential proves the comparison directly: age is greater than or equal to 18. The verifier receives a pass or fail result and nothing else, no date of birth, no document image, no document number ever crosses the wire.

This is a zero-knowledge proof example running inside a credential-based selective disclosure flow, not a hypothetical. Hypersign's Selective Disclosure and Zero-Knowledge Age Proofs feature implements exactly this today: a verifier configures a minimum age against a ProofOfAge credential, the comparison runs as a threshold proof, and the response the verifier's system receives is limited to pass or fail. The same predicate model extends past age, jurisdiction checks ("EU resident: yes or no") and KYC tier checks ("verified at Level 2 or above") use the identical mechanism, which matters directly for age-gated platforms and other use cases mapped in more depth in our age verification solution, where age verification privacy is the whole point, not an afterthought bolted onto a document check.

eIDAS 2.0: Why the EU Digital Identity Wallet Needs This

Regulation (EU) 2024/1183, the amendment that added the wallet framework to the base eIDAS Regulation, writes selective disclosure into the design of the European Digital Identity Wallet as a baseline requirement, not an optional feature a Member State can choose to skip. Every EU Digital Identity Wallet has to technically enable a user to selectively disclose attributes, including combining attributes drawn from multiple separate credentials, to a relying party. Data minimization is the legal principle behind the requirement, and selective disclosure is the mechanism that makes it enforceable at the protocol level instead of resting on a policy promise a business could quietly ignore.

Every EU Member State has to offer citizens at least one certified digital identity wallet by the end of 2026, and large private relying parties in regulated sectors face mandatory wallet acceptance roughly a year after their Member State's wallet goes live. Actually requesting anything from a wallet also requires registering as a relying party first, a separate legal filing we cover in detail in EUDI Wallet Registration: The Relying Party Filing Every Fintech Must Get Right. What matters for this post is narrower: the digital identity wallet every EU citizen will hold by next year is built around selective disclosure by regulatory mandate, which means a verifiable credential and zero-knowledge proof stack that already speaks that language has a real head start, not just a nice-to-have privacy feature.

What to Check Before You Adopt Verifiable Credentials and ZK Proofs

A vendor claiming support for verifiable credentials or zero-knowledge proofs isn't specific enough to evaluate against. Check for these instead:

• Does the credential format follow the W3C Verifiable Credential Data Model, or a proprietary schema one vendor controls end to end?
• Is selective disclosure implemented with BBS+, SD-JWT, or neither, meaning fields get redacted manually after the fact rather than cryptographically?
• Can the holder choose which attributes to share on a per-request basis, or is disclosure all-or-nothing regardless of what the verifier actually asked for?
• Does the stack interoperate with the SD-JWT-based EUDI Wallet direction today, or would meeting the 2026 mandate mean rebuilding the credential layer later?
• Is a completed verification reusable across relying parties, the reusable kyc model, self sovereign identity in practice, or does every new partner still mean a fresh document upload?

Most teams end up needing more than one of these properties at once, a W3C-compliant credential format alone doesn't guarantee interoperable selective disclosure, and a zero-knowledge proof capability without a portable credential underneath it doesn't solve reusability. Evaluate the whole chain, not just whichever term shows up first on a vendor's homepage.

Where This Leaves You

Verifiable credentials give you a tamper-evident, holder-controlled data structure. Zero-knowledge proofs let you prove a computed fact from that structure without revealing the value behind it. Selective disclosure is the two combined, already the mandatory baseline for every EU Digital Identity Wallet by the end of 2026, and increasingly the expectation everywhere else identity verification touches a user. Whether the right mechanism for a given flow is field-level BBS+ disclosure, a full zero-knowledge threshold proof, or SD-JWT for EUDI Wallet interoperability depends on what a specific verifier actually needs to know, not on which term sounds most impressive in a pitch deck.

FAQ

What's the difference between a verifiable credential and a zero-knowledge proof?

A verifiable credential is the signed, tamper-evident data structure that holds a claim about someone, issued by an authority and controlled by its holder. A zero-knowledge proof is a cryptographic technique for proving something about that data without revealing it. They're often used together, but one is a data format and the other is a proof method, and a system can implement either without the other.

Is selective disclosure the same thing as a zero-knowledge proof?

No. Selective disclosure means sharing only specific fields from a credential as-is, which needs no zero-knowledge proof at all. A zero-knowledge proof adds the ability to reveal only the outcome of a comparison, such as age being over 18, without disclosing the underlying value. Both can appear in the same consent flow, and Hypersign supports both.

What is SD-JWT, and how is it different from BBS+?

SD-JWT, formally IETF RFC 9901, is a JSON Web Token format that supports selective disclosure by hashing individual claims at issuance, and it's the mechanism the EU's EUDI Wallet has standardized on. BBS+ is a signature scheme that lets one signed credential support many cryptographically independent partial disclosures. Both achieve selective disclosure, through different underlying math.

References

Primary sources for the citations above:

• W3C Verifiable Credentials Data Model 2.0
  The specification defining what a verifiable credential is and the issuer-holder-verifier model.
• W3C Data Integrity BBS Cryptosuites v1.0
  The BBS+ signature scheme specification for unlinkable selective disclosure.
• RFC 9901, Selective Disclosure for JSON Web Tokens (IETF)
  The SD-JWT specification and its salted-hash disclosure mechanism.
• Regulation (EU) 2024/1183 (EUR-Lex)
  The eIDAS 2.0 amendment requiring selective disclosure in every EU Digital Identity Wallet.

About Hypersign

Hypersign issues KYC results as signed W3C Verifiable Credentials rather than stored documents, with BBS+ selective disclosure and zero-knowledge age and threshold proofs live in the KYC widget and dashboard today, aligned with the SD-JWT direction the EU Digital Identity Wallet is standardizing on. It doesn't write the W3C or IETF specifications themselves, and it isn't a general-purpose zero-knowledge proving system for use cases outside identity, its scope is applying selective disclosure specifically to the KYC and verification moment. See the full Selective Disclosure and Zero-Knowledge Age Proofs platform for how the credential and proof layers fit together.