Tags: Data Model, Permanent Data

Although related, this concept is different from hm://z6MkuBbsB1HbSNXLvJCRCrPhimY6g7tzhr4qvcYKPuSZzhno/definitions/object-capability.

Strictly speaking our capabilities are not really Object Capabilities, they are more like Certificate Capabilities.

In a true OCAP system, authority is just possession. If you hold the capability, you can use it. There are no identities and no signatures — it’s a runtime concept.

Our system works across processes and machines, so we can’t rely on object references. Instead, we use signed certificates — similar to UCAN, SPKI/SDSI, ZCAP-LD, and similar systems, but simpler and tightly scoped to our needs.

Each certificate says: this identity is allowed to do X on resource Y, under these constraints.

The "to do X" part in our system is defined by a coarse-grained role concept, not fine-grained permissions.

An unforgeable token that grants access to some data of one Account, the Issuer, to another Account, the Delegate. The Issuer’s private key signs the capability. The Delegate’s private key must sign anything that uses the capability and include its Public Key so it can be verified by others.

Pseudocode

type Role = "reader" | "writer" | "admin";

interface CapabilityCertPayload {
  iss: string;      // issuer identity (DID / public-key id)
  sub: string;      // subject identity (who gets the rights)
  res: string;      // resource identifier (space, doc, bucket, etc.)
  role: Role;       // coarse-grained role
  exp: number;      // expiration timestamp (unix seconds)
  constraints?: {
    ipAllowlist?: string[];
    maxUses?: number;
    // any other custom constraints
  };
}

interface SignedCapabilityCert {
  payload: CapabilityCertPayload;
  signature: string;   // base64-encoded signature over `payload`
}