Does a WebID leak more than a DID does? An open, unaudited question

The unlinkability implementation described here is unaudited.

Why the question gets asked

A WebID is a URL, and a URL is memorable, guessable and inherently linkable. Hand the same one to five services and all five hold the same string. If any two of them compare notes, they have correlated you, and that requires no cryptography, no attack, and no cleverness.

The intuition is then: a DID is an opaque identifier, so surely it leaks less.

It does not follow, and this is the part worth being precise about.

The uncomfortable answer

The string being unreadable to a human changes nothing about a join between two databases.

What actually reduces correlation is using a different identifier per relying party, and that is a property of how you use identifiers, not of which kind you use. A WebID can be per-party. A DID can be reused everywhere.

So the comparison people expect, DID good, WebID bad, is not one we can make.

What is genuinely different, and it is small

A WebID resolves by fetching a URL. That fetch is visible to whoever serves it, so the party hosting your profile learns, at minimum, that somebody looked you up, and when.

Our resolution is a call to a chain endpoint. Which we operate, so the same observation applies to us, and today the observer is us. That is not an improvement; it is the same property with a different observer.

The one structural difference worth naming: a WebID profile typically points at your storage location, so dereferencing it reveals where your data lives. Our record's service array is empty, verified live, so it currently reveals no endpoint. That is an accident of it being unpopulated, not a privacy feature, and the same emptiness is a functional gap on another page.

What this page does not address, stated as the term's own entry states it

• Network-level correlation. IP addresses, timing, traffic analysis. Nothing we have built touches this, and nothing we have measured accounts for it.
• Out-of-band correlation. An email address, a phone number, a payment, a name given at signup. Most real-world linking happens here, and no identifier design prevents it.

A page claiming a correlation advantage while ignoring those two would be worthless. They are where the leakage actually is.

The mechanism that would help, and its real status

Per-verifier identifiers (a different identifier for each relying party, derived so the holder can manage them) are the recognised answer.

The derivation exists in our codebase with fixed test vectors. On the surfaces we have examined, nothing calls it. So it is a building block, not a shipped feature, and we are not going to describe it as protection you have.

What would let us answer the question

1. A published external audit of the unlinkability work. Contingent on an unawarded grant.
2. Per-verifier identifiers actually wired into a surface, not just derivable.
3. A measurement: an adversarial analysis of what a colluding set of relying parties could reconstruct. Nobody has done one, including us.

Until then the honest answer to the title is "open". We would rather publish that than a comparison we cannot support.