notes: research/papers/kerione-keridemlia-a-discovery-mechanism-for-keri

This data as json

path title type status classification words body
research/papers/kerione-keridemlia-a-discovery-mechanism-for-keri Keridemlia: A Discovery Mechanism for KERI summary v0.1 — 2026-10-14: drafted by Claude from the PDF (page images); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only partner 610 # Keridemlia: A Discovery Mechanism for KERI **Abstract.** A paper by Ryan W. West and Samuel M. Smith describing Keridemlia, a prototype discovery service for Key Event Receipt Infrastructure (KERI) that maps autonomic identifiers (AIDs) to their witnesses' identifiers and witness identifiers to IP addresses, using the Kademlia distributed hash table (DHT). It covers the design, the data structures considered, a four-endpoint HTTP API, verification of published data, and planned optimizations. For developers interested in how KERI identifiers could be located when KERI is used in indirect mode. ## Summary The abstract presents KERI as a decentralized, end-to-end verifiable identity system in which each identifier is bound to a separately stored key event log (KEL), held by always-available witness servers. To verify who controls an identifier, a user must retrieve its KEL, which requires knowing a witness's IP address. Keridemlia is described as a service similar to the Domain Name System (DNS) that stores this mapping and accepts only signed, verified data. The background section recounts the Internet's insecure origins and the later addition of HTTPS with certificate authorities and of DNS Security Extensions (DNSSEC), and contrasts these with KERI, whose self-certifying, self-managing AIDs rely on cryptographic proof rather than certificate authorities. KERI can run in direct mode, where controllers exchange IP addresses, or indirect mode through witnesses, which needs a discovery mechanism. Keridemlia acts like a DNS server that can map names to other names (like a CNAME record) and names to addresses (like an A record), and the authors suggest it may serve as an end-verifiable replacement for DNS. The design wraps a Python Kademlia implementation in an API, chosen after comparing ways to build distributed systems; the DHT stores controller AIDs mapped to their key event state (KES), which lists current witnesses, and witness AIDs mapped to IP addresses. The paper explains KELs, inception, rotation with a pre-rotated "next" key commitment, and interaction events. Verification follows KERI's end-verifiability: transferable AIDs are checked against the public key in their key state, non-transferable witness AIDs against the key embedded in the identifier, and witnesses must sign their IP mappings. Stored signatures are returned on every request, which the authors say prevents cache poisoning and limits a malicious node to dropping data or denying service. The prototype implements the first two design steps; full verification before publishing was still being worked on. Optimizations include automatic republishing, a single combined lookup, local caching and support for Legitimized Human Meaningful Identifiers (LIDs). Related work compares the Handshake naming network. ## Key terms KERI, autonomic identifier (AID), key event log (KEL), key event state (KES), witness, indirect mode, distributed hash table (DHT), Kademlia, end-verifiability, pre-rotation ## Claims and their evidence - KERI used in indirect mode needs a discovery mechanism that maps an AID to a witness IP address. [informative] - Keridemlia accepts only signed, verified data, which prevents cache poisoning on an honest server. [informative] - The prototype implements the first two design steps and does not yet fully verify all data before publishing. [presenter-reported] - Keridemlia may serve as a secure, decentralized replacement for DNS. [unverified] ## Related The KERI white paper (Key Event Receipt Infrastructure); the KERI specification's treatment of witnesses and discovery; later out-of-band introductions (OOBI), which took up discovery in KERI. ## Provenance Drafted by Claude on 2026-10-14 from the PDF (10 pages). The PDF's text layer is broken, so pages 1, 3, 6, 8 and 9 were read as rendered images and the rest only by section. The paper carries no date; the PDF was created in February 2021. The line on OOBI under Related is Claude's context, not from the paper. Not yet read by Mark.

Links from other tables