Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 195 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
A credential is evidence of authority, status, rights, or entitlement to privileges, consisting of a set of claims about a subject that can be cryptographically verified. In the KERI/ACDC ecosystem, credentials are implemented as Authentic Chained Data Containers (ACDCs) that provide verifiable proof-of-authorship and can be chained together to form directed acyclic graphs of trust relationships.
Within the KERI/GLEIF ecosystem, a credential is formally defined as evidence of authority, status, rights, entitlement to privileges, or the like. The canonical KERI glossary establishes that a credential has both a current state and a history, which is captured in a document or graph structure.
The W3C Verifiable Credentials Data Model provides the broader industry definition: credentials are data structures that represent a set of one or more claims made by an issuer, which can be cryptographically verified. The vLEI ecosystem builds upon this foundation while adding KERI-specific properties.
Official abbreviations: VC (Verifiable Credential), ACDC (Authentic Chained Data Container - the KERI implementation of verifiable credentials), vLEI (verifiable Legal Entity Identifier - specific credential types in the GLEIF ecosystem).
Credentials form the fundamental unit of verifiable information exchange in the vLEI ecosystem. The GLEIF vLEI Ecosystem Governance Framework defines six primary credential types that create a hierarchical trust structure:
Implementing credential systems within the vLEI ecosystem requires adherence to multiple governance frameworks:
Schema Compliance: All credentials must conform to their published JSON schemas, which are identified by SAIDs and versioned using semantic versioning. Schema changes that break backward compatibility require major version increments.
Identity Verification: Credential issuers must implement identity assurance procedures meeting at least IAL2 standards, including real-time OOBI sessions with challenge-response authentication for role credentials.
Multi-Signature Requirements: For Legal Entities with multiple authorized signers, authorization credentials must be signed by all LARs meeting the signing threshold of the Legal Entity's AID.
Registry Management: Credential issuers must maintain Transaction Event Logs for tracking credential status and anchor all credential lifecycle events to their KELs.
Grace Period Handling: QVI credentials include grace periods (default 90 days) to enable smooth transitions when QVIs are terminated, requiring careful lifecycle management.
Credential implementations must support graduated disclosure mechanisms:
Compact Disclosure: Present only SAIDs without revealing underlying content, suitable for initial low-trust interactions.
Partial Disclosure: Reveal specific sections while keeping others compact, enabling progressive trust building.
Selective Disclosure: Use attribute aggregates to selectively reveal individual claims without exposing other attributes in the same block.
Chain-Link Confidentiality: Implement contractual protections that bind downstream recipients to confidentiality obligations, creating legally enforceable privacy chains.
Credential verifiers must implement comprehensive validation:
Cryptographic Validation: Verify issuer signatures using current key state from KEL, validate all SAIDs, check CESR proof signatures.
Schema Validation: Confirm credential structure matches declared schema, verify required fields, validate field formats.
Chain Validation: Follow edge references to prerequisite credentials, verify entire chain to root of trust, validate edge operators.
Status Checking: Query TEL for revocation status, verify issuer credential validity, check grace periods.
Each credential type serves a specific governance function within the trust chain, enabling verifiable organizational identity and role-based authorization.
GLEIF (Global Legal Entity Identifier Foundation) operates as the root of trust for the vLEI ecosystem. The organization:
Credentials in this context serve to digitize and make verifiable the traditional LEI system, transforming static organizational identifiers into dynamic, cryptographically verifiable credentials that can participate in automated trust decisions.
Qualified vLEI Issuers (QVIs): Organizations qualified by GLEIF to issue Legal Entity and role credentials. QVIs must hold valid QVI vLEI Credentials and operate under contractual obligations defined in the vLEI Issuer Qualification Agreement.
Legal Entities: Organizations holding LEIs that receive Legal Entity vLEI Credentials. These entities can then authorize QVIs to issue role credentials to their representatives.
Legal Entity Authorized Representatives (LARs): Individuals authorized by Legal Entities to request credential issuance and manage the entity's vLEI credential lifecycle.
QVI Authorized Representatives (QARs): Individuals authorized by QVIs to perform identity verification and credential issuance operations.
Credentials in the KERI/ACDC framework serve multiple critical functions:
Proof of Authority: Credentials provide verifiable evidence that an entity has specific rights, permissions, or authorizations. In the vLEI context, this includes proving that a QVI is authorized to issue credentials, that a Legal Entity holds a valid LEI, or that an individual holds an official role within an organization.
Identity Binding: Credentials cryptographically bind claims to specific Autonomic Identifiers (AIDs), creating non-repudiable associations between identities and assertions. The credential's issuer AID appears at the top level, while the issuee AID (when present) appears in the attributes section.
Chain of Trust: Through ACDC's edge mechanism, credentials can reference other credentials, creating verifiable chains of authority. For example, an OOR credential chains to an OOR Authorization credential, which chains to a Legal Entity credential, which chains to a QVI credential, ultimately anchoring to GLEIF's root of trust.
Selective Disclosure: ACDC credentials support graduated disclosure mechanisms, allowing holders to reveal only necessary information in different contexts. Credentials can be presented in compact form (showing only SAIDs), partially disclosed (revealing some sections), or fully disclosed (showing all attributes).
Revocation Management: Credentials reference Transaction Event Logs (TELs) through their registry identifier (ri field), enabling verifiable revocation status checking without requiring centralized revocation lists.
Issuance Authority: Only entities holding appropriate authorization credentials can issue specific credential types. For example, only QVIs holding valid QVI vLEI Credentials can issue Legal Entity credentials, and only after receiving proper authorization credentials from the Legal Entity.
Verification Authority: Any party can cryptographically verify a credential's authenticity by:
Presentation Authority: Credential holders control when and how their credentials are presented. The IPEX (Issuance and Presentation Exchange) protocol governs credential disclosure, enabling holders to negotiate what information to reveal based on verifier requirements and holder policies.
Scope Boundaries: Each credential type has explicitly defined scope within its governance framework. For example, OOR credentials attest to official organizational roles but do not imply broader authority beyond what the role description specifies.
Temporal Constraints: Credentials include issuance timestamps (dt field) and may have grace periods or validity windows. Verifiers must check that credentials are being used within their intended temporal scope.
Context Restrictions: While vLEI credentials are designed for context independence (usable in-person, online, or telephonically), specific use cases may impose additional requirements through the rules section of the credential.
Non-Transferability: Credentials are cryptographically bound to specific AIDs and cannot be transferred between identities. The strong binding principle ensures that only the legitimate holder can present the credential.
The credential issuance process varies by credential type but follows a general pattern:
1. Authorization Phase: For role credentials, the Legal Entity must first issue an authorization credential to the QVI, explicitly granting permission to issue the role credential to a specific individual.
2. Identity Verification: The issuer (or their authorized representative) must perform identity assurance according to the credential's governance framework. For vLEI credentials, this typically requires:
3. Credential Creation: The issuer constructs the ACDC following the appropriate JSON schema, including:
4. Registry Anchoring: The credential issuance event is anchored to the issuer's KEL through a Transaction Event Log (TEL), creating a verifiable record of issuance.
5. IPEX Grant: The credential is transmitted to the holder using the IPEX protocol, which provides secure, authenticated credential delivery with cryptographic proof of transmission.
6. Holder Admission: The holder receives the credential, validates it, and stores it in their credential database, completing the issuance cycle.
Credential verification involves multiple validation steps:
Cryptographic Verification:
Schema Validation:
Chain Validation:
Status Checking:
Policy Evaluation:
Credentials may be revoked under various circumstances defined in their governance frameworks:
QVI Credential Revocation:
Legal Entity Credential Revocation:
Role Credential Revocation:
Revocation is implemented through TEL events that are anchored to the issuer's KEL, creating an immutable, verifiable record of the revocation action.
vLEI Ecosystem Governance Framework v3.0: The overarching governance document that establishes core policies, principles, and requirements for all vLEI credentials. This framework defines:
Qualified vLEI Issuer vLEI Credential Framework: Defines requirements for QVI credentials, including:
Legal Entity vLEI Credential Framework: Establishes requirements for Legal Entity credentials, including:
Legal Entity Official Organizational Role vLEI Credential Framework: Governs OOR credentials, including:
Legal Entity Engagement Context Role vLEI Credential Framework: Governs ECR credentials, including:
Qualified vLEI Issuer Authorization vLEI Credential Framework: Defines authorization credentials, including:
ACDC Specification: The Trust over IP Foundation specification defining Authentic Chained Data Containers, including:
IPEX Specification: The Issuance and Presentation Exchange protocol specification, defining:
CESR Proof Signatures Specification: Defines how credentials are cryptographically signed, including:
vLEI Credential Schema Registry: Technical requirements document listing:
vLEI Ecosystem Information Trust Policies: Establishes cross-cutting policies for:
vLEI Ecosystem Risk Assessment: Documents identified risks and mitigation strategies for:
vLEI Glossary: Provides authoritative definitions for all terms used in the vLEI ecosystem, ensuring consistent interpretation across governance documents and technical specifications.
Credentials in the KERI/ACDC framework are implemented as structured JSON documents with specific field ordering requirements. The top-level structure includes:
[v, d, u, i, ri, s, a, A, e, r]
Where fields must appear in this exact order when present. The attributes section (a) contains the substantive claims, the edges section (e) provides credential chaining, and the rules section (r) contains legal disclaimers and usage terms.
Credentials leverage SAIDs (Self-Addressing Identifiers) extensively, with each major section having its own SAID. This enables:
The CESR encoding of credentials enables efficient streaming and attachment of cryptographic proofs, supporting both text and binary representations while maintaining composability.
Credentials integrate with the broader KERI ecosystem through multiple mechanisms:
KEL Anchoring: Credential issuance and revocation events are anchored to the issuer's Key Event Log, binding credential lifecycle to identifier control authority.
TEL Integration: Transaction Event Logs track credential status, enabling verifiable revocation checking without centralized infrastructure.
OOBI Discovery: Out-Of-Band Introductions enable discovery of credential issuers and their service endpoints, facilitating credential verification.
Witness Networks: KERI witnesses provide high availability and duplicity detection for credential-related events, ensuring ecosystem resilience.
Watcher Networks: Watchers provide ambient duplicity detection, enabling any party to verify credential authenticity without trusting specific infrastructure.
This integration creates a comprehensive, end-verifiable credential ecosystem that operates without requiring centralized registries, certificate authorities, or trusted intermediaries.
Policy Enforcement: Apply verifier-specific acceptance policies, evaluate credential rules, assess disclosure adequacy.