Comprehensive Explanation

ACDC (Authentic Chained Data Container)

Protocol Definition

Core Purpose and Objectives

The Authentic Chained Data Container (ACDC) protocol is an IETF internet draft specification that defines a data container format for creating verifiable, chainable data structures that provide granular provenanced proof-of-authorship (authenticity) of contained data. ACDCs form directed acyclic graphs (DAGs) where each container serves as a node with cryptographically verifiable connections (edges) to other ACDCs, enabling the construction of complex, verifiable data relationships.

The primary objectives of the ACDC protocol are:

1. Authentic Data Provenance: Provide cryptographically verifiable proof-of-authorship through a tree or chain of linked ACDCs, forming a DAG that enables an "authentic web" where all data has verifiable proof-of-authorship
2. Proof-of-Authority Extension: With additional syntactic features, extend to provide proof-of-authority for delegated authorizations, entitlements, permissions, rights, and credentials
3. Privacy-Preserving Disclosure: Enable graduated disclosure mechanisms (compact, partial, selective, full) that allow progressive revelation of information while maintaining cryptographic verifiability
4. Composability: Support multiple serialization formats (JSON, CBOR, MGPK, CESR) with compact and uncompacted variants
5. Schema-Based Type System: Use JSON Schema itself as the type definition mechanism, providing clean separation between data payload and metadata

Formal Specification References

The ACDC specification is being developed under the Trust Over IP Foundation's Technical Stack Working Group and is currently at version 0.9 Draft status. The specification references several normative dependencies:

• KERI (Key Event Receipt Infrastructure): Provides the foundational identifier and key management infrastructure
• SAID (Self-Addressing IDentifier): Protocol for self-referential cryptographic digests
• CESR (Composable Event Streaming Representation): Encoding protocol for primitives
• PTEL (Public Transaction Event Log): For credential status tracking
• CESR-Proof: For cryptographic signature attachments
• IPEX (Issuance and Presentation Exchange): Protocol for ACDC exchange

The specification is hosted at the Trust Over IP Foundation GitHub repository and is being incubated for eventual IETF standardization.

Version History and Evolution

The ACDC specification has evolved through several phases:

• Early Conceptual Phase (2021): Initial presentations at IIW and DICE conferences establishing core concepts of authentic data containers and chained provenance
• Draft Specification Phase (2022): Development of formal specification with JSON Schema integration, SAID protocol integration, and graduated disclosure mechanisms
• Current Phase (2023-2024): Refinement of edge operators (I2I, DI2I, NI2I), integration with IPEX protocol, and production deployment in GLEIF vLEI ecosystem

The specification has added crucial technical terms including ACDC, CESR, and IPEX in version 1.3, demonstrating continued technical sophistication.

Protocol Architecture

High-Level Architecture

ACDCs are structured as ordered nested field maps (key-value mappings) where the term "field" is deliberately used instead of "key" to avoid confusion with cryptographic keys. The architecture follows a layered approach:

Layer 1: Structural Foundation

• Ordered nested field maps with insertion-order preservation
• Support for multiple serialization types (JSON, CBOR, MGPK, CESR)
• Canonical serialization requirements for SAID computation

Layer 2: Cryptographic Binding

• SAID protocol for self-referential cryptographic digests
• Cryptographic commitment to content through SAIDs
• Signature attachments via CESR-Proof

Layer 3: Graph Structure

• DAG formation through edge references
• Chained provenance through SAID-based linking
• Support for complex authorization graphs

Layer 4: Disclosure Control

• Compact variants using SAID references
• Graduated disclosure mechanisms
• Privacy-preserving attribute revelation

Component Organization

An ACDC consists of several primary components:

Top-Level Fields (mandatory ordering: [v, d, u, i, rd, s, a, A, e, r]):

• v (Version String): Protocol identification and metadata
• d (SAID): Self-referential cryptographic digest of the enclosing map
• u (UUID): Optional high-entropy nonce for privacy
• i (Issuer AID): Autonomic Identifier of the issuer
• rd (Registry SAID): Reference to issuance/revocation registry
• s (Schema): SAID of JSON Schema or schema block itself
• a (Attribute): SAID of attribute block or block itself
• A (Attribute Aggregate): Aggregate of selectively disclosable attributes
• e (Edge): SAID of edge block or block itself
• r (Rule): SAID of rules block or block itself

