Agent Delegation Receipts

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.¶

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 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.)¶

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.¶

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). The top-level body field set defined in Sections 4.2 and 4.3 is CLOSED. Issuers MUST NOT emit unknown top-level body fields. A verifier that encounters an unknown top-level body field MUST reject the receipt and MUST NOT silently ignore the field or produce an allow: an unrecognized field could be a restriction on authority, and ignoring it would be indistinguishable from widening what was authorized. The reference implementation reports this condition as UNKNOWN_BODY_FIELD with the offending field names appended.¶

The defined extension point is the "metadata" object (Section 4.3). Verifiers MUST ignore unknown fields inside "metadata"; their presence or absence does not change the verification decision. The "metadata" object is part of the signed body (JCS-canonicalized with the rest), so extensions placed there are authenticated but never interpreted.¶

A verifier MUST verify the signature over the exact received signing input. It MUST NOT strip unknown fields, re-canonicalize, and verify against the modified bytes: a receipt whose bytes do not match the canonical form of its recognized fields is rejected.¶

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-<unix-milliseconds>-<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 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 -12 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. This is the defined extension point for fields this document does not define: verifiers MUST ignore the contents of "metadata" for authorization decisions (see Section 4.1), so adding e.g. "metadata.displayLabel" preserves the verification decision. 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 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 "<receiptId>:<nonce>" 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 -12 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¶

orchestrator-delegation:<parentReceiptId>:<receiptId>

It cryptographically links the Orchestrator's key to the specific parent-child receipt pair. In the -12 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.¶

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]:¶

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 -12 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 -12 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.¶

6.6. Receipt identifier

The "receiptId" of a -12 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.¶

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):¶

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 -12; 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).¶

4. Compute the child "receiptId" (Section 6.6), then sign the binding string "orchestrator-delegation:<parentReceiptId>:<receiptId>" 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.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 -12 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.¶

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 "<receiptId>:<nonce>" when the receipt carries "nonce".¶

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.¶

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.¶

• 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.¶

15.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Key (JWK)", RFC 7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC7797]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, February 2016, <https://www.rfc-editor.org/rfc/rfc7797>.

[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, <https://www.rfc-editor.org/rfc/rfc8037>.

[RFC8259]

Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8785]

Rondinelli, E. and S. Miller, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

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", <https://eips.ethereum.org/EIPS/eip-8004>.

[UCAN]

UCAN Working Group, "User Controlled Authorization Networks (UCAN): capability tokens with proof chains and attenuation", <https://github.com/ucan-wg/spec>.

[W3C-VC]

W3C, "Verifiable Credentials Data Model", W3C Recommendation.

[AGENT-PASSPORT]

agent-passport-system, "Action Receipts v1.1".

[DAAP]

Mishra, "Delegated Agent Authorization Protocol (DAAP)", Work in Progress, Internet-Draft, draft-mishra-oauth-agent-grants, <https://datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants>.

[LIU-AUTH]

Liu, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft-liu-agent-operation-authorization, <https://datatracker.ietf.org/doc/html/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, <https://www.rfc-editor.org/rfc/rfc3161>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.

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": {
    "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"]}

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.¶