Agent Delegation Receipts
draft-nelson-agent-delegation-receipts-15
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.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Ryan Nelson | ||
| Last updated | 2026-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-15
Network Working Group R. Nelson
Internet-Draft Authproof
Intended status: Informational 21 October 2026
Expires: 24 April 2027
Agent Delegation Receipts
draft-nelson-agent-delegation-receipts-15
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. Version -15
adopts the grant/execution vocabulary of [CHEN-AGENT-USE-CASES]: the
receipt as Execution Layer Evidence for a Grant Layer Authority. It
adds delegatee holder binding for sub-receipts -- a parent names the
delegatee's public key, closing a bearer-copy issuance gap found in
review -- deprecates orchestratorSignature as redundant, sketches an
OAuth authorization_details binding so a token can reference its
receipt, and states normative custody requirements for the
authorizing key. The delegateeKey field is a wire-format addition;
-14-era verifiers will reject receipts carrying it, which is the
intended fail-closed version behavior.
Nelson Expires 24 April 2027 [Page 1]
Internet-Draft Agent Delegation Receipts October 2026
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements language . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Relationship to Existing Work . . . . . . . . . . . . . . 6
2.4. What a receipt proves . . . . . . . . . . . . . . . . . . 8
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
4. Receipt Data Model . . . . . . . . . . . . . . . . . . . . . 9
4.1. Design . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Required fields . . . . . . . . . . . . . . . . . . . . . 10
4.3. Optional fields . . . . . . . . . . . . . . . . . . . . . 11
4.4. Attached and derived values . . . . . . . . . . . . . . . 13
4.5. The scopeSchema object . . . . . . . . . . . . . . . . . 13
4.6. Authorizing key requirements . . . . . . . . . . . . . . 14
5. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 15
Nelson Expires 24 April 2027 [Page 2]
Internet-Draft Agent Delegation Receipts October 2026
6. JWS Profile . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Protected header . . . . . . . . . . . . . . . . . . . . 16
6.2. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Compact serialization . . . . . . . . . . . . . . . . . . 16
6.4. Detached serialization . . . . . . . . . . . . . . . . . 16
6.5. Algorithm registry . . . . . . . . . . . . . . . . . . . 17
6.6. Receipt identifier . . . . . . . . . . . . . . . . . . . 17
7. COSE Profile . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Scope Model and Attenuation Rules . . . . . . . . . . . . . . 18
8.1. Structured scopes . . . . . . . . . . . . . . . . . . . . 18
8.2. Wildcard matching . . . . . . . . . . . . . . . . . . . . 18
8.3. Constraints . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. Text scope is advisory . . . . . . . . . . . . . . . . . 19
8.5. Attenuation rules . . . . . . . . . . . . . . . . . . . . 19
8.6. Depth limit . . . . . . . . . . . . . . . . . . . . . . . 20
8.7. Sub-receipt issuance . . . . . . . . . . . . . . . . . . 20
8.8. Terminal delegation . . . . . . . . . . . . . . . . . . . 22
9. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Registry model . . . . . . . . . . . . . . . . . . . . . 22
9.2. Revocation record . . . . . . . . . . . . . . . . . . . . 22
9.3. Cascade revocation . . . . . . . . . . . . . . . . . . . 23
9.4. Offline behavior . . . . . . . . . . . . . . . . . . . . 23
9.5. One-time-use receipts . . . . . . . . . . . . . . . . . . 23
10. Implementation Profile: Pre-Execution Verification . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 25
11.2. Limitations . . . . . . . . . . . . . . . . . . . . . . 26
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
13. Binding to OAuth . . . . . . . . . . . . . . . . . . . . . . 29
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15. Explicit Out-of-Scope . . . . . . . . . . . . . . . . . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Worked Example . . . . . . . . . . . . . . . . . . . 33
A.1. The receipt (presentation form) . . . . . . . . . . . . . 33
A.2. JCS canonical form . . . . . . . . . . . . . . . . . . . 34
A.3. JWS compact serialization (ES256) . . . . . . . . . . . . 35
A.4. Detached form (RFC 7797) . . . . . . . . . . . . . . . . 35
A.5. Example key (DO NOT USE) . . . . . . . . . . . . . . . . 35
Appendix B. Changes from -14 to -15 . . . . . . . . . . . . . . 36
Appendix C. Changes from -13 to -14 . . . . . . . . . . . . . . 37
Appendix D. Changes from -12 to -13 . . . . . . . . . . . . . . 38
Appendix E. Changes from -11 to -12 . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
Nelson Expires 24 April 2027 [Page 3]
Internet-Draft Agent Delegation Receipts October 2026
1. Introduction
AI agents act on behalf of people using natural language instructions
as their working orders. The person who is supposed to be in charge
writes or approves a scope. The operator who runs the deployment
delivers the actual instructions to the agent at runtime. Nothing in
that pipeline is cryptographic, so when the agent does something the
person did not want, there is no reliable record of what was
authorized versus what was delivered.
This document specifies the Delegation Receipt, a signed
authorization artifact that closes that gap on paper. Before an
agent acts, the authorizing key signs a receipt body containing the
scope, the boundaries, the validity window, and a hash of the
operator's stated instructions. Any later deviation between the
committed instructions and the delivered instructions is detectable
by recomputing a hash. The receipt is a small, self-contained,
verifiable claim: this key authorized this scope for this agent
during this window under these instructions.
Two things this document is not. It is not a control that stops a
malicious operator. An operator who controls the runtime can simply
not run the checks, and no signature prevents that. The receipt is
an audit and attribution layer for honest deployments: it makes
misbehavior provable after the fact, not impossible. Readers who
need that distinction spelled out will find it in Section 11.
It is also not a new cryptographic invention. Earlier versions of
this draft defined a custom signature over non-canonical JSON, which
was a mistake: it made every implementation a snowflake and made
interop with anything else needless work. Version -11 fixes that by
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".
Nelson Expires 24 April 2027 [Page 4]
Internet-Draft Agent Delegation Receipts October 2026
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.
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.
*Grant Layer Authority:* The standing delegation: who may do what,
within which bounds, for how long. Permissions established at
authorization time, defining what an agent is allowed to do in
principle. In OAuth deployments this is typically the authorization
server's grant, expressed as scopes or rich authorization requests
[RFC9396].
*Execution Layer Evidence:* A verifiable, non-repudiable record
generated when a specific action is taken, proving the execution was
covered by a Grant Layer Authority. A Delegation Receipt is
Execution Layer Evidence for the grant it chains to.
*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.
Nelson Expires 24 April 2027 [Page 5]
Internet-Draft Agent Delegation Receipts October 2026
*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;
its "signerPublicKey" MUST match the parent's "delegateeKey" (holder
binding, Section 8.7).
*Delegation Chain:* A root receipt plus zero or more sub-receipts
linked by parentReceiptId, each hop narrowing scope. The root is at
depth 0. A chain of length zero -- a root receipt with no sub-
receipts -- is a complete delegation, called a terminal delegation
(Section 8.8), not a degenerate case.
*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
Nelson Expires 24 April 2027 [Page 6]
Internet-Draft Agent Delegation Receipts October 2026
synonym for a Delegation Receipt where the payment context applies.
The deliberate difference: AP2 is scoped to payments and commerce and
produces pre-transaction authorization evidence. This draft's
receipt is a general-purpose authorization and audit artifact that
covers arbitrary agent actions, and deployments pair it with a signed
log of what was actually done. (AP2 chain details summarized from
third-party technical write-ups; the AP2 specification text itself
was not directly reviewed for this draft: unverified.)
*PACT (Decagon Personal Agent Consent & Trust Protocol).* PACT
defines businesses issuing signed delegation tokens to personal
agents over OAuth 2.0 and A2A, with a signed receipt on every reply.
PACT's per-reply receipt is a compact JWS carrying grant, user,
agent, brand, scopes-used, and action claims. This draft's JWS
profile (Section 6) is intentionally compatible in shape with that
approach: a compact JWS over a JSON claim set. The deliberate
difference: PACT is a consent protocol between a customer, a personal
agent, and a business, with short-lived tokens (delegation tokens
valid at most an hour, request JWTs at most five minutes). This
draft covers user-to-operator delegation with longer windows and adds
the pre-execution gate, scope attenuation across agent-to-agent hops,
and cascade revocation, which PACT's published material does not
define (PACT claim names and lifetimes summarized from an independent
spec teardown; the normative PACT text was not directly reviewed:
unverified).
*ERC-8004 ("Trustless Agents").* ERC-8004 defines three on-chain
registries: Identity (ERC-721 based agent identifiers), Reputation
(feedback signals), and Validation (third-party verification of
work). This draft uses "registry" in the same spirit for its
revocation registry (Section 9), but the two are different layers:
ERC-8004 standardizes who an agent is and what others say about it;
this draft standardizes what a specific key authorized a specific
agent to do. They are complementary, not overlapping.
*UCAN (User Controlled Authorization Networks).* UCANs are capability
tokens (JWTs binding issuer to audience) with "prf" proof chains and
attenuation semantics: each delegation may only narrow the
capabilities of its parent. This draft's delegation chain and scope
attenuation rules (Section 8) follow the same principle, and this
document uses "attenuation" in UCAN's sense. The deliberate
difference: UCAN is a general capability-token format; this draft
adds the receipt-as-audit-trail (instruction pinning, signed action
log, revocation registry), which UCAN does not define. (UCAN field
details summarized from secondary write-ups; the UCAN specification
has been stale since March 2024: unverified.)
Nelson Expires 24 April 2027 [Page 7]
Internet-Draft Agent Delegation Receipts October 2026
*W3C Verifiable Credentials.* AP2's mandates are expressed as SD-JWT
VCs. This draft does not use the VC data model: a Delegation Receipt
is a JWS (or COSE) over a fixed claim set, not a credential with
selective disclosure. Deployments that need selective disclosure
should use AP2's mandate format for the payment portions of a
workflow and this draft's receipt for the general authorization
record.
*IETF drafts.* Two individual drafts cover adjacent ground: draft-
liu-agent-operation-authorization (verifiable human delegation of
specific operations to AI agents) and draft-mishra-oauth-agent-grants
(Delegated Agent Authorization Protocol: persistent agent identity,
multi-agent delegation, tamper-evident audit). Both are cited
informatively; neither was reviewed in full for this revision
(unverified).
*OAuth 2.0.* This document does not compete with the authorization
server for the initial human consent event. Where an authorization
server (AS) is in the loop, its consent record is the attributable
authorization for the first hop. The receipt chain covers what the
AS does not see: downstream delegation hops, offline execution, and
multi-agent chains with no common AS. The receipt is Execution Layer
Evidence (Section 2.4) for a Grant Layer Authority that may originate
at an AS; the two compose rather than overlap. A principal-signed
root adds one thing an AS consent record does not: proof that the
human principal, and not the operator, authorized the delegation, and
only when the authorizing key meets the custody requirements of
Section 4.6.
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.
2.4. What a receipt proves
A Delegation Receipt is Execution Layer Evidence
[CHEN-AGENT-USE-CASES] for a Grant Layer Authority: it proves that a
specific execution was covered by the grant's terms. A verifier
checking a receipt answers one question: was this action within the
scope, boundaries, and validity window the authorizing key signed,
under the instructions committed at issuance? The verifier MUST NOT
re-adjudicate the principal's intent per action; intent was settled
when the grant was made.
Coverage and parameters are proved by different fields, and both are
required for the full claim:
Nelson Expires 24 April 2027 [Page 8]
Internet-Draft Agent Delegation Receipts October 2026
* *Coverage:* "scope" / "scopeSchema", "boundaries", and
"timeWindow" prove the execution fell inside the grant.
* *Parameters:* "instructionsHash" pins the concrete operator
instructions committed at issuance; recomputation at execution
time detects drift (Section 4.2).
A receipt that proves coverage but whose instructions cannot be
reconciled with what was delivered proves an authorized envelope
around an unverified action. Deployments that need per-action
approval semantics MUST NOT read them into this document: the receipt
proves the execution was covered, not that the principal reviewed
each action.
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 24 April 2027 [Page 9]
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 24 April 2027 [Page 10]
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 24 April 2027 [Page 11]
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. Its presence marks the
receipt as a sub-receipt and triggers chain checks (Section 8.7,
Section 10).
delegateeKey (JWK, OPTIONAL): The public key of the delegatee -- the
party authorized to hold this receipt and mint sub-receipts under
it. Same JWK constraints as "signerPublicKey" (Section 4.2):
exactly the members "kty", "crv", "x", and "y"; no private
material. Present on any receipt under which sub-receipts may be
issued. A receipt that carries no "delegateeKey" is terminal: no
sub-receipt may be issued under it (Sections 8.7, 8.8).
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").
Nelson Expires 24 April 2027 [Page 12]
Internet-Draft Agent Delegation Receipts October 2026
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:* DEPRECATED as of -15. The holder-binding
rule (Sections 4.3, 8.7) subsumes it: the parent-child link is now
bound by the parent's "delegateeKey" matching the child's
"signerPublicKey", with "parentReceiptId" in the signed child body.
Issuers conforming to this revision MUST NOT emit
"orchestratorSignature". Verifiers MUST NOT require it and MUST NOT
treat its presence as satisfying holder binding. It remains
parseable so pre-15 receipts stay readable for audit; it carries no
authorization meaning under this revision.
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.
Nelson Expires 24 April 2027 [Page 13]
Internet-Draft Agent Delegation Receipts October 2026
* *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. 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.
4.6. Authorizing key requirements
A Delegation Receipt's non-repudiation claim (Section 11.1) holds
only if the authorizing key is under the human principal's sole
control. For a root receipt to carry that claim, the authorizing key
MUST satisfy all of the following:
* *Non-exportable:* the private key MUST NOT be extractable from the
store that holds it, by the principal, the operator, or anyone
else.
* *Gated on user verification:* each signing operation MUST require
an explicit user-verification gesture (for example, a biometric
check or PIN entry on a platform authenticator). Cached,
standing, or pre-authorized signing sessions MUST NOT satisfy this
requirement.
* *Sole control:* no party other than the human principal holds a
copy of, or signing access to, the private key.
A signing ceremony the agent can complete without the human -- a
click-through dialog, a pre-approved auto-signing rule, a standing
delegation the agent invokes on its own -- is not a human grant. A
receipt produced under such a ceremony MUST NOT be presented as non-
repudiable evidence of the human principal's authorization; it is
operator-asserted evidence at best, and deployments MUST label it as
such where the distinction matters.
Nelson Expires 24 April 2027 [Page 14]
Internet-Draft Agent Delegation Receipts October 2026
How these properties are achieved is deployment-defined and out of
scope (Section 15). FIDO2 / WebAuthn platform authenticators
[WebAuthn] are RECOMMENDED as the mechanism: they provide non-
exportable keys gated on user verification as a commodity.
The receipt format itself cannot prove key custody from the receipt
bytes alone. Custody is attested by the deployment, not proven by
the format. A verifier that needs the non-repudiation claim MUST
obtain the custody attestation through a channel outside the receipt
before treating the receipt as the human principal's act.
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 24 April 2027 [Page 15]
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" (where "drp" abbreviates
"delegation 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 24 April 2027 [Page 16]
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. (Reference-implementation
test vectors cover Ed25519; second-implementation interop evidence
is P-256 only.)
* *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 bytes a compact serialization
of the same receipt would contain: the ASCII of the protected-header
segment, a period, BASE64URL(JCS body bytes), a period, and the
signature segment. 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 24 April 2027 [Page 17]
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 24 April 2027 [Page 18]
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".
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" with constraints equal or broader:
the child's denial MUST cover at least the authority the parent's
denial covered (a denial pattern in the child MUST match every
string the parent's pattern matched, and a numeric denial bound
in the child MUST NOT be smaller than the parent's). A child MAY
add denials but MUST NOT drop or narrow any.
4. For each constraint key in a parent entry for an
"operation::resource" key, the child entry for the same key MUST
carry that constraint key with a value authorizing no more than
Nelson Expires 24 April 2027 [Page 19]
Internet-Draft Agent Delegation Receipts October 2026
the parent's: a numeric limit in the child MUST NOT exceed the
parent's value, and a wildcard pattern in the child MUST NOT
match strings the parent's pattern does not match. Dropping or
renaming a parent constraint key is a violation: for constraints,
fewer keys means more authority. Profiles MAY define narrowing
for other constraint value forms.
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 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. Holder binding: if the parent body carries no "delegateeKey", the
parent is terminal and issuance MUST fail. Otherwise the
issuer's signing key MUST be the key named in the parent's
"delegateeKey" (compared as [RFC7638] SHA-256 thumbprints);
issuance MUST fail on mismatch. The child body MUST carry
"parentReceiptId" and its own "signerPublicKey", which is the key
just matched.
2. Resolve the parent's scope ("scopeSchema" if present, else the
text "scope" field; structured scope is REQUIRED for machine-
checked attenuation).
Nelson Expires 24 April 2027 [Page 20]
Internet-Draft Agent Delegation Receipts October 2026
3. 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).
4. Build the child body including "parentReceiptId", sign it per the
active profile (Section 6 or 7).
5. Compute the child "receiptId" (Sections 6.6, 7). No further
binding artifact is needed: the parent-child link is established
by the child's "parentReceiptId" in the signed body together with
the holder-binding key match of step 1. Issuers conforming to
this revision MUST NOT emit "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.
Verifiers MUST check, for any receipt carrying "parentReceiptId": the
parent's signature is valid; the parent body carries a "delegateeKey"
(a parent without one is terminal, and any child presented under it
MUST be denied); the sub-receipt's "signerPublicKey" matches the
parent's "delegateeKey" ([RFC7638] SHA-256 thumbprint comparison);
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.
Cross-format chains: a sub-receipt presented under a parent expressed
in a receipt format with no delegateeKey concept MUST be denied.
Holder binding cannot be evaluated across formats, so the chain
cannot be verified.
Receipts carry no wire version marker, so a pre-15 receipt and a
receipt that is terminal by intent are indistinguishable on the wire;
both are terminal, and issuance of a sub-receipt under either MUST
fail. There is no grandfathering of pre-15 chains.
Nelson Expires 24 April 2027 [Page 21]
Internet-Draft Agent Delegation Receipts October 2026
A parallel key-binding mechanism appears in [WEI-AIC-JWT] as
"da.agent_key_binding.key_hash", where the verifier requires the
presenting key to match the bound hash before accepting the token.
The mechanisms differ in key representation (SPKI hash there,
[RFC7638] thumbprint here) and in that this document applies the
check at every delegation hop.
8.8. Terminal delegation
A delegation terminates at the delegate when the authorizing party
intends no further sub-delegation. A receipt with no sub-receipts is
a complete, verifiable delegation on its own: verifiers apply
Sections 4-7 and 9 without chain walking.
Cryptographic termination: a receipt that carries no "delegateeKey"
(Section 4.3) is terminal. Issuance of a sub-receipt under a
terminal receipt MUST fail (Section 8.7). Deployments that intend a
delegation to be non-delegable SHOULD omit "delegateeKey" rather than
relying on policy alone.
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 15);
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
Nelson Expires 24 April 2027 [Page 22]
Internet-Draft Agent Delegation Receipts October 2026
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".
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
Nelson Expires 24 April 2027 [Page 23]
Internet-Draft Agent Delegation Receipts October 2026
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 check ordering, gate-signing, audit-log format, and replay-guard
behaviors in this section are requirements of the Pre-Execution
Verification profile only. They are not requirements of the receipt
format, and a verifier that implements the semantics of Sections 4-9
with different plumbing conforms to this document but does not claim
the profile.
The gate runs checks sequentially and stops at the first failure
(fail closed). Implementations MAY add diagnostic prefixes (such as
a per-hop prefix) to the codes named here; the unprefixed code is the
interoperable identifier. The implemented checks, in order:
1. Receipt signature valid (over the canonical body; attached
signatures excluded from the signed input).
2. Receipt not revoked (registry check; offline fail-closed per
Section 9.4).
3. Within time window (a timestamp from the deployment's tamper-
evident log 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").
Nelson Expires 24 April 2027 [Page 24]
Internet-Draft Agent Delegation Receipts October 2026
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, holder binding holds (child "signerPublicKey" matches
parent "delegateeKey"; parent without "delegateeKey" is terminal
and the child is denied), 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. Within the chain walk,
"stops at the first failure" applies per hop: a failed hop skips
its remaining checks while the walk continues to later hops.
15. Authority state drift (optional; "authorityStateCommitment";
policy "block" denies with AUTHORITY_STATE_DRIFT, otherwise a
re-authorization flag is set).
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.
| Implementation note -- known deviation (carried from the
| reference 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. This deviation imposes no conformance requirement;
| it documents where the reference implementation does not yet
| meet this document's rule.
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.
Nelson Expires 24 April 2027 [Page 25]
Internet-Draft Agent Delegation Receipts October 2026
*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
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.
*Rogue operator root.* The non-repudiation claim above is about the
key holder, not necessarily the human principal. An operator who
holds (or can invoke) the authorizing key can sign a well-formed root
receipt the human never saw. Section 4.6 states the key-custody
properties under which the key holder and the human principal
coincide; without them, a valid signature proves only that whoever
held the key signed.
11.2. Limitations
What receipts cannot do, stated without hedging:
Nelson Expires 24 April 2027 [Page 26]
Internet-Draft Agent Delegation Receipts October 2026
* *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 15). A
compromised signing key voids every guarantee in this document.
Section 4.6 now specifies the properties the authorizing key MUST
have for the non-repudiation claim to hold; the mechanisms that
achieve those properties remain the deployer's problem.
Nelson Expires 24 April 2027 [Page 27]
Internet-Draft Agent Delegation Receipts October 2026
* *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.
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.
Nelson Expires 24 April 2027 [Page 28]
Internet-Draft Agent Delegation Receipts October 2026
13. Binding to OAuth
This section sketches how an authorization server or resource server
ties an access token to the Delegation Receipt that authorized the
underlying delegation. It is informative: the "delegation_receipt"
authorization_details type sketched here is not registered by this
document, and the names below are sketches, not final registered
names.
When an AS issues (or a client requests) an access token for an agent
acting under a Delegation Receipt, the authorization_details
[RFC9396] object MAY carry:
{
"type": "delegation_receipt",
"receipt_id": "<receiptId of the root receipt, hex64>",
"delegatee_key_thumbprint": "<RFC 7638 SHA-256 thumbprint of the
delegateeKey JWK named in the receipt>"
}
A resource server holding such a token can resolve "receipt_id"
through whatever receipt distribution the deployment provides, verify
the receipt chain per Sections 4-9, and confirm the delegatee key
thumbprint matches the key the agent authenticates with. The token
proves the AS's grant; the receipt proves the human principal's
delegation behind it. Either may be checked without the other, but
only together do they answer both "what was the AS asked for" and
"who authorized the agent to act."
Deployments that cannot carry authorization_details MAY use an
equivalent token claim carrying the same two values; the claim name
is deployment-defined until a registered name exists.
14. 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.
15. 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. The required properties of the
authorizing key are specified in Section 4.6; the mechanisms are
not specified here.
Nelson Expires 24 April 2027 [Page 29]
Internet-Draft Agent Delegation Receipts October 2026
* *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.
16. References
16.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>.
[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>.
Nelson Expires 24 April 2027 [Page 30]
Internet-Draft Agent Delegation Receipts October 2026
[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>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "Rich
Authorization Requests (RAR)", RFC 9396, February 2024,
<https://www.rfc-editor.org/rfc/rfc9396>.
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, September 2015,
<https://www.rfc-editor.org/rfc/rfc7638>.
16.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.
Nelson Expires 24 April 2027 [Page 31]
Internet-Draft Agent Delegation Receipts October 2026
[WebAuthn] W3C, "Web Authentication: An API for accessing Public Key
Credentials Level 2", W3C Recommendation, April 2021.
[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>.
[CHEN-AGENT-USE-CASES]
Chen, M., Chen, J., Yao, J., Jiang, Y., Liu, C.P., and X.
Liu, "Agent Authorization use cases and gap analysis",
Work in Progress, Internet-Draft, draft-chen-oauth-agent-
authz-use-cases, October 2026,
<https://datatracker.ietf.org/doc/html/draft-chen-oauth-
agent-authz-use-cases>.
[WEI-AIC-JWT]
Wei, J., "AI Agent Identity Certificate (AIC) JSON Web
Token Profile", Work in Progress, Internet-Draft, draft-
wei-aic-jwt, October 2026,
<https://datatracker.ietf.org/doc/html/draft-wei-aic-jwt>.
[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/>.
Nelson Expires 24 April 2027 [Page 32]
Internet-Draft Agent Delegation Receipts October 2026
[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>.
[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",
Nelson Expires 24 April 2027 [Page 33]
Internet-Draft Agent Delegation Receipts October 2026
"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.
Nelson Expires 24 April 2027 [Page 34]
Internet-Draft Agent Delegation Receipts October 2026
A.3. JWS compact serialization (ES256)
Protected header: {"alg":"ES256","typ":"drp-receipt"}, base64url:
eyJhbGciOiJFUzI1NiIsInR5cCI6ImRycC1yZWNlaXB0In0
The full compact serialization (header.payload.signature), EXAMPLE:
eyJhbGciOiJFUzI1NiIsInR5cCI6ImRycC1yZWNlaXB0In0.eyJhZ2VudElkIjoiY2FsZW5kYXItYWdlbnQtMDEiLCJib3VuZGFyaWVzIjoibmV2ZXIgc2VuZCBlbWFpbCB3aXRob3V0IGV4cGxpY2l0IGNvbmZpcm1hdGlvbjsgbmV2ZXIgZGVsZXRlIGNhbGVuZGFyIGV2ZW50cyIsImRlbGVnYXRpb25JZCI6ImF1dGgtMTc5MDAwMDAwMDAwMC1hMWIyYyIsImluc3RydWN0aW9uc0hhc2giOiJjNzMwZGU3NThlNTg2ZTE5YTgxMDk4ZmExY2Q0MDcyMTE2MmRhOTgxN2ZhN2Y3ZTY1MTUyNGEyN2M5M2VlNGZiIiwiaXNzdWVkQXQiOiIyMDI2LTEwLTA5VDEyOjAwOjAwLjAwMFoiLCJtZXRhZGF0YSI6eyJzZXNzaW9uIjoiZGVtby0wMDEifSwib3BlcmF0b3JJbnN0cnVjdGlvbnMiOiJSZWFkIHRvZGF5J3MgY2FsZW5kYXIgZXZlbnRzIGFuZCBkcmFmdCBhIHN1bW1hcnkgZm9yIHRoZSAycG0gc3RhbmR1cC4iLCJzY29wZSI6InJlYWQgY2FsZW5kYXIgZXZlbnRzIGFuZCBkcmFmdCBtZWV0aW5nIHN1bW1hcmllcyIsInNjb3BlU2NoZW1hIjp7ImFsbG93ZWRBY3Rpb25zIjpbeyJvcGVyYXRpb24iOiJyZWFkIiwicmVzb3VyY2UiOiJjYWxlbmRhci9ldmVudHMifSx7ImNvbnN0cmFpbnRzIjp7Im1heEV2ZW50cyI6MTB9LCJvcGVyYXRpb24iOiJ3cml0ZSIsInJlc291cmNlIjoiY2FsZW5kYXIvZHJhZnRzIn1dLCJkZW5pZWRBY3Rpb25zIjpbeyJvcGVyYXRpb24iOiJkZWxldGUiLCJyZXNvdXJjZSI6ImNhbGVuZGFyL2V2ZW50cyJ9XSwidmVyc2lvbiI6IjEuMCJ9LCJzaWduZXJQdWJsaWNLZXkiOnsiY3J2IjoiUC0yNTYiLCJrdHkiOiJFQyIsIngiOiI4YndnTDVVM2wwSTdua2JjVEpSY2p6VGVWMG42V3pjZ20tS1N0UXdiSEVvIiwieSI6IjdTTXJXbXhQZXRZd2EwTHZBWDR0cEdBMU9rRVZCdGt2aHFoX29MaDMtMjgifSwidGltZVdpbmRvdyI6eyJlbmQiOiIyMDI2LTEwLTA5VDEzOjAwOjAwLjAwMFoiLCJzdGFydCI6IjIwMjYtMTAtMDlUMTI6MDA6MDAuMDAwWiJ9LCJ0cnVzdGVkU291cmNlcyI6WyJ1c2VyIiwic3lzdGVtX3Byb21wdCJdfQ.x-25GCeZP17YIXVxETe10cwsg2_Qui7X412Ubx0q64H4uq6jta8f1n4O9bqOeFLaVArHCgwv--_TuscMJwttlw
The signature is the raw 64-byte R||S concatenation required by
Section 6.3 (RFC 7518 Section 3.4). The receiptId is the SHA-256 hex
of the ASCII bytes of that string:
061cef91d98ef21ad9ba2550f1d71b8e16717c97e008282d6a10523a7a838199
A.4. Detached form (RFC 7797)
With header {"alg":"ES256","b64":false,"crit":["b64"]} and the same
JCS bytes supplied out of band, the transmitted form is
header..signature (EXAMPLE):
eyJhbGciOiJFUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..T_iG4gR4ms4pMp5RXGz7NNieNQkF_9oBwEYCFZWZ7Kig_WWUaLlFhvWS_wvpw3-B8HQww7dq1KiLgaDRkitvUw
A.5. Example key (DO NOT USE)
Public JWK:
{
"kty": "EC",
"crv": "P-256",
"x": "8bwgL5U3l0I7nkbcTJRcjzTeV0n6Wzcgm-KStQwbHEo",
"y": "7SMrWmxPetYwa0LvAX4tpGA1OkEVBtkvhqh_oLh3-28"
}
The corresponding private "d" value (published so the example is
reproducible; throwaway):
nvTRYETQC0GN4fA2Q8Fe9am6PG8xlfXqXsjvs1eeaZw.
To re-verify: base64url-decode the payload segment, confirm it is
byte-identical to the JCS form in Section A.2, then verify the ES256
signature over ASCII(headerSegment || "." || payloadSegment) with the
public JWK above, using the raw 64-byte R||S form per RFC 7518
Section 3.4.
Nelson Expires 24 April 2027 [Page 35]
Internet-Draft Agent Delegation Receipts October 2026
Appendix B. Changes from -14 to -15
-15 (October 2026) aligns the draft with the grant/execution split of
[CHEN-AGENT-USE-CASES]: the receipt as Execution Layer Evidence under
a Grant Layer Authority, with delegatee holder binding for sub-
receipts, an OAuth binding sketch so a token can point at its
receipt, and normative requirements for the authorizing key's
custody. It incorporates reviewer feedback from Caleb Dayton
(private correspondence) and Kieran Sweeney (OAuth list) and WIMSE-
list comments from Jeff Lombardo.
*Scoping rule: what a receipt proves.* New Section 2.4 states the
receipt's job normatively: it proves the execution was covered by the
grant's terms -- scope, boundaries, and validity window -- without
re-adjudicating the principal's intent per action. Section 2.2 gains
"Grant Layer Authority" and "Execution Layer Evidence" definitions
drawn from [CHEN-AGENT-USE-CASES]. The receipt proves both coverage
(scope/window) and concrete parameters (instructionsHash); it does
not re-decide intent.
*OAuth composition and binding sketch.* Section 2.3 now states the
composition position: where an authorization server is in the loop,
its consent record is the attributable authorization for the first
hop; the receipt chain covers the downstream hops the AS does not
see. New informative Section 13 sketches an authorization_details
type ("delegation_receipt") carrying the receipt identifier and the
delegatee key thumbprint, so an AS or RS can tie an access token to
its receipt. The type is not registered by this document; the names
are sketches.
*Terminate at the delegate.* A chain of length zero -- a root receipt
with no sub-receipts -- is now named a terminal delegation
(Section 8.8): a complete pattern, not a degenerate case. A receipt
carrying no "delegateeKey" is cryptographically terminal: issuance of
a sub-receipt under it MUST fail.
*Authorizing-key requirements.* New Section 4.6 states the normative
properties the authorizing key MUST have for the non-repudiation
claim to hold: non-exportable, gated on user verification per signing
operation, and under the human principal's sole control. A signing
ceremony the agent can complete without the human is not a human
grant. Section 11.1 gains the rogue-operator-root paragraph;
Sections 11.2 and 15 qualify the key-management limitation.
Mechanisms remain out of scope; FIDO2/WebAuthn platform
authenticators are RECOMMENDED.
Nelson Expires 24 April 2027 [Page 36]
Internet-Draft Agent Delegation Receipts October 2026
*Sub-receipt holder binding (breaking change).* Section 4.3 gains an
OPTIONAL "delegateeKey" (JWK): the public key of the delegatee.
Section 8.7 now requires the child's "signerPublicKey" to match the
parent's "delegateeKey" ([RFC7638] SHA-256 thumbprint comparison) at
issuance and verification; a parent without "delegateeKey" is
terminal. "orchestratorSignature" is DEPRECATED (Section 4.4):
issuers MUST NOT emit it, verifiers MUST NOT require it; it remains
parseable for audit of pre-15 receipts. This closes the bearer-copy
issuance gap found in review: under -14, anyone holding a copy of a
parent receipt could mint a narrower child passing every chain check.
Existing -14 chain vectors that lack "delegateeKey" fail under -15
rules by design; single-receipt (terminal) vectors are unaffected.
The "delegateeKey" field is a wire-format addition; -14-era verifiers
will reject receipts carrying it, which is the intended fail-closed
version behavior.
*Conformance boundary sharpened.* Section 10 now states explicitly
that its check ordering, gate-signing, audit-log format, and replay-
guard behaviors are requirements of the Pre-Execution Verification
profile only, not of the receipt format. The known implementation
deviation is restated as a non-normative implementation note. Check
14 now orders the holder-binding rule. Section 8.7 cites the
parallel holder-binding design of [WEI-AIC-JWT] as an informative
reference.
*Submission metadata.* The document element again carries
submissionType="IETF", reverting its removal in -14.
Appendix C. 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". The reference pattern needs no new
fields: the delegation receipt remains the authorization record.
*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
Nelson Expires 24 April 2027 [Page 37]
Internet-Draft Agent Delegation Receipts October 2026
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 D. 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.
No wire-format changes from -12: the JWS and COSE_Sign1 profiles, the
field set, and the verification gate are otherwise unchanged.
Nelson Expires 24 April 2027 [Page 38]
Internet-Draft Agent Delegation Receipts October 2026
Appendix E. 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 24 April 2027 [Page 39]