Required Fields: [v, d, i, s]

Section Blocks:

• Attribute Section: Contains claims about the credential subject
• Edge Section: Defines connections to other ACDCs forming the DAG
• Rule Section: Contains Ricardian contracts and usage policies

Data Flow and Control Flow

Issuance Flow:

1. Issuer creates ACDC with required fields and sections
2. SAID computation recursively processes nested structures
3. Issuer signs the ACDC (typically the compact variant)
4. Signature is anchored in issuer's KEL via interaction or rotation event
5. ACDC is registered in TEL for status tracking
6. ACDC is transmitted to holder via IPEX protocol

Presentation Flow:

1. Holder receives presentation request from verifier
2. Holder selects appropriate disclosure level (compact, partial, selective, full)
3. Holder creates presentation ACDC with chosen disclosure
4. Holder signs presentation via CESR-Proof
5. Presentation is transmitted to verifier via IPEX
6. Verifier validates signatures, SAIDs, and credential status

Verification Flow:

1. Verifier receives ACDC presentation
2. Verifier resolves issuer AID via OOBI
3. Verifier validates issuer's KEL and key state
4. Verifier verifies ACDC signature against issuer's current keys
5. Verifier validates SAID integrity recursively
6. Verifier checks credential status in TEL
7. Verifier validates schema compliance
8. Verifier validates edge chains if present

State Management Approach

ACDCs themselves are stateless data structures - they represent immutable commitments at a point in time. However, state management occurs through:

KEL (Key Event Log) State:

• Issuer's key state determines signature validity
• Key rotations affect which keys can verify ACDC signatures
• KEL provides authoritative key state at any point in time

TEL (Transaction Event Log) State:

• Tracks issuance, revocation, and transfer events
• Provides current status of credential (issued, revoked, transferred)
• Anchored to issuer's KEL for verifiable provenance

Presentation State:

• Ephemeral state during IPEX exchanges
• Challenge-response authentication state
• Negotiation state for graduated disclosure

Message Formats & Encoding

ACDC Message Structure

ACDCs support multiple serialization formats with consistent semantic structure:

JSON Serialization (primary format for examples):

{
  "v": "ACDC10JSON00011c_",
  "d": "EAdXt3gIXOf2BBWNHdSXCJnFJL5OuQPyM5K0neuniccM",
  "u": "0ABghkDaG7OY1wjaDAE0qHcg",
  "i": "did:keri:EBkPreYpZfFk66jpf3uFv7vklXKhzBrAqjsKAn2EDIPM",
  "ri": "did:keri:ECmRy7xMwsxUelUauaXtMxTfPAMPAI6FkekeolOjkggt",
  "s": "ED6jrVPTzlSkUPqGGeIZ8a8FWS7a6s4reAXRZOkogZ2A",
  "a": "EEveY4-9XgOcLxUderzwLIr9Bf7V_NHwY1lkFrn9y2PY",
  "e": "EFH3dCdoFOLe71iheqcywJcnjtJtQIYPvAu6DZIl3MOA",
  "r": "EG71iheqcywJcnjtJtQIYPvAu6DZIl3MORH3dCdoFOLB"
}

CBOR Serialization: Binary encoding following RFC 8949 MGPK Serialization: MessagePack binary encoding CESR Serialization: Composable Event Streaming Representation for primitives

Field Definitions and Semantics

Version String (v):

• Format: ACDCMmmGggKKKKSSSS.
• ACDC: Protocol identifier
• Mm: Major version (hex)
• Ggg: CESR genus version (hex)
• KKKK: Serialization kind code
• SSSS: Size in characters/bytes (hex)
• .: Terminator

Example: ACDC10JSON00011c_ indicates ACDC version 1.0, JSON serialization, size 0x11c

SAID (d):

• Self-Addressing Identifier computed over the entire ACDC
• Uses Blake3-256 digest algorithm (approximately 128 bits cryptographic strength)
• Encoded in CESR format (44 characters for 256-bit digest)
• Computed by:
  1. Replacing d field with placeholder # characters
  2. Serializing to canonical form
  3. Computing Blake3-256 digest
  4. Encoding digest in CESR
  5. Replacing placeholder with computed SAID

