Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 173 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 top-level field map within an ACDC that provides directed connections to other ACDCs, forming a labeled property graph (LPG) where each edge represents a cryptographically verifiable relationship with optional operators, weights, and semantic properties.
An edge in the ACDC (Authentic Chained Data Container) specification is a top-level field map identified by the field label e that enables ACDCs to form directed acyclic graphs (DAGs) through cryptographically verifiable connections to other ACDCs. This structure transforms individual ACDCs from isolated credentials into nodes within a distributed property graph, where edges represent typed, weighted, and semantically rich relationships.
The edge section serves three critical purposes within the ACDC architecture:
The edge section follows ACDC's dual-mode design pattern, supporting two representations:
Compact Form: A single string containing the SAID of the edge block:
{
"e": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA"
}
This compact representation provides privacy-preserving disclosure where the edge structure exists but its details remain hidden until explicitly revealed.
Expanded Form: A complete field map containing the edge block SAID (d), individual edge nodes, operators, and weights:
{
"e": {
"d": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"auth": {
"n": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
"s": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
"o": "I2I"
}
}
}
Canonical Serialization: Edge block SAIDs must be computed over canonical JSON serialization with insertion-ordered field maps. Lexicographic ordering will produce incorrect SAIDs and break verification.
Field Ordering: The edge block SAID (d field) must be computed with placeholder characters in the SAID position, then the computed SAID replaces the placeholder. This creates the self-referential property.
Default Behavior: If the o field is omitted from an edge node, implementations MUST default to I2I operator behavior. This is the most restrictive and secure default.
Delegation Verification: DI2I operator requires checking the KEL of the child issuer to verify delegation from the parent issuee. This requires access to KEL infrastructure and adds verification complexity.
NI2I Security: When using NI2I operator, implementations should clearly document that no authorization chain is implied. This operator should be used only for reference purposes, not authorization decisions.
Recursive Verification: Complete credential chain validation requires recursively resolving and verifying all edges. Implementations must guard against:
Revocation Checking: Each ACDC in the chain must be checked against its registry for revocation status. A revoked credential anywhere in the chain invalidates the entire chain.
Schema Validation: The s field in edge nodes provides type safety. Implementations MUST verify that resolved target ACDCs have schema SAIDs matching the edge constraint.
Caching: Edge resolution can be expensive. Implement caching strategies for:
Lazy Resolution: For compact edges, defer resolution until needed. Not all verification scenarios require full edge expansion.
Parallel Resolution: When resolving multiple edges, fetch target ACDCs in parallel to reduce latency.
Each edge block contains:
d (SAID): Self-addressing identifier of the edge block itself, providing cryptographic integrityauth, le, qvi) representing individual connectionsn: SAID of the target ACDC being referenceds: Required schema SAID that the target ACDC must conform too: Optional operator defining the relationship logicw: Optional weight for directed weighted edgesThe edge section is defined in the ACDC specification with the following structure:
Top-Level Edge Field (e):
Edge Block SAID (d):
Edge Node Structure:
Each named edge (e.g., auth, le, qvi) contains:
{
"n": "<SAID of target ACDC>",
"s": "<Required schema SAID>",
"o": "<Operator code>",
"w": "<Weight value>"
}
Field Specifications:
n (node):
s (schema):
o (operator):
w (weight):
Edge blocks follow ACDC's standard encoding requirements:
Compact Form:
Expanded Form:
Edge Count:
Edge Block Construction:
e fieldExample Construction Process:
# Step 1: Define edge structure
edge_block = {
"auth": {
"n": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
"s": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
"o": "I2I"
}
}
# Step 2: Compute SAID
edge_said = compute_said(edge_block, algorithm="blake3-256")
# Step 3: Add SAID to edge block
edge_block["d"] = edge_said
# Step 4: Embed in ACDC
acdc["e"] = edge_block # Expanded form
# OR
acdc["e"] = edge_said # Compact form
Immutability Principle: Edge blocks are immutable once created. The SAID computation creates a cryptographic binding that makes any modification detectable. To change edges:
Edge Expansion: Transitioning from compact to expanded form:
# Compact form
acdc_compact = {
"e": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA"
}
# Retrieve full edge block from storage/cache
edge_block = retrieve_edge_block("EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA")
# Verify SAID matches
assert compute_said(edge_block) == "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA"
# Expand in ACDC
acdc_expanded = acdc_compact.copy()
acdc_expanded["e"] = edge_block
Edge Verification Process:
n fieldss constraintsOperator Validation Logic:
I2I (Issuer-to-Issuee): Default operator requiring strict chain
def validate_i2i_edge(child_acdc, parent_acdc, edge_node):
# Child issuer must be parent issuee
child_issuer = child_acdc["i"]
parent_issuee = parent_acdc["a"]["i"]
if child_issuer != parent_issuee:
raise ValidationError("I2I constraint violated")
# Verify schema constraint
if parent_acdc["s"] != edge_node["s"]:
raise ValidationError("Schema constraint violated")
DI2I (Delegated-Issuer-to-Issuee): Allows delegated issuers
def validate_di2i_edge(child_acdc, parent_acdc, edge_node):
# Child issuer must be parent issuee OR delegated from parent issuee
child_issuer = child_acdc["i"]
parent_issuee = parent_acdc["a"]["i"]
if child_issuer == parent_issuee:
return True # Direct match
# Check delegation chain
if is_delegated_from(child_issuer, parent_issuee):
return True
raise ValidationError("DI2I constraint violated")
NI2I (Not-Issuer-to-Issuee): Permissive linking
def validate_ni2i_edge(child_acdc, parent_acdc, edge_node):
# No issuer-issuee relationship required
# Only verify schema constraint
if parent_acdc["s"] != edge_node["s"]:
raise ValidationError("Schema constraint violated")
return True # NI2I allows any issuer
ACDC Specification: Edges are a core component of the ACDC protocol, enabling:
IPEX (Issuance and Presentation Exchange): Edge structures are traversed during:
vLEI Ecosystem: Edges implement the vLEI trust chain:
Creation Phase:
Presentation Phase:
Verification Phase:
Revocation Phase:
SAID (Self-Addressing Identifier):
d field)n field)s field)Attribute Section (a):
Schema Section (s):
Rules Section (r):
ACDCs can contain multiple edges forming complex graphs:
{
"e": {
"d": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"auth": {
"n": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
"s": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
"o": "I2I"
},
"le": {
"n": "EMhvwOlyEJ9kN4PrwCpr9Jsv7TxPhiYveZ0oP3lJzdEi",
"s": "ENPXp1vQzRF6JwIuS-mp2U8Uf1MoADoP_GqQ62VsDZWY",
"o": "I2I"
}
}
}
This structure creates a credential that references both an authorization credential and a legal entity credential, enabling complex validation logic.
Weighted edges enable quantitative relationship modeling:
{
"e": {
"d": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
"endorsement": {
"n": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
"s": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
"w": "0.85"
}
}
}
Weights can represent:
Complex authorization logic through operator selection:
Strict Chain (I2I):
Flexible Delegation (DI2I):
Reference Only (NI2I):
Edge Integrity:
Chain Validation:
Operator Security:
Privacy Implications:
Graduated Disclosure: Support both compact and expanded edge forms. Compact form reveals only that edges exist, not their structure or targets.
Selective Expansion: Allow selective expansion of specific edges while keeping others compact. This enables fine-grained privacy control.
Correlation Risks: Be aware that edge structures can enable correlation across presentations. Consider using different credential instances for different contexts.
Resolution Failures: Implement robust error handling for:
Validation Failures: Provide detailed error messages indicating:
Edge Validation Tests: Implement comprehensive tests for:
Chain Resolution Tests: Test:
Interoperability Tests: Verify: