ZCAPs
Identity Protocol
Comunidade
Links
Detalhes
Licença Open source — reference implementations under various open licenses; @digitalbazaar/zcap (Node.js), ucanto (related capability work), various incremental implementations
Status de Dev 📝 Rascunho
Detalhe do Status de Dev Draft Specification / Community Group Report (W3C CCG draft; reference implementations exist; pre-W3C Recommendation track)
Proprietário W3C Credentials Community Group (CCG); editors include Manu Sporny, Christopher Lemmer Webber, others
País International (W3C)
Ano de Início 2018
Stack Specification; reference implementations primarily in JavaScript/Node.js; can be implemented in any language supporting JSON-LD and cryptographic signatures
Financiamento W3C standards process; Digital Bazaar and other CCG participants contribute development
Última Investigação 1 de jul. de 2026
Identity Protocol Atributos
Origins Capability-based security (E-language, Object Capability Model heritage); developed to provide authorization patterns compatible with W3C DIDs and VCs
Database N/A — ZCAPs are signed documents passed between parties; storage is application-level
Query Language N/A (authorization document specification)
Data Formats JSON-LD (capability documents use Linked Data Proofs / Data Integrity for cryptographic signing); verifiable proofs attached to capability invocations
Mobile Support Library-level (JavaScript implementations work on mobile via web or native bindings)
Web Support Yes (JSON-LD-based; works with browser JavaScript)
Native Apps Library-level
Terms Open standard — W3C CCG specification (Community Group output)
Funds N/A (Community Group output)
Based On Object Capability Model (OCAP); W3C DIDs (signers identified by DIDs); W3C Verifiable Credentials Data Integrity / Linked Data Proofs (signature mechanism); JSON-LD; related to but distinct from UCAN (another capability-based authorization specification)
Permissions Self — ZCAPs ARE a permissions specification (capability-based authorization); fine-grained, delegatable, auditable permissions via signed capability documents
Authentication & Identity Capability holders identified by W3C DIDs; capability invocations cryptographically signed by the invoker's key; delegation chains verified by checking signatures along the path from the original capability issuer
Storage Model N/A — capabilities are signed documents passed between parties; storage is application-level
Interoperability High — built on W3C DIDs, Linked Data Proofs, and JSON-LD; composes with W3C VCs; ecosystem-aligned with Solid, ActivityPub, and broader linked-data infrastructure
Data Portability N/A — authorization specification, not data storage
Governance & Decision Making W3C Credentials Community Group (multi-stakeholder W3C process)
Protocol Maturity / Standardization W3C CCG Draft Specification / Community Group Report (not yet on W3C Recommendation track; reference implementations exist; pre-final)
Identity Standards W3C DIDs (Decentralized Identifiers); W3C Data Integrity / Linked Data Proofs
DID Methods Supported Any DID method — ZCAPs are method-agnostic; capability invocations work with whatever DIDs the involved parties use
Key Management Inherits from associated DID method's key management; ZCAPs themselves do not manage keys
Credential Types N/A (ZCAPs are capability documents, not credentials; they compose with W3C VCs)
Verification Method Linked Data Proofs / Data Integrity — Ed25519Signature2020, EcdsaSecp256k1Signature2019, and other proof suites; signature verified using verificationMethod from the signing DID's document
Privacy Features Selective delegation (capabilities can be narrowed when delegating; original holder retains broader capability); minimal disclosure (capability invocations include only the necessary delegation chain)
Authentication Methods Capability invocation — invoker signs the action request with their DID-controlled key, attaching the capability chain that authorizes the action
Revocation Mechanism Status list capabilities (revocation lists referenced from capability documents); capability expiry (time-bounded validity); revocation by issuer through publication of revocation status
Agent Types Supported Humans, organizations, services, software agents — anything that can hold a DID can hold and invoke ZCAPs
Wallet/Client Types Any DID-aware client / wallet (no ZCAP-specific wallet type)
Recovery Mechanisms Inherits from associated DID method's recovery mechanisms
Compliance / Regulations Designed to support data sovereignty patterns relevant to GDPR (capability invocations create cryptographically auditable consent trails); not certified for specific regulations
Credential Exchange Protocols Composes with W3C VC exchange protocols (e.g. VC-API); capabilities can authorize VC issuance, verification, or holder operations
Trust Framework Capability chain — each delegation in the chain is independently verifiable through DID-based signatures; trust ultimately roots in the original capability issuer
Cost Model Free (open standard; implementation and infrastructure costs are deployment-specific)
Censorship Resistance High — capabilities are cryptographic documents that can be passed through any channel; no centralized infrastructure required for capability validity