ECHO AUTHORITY PROTOCOL · §18 IDENTITY-STANDARDS BRIDGE
It speaks your identity standards now.
DID. Verifiable Credentials. KERI. And still: authority comes only from a human.
Until now, adopting the Authority Object meant adopting our worldview instead of slotting into yours — the gap we named on the proof index as the most important one we knew of. This is that bridge. It resolves DIDs, verifies credentials against live key state, and walks KERI-style event logs. What it will not do is let any of that become permission.
Three standards, three questions
None of them answers “what may be done”
The adapters in §17 translate OAuth, MCP and GNAP — permission formats, where the only rule that matters is never widening authority. These three are different in kind. They are identity standards, and conflating identity with authority is the oldest mistake this protocol exists to refuse.
Who is this, and which key speaks for them?
A resolvable identifier and the verification methods bound to it.
It does not say what may be done. A DID presented alone mints nothing.
What has someone signed a claim about?
Portable, verifiable evidence about a subject.
Evidence can satisfy a condition on a grant. It can never be the grant.
Is that key still the right key?
An append-only key history with pre-rotation — the next key is committed in advance.
It proves key state, not permission. Current keys authorise nothing by themselves.
Live
Translate a real credential — and watch what it cannot buy
Every verdict below is genuine: real Ed25519 signatures, real key event logs walked event by event, and the same attenuation algebra Border Control uses. The first case is the one that matters most — an identity that checks out completely, and still authorises nothing.
The one that needed a key log
Pre-rotation: a stolen key still cannot take over the identifier
Our revocation lists could already retire a grant. They had no way to say “the issuer's key changed.” A KERI-style log fixes that, and its central idea is that every event commits to the digest of the next key in advance. So an attacker holding the current signing key still cannot rotate the identifier to a key of their own choosing — the digest they would have to match was committed before they arrived.
k0, commits digest(k1)k1 — accepted only because it matches the digest committed at s=0k0 rotates in a key of their own — signature valid, digest wrong, refusedA credential signed by a key that has since been rotated out gets its own verdict, separate from a forgery. Both fail the same signature check, but they are very different facts about the same credential, and collapsing them would lose the one that tells you to go ask for a fresh credential.
Verify it yourself
34 assertions, against the exported engine
The suite runs the real bridge — not a mirror of it — and asserts the exact reason code for every case, including that a fully verified identity mints nothing.
npx tsx scripts/authority-did.test.ts ok did-identity-only -> IDENTITY_IS_NOT_AUTHORITY ok did-identity-only authorises nothing ok vc-conditioned-grant -> OK ok vc-claims-authority -> CREDENTIAL_CLAIMS_AUTHORITY ok keri-stale-key -> SIGNED_BY_ROTATED_KEY ok keri-hijacked-rotation -> KEY_STATE_BROKEN ok vc-widen-resource -> NOT_A_SUBSET ok vc-condition-missing -> CONDITION_NOT_SATISFIED ok refusal names pre-rotation ok and STILL nothing was minted 34 passed, 0 failed
Honest edges
Verification methods carry SPKI base64 because that is what WebCrypto imports and what the rest of the protocol already signs. The W3C spec carries publicKeyMultibase, and real credentials are canonicalised with JSON-LD or SD-JWT. Those are the conformance details a production bridge owes you, and they are not done here. The field is named publicKeySpkiB64 rather than mislabelled as multibase.
Documents resolve from an in-memory registry. Real did:web resolution is an HTTPS fetch and real did:key is decoded from the identifier itself. Nothing here reaches the network, so nothing here proves we handle a hostile resolver.
This closes the gap where the Authority Object could not speak these standards at all. It does not mean anyone has adopted it. The milestone we still have not reached is someone unrelated to this project translating their own credentials through a conformant bridge they wrote themselves.
A key event log proves that a rotation was pre-committed, which stops an attacker with a stolen key from rotating the identifier. It cannot tell you the current key was stolen and is being used honestly-looking. That needs watchers gossiping about duplicity, which is the same federation gap our witnesses still have.
A credential can prove who you are, what you have been accredited for, and that the key saying so is still the right key. It cannot decide what may be done with that. Only the human who holds the authority can.