UUID (u):

• High-entropy pseudo-random string (≥128 bits)
• Serves as "salty nonce" for privacy protection
• Prevents rainbow table attacks on public ACDCs
• Optional field distinguishing public vs. private ACDCs

Issuer AID (i):

• KERI Autonomic Identifier of credential issuer
• Must be transferable (support key rotation)
• Encoded in CESR format
• Resolves to KEL for key state verification

Registry Identifier (ri):

• SAID of TEL tracking credential status
• Enables revocation checking
• Optional for non-revocable credentials

Schema (s):

• SAID of JSON Schema defining credential structure
• Enables schema verification and validation
• Supports composed schemas via JSON Schema composition operators
• Can be compact (SAID only) or expanded (full schema)

Attribute Section (a):

• Contains credential claims and assertions
• Can be compact (SAID) or expanded (full attributes)
• Supports nested structures
• Required fields depend on credential type

Attribute Aggregate (A):

• Array or aggregate of selectively disclosable attributes
• Each attribute has its own SAID for selective disclosure
• Enables unbundling of attributes
• Supports bulk issuance patterns

Edge Section (e):

• Defines connections to other ACDCs
• Creates DAG structure
• Supports edge operators (I2I, DI2I, NI2I)
• Enables complex authorization graphs

Rule Section (r):

• Contains Ricardian contracts
• Defines usage policies and constraints
• Machine-readable and human-readable
• Supports chain-link confidentiality

Encoding Schemes

CESR Encoding:

• All cryptographic primitives encoded in CESR
• Supports both text and binary domains
• Composable and self-framing
• Enables round-trip conversion between domains

JSON Schema Integration:

• Type-is-schema approach
• Immutable schemas identified by SAID
• Composable via JSON Schema operators
• Supports both compact and uncompacted variants

Canonical Serialization:

• Insertion-ordered field maps
• No lexicographic ordering requirement
• Consistent serialization for SAID computation
• Round-trip preservation of field order

Protocol Mechanics

Message Exchange Patterns

Issuance Exchange Pattern:

1. Offer Phase: Issuer offers credential to holder

   • Issuer sends IPEX offer message with ACDC SAID
   • Holder evaluates offer and decides to accept/reject

2. Grant Phase: Issuer grants credential to holder

   • Issuer sends IPEX grant message with full ACDC
   • ACDC includes issuer signature via CESR-Proof
   • Holder receives and validates ACDC

3. Admit Phase: Holder admits receipt of credential

   • Holder sends IPEX admit message acknowledging receipt
   • Holder may sign ACDC to indicate agreement with terms
   • Completes issuance exchange

Presentation Exchange Pattern:

1. Apply Phase: Verifier requests credential presentation

   • Verifier sends IPEX apply message specifying requirements
   • Requirements may include schema, attributes, disclosure level

2. Offer Phase: Holder offers to present credential

   • Holder sends IPEX offer message with ACDC SAID
   • Indicates willingness to present at specified disclosure level

3. Grant Phase: Holder grants credential presentation

   • Holder sends IPEX grant message with ACDC at chosen disclosure level
   • Includes holder signature via CESR-Proof
   • Verifier receives and validates presentation

4. Admit Phase: Verifier admits acceptance of presentation

   • Verifier sends IPEX admit message acknowledging validation
   • Completes presentation exchange

State Transitions

Credential Lifecycle States:

1. Issued: Initial state after issuance, recorded in TEL
2. Active: Credential is valid and not revoked
3. Revoked: Credential has been revoked by issuer
4. Expired: Credential has passed validity period (if specified)
5. Transferred: Credential ownership has been transferred (if transferable)

TEL State Transitions:

• Issuance Event: Transitions credential to Issued state
• Revocation Event: Transitions credential to Revoked state
• Transfer Event: Transitions credential ownership
• All transitions anchored in issuer's KEL

Disclosure State Transitions:

• Compact → Partial: Expand selected sections while keeping others compact
• Partial → Selective: Reveal specific attributes from aggregate
• Selective → Full: Expand all remaining compact sections
• All transitions maintain SAID integrity

