KERI Fundamentals

KERI (Key Event Receipt Infrastructure) is the cryptographic protocol that powers DTF’s identity and verification system. This guide explains the core concepts you’ll encounter when working with the platform.

Why KERI?

Traditional identity systems depend on a central authority (like a certificate authority) that everyone must trust. If that authority is compromised, the entire system fails.

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

Core Concepts

AID (Autonomic Identifier)

An AID is a self-certifying identifier — it’s derived from its own public key, so it proves itself. No registration authority needed.

Every entity in DTF has an AID:

Tenant AID — Represents your organization
Enterprise AID — Represents a legal entity within your tenant
Officer AID — Represents an individual with signing authority
Service AID — Represents an automated system

KEL (Key Event Log)

The KEL is the append-only log of everything that happens to an AID. It records:

Inception — The AID is created with its initial key pair
Rotation — Keys are changed (old keys can no longer sign)
Interaction — A data anchoring event (seals)
Delegation — Authority is delegated to another AID

Each event 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 key pair (by publishing its hash). When you rotate, you reveal the new key and commit to the next one.

This means an attacker who compromises your current key still can’t take over your identity — they don’t know the pre-committed next key.

Witnesses

Witnesses are independent infrastructure nodes that store copies of KELs and provide receipts. They serve two purposes:

Availability — Your KEL is accessible even if your own infrastructure is down
Duplicity detection — Multiple witnesses make it hard to present different versions of a KEL to different verifiers

DTF currently operates in self-witnessed mode. External witness infrastructure is on the roadmap.

SAID (Self-Addressing Identifier)

A SAID is a content-addressable hash. The content includes a placeholder for the hash itself, which is then replaced with the actual computed hash. This creates a tamper-evident seal: if any byte of the content changes, the SAID changes.

Every ACDC credential, every trustable, and every event in DTF has a SAID.

ACDC (Authentic Chained Data Container)

An ACDC is a verifiable data container — the fundamental credential format in KERI. It includes:

Issuer — The AID that created it
Schema — What kind of data it contains
Attributes — The actual data
Edges — References to other ACDCs (creating chains)
Rules — Constraints on how the credential can be used

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

TEL (Transaction Event Log)

The TEL tracks the lifecycle of a credential — when it was issued, revoked, or reinstated. Like the KEL, it’s append-only and tamper-evident.

When you check if a credential is valid, you check its TEL to confirm it hasn’t been revoked.

OOBI (Out-of-Band Introduction)

An OOBI is the entry point for discovering an identity. It tells you where to find an AID’s KEL so you can verify it. OOBIs are shared out-of-band (via URL, QR code, etc.) and bootstrap the trust verification process.

CESR (Composable Event Streaming Representation)

CESR is KERI’s binary encoding format. It’s designed to be:

Self-framing — Each element includes its own length
Composable — Elements can be concatenated and parsed without delimiters
Round-trip safe — Converts cleanly between text and binary

DTF uses CESR for signatures, attachments, and credential encoding.

How It All Fits Together


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

2. Delegation
   Enterprise AID delegates to Officer AID (delegation event)
   → Creates verifiable authority chain

3. Credential Issuance
   Officer signs an ACDC using their AID
   → TEL records the issuance event
   → SAID uniquely identifies the credential

4. Verification
   Verifier receives the credential's SAID
   → Fetches KEL via OOBI → confirms key is valid
   → Walks delegation chain → confirms authority
   → Checks TEL → confirms not revoked
   → Result: cryptographically verified trust

KERI in DTF

DTF uses KERI through the Keria microservice, which manages:

Habery instances — One per tenant, managing all AIDs
Reger instances — Credential registries and TEL management
LMDB storage — Per-tenant key material storage

The Platform service communicates with Keria for all KERI operations — creating AIDs, issuing credentials, building delegation chains, and resolving OOBIs.