We Bet Against the Identifier That Has Real Deployments. That Is a Bet, and It Could Be the Wrong One.

The approach on this page is one we deliberately do not use, and it has production deployments behind it that we do not have.

The approach we did not take

An identifier that is just a web address. Fetch it and you get a document describing the person or agent it names. Authentication happens with a certificate or a token proving control of that address.

Its strength is that it needs nothing new. No chain, no registry, no method specification, no new infrastructure. The web already resolves URLs and already has a certificate system. An organisation that can host a page can issue identifiers.

That is a serious advantage and it is why the approach has real institutional deployments. Our own reference notes record years of use behind it, in public-sector and broadcast settings in Europe. Whatever else is true, that is more production use than we have, and we have none.

What we chose instead, and why

Chain-anchored identifiers, with revocation enforced as a consensus rule.

The reason is narrow and it is the only reason. When an identifier is a web address, revoking it means changing what that address serves, and the timing is governed by caches, certificate lifetimes and whoever controls the hosting. When it is a chain record, revocation takes effect when a block commits, and every resolver sees the same state because the state is the chain.

For a system whose central claim is that a credential can be withdrawn, that difference is the product. We were not choosing an aesthetic. We were choosing where revocation timing is decided.

What the bet costs us, stated plainly

We inherit nothing. The web-address approach runs on infrastructure that exists whether or not its proponents do. Ours resolves because we operate the chain it resolves against. If we stop, resolution stops.

We ask for adoption of something new. Any relying party integrating with us adds a method they have not seen. The other approach asks them to fetch a URL.

Against years of institutional use, that is not a close comparison, and pretending the architecture argument settles it would be dishonest.

A bet with a good reason behind it is still a bet. We would rather write that than describe our choice as a conclusion.

When the other approach is simply better

Worth saying without hedging, because a page that only lists the costs of the road not taken is an advertisement.

If your identities are organisational and already have web presence, the address-based approach fits what you have.

If you need deployments to point at in a procurement conversation, it has them and we do not.

If revocation latency measured in minutes rather than seconds is acceptable to you, the property we optimised for is not worth a new dependency, and you should use the thing that already works.

What to ask about either approach

"Who decides when a revocation takes effect, and how long does it take?" The question our whole choice turns on. For the address-based approach it is hosting and caches; for us it is block commitment.

"What happens to resolution if the vendor disappears?" The address-based approach survives us. Ours does not survive us.

"How many production deployments, operated by someone other than the vendor?" For us: none.

"Is this a standard, or a method registered under one?" Registration is a listing, not an endorsement, ours included.

Where this leaves a decision

If you need an identifier with a deployment record and no new infrastructure, the approach we bet against is a better answer than we are, and we would rather point at it than argue with it.