notes: research/papers/kerione-gleif-vlei-architecture

This data as json

path title type status classification words body
research/papers/kerione-gleif-vlei-architecture GLEIF vLEI Architecture summary v0.1 — 2026-10-14: drafted by Claude from the slides (PDF); unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only partner 556 # GLEIF vLEI Architecture **Abstract.** A slide deck by Samuel M. Smith (version 1.2, 5 January 2021), linked on keri.one as "GLEIF vLEI KERI Implementation", giving an early overview of the cryptographic infrastructure the Global Legal Entity Identifier Foundation (GLEIF) chose for the verifiable Legal Entity Identifier (vLEI). It explains why GLEIF chose Key Event Receipt Infrastructure (KERI) based identifiers over shared-ledger registries, how key event logs control credential registries, and how delegation from a single GLEIF root identifier structures the ecosystem. For readers who want the architectural reasoning behind the vLEI as it stood in early 2021. ## Summary The deck opens by defining a vLEI as a digitally signed document making assertions about a legal entity, such as its Legal Entity Identifier (LEI) code, official name and registered address. It separates two senses of "verifiable": the veracity of the assertions, assured by GLEIF and its issuing organizations through their processes and policy, and the authenticity of the document, assured cryptographically. At that point the vLEI format was described as based on the W3C verifiable credential (VC) and decentralized identifier (DID) standards. It then presents the issuer, holder and verifier model, and adds a verifiable data registry (VDR) through which verifiers establish control authority over a DID. Most DID methods use a shared ledger as their VDR; the deck states that GLEIF chose KERI-based DID methods instead, because they are ledger independent and do not force all participants onto one ledger. In KERI, each identifier has its own key event log (KEL), a hash-chained record of inception, rotation and interaction events that proves the current authoritative keys. Such identifiers are called autonomic identifiers (AIDs). A KEL can control a transaction event log (TEL) through anchoring seals; for the vLEI, TELs hold issuance and revocation state, and each credential can have its own separable TEL keyed by its content digest. Later slides cover identifier system security, KERI's cryptographic root of trust, the modular infrastructure stack (controller, witness, watcher, delegate, oracle and validator services) and delegation. The root of trust is one globally published GLEIF identifier (the GID), which delegates to the identifiers of vLEI issuers. Each delegation level forms a nested trust domain, and delegations can extend to official organizational roles and individual employees. ## Key terms vLEI, verifiable data registry (VDR), key event log (KEL), transaction event log (TEL), autonomic identifier (AID), seal, delegation, GLEIF identifier (GID), decentralized key management infrastructure (DKMI), witness ## Claims and their evidence - GLEIF and its issuing organizations assure the veracity of vLEI assertions through their own processes and policy. [presenter-reported] - GLEIF chose KERI-based DID methods over shared-ledger VDRs for ledger independence. [presenter-reported] - A KEL provides cryptographically verifiable proof of an identifier's current authoritative keys. [informative] - A KEL can control a TEL so that any validator can verify registry state. [informative] - Nested delegation from the GID increases security while allowing faster issuance in lower layers. [informative] ## Related The KERI white paper (Key Event Receipt Infrastructure); the vLEI Ecosystem Governance Framework; the ACDC (Authentic Chained Data Containers) specification, which later replaced the W3C VC format described here. ## Provenance Drafted by Claude on 2026-10-14 from the slide PDF (18 pages), text extracted in full; diagrams not seen. The line on ACDC under Related is Claude's context, not from the deck. Not yet read by Mark.

Links from other tables