Signed Execution Receipts for AI Agent Tool Calls (XAIP Receipts)
draft-xkumakichi-xaip-receipts-03
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 | XAIP | ||
| Last updated | 2026-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Live trust score dashboard
XAIP protocol reference implementation |
||
| 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-xkumakichi-xaip-receipts-03
Independent Submission xkumakichi
Internet-Draft 2 July 2026
Intended status: Informational
Expires: 3 January 2027
Signed Execution Receipts for AI Agent Tool Calls (XAIP Receipts)
draft-xkumakichi-xaip-receipts-03
Abstract
This document defines a wire format for signed execution receipts
produced by AI agents when they invoke tools, services, or other
agents. A receipt records the minimum facts needed to make a trust
decision about a future call: who acted, who delegated, what tool was
used, whether the call succeeded, how long it took, and how the
call's inputs and outputs are identified (without disclosing their
contents).
A distinguishing property of the format is optional caller co-
signature over the same canonical per-call record. When both
signatures validate, the receipt cryptographically binds the
identified Caller and Agent to the same canonical payload. This does
not establish that either party independently observed every field,
that the recorded execution was correct, or that the parties did not
collude. A receipt may carry the Agent signature alone, and
consumers may distinguish the two cases according to deployment
policy.
The format is intentionally tool-system-agnostic. The same receipt
structure can be emitted by MCP (Model Context Protocol) servers,
LangChain.js callback handlers, OpenAI tool-calling loops, HTTP
clients, or proprietary agent runtimes. Receipts use Ed25519
signatures over a JCS-canonicalized payload, and identities are W3C
Decentralized Identifiers (DIDs).
This revision introduces an explicit wire-format version
(formatVersion), pins the hash preimage profile, and ships executable
conformance test vectors.
Scoring policy, aggregation architecture, and reactive behavior in
response to receipts are explicitly out of scope and left to
deployments.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
xkumakichi Expires 3 January 2027 [Page 1]
Internet-Draft XAIP Receipts July 2026
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 3 January 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 3
1.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Conventions and Definitions . . . . . . . . . . . . . . . 4
1.4.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
2. Receipt Structure . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Canonical Payload and Signing . . . . . . . . . . . . . . . . 8
3.1. Canonical Payload . . . . . . . . . . . . . . . . . . . . 8
3.2. Signing Algorithm . . . . . . . . . . . . . . . . . . . . 9
3.3. Verification . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Format Versioning and Legacy Receipts . . . . . . . . . . 10
3.5. Hash Preimage Profile . . . . . . . . . . . . . . . . . . 10
4. SigningDelegate Pattern (Caller Co-signature) . . . . . . . . 11
5. Failure Type Classification . . . . . . . . . . . . . . . . . 12
6. Tool Metadata (Optional) . . . . . . . . . . . . . . . . . . 13
7. Identity (DID) Requirements . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. Caller-Side Forgery . . . . . . . . . . . . . . . . . . . 14
8.4. Single-Observer Dominance . . . . . . . . . . . . . . . . 14
xkumakichi Expires 3 January 2027 [Page 2]
Internet-Draft XAIP Receipts July 2026
8.5. Key Compromise . . . . . . . . . . . . . . . . . . . . . 14
8.6. Timestamp Trust . . . . . . . . . . . . . . . . . . . . . 15
8.7. Co-signature Trust Boundary . . . . . . . . . . . . . . . 15
9. Known Limitations . . . . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Relationship to the XAIP Reference Implementation . 17
Appendix B. Adoption Path for Agent-Payment Protocols . . . . . 18
Appendix C. Relationship to Adjacent Receipt and Audit
Formats . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix D. Conformance Test Vectors . . . . . . . . . . . . . . 19
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
1.1. Motivation
AI agents increasingly act on behalf of users: they pick tools, call
APIs, delegate to other agents, and -- in some deployments --
participate in transaction workflows. Each of those actions is
preceded by an implicit trust decision: which tool should I use, and
is it likely to do what I expect?
Today, that decision is mostly answered by upstream proxies --
whether the tool's name appears in a model's training data, whether a
registry surfaces it, whether a platform recommends it. None of
these proxies record what the tool actually did in real calls. There
is no widely-deployed, interoperable record format that an agent (or
an agent-payment protocol, or an audit system) can use to look back
and answer "what happened the last N times this tool was called?"
This document defines such a format. It is intentionally narrow: it
covers the wire format for one receipt. How receipts are stored,
aggregated, queried, scored, or reacted to is a deployment-policy
concern and is out of scope.
1.2. Design Principles
* Wire format only. Scoring models, aggregation topologies, and
decision logic are deployment choices, not protocol requirements.
* Tool-system-agnostic. The same receipt can be produced by MCP,
LangChain, OpenAI tool calling, plain HTTP, or proprietary
runtimes.
xkumakichi Expires 3 January 2027 [Page 3]
Internet-Draft XAIP Receipts July 2026
* Content-minimizing. Receipts identify inputs and outputs by hash
rather than embedding their contents. This reduces direct
disclosure but does not make low-entropy or guessable values
private; see the Security Considerations.
* Independently verifiable. Anyone holding the receipt and the
public keys can verify the signatures without consulting any
registry or trusted third party.
* Mechanically checkable. Every processing rule in this document is
exercised by the executable test vectors described in the
appendices; a conforming implementation can be validated byte-for-
byte without interpreting prose.
* Co-signature supported. The Caller can sign the same canonical
payload as the Executor (Agent). A receipt verifies as co-signed
only when valid signatures for both the identified Caller and
Agent are present. The degree to which those signatures represent
operationally independent assertions depends on the control
separation described in the Security Considerations.
1.3. Out of Scope
This document does NOT define:
* A scoring model. Trust scores derived from receipts are
deployment policy.
* An aggregation architecture. Receipts can be stored locally,
federated, anchored, or relayed in any pattern.
* A query API. Consumers may serve receipts and/or derived data
over any protocol they choose.
* Identity priors. If a deployment chooses to weight different DID
methods differently, that is deployment policy.
* A specific transport. Receipts may be exchanged over HTTP, MCP,
message queues, or any other carrier.
1.4. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.4.1. Terminology
Agent: An automated system, typically an AI agent, that invokes
tools, services, or other agents on a principal's behalf.
Caller: The party that delegated the tool call to the Agent. Often
(but not always) the same legal entity as the Agent's principal.
Tool: A named operation invoked by the Agent. The tool
xkumakichi Expires 3 January 2027 [Page 4]
Internet-Draft XAIP Receipts July 2026
implementation may be local code, an MCP server, an HTTP API, a
sub-agent, or any callable target.
Receipt: A signed record of a single Tool execution attempt.
Executor signature: The signature produced by the Agent that ran the
tool.
Caller signature: The signature produced by the Caller over the same
canonicalized payload as the Executor signature.
DID: Decentralized Identifier, as defined in the W3C DID Core
specification [DID-CORE].
Legacy receipt: A receipt produced before this revision, carrying no
formatVersion member (see Section 3.4).
2. Receipt Structure
A receipt is a JSON object with the following fields:
+===============+==========+===========+============================+
|Field |Type |Required |Description |
+===============+==========+===========+============================+
|formatVersion |string |yes (this |MUST be "1" for receipts |
| | |revision) |conforming to this |
| | | |revision. Part of the |
| | | |canonical payload |
| | | |(Section 3.1). Receipts |
| | | |without this member are |
| | | |legacy receipts; see |
| | | |Section 3.4. |
+---------------+----------+-----------+----------------------------+
|agentDid |string |yes |The Agent that executed the |
| |(DID) | |tool. |
+---------------+----------+-----------+----------------------------+
|callerDid |string |yes |The Caller that delegated |
| |(DID) | |the tool call. MUST be |
| | | |present on formatVersion |
| | | |"1" receipts; it MAY equal |
| | | |agentDid when there is no |
| | | |delegation. |
+---------------+----------+-----------+----------------------------+
|toolName |string |yes |A stable identifier for the |
| | | |tool. Format is opaque to |
| | | |this spec. |
+---------------+----------+-----------+----------------------------+
|taskHash |string |yes |A SHA-256 hash of the task |
| |(64-char | |input, computed per the |
| |hex, | |preimage profile |
| |lowercase)| |(Section 3.5). |
+---------------+----------+-----------+----------------------------+
|resultHash |string |yes |A SHA-256 hash of the task |
xkumakichi Expires 3 January 2027 [Page 5]
Internet-Draft XAIP Receipts July 2026
| |(64-char | |output, computed per the |
| |hex, | |preimage profile |
| |lowercase)| |(Section 3.5). When |
| | | |success is false and no |
| | | |output is committed to, the |
| | | |value MUST be the empty- |
| | | |input sentinel |
| | | |(Section 3.5); when a |
| | | |canonical failure |
| | | |description is committed to |
| | | |instead, the preimage |
| | | |profile applies to it. |
+---------------+----------+-----------+----------------------------+
|success |boolean |yes |true if the tool call |
| | | |satisfied the agent's |
| | | |success criterion, false |
| | | |otherwise. |
+---------------+----------+-----------+----------------------------+
|latencyMs |integer |yes |Wall-clock time from |
| | | |invocation to completion, |
| | | |in milliseconds. MUST be |
| | | |an integer in the range 0, |
| | | |2^53 - 1 (the I-JSON |
| | | |exactly-representable |
| | | |range, which JCS serializes |
| | | |deterministically). |
+---------------+----------+-----------+----------------------------+
|failureType |string |yes |One of the values defined |
| | | |in Section 5 when success |
| | | |is false. When success is |
| | | |true, the value MUST be the |
| | | |empty string "". The |
| | | |member is always present on |
| | | |the wire and in the |
| | | |canonical payload as a |
| | | |(possibly empty) string; |
| | | |null is not used and the |
| | | |member MUST NOT be omitted. |
+---------------+----------+-----------+----------------------------+
|timestamp |string |yes |UTC timestamp of |
| |(RFC 3339)| |completion. formatVersion |
| | | |"1" producers SHOULD render |
| | | |it with exactly three |
| | | |fractional-second digits |
| | | |and the Z designator (e.g. |
| | | |2026-07-02T01:23:45.678Z); |
| | | |a single rendering keeps |
| | | |signature-level |
xkumakichi Expires 3 January 2027 [Page 6]
Internet-Draft XAIP Receipts July 2026
| | | |deduplication (Section 8.2) |
| | | |byte-stable. A future |
| | | |revision may make one |
| | | |rendering mandatory. |
+---------------+----------+-----------+----------------------------+
|signature |string |yes |Ed25519 signature by the |
| |(hex) | |Agent over the canonical |
| | | |payload (Section 3), |
| | | |encoded as exactly 128 |
| | | |lowercase hexadecimal |
| | | |characters (a 64-byte |
| | | |signature). |
+---------------+----------+-----------+----------------------------+
|callerSignature|string |recommended|Ed25519 signature by the |
| |(hex) | |Caller over the same |
| | | |canonical payload, same |
| | | |encoding as signature. See |
| | | |Section 4. |
+---------------+----------+-----------+----------------------------+
|toolMetadata |object |optional |Tool-class or capability |
| | | |hints. Format is |
| | | |deployment-defined; see |
| | | |Section 6. Never part of |
| | | |the canonical payload. |
+---------------+----------+-----------+----------------------------+
Table 1
A receipt SHOULD NOT carry top-level members other than those defined
above. Consumers MUST treat any unknown top-level member as
unauthenticated data: unknown members are not part of the canonical
payload and are not covered by any signature. Producers MUST NOT
rely on unknown members being preserved by intermediaries.
2.1. Example
The following receipt is complete and verifiable: both signatures
validate against the test keys published with the conformance vectors
(Appendix D), and every hash is reproducible from the preimages given
there. The task input is the JSON object {"text": "hello", "target":
"ja"} and the output is a five-character Japanese text string whose
exact value is given in the unicode_string_raw_utf8 conformance
vector.
xkumakichi Expires 3 January 2027 [Page 7]
Internet-Draft XAIP Receipts July 2026
{
"formatVersion": "1",
"agentDid": "did:web:translator.example",
"callerDid": "did:web:orchestrator.example",
"toolName": "translate",
"taskHash":
"a1f15dbb98240bfcd2ae4e21497f0fc011e99397929d2836bff327ff09254103",
"resultHash":
"125aeadf27b0459b8760c13a3d80912dfa8a81a68261906f60d87f4a0268646c",
"success": true,
"latencyMs": 142,
"failureType": "",
"timestamp": "2026-07-02T01:23:45.678Z",
"signature": "1fbf11f917c6404db0476f4542f981b0bd00f3391ffa2a
859f1f700b520228ac13f6d1b8a09394012290830c908d7b7906c4e3498d9dc4
1f2badb8bc7de97905",
"callerSignature": "5dadd87738832b65557072e15877ace0abe74f9c21
ea7c32cc64b838e4379f6e15f974ff05aa65f4adcc320c01a4b0d4dc72bc154f
cc12af7b696b485a51c40c"
}
(The two signature values are single hex strings; they are wrapped
here for line-length reasons only.)
3. Canonical Payload and Signing
3.1. Canonical Payload
The signed payload is the JSON object containing the following
fields, in this order after lexicographic sorting per [RFC8785]:
agentDid, callerDid, failureType, formatVersion, latencyMs,
resultHash, success, taskHash, timestamp, toolName
For receipts conforming to this revision, formatVersion MUST be
present with the value "1" and is part of the signed payload. For
legacy receipts (Section 3.4) the payload contains the nine remaining
fields only.
The signature, callerSignature, and toolMetadata fields are excluded
from the canonical payload. Implementations producing receipts MUST
canonicalize using JCS as defined in [RFC8785].
Verifiers MUST recompute the canonical payload from the receipt's
field values exactly as received. In particular, verifiers MUST NOT
apply Unicode normalization (NFC, NFD, NFKC, or NFKD) or any other
transformation to field values before canonicalization; a storage or
transport layer that normalizes strings will render legitimately
xkumakichi Expires 3 January 2027 [Page 8]
Internet-Draft XAIP Receipts July 2026
signed receipts unverifiable. Producers SHOULD emit NFC-normalized
strings. Compatibility normalization (NFKC/NFKD) MUST NOT be applied
at any layer: it can fold visually or semantically distinct
identifiers (for example, two different toolName values) into one.
The taskHash and resultHash fields MUST contain a SHA-256 digest as
defined in [RFC6234], encoded as exactly 64 lowercase hexadecimal
characters. Because a receipt carries no hash-algorithm identifier,
verifiers MUST interpret both fields as SHA-256 in this version.
Supporting additional hash algorithms would require a future revision
of the formatVersion mechanism (Section 3.4).
3.2. Signing Algorithm
Signatures are computed using Ed25519, as defined in [RFC8032]. The
signature input is the UTF-8 encoding of the canonical JSON string
produced in the previous subsection.
The signature field is the Executor's Ed25519 signature, encoded as a
lowercase hexadecimal string of exactly 128 characters. The
callerSignature field, when present, is the Caller's Ed25519
signature over the same canonical input, in the same encoding.
3.3. Verification
A verifier MUST:
1. Recompute the canonical payload from the receipt's fields per
Section 3.1.
2. Resolve agentDid to its current public key per [DID-CORE].
3. Verify signature against the canonical payload using the Agent's
public key.
4. If callerSignature is present, resolve callerDid similarly and
verify callerSignature against the same canonical payload.
5. Reject the receipt if any signature verification fails.
Verification of formatVersion "1" receipts is additionally fail-
closed with respect to the wire format: a verifier MUST reject a
formatVersion "1" receipt whose taskHash or resultHash is not exactly
64 lowercase hexadecimal characters, or whose failureType is
inconsistent with success (Section 5) -- regardless of whether its
signatures are valid. A cryptographically valid signature over a
malformed record does not make the record conformant. Verifiers
SHOULD likewise validate the remaining MUST-level constraints of
Section 2 through Section 5 and reject violations.
A verifier MAY additionally validate that timestamp is within a
deployment-defined freshness window.
xkumakichi Expires 3 January 2027 [Page 9]
Internet-Draft XAIP Receipts July 2026
3.4. Format Versioning and Legacy Receipts
The formatVersion member identifies which revision's processing rules
apply to a receipt. The only value defined by this document is "1",
denoting: full 64-character hashes, the preimage profile of
Section 3.5, toolMetadata excluded from the signed payload,
failureType always present as a string, and callerDid always present.
A receipt without a formatVersion member is a legacy receipt,
produced under revisions -00 through -02 of this document. Verifiers
MAY accept legacy receipts by reconstructing the nine-field canonical
payload (Section 3.1) and applying lenient handling; deployments
SHOULD record which regime a stored receipt was accepted under. Two
known properties of legacy receipts deserve care:
* Some legacy producers truncated taskHash/resultHash to 16
hexadecimal characters. A 64-bit digest is collision-findable
with roughly 2^32 work and MUST NOT be produced anymore; consumers
SHOULD NOT rely on truncated hashes as commitments.
* Some legacy producers incorrectly included toolMetadata in the
signed payload, contrary to the canonical-payload rule of every
revision that defined it. Such receipts fail verification under
this revision's payload rule.
Because formatVersion is part of the signed payload, a receipt's
version claim cannot be altered without invalidating its signatures.
Verifiers encountering an unknown formatVersion value MUST reject the
receipt.
3.5. Hash Preimage Profile
formatVersion "1" producers MUST compute taskHash and resultHash over
the following preimages. This profile makes hashes of semantically
identical values byte-identical across independent producers, which
is what enables cross-deployment comparison and later disclosure
verification.
Text (a string value): The raw UTF-8 content bytes of the string
itself -- not its JSON-string serialization. "hello" hashes the 5
bytes hello (digest 2cf24dba...); a format that hashed the 7-byte
JSON form (with quotation marks) would produce 5aa762ae...
instead.
Raw binary content: Its raw bytes, directly. (Together with the
text rule: scalar content hashes its content bytes.)
Structured JSON value (object, array, number, boolean): The UTF-8
bytes of its JCS [RFC8785] canonical form. Member order therefore
cannot change the hash.
Absent (no input; no output, e.g. on failure) or JSON null: The
xkumakichi Expires 3 January 2027 [Page 10]
Internet-Draft XAIP Receipts July 2026
empty byte string. SHA-256 of the empty string is the empty-input
sentinel:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.
Two consequences worth stating explicitly. First, hashing a
structured value requires the same type-level discipline as the
canonical payload itself: values must be JSON-representable and
serialized by JCS, not by an implementation's default serializer.
Second, the sentinel makes "no output" a first-class, verifiable
state -- a failed call with no output has a well-defined resultHash
rather than an empty or producer-invented value.
Semantic equivalence across different profiles (for example,
comparing a hash produced under this profile with one produced by a
format that hashes JSON-string serializations) remains out of scope;
the formatVersion mechanism exists so that such profile changes are
explicit rather than silent.
4. SigningDelegate Pattern (Caller Co-signature)
To produce a co-signed receipt, a Caller MUST NOT transmit private
key material to the Executor. Instead, the Caller exposes a
SigningDelegate interface:
interface SigningDelegate {
did: DIDString
sign(payload: string): Promise<HexString>
}
The Executor sends the canonical payload string to the Caller's sign
method and receives the signature. The private key never leaves the
Caller's process boundary.
When the Caller and Executor are not co-located, the transport
carrying canonical payloads to the Caller MUST use TLS or an
equivalent confidentiality and integrity layer.
A Caller MAY decline to sign -- for example, if the Caller does not
consent to the receipt's contents. In that case the Executor
publishes the receipt with only its own signature and no
callerSignature. Such receipts remain syntactically valid; consumers
may weight them differently as a matter of deployment policy.
xkumakichi Expires 3 January 2027 [Page 11]
Internet-Draft XAIP Receipts July 2026
Before signing, a conforming Caller SHOULD at minimum parse the
canonical payload and confirm that callerDid identifies itself and
that the payload corresponds to a delegation it actually issued (for
example, by matching toolName and recomputing taskHash from the input
it delegated). A Caller that signs whatever it is handed adds
attribution but no verification; Section 8.7 discusses the resulting
trust boundary.
By producing callerSignature, a conforming Caller attests that it
accepts the canonical record as representing the identified Caller-
to-Agent delegation. This attestation does not, by itself, imply
that the Caller independently recomputed taskHash, observed the
result committed to by resultHash, or validated success, latencyMs,
or failureType, unless a deployment defines and enforces those
checks. The Security Considerations discuss the resulting trust
boundary.
5. Failure Type Classification
When success is false, failureType MUST be either one of the
following registry values or a deployment-defined extension value:
+============+================================================+
| Value | Condition |
+============+================================================+
| timeout | The call exceeded a deployment-defined latency |
| | bound (default RECOMMENDED: 30000 ms), or the |
| | underlying error was timeout-shaped. |
+------------+------------------------------------------------+
| validation | The call failed due to input or output |
| | validation (schema, parse, type mismatch). |
+------------+------------------------------------------------+
| error | All other failures. This is the registry |
| | catch-all. |
+------------+------------------------------------------------+
Table 2
Receiving implementations MUST treat unknown failureType values as
error for the purposes of any deployment-policy decision they make.
Deployments defining extension values should note that extensions
carry meaning only within that deployment.
When success is true, failureType MUST be the empty string "". This
is a deliberate choice over a null value: it keeps the canonical
payload's value type stable (always string) so that JCS
canonicalization (Section 3.1) produces a predictable byte sequence
regardless of success state. A verifier that substitutes a null
xkumakichi Expires 3 January 2027 [Page 12]
Internet-Draft XAIP Receipts July 2026
value for an empty failureType will compute a different canonical
payload and will fail to verify legitimate receipts. A formatVersion
"1" receipt with success true and a non-empty failureType, or success
false and an empty failureType, is malformed and MUST be rejected
(Section 3.3).
6. Tool Metadata (Optional)
A receipt MAY carry a toolMetadata object describing class or
capability hints about the tool. This document does not standardize
the schema of toolMetadata. A deployment may use it to convey:
* A tool class (e.g., advisory, data-retrieval, mutation,
settlement).
* A settlement layer identifier when the tool executes on-chain
transactions.
* A verifiability hint indicating whether the tool's outcome is
externally anchored.
toolMetadata is NOT part of the canonical payload and is NOT signed.
Consumers that wish to trust toolMetadata MUST validate it through
out-of-band means (e.g., the tool's published manifest, signed
separately).
A future revision of this document, or a companion document, MAY
standardize a portion of the toolMetadata schema if interoperability
needs emerge.
7. Identity (DID) Requirements
Both agentDid and callerDid MUST be syntactically valid DIDs per
[DID-CORE]. This document does not constrain the DID method. Common
choices in production include did:key, did:web, and ledger-anchored
methods such as did:xrpl or did:ethr.
A deployment MAY apply policy based on DID method -- for example,
treating ledger-anchored identities differently from cryptographic-
only identities. Such policy is out of scope for this document; the
wire format treats all DID methods uniformly.
8. Security Considerations
8.1. Privacy
Receipts identify inputs and outputs by hash. Implementations MUST
NOT include raw inputs, outputs, prompts, user data, secrets, or PII
in any signed field. toolMetadata, while not part of the canonical
payload, also SHOULD NOT contain such data.
xkumakichi Expires 3 January 2027 [Page 13]
Internet-Draft XAIP Receipts July 2026
Hash construction matters: a deployment that hashes uncanonicalized
inputs may leak information through hash collisions or correlation.
The preimage profile (Section 3.5) removes serializer-level
divergence; note that hashing does not make low-entropy or guessable
values private, since a verifier holding a candidate value can always
test it against the hash.
8.2. Replay
A signed receipt is replayable by anyone who possesses it. Receivers
SHOULD enforce a freshness window on timestamp and SHOULD reject
duplicate receipts identified by (signature). Note that signature-
level deduplication identifies distinct records, not distinct
executions: two executions whose nine field values coincide exactly
(same hashes, same millisecond timestamp, same latency) produce the
same canonical payload and -- Ed25519 being deterministic -- the same
signature, and are therefore indistinguishable at this layer; see
Section 9. A deployment that needs cross-receipt deduplication MAY
additionally store and dedupe by (agentDid, taskHash, timestamp).
8.3. Caller-Side Forgery
A receipt with only signature (Executor) and no callerSignature
represents the Executor's claim alone. A malicious Executor could
fabricate such receipts. Co-signature by the Caller prevents this: a
Caller observing a forged receipt about its own delegations would
notice the absence of its callerSignature and could repudiate.
When callerSignature is missing, a deployment SHOULD weight the
receipt accordingly. The exact weighting is policy, but treating co-
signed and non-co-signed receipts identically is a security mistake.
8.4. Single-Observer Dominance
If a deployment derives reputation or trust signals from receipts and
a single Caller produces most of the receipts about a given tool,
that Caller's environment-specific bugs, biases, or hostile behavior
propagate directly into the derived signal. This is a deployment-
policy concern, not a wire-format concern. Deployments SHOULD record
the set of distinct callerDid values contributing to any derived
statistic so that consumers can reason about observer diversity.
8.5. Key Compromise
A compromised Agent or Caller key allows arbitrary receipt forgery
for the lifetime of that key. DID methods that support key rotation
SHOULD rotate routinely. Verifiers MUST resolve DIDs to the current
key set at verification time, not at receipt emission time.
xkumakichi Expires 3 January 2027 [Page 14]
Internet-Draft XAIP Receipts July 2026
8.6. Timestamp Trust
timestamp is asserted by the Executor and is not independently
anchored by this format. A deployment that requires verifiable time
SHOULD pair receipts with an external time-anchoring mechanism
([RFC3161], blockchain inclusion, etc.).
8.7. Co-signature Trust Boundary
A caller co-signature adds a second attributable assertion over the
same canonical record. It represents evidence from an operationally
independent source only to the extent that the Caller's signing
authority is operationally separated from the Executor's authority.
If the Caller and Executor share a process, operator, or key-
management boundary, two signatures do not establish two independent
observers.
Co-signature does not prevent collusion. A Caller and Executor
acting together can produce a co-signed receipt that describes an
execution inaccurately or describes an execution that did not occur.
Co-signature binds both identified parties to the same canonical
record; it does not establish that the record is true.
9. Known Limitations
The following are known limitations of this format. They are
recorded so that implementers and reviewers can account for them; a
future revision or companion document may address them.
* Key rotation and historical verification. A receipt carries no
verification-method identifier. When a DID document exposes
multiple applicable verification methods, a verifier may need to
try multiple candidate keys, and the receipt provides no stable
reference to the key used at issuance. If that key is later
removed from the DID document, a legitimately issued receipt can
become unverifiable. A deployment that needs long-lived
verifiability must retain historical key material or pin keys out
of band. Carrying an explicit key identifier in the receipt is a
candidate for a future revision.
* Tool identity. Only the opaque toolName is part of the signed
payload; toolMetadata is not signed. Two implementations,
providers, or versions that share a toolName are not
distinguishable from the receipt alone. Binding a stable tool
identifier, a provider or endpoint identity, or a version or
manifest digest into the signed payload is a candidate for a
future revision.
xkumakichi Expires 3 January 2027 [Page 15]
Internet-Draft XAIP Receipts July 2026
* Receipt uniqueness. The format carries no nonce or per-receipt
identifier. Two executions whose field values coincide exactly
are represented by byte-identical receipts (Section 8.2) and
cannot be distinguished or counted separately. Deployments for
which double-counting or under-counting such coincidences matters
must add an out-of-band identifier; a nonce field is a candidate
for a future revision.
* Cross-profile hash comparison. Section 3.5 pins one preimage
profile for formatVersion "1", which makes hashes comparable
across producers within this format. Comparing hashes against
records produced under a different profile (including legacy
truncated hashes, and formats that hash JSON-string
serializations) remains undefined and requires out-of-band
agreement.
10. IANA Considerations
This document has no IANA actions in its current form. A future
revision may register a media type (e.g., application/xaip-
receipt+json) and a failureType registry.
11. References
11.1. Normative References
[DID-CORE] Sporny, M., "Decentralized Identifiers (DIDs) v1.0",
W3C Recommendation, July 2022,
<https://www.w3.org/TR/did-core/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
xkumakichi Expires 3 January 2027 [Page 16]
Internet-Draft XAIP Receipts July 2026
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
11.2. Informative References
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/info/rfc3161>.
[XAIP-CASE-2026-05]
xkumakichi, "XAIP Single-Caller Dominance Case Study", May
2026, <https://github.com/xkumakichi/xaip-
protocol/blob/main/docs/case-study/single-caller-
dominance.md>.
[XAIP-IMPL]
xkumakichi, "XAIP Protocol Reference Implementation",
2026, <https://github.com/xkumakichi/xaip-protocol>.
[XAIP-VECTORS]
xkumakichi, "XAIP Receipts Conformance Test Vectors
(formatVersion 1)", July 2026,
<https://github.com/xkumakichi/xaip-
protocol/tree/main/docs/spec/test-vectors>.
Appendix A. Relationship to the XAIP Reference Implementation
The XAIP reference implementation [XAIP-IMPL] wraps this wire format
with an aggregator, a Bayesian trust score, a class-aware risk-flag
evaluator, and a decision engine that ranks candidate tools. None of
those components are required to produce or consume receipts
conformant to this document. A consumer that only wants to verify
and store receipts does not need to import any of them.
A consumer that wants a turnkey aggregator and scoring layer may use
the reference implementation. A consumer that disagrees with any of
those design choices is free to substitute its own implementation
while remaining interoperable at the receipt-format layer.
As of this revision, the reference implementation (SDK middleware,
four client emitters, and the aggregation service) produces and fail-
closed-validates formatVersion "1" receipts, and its behavior is
locked to the conformance vectors of Appendix D.
xkumakichi Expires 3 January 2027 [Page 17]
Internet-Draft XAIP Receipts July 2026
The single-observer dominance failure mode discussed earlier in this
document was first surfaced in the public dataset of that reference
implementation [XAIP-CASE-2026-05].
Appendix B. Adoption Path for Agent-Payment Protocols
This format is intended to be useful to agent-payment protocols (for
example, agent-to-agent payment protocols, agent-mediated commerce
protocols, and agent escrow systems) that need a "trust precondition"
check before committing to a transaction. Such a protocol can:
1. Require that an Agent present a set of recent receipts before
being allowed to initiate a payment.
2. Define its own scoring policy over the receipt set, or consult an
external scoring service.
3. Require that receipts above a certain transaction value include
callerSignature (co-signed).
4. Require that receipts for settlement-class tools (declared via
toolMetadata, which is unsigned and therefore validated out of
band per Section 6) be additionally anchored to an external
ledger.
Each of those is a policy decision local to the agent-payment
protocol. This document only defines the receipt wire format; it
does not define a payment mechanism, a settlement rail, or any value-
transfer system.
Appendix C. Relationship to Adjacent Receipt and Audit Formats
Other efforts also record evidence about AI agent actions. They
differ from this document mainly in two dimensions: the unit of
evidence (a single call versus a whole session) and which party
attests to the record. This appendix is informative and describes
that adjacent work for context; this document does not depend on any
of these formats.
Session-level integrity bundles record an entire agent session as a
single hash-chained, signed archive, answering post-hoc audit
questions about a completed workflow. A per-call receipt as defined
here and a session-level bundle are composable: a bundle may embed or
reference per-call receipts, and a per-call receipt may carry a
reference to the session in which it occurred.
Receiver-attested receipts are signed by the service that received
the call and produced the result; obtaining such an attestation
requires the invoked service to participate in the receipt protocol.
The caller co-signature model in this document (the SigningDelegate
pattern, Section 4) instead lets the party that delegated the work
xkumakichi Expires 3 January 2027 [Page 18]
Internet-Draft XAIP Receipts July 2026
sign the same canonical per-call record as the executing Agent, so
that -- when both signatures are present -- the record is
attributable to both parties to the Caller-to-Agent delegation
without requiring the invoked Tool or service to sign. A further
pattern places the signature on a mediator at the communication
boundary between the Agent and the tool. These approaches represent
different observation and control boundaries: a caller co-signature,
in particular, does not imply that the Caller independently observed
every field, and its evidentiary value depends in part on the
operational separation between the Caller and the Agent.
In that space, this document occupies the per-call point at which the
executing Agent and the delegating Caller can co-attest the same
record. It does not subsume executor-only assertion, receiver
attestation, mediator attestation, or session-level bundles; a single
deployment may combine more than one of them.
Appendix D. Conformance Test Vectors
Executable test vectors for this revision are published in the
reference repository [XAIP-VECTORS]:
* docs/spec/test-vectors/receipts-v1-vectors.json -- the vectors.
Every hash, canonical payload byte string, and Ed25519 signature
is real; test keys are embedded (and marked as such).
* docs/spec/test-vectors/check.mjs -- a dependency-free checker
(Node.js 18 or later, standard library only) that re-derives every
value from the vectors file and verifies all signatures, failing
loudly on any drift.
The vectors pin, as executable bytes: the preimage profile of
Section 3.5 (raw-UTF-8 text hashing with the JSON-form value shown as
the explicit wrong answer; JCS member-order invariance; the empty-
input sentinel); canonical payload construction with and without
formatVersion, including the byte-identity of payloads with and
without toolMetadata; a complete co-signed receipt (the example in
Section 2), a failure receipt using the sentinel, and a legacy
receipt; a tamper case whose signatures must fail; and the fail-
closed rejections of Section 3.3 (truncated hash, uppercase hash,
failureType inconsistent with success).
The vectors are the executable form of this document's processing
rules: an implementation that reproduces them byte-for-byte conforms
to the hashing and canonicalization layers of this revision, without
needing to interpret prose. The example in Section 2 and the vectors
are generated from the same values, so the example cannot silently
drift from the specification.
xkumakichi Expires 3 January 2027 [Page 19]
Internet-Draft XAIP Receipts July 2026
Appendix E. Change Log
* -03 (2026-07-02): Versioned the wire format and made it
mechanically checkable. Added the formatVersion member (value
"1"), carried inside the signed payload, and defined legacy-
receipt handling. Pinned the hash preimage profile -- scalar
content hashes its content bytes, structured JSON hashes its JCS
form, absent values hash the empty-input sentinel -- narrowing the
-02 known limitation on preimage encoding. Made verification of
formatVersion "1" receipts fail-closed for hash format and
failureType consistency. Pinned: no Unicode normalization at
verification, NFKC/NFKD prohibited at any layer, NFC recommended
for producers; signature encoding exactly 128 lowercase hex
characters; latencyMs range [0, 2^53 - 1]; a single RECOMMENDED
RFC 3339 rendering for timestamp; unknown top-level members are
unauthenticated. Resolved the -02 contradiction between the
closed failureType value set and deployment extensions, and
required rejection of success/failureType-inconsistent receipts.
Required the empty-input sentinel for failure receipts committing
to no output. Added a SHOULD-level minimum check list for Callers
before co-signing. Corrected the replay-section uniqueness claim
and added the receipt-uniqueness (no nonce) known limitation;
removed the format-versioning known limitation (resolved by
formatVersion). Replaced the example receipt -- whose hash values
did not conform to this document's own length requirement in -00
through -02 -- with a complete receipt that verifies against
published test keys. Added executable conformance test vectors
and a dependency-free checker. No changes to the signing
algorithm, canonicalization scheme, or trust-boundary language of
-02.
* -02 (2026-06-19): Scoped to define precisely what a caller co-
signature establishes and what it does not. The Abstract no
longer states that co-signature prevents unilateral fabrication
outright; it now states that two valid signatures bind the
identified Caller and Agent to the same canonical record, and that
this does not establish independent observation of every field,
execution correctness, or absence of collusion. Clarified caller-
signature semantics, separated attribution from operational
independence in the Security Considerations, scoped the adjacent-
formats appendix to the Caller-to-Agent delegation, and named the
executor / delegator / receiver / mediator / session-bundle
attestation axis. Softened the privacy design principle to a
content-minimizing claim. Normative clarification: taskHash and
resultHash MUST be computed with SHA-256 and encoded as exactly 64
lowercase hexadecimal characters; this narrows the -00/-01
wording, which only RECOMMENDED SHA-256. Added a Known
Limitations section. No wire fields were added or changed.
xkumakichi Expires 3 January 2027 [Page 20]
Internet-Draft XAIP Receipts July 2026
* -01 (2026-06-19): Foregrounded caller co-signature (mutual
attestation) as a distinguishing property of the format in the
Abstract, and added an informative appendix relating per-call,
caller-co-signed receipts to session-level integrity bundles and
receiver-attested receipts. No wire-format or normative changes;
receipts valid under -00 remain valid under -01.
* -00 (2026-05-22): Initial individual draft. Split out from the
XAIP reference implementation specification, focused on the
receipt wire format only. Removed aggregator, scoring, and
decision-engine content; left those to deployment policy.
Author's Address
xkumakichi
Email: kuma.github@gmail.com
xkumakichi Expires 3 January 2027 [Page 21]