Somebody Holds a Kill Switch Over Every Credential Network. Ours Is Held by Us

No deployment exists behind anything described here.

The question that decides whether a credential means anything

A verifier receives a credential, checks the signature, and finds it valid. The signature proves the credential has not been altered and that a particular key signed it.

It proves nothing about whether that issuer should still be trusted.

An issuer can be compromised, can start issuing carelessly, can lose its own accreditation, or can turn out to have been fraudulent from the start. Every credential it ever signed still verifies perfectly. Something outside the signature has to answer "and is this issuer still one we accept", and that something is a trust registry.

What a registry actually is

A list of issuers a verifier will accept, maintained by somebody, consulted at verification time.

Europe's version is the trusted-list system: each Member State publishes a signed, machine-readable list of its supervised trust service providers, and the Commission publishes a list of those lists. Twenty-seven registries that recognise each other, with supervision behind each one.

The mechanism is simple. The governance is the entire product.

The lever, stated plainly

Removing an issuer from a registry flips every subsequent verification of that issuer's credentials to reject, across the whole network, immediately.

That is a genuine accountability mechanism and it is the only one that works at issuer level. Revocation lists handle individual credentials; a registry handles the party that issued them.

It is also, unavoidably, a veto. Whoever maintains the list can invalidate an issuer's entire history of work with an edit.

Why we would rather write that than have you infer it

Because it is the first thing a serious buyer should ask any credential network, and most vendors answer it with an architecture diagram rather than a name. The diagram shows a box labelled trust registry. The question is who is inside the box, and what happens when they and you disagree.

For us, today, the answer is that we are inside the box and there is no process for disagreeing.

What has to exist before that changes

Published admission criteria, so inclusion is a test rather than a decision. More than one operator, so removal requires agreement rather than an edit. An appeals path, so an issuer removed in error has somewhere to go. Federation, so a verifier can choose which registry it trusts rather than inheriting ours.

Each of those is governance work rather than engineering work, which is why they are usually late. None of them exists here yet.

What to ask any credential network

"Who can remove an issuer, and what stops them?" If the answer is a company, you have found the dependency. If the answer is a process, ask to read it.

"What happens to already-issued credentials when an issuer is removed?" There is a real design choice between invalidating history and invalidating only future presentations, and a network that has not made it deliberately will make it accidentally.

"Can I choose a different registry?" If not, the registry operator is a single point of trust regardless of how decentralised the ledger underneath is.

Where this leaves a buyer

If you need issuer governance that does not depend on one company's judgement, we do not have it and the European trusted-list model does. If what you need is a working accountability lever on a network at this stage, it exists, it works, and we hold it.