What Is a Zero-Knowledge Proof — and Why Should You Care?

June 12, 2026 ·Gustav Poola ·

zero-knowledge-proofszero-knowledge-identityzkpselective-disclosuresd-jwtbbs-signatureseudi-walletverifiable-credentialseidasprivacy-by-design

Zero-knowledge proofs are real technology in production today — privacy crypto, blockchain scaling, and selective disclosure of verifiable credentials. RFC 9901 standardised SD-JWT in November 2025; the EUDI Wallet ARF points toward BBS+ as the everlasting-privacy target. The bit ZKPs do not replace is identity proofing itself.

What Is a Zero-Knowledge Proof — and Why Should You Care?

Zero-knowledge proofs are real technology in production today, mainly in three places: privacy-preserving cryptocurrency, blockchain scaling, and zero-knowledge identity — the selective disclosure of verifiable credentials. The third is the one that matters for digital identity. RFC 9901 standardised SD-JWT in November 2025; the EUDI Wallet Architecture Reference Framework points toward BBS+ as the everlasting-privacy target. The bit zero-knowledge identity does not replace is identity proofing itself.

The question we got last quarter

A compliance officer at a Stockholm-headquartered financial-services integrator we work with asked, on a Thursday afternoon call: can the wallet prove our customer is over eighteen for the streaming-platform partnership we're shipping, without us recording the date of birth? The vendor pitch they had read claimed yes, immediately, via zero-knowledge proofs. The integration target date was eight weeks out. The customer was asking — in good faith — whether they should write that capability into the contract. The same selective-disclosure plumbing that this post unpacks shows up on the holder-binding side of verifiable diplomas, which we covered in our earlier post on EBSI holder binding.

The honest 2026 answer is yes, with caveats that matter for the contract. The marketing layer compresses three different technologies into one phrase, and the contract drafting has to disambiguate them. This post is how we walked through it on that call. If you're reading because the question reached your inbox the same way it reached ours, the rest of this post is the conversation we had.

So what does a zero-knowledge proof actually prove?

A zero-knowledge proof lets one party (the prover) convince another party (the verifier) that a specific statement is true, without revealing why it is true or how the prover knows it. The cryptographic definition gives a ZKP three properties: completeness (a true statement always convinces an honest verifier), soundness (a false statement essentially never convinces an honest verifier), and zero-knowledge (the verifier learns nothing beyond the truth of the statement). In identity terms: a wallet can prove "the holder is over eighteen" without disclosing the date of birth. The verifier learns the predicate's truth value, nothing more.

What's actually shipping in 2026?

Three production families, in descending order of identity relevance.

Selective disclosure of verifiable credentials — what most of the industry now calls zero-knowledge identity — is the production use case for identity. RFC 9901 — Selective Disclosure for JSON Web Tokens became an IETF standard in November 2025; draft-ietf-oauth-sd-jwt-vc-16 ties it to verifiable digital credentials and is the spec EUDI Wallet pilots are integrating against. The mechanism replaces a subset of credential fields with digests of salted values; the wallet decides at presentation which fields to disclose and which to keep opaque. EBSI documents the same approach for the European academic and government wallet stack (EBSI Hub — Selective Disclosure with SD-JWT).

Privacy-preserving cryptocurrency has been live since 2016, when Zcash shipped zk-SNARK-based shielded transactions. The lesson worth carrying over to identity engineering is operational, not financial — ZKPs at this scale have been running in adversarial environments for nearly a decade. The cryptographic primitives are stable; the friction has historically been integration, not maths.

Blockchain layer-2 scaling is the area that has driven the recent proving-system performance gains. zkSync, Polygon zkEVM, Starknet — these use general-purpose proving systems (Plonk, Halo2, Stark families) to compress execution proofs. The integrator who called us was reading about throughput numbers from this category and assuming identity proofs would inherit them. They do not. The identity-layer proofs are smaller and slower, and the engineering question is not throughput but spec stability.

Three disclosure modes — full credential, SD-JWT selective disclosure, and BBS+ predicate proof — showing what the verifier learns in each. Full disclosure reveals all attributes; SD-JWT reveals chosen attributes plus opaque digests but is linkable across presentations; BBS+ reveals only predicate truth values, with fresh proofs per presentation and unlinkability across verifiers.

What trade-off does SD-JWT not solve?

SD-JWT is real selective disclosure. It is not, on its own, unlinkable selective disclosure.

The salted-hash mechanism works by replacing credential fields with digests of salted values. The wallet reveals the salt + value pair for the fields it discloses, and the digests stay opaque for the rest. The verifier checks each disclosed field by recomputing the digest. The catch is that the salts and digests of the un-disclosed fields stay constant across every presentation of the same credential. A verifier — or, more concerning, a collusion of verifiers — can correlate presentations across services even when no attribute is ever fully revealed. The EUDI Wallet ARF section 5.2 on Zero-Knowledge Proofs calls this out explicitly, which is one reason the ARF text positions BBS+ as the target end-state rather than SD-JWT as the destination.

