Petteri Stenius In this article, we explore the vLEI (verifiable Legal Entity Identifier) and KERI (Key Event Receipt Infrastructure). KERI is the technology that vLEI is built on.
What is vLEI?
vLEI is a new form of digitized organizational identity representing a secure digital form of a conventional LEI. To understand these concepts first, we have published articles introducing both LEI and vLEI.
vLEI is also an implementation of Verifiable Credentials, read our introduction on the concept of Verifiable Credentials. In short, “verifiable” means each vLEI credential has cryptographic proof that enables a recipient or Verifier to cryptographically verify its integrity and authenticity.
What is KERI?
KERI is a modern Distributed Key Management System (DKMS) and is the protocol on which vLEI is built.
In this section, we’ll look at how vLEI builds on the KERI architecture and what the most important KERI features are for vLEI.
KERI Architecture
This diagram represents a typical KERI architecture for vLEI. See below for a description of each term included in the diagram.
Signify Client
The end user or controller uses a Signify Client instance to perform KERI operations. Only the Signify Client has access to the private keys of the controller. It implements a “Signing at the edge” concept where the private keys are never exposed outside the context of the Signify Client. The Signify Client adds controller signatures to key event log entries.
Signify Client is not an end user application itself. Instead, it is a library that is embedded as a component in other applications, such as mobile wallets, web applications etc.
KERI Agent
This is the backend of a Signify Client. The KERI Agent manages the key event logs of each Signify Client and publishes signed key event logs to witnesses.
Witness Network
A KERI Witness receives key event logs with controller signatures from KERI Agents. For authenticity, the witness adds witness signatures to the key events, then makes the key event logs available to Verifiers.
Verifier
A controller uses Signify Client to create digital signatures and to send presentations of verifiable credentials to Verifiers. The Verifier will access key event logs provided by KERI Witnesses when verifying digital signatures and credential presentations. Comparing key event logs from multiple witnesses lets the Verifier mitigate against duplicity and other types of threats against key event logs.
Many types of applications can act as Verifiers. For example, Verifier functionality could be integrated in the backend of a web application or in document management systems where signatures of signed documents are verified.
KERI Features
The KERI key management system has many features. Below I expand on some of the most important features for vLEI.
Key management
Key management is the main function of KERI. Key management solves problems such as:
- How do you make sure you are using the correct keys with your peers?
- How do you signal to your peers you have changed or terminated your keys?
Key Event Log
The Key Event Log (KEL) is the basic construct of KERI. The KEL is a hash linked chain of key events. A KERI identifier represents a single distinct KEL. The KEL is the cryptographic ledger or block chain of KERI.
Inception, rotation, and interaction are examples of common events in a KEL. Every KEL begins with an inception event followed by other events. The hash value of the first inception event becomes the KERI identifier of a KEL. Many key event logs will be relatively small and rather static with only a few entries.
The controller of a KEL adds its controller signature to each event that gets added to a KEL. As events are added the controller continuously publishes the KEL to one or more witnesses who add their witness signature to each event in the KEL. Once the KEL has been published to witnesses, the KEL becomes immutable, and no past entries in the KEL can be modified or removed. The witness makes the KEL available to Verifiers.
By comparing KELs from multiple witnesses a Verifier can make sure the KEL is authentic and has not, for example, been duplicated, branched, or otherwise tampered with.
Pre-rotation
Pre-rotation is a unique feature of KERI, where only the current public key or keys are published in a KEL. Only the hashes or commitments of the next public keys are published. Pre-rotation improves security because no parts of the key material of the next keys are made public.
Delegation
KERI delegation is a cooperative mutual agreement between two KERI identifiers. Delegation requires cryptographic commitment from both parties. KERI delegation delegates signing authority to the delegate.
In vLEI, delegation is used between the GLEIF root (a KERI identifier that links back to everything within the eco-system, this link is what provides the delegate-able abilities to vLEI) and external identifiers, and between the GLEIF external and QVI identifiers.
Multi-sig
KERI multi-sig is a KERI identifier formed from a group of public keys. Each multi-sig may be given a signing threshold to control who has signing authority and to improve resilience.
For example, a group with a signing threshold of three out of three always requires participation of all members. This threshold sets a strict control on signing authority but does not improve resilience. If any of the members lost control of their key, the group could no longer operate and recover from the loss.
In vLEI currently, the GLEIF root has a threshold of three out of seven. GLEIF external is two out of five. The minimum requirement for QVI and Legal Entity identifiers is a group of two members.
ACDC credentials
The wider ‘KERI’ ecosystem provides a verifiable credential format known as Authentic Chained Data Container (ACDC) credentials. Credential chaining is a unique feature of ACDC credentials compared to most other Verifiable Credential formats present today.
When verifying an ACDC credential the Verifier will check the revocation status of the received credential and each of the chained credentials. This allows implementing advanced use cases where, for example, credential revocation authority is delegated to other actors than the issuer of the credential.
In vLEI, every credential is on a chain that leads up to the QVI credential issued by GLEIF (Global LEI Foundation) to the QVI.
vLEI Trust Model
The vLEI Ecosystem Governance Framework describes the trust model of vLEI in full. This is a distilled view of the most important roles and types of credentials.
GLEIF
The Global Legal Entity Identifier Foundation (GLEIF) controls the vLEI root of trust with two multi-sig identifiers: GLEIF root and GLEIF external. The two identifiers are established with a delegation agreement. A member of the GLEIF multi-sig groups is called GLEIF Authorized Representative (GAR). The GARs will perform identity verification needed to issue QVI credentials.
The QVI credential is issued by the GLEIF external identifier to Qualified vLEI Issuers. The root identifier will never issue any credentials. This way the root identifier can remain offline, while only the KEL of the root identifier is made public.
Figure 2 – GLEIF identifiers for vLEI root of trust.
Qualified vLEI Issuer
The Qualified vLEI Issuer (QVI) is an organization that has been qualified by GLEIF to act as an issuer of vLEI credentials.
The QVI controls a multi-sig identifier with at least two members and that has established a delegation agreement with GLEIF external.
In addition, a QVI credential is issued by GLEIF external to the QVI. The QVI credential claims contain the LEI code of the QVI. The QVI credential is the top-most credential in the chain of vLEI credentials.
A member of the QVI multi-sig group is called Qualified vLEI Issuer Authorized Representative (QAR). The QARs will perform identity verification needed to issue vLEI, OOR and ECR credentials.
Figure 3 – GLEIF authorizes the QVI by setting up delegation and issuing a QVI credential.
Legal Entity
The Legal Entity (LE) is an organization that receives the vLEI credential.
The LE controls a multi-sig identifier with at least two members.
A LE-vLEI credential is issued by the QVI to the LE. The LE-vLEI credential claims contain the LEI code and name of the LE. The LE-vLEI credential is chained to the QVI credential of the issuer.
A member of the LE multi-sig group is called Legal Entity Authorized Representative (LAR).
Figure 4 – The QVI issues a vLEI credential to the Legal Entity.
The LE may issue OOR and ECR authorization credentials to a QVI, to authorize the QVI to issue individual OOR and ECR credentials on its behalf. The LE may also directly issue individual ECR credentials.
OOR and ECR Authorization Credentials
Authorization credentials are issued to the QVI by the LE. The credential’s claims contain the person’s name and role. The authorization credentials are chained to the vLEI credential of the LE. This way the LE has authority to revoke any OOR and ECR credentials.
OOR Credentials
Official Organization Role (OOR) credentials are issued to an individual person by the QVI. The credential’s claims contain the person’s name and official role as defined by ISO, from the authorization credential. The OOR credential is chained to the OOR authorization credential.
The QVI will verify information about Official Role assignment such as Chairman of the Board, CEO etc. from public records and perform identity verification needed to issue the OOR credential.
Figure 5 – An OOR credential has many levels of chaining, leading up to the QVI Credential.
ECR Credentials
Engagement Context Role (ECR) credentials are issued to an individual person either by the LE itself or by the QVI. The credential’s claims contain the person’s name and context role. The role name is context specific and defined by the LE. The ECR credential is either chained to the vLEI credential or the ECR authorization credential.
If the LE issues the ECR credential, then it is the responsibility of the LE to perform identity verification to a level that satisfies requirements of the LE.
If the LE authorizes the QVI to issue the ECR credential, for example to external contractors, then the QVI will perform identity verification needed to issue the ECR credential.
Figure 6 – An ECR credential has many levels of chaining, leading up to the QVI Credential.
If you want to know more about how you could use vLEIs in your business, please contact us.
Terminology
| Term | Description |
| GLEIF | Global Legal Entity Identifier Foundation |
| KERI | Key Event Receipt Infrastructure Modern distributed key management system (DKMS) |
| LEI | Legal Entity Identifier |
| vLEI | Verifiable LEI The LEI as a Verifiable Credential |
| GAR | GLEIF Authorized Representative |
| QVI | Qualified vLEI Issuer |
| QAR | Qualified vLEI Issuer Authorized Representative |
| LE | Legal Entity |
| LAR | Legal Entity Authorized Representative |
| ECR | Engagement Context Role |
| OOR | Official Organization Role |
| Signify | KERI Component Implements “Signing at the Edge” concept |
| KERI Agent | KERI Component Backend component of Signify |
| Witness | KERI Component |
| KEL | Key Event Log |
About The Author: Petteri Stenius
Principal Scientist at Ubisecure
More posts by Petteri Stenius