Unlinkability Is a Commercial Property That Happens to Be Bought With Cryptography

The word is treated as a maths property, and the buyer's question is not mathematical

Vendors explain unlinkability with proof systems. Buyers are asking something simpler: if my customers use this in ten places, can those ten places build a picture of them?

That is a question about business relationships and data pooling, and cryptography is one of several things that decides the answer. Treating it as purely mathematical is how a system with excellent proofs ends up correlating everybody.

What it is actually worth, commercially

It removes a category of liability you would otherwise acquire. If presentations cannot be linked, there is no cross-context profile for you to be asked about, breach, or explain to a regulator. Not a control you operate: an exposure that does not exist.

It changes what a partner can do with what you gave them. Data that cannot be joined to their other data is worth less to them and safer for you.

And it is a differentiator in exactly one direction. No consumer chooses a bank for unlinkability. But an enterprise buyer whose own compliance function asks "can this vendor's system be used to track our customers" needs an answer, and "structurally no" is a different answer from "we promise not to."

The four things that have to be true at once

Cryptography delivers one of them.

The proof must not carry a stable value. This is the cryptographic part, and the mechanism that provides it is the one whose implementation we have not had audited.

The envelope around it must not either. One constant field defeats the whole construction, and we shipped exactly that defect once, which has its own page.

The network must not. IP address, timing and device characteristics correlate people regardless of what the credential does.

And the parties must not already share data out of band. Two verifiers who both hold a customer's email address do not need the credential to link anything.

So unlinkability is a property of a deployment, not of a library. A vendor claiming it as a feature has claimed one of four and implied the set.

Why we will not sell it as a guarantee

Because the two conditions we do not control are the ones most likely to break it.

We cannot stop a verifier logging IP addresses. We cannot stop two businesses joining data they collected themselves. A vendor promising unlinkability as an outcome is promising something about your deployment and your partners, which they cannot see.

What we can offer is that the credential layer does not contribute a handle. That is a real, checkable contribution and it is one quarter of the answer.

What to ask any vendor claiming it

"Which mechanism, and is it audited?" Two questions. Ours: the unlinkable one exists, and no.

"Show me two presentations from the same holder and let me diff them." This converts the claim into a check that takes minutes.

"What does your claim explicitly not cover?" If network-level and out-of-band correlation are not in the answer, the claim is broader than the property.

"Which mechanism do you use by default?" Products often support the strong one and deploy the other, which is our situation and worth asking about everywhere.

Where this leaves a decision

If your requirement is that a verifier receives less, that is a different and easier property, it is what the deployed path delivers, and conflating the two is the mistake this page exists to prevent.

The audit status of this implementation

The unlinkability implementation described here is unaudited.