ACDC (Authentic Chained Data Containers)
Protocolo de Identidad
Comunidad
Detalles
Licencia Open source — Apache 2.0 for code; OWF Contributor License Agreement 1.0 for specification text; canonical specification repository at github.com/trustoverip/kswg-acdc-specification; reference implementations available across the WebOfTrust GitHub organization
Estado de Desarrollo 🟢 Activo
Detalle del Estado de Desarrollo Released / Active — v1.1 specification published; IETF Internet-Draft active (draft-ssmith-acdc-03); production-deployed via GLEIF vLEI; reference implementations in multiple languages; ongoing refinement through the KSWG. Note: the original TSS0033 ToIP draft repository (2021) is archived; canonical work continues at trustoverip/kswg-acdc-specification
Propietario Samuel Smith (Prosapien) — primary author; Philip Feairheller (GLEIF) — co-author; Kevin Griffin (GLEIF) — editor; co-incubated at Trust Over IP Foundation via the KERI Suite Working Group (KSWG); IETF Internet-Draft track. Contributors include Nuttawut Kongsuwan, Henk van Cann (Blockchainbird), and Kor Dwarshuis (Blockchainbird)
Órgano de Gobierno ToIP / LF Decentralized Trust (KERI Suite Working Group) | IETF (Internet-Draft process, draft-ssmith-acdc)
Órgano de Gobierno - Lista
- Internet Engineering Task Force
- Trust Over IP Foundation
País International specification development (United States lead authorship — Samuel Smith / Prosapien; Philip Feairheller / GLEIF — international); ToIP is internationally chartered; IETF is internationally chartered
Año de Inicio 2020
Stack Specification document (Spec-Up-T markdown source); JSON Schema 2020-12 dialect for ACDC schemas; CESR (Composable Event Streaming Representation) for native wire format; reference implementations in Python (keripy / signify-py); TypeScript (signify-ts); additional language implementations under the WebOfTrust organization
Financiamiento GLEIF (Global Legal Entity Identifier Foundation) for vLEI production deployment funding; ToIP Foundation member organizations; Prosapien and other commercial implementers; DARPA funded early KERI research that ACDC builds on; HealthKERI for healthcare-sector deployment work
Última Investigación 1 jul 2026
Protocolo de Identidad Atributos
Orígenes Self-sovereign identity and verifiable credentials (designed as a variant of W3C Verifiable Credentials addressing perceived limitations); supply chain provenance; delegated authorization chains; emerged from Samuel Smith's broader KERI ecosystem work as the credential and attestation layer atop KERI's identifier substrate; co-evolved with GLEIF's vLEI program for verifiable Legal Entity Identifiers
Base de Datos N/A — ACDC is a credential format specification; persistence is implementation concern. Reference implementations typically use LMDB for KERI key event log storage and transaction event log (TEL) state; the ACDC specification itself mandates no backend
Lenguaje de Consulta N/A — ACDC is a credential format; lookups are by SAID (content-addressable) or by edge traversal in the chained graph; no query language defined in the specification
Formatos de Datos Multiple supported serializations — JSON (most common in examples), CBOR, MGPK (MessagePack), and CESR (KERI's native composable wire format optimized for both text and binary with lookahead streaming properties). Schemas use JSON Schema 2020-12 dialect with composable oneOf operators. All serializations are content-addressed via SAIDs. Each ACDC is internally structured as ordered field maps with top-level fields v (version), t (message type), d (SAID), u (UUID), i (issuer AID), rd (registry SAID), s (schema), a/A (attribute/aggregate section), e (edge section), r (rule section)
Soporte Móvil Yes — signify-ts targets browser and mobile JavaScript environments; KERIA-based agents are designed for cloud or mobile deployment with edge agents (Signify) for constrained devices; reference implementations support standard JavaScript and Python mobile environments
Soporte Web Yes — signify-ts for browser JavaScript; KERIA agents expose HTTP-based interfaces; ACDCs are designed for web-deliverable verifiable credentials
Aplicaciones Nativas Yes — wallet and agent implementations exist via KERIA and various commercial offerings in the ToIP and GLEIF vLEI ecosystem (ProSapien, Provenant, others); GLEIF tooling for vLEI credential lifecycle management
Términos Open Source / Free — OWF Contributor License Agreement 1.0 for specification text; Apache 2.0 for source code
Fondos Not separately disclosed at the specification level; GLEIF's vLEI program represents the largest concrete funding stream for KERI/ACDC infrastructure (vLEI deployment funded through GLEIF's operational budget for the global LEI ecosystem)
Basado En Built on KERI (Key Event Receipt Infrastructure) for identifier and key state substrate; built on SAID (Self-Addressing Identifier) specification for content-addressable digests; built on CESR (Composable Event Streaming Representation) for native wire format; complemented by IPEX (Issuance and Presentation Exchange Protocol), OOBI (Out-Of-Band Introductions), did:keri DID method, and Transaction Event Logs (TELs) for revocation state; variant of W3C Verifiable Credentials data model; JSON Schema 2020-12 for schemas; influenced by Ricardian Contracts pattern for the rules section
Órgano de Gobierno - Lista
- Internet Engineering Task Force
- Trust Over IP Foundation
Permisos Capability-style authorization expressed through chained ACDCs — each ACDC in a chain may delegate or attenuate authority to its issuee, who may then issue further ACDCs downstream. Delegation chains are end-verifiable from any leaf back to a root of authority. Rules section (r field) carries Ricardian contractual obligations binding to the credential. Chain-Link Confidentiality enforces permission rules cryptographically across the disclosure chain. Multi-signature thresholds at the AID level for multi-party permission
Autenticación e Identidad ACDC issuance and presentation are authenticated through KERI-anchored AID signatures. The Issuer AID (`i` field) is a KERI Autonomic Identifier whose control authority is established via KERI's verifiable Key Event Log. Verification of any ACDC requires verifying the Issuer's KEL key state at the time of issuance, then verifying the digital signature on the ACDC's SAID. For Targeted ACDCs (with an Issuee AID in the attribute section), the Issuee can also make non-repudiable commitments to the credential, enabling provable disclosure by the holder
Modelo de Almacenamiento Per-issuer Key Event Log (KEL) maintained by the issuer's KERI infrastructure; per-credential registry state in Transaction Event Logs (TELs) for issuance, revocation, transfer, and retraction events; ACDC documents themselves are content-addressable via their SAIDs and may be stored anywhere (cached, attached, or distributed); chained edges reference other ACDCs by SAID enabling fragment-by-fragment graph distribution
Interoperabilidad High within the KERI ecosystem — composes natively with KERI identifiers, did:keri, CESR wire format, IPEX presentation protocol, and OOBI discovery. Optional interoperability with W3C VC ecosystem (ACDC is positioned as a VC variant; JSON serialization can be processed by VC tooling). Compatible with W3C DIDs via did:keri or did:webs. Bridges to other DID methods feasible through KERI-based attestation. ACDCs are explicitly designed to be portable across trust domains without shared trust assumptions between Controllers and Verifiers
Portabilidad de Datos High — ACDCs are content-addressable (via SAID), self-contained, and verifiable without online lookup once the issuer's KEL state is established. Credentials portable across any infrastructure that supports KERI verification. Multiple serialization formats (JSON, CBOR, MGPK, CESR) enable cross-platform exchange. Chained edges reference other ACDCs by SAID, so partial graph fragments can be exchanged without exposing the full chain
Gobernanza y Toma de Decisiones Trust Over IP Foundation stewardship via the KERI Suite Working Group (KSWG); IETF Internet-Draft process for formal standardization; Samuel Smith (Prosapien) as primary author and technical lead; multi-stakeholder editorial group including GLEIF, Blockchainbird, and others; specification developed via the trustoverip/kswg-acdc-specification GitHub repository with public pull-request process; production deployment governance handled by GLEIF for the vLEI ecosystem
Madurez del Protocolo / Estandarización Released / Production-active — v1.1 specification published; IETF Internet-Draft active (draft-ssmith-acdc-03); GLEIF vLEI is the largest concrete production deployment; multiple reference implementations mature; ongoing standardization through ToIP KSWG; pre-IETF-final but with substantial real-world adoption ahead of formal RFC publication
Estándares de Identidad KERI (identifier substrate); SAID (content-addressable identifiers); CESR (wire format); did:keri DID method; W3C Verifiable Credentials (as a variant); W3C DIDs (composable via did:keri); JSON Schema 2020-12. Composable with ToIP's Trust Spanning Protocol and Trust Registry Query Protocol
Estándares de Identidad - Lista
Métodos DID Soportados Native: did:keri (primary, KERI-anchored). Compatible: did:webs (web-anchored KERI variant); ACDCs can reference any DID method as an identifier value, but verifiable trust semantics depend on the KERI substrate. Other DID methods may appear in ACDC content but their key state verification is delegated to their respective resolvers
Gestión de Claves Inherited from KERI — pre-rotation key management (next key committed in advance via hash, eliminating the rotation vulnerability window); multi-signature thresholds for multi-party control; delegated identifiers for hierarchical key management; post-quantum secure when paired with post-quantum signature algorithms. ACDC issuance is bound to the issuer's KERI key state at time of signing
Tipos de Credenciales ACDC variants — Public, Private, Metadata, Compact, Uncompacted, Targeted, Untargeted, Bespoke. Variants are determined by the presence or absence of UUID (u), Issuee (i), and field expansion state. Public ACDCs allow rainbow-table attacks on schema-known fields; Private ACDCs include high-entropy UUIDs that blind contents. Targeted ACDCs have an Issuee AID enabling delegation chains; Untargeted ACDCs provide verifiable authorship attestations without a specific recipient. Metadata ACDCs enable contractually-protected pre-disclosure negotiation. Bespoke ACDCs are disclosure-specific issuances bound to particular disclosure events
Tipos de Credenciales - Lista
Método de Verificación Multi-step — (1) verify the Issuer's KERI Key Event Log to establish their current key state; (2) verify the ACDC's digital signature against that key state; (3) verify the ACDC's SAID against its content (digest equivalence); (4) verify the schema SAID against the ACDC's structure (JSON Schema validation); (5) traverse the edge graph to verify any chained ACDCs recursively; (6) check the Transaction Event Log (TEL) for issuance/revocation state. Verification is end-verifiable and does not require trusted intermediaries
Funciones de Privacidad Comprehensive multi-layer privacy model. Graduated Disclosure: Compact ACDCs hide field contents behind SAIDs; Private ACDCs use high-entropy UUIDs to blind contents; Partial Disclosure exposes some sections while hiding others; Selective Disclosure (via the Aggregate section A field) discloses individual attributes from a blinded aggregate without revealing others; Contractually Protected Disclosure binds the discloser and disclosee to terms-of-use before any disclosure occurs (via the Metadata ACDC pattern). Chain-Link Confidentiality protects against unpermissioned downstream sharing through cryptographic chain rules. Pairwise AIDs supported for unlinkability across relationships. Bulk-issued credentials with independent registries minimize correlation
Métodos de Autenticación KERI AID signature-based — Issuer signs the ACDC with the private key corresponding to the current key state in their KEL; Issuee can counter-sign via their own AID for offer/agreement flows. IPEX (Issuance and Presentation Exchange Protocol) defines the message exchange patterns for offer, agreement, issuance, and presentation. Mutual authentication via paired AID interactions. Out-Of-Band Introductions (OOBI) provide identifier discovery
Mecanismo de Revocación Transaction Event Log (TEL) registries — each ACDC's `rd` field references a TEL registry that maintains dynamic state for the credential including issuance, revocation, transfer, and retraction events. TEL events are anchored in the issuer's KEL, providing non-repudiable state transitions. Supports both blindable (privacy-preserving) and public TEL updates. Ledger-less — no on-chain revocation lookup required; verifiers consult the TEL referenced by the credential
Tipos de Agentes Soportados Humans, organizations (notably Legal Entities via vLEI), services, devices, sensors, IoT endpoints, software agents — any entity capable of controlling a KERI AID can issue or hold ACDCs. GLEIF's vLEI program uses ACDCs for Legal Entity-issued credentials at production scale. Untargeted ACDCs enable sensor and observation-source attestations. Targeted ACDCs support delegation chains where issuees become issuers downstream
Tipos de Billetera/Cliente KERIA-based cloud agents; Signify edge agents (mobile/browser via signify-ts and signify-py); GLEIF vLEI tooling (issuer wallets, QVI wallets, holder wallets); commercial wallets from ProSapien, Provenant, and other ToIP ecosystem implementers; reference implementations across the WebOfTrust GitHub organization
Mecanismos de Recuperación Inherited from KERI — pre-rotation provides built-in single-key-compromise recovery (rotate to the pre-committed next key); multi-signature thresholds for multi-party control with partial-key-loss tolerance; delegated identifiers enable hierarchical recovery via parent controller. Credential-level: revoked credentials can be reissued under new ACDC SAIDs anchored to the recovered key state
Cumplimiento / Regulaciones GLEIF vLEI alignment with global Legal Entity Identifier regulatory framework; eIDAS 2.0 alignment work ongoing through ToIP and partner organizations; GDPR-compliant by KERI's non-intertwined identifier trust bases (true forgetting possible per-identifier); financial sector use cases via vLEI for KYC and trade finance; healthcare sector via HealthKERI; compliance posture is deployment-specific
Protocolos de Intercambio de Credenciales IPEX (Issuance and Presentation Exchange Protocol) — KERI's native protocol for issuance, offer, agreement, presentation, and revocation message exchange; CESR-streamed message exchange; mailbox-based asynchronous delivery; compatible with DIDComm for protocol-level interop with the broader SSI ecosystem; OOBI for identifier discovery
Protocolos de Intercambio de Credenciales - Lista
Marco de Confianza Trust Over IP Foundation (KERI Suite Working Group); GLEIF vLEI Ecosystem Governance Framework for production legal-entity credential use; composable with ToIP's Trust Spanning Protocol and Trust Registry Query Protocol; supports nested Ecosystem Governance Frameworks (EGFs) for application-domain-specific credential rules; the Rules section (r field) of each ACDC carries Ricardian contract terms binding the credential to specific governance
Modelo de Costos Specification is free; reference implementations are open-source; operational costs are deployment-specific (issuer KEL infrastructure, witness/watcher networks, TEL hosting, agent hosting); ledger-less design avoids on-chain transaction fees. Commercial offerings from ProSapien, Provenant, and others price their own deployment infrastructure
Resistencia a la Censura High — ACDCs inherit KERI's ledger-less trust model. Issuers can move witness sets and TEL registry hosts if adversarial; credentials remain verifiable as long as the issuer's KEL and the relevant TEL state are reachable through any chosen witness or replica. No global gatekeeper for credential issuance or verification
Relaciones
Cómo se conecta esta herramienta con otras herramientas y organizaciones, según relaciones revisadas por el responsable de datos de OpenHaven. Describen cómo se conectan los proyectos, no su calidad.
- Administrado por
- Internet Engineering Task Force
- Trust Over IP Foundation
- Almacena en
- Construido sobre
- Estandarizado en
- Internet Engineering Task Force
- Habla el protocolo
- Miembro de la suite
- KERI Suite
- Puente hacia
- Requiere
- Interopera con
- Protocolo hablado por