Timing and Ordering Requirements

SAID Computation Ordering:

• Must compute SAIDs from innermost blocks outward
• Nested SAIDs must be computed before parent SAIDs
• Ensures consistent SAID values across all variants

Signature Ordering:

• Issuer signature must be applied after SAID computation
• Holder signature (if required) applied during presentation
• Signatures verified in reverse order of application

KEL Anchoring Timing:

• ACDC signature must be anchored in issuer's KEL
• Anchoring event must be witnessed and receipted
• Verifiers must validate KEL state at time of signature

TEL Registration Timing:

• Issuance event must be registered in TEL
• Registration must occur before credential presentation
• Revocation events must be registered before taking effect

Security Properties

Threat Model

The ACDC protocol addresses several threat categories:

Forgery Attacks:

• Attacker attempts to create fake credentials
• Mitigated by: Issuer signature verification via KEL
• Attacker cannot forge valid signatures without compromising issuer keys

Tampering Attacks:

• Attacker attempts to modify credential content
• Mitigated by: SAID integrity verification
• Any modification invalidates SAID, detected during verification

Replay Attacks:

• Attacker attempts to reuse revoked credentials
• Mitigated by: TEL status checking
• Verifiers must check current credential status

Correlation Attacks:

• Attacker attempts to correlate credential presentations
• Mitigated by: UUID nonces, selective disclosure, graduated disclosure
• Private ACDCs use high-entropy UUIDs to prevent correlation

Rainbow Table Attacks:

• Attacker attempts to discover credential content via precomputed hashes
• Mitigated by: UUID nonces in private ACDCs
• High-entropy UUIDs make rainbow tables computationally infeasible

Key Compromise Attacks:

• Attacker compromises issuer's signing keys
• Mitigated by: Key rotation via KERI, pre-rotation for quantum resistance
• Compromised keys can be rotated, invalidating old signatures

Security Guarantees

The ACDC protocol provides several cryptographic security guarantees:

Authenticity:

• Cryptographic proof of issuer identity via AID
• Non-repudiable signatures anchored in KEL
• End-verifiable without trusted intermediaries

Integrity:

• Tamper-evident via SAID mechanism
• Any modification breaks cryptographic binding
• Recursive integrity through nested SAIDs

Provenance:

• Verifiable chain of authority via edge references
• DAG structure provides complete provenance graph
• Cryptographic binding between chained credentials

Revocability:

• Issuer can revoke credentials via TEL
• Revocation is verifiable and non-repudiable
• Revocation state is end-verifiable

Privacy:

• Graduated disclosure enables minimal disclosure
• Selective disclosure prevents unnecessary correlation
• Private ACDCs resist rainbow table attacks

Attack Resistance

Cryptographic Strength:

• Minimum 128 bits of cryptographic strength required
• Blake3-256 provides approximately 128 bits security
• Ed25519 signatures provide 128 bits security
• Post-quantum considerations via KERI pre-rotation

Duplicity Detection:

• KERI's duplicity detection extends to ACDCs
• Conflicting credentials from same issuer are detectable
• Witnesses and watchers provide duplicity evidence

Sybil Resistance:

• AIDs provide Sybil-resistant identifiers
• Key management via KERI prevents identity proliferation
• Witness pools provide additional Sybil resistance

Denial of Service Resistance:

• Stateless verification reduces DoS attack surface
• No online issuer required for verification
• Distributed witness pools prevent single points of failure

Interoperability

Dependencies on KERI/ACDC Protocols

KERI (Key Event Receipt Infrastructure):

• Provides AID infrastructure for issuers and holders
• KEL provides authoritative key state
• Witness pools provide availability and duplicity detection
• Pre-rotation provides quantum-resistant key management

SAID (Self-Addressing IDentifier):

• Core integrity mechanism for ACDCs
• Enables content-addressable references
• Provides tamper-evident properties
• Supports graduated disclosure

CESR (Composable Event Streaming Representation):

• Encoding for all cryptographic primitives
• Enables text/binary domain composability
• Provides self-framing properties
• Supports efficient streaming

CESR-Proof:

• Signature attachment mechanism
• Enables nested partial signatures
• Supports transposable signatures
• Provides SAD path language for targeting

