Network Working Group R. Nelson Internet-Draft Authproof Intended status: Informational 9 October 2026 Expires: 12 April 2027 Agent Delegation Receipts draft-nelson-agent-delegation-receipts-11 Abstract This document defines the Agent Delegation Receipt: a signed record of what a human principal authorized an AI agent to do, for how long, and under what instructions. The receipt carries a scope, hard boundaries, a validity window, and a hash of the operator's stated instructions, all signed by the authorizing key. Version -11 replaces the draft's earlier custom signature format with two standard profiles: a JWS profile (RFC 7515) over JCS-canonicalized JSON (RFC 8785) as the primary wire format, and a COSE_Sign1 profile (RFC 9052) for constrained environments. It also specifies scope attenuation rules for multi-agent delegation chains, a revocation registry model with cascade semantics, and the limitations of what receipts can and cannot prove. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Nelson Expires 12 April 2027 [Page 1] Internet-Draft Agent Delegation Receipts October 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements language . . . . . . . . . . . . . . . . . . 4 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Relationship to Existing Work . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4. Receipt Data Model . . . . . . . . . . . . . . . . . . . . . 7 4.1. Design . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Required fields . . . . . . . . . . . . . . . . . . . . . 8 4.3. Optional fields . . . . . . . . . . . . . . . . . . . . . 9 4.4. Attached and derived values . . . . . . . . . . . . . . . 10 4.5. The scopeSchema object . . . . . . . . . . . . . . . . . 11 5. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 11 6. JWS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Protected header . . . . . . . . . . . . . . . . . . . . 12 6.2. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Compact serialization . . . . . . . . . . . . . . . . . . 12 6.4. Detached serialization . . . . . . . . . . . . . . . . . 13 6.5. Algorithm registry . . . . . . . . . . . . . . . . . . . 13 6.6. Receipt identifier . . . . . . . . . . . . . . . . . . . 14 7. COSE Profile . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Scope Model and Attenuation Rules . . . . . . . . . . . . . . 14 8.1. Structured scopes . . . . . . . . . . . . . . . . . . . . 15 8.2. Wildcard matching . . . . . . . . . . . . . . . . . . . . 15 8.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . 15 8.4. Text scope is advisory . . . . . . . . . . . . . . . . . 15 8.5. Attenuation rules . . . . . . . . . . . . . . . . . . . . 15 8.6. Depth limit . . . . . . . . . . . . . . . . . . . . . . . 16 8.7. Sub-receipt issuance . . . . . . . . . . . . . . . . . . 16 9. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Registry model . . . . . . . . . . . . . . . . . . . . . 17 9.2. Revocation record . . . . . . . . . . . . . . . . . . . . 17 9.3. Cascade revocation . . . . . . . . . . . . . . . . . . . 18 9.4. Offline behavior . . . . . . . . . . . . . . . . . . . . 18 9.5. One-time-use receipts . . . . . . . . . . . . . . . . . . 18 10. Implementation Profile: Pre-Execution Verification . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 Nelson Expires 12 April 2027 [Page 2] Internet-Draft Agent Delegation Receipts October 2026 11.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 20 11.2. Limitations . . . . . . . . . . . . . . . . . . . . . . 21 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 14. Explicit Out-of-Scope . . . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 24 Appendix A. Worked Example . . . . . . . . . . . . . . . . . . . 25 A.1. The receipt (presentation form) . . . . . . . . . . . . . 25 A.2. JCS canonical form . . . . . . . . . . . . . . . . . . . 26 A.3. JWS compact serialization (ES256) . . . . . . . . . . . . 27 A.4. Detached form (RFC 7797) . . . . . . . . . . . . . . . . 27 A.5. Example key (DO NOT USE) . . . . . . . . . . . . . . . . 27 Appendix B. Changes from -08 to -11 . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction AI agents act on behalf of people using natural language instructions as their working orders. The person who is supposed to be in charge writes or approves a scope. The operator who runs the deployment delivers the actual instructions to the agent at runtime. Nothing in that pipeline is cryptographic, so when the agent does something the person did not want, there is no reliable record of what was authorized versus what was delivered. This document specifies the Delegation Receipt, a signed authorization artifact that closes that gap on paper. Before an agent acts, the authorizing key signs a receipt body containing the scope, the boundaries, the validity window, and a hash of the operator's stated instructions. Any later deviation between the committed instructions and the delivered instructions is detectable by recomputing a hash. The receipt is a small, self-contained, verifiable claim: this key authorized this scope for this agent during this window under these instructions. Two things this document is not. It is not a control that stops a malicious operator. An operator who controls the runtime can simply not run the checks, and no signature prevents that. The receipt is an audit and attribution layer for honest deployments: it makes misbehavior provable after the fact, not impossible. Readers who need that distinction spelled out will find it in Section 11. It is also not a new cryptographic invention. Earlier versions of this draft defined a custom signature over non-canonical JSON, which was a mistake: it made every implementation a snowflake and made interop with anything else needless work. Version -11 fixes that by Nelson Expires 12 April 2027 [Page 3] Internet-Draft Agent Delegation Receipts October 2026 defining the receipt as a standard JWS (with a COSE alternative), canonicalized per RFC 8785. The receipt format is deliberately boring now, so that verifying it can be done with libraries that already exist. This draft sits alongside, not against, neighboring work. Google's AP2 defines signed mandates for agent payments. Decagon's PACT defines signed delegation tokens and per-reply receipts for personal agents. ERC-8004 defines on-chain registries for agent identity, reputation, and validation. UCAN defines capability tokens with delegation chains. Where the terminology lines up, this document uses the shared terms; where this draft deliberately differs, it says so plainly. See Section 2.3. 2. Terminology 2.1. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Definitions *Delegation Receipt:* A signed authorization object produced before an agent acts. It binds a scope, boundaries, a validity window, and a hash of the operator's stated instructions to the authorizing key's signature. *Receipt Body:* The JSON object that is canonicalized and signed to produce a Delegation Receipt. It contains every field listed in Section 4 except the signature values themselves. *User (Principal):* The human principal whose authority is being delegated. The User's private key is the signing authority for root Delegation Receipts. *Operator:* The party that builds and deploys the agent. The Operator delivers instructions to the agent at runtime and is bound by the instruction hash committed in the receipt. *Agent:* The AI system taking actions on behalf of the User. In deployments that enforce this specification, the Agent presents a valid Delegation Receipt before executing an action. Nelson Expires 12 April 2027 [Page 4] Internet-Draft Agent Delegation Receipts October 2026 *Orchestrator:* In a multi-agent delegation, the agent (or its controlling key) that issues a sub-receipt to a downstream agent. The Orchestrator signs the sub-receipt and the delegation binding. *Scope:* The set of operations an agent is authorized to perform, expressed either as free text (advisory) or as a structured scopeSchema (machine-enforceable). See Section 8. *Boundaries:* Prohibitions embedded in a Delegation Receipt that survive any later operator instruction. Boundaries MUST NOT be waived by the Operator. *Instruction Hash (instructionsHash):* The SHA-256 digest of the Operator's stated instructions at delegation time, after text normalization (Section 4.2). Recomputing it at execution time detects operator instruction drift. *Time Window (timeWindow):* The validity interval of the receipt, as an object with "start" and "end" ISO 8601 timestamps. *Sub-Receipt:* A Delegation Receipt issued by an Orchestrator to a downstream agent. It carries "parentReceiptId" in its signed body and an "orchestratorSignature" binding it to the parent. *Delegation Chain:* A root receipt plus zero or more sub-receipts linked by parentReceiptId, each hop narrowing scope. The root is at depth 0. *Revocation Registry:* An append-only store of signed revocation records, consulted before execution. Revocations are permanent. *Verifier:* The component that checks a receipt (signature, revocation, time window, scope, instruction hash, and chain integrity) before an action executes. 2.3. Relationship to Existing Work This section maps this document's terms to neighboring specifications where the mapping is clean, and states plainly where this draft deliberately differs. Claims about peer specifications that were not verified against the peer's own published text are marked (unverified). *AP2 (Google Agent Payments Protocol).* AP2's "mandate" is the closest conceptual relative of this document's Delegation Receipt: a signed, user-authorized record of what an agent may do. AP2 expresses mandates as SD-JWT verifiable credentials and chains them for delegation (open mandates signed by the user, closed mandates Nelson Expires 12 April 2027 [Page 5] Internet-Draft Agent Delegation Receipts October 2026 signed by the agent). This draft adopts "mandate" as an accepted synonym for a Delegation Receipt where the payment context applies. The deliberate difference: AP2 is scoped to payments and commerce and produces pre-transaction authorization evidence. This draft's receipt is a general-purpose authorization and audit artifact that covers arbitrary agent actions, and deployments pair it with a signed log of what was actually done. (AP2 chain details summarized from third-party technical write-ups; the AP2 specification text itself was not directly reviewed for this draft: unverified.) *PACT (Decagon Personal Agent Consent & Trust Protocol).* PACT defines businesses issuing signed delegation tokens to personal agents over OAuth 2.0 and A2A, with a signed receipt on every reply. PACT's per-reply receipt is a compact JWS carrying grant, user, agent, brand, scopes-used, and action claims. This draft's JWS profile (Section 6) is intentionally compatible in shape with that approach: a compact JWS over a JSON claim set. The deliberate difference: PACT is a consent protocol between a customer, a personal agent, and a business, with short-lived tokens (delegation tokens valid at most an hour, request JWTs at most five minutes). This draft covers user-to-operator delegation with longer windows and adds the pre-execution gate, scope attenuation across agent-to-agent hops, and cascade revocation, which PACT's published material does not define (PACT claim names and lifetimes summarized from an independent spec teardown; the normative PACT text was not directly reviewed: unverified). *ERC-8004 ("Trustless Agents").* ERC-8004 defines three on-chain registries: Identity (ERC-721 based agent identifiers), Reputation (feedback signals), and Validation (third-party verification of work). This draft uses "registry" in the same spirit for its revocation registry (Section 9), but the two are different layers: ERC-8004 standardizes who an agent is and what others say about it; this draft standardizes what a specific key authorized a specific agent to do. They are complementary, not overlapping. *UCAN (User Controlled Authorization Networks).* UCANs are capability tokens (JWTs binding issuer to audience) with "prf" proof chains and attenuation semantics: each delegation may only narrow the capabilities of its parent. This draft's delegation chain and scope attenuation rules (Section 8) follow the same principle, and this document uses "attenuation" in UCAN's sense. The deliberate difference: UCAN is a general capability-token format; this draft adds the receipt-as-audit-trail (instruction pinning, signed action log, revocation registry), which UCAN does not define. (UCAN field details summarized from secondary write-ups; the UCAN specification has been stale since March 2024: unverified.) Nelson Expires 12 April 2027 [Page 6] Internet-Draft Agent Delegation Receipts October 2026 *W3C Verifiable Credentials.* AP2's mandates are expressed as SD-JWT VCs. This draft does not use the VC data model: a Delegation Receipt is a JWS (or COSE) over a fixed claim set, not a credential with selective disclosure. Deployments that need selective disclosure should use AP2's mandate format for the payment portions of a workflow and this draft's receipt for the general authorization record. *IETF drafts.* Two individual drafts cover adjacent ground: draft- liu-agent-operation-authorization (verifiable human delegation of specific operations to AI agents) and draft-mishra-oauth-agent-grants (Delegated Agent Authorization Protocol: persistent agent identity, multi-agent delegation, tamper-evident audit). Both are cited informatively; neither was reviewed in full for this revision (unverified). What this draft does NOT claim: wire-format interoperability with any of the above. No adapter between this draft's receipt format and AP2, PACT, UCAN, or agent-passport Action Receipts has been built or verified. Terminology alignment is not interoperability, and this document does not present it as such. 3. Problem Statement Agentic deployments separate the authority to act from the instructions that drive action. The User approves a scope. The Operator writes the prompts, configures the tools, and runs the runtime. Between those two sits a gap: the authorization the User believes they granted and the instructions the Operator actually delivered. Prompt injection, instruction drift, silent scope widening, and model substitution all live in that gap, and none of them leave a cryptographic trace in a conventional deployment. The Delegation Receipt puts a signed artifact in the gap. It commits the User's scope, boundaries, validity window, and the hash of the Operator's stated instructions under the User's key before the agent runs. After the fact, anyone holding the receipt can answer three questions without trusting the Operator: what was authorized, what instructions were committed, and whether the instructions delivered at runtime match the commitment. What it cannot do is force a dishonest Operator to check. Section 11 states that limit without hedging. 4. Receipt Data Model Nelson Expires 12 April 2027 [Page 7] Internet-Draft Agent Delegation Receipts October 2026 4.1. Design A Delegation Receipt is a JSON object [RFC8259]. The receipt body is the set of fields defined in Sections 4.2 and 4.3. The signature values defined in Section 4.4 are attached to the receipt but are NEVER part of the signed body: the JWS or COSE signature is computed over the canonicalized body alone. Every field name below is REQUIRED to appear exactly as written (case-sensitive). Implementations MUST ignore unknown fields in the body when verifying, but MUST NOT include them in any canonicalized signing input they produce (unknown fields are dropped before canonicalization). Field types: "string", "boolean", "object", "array of string", "ISO 8601" (a string in RFC 3339 / ISO 8601 UTC form, e.g. "2026-10-09T12:00:00.000Z"), "hex64" (64 lowercase hex characters, a SHA-256 digest), and "JWK" (a JSON Web Key object [RFC7517]). 4.2. Required fields delegationId (string, REQUIRED): An opaque identifier assigned at issuance. The reference implementation uses the form "auth--<5 lowercase hex chars>" with a CSPRNG-backed suffix. It is NOT a hash of the body (this changed from -08; see Appendix B). Verifiers MUST treat it as opaque. issuedAt (ISO 8601, REQUIRED): The issuance timestamp as asserted by the issuer. This is a claim, not a trusted timestamp; see Section 11 on timestamp limits. scope (string, REQUIRED): Human-readable description of what the agent is authorized to do (e.g. "read calendar events and draft meeting summaries"). Free-text scope is advisory: it is NOT machine-enforced. Machine enforcement requires "scopeSchema" (Section 4.3). A receipt with only text scope MUST NOT be presented as cryptographically scope-enforced. boundaries (string, REQUIRED): Human-readable prohibitions the agent MUST NOT violate regardless of operator instruction (e.g. "never send email without explicit confirmation"). Like "scope", this field is advisory text unless mirrored in "scopeSchema"'s deniedActions. timeWindow (object, REQUIRED): Validity interval with two REQUIRED Nelson Expires 12 April 2027 [Page 8] Internet-Draft Agent Delegation Receipts October 2026 string members: "start" and "end", both ISO 8601. An action at time T is temporally valid only if start <= T <= end. For a sub- receipt, the child window MUST be contained within the parent window (child.start >= parent.start AND child.end <= parent.end); issuance MUST fail otherwise. operatorInstructions (string, REQUIRED): The Operator's stated instructions at delegation time, in plaintext. instructionsHash (hex64, REQUIRED): SHA-256 over the normalized form of "operatorInstructions". Normalization: trim leading/trailing whitespace, lowercase, collapse internal whitespace runs to single spaces, remove commas, remove sentence-final periods, remove straight and curly quote characters, and sort detected key-value pairs alphabetically by key. (This normalization is lossy by design: it detects semantic drift, not byte edits. Verifiers MUST apply the identical normalization before comparing.) signerPublicKey (JWK, REQUIRED): The public key corresponding to the signing key, as a JWK containing exactly the members "kty", "crv", "x", and "y". The -11 profiles use "kty": "EC", "crv": "P-256". The JWK MUST NOT contain private material. Verifiers MUST confirm the key's "crv" matches the signature algorithm before verifying. 4.3. Optional fields agentId (string, OPTIONAL): Identifier of the agent being authorized. metadata (object, OPTIONAL): Arbitrary JSON metadata, stored and signed as-is. Implementations MUST NOT put secrets here; the body is signed, not encrypted. toolSchemaHash (hex64, OPTIONAL): SHA-256 of the canonical tool schema the receipt was issued against. When present, verifiers detect tool-schema substitution. trustedSources (array of string, OPTIONAL): Instruction sources permitted to influence agent behavior, e.g. "user", "system_prompt", "verified_tool". When present, actions driven by an instruction source not in the list MUST be denied. toolOutputHash (hex64, OPTIONAL): SHA-256 of the expected tool output that triggers the action. When present, verifiers detect tampered tool outputs. revocationRequired (boolean, OPTIONAL): When true, the receipt Nelson Expires 12 April 2027 [Page 9] Internet-Draft Agent Delegation Receipts October 2026 REQUIRES a live revocation-registry check. Verifiers operating without registry access MUST deny such receipts (fail closed). See Section 9.4. oneTimeUse (boolean, OPTIONAL): When true, the receipt authorizes at most one action globally. Enforcement requires a durable, shared consumption store; without one, verifiers MUST deny (fail closed). See Section 9.5. parentReceiptId (string, OPTIONAL): Present only on sub-receipts. The identifier of the parent receipt (the DelegationLog key under which the parent is stored). Its presence marks the receipt as a sub-receipt and triggers chain checks (Section 8.7, Section 10). authorityStateCommitment (hex64, OPTIONAL): SHA-256 commitment over the authority state (roles, groups, entitlements, attributes) at issuance. When present, verifiers can detect authority-state drift. reauthPolicy (object, OPTIONAL): Re-authorization policy, stored as- is, with OPTIONAL members "secondsBeforeExpiry" (number), "trustScoreBelow" (number), and "onAuthorityStateDrift" (string, "block" or "reauth"). scopeSchema (object, OPTIONAL): Machine-readable structured scope (Section 8.1). When present, it is the enforced scope; the text "scope" field remains advisory. nonce (string, OPTIONAL): When present on a oneTimeUse receipt, the consumption key is ":" instead of the receiptId alone, allowing the same receiptId to be consumed once per nonce. 4.4. Attached and derived values These values travel with the receipt but are NOT part of the signed body and MUST be excluded from canonicalization and signing input. *Signature:* In the -11 profiles the signature is the JWS (Section 6) or COSE_Sign1 (Section 7) object itself; there is no separate "signature" field inside the body. (Pre-11 implementations attached a "signature" field holding lowercase hex of the DER-encoded ECDSA signature over UTF-8(JSON.stringify(body)); that format is deprecated by this document, precisely because its signing input was not canonical.) *orchestratorSignature:* Present only on sub-receipts. A signature by the Orchestrator's key over the exact ASCII binding string Nelson Expires 12 April 2027 [Page 10] Internet-Draft Agent Delegation Receipts October 2026 orchestrator-delegation:: It cryptographically links the Orchestrator's key to the specific parent-child receipt pair. In the -11 profiles it is carried as a second, attached JWS (Section 6.3) whose payload is the binding string; verifiers MUST verify it against the parent receipt's signerPublicKey in addition to the sub-receipt's own signature. revoked (boolean): An implementation-local annotation set from the revocation registry. It is not signed and not transmitted. receiptId (hex64, derived): The SHA-256 digest (lowercase hex) of the ASCII bytes of the JWS Compact Serialization (Section 6.6). It identifies the issued artifact, binding body and signature together. (Pre-11: SHA-256 hex of JSON.stringify(body + signature). The definition changed with the wire format; see Appendix B.) 4.5. The scopeSchema object When present, "scopeSchema" is an object with: * *version* (string, default "1.0"): Schema version. * *allowedActions* (array, REQUIRED): Each entry is an object with REQUIRED "operation" (string) and "resource" (string), and OPTIONAL "constraints" (object). Entries support wildcards (Section 8.2). * *deniedActions* (array, default []): Same entry shape. Denied entries are evaluated FIRST; denial takes precedence over allowance. * *maxDuration* (string, OPTIONAL, e.g. "4h"): Carried for policy use. NOTE: the reference implementation stores but does not enforce maxDuration; verifiers MUST NOT claim enforcement of it. * *manifestHash* (hex64, OPTIONAL): SHA-256 binding a tool server's capability manifest, so server/manifest divergence is detectable. 5. Canonicalization The signing input for both -11 profiles is the JCS canonical form [RFC8785] of the receipt body (Sections 4.2-4.3), with these rules: Nelson Expires 12 April 2027 [Page 11] Internet-Draft Agent Delegation Receipts October 2026 1. The body MUST be canonicalized per RFC 8785: object member names sorted in ascending UTF-16 code unit order at every nesting level, no insignificant whitespace, shortest-round-trip number form, and the RFC 8785 string escaping rules. 2. Attached values (Section 4.4) MUST be removed before canonicalization. Unknown fields MUST be dropped. 3. The canonical bytes are UTF-8 encoded; those bytes are the JWS payload (Section 6.2) or the COSE_Sign1 payload (Section 7). This is the deliberate fix for the pre-11 signing input, which was UTF-8(JSON.stringify(body)): JavaScript insertion-order serialization, not a canonical form. Two implementations holding the same logical receipt could produce different signing inputs, and cross-language verification (notably the Python SDK) could not rely on byte equality. JCS removes the ambiguity: there is exactly one valid serialization of a given body, so signers and verifiers in any language agree on the bytes. The cost is that pre-11 receipts are not verifiable under the -11 profiles; they remain verifiable only by the legacy rule, which this document deprecates. 6. JWS Profile The primary wire format. A Delegation Receipt is a JSON Web Signature [RFC7515] whose payload is the JCS-canonicalized receipt body. 6.1. Protected header The JWS Protected Header MUST contain "alg" (Section 6.5) and SHOULD contain "typ" with the value "drp-receipt". It MAY contain "kid" to identify the signing key. No other header parameters are defined by this document; verifiers MUST ignore unrecognized parameters except as required by RFC 7515 ("crit" handling). 6.2. Payload The payload is the exact byte string produced by Section 5. It is a JSON object and nothing else. Verifiers MUST parse the payload, confirm it is an object, and validate every field per Section 4 before applying any authorization logic. 6.3. Compact serialization The standard form is the JWS Compact Serialization [RFC7515]: Nelson Expires 12 April 2027 [Page 12] Internet-Draft Agent Delegation Receipts October 2026 BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature) For ECDSA signatures the JWS Signature value is the raw fixed-length concatenation R || S (64 bytes for P-256), base64url encoded per [RFC7518] Section 3.4. DER-encoded signatures MUST be rejected: they are the pre-11 format and are not valid -11 JWS. 6.4. Detached serialization When the receipt body travels separately from its signature (e.g. the body is already stored under its receiptId), the JWS MAY use the detached form with an unencoded payload [RFC7797]: the Protected Header MUST contain "b64": false and "crit": ["b64"], and the signing input is ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || JWS Payload) with the payload bytes used raw. The compact transmission form is then header..signature (empty payload segment), and the verifier supplies the payload bytes out of band. The payload bytes supplied MUST be byte-identical to the JCS form; any deviation fails verification. 6.5. Algorithm registry * *ES256* (ECDSA P-256 with SHA-256, [RFC7518]): REQUIRED. This is the only algorithm the reference implementation issues and verifies. All conforming implementations MUST support ES256 for verification and SHOULD use it for issuance. * *ES384, ES512* ([RFC7518]): OPTIONAL. * *EdDSA* (Ed25519, [RFC8037]): OPTIONAL. (Some peer receipt formats use Ed25519; no -11 test vectors use it: unverified.) * *RS256, PS256* ([RFC7518]): OPTIONAL, NOT RECOMMENDED for new deployments (larger keys and signatures for no benefit here). * *"none"*: PROHIBITED. Verifiers MUST reject unsecured JWS. No other "alg" values are defined by this document. Nelson Expires 12 April 2027 [Page 13] Internet-Draft Agent Delegation Receipts October 2026 6.6. Receipt identifier The "receiptId" of a -11 receipt is the lowercase hex SHA-256 digest of the ASCII bytes of its JWS Compact Serialization. For the detached form, the digest is computed over the compact form with the payload segment replaced by BASE64URL(JCS body bytes), i.e. over the exact bytes a compact serialization of the same receipt would contain. The receiptId binds the issued artifact (body plus signature); the same body signed by two keys yields two receiptIds. 7. COSE Profile For constrained environments (small runtimes, embedded agents, or transports where every byte counts), a Delegation Receipt MAY instead be a COSE_Sign1 object [RFC9052]: * The COSE_Sign1 payload is the exact byte string produced by Section 5 (JCS-canonicalized body, UTF-8). * The protected header MUST contain algorithm -7 (ES256). It SHOULD contain content type 0 or be empty; the payload is self-describing JSON. * The signature is the raw R || S form (64 bytes for P-256), per COSE ECDSA requirements. * The external_aad is empty unless the deployment defines one; if defined, verifiers MUST apply it identically. * The receiptId rule of Section 6.6 applies with "COSE_Sign1 bytes" in place of "JWS Compact Serialization bytes". The COSE profile is an alternative, not a second primary: JWS is first because the surrounding ecosystem (PACT's per-reply receipts, UCAN's JWT form, and general JSON tooling) already speaks JWS, and the interop goal of this draft track is best served by the format peers can verify with libraries they already have. COSE exists for deployments where JWS's base64url overhead or JSON framing is a real constraint. A receipt MUST use one profile or the other, never both for the same issuance. 8. Scope Model and Attenuation Rules Nelson Expires 12 April 2027 [Page 14] Internet-Draft Agent Delegation Receipts October 2026 8.1. Structured scopes A "scopeSchema" (Section 4.5) is the machine-enforceable scope. An action is described as { operation, resource, constraints? }. To test an action against a schema: first check "deniedActions"; if any entry matches, the action is denied. Then check "allowedActions"; if any entry matches (and its constraints hold), the action is allowed. Otherwise the action is denied. Default-deny: anything not listed is not permitted. 8.2. Wildcard matching Operation patterns: "*" matches any operation; otherwise exact string equality is required. Resource patterns: "*" matches anything. A pattern containing "*" is a glob: the "*" segments match any character sequence, anchored at both ends (e.g. "files/*" matches "files/report.pdf" but not "files"; "*.company.com" matches "mail.company.com"). Non-wildcard patterns require exact equality. 8.3. Constraints An "allowedActions" entry MAY carry "constraints", an object mapping parameter names to limits. Two limit forms are defined: a number (the action's parameter value MUST NOT exceed it, e.g. { "maxEvents": 10 }), and a wildcard string pattern (a string parameter MUST match it, e.g. { "sender": "*.company.com" }). Parameters absent from the action are skipped. A constraint violation denies the action. 8.4. Text scope is advisory The "scope" and "boundaries" string fields, and any keyword-overlap heuristic over them, are advisory signals for observability only. They MUST NOT gate allow/deny decisions. Real scope enforcement REQUIRES a "scopeSchema". (The reference implementation records a fuzzy keyword-overlap signal for text-only receipts but never allows or denies on it.) 8.5. Attenuation rules When an Orchestrator issues a sub-receipt, the child scope MUST be a strict proper subset of the parent scope. The check operates on literal "operation::resource" keys (exact string comparison; wildcard patterns are compared as literal strings, not expanded): Nelson Expires 12 April 2027 [Page 15] Internet-Draft Agent Delegation Receipts October 2026 1. Every entry in the child's "allowedActions" MUST have its "operation::resource" key present in the parent's "allowedActions". An agent MUST NOT grant what it was not given. 2. The child MUST have strictly fewer "allowedActions" entries than the parent. Equal scope is rejected: delegation MUST narrow. 3. Every entry in the parent's "deniedActions" MUST be present in the child's "deniedActions". A child MAY add denials but MUST NOT drop any. Violation MUST abort issuance; the reference implementation raises a scope-attenuation error before signing. Attenuation is checked at issuance AND re-checked by verifiers walking the chain. Note: because the comparison is on literal keys, a child entry "read::calendar/events" is NOT covered by a parent entry "read::calendar/*". Wildcard-aware subset reasoning is out of scope for -11; deployments needing it must carry the identical pattern string down the chain. 8.6. Depth limit The root receipt is at depth 0; each delegation hop adds 1. A delegation that would place a receipt at depth >= maxDepth MUST be rejected before signing. The default maxDepth is 3, so a default chain holds the root (depth 0) and at most two delegation levels (depths 1 and 2). Verifiers walking a chain MUST deny with CHAIN_DEPTH_EXCEEDED when the walked depth exceeds their configured maximum (default 3). maxDepth is a deployment parameter, not a receipt field: the receipt carries "parentReceiptId" links, and depth is counted by walking them. 8.7. Sub-receipt issuance Issuing a sub-receipt MUST follow this sequence: 1. Resolve the parent's scope ("scopeSchema" if present, else the text "scope" field; structured scope is REQUIRED for machine- checked attenuation). 2. Verify the child scope against Section 8.5 and the child timeWindow against the parent window (Section 4.2). 3. Build the child body including "parentReceiptId", sign it per the active profile (Section 6 or 7). Nelson Expires 12 April 2027 [Page 16] Internet-Draft Agent Delegation Receipts October 2026 4. Compute the child "receiptId" (Section 6.6), then sign the binding string "orchestrator- delegation::" with the Orchestrator's key and attach it as "orchestratorSignature" (Section 4.4). Verifiers MUST check, for any receipt carrying "parentReceiptId": the parent's signature is valid, the orchestratorSignature verifies against the parent's signerPublicKey over the exact binding string, the child window is contained in the parent window, the child scope attenuates per Section 8.5, and no ancestor is revoked (Section 9.3). Any failure denies the action. 9. Revocation 9.1. Registry model Revocation state lives in a Revocation Registry: an append-only store mapping receiptIds to signed revocation records. The registry is consulted by verifiers before execution (after signature verification). The registry interface is two operations: "check(receiptId)" returning { revoked, reason?, revokedAt? }, and "revoke(receiptId, { reason?, revokedAt? })" creating a signed record. Revocation is permanent: the registry MUST NOT provide un- revocation, and "revoke" on an already-revoked receiptId MUST fail. This document defines the record format and check semantics. How revocation records are distributed to verifiers (the revocation distribution protocol) is explicitly out of scope (Section 14); deployments without a distribution story have an unsolved window between revocation and enforcement, and MUST say so. 9.2. Revocation record A revocation record contains: "receiptHash" (the receiptId), "reason" (string), "revokedAt" (Unix milliseconds), "revokedBy" (the revoker's public JWK), and a signature over the record by the revoker's key (a JWS in -11 deployments). Records MUST be signature-verified before import into a registry; records with invalid signatures MUST be skipped and reported. The log anchor of the revocation record establishes the authoritative revocation time: actions taken before it remain valid; actions attempted after it MUST fail. Nelson Expires 12 April 2027 [Page 17] Internet-Draft Agent Delegation Receipts October 2026 9.3. Cascade revocation Revoking any receipt in a delegation chain denies all of its descendants. Verifiers enforce the cascade live at check time: when checking a sub-receipt, the verifier walks every ancestor via "parentReceiptId" links and consults the registry for each; any revoked ancestor denies the child with ANCESTOR_REVOKED. This holds regardless of which API created the revocation: a parent revoked through any path still denies its children at the gate. A registry or chain manager MAY also eagerly mark descendants revoked (breadth- first traversal), but eager marking is an optimization; the gate's ancestor walk is the normative enforcement. 9.4. Offline behavior A verifier without registry access (offline mode) MUST NOT treat "unknown" as "not revoked". The rule is fail-closed: any receipt with "revocationRequired": true is denied immediately (REVOCATION_CHECK_REQUIRED), and any walked ancestor carrying "revocationRequired": true denies the whole subtree (ANCESTOR_REVOCATION_CHECK_REQUIRED). Receipts without the flag are checked against whatever registry state is locally available; a deployment that cannot reach its registry SHOULD treat the gap as a declared risk, not as silent approval. 9.5. One-time-use receipts A receipt with "oneTimeUse": true authorizes at most one action globally. Consumption MUST be attempted only after every other check has passed, so a consumption slot is never burned on a receipt that would be denied for another reason. Enforcement requires a durable, shared consumption store: without one, the verifier MUST deny with CONSUMPTION_STORE_REQUIRED (fail closed), because an in-memory or per-instance store cannot guarantee global uniqueness. An already consumed receipt is denied with RECEIPT_ALREADY_CONSUMED. The consumption key is the receiptId, or ":" when the receipt carries "nonce". 10. Implementation Profile: Pre-Execution Verification This section describes the reference implementation's pre-execution gate: the component that runs the checks in Sections 4-9 before an agent action executes. It is an implementation profile, not a second standard: conforming verifiers MUST implement the semantics of Sections 4-9 but MAY differ in check plumbing. The gate runs checks sequentially and stops at the first failure (fail closed). The implemented checks, in order: Nelson Expires 12 April 2027 [Page 18] Internet-Draft Agent Delegation Receipts October 2026 1. Receipt signature valid (over the canonical body; attached signatures excluded from the signed input). 2. Receipt not revoked (registry check; offline fail-closed per Section 9.4). 3. Within time window (a log timestamp is the time oracle, not the client clock). 4. Action within scope ("scopeSchema" validation; signed scope wins over unsigned log metadata: if both are present and disagree, the gate denies with SCOPE_METADATA_MISMATCH; log metadata is only a fallback when the receipt carries no structured scope; text-only scope yields an advisory signal, never a decision). 5. Operator instructions match (hash comparison after normalization; if the caller omits the claimed instructions, the check is skipped with an explicit warning and drift is NOT verified for that call). 6. Program hash match (optional; prevents code substitution; signed program hash wins over log metadata per the Check 4 rule, else PROGRAM_METADATA_MISMATCH). 7. Session risk evaluation (optional). 8. Tool schema integrity (optional; "toolSchemaHash"). 9. Model state verification (optional). 10. Tool output hash binding (optional; "toolOutputHash"). 11. Instruction provenance (optional; "trustedSources"; untrusted source denies with UNTRUSTED_INSTRUCTION_SOURCE). 12. (Unassigned.) 13. (Unassigned.) 14. Parent scope containment (sub-receipts only): parent signature valid, orchestratorSignature valid over the binding string, time window containment, scope attenuation per Section 8.5, chain depth within maxChainDepth, and the ancestor revocation walk of Section 9.3. 15. Authority state drift (optional; "authorityStateCommitment"; policy "block" denies with AUTHORITY_STATE_DRIFT, otherwise a re-authorization flag is set). Nelson Expires 12 April 2027 [Page 19] Internet-Draft Agent Delegation Receipts October 2026 One-time-use consumption runs after all checks. The gate signs every decision (permit and deny) with its own key and appends it to an immutable audit log (best-effort: logging never changes the decision). A second concurrent check using the same receipt hash is blocked as a replay guard. Known deviation (carried from the implementation, deferred fix): in Check 14 the reference implementation resolves parent and child scope from unsigned log metadata before the signed receipt body. The normative rule of this document (Sections 4, 8.5) is that the signed body wins and conflicting unsigned metadata denies; the implementation's Check 14 ordering does not yet meet that rule and MUST NOT be cited as hardened against log-metadata scope widening. 11. Security Considerations 11.1. Threat model *Compromised operator instructions.* An attacker who alters the instructions delivered to the agent produces an instruction hash mismatch at Check 5. They cannot forge a passing hash without the User's private key. *Scope widening by the operator.* The signed scope and program hash always win over unsigned operator log metadata; disagreement denies the action (SCOPE_METADATA_MISMATCH / PROGRAM_METADATA_MISMATCH). An operator who can write to the log cannot widen scope without invalidating the receipt signature. *Revoked credential reuse.* The registry check (Check 2) and the ancestor walk (Check 14) deny revoked receipts and their descendants. Revocation records are signed and permanent. *Prompt injection via untrusted channels.* "trustedSources" (Check 11) lets the User restrict which input channels may drive behavior; actions from unlisted sources are denied. This controls which channels can act, not whether a trusted channel carries a malicious payload. *Code and tool substitution.* "toolSchemaHash" (Check 8), "toolOutputHash" (Check 10), and the program hash (Check 6) bind the receipt to the exact tools and code it was issued against. Nelson Expires 12 April 2027 [Page 20] Internet-Draft Agent Delegation Receipts October 2026 *Replay.* One-time-use receipts (Section 9.5) give at-most-once semantics when backed by a durable store. The gate additionally blocks concurrent duplicate checks on the same receipt hash. Beyond that, receipts are bearer instruments: possession plus a valid signature authorizes, and general replay protection across deployments is out of scope. *Non-repudiation.* Under the EUF-CMA unforgeability of ECDSA P-256, a valid receipt on the log is non-repudiable evidence that the key holder authorized the body content. This is evidence, not prevention. 11.2. Limitations What receipts cannot do, stated without hedging: * *No control over malicious operators.* The verifier is same- process software in the reference implementation. An operator who controls the runtime can simply not call it. The receipt is an audit and attribution layer for honest deployments: it makes misbehavior provable, not impossible. Any claim that this protocol "sits outside the agent runtime" or constrains a malicious operator is false for the reference implementation. * *Revocation distribution is unsolved.* The registry model (Section 9) defines records and check semantics, not distribution. Until a distribution protocol exists, there is a window between revocation and enforcement that this document does not close. * *Timestamps are presence-checked, not verified.* Where the implementation touches RFC 3161 timestamp tokens, it confirms only that the token bytes contain the entry digest. It does NOT verify the TSA's signature or certificate chain; a forged token embedding the digest would pass. Full TSA signature verification is out of scope. The word "verified" MUST NOT appear next to RFC 3161 or TSA claims without this qualification. * *No hardware attestation.* TEE and model-state features in the reference implementation are software-computed, self-attested measurements for audit and tamper-evidence in honest deployments, not hardware-rooted attestation. Hardware guarantees require real TEE hardware and are not provided. * *Text scope is not enforced.* Free-text "scope" and "boundaries" are advisory. Only "scopeSchema" is machine-enforced. Nelson Expires 12 April 2027 [Page 21] Internet-Draft Agent Delegation Receipts October 2026 * *Instruction-drift check can be skipped.* If the caller does not supply the operator's claimed instructions, Check 5 is skipped with a warning; drift is then unverified for that call. * *Guided scope discovery auto-approves.* The one-call guided delegation flow approves the full observed scope with no human review unless a review hook is supplied. It is observation, not authorization. * *Key management is the deployer's problem.* Generation, storage, rotation, and custody are out of scope (Section 14). A compromised signing key voids every guarantee in this document. * *Bearer semantics.* Apart from one-time-use with a durable store, a valid receipt presented twice is valid twice. 12. Privacy Considerations Receipt bodies are signed, not encrypted. Anyone holding a receipt can read it, and receipts anchored to a public log are public forever: * "operatorInstructions" is plaintext. Do not put secrets, personal data, or credentials in it if the receipt leaves a trust boundary. * "agentId", "metadata", and "signerPublicKey" correlate activity: every receipt from one key is linkable to that key. * "instructionsHash" is vulnerable to dictionary attacks on predictable instructions; it confirms a guess, it does not hide the text from anyone who can guess it. * Revocation records are permanent and public; "reason" strings should not contain sensitive information. * "authorityStateCommitment" hides the authority state behind a hash, but the state is guessable if its shape is predictable. Deployments SHOULD keep receipts off public logs, encrypt instruction text at the application layer before inclusion, or redact fields before publication, and MUST document which choice they made. 13. IANA Considerations This document makes no IANA requests. It defines no new JWS algorithms, no new COSE algorithms, no new media types, and no new registries. Nelson Expires 12 April 2027 [Page 22] Internet-Draft Agent Delegation Receipts October 2026 14. Explicit Out-of-Scope The following are deliberately NOT specified here, and conformance to this document MUST NOT be read as covering them: * *Key management:* generation, storage, rotation, recovery, and custody of signing keys. * *Revocation distribution protocol:* how revocation records reach verifiers, propagation latency bounds, and offline synchronization. * *Hardware attestation:* TEE quotes, secure-enclave measurements, and hardware-rooted model identity. * *TSA-grade timestamps:* full RFC 3161 signature and chain verification; trusted time sources generally. * *Append-only log construction:* transparency proofs, log gossip, fork detection, and witness protocols. This document assumes a tamper-evident log exists; building one is separate work. * *Selective disclosure:* use AP2's SD-JWT mandate format where disclosure minimization is required. * *General replay protection* beyond Section 9.5 and the gate's concurrent-check guard. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, . [RFC7517] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Key (JWK)", RFC 7517, May 2015, . Nelson Expires 12 April 2027 [Page 23] Internet-Draft Agent Delegation Receipts October 2026 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May 2015, . [RFC7797] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, February 2016, . [RFC8037] Ligur, I. and Y. Sheffer, "CFRG Elliptic Curve Diffie- Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, January 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . [RFC8785] Rondinelli, E. and S. Miller, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . 15.2. Informative References [AP2] Google, "Google Agent Payments Protocol (AP2): signed mandates for agent payments, expressed as SD-JWT verifiable credentials with delegation chains". [PACT] Decagon, "Personal Agent Consent & Trust Protocol (PACT)", October 2026. [ERC-8004] Ethereum, "ERC-8004: Trustless Agents", . [UCAN] UCAN Working Group, "User Controlled Authorization Networks (UCAN): capability tokens with proof chains and attenuation", . [W3C-VC] W3C, "Verifiable Credentials Data Model", W3C Recommendation. [AGENT-PASSPORT] agent-passport-system, "Action Receipts v1.1". Nelson Expires 12 April 2027 [Page 24] Internet-Draft Agent Delegation Receipts October 2026 [DAAP] Mishra, "Delegated Agent Authorization Protocol (DAAP)", Work in Progress, Internet-Draft, draft-mishra-oauth- agent-grants, . [LIU-AUTH] Liu, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft-liu-agent-operation-authorization, . [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013, . Appendix A. Worked Example Everything in this appendix is EXAMPLE material. The key below is a throwaway generated only for this draft; it MUST NOT be used for anything real. The signatures shown are genuine: they were computed over the shown inputs with the shown key, and anyone can re-verify them with the shown public JWK. That is the point: real signatures over example inputs, not fabricated strings. This appendix was regenerated for -11 to fix two defects in the earlier worked example: the signatures were DER-encoded (which Section 6.3 requires verifiers to reject), and the published private scalar did not derive the published public key. The receipt payload is unchanged apart from the replacement throwaway key. A.1. The receipt (presentation form) { "delegationId": "auth-1790000000000-a1b2c", "issuedAt": "2026-10-09T12:00:00.000Z", "scope": "read calendar events and draft meeting summaries", "boundaries": "never send email without explicit confirmation; never delete calendar events", "timeWindow": { "start": "2026-10-09T12:00:00.000Z", "end": "2026-10-09T13:00:00.000Z" }, "operatorInstructions": "Read today's calendar events and draft a summary for the 2pm standup.", "instructionsHash": "c730de758e586e19a81098fa1cd40721162da9817fa7f7e651524a27c93ee4fb", "signerPublicKey": { Nelson Expires 12 April 2027 [Page 25] Internet-Draft Agent Delegation Receipts October 2026 "kty": "EC", "crv": "P-256", "x": "8bwgL5U3l0I7nkbcTJRcjzTeV0n6Wzcgm-KStQwbHEo", "y": "7SMrWmxPetYwa0LvAX4tpGA1OkEVBtkvhqh_oLh3-28" }, "agentId": "calendar-agent-01", "metadata": { "session": "demo-001" }, "trustedSources": [ "user", "system_prompt" ], "scopeSchema": { "allowedActions": [ { "operation": "read", "resource": "calendar/events" }, { "constraints": { "maxEvents": 10 }, "operation": "write", "resource": "calendar/drafts" } ], "deniedActions": [ { "operation": "delete", "resource": "calendar/events" } ], "version": "1.0" } } The "instructionsHash" is SHA-256 over the normalized instructions ("read today's calendar events and draft a summary for the 2pm standup." lowercased, punctuation-stripped per Section 4.2). A.2. JCS canonical form Canonicalized per RFC 8785 (keys sorted, no whitespace). This exact byte string is the JWS payload: {"agentId":"calendar-agent-01","boundaries":"never send email without explicit confirmation; never delete calendar events","delegationId":"auth-1790000000000-a1b2c","instructionsHash":"c730de758e586e19a81098fa1cd40721162da9817fa7f7e651524a27c93ee4fb","issuedAt":"2026-10-09T12:00:00.000Z","metadata":{"session":"demo-001"},"operatorInstructions":"Read today's calendar events and draft a summary for the 2pm standup.","scope":"read calendar events and draft meeting summaries","scopeSchema":{"allowedActions":[{"operation":"read","resource":"calendar/events"},{"constraints":{"maxEvents":10},"operation":"write","resource":"calendar/drafts"}],"deniedActions":[{"operation":"delete","resource":"calendar/events"}],"version":"1.0"},"signerPublicKey":{"crv":"P-256","kty":"EC","x":"8bwgL5U3l0I7nkbcTJRcjzTeV0n6Wzcgm-KStQwbHEo","y":"7SMrWmxPetYwa0LvAX4tpGA1OkEVBtkvhqh_oLh3-28"},"timeWindow":{"end":"2026-10-09T13:00:00.000Z","start":"2026-10-09T12:00:00.000Z"},"trustedSources":["user","system_prompt"]} Nelson Expires 12 April 2027 [Page 26] Internet-Draft Agent Delegation Receipts October 2026 Note the key ordering ("agentId" before "boundaries", "end" before "start" inside "timeWindow"): byte order follows UTF-16 code unit sorting, not the presentation order of Section A.1. A.3. JWS compact serialization (ES256) Protected header: {"alg":"ES256","typ":"drp-receipt"}, base64url: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRycC1yZWNlaXB0In0 The full compact serialization (header.payload.signature), EXAMPLE: eyJhbGciOiJFUzI1NiIsInR5cCI6ImRycC1yZWNlaXB0In0.eyJhZ2VudElkIjoiY2FsZW5kYXItYWdlbnQtMDEiLCJib3VuZGFyaWVzIjoibmV2ZXIgc2VuZCBlbWFpbCB3aXRob3V0IGV4cGxpY2l0IGNvbmZpcm1hdGlvbjsgbmV2ZXIgZGVsZXRlIGNhbGVuZGFyIGV2ZW50cyIsImRlbGVnYXRpb25JZCI6ImF1dGgtMTc5MDAwMDAwMDAwMC1hMWIyYyIsImluc3RydWN0aW9uc0hhc2giOiJjNzMwZGU3NThlNTg2ZTE5YTgxMDk4ZmExY2Q0MDcyMTE2MmRhOTgxN2ZhN2Y3ZTY1MTUyNGEyN2M5M2VlNGZiIiwiaXNzdWVkQXQiOiIyMDI2LTEwLTA5VDEyOjAwOjAwLjAwMFoiLCJtZXRhZGF0YSI6eyJzZXNzaW9uIjoiZGVtby0wMDEifSwib3BlcmF0b3JJbnN0cnVjdGlvbnMiOiJSZWFkIHRvZGF5J3MgY2FsZW5kYXIgZXZlbnRzIGFuZCBkcmFmdCBhIHN1bW1hcnkgZm9yIHRoZSAycG0gc3RhbmR1cC4iLCJzY29wZSI6InJlYWQgY2FsZW5kYXIgZXZlbnRzIGFuZCBkcmFmdCBtZWV0aW5nIHN1bW1hcmllcyIsInNjb3BlU2NoZW1hIjp7ImFsbG93ZWRBY3Rpb25zIjpbeyJvcGVyYXRpb24iOiJyZWFkIiwicmVzb3VyY2UiOiJjYWxlbmRhci9ldmVudHMifSx7ImNvbnN0cmFpbnRzIjp7Im1heEV2ZW50cyI6MTB9LCJvcGVyYXRpb24iOiJ3cml0ZSIsInJlc291cmNlIjoiY2FsZW5kYXIvZHJhZnRzIn1dLCJkZW5pZWRBY3Rpb25zIjpbeyJvcGVyYXRpb24iOiJkZWxldGUiLCJyZXNvdXJjZSI6ImNhbGVuZGFyL2V2ZW50cyJ9XSwidmVyc2lvbiI6IjEuMCJ9LCJzaWduZXJQdWJsaWNLZXkiOnsiY3J2IjoiUC0yNTYiLCJrdHkiOiJFQyIsIngiOiI4YndnTDVVM2wwSTdua2JjVEpSY2p6VGVWMG42V3pjZ20tS1N0UXdiSEVvIiwieSI6IjdTTXJXbXhQZXRZd2EwTHZBWDR0cEdBMU9rRVZCdGt2aHFoX29MaDMtMjgifSwidGltZVdpbmRvdyI6eyJlbmQiOiIyMDI2LTEwLTA5VDEzOjAwOjAwLjAwMFoiLCJzdGFydCI6IjIwMjYtMTAtMDlUMTI6MDA6MDAuMDAwWiJ9LCJ0cnVzdGVkU291cmNlcyI6WyJ1c2VyIiwic3lzdGVtX3Byb21wdCJdfQ.x-25GCeZP17YIXVxETe10cwsg2_Qui7X412Ubx0q64H4uq6jta8f1n4O9bqOeFLaVArHCgwv--_TuscMJwttlw The signature is the raw 64-byte R||S concatenation required by Section 6.3 (RFC 7518 Section 3.4). The receiptId is the SHA-256 hex of the ASCII bytes of that string: 061cef91d98ef21ad9ba2550f1d71b8e16717c97e008282d6a10523a7a838199 A.4. Detached form (RFC 7797) With header {"alg":"ES256","b64":false,"crit":["b64"]} and the same JCS bytes supplied out of band, the transmitted form is header..signature (EXAMPLE): eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..T_iG4gR4ms4pMp5RXGz7NNieNQkF_9oBwEYCFZWZ7Kig_WWUaLlFhvWS_wvpw3-B8HQww7dq1KiLgaDRkitvUw A.5. Example key (DO NOT USE) Public JWK: { "kty": "EC", "crv": "P-256", "x": "8bwgL5U3l0I7nkbcTJRcjzTeV0n6Wzcgm-KStQwbHEo", "y": "7SMrWmxPetYwa0LvAX4tpGA1OkEVBtkvhqh_oLh3-28" } The corresponding private "d" value (published so the example is reproducible; throwaway): nvTRYETQC0GN4fA2Q8Fe9am6PG8xlfXqXsjvs1eeaZw. To re-verify: base64url-decode the payload segment, confirm it is byte-identical to the JCS form in Section A.2, then verify the ES256 signature over ASCII(headerSegment || "." || payloadSegment) with the public JWK above, using the raw 64-byte R||S form per RFC 7518 Section 3.4. Nelson Expires 12 April 2027 [Page 27] Internet-Draft Agent Delegation Receipts October 2026 Appendix B. Changes from -08 to -11 -08 (May 2026) described the pre-standardization SDK. -11 (October 2026) redefines the wire format and corrects the record. Summary: *Wire format (the big change).* -08 specified a custom signature: hex-encoded ECDSA over JSON.stringify of the body (insertion-order serialization). -11 replaces it with two standard profiles: JWS (RFC 7515) over JCS-canonicalized JSON (RFC 8785) as the primary format, and COSE_Sign1 (RFC 9052) for constrained environments. The signing input is now canonical, which fixes cross-implementation and cross- language verification. Pre-11 receipts are not verifiable under the -11 profiles. *Data model corrected to the implementation.* -08's field table did not match the shipped SDK. -11 documents the actual fields: "delegationId" is an opaque issuance identifier (not a body hash); "scope" and "boundaries" are text strings (not arrays, not a reads/writes/deletes/executes object); "timeWindow" uses "start"/"end" (not "notBefore"/"notAfter"); the instruction hash field is "instructionsHash" (not "instructionHash"); "version" is a scopeSchema member, not a receipt field. New optional fields since -08: "trustedSources", "toolOutputHash", "revocationRequired", "oneTimeUse", "parentReceiptId", "authorityStateCommitment", "reauthPolicy", "agentId", "metadata", "toolSchemaHash", "nonce". *Sub-receipts and chains.* -08 described "micro-receipts". The implementation issues sub-receipts carrying "parentReceiptId" in the signed body plus an "orchestratorSignature" over the binding string "outside" the body. -11 specifies both, the strict proper-subset attenuation rules (with the literal-key comparison the code actually performs), the depth-0 root / maxDepth default-3 semantics, and the verifier's chain checks including the live ancestor revocation walk. *Revocation rewritten.* -08 described revocation as signed records on a transparency log with no registry semantics. -11 specifies the RevocationRegistry model the SDK actually implements: append-only, permanent, signed records; the cascade enforced live at the gate (ANCESTOR_REVOKED); and the offline fail-closed rule for "revocationRequired" receipts. Revocation distribution remains explicitly unsolved and out of scope. *Verification checks updated.* -08 listed 10 checks in the wrong order with stale names. -11 documents the implemented 13-check gate (1-11, 14, 15; 12-13 unassigned), the correct order (signature before revocation), signed-body precedence over log metadata with fail- closed mismatch codes, the advisory-only text-scope signal, and the Check 5 skip-with-warning behavior. Nelson Expires 12 April 2027 [Page 28] Internet-Draft Agent Delegation Receipts October 2026 *Honesty section added.* -08's Security Considerations claimed the verifier sits outside the agent runtime and implied control over malicious operators. -11's Section 11.2 states the limits plainly: same-process verifier, no malicious-operator control, presence-only TSA checks, self-attested (non-hardware) TEE/model measurements, unenforced text scope, bearer semantics, and key management as the deployer's problem. The "Explicit Out-of-Scope" section (14) is new. *Terminology aligned; interop not claimed.* -11 adds Section 2.3 mapping terms to AP2, PACT, ERC-8004, UCAN, and related IETF drafts, and states the deliberate divergences. It explicitly does NOT claim wire-format interoperability: no adapter has been built or verified. *Worked example added.* Appendix A gives a complete receipt, its JCS form, and genuine ES256 JWS serializations (compact and detached) computed with a published throwaway key. Author's Address Ryan Nelson Authproof Email: nelson73620@gmail.com Nelson Expires 12 April 2027 [Page 29]