KERI: Decentralised Identity Without the Blockchain Dependency

The trust problem in digital identity has always been the same question: how does a verifier know that the entity presenting a credential is actually who they claim to be? For decades, the answer was a central authority, a certificate authority, an identity provider, a government registry. Decentralised identity systems tried to fix this by replacing the central authority with a blockchain. But in doing so, they moved the dependency rather than eliminating it.

KERI (Key Event Receipt Infrastructure) asks a more precise question: what is the minimum infrastructure required to establish cryptographic trust in an identifier? The answer it arrives at is just the keys themselves.

The Identifier as a Commitment

In most DID methods, an identifier is a pointer. It resolves by querying a ledger or registry. The meaning of that identifier, what keys control it, what it represents, is stored externally and retrieved at verification time. This creates a hard availability dependency: if the ledger is congested, forked, or its resolution infrastructure changes, verification fails or the result changes.

A KERI AID (Autonomic Identifier) works differently. For transferable identifiers, the kind used in production systems where key rotation is expected, the AID is derived from the digest of the inception event itself. That inception event contains the initial key set, the signing thresholds, the next-key commitments, and the witness configuration. The identifier doesn't point to anything external, it is a cryptographic commitment to the initial state of the identity, and the key event log that follows is a verifiable chain of transitions from that initial state.

Verifying that a given entity controls an AID requires two things: a valid key event log that starts with the inception event corresponding to the AID, and a signature from the keys that the log establishes as currently authoritative. No external query. No ledger state to fetch. The identifier's meaning is intrinsic, not delegated.

Key Event Logs and Self-Certification

The key event log (KEL) is the core data structure. It's an append-only sequence of signed events: inception (establishing the identity), rotation (transferring control to new keys), and interaction (anchoring external data without changing keys). Each event is signed by the currently authoritative keys, and each includes a digest of the previous event, forming a hash-chained, tamper-evident sequence.

This is what KERI means by self-certifying: the log is its own proof. You don't need to trust a registry or a consensus mechanism to verify that a given KEL is internally consistent. The cryptographic structure of the log, signatures, digests, pre-rotation commitments, is sufficient. Any party with the log can verify it independently and arrive at the same conclusion about which keys are authoritative.

Witnesses and Availability

Self-certification solves the trust problem but introduces an availability problem. Without a ledger providing a canonical view of current state, what prevents a compromised controller from presenting different versions of their KEL to different verifiers, a duplicity attack?

KERI's answer is witnesses: a set of independent nodes designated at inception that receipt key events. A witness receipt is a signed acknowledgment that the witness has seen and stored a specific event. When a controller publishes a new event, they collect receipts from their designated witnesses. A sufficient threshold of receipts, configured per-identifier in the inception event, must be present for verifiers to accept the event.

Witnesses don't hold keys and don't validate identity. They provide consistency guarantees: if a controller tries to present two conflicting versions of their KEL, the receipts won't match, at least one witness would have to be compromised or colluding. The threshold is a tunable parameter: a personal identifier might use three witnesses, while an enterprise identity might require ten with a higher threshold.

The witness network is configurable per-identifier. The trust assumptions are explicit, visible in the inception event, and auditable. There is no hidden dependency on a shared validator set whose governance might change out from under you.

Discovery Through OOBIs

A remaining practical question: how does a verifier find a controller's KEL in the first place? KERI addresses this with OOBIs, Out-of-Band Introductions. An OOBI is a URL that points to a service endpoint (typically a witness or a watcher) that can provide the KEL for a given identifier.

The OOBI itself is not trusted. It's a discovery hint, not an assertion. Once the verifier retrieves the KEL through the OOBI endpoint, they verify the log's cryptographic structure independently. An OOBI from an untrusted source is fine, the worst it can do is point you to a valid KEL you didn't know about, or point you to an invalid one that fails verification.

This separation between discovery (OOBIs) and trust (the KEL's cryptographic structure) is a deliberate design choice. Discovery can be opportunistic, social, even insecure. Trust is always derived from the keys.

Ambient Verifiability

The practical consequence of KERI's design is what its architects call ambient verifiability. Credentials issued under KERI, ACDCs, Authentic Chained Data Containers, can be verified by anyone who possesses the issuer's KEL, regardless of whether any particular infrastructure is online at the time of verification.

This is a different class of guarantee than what blockchain-anchored identity provides. A blockchain DID's validity is contingent on the continued availability and stability of a specific chain. A KERI-based credential's validity depends only on the issuer's key event log and the cryptographic structure of the credential itself. KERI can optionally anchor events to a ledger for additional timestamping assurance, but it never requires it, the trust model holds without any external anchor.

For regulated industries, cross-border identity, and long-lived credentials, contexts where a document might need to be verified years or decades after issuance, this property is not a theoretical nicety. It is the difference between infrastructure that degrades predictably and infrastructure that breaks silently when a dependency changes.

Chain-Agnosticism as a Consequence

KERI's chain-agnosticism isn't a marketing claim, it's a structural property. The identity layer makes no assumptions about what other infrastructure exists. It doesn't matter whether your application runs on Cardano, Ethereum, a private ledger, or no blockchain at all. KERI credentials issued on one stack are verifiable in any context that has the issuer's KEL.

This is the design space that becomes available when you strip identity back to its cryptographic essentials and refuse to let it inherit the governance constraints of any particular platform.