IPEX (Issuance and Presentation Exchange):

• Protocol for ACDC exchange
• Defines offer/grant/admit patterns
• Supports both issuance and presentation
• Enables graduated disclosure negotiation

OOBI (Out-Of-Band Introduction):

• Discovery mechanism for AIDs
• Enables KEL resolution
• Provides service endpoint discovery
• Supports witness pool discovery

TEL (Transaction Event Log):

• Credential status tracking
• Issuance/revocation/transfer events
• Anchored to issuer's KEL
• Provides verifiable credential lifecycle

Integration Points

W3C Verifiable Credentials:

• ACDCs can be expressed as W3C VCs
• ACDC provides enhanced features (chaining, graduated disclosure)
• Compatible with VC data model
• Extends VC with KERI security properties

DID Methods:

• did:keri method for KERI AIDs
• did:webs method for web-based KERI
• Compatible with DID resolution
• Supports DID document generation

JSON-LD:

• ACDCs can include JSON-LD contexts
• Schema-based approach preferred over JSON-LD
• Avoids JSON-LD security issues
• Maintains semantic interoperability

OAuth/OIDC:

• ACDCs can be used in OAuth flows
• IPEX provides alternative to OIDC
• Compatible with existing identity infrastructure
• Provides enhanced security properties

vLEI Ecosystem:

• Production deployment by GLEIF
• Legal Entity Identifier credentials
• Role credentials (OOR, ECR)
• Hierarchical trust model

Implementation Considerations

Common Challenges

SAID Computation:

• Recursive computation requires careful ordering
• Canonical serialization must be consistent
• Placeholder replacement must be exact
• Different serialization formats require different handling

Graduated Disclosure:

• Determining appropriate disclosure level
• Managing multiple ACDC variants
• Ensuring SAID consistency across variants
• Balancing privacy and verifiability

Edge Validation:

• Validating edge operator constraints (I2I, DI2I, NI2I)
• Resolving chained credentials
• Detecting circular references
• Validating DAG structure

Schema Management:

• Ensuring schema immutability
• Managing schema versions
• Validating schema composition
• Handling schema evolution

TEL Integration:

• Anchoring credentials in TEL
• Checking credential status
• Handling revocation events
• Managing TEL state

Performance Considerations

SAID Computation Performance:

• Blake3-256 is highly optimized
• Recursive computation can be parallelized
• Caching SAIDs improves performance
• Incremental computation for large structures

Signature Verification Performance:

• Ed25519 verification is fast
• Batch verification can improve throughput
• Caching verified signatures reduces overhead
• Parallel verification of multiple signatures

KEL Resolution Performance:

• OOBI resolution can be cached
• Witness pools provide redundancy
• Watchers provide local KEL copies
• Incremental KEL updates reduce bandwidth

TEL Query Performance:

• TEL state can be cached
• Backers provide redundant TEL copies
• Incremental TEL updates reduce overhead
• Bloom filters can optimize status checks

Disclosure Performance:

• Compact variants reduce transmission size
• Graduated disclosure enables progressive loading
• Selective disclosure reduces processing overhead
• Caching disclosed variants improves performance

Best Practices

Schema Design:

• Use immutable schemas identified by SAID
• Leverage JSON Schema composition for extensibility
• Design for graduated disclosure from the start
• Include clear attribute semantics

Privacy Protection:

• Use private ACDCs (with UUID) for sensitive data
• Implement graduated disclosure strategies
• Use selective disclosure for minimal disclosure
• Apply chain-link confidentiality for legal protection

Key Management:

• Use KERI pre-rotation for quantum resistance
• Implement multi-sig for high-value credentials
• Rotate keys regularly
• Use HSMs for key protection

Credential Lifecycle:

• Register credentials in TEL immediately
• Implement revocation procedures
• Monitor credential status
• Archive revoked credentials

Verification:

• Always verify issuer's KEL state
• Check credential status in TEL
• Validate SAID integrity recursively
• Verify edge chains completely
• Validate schema compliance

Interoperability:

• Use standard schemas where possible
• Support multiple serialization formats
• Implement IPEX protocol correctly
• Provide OOBI for AID discovery
• Document custom extensions clearly