notes: research/papers/papers-keri-request-authentication-mechanism-kram
This data as json
| path | title | type | status | classification | words | body |
|---|---|---|---|---|---|---|
| research/papers/papers-keri-request-authentication-mechanism-kram | Keri Request Authentication Mechanism (KRAM) | summary | v0.1 — 2026-10-15: drafted by Claude from the markdown file in the Papers repository; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only | partner | 556 | # Keri Request Authentication Mechanism (KRAM) **Abstract.** A working design document (version 0.7.6) for KRAM, a non-interactive method of authenticating requests signed with the current key state of a Key Event Receipt Infrastructure (KERI) identifier, protecting against replay through datetime stamps and timeliness caches. It describes simple KRAM, as implemented in keripy, and a redesigned full KRAM with multi-signature support, cache types, databases and processing logic. For implementers of keripy and related KERI services. ## Summary The document opens with the full KRAM redesign. It separates authentication types by the cardinality of the sender's current key list (single-key or multi-key) and by whether a message is authenticated by attached signatures or by a reference to an anchoring seal in the sender's key event log (KEL). Exchange (`exn`) messages that belong to a transaction use a two-level cache: an inner window per message identifier and an outer window per exchange identifier. Caches are keyed by Self-Addressing Identifiers (SAIDs) for fast lookup, and separate accept and prune lags allow window changes without opening a gap for replay or first-play attacks. The redesign assumes KERI version 2. Later sections specify the configuration, the timeliness cache representation, the databases (cache-type, message cache, transactioned message cache and partially signed multi-key stores) and processing and pruning logic. The background explains why, given cryptographically strong random numbers, asymmetric signatures tied to key state, and ubiquitous network time, a non-interactive timestamp approach suits asynchronous public networks better than challenge-response. The author reports first solving the problem in a proof of concept within the open-source Indigo-BluePea project. A comparison with FIDO2/WebAuthn notes that it lacks built-in verifiable key rotation. Replay protection rests on timeliness and uniqueness. Simple KRAM drops any request whose timestamp falls outside a short window around the recipient's clock; this needs no cache and is what keripy implements, but it is problematic for multi-signature identifiers that need time to collect signatures. Full KRAM keeps monotonic timeliness caches per source identifier or finer (message type, route, exchange ID, message ID), allows long windows bounded only by storage, and persists the latest seen time to resist retrograde clock attacks. Further sections give worked examples, discuss time resolution, throughput and out-of-order delivery, two-level simple KRAM for multi-signature, and an obsolete section kept for reference. ## Key terms KRAM, non-interactive authentication, replay attack, first-play attack, timeliness cache, simple KRAM, full KRAM, accept lag, prune lag, exchange ID, anchoring seal reference, retrograde attack ## Claims and their evidence - Simple KRAM is what keripy currently implements. [informative] - All practical replay protection mechanisms include both timeliness and uniqueness properties. [informative] - Except for a few corner cases, interactive authentication has little advantage over KRAM's non-interactive approach. [informative] - FIDO2/WebAuthn has no built-in automated verifiable key rotation. [informative] - The author first solved this problem in the Indigo-BluePea proof of concept. [presenter-reported] ## Related KERI specification, KERI Architectures for Group Issuance (KAGI), ACDC specification (IPEX section), keripy. ## Provenance Drafted by Claude on 2026-10-15 from the markdown file `whitepapers/kram.md` (v0.7.6; about 22,000 words): the opening redesign sections, background, replay protection, simple and full KRAM read in full; databases, processing logic, examples and the obsolete section by headings. The document names no author line; the background is written in the first person, and the file is attributed to Samuel M. Smith by the repository. Not yet read by Mark. |
Links from other tables
- 1 row from summary in resources