Delegation Receipt v1 Specification (Experimental)

DID.is Delegation Receipt v1 Specification (Experimental)

5.3 DID.is Delegation Receipt v1 (Experimental Specification — DID.is Proprietary)

5.3.1 Formal Status & Standards Governance

The DID.is Delegation Receipt v1 specification is formally designated as:

Formal Status: Experimental Specification (DID.is Proprietary)
Normative Scope: Compact JWS-based capability delegation chains for autonomous AI agents, microservices, and sub-agents.
Engine Binding: Implemented in crates/resolver-core/src/delegation.rs and verified via crates/resolver-core/tests/delegation.rs.

Traditional decentralized identity and authorization standards (OAuth 2.0, GNAP, and W3C Verifiable Presentations) exhibit fundamental architectural limitations when applied to real-time autonomous AI agent execution:

1. Interactive Roundtrips: OAuth/GNAP flows require continuous network roundtrips to centralized authorization servers, introducing latency and single points of failure that break agent execution pipelines.
2. Overhead & Complexity: Standard W3C Verifiable Presentation exchanges introduce heavy JSON-LD processing, proof enveloping, and cryptographic overhead that burden lightweight microservices.
3. Lack of Compact Provenance Chaining: Existing token formats lack an immutable, lightweight parent hash-commitment mechanism capable of proving uninterrupted provenance from a human principal through enterprise organizations to ephemeral sub-agents.

DID.is designed Delegation Receipt v1 as an open, inspectable, fail-closed capability delegation protocol specifically engineered for high-throughput AI agent runtimes.

Delegation Chain Verification Flow:
  [Root Receipt (Human)] ──► [Receipt 2 (Org)] ──► [Receipt 3 (Agent)] ──► [Receipt 4 (Sub-Agent)]
  prf: NULL                 prf: SHA256(Root)     prf: SHA256(R2)          prf: SHA256(R3)
  cap: ["*"]                cap: ["db:*"]         cap: ["db:read"]         cap: ["db:read"]

5.3.2 Cryptographic Rationale & Mathematical Invariants

Delegation Receipt v1 enforces five foundational cryptographic invariants:

1. Parent Hash Chaining (prf Commitment): For every subordinate receipt link $i > 0$, the payload MUST contain a prf claim set to the hex-encoded SHA-256 digest of the immediate parent’s raw compact JWS string: $$\text{prf}i \equiv \text{hex}(\text{SHA-256}(\text{raw_compact_jws}{i-1}))$$

   • The root receipt ($i=0$) MUST NOT contain a prf claim.
   • Any tampering, payload modification, or signature re-generation in ancestor receipt $i-1$ alters its raw compact JWS bytes, causing $\text{prf}_i$ verification to immediately fail closed.
   • This prevents splice, reordering, and ancestor-substitution attacks without requiring heavy Merkle trees or interactive consensus.

2. Monotonic Capability Attenuation: Authority in an autonomous delegation hierarchy MUST strictly decrease or remain invariant as depth increases ($c \subseteq p$). Privilege expansion at any link aborts evaluation immediately with privilege escalation. Formally, let $\text{cap}_i$ be the set of capability tokens granted in link $i$. For every token $c \in \text{cap}i$, there MUST exist at least one parent token $p \in \text{cap}{i-1}$ such that $p \supseteq c$:

   • Global Wildcard: * covers all actions and all namespaces.
   • Namespace Wildcard: ns:* covers all ns:<action> tokens within namespace ns.
   • Exact Matching: action covers only identical string tokens (case-insensitive).
   • Anti-Escalation Rule: A child link declaring * when the parent declared ns:* fails evaluation.

3. Directed Acyclic Graph (DAG) Acyclicity: To prevent infinite delegation loops, recursive privilege re-inflation, and cyclic trust confusion:

   • No principal DID may appear more than once in the delegation path.
   • Self-delegation ($\text{iss} == \text{aud}$) is prohibited.
   • Any cycle detected across the chain terminates validation with Check::new("cycle", "FAIL").

4. Strict Temporal Containment: Every subordinate link must operate strictly within the operational lifetime granted by its delegator: $$[\text{nbf}i, \text{exp}i] \subseteq [\text{nbf}{i-1}, \text{exp}{i-1}]$$

   • Child $\text{nbf}i \ge \text{nbf}{i-1}$.
   • Child $\text{exp}i \le \text{exp}{i-1}$.
   • A child receipt cannot outlive its parent. Clock skew tolerance is strictly bounded to $\pm 60\text{s}$.

5. Cryptographic Verification Method Relationship Binding: Receipt signatures are evaluated using the public key bound to the delegator’s capabilityDelegation verification relationship within their resolved DID document. Signing keys belonging solely to authentication or assertionMethod are rejected.

5.3.3 JWS Envelope Format & Claims Schema

Protected JWS Header

{
  "alg": "EdDSA",
  "typ": "didis-delegation+jwt",
  "kid": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
}

• alg: MUST be a supported signature algorithm (EdDSA, ES256, ES256K).
• typ: MUST equal "didis-delegation+jwt". Standard "JWT" or "vc+jwt" tokens are rejected.
• kid: MUST be a fully qualified URI referencing the delegator’s capabilityDelegation key.

Receipt Claims Payload

{
  "iss": "did:key:z6MkRootHuman...",
  "aud": "did:key:z6MkOrgPlatform...",
  "cap": ["payments:*", "compute:execute"],
  "nbf": 1775782000,
  "exp": 1775785600,
  "jti": "urn:uuid:6c310217-1f48-4cb2-850d-d48e89843657",
  "prf": "4f9b8c03e1a7b..."
}

• iss (String, Required): DID of the delegator principal.
• aud (String, Required): DID of the delegatee principal.
• cap (Array of Strings, Required): Non-empty capability list ($1 \le |\text{cap}| \le 64$).
• nbf (Integer NumericDate, Required): Timestamp marking inception of validity.
• exp (Integer NumericDate, Required): Timestamp marking expiration ($exp > nbf$).
• jti (String, Optional): Unique identifier for audit logging and nonce tracking.
• prf (String, Conditional): Hex-encoded SHA-256 digest of the immediate parent compact JWS. Forbidden on root receipt ($i=0$); mandatory on all subordinate links ($i > 0$).

5.3.4 Execution & State Management Invariants

1. Depth Ceiling: Maximum chain length is strictly bounded to MAX_CHAIN_DEPTH = 8.
2. Stateful In-Memory & Persistent Registry:
   • resolver-core provides DelegationRegistry for tracking active delegations.
   • Zero Raw Verdict Caching: When configured with a persistent SQLite backing store (agent_delegations table), the engine persists only the raw compact JWS chain strings. Standalone verdicts are never stored.
   • Genesis Re-Verification on Startup: Upon process boot, restore_delegations() re-verifies every stored chain from cryptographic genesis. Expired, tampered, or invalid rows are immediately dropped from the database.

5.3.5 Forward Standards Roadmap (W3C CCG Submission)

DID.is is committed to open, transparent standardization. The Delegation Receipt specification follows a structured governance transition roadmap:

┌────────────────────────────────┐     ┌────────────────────────────────┐     ┌────────────────────────────────┐
│ Phase 1: Internal Validation   │ ──► │ Phase 2: Community Draft       │ ──► │ Phase 3: Formal W3C CCG Report │
│ DID.is resolver-core engine    │     │ Public CCG Draft Specification │     │ Multi-vendor interoperability  │
│ Zero-regression test harness   │     │ Open test vectors & fixtures   │     │ Ratified W3C Community Report  │
└────────────────────────────────┘     └────────────────────────────────┘     └────────────────────────────────┘

1. Phase 1 (Active): Core engine hardening and multi-language SDK client adoption (didis-client TypeScript, didis-py Python, MCP security middleware).
2. Phase 2 (Target: Q1 2027): Publication of the standalone Delegation Receipt v1: Compact Capability Chains for Autonomous Agents specification under the W3C Community Contributor License.
3. Phase 3 (Target: Q2 2027): Formal submission to the W3C Credentials Community Group (CCG) and the Decentralized Identity Foundation (DIF) Agent Auth Working Group, initiating public RFC review, cross-platform test vector exchange, and standardization track advancement.

---