Key Components

Each edge block contains:

• d (SAID): Self-addressing identifier of the edge block itself, providing cryptographic integrity
• Edge nodes: Named field maps (e.g., auth, le, qvi) representing individual connections
• Node properties:
  • n: SAID of the target ACDC being referenced
  • s: Required schema SAID that the target ACDC must conform to
  • o: Optional operator defining the relationship logic
  • w: Optional weight for directed weighted edges

Data Format

Field Definitions

The edge section is defined in the ACDC specification with the following structure:

Top-Level Edge Field (e):

• Type: String (compact) or Object (expanded)
• Required: No (optional top-level field)
• Purpose: Contains edge block SAID or full edge structure

Edge Block SAID (d):

• Type: String
• Format: CESR-encoded SAID
• Purpose: Content-addressable identifier for the edge block
• Computation: Cryptographic digest of the canonical serialization of the edge block

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):

  • Type: String
  • Format: CESR-encoded SAID
  • Required: Yes
  • Purpose: Identifies the target ACDC being referenced
  • Validation: Must resolve to a valid ACDC

• s (schema):

  • Type: String
  • Format: CESR-encoded SAID
  • Required: Yes
  • Purpose: Specifies the required schema of the target ACDC
  • Validation: Target ACDC's schema SAID must match this value

• o (operator):

  • Type: String
  • Format: Operator code (e.g., "I2I", "DI2I", "NI2I")
  • Required: No (defaults to I2I if omitted)
  • Purpose: Defines the logical relationship between issuer and issuee

• w (weight):

  • Type: String or Number
  • Required: No
  • Purpose: Provides edge weight for directed weighted graphs
  • Use case: Enables weighted authorization schemes

Encoding Format

Edge blocks follow ACDC's standard encoding requirements:

1. Serialization: JSON, CBOR, or MGPK (MessagePack)
2. Field Ordering: Insertion-ordered field maps (not lexicographic)
3. SAID Computation: Blake3-256 digest of canonical serialization
4. CESR Encoding: All SAIDs encoded as qualified CESR primitives

Size and Constraints

Compact Form:

• Size: 44 characters (CESR-encoded SAID)
• Overhead: Minimal, suitable for bandwidth-constrained scenarios

Expanded Form:

• Size: Variable, depends on number of edges and properties
• Typical range: 200-1000 bytes for simple edge structures
• Maximum: No hard limit, but practical considerations apply

Edge Count:

• Minimum: 0 (edge section is optional)
• Maximum: Unlimited (constrained by practical considerations)
• Typical: 1-5 edges per ACDC in vLEI ecosystem

Operations

Creation and Initialization

Edge Block Construction:

1. Define Edge Nodes: Identify target ACDCs and their relationships
2. Specify Schema Constraints: Set required schema SAIDs for type safety
3. Select Operators: Choose appropriate edge operators (I2I, DI2I, NI2I)
4. Compute Edge Block SAID: Generate cryptographic digest
5. Embed in ACDC: Include as top-level e field

Example 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

Updates and Modifications

Immutability Principle: Edge blocks are immutable once created. The SAID computation creates a cryptographic binding that makes any modification detectable. To change edges:

1. Create New ACDC: Issue a new credential with updated edge structure
2. Revoke Old ACDC: Mark the previous credential as revoked in the registry
3. Update References: Ensure downstream systems reference the new ACDC

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

Verification and Validation

Edge Verification Process:

1. SAID Verification: Confirm edge block SAID matches computed digest
2. Target Resolution: Retrieve target ACDCs referenced by n fields
3. Schema Validation: Verify target ACDC schemas match s constraints
4. Operator Validation: Check operator logic (I2I, DI2I, NI2I)
5. Chain Validation: Recursively verify entire credential chain

Operator 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

Usage Context

In Which Protocols

ACDC Specification: Edges are a core component of the ACDC protocol, enabling:

• Credential chaining for authorization hierarchies
• Proof-of-authority through verifiable delegation chains
• Complex authorization logic through operator combinations

IPEX (Issuance and Presentation Exchange): Edge structures are traversed during:

• Credential presentation to verifiers
• Chain-of-authority validation
• Graduated disclosure negotiations

vLEI Ecosystem: Edges implement the vLEI trust chain:

