Agent Delegation Receipts
draft-nelson-agent-delegation-receipts-14
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Ryan Nelson | ||
| Last updated | 2026-10-15 (Latest revision 2026-10-13) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nelson-agent-delegation-receipts-14
Network Working Group R. Nelson
Internet-Draft Authproof
Intended status: Informational 15 October 2026
Expires: 18 April 2027
Agent Delegation Receipts
draft-nelson-agent-delegation-receipts-14
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. Version -12 resolves the unknown-
fields question raised on the IETF oauth mailing list: authorization
fields are closed (verifiers reject unknown top-level body fields
rather than silently ignoring them), the "metadata" object is the
defined extension point, and one-time-use receipts fail closed
without a durable consumption store. Version -13 incorporates
independent-implementation feedback: it pins the
orchestratorSignature verification key to the sub-receipt signer's
key, states the receipt-issuance computation order explicitly, and
guides issuers on default boundaries versus explicit allowances.
Version -14 adds a pointer to content profiles for verification of
what the agent produced, following implementer feedback; no wire-
format changes.
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/.
Nelson Expires 18 April 2027 [Page 1]
Internet-Draft Agent Delegation Receipts October 2026
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 18 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Relationship to Existing Work . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
4. Receipt Data Model . . . . . . . . . . . . . . . . . . . . . 8
4.1. Design . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Required fields . . . . . . . . . . . . . . . . . . . . . 9
4.3. Optional fields . . . . . . . . . . . . . . . . . . . . . 10
4.4. Attached and derived values . . . . . . . . . . . . . . . 12
4.5. The scopeSchema object . . . . . . . . . . . . . . . . . 12
5. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 13
6. JWS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Protected header . . . . . . . . . . . . . . . . . . . . 14
6.2. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Compact serialization . . . . . . . . . . . . . . . . . . 14
6.4. Detached serialization . . . . . . . . . . . . . . . . . 14
6.5. Algorithm registry . . . . . . . . . . . . . . . . . . . 15
6.6. Receipt identifier . . . . . . . . . . . . . . . . . . . 15
7. COSE Profile . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Scope Model and Attenuation Rules . . . . . . . . . . . . . . 16
8.1. Structured scopes . . . . . . . . . . . . . . . . . . . . 16
8.2. Wildcard matching . . . . . . . . . . . . . . . . . . . . 16
8.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . 17
Nelson Expires 18 April 2027 [Page 2]
Internet-Draft Agent Delegation Receipts October 2026
8.4. Text scope is advisory . . . . . . . . . . . . . . . . . 17
8.5. Attenuation rules . . . . . . . . . . . . . . . . . . . . 17
8.6. Depth limit . . . . . . . . . . . . . . . . . . . . . . . 18
8.7. Sub-receipt issuance . . . . . . . . . . . . . . . . . . 18
9. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Registry model . . . . . . . . . . . . . . . . . . . . . 19
9.2. Revocation record . . . . . . . . . . . . . . . . . . . . 19
9.3. Cascade revocation . . . . . . . . . . . . . . . . . . . 19
9.4. Offline behavior . . . . . . . . . . . . . . . . . . . . 20
9.5. One-time-use receipts . . . . . . . . . . . . . . . . . . 20
10. Implementation Profile: Pre-Execution Verification . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 22
11.2. Limitations . . . . . . . . . . . . . . . . . . . . . . 23
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14. Explicit Out-of-Scope . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Worked Example . . . . . . . . . . . . . . . . . . . 28
A.1. The receipt (presentation form) . . . . . . . . . . . . . 28
A.2. JCS canonical form . . . . . . . . . . . . . . . . . . . 29
A.3. JWS compact serialization (ES256) . . . . . . . . . . . . 29
A.4. Detached form (RFC 7797) . . . . . . . . . . . . . . . . 30
A.5. Example key (DO NOT USE) . . . . . . . . . . . . . . . . 30
Appendix B. Changes from -13 to -14 . . . . . . . . . . . . . . 30
Appendix C. Changes from -12 to -13 . . . . . . . . . . . . . . 31
Appendix D. Changes from -11 to -12 . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32
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.
Nelson Expires 18 April 2027 [Page 3]
Internet-Draft Agent Delegation Receipts October 2026
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
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. Verification of what the agent
produced -- as opposed to what it was authorized to do -- is the role
of content profiles, such as the EU2122 content profile [EU2122]; a
verification receipt can reference the corresponding authorization
record using its "receiptId".
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
[BCP14] when, and only when, they appear in all capitals, as shown
here.
Nelson Expires 18 April 2027 [Page 4]
Internet-Draft Agent Delegation Receipts October 2026
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.
Nelson Expires 18 April 2027 [Page 5]
Internet-Draft Agent Delegation Receipts October 2026
*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.)
Nelson Expires 18 April 2027 [Page 6]
Internet-Draft Agent Delegation Receipts October 2026
*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.
Nelson Expires 18 April 2027 [Page 7]
Internet-Draft Agent Delegation Receipts October 2026
*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 who has anchored
the authorizing key to the User through a trusted channel outside the
receipt (Section 11) 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
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.
Nelson Expires 18 April 2027 [Page 8]
Internet-Draft Agent Delegation Receipts October 2026
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, when
it was a hash of the body). 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
Nelson Expires 18 April 2027 [Page 9]
Internet-Draft Agent Delegation Receipts October 2026
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. When the
claimed instructions are supplied, 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.
Nelson Expires 18 April 2027 [Page 10]
Internet-Draft Agent Delegation Receipts October 2026
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.
programHash (hex64, OPTIONAL): SHA-256 of the agent program or code
the receipt authorizes. When present, verifiers detect code
substitution. The hash construction (what bytes are hashed) is
deployment-defined; the issuer and verifier MUST use the same
construction for the check to be meaningful.
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.
Nelson Expires 18 April 2027 [Page 11]
Internet-Draft Agent Delegation Receipts October 2026
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. A verifier MUST validate orchestratorSignature using the
public key carried in the sub-receipt's signerPublicKey field: the
Orchestrator is the holder of the parent delegation, and the key it
signs the sub-receipt with is the key that binds the pair.
Verification against the parent's key is NOT sufficient.
revoked (boolean): An implementation-local annotation set from the
revocation registry. It is not signed and not transmitted.
receiptId (hex64, derived): The profile-neutral identifier of the
issued artifact, binding body and signature together: the
lowercase-hex SHA-256 digest of the bytes of the issued signed
artifact, as computed by the active profile (JWS: Section 6.6;
COSE: Section 7). (Before -11 it was the SHA-256 hex of
JSON.stringify(body + signature); the definition changed with the
-11 wire format.)
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).
Nelson Expires 18 April 2027 [Page 12]
Internet-Draft Agent Delegation Receipts October 2026
* *deniedActions* (array, default []): Same entry shape. Denied
entries are evaluated FIRST; denial takes precedence over
allowance. An issuer that explicitly allows an action class in
"allowedActions" SHOULD omit the corresponding default boundary
from "deniedActions": keeping both would silently deny an action
the same signed receipt allows.
* *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 -12 profiles is the JCS canonical form
[RFC8785] of the receipt body (Sections 4.2-4.3), with these rules:
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. When constructing the signing input, the
issuer MUST NOT include unknown fields -- issuers MUST NOT emit
them in the first place (Section 4.1).
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 -12 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.
Nelson Expires 18 April 2027 [Page 13]
Internet-Draft Agent Delegation Receipts October 2026
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.
Nelson Expires 18 April 2027 [Page 14]
Internet-Draft Agent Delegation Receipts October 2026
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 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.
Issuers MUST follow this computation order, which admits no
circularity: (1) assemble the body fields (Sections 4.2, 4.3); the
"receiptId" is not yet defined and plays no part; (2) canonicalize
the body per Section 5 and sign the profile signing input ([RFC7515]
Section 5.1), producing the signature; (3) assemble the JWS Compact
Serialization (Section 6.3); (4) compute the "receiptId" as the
SHA-256 hex digest of the ASCII bytes of that serialization. No step
consumes a value produced by a later step.
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).
Nelson Expires 18 April 2027 [Page 15]
Internet-Draft Agent Delegation Receipts October 2026
* 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" of a COSE-profile receipt is the lowercase-hex
SHA-256 digest of the encoded bytes of the issued COSE_Sign1
structure [RFC9052]: the exact byte string the issuer transmits or
stores as the receipt (CBOR-encoded COSE_Sign1, comprising
protected header, unprotected header, payload, and signature).
Issuers MUST compute the digest over the same bytes they emit,
after signing; verifiers recompute it over the bytes received.
The receiptId binds the issued artifact (body plus signature); the
same body signed by two keys yields two receiptIds.
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
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.
Nelson Expires 18 April 2027 [Page 16]
Internet-Draft Agent Delegation Receipts October 2026
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 both the parent and child receipts carry "scopeSchema" and 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.
Nelson Expires 18 April 2027 [Page 17]
Internet-Draft Agent Delegation Receipts October 2026
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 is greater than or equal
to 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 when both receipts
carry "scopeSchema" (otherwise the text-scope advisory rules of
Section 8.4 apply) 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" (Sections 6.6, 7), then sign the
binding string "orchestrator-
delegation:<parentReceiptId>:<receiptId>" with the Orchestrator's
key and attach it as "orchestratorSignature" (Section 4.4).
Schema parity across delegation hops: sub-receipt issuance without
"scopeSchema" MUST fail unless the parent receipt also carries no
"scopeSchema", in which case only the text-scope advisory rules of
Section 8.4 apply and the sub-receipt MUST NOT be presented as
cryptographically scope-enforced (Section 4.2). Verifiers walking
the chain MUST enforce this parity; a parity failure denies the
action.
Nelson Expires 18 April 2027 [Page 18]
Internet-Draft Agent Delegation Receipts October 2026
Verifiers MUST check, for any receipt carrying "parentReceiptId": the
parent's signature is valid, the orchestratorSignature verifies
against the sub-receipt's signerPublicKey over the exact binding
string (Section 4.4), the child window is contained in the parent
window, the child scope attenuates per Section 8.5 when both receipts
carry "scopeSchema" (otherwise the text-scope advisory rules of
Section 8.4 apply), 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 -12 deployments). Records MUST be signature-verified before
import into a registry; records with invalid signatures MUST be
skipped and reported. The "revokedAt" time in the signed 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
Nelson Expires 18 April 2027 [Page 19]
Internet-Draft Agent Delegation Receipts October 2026
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".
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. This section is
normative for deployments claiming conformance to the Pre-Execution
Verification profile: such deployments MUST implement the precedence,
gate-signing, audit-logging, and replay-guard behaviors stated here
in addition to the check semantics of Sections 4-9.
The gate runs checks sequentially and stops at the first failure
(fail closed). The implemented checks, in order:
1. Receipt signature valid (over the canonical body; attached
signatures excluded from the signed input).
Nelson Expires 18 April 2027 [Page 20]
Internet-Draft Agent Delegation Receipts October 2026
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 (only when the receipt carries "programHash";
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 when both
receipts carry "scopeSchema" (otherwise the text-scope advisory
rules of Section 8.4 apply), chain depth within maxDepth, 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 18 April 2027 [Page 21]
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, when the
receipt carries it, the signed 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, when
present) 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
Nelson Expires 18 April 2027 [Page 22]
Internet-Draft Agent Delegation Receipts October 2026
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.
Nelson Expires 18 April 2027 [Page 23]
Internet-Draft Agent Delegation Receipts October 2026
* *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.
* *Key-to-user binding is out-of-band.* The "signerPublicKey"
carried in the signed body is self-asserted: a valid signature
proves the key holder authorized the body, not that the key holder
is the claimed User. Verifiers MUST obtain the authorizing public
key through a trusted out-of-band channel or equivalent trust
anchor (for example a pinned key directory, an account-bound key
ceremony, or a key commitment recorded in the append-only log) and
MUST confirm the receipt's "signerPublicKey" matches it before
relying on the receipt. A receipt whose signer key is not
anchored to the claimed User proves nothing about that User's
authorization.
* *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.
Nelson Expires 18 April 2027 [Page 24]
Internet-Draft Agent Delegation Receipts October 2026
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.
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
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Best Current Practice 14, BCP 14,
RFC 2119, RFC 8174, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Nelson Expires 18 April 2027 [Page 25]
Internet-Draft Agent Delegation Receipts October 2026
[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.
Nelson Expires 18 April 2027 [Page 26]
Internet-Draft Agent Delegation Receipts 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>.
[AGENTLEDGER]
Chengyue2025, "agentledger: tamper-evident evidence ledger
for AI agents", Independent Python implementation of this
draft; interop feedback filed as INTEROP-15, October 2026,
<https://github.com/Chengyue2025/agentledger>.
[EU2122] Klassen, B.N., "EU2122 V1.0 Standard: Content Profile for
AI Output Verification Receipts", Content profile for
verification receipts; cites this draft informatively,
Work in Progress, Internet-Draft, draft-klassen-eu2122-
content-profile, October 2026,
<https://datatracker.ietf.org/doc/draft-klassen-eu2122-
content-profile/>.
[INTEROP-15]
Chengyue2025, "Interop feedback from an independent
implementation", authproof-sdk issue 15: three
specification ambiguities found while implementing draft
-12, plus an interop corpus exchange offer, October 2026,
<https://github.com/Commonguy25/authproof-sdk/issues/15>.
[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>.
Nelson Expires 18 April 2027 [Page 27]
Internet-Draft Agent Delegation Receipts October 2026
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
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": {
"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": [
Nelson Expires 18 April 2027 [Page 28]
Internet-Draft Agent Delegation Receipts October 2026
{
"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
Nelson Expires 18 April 2027 [Page 29]
Internet-Draft Agent Delegation Receipts October 2026
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.
Appendix B. Changes from -13 to -14
-14 (October 2026) adds a pointer to content profiles for
verification of what the agent produced, following implementer
feedback from VeroNex (Bruce Klassen):
*Content-profile layering.* The Introduction now states that
verification of what the agent produced is the role of content
profiles such as the EU2122 content profile [EU2122], and that a
verification receipt can reference the corresponding authorization
record using its "receiptId". No wire-format changes: the delegation
receipt remains the authorization record, and the reference pattern
needs no new fields.
Nelson Expires 18 April 2027 [Page 30]
Internet-Draft Agent Delegation Receipts October 2026
*Specification hardening.* Section 10 is now explicitly normative for
deployments claiming the Pre-Execution Verification profile; a new
OPTIONAL "programHash" field (Section 4.3) backs the code-
substitution check; the "instructionsHash" normalization requirement
is conditioned on the claimed instructions being supplied; sub-
receipt issuance without "scopeSchema" MUST fail unless the parent
also carries none (Section 8.7); verifiers MUST anchor the
authorizing key to the User through a trusted out-of-band channel
(Section 11), and the Section 3 claim is qualified accordingly;
"receiptId" is restated profile-neutrally (Section 4.4) with an
explicit COSE computation (Section 7); the undefined "log anchor" is
replaced by the signed record's "revokedAt" time (Section 9.2).
*Corrections.* The Section 5 unknown-fields rule is scoped to
signing-input construction (resolving a contradiction with
Section 4.1); the Section 6.6 issuance-order steps now cite the
correct subsections; two stale Appendix B pointers were restated
inline; "maxChainDepth" is corrected to "maxDepth". Removed
"submissionType" from the document element, resolving an idnits
error.
The field set is otherwise unchanged: the JWS and COSE_Sign1 profiles
and the verification gate carry the same checks as -13.
Appendix C. Changes from -12 to -13
-13 (October 2026) incorporates feedback from an independent Python
implementation of the draft (agentledger, [AGENTLEDGER]), filed as
[INTEROP-15]:
*Orchestrator verification key pinned.* Section 4.4 and the
Section 10 checklist now state that a verifier MUST validate
orchestratorSignature using the public key carried in the sub-
receipt's signerPublicKey field. -12 said "the parent receipt's
signerPublicKey", which misidentified the signer: the Orchestrator is
the holder of the parent delegation, and the key it signs the sub-
receipt with is the key that binds the pair.
*Issuance computation order stated.* Section 6.6 now gives the
numbered order body, sign, serialize, hash, closing the circularity
an independent implementer flagged.
*Default boundaries versus explicit allowances.* Section 4.5 now
guides issuers that explicitly allow an action class to omit the
corresponding default boundary, since denial takes precedence and
keeping both would silently deny an allowed action.
Nelson Expires 18 April 2027 [Page 31]
Internet-Draft Agent Delegation Receipts October 2026
No wire-format changes from -12: the JWS and COSE_Sign1 profiles, the
field set, and the verification gate are otherwise unchanged.
Appendix D. Changes from -11 to -12
-11 (October 2026) redefined the wire format around standard JWS and
COSE profiles and corrected the record against the implementation.
-12 (October 2026) resolves the unknown-fields question that -11 left
open, following feedback on the IETF oauth mailing list. Summary:
*Unknown fields: closed authorization fields, metadata as the
extension point.* -11 required verifiers to ignore unknown body
fields. -12 reverses that for the top level: the body field set is
CLOSED (Sections 4.2, 4.3). Issuers MUST NOT emit unknown top-level
body fields, and verifiers MUST reject receipts carrying them rather
than silently ignore them 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 defined
extension point is the "metadata" object (Section 4.3): verifiers
MUST ignore unknown fields inside "metadata", and their presence does
not change the verification decision. The reference implementation
reports unknown top-level fields as UNKNOWN_BODY_FIELD with the
offending field names. This resolution follows the proposal by Iman
Schrock (EMILIA Protocol) on the oauth list, including his three
pinned cases: "metadata.displayLabel" preserves the decision; an
uninterpretable authority constraint must not produce an allow; and
"oneTimeUse": true fails closed without a durable consumption store
(CONSUMPTION_STORE_REQUIRED, Section 9.5). All three cases are
implemented and covered by conformance vectors in the reference
implementation.
*Signature input clarified.* -12 states explicitly that verifiers
MUST verify the signature over the exact received signing input and
MUST NOT strip unknown fields, re-canonicalize, and verify against
the modified bytes.
No wire-format changes from -11: the JWS and COSE_Sign1 profiles, the
field set, and the verification gate are otherwise unchanged. The
-08 to -11 changelog was published with the -11 revision.
Author's Address
Ryan Nelson
Authproof
Email: nelson73620@gmail.com
Nelson Expires 18 April 2027 [Page 32]