Privacy

This is the section that explains why the architecture is shaped the way it is. Selective disclosure and portability are mechanisms; correlation, linkability, herd privacy and the phone-home problem are the reasons anyone bothered to build them. They are also the questions worth putting to any credential vendor, because they decide whether a system quietly watches the people using it.

The failure modes a credential system has to survive

1. Linkability. Two presentations of the same credential to two different verifiers: can anyone tell they came from the same person? If yes, the credential has become a tracking identifier, and handing users a portable one has made surveillance easier than the system it replaced. This is the risk that makes reusable credentials dangerous if done naively, and it is the reason BBS+ matters more than convenience arguments.
2. Correlation. The broader version: any shared value across contexts that lets two observers join their records. A reused signature, a fixed identifier, a timestamp precise enough to be unique. The cryptography section's correlation handle entry catalogues the specific ones.
3. The phone-home problem. A verifier that must ask the issuer "is this credential still valid?" tells the issuer, in real time, every place the user showed it. The convenient design leaks a complete movement log to the issuer. The standards section's status list entry is the answer: publish a compressed bitstring covering many credentials, let the verifier check offline, and the issuer learns nothing about individual checks.
4. Over-disclosure. Minimal disclosure is revealing only the attribute needed; data minimisation is the legal principle requiring it. In practice this is the difference between proving you are over 18 and handing over a passport scan containing your name, nationality, document number and photograph. Most deployed systems do the second because it is easier.
5. Herd privacy. A property people forget: an anonymity technique protects nobody if too few people use it. If exactly one person in a system uses selective disclosure, the fact of using it identifies them. Privacy needs a crowd, which is why a privacy claim on a system with a small user base is weaker than the mathematics suggests, including ours.

What Solidus actually does about it

Pairwise DIDs, so a different identifier is used with each relying party. BBS+ presentations, so each presentation is a freshly derived proof rather than a copy of the issuer's signature. Status lists, so revocation checks do not phone home. Selective disclosure, so the holder chooses the fields.

Every one of those is a design decision that is correct on paper and unverified in our implementation. An audit is targeted for H2 2026 contingent on an NLnet NGI Zero grant which has not been awarded and whose work has not begun. Until then, the honest claim is "designed to be unlinkable," never "unlinkable."

Where this category ends

The mathematics, how BBS+ derives an unlinkable proof, is cryptography. The legal duties that make minimisation mandatory are the EU and Türkiye sections. What a personal data store adds is the Solid section.

How far our own implementation has been checked

Everything here describes design intent on an unaudited testnet. The cryptography these properties depend on has not been independently reviewed, and privacy is the one property where "we designed it correctly" and "it is correct" are separated by exactly the audit we have not had.