Delegation Receipts v1

7. Delegated Authority & Delegation Receipts

The Autonomous Delegation Challenge

In multi-agent architectures, an enterprise or user must delegate restricted authority to an orchestrator agent, which may further delegate a sub-task to a worker agent. Passing master API keys across agent boundaries is catastrophic.

To solve this, DID.is implements Delegation Receipt v1—an open, cryptographically verifiable, multi-hop delegation protocol.

DID.is Delegation Receipt v1 Specification

A delegation receipt is a compact JWS signed by the delegator:

• Header:

  {
    "alg": "EdDSA",
    "typ": "didis-delegation+jwt",
    "kid": "did:web:enterprise.example#key-1"
  }

• Payload:

  {
    "iss": "did:web:enterprise.example",
    "aud": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
    "cap": ["payments:refund", "reports:read"],
    "nbf": 1790000000,
    "exp": 1790003600,
    "prf": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  }

Multi-Hop Chain Verification Rules

When evaluating a delegation chain, DID.is enforces five mathematical constraints:

[ Root Issuer DID ] ──(Receipt 1: "payments:*")──► [ Orchestrator DID ] ──(Receipt 2: "payments:refund")──► [ Worker DID ]
prf: null                                           prf: SHA-256(Receipt 1)

1. Proof-of-Receipt Hash Chaining (prf):
   • The Root Receipt must have prf: null.
   • Every subsequent child receipt must contain a prf claim exactly equal to the hexadecimal SHA-256 digest of the compact JWS string of its immediate parent receipt.
2. Capability Delegation Key Binding:
   • Each receipt must be signed by a verification method listed in the issuer’s capabilityDelegation relationship.
3. Monotonic Capability Attenuation:
   • A child can only restrict or match capabilities, never expand them.
   • Example: * $\rightarrow$ payments:* $\rightarrow$ payments:refund is VALID.
   • Attempting payments:refund $\rightarrow$ payments:* immediately fails with CAPABILITY_EXPANSION.
4. Time Window Containment:
   • The child receipt’s nbf (not before) and exp (expiration) must lie entirely within the parent’s validity window.
5. Strict Acyclicity & Depth Limits:
   • No DID may appear more than once in a chain (prevents loops).
   • Maximum chain depth is bounded to 8 links.

Tool Authorization & Execution Engine

Using the /v1/agents/authorize API or the Delegation Workspace UI:

• Submit a delegation chain alongside a requested action (e.g., tool: "payments:refund").
• DID.is checks if the leaf agent possesses valid authorization derived from an unbroken chain back to an authorized root.
• Returns a deterministic ALLOW or DENY decision.

Persistent Registered Chains (verify-tool)

When registering chains via /v1/agents/verify-delegation with register: true:

• Valid chains are saved in SQLite (schema v15 registered_delegations).
• Downstream systems can query GET /v1/agents/verify-tool?agent=<did>&tool=<name> for instantaneous authorization without re-transmitting receipt chains.
• Default policy is strictly DENY. Chains that expire or fail validation upon resolver restart are automatically purged.

In-Browser WebCrypto Demo Chain Generator

The Delegation Workspace features a built-in cryptographic simulator:

• Generates 4 distinct Ed25519 did:key identities locally in your browser using the W3C WebCrypto API:
  1. Human Executive (Root)
  2. Enterprise Gateway (Intermediate 1)
  3. AI Orchestrator (Intermediate 2)
  4. Specialized Worker (Leaf Agent)
• Signs compact JWS receipts, links SHA-256 prf hashes, attenuates capabilities, and submits the chain to the engine.
• Zero Key Egress: All private signing keys exist exclusively in browser RAM and are never transmitted over the network.

---