ZCAP-LD

ZCAP-LD (ZCAP Linked Data) is a W3C community specification that defines a cryptographically secure, machine-readable format for expressing delegatable authorization using Linked Data principles and JSON-LD. At its core, it is a standard for creating a ZCAP (Authorization Capability), which is a digitally signed document that grants a specific party the right to perform a particular action on a protected resource. This model shifts authorization from a centralized, identity-based "who are you?" check to a capability-based "what do you possess?" verification, enabling fine-grained, auditable, and revocable access control in decentralized environments like Decentralized Web Nodes (DWNs) and Decentralized Identifiers (DIDs) ecosystems.

The specification leverages Linked Data Proofs (like Ed25519Signature2020) to create a verifiable chain of delegation. A root capability, often held by a resource controller, can be used to derive delegated capabilities for other entities, which can further delegate within the constraints of the original grant. This creates a capability chain where each link is independently verifiable. The authorization check involves cryptographically verifying the signature on the presented capability and ensuring the requested action (e.g., read, write) is within the capability's allowedAction set and that the capability's invocationTarget matches the resource being accessed.

A key architectural benefit of ZCAP-LD is its resource-centric design. Authorization is directly bound to the resource URI, not to a user's global identity. This aligns with URL-based access control and Object Capability security models, promoting the principle of least privilege. For example, a user could be granted a capability to write to a specific folder in a Decentralized Web Node without being granted broader access to the entire node or needing the node to maintain an access control list (ACL). The capability itself is the token of authority.

In practice, ZCAP-LD is foundational for protocols like Web5, where it secures interactions with Decentralized Web Nodes. Common operations include creating a capability to share a Verifiable Credential, granting write access to a decentralized data vault, or allowing an application to query a specific dataset. The capability invocation protocol typically involves an HTTP POST request where the client presents the capability in an Authorization: ZCAP-BEARER header or as a signed request body, enabling stateless and scalable authorization checks.

ZCAP-LD stands for Zero-Confirmation Authorization Protocol for Linked Data. Its etymology reveals its dual heritage. The ZCAP component originates from work on decentralized authorization, where a capability is a cryptographically secure, unforgeable token that grants specific permissions. The -LD suffix denotes its implementation using Linked Data principles, a W3C standard for publishing structured, machine-readable data on the web using JSON-LD and URIs. This combination creates a protocol for expressing and verifying authorization in a decentralized, interoperable manner.

The concept of capability-based security, the philosophical ancestor of ZCAPs, dates to research in the 1960s and 1970s on operating system design. In this model, possession of a capability token is the sole requirement to perform an action, contrasting with identity-based access control lists (ACLs). The Linked Data framework, formalized in the 2000s, provides the semantic structure, allowing capabilities to be expressed as verifiable credentials and understood across different systems without centralized coordination. ZCAP-LD synthesizes these ideas for the modern web, enabling fine-grained, delegatable authority over resources like Decentralized Identifiers (DIDs) and HTTP endpoints.

The development of ZCAP-LD is closely associated with the W3C Credentials Community Group and the Decentralized Identity Foundation (DIF). It builds directly upon the W3C Verifiable Credentials Data Model, treating a ZCAP-LD capability as a special type of verifiable credential with a specific authorization purpose. This lineage ensures it integrates seamlessly with the broader SSI (Self-Sovereign Identity) stack, providing a standardized mechanism for actions like "this DID is authorized to update this document" or "delegate access to this API."

A key innovation in ZCAP-LD's design is its use of cryptographic suites and linked data proofs for signing and verification. This allows the protocol to be algorithm-agile, supporting various signature types like Ed25519Signature2020 or JsonWebSignature2020. The LD-Proofs format ensures the capability's integrity and authenticity are cryptographically bound to its Linked Data structure, making it both a machine-readable document and a secure token. This makes ZCAP-LD a core primitive for building decentralized web applications (DApps) and secure service meshes where trust is not centralized.

In practice, ZCAP-LD enables use cases like delegatable API keys, where a service can issue a capability to a client, which can then be attenuated (have its permissions reduced) and delegated to another party without the original issuer's involvement. Another critical application is in encrypted data vaults, such as those specified by the DIF Secure Data Store standard, where ZCAP-LD defines who can read, write, or share stored data. Its origin in combining proven security models with modern web standards positions it as a foundational protocol for the permissioned, user-centric web.

At its core, ZCAP-LD is a Linked Data specification that defines a structured format for creating, signing, and verifying capability tokens. A capability is a JSON-LD object containing a unique identifier (id), the authorized action (invocationTarget), the cryptographic proof of authorization (proof), and the chain of allowed delegates (parentCapabilityId). The proof is typically a digital signature from the capability's issuer, making the token a self-contained, verifiable credential. This structure allows any service, or invocation target, to validate a request's authorization by checking the token's cryptographic proof and delegation chain without needing to query a central authority.

The protocol's power lies in its delegation model. The holder of a ZCAP-LD token can create a new, more restricted capability and delegate it to another party. This creates a verifiable chain of authority, where each link is cryptographically signed. For example, a user (root controller) could grant an application a capability to read their data, and that application could then delegate a time-limited, read-only sub-capability to an analytics service. The final service can validate the entire chain back to the original root controller to ensure the request is legitimate. This enables complex, decentralized workflows without centralized permission servers.

ZCAP-LD integrates with Decentralized Identifiers (DIDs) and Verifiable Credentials to establish cryptographic accountability. The controller of a capability is often a DID, linking the authorization directly to a decentralized identity. When a capability is invoked, the verifier checks the signature against the controller's public key, which is resolved from its DID document. This creates a secure, SSI (Self-Sovereign Identity)-native authorization system where permissions are bound to identities, not accounts. It is particularly suited for decentralized web (Web5) architectures, enabling user-centric control over data sharing and API access across different domains and services.

The ZCAP-LD flow begins with a root capability, a cryptographically signed Linked Data document that grants a specific authority—such as the right to update a decentralized identifier (DID) document or access a resource. This root capability is created by the controller, the entity with ultimate authority over the resource. The capability's invocationTarget specifies the resource (e.g., a URL), its proof contains the controller's digital signature, and its expires field sets a validity period, establishing a secure, machine-readable grant of authority.

A key power of ZCAP-LD is delegation, where a holder of a capability can create a new, derived capability for another party. The delegator signs the new capability, which includes a parentCapabilityId linking it back to the chain of authority. This creates a verifiable delegation chain without requiring the original controller's involvement for each new grant. Delegation can be constrained using properties like allowedAction to limit permissions or a different expires date, enabling fine-grained, decentralized access management.

To invoke the capability, the holder presents it along with an invocation proof—a signature created using a secret key associated with the capability's proof method—to the verifier (e.g., a server or smart agent). The verifier performs a multi-step check: it validates the invocation signature, verifies the chain of signatures back to a trusted root capability, and ensures the request's action matches the allowedAction and that the capability hasn't expired. This process authorizes the action without revealing user identities or relying on a central auth server.

The final stage is continuation, where the verifier, after successful invocation, may return a new capability for a subsequent related action. For example, after authorizing a payment, a server might issue a capability to check the payment's status. This creates a stateful, capability-driven session, allowing a series of authorized interactions to flow securely from one delegated right to the next, all auditable via the cryptographic chain.