We Are in the W3C Method Registry. That Is a Listing, Not an Endorsement, and Anyone Can Get One.
This page explains why our own registration proves less than it sounds like it proves.
What a method is
The identifier standard defines a shape, not a system. It says an identifier has three parts and resolves to a document describing keys and services. It does not say where that document lives or who decides what it contains.
A method fills that in. It names the system of record, defines how identifiers are created, how keys rotate, how an identifier is revoked, and how a resolver turns one into a document.
So the standard is the socket and a method is the plug. Every meaningful question a buyer has (who can revoke this, what happens if the operator disappears, how fast does a rotation propagate) is answered by the method, not by the standard. Two systems can both be conformant and share nothing that matters.
The registry, and what being in it means
There is a public registry of methods, maintained as a directory of files in the open. Ours is in it.
Here is the whole thing, and you can check it without an account:
curl -s https://raw.githubusercontent.com/w3c/did-extensions/main/methods/solidus.json
Checked 2026-08-04 from a clean directory, that returns our entry with "status": "registered", a contact address and a link to our specification. Two controls beside it: a made-up method file returns 404, and a long-established method's file returns 200, which is how you know the endpoint discriminates rather than answering everything the same way.
Now read what it actually contains. A name, a status, a contact and a pointer to a document we wrote ourselves. There is no review of the specification, no assessment of the implementation, and no statement that anything works.
Being listed is not being standardised and it is not being endorsed, which is the phrasing we hold ourselves to everywhere we mention did:solidus. We say this about our own registration because the temptation to imply otherwise is enormous and the material in this industry is full of it.
What the registry is genuinely for
Preventing collisions and making methods discoverable. Two projects should not both call themselves the same thing, and somebody encountering an unfamiliar identifier should be able to find out whose it is.
Those are real and useful jobs. They are simply not quality signals, and a buyer who reads a registry entry as a seal will draw the wrong conclusion from a directory that is working exactly as intended.
The questions the registry cannot answer for you
"Who can revoke my identifier, and by what process?" The method decides. Sometimes the answer is the operator alone.
"What happens to resolution if the operator stops?" For methods anchored to somebody else's established chain, resolution outlives the vendor. For ours, it does not.
"How long between an operation and every resolver seeing it?" A number the vendor should know.
"Is your implementation reviewed, as distinct from your specification being published?" These are unrelated, and only the second is easy. For us: not reviewed.
What to ask any vendor about method registration
"Registered, or standardised?" Anyone can register. If a vendor blurs this, note it and re-read everything else they have told you.
"Who reviewed your method specification?" Usually the answer is the authors. Ours is the authors.
"Can I read your entry without asking you?" Yes, for everyone, and the entry will be shorter than you expect. Ours is above.
Where this leaves a decision
If you are looking for an identifier method whose survival does not depend on the vendor, ours does depend on us, and a method anchored to an established public chain answers that question better than we can.
If you are evaluating whether we are straight with you about our own credentials, this page is the test: our registration is real, it is checkable in one request, and it certifies nothing about quality, which we would rather tell you ourselves than have you infer later.