Trust Anchors Are the Verifier's Problem, Not the Holder's

A trust anchor is the place where checking stops. A signature is checked against a key, that key comes from a document, and at some point somebody accepts a key for reasons that are not cryptographic. That acceptance is the anchor.

And it does not belong to you. It belongs to whoever is deciding whether to act on your credential.

Why a holder has no anchor to set

You can hold a credential from anybody. Nothing stops an issuer nobody has heard of from issuing you something, and nothing stops you keeping it.

Whether it is worth anything is decided elsewhere, at presentation, by a verifier consulting its own list. Two verifiers can look at the same credential and reach opposite conclusions, and neither is malfunctioning.

So the useful question for a holder is not "do I trust this issuer" but "who accepts this issuer", which is a question about the world rather than about your wallet.

What the wallet tells you about an issuer, which is the identifier and nothing else

The credential list shows the issuer as a monospace identifier. There is no badge, no verified marker, no registry lookup.

A search across the wallet for trust, registry and allowlist vocabulary returns only unrelated matches, about cross-origin policy, cookies, locale handling and key-set fetching. There is no issuer-trust mechanism here to find.

That is the honest behaviour, because a badge would be a judgement the wallet is in no position to make. It also means you have no basis in this interface to tell a real issuer from anybody who managed to issue you something, and a holder should know that rather than assuming an entry in the list implies endorsement.

The three questions that decide whether an anchor is worth anything

Who is in the set. One entry is a configuration value. Many entries with published criteria is a governance system, and the engineering is nearly identical.

How the set changes. Adding is easy. Removing is the hard one, because removal is what makes an anchor accountable, and a set with no removal path is a list of things somebody trusted once.

What happens when the lookup fails. An anchor that accepts what it could not check has inverted its own purpose.

Ours, measured on the surface that has one

Our own verifier's anchor was read at its call sites while documenting the authentication surface, and it is reused here rather than re-derived.

It fails closed, which is the right default: a lookup error rejects the presentation rather than admitting it, and the call is timeout-wrapped.

And the configured entry short-circuits the chain. The first entry consulted is configuration, so the one issuer the verifier actually trusts is the one whose document is never re-read. There is no expiry on it and no way for the chain to withdraw it, which means removal requires a deployment rather than a decision.

An anchor you cannot revoke without a deploy is a deployment artefact more than a trust decision, and the caching that makes it fast is what makes it unrevokable.

What to take from this as a holder

Do not read possession as acceptance. A credential in your list is a record that somebody signed something, and nothing more.