Loading today’s stories
Build1 distinct publisher3 min readPublished
Verifiable credentials are a data format and zero-knowledge proofs are a technique. The layer that decides what a user sees, and what every verifier implements, is the disclosure mechanism, and for EU wallets it is already picked.
The Engineer · Build desk
build
Hybrid Post-Quantum TLS: Same Protocol, a 1,216-Byte Key Share1 distinct publisher
security
IETF Publishes Encrypted Client Hello as a Standard to Encrypt SNI, With Caveats1 distinct publisher
build
"Follow the same standard" is how mobile accessibility debt gets onto the books1 distinct publisher
build
Signed receipts on MCP tool calls: 20 lines buys you evidence, not trust1 distinct publisher
Compiled by The EngineerSomething wrong?How this is made
Two mechanisms named, one mandated, and the text we were supplied never says which [8]. According to the dev.to post, BBS+ signatures and SD-JWT solve the same problem with different math, and one of them is the mandatory baseline for every European Digital Identity Wallet due by the end of 2026 [6][7]. That identification is the single fact a build depends on, and it should arrive as a spec name and a version. "One of them" is a fine thing to say on a conference panel and a poor thing to hand an implementer.
So the order of work is: read the mandated profile, then shortlist libraries, then argue about proof systems.
The post splits selective disclosure into two levels and the supplied text runs out partway through describing the first, field-level disclosure, where a credential carries attributes such as name, document number, gender and nationality and the holder releases only some of them [12]. The gap between that and a predicate proof is not cosmetic. Field-level disclosure answers which attribute the holder released; computation-level disclosure answers whether a condition holds over a value that was never sent [20]. Those are different request shapes, different verifier code paths, and different things to log.
There is a second inversion in the model that teams miss because it is not a cryptography question. The holder decides where a credential goes and when it is presented, which the post contrasts with a centralized identity database a business queries on demand [15]. Combine that with a verifier that checks the issuer signature locally [2], and your integration point stops being a server-to-server call to an identity provider and becomes an inbound presentation from a wallet you do not operate [21]. If your current KYC flow is an outbound HTTP request, that is the piece of your architecture that moves.
Credit where the explainer earns it. It flags "zero-knowledge encryption" as a looser marketing synonym rather than a distinct primitive, and less precise than "zero-knowledge proof" [11]. That is the sentence I would keep. A datasheet that reaches for the phrase has told you nothing about the signature scheme, and the signature scheme is what you have to implement, test, and eventually rotate.
Which gives a usable transfer test for any vendor claim about zero-knowledge support. For the claim to mean anything in your build, it would have to name the selective-disclosure mechanism, and that mechanism would have to be the one the wallets you are required to accept actually emit [6][7]. A stack can support proofs, satisfy a procurement checklist, and still present credentials your verifier cannot parse. The proof system is the part that transfers between deployments. The disclosure mechanism is the part that has to match the jurisdiction you are shipping into.
Ranked by verification strength, evidence, and original report placement.
Verifiable credentials, zero-knowledge proofs and selective disclosure are used almost interchangeably in identity marketing, which the post argues is a problem for anyone building on top of them: a verifiable credential is a data format, a zero-knowledge proof is a cryptographic proof technique, and selective disclosure is neither by itself.
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.
Selective disclosure is what happens when a credential's field-level structure and, often but not always, a zero-knowledge proof combine to let someone share exactly one fact about themselves and nothing else.
The post argues a team evaluating an identity stack ends up asking the wrong question, whether it supports zero-knowledge proofs, when the question that actually determines what a user experiences is which selective disclosure mechanism sits behind that answer.
A credential on its own can reveal a field as-is, such as name, document number or gender, while a zero-knowledge proof lets you reveal only the outcome of a computation over a field, such as greater-than, equals or matches, without the underlying value ever being transmitted.
BBS+ signatures and SD-JWT solve the same problem with different math.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 2, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Definitions check out, the headline does not
Every conceptual claim here can be walked back to something public that the post actually names — the W3C data model, the BBS cryptosuites, RFC 9901 — and the BBS+ versus SD-JWT contrast is described precisely enough to be argued with. The headline is the exception: Brussels choosing a baseline arrives with no regulation, no implementing act, no article number, and no name for the winning mechanism. The text also breaks off mid-word inside the SD-JWT bullets, so even the comparison is incomplete on the page.
Two specifications and one self-reported user
What can actually be counted is thin. Two standards exist on paper, one vendor — the author's own — says it uses BBS+ for KYC today, and the OpenID Foundation's mDL work gets a passing mention. The European wallets are a deadline, not a deployment: no wallet, issuer or verifier is named, and no volume of any kind appears.
Careful prose, overconfident headline
The post spends its length arguing against loose usage, and it flags zero-knowledge encryption as marketing rather than a primitive — that is the opposite of hype. The stretch is in the certainty: 'already picked' is presented as settled while the picked thing goes unnamed and uncited, which is a firmer claim than anything on offer here can carry.
The explainer is also a product placement
Hypersign appears three times in a piece that reads as neutral tutorial: its Verifiable Credentials platform, its KYC issuance approach, and a bullet stating BBS+ is what its credentials use today. BBS+ is one of the two candidates for the EU baseline the post declines to name — so the mechanism the author's employer already ships is left standing next to an unresolved mandate. Self-published on dev.to, with no editor between the explanation and the placement.
One post, one author, truncated
There is nothing to triangulate against. A single dev.to piece, a single author with a stake in one of the two answers, and a body that stops mid-sentence. The scaffolding would survive scrutiny by anyone who reads the specifications; the deadline-shaped claim in the headline is precisely the part no one else has touched.