• QVI credentials edge to GLEIF root
• LE credentials edge to QVI credentials
• OOR/ECR authorization credentials edge to LE credentials
• OOR/ECR credentials edge to authorization credentials

Lifecycle Management

Creation Phase:

1. Issuer determines required credential chains
2. Constructs edge block with appropriate operators
3. Computes edge block SAID
4. Embeds in ACDC during issuance
5. Anchors to KEL through interaction event

Presentation Phase:

1. Holder receives presentation request
2. Determines required disclosure level (compact/expanded)
3. Resolves edge references if expanded form needed
4. Constructs presentation including chained credentials
5. Transmits via IPEX protocol

Verification Phase:

1. Verifier receives presentation
2. Extracts edge structure from presented ACDC
3. Resolves target ACDCs referenced in edges
4. Validates operator constraints
5. Recursively verifies entire credential chain
6. Makes authorization decision based on chain validity

Revocation Phase:

1. Issuer decides to revoke credential
2. Updates credential registry (TEL)
3. Edge references remain valid but credential status changes
4. Verifiers check registry during validation
5. Revoked credentials fail verification despite valid edges

Related Structures

SAID (Self-Addressing Identifier):

• Edge blocks have their own SAID (d field)
• Edge nodes reference target ACDCs via SAID (n field)
• Schema constraints specified via SAID (s field)

Attribute Section (a):

• Contains issuee AID referenced in I2I/DI2I validation
• Provides context for edge relationship semantics
• May contain additional edge-relevant data

Schema Section (s):

• Defines valid edge structures for ACDC type
• Specifies required/optional edge nodes
• Constrains operator usage

Rules Section (r):

• May contain legal language governing edge relationships
• Defines contractual obligations for credential chains
• Specifies liability for delegated authority

Advanced Edge Patterns

Multi-Edge Structures

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

Weighted edges enable quantitative relationship modeling:

{
  "e": {
    "d": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
    "endorsement": {
      "n": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
      "s": "EKA57bKBKxr_kN7iN5i7lMUxpMG-s19dRcmov1iDxz-E",
      "w": "0.85"
    }
  }
}

Weights can represent:

• Confidence levels in attestations
• Priority in authorization hierarchies
• Strength of relationships in reputation systems

Operator Combinations

Complex authorization logic through operator selection:

Strict Chain (I2I):

• Use case: Official organizational hierarchies
• Constraint: Each issuer must be previous issuee
• Example: CEO → CFO → Accountant credential chain

Flexible Delegation (DI2I):

• Use case: Scalable signing infrastructure
• Constraint: Issuer must be issuee or delegate
• Example: Company → Signing Service → Employee credential

Reference Only (NI2I):

• Use case: Supporting evidence without authority transfer
• Constraint: No issuer-issuee relationship required
• Example: Credential referencing external certifications

Security Considerations

Edge Integrity:

• SAID computation ensures edge block immutability
• Any modification to edge structure invalidates SAID
• Verifiers must always recompute and verify SAIDs

Chain Validation:

• Recursive verification required for entire chain
• Single invalid edge invalidates entire credential
• Revocation checking must occur at each level

Operator Security:

• I2I provides strongest authorization guarantees
• DI2I requires delegation verification infrastructure
• NI2I should be used cautiously for authorization decisions

Privacy Implications:

• Compact edges hide relationship structure
• Expanded edges reveal credential chains
• Graduated disclosure enables privacy-preserving presentations

Privacy Considerations

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.

Error Handling

Resolution Failures: Implement robust error handling for:

• Target ACDC not found
• Network failures during resolution
• Invalid SAIDs in edge nodes
• Schema mismatches

Validation Failures: Provide detailed error messages indicating:

• Which edge failed validation
• What constraint was violated
• Expected vs actual values

Testing Requirements

Edge Validation Tests: Implement comprehensive tests for:

• I2I operator validation (positive and negative cases)
• DI2I operator with delegation chains
• NI2I operator permissive behavior
• Schema constraint enforcement
• SAID verification

Chain Resolution Tests: Test:

• Simple two-level chains
• Complex multi-level chains
• Multiple edges per ACDC
• Circular reference detection
• Maximum depth enforcement

Interoperability Tests: Verify:

• Compact/expanded form conversion
• Cross-implementation compatibility
• CESR encoding/decoding
• JSON/CBOR/MGPK serialization