Checking Whether a Credential Issuer Is Trusted: The Check Is Live, and the Answer for Everybody Today Is Not Enrolled

The question underneath the question

A credential tells you who issued it. It cannot tell you whether that issuer should be believed.

Anybody can mint an identifier and sign a claim with it. So a party receiving a credential has a second question after "is this signature valid", and the second question is the harder one: who says this issuer is entitled to make this claim.

There is a live check, and you can run it right now

curl https://capture-api.solidus.network/registry/issuers/<did>

It answers. An identifier the registry has never seen comes back as a rejection with a message written for exactly that case.

CONTROL: asking for a path that does not exist returns a generic router error instead, so the message above is a lookup that ran and found nothing, not a request falling through to a default.

And the semantics are the right way round

Two different rejections, kept distinct. An identifier the registry has never seen is one answer. An identifier it has de-listed is a different one, returned as a definitive rejection rather than a silence. A verifier is told to treat both as untrusted, and the code says so.

The reason for a de-listing is deliberately not public. The status and its timestamp are. That is a considered choice about what a public endpoint owes a stranger.

And the caching is asymmetric in the safe direction. An enrolled answer may be cached briefly. A rejection is served with caching switched off, so a rejection is never the stale answer.

The code names its own hole, so we will too

A de-listing can reach a cached verifier up to a minute late.

And the per-credential status list does not cover that window, because it carries revocation for individual credentials rather than the standing of the issuer behind them. Those are different questions and only one of them is in that document.

The comment in the code states this and accepts it for a first version. A minute is small until the thing you de-listed is being used in that minute.

And the answer today is nobody

The registry is empty. Measured read-only against the production database: no issuer rows, no client rows, and no entries in the append-only status ledger.

That is structural rather than a sampling artefact. An issuer row cannot exist without a client row, because the schema requires one, so the two readings cannot disagree.

So the honest description is: the read path is built, deployed and answering, and there is nothing enrolled for it to answer about. A registry with no entries rejects everybody, which is the correct behaviour and is not the same thing as a working trust fabric.

And none of this touches the chain

This is a different host and an ordinary database table. It is not chain state, it is not in a block, and no explorer can show it to you.

The chain's own credential check does not consider the issuer at all. It answers whether a credential is revoked. It takes no trust input, so a valid answer from it says nothing about who issued the thing.

A reader who assumed the chain was arbitrating issuer trust should stop assuming that here.

The root of the chain of trust is a configured string

Every enrolled issuer records who accredited it. That value comes from one configuration entry with a default, and the default identifier resolves to nothing on the chain and is not in the registry either.

CONTROL: a known-good identifier resolves in the same second, so that is a reading rather than a broken resolver.

Nothing depends on it today, because nothing is enrolled. It would matter on the first enrolment, and it is the kind of placeholder that becomes load-bearing without anybody deciding it should.

De-listing ends an identifier, not an operator

De-listing is terminal for the identifier. That is a real accountability property.

The same operator may enrol again under a new identifier, which the schema permits by design.

So a verifier learns that an identifier is finished. It does not learn that an operator is gone, and reading the first as the second would be a mistake this page would rather you did not make.

Why this exists at all, and where it is going

A self-issued identifier is worth nothing until a relying party trusts the issuer behind it. A registry is one way to manufacture that trust, and it is the way that scales to strangers. The European framework manufactures the same thing at continental scale, which is why this shape of component exists at all rather than being invented here.

We hold no accreditation, certification or conformity assessment of any kind. Alignment with the European reference architecture is a roadmap conformance statement targeting the fourth quarter of 2026 and is not a held certification, and the qualified-trust-service path is documented roadmap rather than anything achieved.

What is already done is on this page and is not nothing: the read path is deployed and answering, the rejection semantics are built and distinguish two cases, the enrolment transaction records terms acceptance, and the status ledger is append-only. What is not done is the part that requires other people: an enrolled issuer, an accreditor that resolves, and anybody relying on the answer.

This page is not legal advice, and a party deciding whether a credential satisfies an obligation should take its own.

What you can check yourself

curl https://capture-api.solidus.network/registry/issuers/did:solidus:testnet:1111111111111111111111zz

Then ask about an identifier you believe in, and notice you get the same answer, because the answer does not currently depend on the identifier.