Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 20 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.
GEDA (GLEIF External Delegated AID) is a KERI Autonomic Identifier delegated from the GLEIF Root AID, used by GLEIF to manage its relationship with and authorize vLEI Issuers (QVIs) within the vLEI ecosystem.
The GLEIF External Delegated AID (GEDA) is formally defined in the vLEI Ecosystem Governance Framework as a KERI Autonomic Identifier (AID) delegated from the GLEIF Root AID. GEDA serves as GLEIF's operational identity for issuing QVI credentials and establishing the chain of trust from the root to QVIs.
According to the GLEIF Identifier Governance Framework v1.0, GEDA is one of two primary delegated AIDs under the GLEIF Root AID, the other being GIDA (GLEIF Internal Delegated AID). While GIDA handles internal GLEIF operations, GEDA specifically manages external ecosystem relationships, particularly the authorization and oversight of Qualified vLEI Issuers.
The canonical abbreviation is GEDA, though it may also be referred to as the "GLEIF External Delegated Identifier" or "GLEIF External AID" in governance documents.
GEDA occupies a critical intermediate position in the vLEI trust hierarchy:
GLEIF Root AID (apex of trust)
|
├── GIDA (Internal Delegated AID)
└── GEDA (External Delegated AID)
|
└── QVI Delegated AIDs
|
└── Legal Entity vLEI Credentials
|
└── Role Credentials (OOR/ECR)
This hierarchical structure implements a tree of trust where:
GLEIF maintains a separation of concerns through its dual delegated AID structure:
GEDA (External):
GIDA (Internal):
This architectural separation ensures that compromise of internal systems does not directly affect external ecosystem trust, and vice versa. It also enables different security policies and operational procedures for internal versus external operations.
GEDA is cryptographically bound to the GLEIF Root AID through KERI's delegation mechanism. According to the governance framework:
This delegation structure provides end-to-end verifiability of GEDA's authority without requiring centralized registries or certificate authorities.
GEDA serves as GLEIF's operational identity for QVI management, with the following core responsibilities:
1. QVI Credential Issuance
GEDA is the issuer of QVI vLEI Credentials, which authorize organizations to act as Qualified vLEI Issuers. According to the Qualified vLEI Issuer vLEI Credential Governance Framework, GEDA:
2. QVI Delegated AID Approval
GEDA must approve the inception of QVI delegated AIDs through a formal delegation ceremony. The technical documentation "Approving QVI Inception Events" specifies that:
delpre field of the QVI's inception configuration3. QVI Oversight and Termination
GEDA manages the operational status of QVIs throughout their lifecycle:
4. Ecosystem Governance Enforcement
GEDA serves as the enforcement mechanism for vLEI ecosystem governance:
GEDA possesses specific authorities within the vLEI ecosystem:
Credential Issuance Authority:
Delegation Authority:
Revocation Authority:
Registry Management:
GEDA's authority is explicitly bounded by governance framework policies:
Scope Limitations:
Delegation Limitations:
Operational Limitations:
GEDA is controlled by a multisig group of External GARs, as documented in the "GLEIF Authorized Representative (GAR)" repository:
Multisig Configuration:
Key Management:
GEDA's KEL is witnessed by a distributed witness pool providing duplicity detection:
Witness Requirements (from Technical Requirements Part 1):
Example Witness Configuration:
{
"wits": [
"BBilc4-L3tFUnfM_wJr4S4OJanAv_VmF_dJNN6vkf2Ha",
"BLskRTInXnMxWaGqcpSyMgo0nYbalW99cGZESrz3zapM",
"BIKKuvBwpmDVA4Ds-EpL5bt9OqPzWPja2LigFYZN2YfX"
],
"toad": 2
}
The QVI delegation ceremony involves coordinated operations between GEDA and QVI participants:
Step 1: QVI Multisig Inception
delpre fieldStep 2: GEDA Approval
Step 3: Delegation Completion
GEDA maintains a Transaction Event Log (TEL) for QVI credential status:
Registry Architecture:
Registry Operations:
The issuance process follows a multi-step qualification and verification workflow:
Phase 1: QVI Qualification
Phase 2: QVI AID Establishment
Phase 3: Credential Issuance
Phase 4: Credential Publication
Verifiers validate QVI credentials through cryptographic verification chains:
Step 1: Credential Verification
Step 2: Issuer Verification
Step 3: Status Verification
Step 4: Chain of Trust Validation
GEDA MUST revoke QVI credentials under specific conditions defined in the governance framework:
Qualification Failure:
LEI Status Changes:
Governance Violations:
Revocation Process:
GLEIF Identifier Governance Framework v1.0 (2022-12-16)
Qualified vLEI Issuer vLEI Credential Governance Framework v1.5 (2025-04-16)
vLEI Ecosystem Governance Framework v3.0 Trust Assurance Framework v1.5 (2025-04-16)
Technical Requirements Part 1: KERI Infrastructure v1.3 (2025-04-16)
vLEI Ecosystem Governance Framework Glossary v1.3 (2023-12-15)
GLEIF Authorized Representative (GAR) Documentation
Approving QVI Inception Events
GEDA implementations MUST adhere to stringent security standards:
Key Management:
Infrastructure Protection:
Operational Security:
GEDA must maintain interoperability across the vLEI ecosystem:
Protocol Compliance:
Discovery Mechanisms:
Credential Formats:
GEDA operations must demonstrate continuous compliance with governance requirements:
Qualification Oversight:
Reporting Requirements:
Policy Updates:
External GAR Coordination: GEDA operations require coordination among multiple External GARs who must maintain secure key stores and participate in multisig ceremonies. Organizations implementing GEDA must establish clear procedures for GAR authentication, challenge-response protocols, and threshold signing coordination.
Witness Pool Management: GEDA's witness pool should be geographically distributed across multiple regions (EU, NA, AS, OC) to provide resilience against regional failures. Witness selection should prioritize independence, reliability, and compliance with GLEIF's security standards.
QVI Delegation Workflow: The QVI delegation approval process requires careful coordination between QVI participants and External GARs. Organizations should implement automated tooling to validate QVI inception configurations against governance requirements before GAR approval.
Credential Registry Maintenance: GEDA's credential registry (TEL) must be continuously available for verifiers. Implementations should include redundancy, backup procedures, and monitoring to ensure registry availability meets ecosystem SLA requirements.
Version Management: GEDA implementations must support KERI specification version upgrades within the 18-month backward compatibility window and 12-month implementation period. Organizations should plan upgrade cycles to maintain ecosystem interoperability.
Key Compromise Recovery: GEDA's pre-rotation mechanism enables recovery from key compromise without breaking the chain of trust. Organizations should maintain secure storage of pre-rotated keys separate from current signing keys, with highest level protection (HSM or equivalent).
Multisig Threshold Selection: The multisig threshold for GEDA should balance security (requiring multiple GAR signatures) with operational efficiency (avoiding excessive coordination overhead). A 2-of-3 or 3-of-5 configuration is typical for production deployments.
Witness Pool Security: Witness compromise does not directly compromise GEDA's keys, but can enable duplicity attacks. Organizations should monitor witness behavior, implement witness rotation procedures, and maintain sufficient witness pool size to tolerate Byzantine faults.
Audit and Monitoring: All GEDA operations should be logged and monitored for anomalous behavior. Implementations should include alerting for unusual patterns such as unexpected credential issuance, revocation events, or key rotation attempts.