KERI / ACDC Infrastructure

Identity That
Holds Up In Court

The selfdriven.legal identity layer uses KERI self-certifying identifiers and ACDC verifiable credentials to create a cryptographic trust infrastructure for every practitioner, client, agent, and legal instrument.

Root Identity Protocol
KERI — Key Event Receipt Infrastructure
Self-certifying · No central authority · Append-only KEL
Credential Standard
ACDC — Authentic Chained Data Containers
GLEIF-endorsed · Chained · Instantly revocable
Authentication
FIDO2 Passkey + KERI AID Binding
No passwords · No SMS OTP · Biometric-bound

Why KERI for Legal Practice

Legal practice has always been fundamentally about trust — establishing who said what, when, with what authority, and whether the record has been tampered with. Paper, wet signatures, notarisation, and court seals are all trust infrastructure. They are just slow, fragile, and expensive infrastructure.

KERI (Key Event Receipt Infrastructure) provides the same trust guarantees cryptographically — with no central authority, no dependency on a PKI hierarchy, and no possibility of silent alteration. Every identifier is self-certifying. Every event is witnessed. Every rotation is pre-committed. The key event log is mathematically tamper-evident.

The legal relevance: KERI produces an append-only record of identity events that can be independently verified by any party — including courts, regulators, and counterparties — without reference to any central registry or certificate authority. It is chain of custody by architecture.

Identity Layers

The identity architecture operates across six discrete layers — from cryptographic key pairs at the foundation to organisational trust at the surface. Each layer depends on the one below it.

L1
KEYS

Cryptographic Key Pairs

Ed25519 or ECDSA key pairs. Current keys sign events. Next keys are pre-committed via hash — enabling instant rotation without key exposure. pre-rotation is KERI's core security innovation.

L2
AID

Autonomous Identifier (AID)

A self-certifying identifier derived from the initial key pair. Stable across key rotations. Not registered anywhere — it is mathematically derived from the keys themselves. icp event creates the AID.

L3
KEL

Key Event Log (KEL)

An append-only log of all key events — inception, rotation, interaction, delegation. Each event references the prior event via digest. Witnessed by 3 distributed nodes; threshold 2-of-3 for confirmation.

L4
ACDC

Verifiable Credentials (ACDC)

Claims anchored to KERI — practitioner qualifications, engagement authorities, agent scopes. Each credential has a SAID (Self-Addressing Identifier) and is chained to the issuer's KEL. ixn event seals issuance.

L5
AUTH

Passkey Authentication

FIDO2 passkeys (biometric/device-bound) linked to the practitioner's KERI AID via interaction event. Every consequential action requires a WebAuthn assertion binding the action data to the AID.

L6
vLEI

vLEI — Organisational Trust

GLEIF-issued Verifiable Legal Entity Identifier anchoring the practice entity to the global trust hierarchy. QVI-issued. Recognised by regulators, financial institutions, and counterparties internationally.

Parties & AIDs

Every participant in a selfdriven.legal matter holds a KERI AID. Identity is not assigned by the practice — it is self-certified by each party. The practice issues ACDC credentials that attest to the party's role; it does not control their identifier.

Client

Authenticates with passkey, creates or recovers their AID. Receives an ACDC engagement credential scoping the matter. Maintains full control of their own identifier.

type: icp · role: client

Human Conductor

Senior practitioner AID. Holds ACDC role credential. Signs all consequential outputs via WebAuthn assertion. Issues delegation credentials to AI agents within their Area of Focus.

type: icp · role: conductor

AI Agent

Delegated AID created via KERI dip event. Authority scoped by conductor delegation — matter-specific, action-specific, time-limited. Cannot exceed the granted scope.

type: dip · delegated-from: conductor

Practice Entity

The selfdriven.legal entity AID. Holds a GLEIF vLEI. Issues practitioner role credentials. Root of trust for all internal delegations. KEL witnessed by 3 nodes.

type: icp · vLEI: GLEIF-anchored

Legal Instrument

Each document (contract, filing, opinion) receives a SAID derived from its content. Sealed in the conductor's KEL at signing. Content integrity is mathematically verifiable.

type: ixn · said: Ef9Kq…

Counterparty

External parties are invited to present or receive KERI-anchored credentials. Counterparty signatures can be verified without any shared infrastructure or central registry.

type: icp · external · self-certifying

Key Event Log

The Key Event Log (KEL) is the canonical record of identity events for every AID in the practice. It is append-only, witnessed, and content-addressed — making it a tamper-evident audit trail that survives any dispute without reference to a trusted third party.

Event Types in Legal Practice

// 1. Practitioner AID inception — creates identity, commits next keys type: icp aid: EKE4g_0hDGBOqDLKzNBT3kFOPxoP7wXkqt keys: [DqI2cOZ06RwGmwCgaSd…] next-keys: [Ef9Kq4NUbuwRpJf…] witnesses: [node-1, node-2, node-3] threshold: 2 // 2. Engagement credential issuance — seals ACDC into KEL type: ixn sn: 1 said: Ef9KqNat5… // ACDC engagement credential // 3. Agent delegation — creates scoped AI agent AID type: dip delegator: EKE4g_0hDGBOqDLKzNBT3kFOPxoP7wXkqt scope: ["matter:draft","matter:research"] // 4. Document signing — seals instrument content hash into KEL type: ixn sn: 4 said: Ek9Rp2Xq… // SHA-256 of signed document // 5. Key rotation — replaces current keys, commits next type: rot sn: 5 keys: [Ef9Kq4NUbuwRpJf…] // pre-committed keys now active

Authentication Flow

All practitioners and clients authenticate using FIDO2 passkeys — biometric or device-bound credentials that are phishing-resistant by design. The passkey is linked to the user's KERI AID via an interaction event, creating a cryptographically verifiable binding between biometric authentication and legal identity.

1

Passkey Registration

User creates a FIDO2 passkey on their device (biometric or PIN). The public key is submitted to the practice, which seals it into the user's KERI KEL via an ixn event — binding device identity to KERI identity.

2

Authentication Challenge

On each session, the server issues a challenge. The user's device generates a WebAuthn assertion — a cryptographic signature over the challenge using the passkey private key. The private key never leaves the device.

3

AID Verification

The server verifies the WebAuthn assertion against the registered public key, then resolves the associated KERI AID and confirms the KEL is current — checking witness receipts and event sequence numbers.

4

Consequential Action Signing

Filing a document, delegating an agent, or signing an instrument requires a fresh WebAuthn assertion binding the specific action data (not just a session cookie) to the user's AID — creating a matter-specific KERI interaction event.

vLEI & Organisational Identity

The selfdriven.legal practice entity holds a Verifiable Legal Entity Identifier (vLEI) — a GLEIF-issued ACDC credential that anchors the organisation to the global legal entity trust hierarchy. The vLEI links the practice's KERI AID to its legal registration, jurisdiction, and regulatory status.

Practitioners within the practice receive vLEI role credentials — ACDC credentials chained to the entity vLEI that attest to their role (Conductor, Legal Engineer, AI Compliance Officer). These credentials are independently verifiable by courts, regulators, and counterparties without any query to the practice itself.

Why this matters in court: A document signed by a conductor whose role credential chains verifiably to the practice entity's GLEIF vLEI has a complete, cryptographically auditable chain of authority — from the biometric action that created the signature, through the practitioner's role, through the entity, to the global legal trust infrastructure.

See the Credential Schemas

Explore the ACDC schemas governing practitioner roles, engagement authorities, and agent delegation.

Credential Schemas → Agent Registry →