Linkability

A credential, or more precisely, a specific way of presenting a credential, is linkable if there's any way, cryptographic or otherwise, for two different verifiers to determine that two separate presentations came from the same underlying credential (and therefore, usually, the same person). Linkability isn't about a credential leaking your name; it's narrower and sneakier than that. Two presentations can each disclose nothing more sensitive than "I am over 18," and still be linkable, if some other field in the presentation (a signature, a hash, a serial number) happens to be identical both times.

This is the direct, named opposite of Unlinkability (see that entry), which is the property a credential system is designed to have when it avoids exactly this. Reading the two entries together is more useful than reading either alone: unlinkability describes the guarantee a system is aiming for; linkability names the specific failure mode that guarantee has to defeat.

Where the term comes from

Jan Camenisch and Anna Lysyanskaya's 2001 work on anonymous credential systems gave linkability its formal cryptographic treatment, proving, for a given credential construction, whether an adversary who sees two presentations can distinguish "same credential, different presentation" from "two different credentials" better than random guessing. Separately, and more recently, EU data-protection regulators gave the term legal weight: the Article 29 Working Party's 2014 Opinion on Anonymisation Techniques lists linkability as one of three concrete tests a dataset must pass to be considered genuinely anonymous, not merely pseudonymous. Solidus did not originate either the cryptographic theory or the regulatory framing.

Two mechanisms, two honest answers

This is where the concrete engineering matters more than the definition. Solidus's live credential ecosystem runs two different disclosure mechanisms (see Selective Disclosure), and they have genuinely different linkability properties, this isn't a nuance to gloss over:

• SD-JWT VC, the format Solidus's testnet issuer actually speaks today, confirmed via its OID4VCI metadata, reveals the same salted hash for a given disclosed claim every time that claim is disclosed. Two verifiers who both see the same disclosed birthdate hash can compare notes and know it's the same credential. This is a documented property of SD-JWT itself, not something Solidus's implementation got wrong.
• BBS+ signatures generate a fresh, randomized zero-knowledge proof for every presentation. Mathematically, two BBS+ presentations of the same credential are unlinkable to each other, provided the implementation is correct, which is precisely what hasn't been independently checked yet.

Solidus status

Both formats run on Solidus's public testnet; there is no mainnet. The BBS+ (unlinkable) path is unaudited, say that before anything else, since the whole unlinkability claim rests on an implementation nobody outside Solidus has verified. The SD-JWT (linkable) path needs no audit caveat to be honest about, because its linkability isn't a bug, it's a known, stated tradeoff of the format, and it's what a relying party gets today by default.

Check it yourself

curl -s https://capture-api.solidus.network/.well-known/openid-credential-issuer confirms the live, linkable SD-JWT path is real, not aspirational. For the unlinkable path, npm i @solidus-network/auth @solidus-network/bbs and run the bundled demo/unlinkability-demo.mjs, its own printed output states the audit-pending boundary rather than asking you to take Solidus's word for it.