Unlinkability

UNAUDITED, first, before anything else. Everything Solidus-specific in this entry describes a testnet-grade, unaudited implementation. External audit is targeted for H2 2026 via NLnet NGI Zero. Nothing below is a production assurance until that lands.

What it is. Unlinkability is a property of a credential system: if the same person presents credentials to two different services, neither service, even if they compare notes afterward, can tell from the credential itself that they served the same person. Contrast this with an ordinary login: if you sign in to two sites with the same Google account, both sites (and Google) can trivially tell it's the same person, because the identifier itself is shared and stable. An unlinkable credential is built so that no such shared, stable identifier exists in what gets presented, each presentation is fresh and, from the outside, looks like it could belong to any of thousands of people who hold the same type of credential.

Who built the idea. David Chaum proposed unlinkable credential systems in 1985, well before the cryptographic tools existed to make them fast and practical. Jan Camenisch and Anna Lysyanskaya formalized the modern theory of anonymous credentials in 2001. BBS+, the signature scheme specified by the W3C/DIF BBS working group, descended from Boneh–Boyen–Shacham (2004), is the construction that finally made the property efficient enough to ship: it lets an issuer sign a credential once, while the holder generates a fresh, randomized proof for every single presentation, unlinkable to each other and to the original signature by construction.

How Solidus uses it. Concretely: Solidus's BBS+ credential header is deliberately cohort-constant, identical for every holder issued in the same epoch, rather than carrying anything per-holder. The presentation envelope carries no holder identifier at all, and the verifier actively rejects any envelope that discloses the subject DID or other flagged fields, even if the underlying proof is otherwise cryptographically valid. A domain-and-nonce challenge is folded into every proof, so a presentation captured at one relying party fails verification at another: two colluding verifiers can't even swap presentations to try to link them.

Worth stating plainly, because it's the more interesting story: an earlier version of this format (v1) embedded a per-credential identifier in the header that would have functioned as a correlation handle just as strong as a DID, quietly defeating the whole unlinkability claim. Solidus's own internal review caught it before it was relied on externally, and the fix (v2, which demotes that field to an always-hidden message) is the entire reason the format carries a version number at all. See Correlation Handle for what that failure mode is in general and why it's worth understanding on its own.

What this does not cover: network-level correlation (two relying parties, or a network observer, comparing IP addresses, request timing, or device fingerprints) and out-of-band pooling (if both relying parties already had the user's email or phone number, the credential isn't what links them. They already were). Solidus does not ship Tor or mixnet transport; this property is about the credential, not the network.

Check it yourself. curl https://verify.solidus.network/.well-known/solidus-bbs-issuer.json for the live per-epoch keys, then npm i @solidus-network/auth @solidus-network/bbs and run the bundled demo/unlinkability-demo.mjs. It issues a credential, presents it twice, verifies both, and prints exactly what a colluding pair of relying parties would actually see pooled together.