KERI Fundamentals

KERI (Key Event Receipt Infrastructure) is the cryptographic protocol behind Foundry’s identity and verification system. This guide explains the core concepts you will meet when working with the Platform.

Why KERI?

Traditional identity systems depend on a central authority, such as a certificate authority, that everyone must trust. If that authority is compromised, everything that relies on it is affected.

KERI removes this single point of trust. Instead of trusting an authority, you verify cryptographic evidence directly. Every identifier has a verifiable history, from its creation through every key change, that anyone can check independently.

Core Concepts

AID (Autonomic Identifier)

An AID is a self-certifying identifier. It is derived cryptographically from its initial key material, usually as the digest of its first (inception) event, so anyone can check that the identifier and its keys belong together. No registration authority is needed.

In Foundry you will meet these identifiers:

Enterprise AID: represents an enterprise registered in your tenant
User AID: a user’s own signing identifier. Custodial users receive one when they first sign in; edge users receive one when they connect their Foundry Wallet.
Officer AID: an officer signs with their own user AID. The enterprise records the officer’s authorization in its key event log.
Tenant issuer AID: the identifier your tenant uses to issue credentials

KEL (Key Event Log)

The KEL is the append-only log of events for an AID. It records:

Inception: the AID is created with its initial keys and a commitment to its next keys
Rotation: the current keys are replaced by the pre-committed next keys, and a new commitment is made
Interaction: the controller anchors data, such as the digest of a credential event, without changing keys
Delegated inception and rotation: events of a delegated AID, which take effect only when the delegating AID anchors them in its own KEL

Each event is signed with the controller’s current keys and includes the digest of the previous event, forming a hash chain. This makes the history tamper-evident: changing any past event breaks the chain.

Key Rotation

Keys can be compromised. KERI handles this through pre-rotation: when you create an AID, you also commit to your next keys by publishing a digest of them. When you rotate, you reveal those next keys and commit to a new set.

An attacker who obtains only your current signing keys can sign with them until you rotate, but cannot rotate the AID to keys of their own, because a valid rotation must reveal keys that match the earlier commitment. You regain control by rotating to your pre-committed keys.

Witnesses

Witnesses are servers that an AID’s controller designates in its key event log. Each witness keeps a copy of the KEL and signs a receipt for each event it accepts. Witnesses serve two purposes:

Availability: the KEL can be retrieved from the witnesses even when the controller is offline.
Duplicity detection: a witness keeps the first version of an event it sees and receipts only that version, so it is hard to get two conflicting versions of a KEL fully receipted.

Witnesses do not vote or decide which version of a log is correct; they only issue receipts. The controller sets a receipt threshold, and a verifier accepts an event once it has enough receipts.

In Foundry, witnesses serve the Platform instance as a whole, not a single tenant. Administrators can see their status on the Network page in the sidebar (page title Network Status). See Duplicity Detection for how witnesses and watchers make conflicting logs visible.

SAID (Self-Addressing Identifier)

A SAID is a digest of some content that is embedded in that same content. To compute it, the SAID field is first filled with placeholder characters of the right length, the digest is computed over the whole content, and the placeholder is replaced with the result. If any byte of the content changes, the SAID no longer matches.

Every ACDC credential, every Trustable and every key event has a SAID.

ACDC (Authentic Chained Data Container)

An ACDC is a verifiable data container and the credential format used with KERI. It includes:

Issuer: the AID that issued it
Schema: what kind of data it contains
Attributes: the data itself
Edges: references to other ACDCs, which create chains of credentials
Rules: terms that apply to the credential and its use

ACDCs are chained through their edges, creating a verifiable graph of credentials.

TEL (Transaction Event Log)

The TEL records the status of credentials issued from a credential registry: when each credential was issued and, if it has been revoked, when it was revoked. TEL events are anchored in the issuer’s KEL, so they share its tamper evidence.

To check whether a credential is still valid, you check its TEL to confirm it has not been revoked.

OOBI (Out-of-Band Introduction)

An OOBI is the entry point for discovering an identifier. It tells you where to find an AID’s KEL so that you can verify it. OOBIs are shared out of band, for example as a URL or a QR code, and start the verification process.

CESR (Composable Event Streaming Representation)

CESR is KERI’s encoding for events, signatures and attachments. It is a dual text and binary encoding:

Text and binary domains: every element has a text form, made of URL-safe Base64 characters, and a compact binary form
Self-framing: each element begins with a code that states its type and size, so a parser knows where it ends
Composable: a whole stream of elements can be converted between its text and binary forms and back without loss

KERI events, signatures and ACDC credentials are commonly exchanged as CESR streams.

How It All Fits Together


1. Identity creation
   An AID is created (inception event in its KEL)
   → Witnesses store the event and issue receipts

2. Enterprise authorization
   The enterprise records an officer's authorization in its KEL
   → A verifiable link from the enterprise to the officer's own AID

3. Credential issuance
   An issuer creates an ACDC with its AID
   → The issuance is recorded in a TEL, anchored in the issuer's KEL
   → The SAID uniquely identifies the credential

4. Verification
   A verifier starts from the credential and its SAID
   → Finds the issuer's KEL (for example through an OOBI) and its current keys
   → Checks the signature against those keys
   → Checks the TEL to confirm the credential is not revoked
   → Checks the signer's authority where one is claimed

KERI in Digital Trust Foundry

Foundry manages KERI identifiers for custodial users, for enterprises and for each tenant’s issuer identifier: it creates them, maintains their key event logs and signs with them when they act.

Edge users keep their keys in their Foundry Wallet, on their own device. Digital Trust Foundry does not hold those keys; the wallet signs on the device.

Foundry publishes key event logs, transaction event logs and OOBIs through standard endpoints, so other KERI-based systems can verify Foundry identifiers and credentials.