Skip to main content

​
What is KERI?

KERI, or Key Event Receipt Infrastructure, is a decentralized framework for creating and managing digital identifiers. It uses cryptographic methods to maintain an immutable log of identity events—such as creation, rotation, and delegation—thereby removing the need for centralized authorities. This framework is designed to empower edge devices and individual entities to manage their own identities securely, making it particularly valuable in fields like healthcare data exchange where privacy and trust are critical.

​
What does KERI do?

The KERI protocol provides verifiable authorship of any message or data item via secure cryptographically verifiable attribution to a KERI Identifier as a primary root-of-trust. This root-of-trust is cryptographic, not administrative, because rather than relying on any trusted third-party administrative process, it is established and governed at the edge with cryptographically verifiable data structures. The root-of-trust enables end verifiability where every data item is attributable to its source by any recipient verifier, without reliance on any infrastructure not under the verifier’s ultimate control. Therefore, KERI has no security dependency on any other infrastructure. Rather than relying on security guarantees that may or may not be provided by the traditional internet infrastructure, it enables verification by anyone, anywhere, at any time.

​
Core Concepts

​
Autonomic Identifier (AID)

KERI’s Self-Certifying or Autonomic Identifiers (AIDs) are derived from cryptographic key material, binding each identifier to the holder’s private key. This self-certifying property removes the need for a centralized certificate authority to vouch for the validity of an identity. Instead, each AID “speaks for itself” by proving control of its corresponding private key.

​
Key Event Log (KEL)

Every AID in KERI is accompanied by a Key Event Log (KEL): a continuously growing, tamper-evident record of identity events. These events include the inception (creation) of an AID, any key rotations, and other relevant changes (like delegations). Because each new event references the cryptographic hash of the previous event, the KEL provides an immutable history that is verifiable by anyone.

​
Key State

Key state is the authoritative cryptographic state of an identifier at a given point in time. It represents the most recent key event in the KEL that defines the control and configuration of that identifier, along with associated data like sequence number, signing keys, witnesses, and any delegations.

​
Witness

To ensure high availability and security—even when direct exchange between controllers is not practical—KERI introduces witnesses. A controller of an AID selects and manages its own pool of witnesses, which can be hosted on any combination of third-party services or self-owned infrastructure. Each witness attests to the validity of a controller’s KEL events by issuing signed receipts. These receipts are exchanged with other witnesses and processed using an agreement algorithm called KAWA, which ensures consistent, fault-tolerant replication of the KEL across all witnesses and Guards against malicious attempts to alter or fork the log. By design, witnesses are under the exclusive control of the AID’s controller and can be changed at any time without impacting the trust model.

​
Watcher

Watchers serve a complementary role for those validating another party’s events. They continuously observe KELs via witnesses, (potentially for multiple AIDs) and apply a “first seen, always seen” policy. Once a watcher has received and recognized an event, any later conflicting version of the same event is considered invalid. This allows watchers to detect duplicity (e.g., if a compromised or dishonest controller tries to publish conflicting versions of its KEL). Unlike witnesses, watchers are not tied to a single AID. Instead, each validator decides how to run or source its watcher infrastructure (self-hosted, third-party, or both). Watchers can also exchange signed receipts of key events, using KAWA to improve their fault tolerance and availability. When they detect a provably duplicitous key state, they can act as Jurors by sharing that evidence with other watchers or validators. Others may serve as Judges, evaluating events based on confirmed duplicity evidence. By distributing these “first-seen” records widely and quickly, watchers ensure that original, valid key states are recognized globally while simultaneously detecting and mitigating attempts to rewrite or fork an AID’s event history.