The Universal Resolver, and Why Single-Resolver DID Methods Are Fragile
The gap described below is ours, it is small, and it is not blocked on anything.
The layer that portability arguments skip
A credential names its issuer with an identifier. Before a verifier can check the signature, it has to turn that identifier into a public key.
That step is called resolution, and it is where the dependency actually lives. Everyone argues about credential formats, which are standardised and interoperable. Almost nobody asks the question underneath: when a verifier meets your issuer's identifier for the first time, what does it have to talk to?
If the answer is your company, the credential is portable and the trust chain is not.
The shared infrastructure that exists for this
The decentralised-identity community maintains a common resolver: one HTTP interface in front of pluggable drivers, one driver per identifier method, so a client can resolve any supported identifier without hard-coding anything method-specific.
It is the same job DNS does for domain names, generalised. A verifier integrates once and can then resolve identifiers from methods it has never heard of, because somebody else contributed the driver.
That is the piece of infrastructure that makes a multi-issuer world practical rather than theoretical.
Where we are, checked today rather than asserted
There is no driver for our identifier method in it.
You do not have to take that from us. The resolver publishes the methods it supports:
curl -s https://dev.uniresolver.io/1.0/methods
Today that returns eighteen methods. key and web are among them, which tells you the request worked. solidus is not.
So a verifier using the shared resolver cannot resolve our issuers. It has to call our own endpoint instead, which means integrating against us specifically, which is the thing the shared resolver exists to avoid.
What that costs a buyer, stated concretely
The format travels and the issuer resolution does not. A credential we issue is a standard document that any conforming verifier can parse. Establishing that the issuer identifier inside it maps to a real key requires our infrastructure.
We become an availability dependency for verification. If our endpoint is unreachable, a verifier that has not cached the issuer's document cannot complete the check. That is a different failure mode from "the credential is invalid" and it belongs to us rather than to the credential.
And it makes the lock-in argument concrete. We have written elsewhere that we are also a form of lock-in and that its shape is the registry and the resolution path rather than the format. This is the resolution path, named, with a public list you can check our absence on.
The uncomfortable part
Writing the driver is days of engineering work. It is not blocked on funding, on a partner, on a specification, or on anyone's permission.
It is outstanding because it has not been prioritised. Our own planning notes call it the one cheap real move still outstanding and warn, in as many words, against describing it as done before it ships.
We are repeating that here because a vendor's backlog is not usually a buyer's business, and this item is: it is the difference between an identifier a stranger can resolve and one only we can.
What is genuinely done, since this is one gap and not the whole picture
The identifier method, did:solidus, is registered in the W3C DID Method Registry, which reserves the name and points at a published specification. That is a registry listing rather than a standard, an approval or an endorsement, and we will not describe it as more than that.
Resolution works. It is documented, and a stranger can exercise it against our endpoint without an account. The credential formats are the community's, not ours.
The missing piece is the adapter that lets somebody else do the resolving. That is a real gap and it is a small one, and both halves of that sentence matter.
What to ask any identifier-based vendor
"Can a third party resolve your issuer identifiers without calling you?" This is the portability question that actually bites, and it is separate from whether the credential format is open.
"Are you in the shared resolver? Let me check while we talk." The list is public and the check takes seconds. A vendor who has not thought about it will say something vague; a vendor who has will tell you their method name.
"What does a verifier do when your resolution endpoint is unavailable?" A caching policy with a stated staleness tolerance is a real answer. Silence is a real answer too.
"What is on your backlog that would remove a dependency on you?" Ask for the item and the reason it has not shipped. Ours is above.
Where this leaves a decision
If your requirement is that no single company sits in the verification path, we do not meet it today, and the specific reason is one adapter that does not exist. What would change it is that adapter reaching the shared resolver, and nothing else has to happen first.
If you are evaluating anyway, the useful framing is that this gap is named and unblocked, which makes it a scheduling question rather than an architectural one, and you are entitled to ask us when rather than whether.