BBS+ closes the linkability gap. A BBS+ signature lets the wallet derive a fresh proof at each presentation — same underlying signature, different proof bytes — so two presentations of the same credential to two different verifiers leave no cryptographic correlator. It also lets the wallet prove predicates over attributes (age over a threshold, country in a set) without revealing the underlying attribute value. SD-JWT cannot do predicate proofs natively; it either discloses an attribute or doesn't.

We watch the BBS+ Signatures specification at the IRTF Crypto Forum Research Group because the standardisation schedule determines when the EUDI Wallet rollout can switch from the SD-JWT-with-salted-hash interim to the BBS+ end-state. The interim is shipping now. The end-state is what the ARF aims at — and Secure Element implementations have to follow the spec.

What we told the integrator

Three things, on that call.

First — the contract should say "selective disclosure of the date-of-birth attribute via SD-JWT, with migration to BBS+ predicate proofs when the spec stabilises". Not "zero-knowledge proof". The phrase "zero-knowledge proof" in a contract draft, without that disambiguation, will land on the customer's data-protection officer's desk and the question will come back six weeks later asking which protocol family is actually being used. Better to specify it now.

Second — the eight-week target was achievable for SD-JWT, with the linkability caveat documented. The customer's data-protection officer will ask about this; the right answer in the contract is that the current implementation uses SD-JWT with the documented salted-hash limitation, and the integration commits to migrate to BBS+ predicate proofs when the EUDI Wallet pilots they're consuming move to it. We expect that in 2027 at the earliest.

Third — the bit they had not asked about, which mattered more for their architecture. SD-JWT and BBS+ both sit at the disclosure layer. Neither answers how the customer's identity was proofed at admission in the first place. The vendor pitch they had read folded all this into "ZKP-based privacy". In their actual deployment, the upstream proofing event — the customer's biometric passport NFC chip read at onboarding for the 179 ICAO 9303 countries, with document authenticity plus biometric face match (FaceTec liveness) as the fallback for the rest — was a separate concern that the ZKP layer does not touch. We confirmed they had a primitive there. They did. The streaming-platform partnership integration was safe to ship.

Where do ZKPs apply in a 2026 identity stack — and where don't they?

After three years of these calls landing on the engineering desk, the pattern of what actually works is consistent.

Use ZKPs at the credential-presentation layer. Selective disclosure with SD-JWT is the right immediate adoption for zero-knowledge identity in 2026 — it ships against RFC 9901, integrates with EUDI Wallet pilots running today, and lands the privacy-by-design properties the GDPR was always asking for (Regulation (EU) 2016/679 Article 25). Plan for the linkability caveat — document it for your data-protection officer — and pin a migration to BBS+ on the roadmap. See our Zero-Knowledge product page for how the IdentiGate stack handles this layer today.

Treat predicate proofs as the high-value 2027 use case. Age over a threshold, residency in a country set, holder-of-a-membership-without-naming-the-membership. These are the cases where BBS+ architecture pays back the implementation effort. Until BBS+ stabilises, accept that "predicate proof" is not yet on the menu in production EUDI Wallet deployments; SD-JWT can disclose-or-not, but not prove-without-disclosing.

Do not treat zero-knowledge identity as a replacement for identity proofing. This is the misconception we see most often in procurement conversations. A zero-knowledge proof can demonstrate that a credential signed by a trusted issuer contains an attribute over a threshold; it cannot tell the verifier whether the holder is actually the person to whom the credential was issued, nor whether the original issuance was based on a genuine identity proofing event. That work happens upstream, at admission, through a primitive — passport-NFC for the 179 ICAO 9303 countries, document plus face match for the rest. See Post 5 of the education cluster on EBSI holder binding for the deeper engineering on this separation.

Keep the disclosure layer separate from the proofing layer in procurement. A vendor pitch that bundles "ZKP-based wallet" with "identity verification" is bundling two architectural concerns that should be procured separately. The disclosure layer commodity-trends faster than the proofing-layer commodity does. Locking yourself into a single vendor at both layers means re-tendering both when one of them moves.

What I'd push back on, when the framing positions ZKPs as a privacy replacement for chip-based admission proofing, is that the two solve disjoint problems. The chip read proves a person exists and is who they claim to be at the moment of enrolment. The ZKP proves a property of that person to a downstream verifier without revealing more than the property's truth value. Both layers are needed. Either alone is the wrong architecture.

Sources

Primary — Selective disclosure and verifiable credentials standards

Primary — EUDI Wallet and BBS+

Primary — Identity-assurance and regulatory framing

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.