notes: research/papers/papers-keri-architectures-for-group-issuance-kagi

This data as json

path title type status classification words body
research/papers/papers-keri-architectures-for-group-issuance-kagi KERI Architectures for Group Issuance (KAGI) 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 608 # KERI Architectures for Group Issuance (KAGI) **Abstract.** A design discussion of the trade-offs among architectures for issuing Authentic Chained Data Containers (ACDCs) from groups of controllers using the Key Event Receipt Infrastructure (KERI) stack, centered on group multi-signature identifiers, the KERI Request Authentication Method (KRAM) and the Issuance and Presentation Exchange (IPEX) protocol. It recommends implementing full KRAM and describes alternatives such as agent-delegated negotiation, anchoring instead of signing, and joint issuance. For implementers of keripy and related libraries. ## Summary The paper defines the KERI stack as the open-source libraries built on or around the keripy reference implementation (including CESR, ACDC, KRAM, SAID, IPEX, OOBI, KERIA, Signify and hio) and a group as cooperating controllers who sign or seal issuances with their identifiers' key state. The motivation is the difficulty of using simple KRAM with exchange (`exn`) messages when negotiating ACDC issuance from group multi-signature identifiers. Background sections explain uneven maturity in the stack by limited direct contributions, noting that the Global Legal Entity Identifier Foundation (GLEIF) built the bare-bones features the verifiable Legal Entity Identifier (vLEI) needed. They then describe single-controller multi-signature Autonomic Identifiers (AIDs), group multi-signature AIDs whose members each contribute a key from their own single-signature AID, the keripy coordination protocol that collects signatures asynchronously in escrow, and least disclosure of group membership, which may be published through an ACDC listing member AIDs. Delegation, witnesses and watchers add further thresholds. KRAM is described in simple and full forms, and Key Event Log (KEL) sealed (anchored) issuance is described as surviving later key-state changes, at the cost of larger KELs. A caveat notes that the partially signed escrow timeout is hours, not days. The IPEX section shows an example exchange message and the routes apply, offer, agree, grant, admit and spurn, and identifies two problems with simple KRAM: signed-only negotiation steps are not verifiable after key rotation, and group signatures cannot be collected inside a short KRAM window. Current code uses a two-level approach: a singly signed wrapper and a multiply signed embedded payload. The paper calls these stop-gaps and recommends giving full KRAM high priority. Other options, prompted by a concern raised by Daniel Hardman about signing burden, are agent-delegated negotiation, anchoring payloads in the group KEL, and joint issuance, in which each member issues a single-signature copy and validators check a threshold of copies. Closing sections cover implementation, time resolution, throughput and out-of-order messages. ## Key terms KERI stack, group multi-sig AID, simple KRAM, full KRAM, timeliness cache, KEL sealed issuance, partially signed escrow, two-level authentication, IPEX, joint issuance ## Claims and their evidence - Uneven maturity of KERI stack components stems from limited direct contributions, with GLEIF's vLEI work shaping which features were built. [informative] - The KEL of a group multi-sig AID does not disclose its member AIDs. [informative] - Simple KRAM makes collecting group multi-signatures on IPEX exchange messages within its time window impractical. [informative] - Full KRAM would work with existing code with at most minor modifications. [informative] - Joint issuance needs no change to the ACDC structure in the specification. [informative] ## Related Keri Request Authentication Mechanism (KRAM), ACDC specification and its IPEX section (Trust over IP), KERI specification, Human Agreement for Multisig Issuance (keripy issue 911), Reliable End-to-End Application Layer Transactions (keripy discussion 909). ## Provenance Drafted by Claude on 2026-10-15 from the markdown file `whitepapers/KERIArchGroupIssuance.md`: the introduction, background, IPEX, problems and solutions sections in full, and the implementation and time sections in outline. The document gives no author line or date; it is attributed to Samuel M. Smith by the repository, and dated by its commits (January to February 2025). Not yet read by Mark.

Links from other tables