GLEIF vLEI Architecture
VLEI = verifiable Legal Entity Identifier AVLEI is a digitally signed digital document that makes assertions about a Legal Entity. These assertions include the LEI code, official name, and registered address. Two senses of verifiable in VLEL. = verifiable veracity of the assertion in the vLEI « verifiable authenticity of the assertions in the vLEI GLEIF and it issuing organizations verify the veracity (accuracy, validity, quality), of the assertions in vLEls they issue. Their credibility, operational integrity, process, policy, and procedures provide assurance of veracity. The digital document format for the vLE! is based on the W3C Verifiable Credential (vC) and Decentralized Identifier (DID) standards. These standards provides interoperable mechanisms for verifying the authenticity of the vLEI. ‘The verifiable in VC refers only to the verifiable authenticity of the document via the attached digital signatures. Think of a VC as an authenticatible data container for assertions. The cryptographic security of the identity systems used to issue the associated DIDs provide assurance of authenticity. AVLEI issued by a GLEIF authorized issuing organization contains assertions of high data quality about the targeted legal entity. AVLEI expressed as a VC provides those assertions in a way that is securely authenticatible to the identified issuing organization. The remainder of these sldes provide a brief overview of the cryptographic infrastructure used to provide secure authenticity.
Tripartite Authentic Data (VC) Model
Issuer: Source of the VC. Creates (issues) and signs VC Holder: Usually the target of the VC. The holder is the “issuee” that receives the VC and holds it for its own use. Verifier: Verifies the signatures on the VC and authenticates the holder at the time of presentation The issuer and target each have a DID (decentralized identifier). ‘The DIDs are used to look-up the public key(s) needed to verify signatures.
Issuer-Holder-Verifier Model
Issuance Presentation Issuer Holder Verifier
Tripartite Authentic Data (VC) Model with VDR Verifiable Data Registry (VDR) enables decentralized but interoperable discovery and verification of authoritative key pairs for DIDs in order to verify the signatures on VCs. A VDR may also provide other information such as data schema or revocation state ofave. Each controller of a DID registers that DID on a VDR so that a verifier can determine the authoritative key pairs for any signatures. We callthis determination, establishment of control authority over a DID. Issuer-Holder-Verifier Model with Verification at Verifiable Data Registry Issuance Presentation Issuer | Holder Verifier Registration Registration Verifiable Verification Data Registry
KERI VDRs vs. Shared Ledger VDRs Most DID methods use a shared ldiger (commony referred to a5 blockchain) for their VOR. Typicaly, i oder o interoperate al participants must use the same shared ledger or support mulipl diferen DID methods, There are currently over 70 DID methads. Instead GLEIF has chosen to use KERI based DID methods. KERI stands for Key Event Recelpt Infrastructure. KERI based VDRs are ledger independent, ..ot locked to a given ledger. his provides a path for greater nteroperabiity withotet forcing participants i the VLE! ecosystem to use the same shared ledger. AKERIVDRis clled a key event log (KEL). It s a cryptographically verfable hash chained data structure. Each KERI based identifie has its own dedicated KEL The purpose of the KEL s to provide proof o the establshment o control authorty over an dentife. Thisprovides cryptogaphicaly verfiable proof ofthe current set of authortative keys for the identifie, KERI identifers are long cryptographic pseudo random strings o characters, They are sef- certfying and seffmanaging. AKERI dentier i abstractly called an Autonormic Identifer (AID) because It s selfcertfying and self managing. A KERI DID i one concrete implementation of a KERI AID. The same KERIprefix may control multple differen DIDs as ong as they share the same prefix. Ful Sequncs S St did:keri:prefix(:options] [/path] [?query] [#fragment] gt Evnt. Roeon v . . o did:keri:ENGFEHS_cfDg8rilz-GDYDaCKV6c10aTZXXVXSHPRY nsrten vt Roeon v Raton vt nerin et [ i— Inerin et i it
KERI Identifier KEL VDR Controls Verifiable Credential Registry TEL VDR A KERI KEL for a given identifier provides proof of authoritative key state at each event. The events are ordered, This ordering may be used to order transactions on some other VDR such s a Verifiable Credential Registry by attaching anchoring seals to the KEL events. The set of transactions that determine registry state form a log called a Transaction Event Log (TEL). Transactions are signed with the authoritative keys determined by the key state in the KEL with the transaction seal. The transactions likewise contain a reference seal back to the ke event authorizing the transaction. This setup enables a KEL to control a TEL for any purpose. Inthe case of the VLEI the TEL controls a vLE! issuance and revocation registry. The TEL provides a cryptographic proof of registry state by reference to the corresponding controlling KEL. Any validator may therefore cryptographically verify the authoritative state of the registry. ot e ot EL Sl O s Torsociors iy TEL PR it Tanscton et Reg o] won s ™G s T Ken s [ Tewden [0 S | Opemin | Sme S T o1 e | Opewen | Sme t Kn s (w2 S| O | S 3 Ken S | Tevsior 3 Sed | Opemin | S St | T 4 S| Opoon | S | S | Tion (5 Sl | Opewien | St
Registry with Separable VC Issuance-Revocation TELs Each VC may be uniquely identified with a content digest. Each VC also has a uniquely identified issuer using a KERI AID. This combination enables a separable registry of VC issuance-revocation state. ‘The state may employ a cryptographic accumulator for enhanced privacy Ionter Ky Lo e A Contort s o rcinti Ragiy Koy Tansacon TsrasionEvtLoge N sae sals eriable Credental - o e TensadionEvls SoparshloVC Tassaton Evrl Log T Sels O VOSul T ke | s [ et 0] sea | e | st sob || | Tersoaim {1 s | R | Rener 2| top Sl gl ‘Separable VC Transacton Event Log T T e T Sl Opestms Ve Sul Sea || Tansaton |- 7 S | Rewk | Redes Seol || Tansatin ‘Seprs VC Tasaton vt Log T Sl Operins voSuls o s | e |t 1 s | Raoe Ree
Identifier System Security Authentic transmission of data may be verified using an identity system security overlay. “This overlay maps cryptographic key-pairs to identifiers. ‘When those identifiers are self-certifying they are derived via cryptographic one-way functions from the key pairs. “This provides a self-certifying identifier with a cryptographic root-of-trust. Akey event log (KEL) provide support for secure key rotation without changing the identifier. Message authenticity is provided by verifying signatures to the authoritative keys pairs for the identifier included in the message. \ key-pair ‘<—> identity system mapping 4—»‘ identifier Authentic Message Verifiable Payload b identifier m signature e
Trust Basis for Identifier Issuance / \\ - s ~— ‘ ( / who's infrastructure ? [ controller | ) \ £ pN e > source-ofruth / - '\ ? L - N - = verifies pincingdentity o — N \ system \ o ,/ seaurity \ validator /* X overlay PN N J \ / \ | key-pair j«——bnong——+{ _identiier | N4 NS
KERI‘s Autonomic Trust Basis Cryptographic Root-of-Trust /h‘\/manages — /7 \gwn Infrastructure 1 controller . 7\ AN < < [poves > sourceobruth | generates / 7 ‘\ ) keyeventlog |~/ Y / v verifies stong | stong 7 \ binding derives binding \ & [wrr / e \ [ validator | /\ ; /\ —— | key-pair <':;":‘"ngg —| identifier | \ / . V
KERI Infrastructure Stack Support for KERI is provided via open source software running on computing devices. These constitute the KERI infrastructure stack. KERI Delegation Stacks For increased security and scalability, KERI supports delegated identifiers. Each participant in a delegation may run their own KERI stack. o Detailed stack & Infrastructure: e Stack Contimaton ) = simple stack Vetator o= é infrasructure Koy | Pomigaton ‘@,« ,k, ] Stack Event [ Storage Sgning | Key Events iy Y Creation Dot Dervaton = Stoage e e " reation e KERI M@ KR
Technical details about the vLEI infrastructure
KERI employs a modular architecture with modular
components that each provide services. Participants
may configure their stacks to provide some of all of
the services or share services provided by others.
The component services include Controller, Witness, P~
Watcher, Delegate, Oracle, Validator. 3,
‘The root-of-trust for the GLEIF ecosystem is. _ I —3
provided by a single globally published AID called o S A
the GLEIF AID or GID for short. It is a KERI DID. 2qD | £8 an on - &p 0 In [ = 2 =
This GID is the issuer of delegations to other KERI T
AID DIDs. These delegated identifiers may be the _—— . —
issuers of vLEls. = == v ap . g8 - OO finsan] & Janai) |—1] T8 =
simplified GLEIF Ecosystem
GLEIF Controller and Witness Network = = ® ¥ ] [} ] ] [} e o ot | | oomecomer | oot | | b orir | | o6k e & &b &k &b (&3 4B | e | o on on on on on 28 88 93 [pr— [repr— l l l l EETI e @ 9 ‘A Components of the GLEIF Ecosystem under GLEIF Control
GLEIF + vLEI Issuer Networks e (= EE B m= EE & & |4 é—i% @ & Rl s S 8888 8 8 - T * & e &R 2 & & & & B GLEIF Ecosystem with both GLEIF and vLEI issuer controlled components
Decentralized Key Management Infrastructure (DKMI) KERV's cryptographic trust basis depends primarily on cryptographic key management infrastructure. Y This dependence simplifies security concerns to key AD management concerns. Key Management Infrastructure Key-pair Generation & Storage Infrastructure ° 3 H Bl g z g 3 @ Key Event Generation & Signing Infrastructure
GLEIF Controller Network (DKMI) KERI supports delegation that enables horizontally scaled key management. P GLEIF's key management for . VLEI Issuer identifiers L2 leverages this capability. Mook oo H? 1 8 - [ 41:W'——‘7 It e | e | e (N e ]| |y | | [ By [ [ i e i i i A i §°1 it o e | || | | ool | [ ||| | ool | ||
GLEIF Ecosystem vLEI Issuance Level 1 Tust Domln | ) Lo 25 b T Doran e — e e ok Vet tan Ee S [rry Py o oo oo ey [ Voot w [ w o ] . w — Lyt T By (S [0 ‘ e | | — = Each level of delegation forms a nested trust domain that is protected by the level above. This increases ultimate security while enabling higher performance event issuance in lower layers. ‘GLEIF’s GID provides the root-of-trust for the whole ecosystem. This enables secure decentralized interoperabilty. Each trust domain may make delegations of both identifiers and verifiable credentials to a subordinate trust domain. These delegations provide revocable authorizations.
GLEIF Ecosystem VLEI Issuance for Official Organizational Roles and Employees Delegations may be granular and include authorizations of individual employees. This = [ provides specific scalable but non-repudiable = [~ accountability of all participants in the eco- | || = System. g H = ; =g = ‘ -l