Proving a Claim Without Handing Over the Whole Document
The unlinkability implementation described here is unaudited.
That caveat sits at the top because it has to, not because the mechanism underneath it is unreal. Selective disclosure means proving one fact drawn from a credential, "over 18," "this address is verified," "this license is current", without showing the verifier the document that fact came from, and without the verifier learning anything else the document contains. A holder who proves "over 18" to a bar's age-check and later proves the same fact to a rental platform gives both parties a valid cryptographic proof and nothing to compare notes on.
The mechanism behind it is a BBS+ signature over the credential's claims. The Lexicon entry covers the cryptography itself, what a holder experiences is that the same signed credential can produce a different proof for every presentation, each one revealing only the fields a verifier asked for and mathematically vouching for the rest without exposing them. The BBS+ implementation referenced here is unaudited.
Run it yourself
The proof is a command, not a diagram. This page reads that same run from the holder's side of the exchange: what gets revealed, and what stays sealed.
npm i @solidus-network/auth @solidus-network/bbs
node node_modules/@solidus-network/auth/demo/unlinkability-demo.mjs
The demo issues one credential and has the holder derive a fresh proof for each verifier, revealing only the claims that verifier asked for. It prints its own result, quoted in full, and read byte by byte, on the unlinkability page, where the same run's correlation check shows two proofs from one credential don't line up. Here, the point is the other half of what that run demonstrates: selective disclosure itself. The BBS+ implementation referenced here is unaudited.
What selective disclosure actually does
The transaction has three moves, and the credential is signed exactly once.
- The issuer signs a vector of claims, name, date of birth, address, license number, "over 18", under a single BBS+ signature. One signature covers every field.
- The holder derives a proof that reveals a chosen subset. To prove "over 18" to a bar's age-check, the holder generates a proof that exposes that one field and mathematically vouches for the rest without showing them. The date of birth the "over 18" was computed from never leaves the holder's device.
- The verifier checks the proof locally against the issuer's public key. It confirms the revealed field is genuinely attested by the original issuer, without contacting the issuer again, and without learning any field the holder didn't disclose. The BBS+ implementation referenced here is unaudited.
That is what "proving a claim without handing over the whole document" means mechanically: the undisclosed fields are present in the math, provably signed, and never transmitted. And because the holder derives a new proof for every presentation instead of replaying the issuer's signature bytes, one credential yields different proof material each time, the property the unlinkability demo measures directly, and the reason a holder can prove "over 18" to a bar and later to a rental platform without handing the two anything to correlate. The BBS+ implementation referenced here is unaudited.
In one line: the issuer signs once, the holder proves selectively, and the verifier checks locally, no re-contact with the issuer, and no field revealed that the holder didn't choose.
What this does and doesn't defend against
Read literally: this is presentation-layer unlinkability. It means the correlation handle a verifier could extract from the credential proof itself, a shared identifier, a repeated signature artifact, a value that leaks across two presentations, isn't there. The BBS+ implementation referenced here is unaudited.
It does not mean the holder is invisible. The demo makes no claim about, and this page makes no claim about, defense against:
- IP address: two presentations from the same network address are trivially linkable by the network layer, independent of anything the credential proof does.
- Timing: two presentations submitted seconds apart, or on a predictable schedule, can be correlated by an observer watching request timing alone.
- Device fingerprinting, browser, TLS, and device characteristics travel with every HTTP request regardless of what the credential proof contains.
- Out-of-band data pooling (nothing in this scheme stops two relying parties from comparing notes through some other channel entirely (a shared analytics vendor, a data broker, a subpoena)) the credential layer was never in a position to prevent that.
The distinction matters because it is easy to conflate with unlinkability in the fuller sense that term sometimes implies. What ships today is unlinkability at the presentation layer, a real, specific, independently-checkable property, not a claim that a holder using this system cannot be tracked by any means. Anyone who needs the fuller property has to solve the network- and device-layer problems separately; this page's job is to state the boundary the demo itself prints, not to round it up. The BBS+ implementation referenced here is unaudited.
Where this fits
This deepens the InteractiveDisclosureDemo teaser on how-it-works: that page shows the shape of the exchange; this one runs the real thing. It's also one half of the identity story that makes reuse possible without re-identification: pair it with pairwise DIDs, which keep the holder's identifier from correlating across verifiers, while selective disclosure keeps the claim content from correlating. Together they're what makes credential portability, reusing one issued credential across many relying parties, something other than a single tracking number wearing a privacy label.