Network Working Group S. Mih Internet-Draft Action State Group, Inc. Intended status: Informational 29 October 2026 Expires: 2 May 2027 An Interaction Model for Requesting Verifiable Evidence draft-mih-agent-evidence-request-01 Abstract Parties increasingly need to request verifiable evidence from a counterparty they do not trust — an audit trail, an interaction history, an account of actions taken — and to receive an answer they can check rather than believe. Evidence formats for the answer exist; the ask has no standard shape, and today one system's silence, another's error, and a third's stale cache are indistinguishable to a relying party. This document defines a transport-agnostic request/ response interaction for verifiable evidence: a request that names its subject and a coverage anchor, and a set of possible outcomes that is exactly one of three things — the evidence artifact, a signed refusal carrying a machine-readable reason, or a recorded absence. The interaction makes asking, granting, and refusing each attributable and checkable, and requires that the same subject under the same coverage yield a byte-identical artifact for every requester. The interaction is symmetric: any party to a recorded exchange may ask the other, anchored on its own record of that exchange. A responder may additionally commit, in a signed statement, to keep a subject answerable until a stated time, so that a later absence is attributable rather than merely recorded. The document deliberately defines no evidence format, no identity or principal scheme, no trust policy, no availability guarantee, and no rule about who may ask. 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." Mih Expires 2 May 2027 [Page 1] Internet-Draft Evidence Request October 2026 This Internet-Draft will expire on 2 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Two Failure Modes . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. The Request . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. What a Record Carries . . . . . . . . . . . . . . . . 9 3.2. Coverage . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Derivation . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Deadline . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Principal Reference . . . . . . . . . . . . . . . . . . . 13 3.8. Recording the Request . . . . . . . . . . . . . . . . . . 13 3.9. Categories . . . . . . . . . . . . . . . . . . . . . . . 14 4. Interaction Outcomes . . . . . . . . . . . . . . . . . . . . 15 4.1. The Artifact Response . . . . . . . . . . . . . . . . . . 15 4.2. The Signed Refusal . . . . . . . . . . . . . . . . . . . 17 4.3. Pending . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. Recorded Absence . . . . . . . . . . . . . . . . . . . . 18 4.5. The Three-State Discipline . . . . . . . . . . . . . . . 18 4.6. Mapping to a Requirement-Satisfaction Status . . . . . . 19 5. Caller Invariance . . . . . . . . . . . . . . . . . . . . . . 20 6. The Symmetric Ask . . . . . . . . . . . . . . . . . . . . . . 22 7. Recording the Exchange . . . . . . . . . . . . . . . . . . . 22 8. Derivation-Scoped Disclosure . . . . . . . . . . . . . . . . 23 8.1. The History Card . . . . . . . . . . . . . . . . . . . . 23 9. Retention Commitments . . . . . . . . . . . . . . . . . . . . 24 10. Transport Bindings . . . . . . . . . . . . . . . . . . . . . 25 10.1. Carriage Rules . . . . . . . . . . . . . . . . . . . . . 26 Mih Expires 2 May 2027 [Page 2] Internet-Draft Evidence Request October 2026 10.2. A2A Binding . . . . . . . . . . . . . . . . . . . . . . 27 10.3. MCP Binding . . . . . . . . . . . . . . . . . . . . . . 28 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . 35 14.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Example Deployments . . . . . . . . . . . . . . . . 37 Appendix B. Reference Blocks and This Interaction . . . . . . . 38 Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . . 39 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction A growing class of systems — autonomous agents, multi-party computation pipelines, registries of signed claims — accumulate evidence about their own actions: signed statements, receipts, transparency-log inclusion proofs. Formats for these artifacts exist and continue to mature; the SCITT architecture [RFC9943] and COSE Receipts [RFC9942] are representative examples, and this document depends on neither. What has no standard shape is the *ask*. Each ecosystem invents its own convention for "give me your evidence": a bespoke query endpoint here, an ad-hoc agent command there, a static file by private agreement somewhere else. The answers are not comparable. When a relying party asks two counterparties the same question, one counterparty's silence, another's transport error, and a third's stale cached answer all look alike — and none of the three leaves a record that the question was asked. This document standardizes the interaction, not the evidence. It defines a request — a small map naming a *subject* (what evidence is wanted) and a *coverage anchor* (the commitment the answer must verify against) — and constrains the outcome to exactly one of three states: the evidence artifact itself, a signed refusal with a machine-readable reason, or a recorded absence. Each outcome is something the requester can record and later cite. The evidence artifact remains opaque to this specification; it is identified by digest and verified against the anchor by format-specific means outside this document. A deployment that already has a format for the artifact — for example an Evidence Bundle ([I-D.mih-zhang-agent-disclosure-bundle]) — carries it inside the artifact response envelope this document defines (Section 4.1); nothing here restates that format. Mih Expires 2 May 2027 [Page 3] Internet-Draft Evidence Request October 2026 Two further properties follow from deployments of this interaction shape, sketched in Appendix A. First, the interaction is symmetric: the party that served a request may later ask the party that made it, and each side's strongest coverage anchor is its own sealed record of the exchange (Section 6). Second, the useful default answer to "show me your history" is not the records but a constant-size summary of the commitments over them — checkpoints, receipts, and consistency proofs — from which any individual record can later be verified (Section 8.1). A third property is optional: a responder may sign a commitment that a subject will remain answerable until a stated time (Section 9). Absence against an outstanding commitment is evidence against the responder; absence otherwise is evidence only of the requester's attempt. 1.1. Two Failure Modes The interaction is designed to close two specific failure modes this shape exists to prevent, sketched in Appendix A: *The flattering version.* A responder that serves evidence through an unconstrained query interface can serve _different_ evidence to different requesters — a fuller history to an auditor it expects, a curated one to a counterparty in a dispute. Nothing in the transport reveals the divergence. The caller-invariance requirement addresses this, conditional on the anchor-consistency requirement of Section 5: the artifact is a function of the subject and the coverage anchor, never of who is asking. *The unaccountable refusal.* A responder that declines by silence, by generic error, or by an unsigned message leaves the requester with nothing citable: "I asked and they refused" is an assertion, not a record. The signed refusal (Section 4.2) constrains this: a refusal is a first-class, signed, machine-readable answer that the requester can record — and the three-state discipline (Section 4.5) keeps genuine non-response distinguishable from refusal, so neither can be laundered into the other. 1.2. Non-Goals This document deliberately does not define: * *Any evidence format.* The artifact is an opaque byte string identified by digest. Signed statements, receipts, log entries, bundles of proofs — all are carried, none are specified here. Mih Expires 2 May 2027 [Page 4] Internet-Draft Evidence Request October 2026 * *Any identity or principal scheme.* Where a deployment binds a request or its response to a principal — the requester, the responder, or both — the reference's scheme (a key, a DID, an account identifier, a host-native name) is defined by the host or deployment, never by this document (Section 3.7). * *Requester identity, purpose, authorization, or disclosure policy carried in the artifact.* These belong to the request/relationship layer — a deployment's own account, contract, or relationship model — and are referenced by this interaction, never embedded in the evidence artifact itself. What a principal field (Section 3.7) names, and what relationship or contract a request cites, is deployment-defined and outside this document. * *Any trust decision.* Receiving an artifact, a refusal, or nothing implies no judgment about the responder. What a requester does with each outcome is its own policy. * *Authorization or standing.* Who may ask, and what any requester is entitled to receive, is the responder's policy and is out of scope. This document constrains only the _form_ of the answer, whichever answer policy selects. * *Any availability guarantee.* The interaction makes loss detectable and, where a responder has committed to retention (Section 9), attributable. It never makes evidence available. 2. 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. *Requester:* the party asking for evidence. *Responder:* the party holding evidence and answering. *Evidence artifact:* the byte string a responder serves in the granting case. Opaque to this specification; identified by its digest. *Evidence stream:* the append-only body of evidence a responder holds and answers from — the ordered records over which its coverage anchors commit. A responder MAY hold several streams; a request is answered against exactly one. Mih Expires 2 May 2027 [Page 5] Internet-Draft Evidence Request October 2026 *Anchored:* verifying against a coverage anchor by the mechanism- specific means of the deployment's evidence format. *Coverage anchor:* a commitment — for example, a signed checkpoint over an append-only log, or a receipt from a transparency service [RFC9943] — that the evidence artifact must verify against. The anchor is what turns an artifact from a story into something checkable: an artifact that verifies against an anchor the requester obtained or constrained independently is tamper-evident with respect to that anchor. *Checkpoint / commitment:* used generically for any signed, compact representation of a body of evidence at a point in its history, such that inclusion and consistency of evidence against it are checkable. [I-D.mih-scitt-checkpointed-local-log] describes one example of such a mechanism; this document depends on no particular one. *Freshness:* how recent a coverage anchor is, measured in a mechanism-specific unit (a log size, a timestamp). *Exchange half:* a party's own sealed record of one interaction with a counterparty — its request, or its response — citing the counterparty's record by digest. *History card:* the derivation history_card/1 (Section 8.1): the checkpoints over an evidence stream, their external receipts, and the consistency proofs between consecutive checkpoints. Constant size in the number of records; discloses no record content. *Retention commitment:* a signed statement by a responder that a named subject will remain answerable under this interaction until a stated time (Section 9). *Route:* a locator — a resolver, a URL, an endpoint identifier — for reaching a responder. Routes are hints. They are never subjects and never identity. *Principal reference:* an opaque value identifying a party — requester, responder, or a party named in a retention commitment — in a scheme this document does not define (Section 3.7). Distinct from a route: a route is where a party can be reached; a principal reference is who it is under whatever identity scheme the deployment recognizes. *The three interaction outcomes:* artifact (Section 4.1), signed refusal (Section 4.2), recorded absence (Section 4.4). Mih Expires 2 May 2027 [Page 6] Internet-Draft Evidence Request October 2026 *Pending:* the state of a request, before its waiting window closes, that has received neither an artifact response nor a signed refusal. Not one of the three interaction outcomes; resolves to recorded absence only once the window closes (Section 4.3). 3. The Request A request is a map — CBOR [RFC8949] in bindings that use CBOR, JSON in bindings that use JSON, with the same field names — with the following fields: +============+=============+========================================+ | Field | Presence | Description | +============+=============+========================================+ | subject | REQUIRED | what evidence is asked for | | | | (Section 3.1) | +------------+-------------+----------------------------------------+ | coverage | REQUIRED | the anchoring constraint the | | | | response must satisfy (Section 3.2) | +------------+-------------+----------------------------------------+ | derivation | OPTIONAL | identifier of a named computation | | | | over the subject (Section 3.3) | +------------+-------------+----------------------------------------+ | deadline | OPTIONAL | latest useful response time | | | | (Section 3.4) | +------------+-------------+----------------------------------------+ | nonce | RECOMMENDED | requester-supplied nonce or | | | | timestamp (Section 3.5) | +------------+-------------+----------------------------------------+ | route | OPTIONAL | where the requester believes the | | | | responder can be reached | | | | (Section 3.6) | +------------+-------------+----------------------------------------+ | categories | OPTIONAL | the evidence categories the | | | | requester asks the responder to | | | | declare (Section 3.9) | +------------+-------------+----------------------------------------+ Table 1 A responder MUST ignore request fields it does not understand. A requester MUST NOT rely on any field not defined by this document being understood. A deployment MAY bind a request to a principal reference (Section 3.7) by a mechanism outside this document — for example, the signature that authenticates the transport, or a field a deployment profile adds; this document defines no such field and takes no position on how the binding is made or checked. Mih Expires 2 May 2027 [Page 7] Internet-Draft Evidence Request October 2026 A request that is malformed — not a well-formed map, missing a REQUIRED field, or carrying a defined field whose value does not conform — is refused with reason request_malformed (Section 13), except where this document assigns a more specific reason (as for coverage, Section 3.2). [[EDITOR: whether the request map is expressed in CDDL is open. The field names in the table above are fixed; the semantics are as specified in this document.]] 3.1. Subject The subject names what is asked for, in one of six forms: +==============+===============+=================================+ | Form | Content | Meaning | +==============+===============+=================================+ | full_history | (none) | the responder's entire evidence | | | | body for this evidence stream | +--------------+---------------+---------------------------------+ | checkpoints | (none) | the responder's checkpoints and | | | | their receipts for this stream; | | | | no records | +--------------+---------------+---------------------------------+ | record | digest | the single record identified by | | | | this digest | +--------------+---------------+---------------------------------+ | range | (a, b) | the records at positions a | | | | through b inclusive, under the | | | | coverage anchor's ordering | +--------------+---------------+---------------------------------+ | correlation | identifier | all records the responder holds | | | | that carry this correlation | | | | identifier (Section 3.1.1) | +--------------+---------------+---------------------------------+ | exchange | digest of the | every record the responder | | | requester's | holds that cites this exchange | | | own half | half (Section 3.1.1, Section 6) | +--------------+---------------+---------------------------------+ Table 2 Subjects are digests, positions, and opaque identifiers — never display names. Names drift; digests do not. A requester that holds only a name has a resolution problem this document does not solve, and a responder MUST NOT attempt fuzzy or best-effort matching of a subject: a subject that does not resolve exactly is answered with a refusal carrying reason no_such_subject (Section 4.2). Mih Expires 2 May 2027 [Page 8] Internet-Draft Evidence Request October 2026 The range form presupposes a coverage-anchor mechanism that defines record positions; under a mechanism defining no positional ordering it cannot be satisfied and is refused with reason coverage_unsatisfiable. The checkpoints form asks for commitments only. It is the cheapest question a stranger can ask and the one a responder can always safely answer; the history_card/1 derivation (Section 8.1) is its proof- carrying form. The exchange form names the requester's own sealed half of a prior interaction. A responder that recorded its side of that interaction holds a record citing that half by digest; the subject resolves to exactly those records. A responder holding no record citing the half answers no_such_subject — which, when the requester holds a signed reply from that responder citing the same half (Section 3.1.1), is itself a contradiction the requester can cite (Section 6). 3.1.1. What a Record Carries The correlation and exchange forms resolve to the records that carry an identifier or cite a half. Which members of a record count is fixed by the record's evidence format. The requester does not fix it, and the responder does not choose it per request. * A record *carries a correlation identifier* when the identifier is, octet for octet, the whole value of one of the record's correlation members: the members its evidence format designates as holding a correlation identifier. The identifier appearing anywhere else does not make the record carry it: in content the format does not designate, in free text, as part of a longer value, or under a member of the same name that the format does not designate. * A record *cites an exchange half* when it holds a typed reference, with the relation its evidence format designates for citing a counterparty's half of an exchange, whose digest is the half's digest. The same digest in any other member, or in a reference with any other relation, does not make the record cite the half. For two record formats that define these subjects' members, the designations are: * Evidence Layer records ([I-D.mih-agent-evidence-layer]): - Correlation members: the header's subject_ref (Section 4 of [I-D.mih-agent-evidence-layer]), and any header field a profile adds under that section's provision for profile-added header Mih Expires 2 May 2027 [Page 9] Internet-Draft Evidence Request October 2026 fields and designates as an equivalent correlation field (Section 9 of [I-D.mih-agent-evidence-layer]), for example each text-valued member of a correlation map added by a profile. - Half citation: an entry of the header's links whose type is cites and whose target is the half's digest (Section 5 of [I-D.mih-agent-evidence-layer]). * Capsules ([I-D.mih-scitt-agent-action-capsule]): - Correlation members: the correlation fields that document names (Section 3.4 of [I-D.mih-scitt-agent-action-capsule]: currently action_id, decision_id, external_ref, and chain), cited here and not redefined. - Half citation: an entry of references whose citation_purpose is counterparty_half and whose digest is the half's digest (Section 5.5.6 of [I-D.mih-scitt-agent-action-capsule]). An entry with any other citation_purpose, responds_to included, does not cite a half. A responder resolves these subjects under the designations of the records it holds, and MUST NOT serve a record for a correlation or exchange subject unless, under its format's designation, the record carries the identifier or cites the half. A served record that, under its format's designation, does not carry the identifier or cite the half is not responsive to the subject, and an artifact that includes one does not answer it. A requester checking a served record against the subject applies the designation of that record's format, not the layout of its own records. A record that carries the identifier, or cites the half, under its own format's designation conforms, wherever the requester's own records would have held it. A requester that cannot identify the record's format, does not implement it, or receives a record whose format designates no correlation members or no half citation, MUST treat the record's carriage as unchecked: it MUST NOT treat the record as not carrying the identifier or not citing the half, and MUST NOT reject the artifact on that ground. An unchecked record is still checked against the coverage anchor like any other. Mih Expires 2 May 2027 [Page 10] Internet-Draft Evidence Request October 2026 3.2. Coverage The coverage field carries *exactly one* of the following two members. A request carrying both, or neither, is malformed, and the responder MUST refuse it with reason coverage_unsatisfiable. A responder first checks that each member present in coverage has a conforming value, and refuses a non-conforming value with reason request_malformed, whether or not the other member is present; only then does it apply the both-or-neither rule. *expected_pin (digest):* the requester already holds, obtained out of band, a specific coverage anchor — for example a published checkpoint — and requires the response to verify against exactly that anchor. This is the strongest form: the anchor's integrity does not depend on the responder at all, because the responder never chose it. A requester's own exchange half is a valid pin for an exchange subject: the responder's record cites it, and the requester sealed it before the responder's answer existed. *min_freshness (size or time):* the requester holds no specific anchor and instead requires that the response be covered by a commitment at least this fresh — at least this log size, or issued no earlier than this time. The responder selects a qualifying anchor and identifies it in the response. This form trades the pin's independence for availability: the requester can always form the request, but the anchor's independence now rests on whatever external witnessing or publication that anchor has, outside this protocol (Section 11). The two forms are mutually exclusive by design. A pinned request that also stated a freshness floor would invite the responder to substitute "fresher" coverage for the coverage the requester actually demanded; forbidding the combination keeps the requester's constraint unambiguous. A responder MAY perform work to satisfy min_freshness — for example, issue a new commitment covering evidence produced since its last one — and SHOULD do so when a deadline permits. A responder that cannot satisfy the coverage constraint MUST refuse with reason coverage_unsatisfiable rather than serve an artifact under weaker coverage. Serving under weaker-than-requested coverage is not a degraded success; it is a different answer to a different question, and this document forbids it. Mih Expires 2 May 2027 [Page 11] Internet-Draft Evidence Request October 2026 3.3. Derivation The derivation field, when present, names a computation over the subject — by a registered token (Section 13) for the derivations this document defines, or by the digest of a definition for any other — and asks for that computation's _result_, re-derivable by the requester, instead of the raw evidence. A count of records matching a predicate, a sum over a declared field, a projection of specific fields: each is a named computation whose definition declares exactly which fields of the underlying evidence it reads. Derivation is also the disclosure mechanism of this document: the declared field set of the named computation bounds what the responder reveals (Section 8). A responder that supports a derivation MUST evaluate it over exactly the subject as anchored by coverage — a derivation is a view of the anchored evidence, not an independent report — and the result MUST be accompanied by whatever the requester needs to check that binding (format-specific, out of scope here beyond the requirement that the binding be checkable). A responder that does not support the named derivation at all refuses with reason derivation_unsupported; a responder that supports the derivation in general but not for this subject refuses with reason no_such_subject, per Section 3.1. 3.4. Deadline The deadline field states the latest time at which a response is useful to the requester. It is advisory in the sense that no transport can enforce it, and normative in one respect: a responder that determines it cannot answer by the deadline SHOULD send a refusal with reason deadline_unmet before the deadline rather than let the exchange lapse into absence. A refusal is cheap and citable; an absence is neither party's record of anything except the requester's attempt. 3.5. Nonce The nonce field carries a requester-chosen nonce or timestamp; its use is RECOMMENDED. It makes each transmitted request instance distinct, so a refusal — identified by request digest, with a signed issuance time (Section 4.2) — binds to _this_ instance of asking, not replayable against a fresh one. Covered by the request digest, it MUST NOT influence the artifact (Section 5). Mih Expires 2 May 2027 [Page 12] Internet-Draft Evidence Request October 2026 3.6. Route The route field carries the requester's belief about where the responder can be reached — a resolver name, a URL, a peer endpoint identifier. It is a hint for the transport binding and nothing more: it MUST NOT influence the artifact (Section 5), it is not a subject, and it is not identity. A responder reached through a route is authenticated by its signature on the response, never by the route (Section 11). The field exists so that the route actually attempted is part of the requester's record of asking, and so a failed route is part of any absence recorded (Section 4.4). 3.7. Principal Reference This document distinguishes a *route* (where a party can be reached, Section 3.6) from a *principal reference* (who a party is). It defines the former and not the latter. Where a deployment needs to say "this request came from, or this response is addressed to, this particular party," it binds a principal reference into the exchange by whatever mechanism it already has — a signature key, a DID, an account identifier, or any other host-native scheme — and this document takes no position on that scheme, its resolution, or its trust. A retention commitment (Section 9) similarly names an answerable party without this document defining what a name is. Two consequences for implementers. First, a requester or responder MAY be authenticated at the transport layer (by the signature over a response, for example, Section 11) without either party ever appearing as a field in the request or response maps this document defines: authentication and subject resolution are independent, and a responder MUST NOT let knowledge of the requester's principal change the artifact served for a given (subject, coverage) pair (Section 5). Second, a deployment profile that adds a principal field to the request or response — to carry purpose, authorization context, or a relationship reference alongside the identity — does so as an extension this document neither requires nor constrains; such a field is request/relationship-layer material and MUST NOT appear inside the evidence artifact itself (Section 1.2). 3.8. Recording the Request The request itself is evidence: it is the requester's proof of _having asked_. Requesters SHOULD record each request they send — in their own evidence stream, signed, in the encoding actually transmitted — before or at transmission time. Where requests are recorded or their digests exchanged, deterministic encoding SHOULD be used: CBOR Core Deterministic Encoding (Section 4.2 of [RFC8949]) for CBOR, JCS [RFC8785] for JSON, so that the recorded bytes and the Mih Expires 2 May 2027 [Page 13] Internet-Draft Evidence Request October 2026 transmitted bytes are the same bytes. A requester that retains neither the transmitted request bytes nor their digest cannot correlate a refusal — identified only by digest — with its own record of having asked. Request recording is a SHOULD, not a MUST: Section 7's "I asked; they refused" property is empty without it, but this document does not require a requester to keep records it has no use for. 3.9. Categories The categories field, when present, names evidence categories and asks the responder to declare, for each one, what it offers. Some evidence formats define such a declaration: a statement inside the artifact that gives each category of a named category set one status, for example available, withheld, or absent. This field is how a requester says which categories it wants declared. The request itself, and the meaning of each status, belong to the evidence format and are not defined here. The value is a map with two members: +========+==========+===============================+ | Member | Presence | Value | +========+==========+===============================+ | set | REQUIRED | identifier of a category set | +--------+----------+-------------------------------+ | names | REQUIRED | a non-empty array of distinct | | | | category names from that set | +--------+----------+-------------------------------+ Table 3 Each identifier and name is a text string. The value space of set, and of names within a set, is that of a category-set registry to be defined in a companion document. This document does not define category sets and registers none. [[EDITOR: open for a later revision: the registry that defines category sets and their names; what a responder declares for a set or a name it does not recognize; and whether the order of names carries meaning.]] Implementing categories is OPTIONAL for a responder. A responder that implements it treats a categories value that is not a map, lacks either member, has a member of the wrong type, or has an empty or duplicated names as malformed, and refuses the request with reason request_malformed. Names are compared as exact strings. Mih Expires 2 May 2027 [Page 14] Internet-Draft Evidence Request October 2026 The field asks for a declaration, nothing else. It does not change the subject, it does not change coverage (Section 3.2), and it does not change which records are served. A declaration states what the responder says it offers. It is not a proof that the responder offers all of it (Section 11). A responder that does not implement categories ignores it, as it ignores any field it does not understand (Section 3), malformed or not. Its artifact then carries no declaration. A requester MUST NOT rely on categories being understood, and MUST NOT read a missing declaration as a statement about any category. 4. Interaction Outcomes An interaction produces exactly one of three outcomes: the artifact response, a signed refusal, or a recorded absence. Only the first two are messages a responder sends; the third is not a message at all — it is the requester's own record that no response arrived within its waiting window. Treating these as *outcomes* rather than as three things a responder chooses among matters: a responder can grant or refuse, full stop; it cannot "respond with absence," because absence is precisely the case in which nothing arrived to be a response. There is no fourth outcome, and no outcome is ever converted into another (Section 4.5). 4.1. The Artifact Response The artifact response is the signed response envelope for the granting outcome. The object it carries is opaque to this specification and MAY be an Evidence Bundle ([I-D.mih-zhang-agent-disclosure-bundle]) or any other evidence artifact the deployment's evidence format defines; this document specifies the envelope and its binding to the request and the coverage anchor, never the carried object's internal shape. The envelope carries: 1. *The artifact:* the evidence bytes themselves, or a derivation result (Section 3.3), identified by digest. 2. *The coverage anchor resolved:* under expected_pin, confirmation of the pinned anchor; under min_freshness, the anchor the responder selected, which MUST satisfy the requested freshness. 3. *Verification material:* whatever proofs let the requester verify the artifact against the anchor *offline* — inclusion proofs, consistency proofs, countersignatures, receipts [RFC9942]. An anchor MAY carry receipts from more than one transparency Mih Expires 2 May 2027 [Page 15] Internet-Draft Evidence Request October 2026 service; each receipt is verified on its own terms, and how many independent services a requester requires is requester policy, not a property of this interaction. The formats are evidence- mechanism-specific and out of scope; the requirement is that the artifact be verifiable against the anchor by the requester alone, with no further round trip to the responder and no appeal to the responder's honesty. 4. *The request identified:* the digest of the request being answered, computed over the request bytes as received, exactly as for a refusal (Section 4.2 item 1). 5. *An issuance time:* the time the envelope was issued. 6. *A signature:* by the responder, in whatever signature format the deployment's evidence mechanism already uses, covering at least items 4 and 5, the artifact's digest, and the identification of the resolved anchor. Items 4 to 6 MUST be present. They bind one answer to one instance of asking. Two envelopes for the same subject under the same anchor name the same artifact digest; envelopes answering requests with different bytes, for example different nonces (Section 3.5), differ in the request digest. The artifact is caller-invariant (Section 5); the envelope is not, and is not meant to be. A requester that holds the bytes it sent, or their digest (Section 3.8), can check that an envelope answers its request and not another one. An envelope whose request digest is not the digest of the requester's own request bytes does not answer that request, however well it verifies otherwise. A deployment profile MAY fix the member names and the signature format of the envelope; this document fixes only what the signature covers. For the checkpoints subject and the history_card/1 derivation the artifact _is_ the verification material: there is no separate record to verify, only commitments and the proofs between them. Implementations MUST NOT serve an empty artifact alongside proofs in these cases; the proofs are the artifact, and caller invariance (Section 5) binds them. An artifact response MAY be accompanied by a retention commitment (Section 9) covering the subject served. An artifact response that cannot be verified against the anchor is, to the requester, not evidence but an unverifiable story, and requesters SHOULD treat a verification failure as adverse — equivalent to discovering the exchange was not what it claimed — rather than as a retryable transport fault. Mih Expires 2 May 2027 [Page 16] Internet-Draft Evidence Request October 2026 4.2. The Signed Refusal A refusal is an answer, not an error. It carries: 1. *The request identified:* the digest of the request being refused, computed over the request bytes as received. 2. *A reason:* exactly one machine-readable token from the registry established in Section 13. The initial tokens are not_authorized, no_such_subject, coverage_unsatisfiable, derivation_unsupported, policy_declined, deadline_unmet, request_malformed, and retention_expired. The last is distinct from no_such_subject by design: it states that the responder once committed to answer this subject (Section 9) and the commitment has lapsed, so a lapsed promise cannot be presented as never having held the evidence. 3. *An issuance time:* the time the refusal was issued, which MUST be present and MUST be covered by the signature. It binds the refusal to a moment, so a recorded refusal cannot be presented as current policy nor replayed against a fresh request (Section 3.5). 4. *A signature:* the refusal is signed by the responder, in whatever signature format the deployment's evidence mechanism already uses, such that the requester can record the refusal and later demonstrate to a third party that this responder refused this request for this stated reason. Human-readable detail MAY accompany the reason token; the token, not the prose, is the machine-readable answer. A responder MUST select the most specific applicable token, with one deliberate exception noted in Section 12: a responder MAY uniformly answer policy_declined wherever a more specific token would disclose information its policy protects, overriding the most-specific-token rule. That choice is policy, made by the responder, applied uniformly; it is not a license to select tokens per-requester in a way that leaks by differentiation (Section 12). A refusal refuses the request, once. It creates no standing obligation and no standing prohibition; the same request MAY be made again and MAY be answered differently as the responder's policy or evidence changes. Mih Expires 2 May 2027 [Page 17] Internet-Draft Evidence Request October 2026 4.3. Pending Before the requester's waiting window closes, a request that has received neither an artifact response nor a signed refusal is *pending*: outstanding, not yet resolved, and not yet evidence of anything. Pending is not one of the three interaction outcomes — it is the state of a request between issuance and either an answer or the close of the window — and MUST NOT be recorded or cited as if it were an absence. A requester MAY track a request as pending, for its own bookkeeping or to display outstanding requests to an operator, without that tracking implying anything about the eventual outcome. Only once the waiting window closes with neither an artifact nor a refusal received does a request's state resolve to absence (Section 4.4). Until that boundary, delay, slow transport, and a responder about to answer are indistinguishable from one another, and none of them MUST be recorded as if the outcome were already known. 4.4. Recorded Absence Absence is the outcome in which no response — neither artifact nor refusal — arrives within the requester's waiting window (its deadline if it set one, or its local timeout otherwise); before that window closes, the request is pending, not absent (Section 4.3). Absence is not sent by anyone; it is _recorded by the requester_: the request digest, the transport attempted, and the window in which no answer came. Absence is an outcome about the exchange, not about the responder's intent. A network partition, a crashed responder, and a responder deliberately ignoring the request produce identical absences, and the requester's record SHOULD NOT embellish the absence with an inferred intent. An absence record SHOULD cite any retention commitment (Section 9) the requester holds for the subject, and the route attempted. Absence inside an outstanding commitment is chargeable to the responder that signed it; absence without one is evidence of nothing but the attempt. The commitment changes whom the absence is evidence _against_; it does not change what the absence _is_, and the requester still MUST NOT infer intent. 4.5. The Three-State Discipline The three outcomes are mutually exclusive and are never synthesized into one another: Mih Expires 2 May 2027 [Page 18] Internet-Draft Evidence Request October 2026 * *Absence is NEVER synthesized into refusal.* No party — not the requester, not a transport intermediary, not a recording system — may manufacture a refusal object from a timeout. A refusal exists only if the responder signed one. A requester's records MUST keep "they refused" (their signature, their reason) and "they did not answer" (my attempt, my window) as distinct, differently-evidenced facts. * *Refusal is never degraded into absence.* A requester that receives a valid signed refusal SHOULD record it as such; discarding a refusal and recording an absence misstates the exchange. * *An unverifiable artifact is not a fourth outcome.* An artifact response that fails verification against the anchor is recorded as what it is: a response received and failed. It is neither a grant nor an absence, and requesters SHOULD NOT record it as a successful grant. * *A commitment never converts an absence into a refusal.* A retention commitment (Section 9) makes an absence attributable; it does not make it a signed act of the responder, and no party may record it as one. * *Pending is never recorded as absence.* A request still inside its waiting window is pending (Section 4.3), not absent; only the close of the window resolves it one way or the other. The discipline exists because the three outcomes carry different evidentiary weight — a refusal is the responder's signed act, an absence is only the requester's attempt — and any synthesis between them forges the stronger from the weaker. 4.6. Mapping to a Requirement-Satisfaction Status This document defines no requirement-satisfaction vocabulary; a deployment composing this interaction with an evidence-contract or evidence-bundle layer typically derives one from the three outcomes above. The mapping shape — not a specific registry — is informative: Mih Expires 2 May 2027 [Page 19] Internet-Draft Evidence Request October 2026 +===========================+==================================+ | Outcome | Typically maps to (illustrative) | +===========================+==================================+ | Artifact response, | requirement satisfied | | verified | | +---------------------------+----------------------------------+ | Artifact response, | requirement status indeterminate | | verification fails | — never treated as satisfied | +---------------------------+----------------------------------+ | Refusal: no_such_subject, | evidence not found, or not yet | | coverage_unsatisfiable | committed | +---------------------------+----------------------------------+ | Refusal: not_authorized, | evidence withheld by policy, not | | policy_declined, | absent | | derivation_unsupported | | +---------------------------+----------------------------------+ | Refusal: | a prior commitment lapsed; | | retention_expired | distinct from never having held | | | the evidence | +---------------------------+----------------------------------+ | Pending | request outstanding; the window | | | has not closed, nothing yet to | | | map | +---------------------------+----------------------------------+ | Recorded absence | status unknown to the requester; | | | not evidence of non-satisfaction | +---------------------------+----------------------------------+ Table 4 A deployment's own vocabulary MAY be coarser or finer than this table; the table exists to show that the three outcomes carry enough distinction to support one, not to define it. 5. Caller Invariance This is the normative core of the document. For a given responder, the same subject under the same coverage anchor MUST yield a byte-identical evidence artifact, regardless of the requester's identity, the transport binding used, or any other property of the request. Formally: the artifact MUST be a deterministic function of (subject, resolved coverage anchor, derivation if present, categories if present and honored (Section 3.9)), and MUST NOT be a function of the requester, its principal reference (Section 3.7), or the channel. Two requests that differ in derivation, or in a categories value the responder honors, ask different questions, and their artifacts are not compared. A Mih Expires 2 May 2027 [Page 20] Internet-Draft Evidence Request October 2026 responder that honors categories MUST honor it alike for every requester that sends the same value; honoring it for some requesters and not others makes the artifact a function of the requester. Under expected_pin the resolved anchor is fixed by the requester, so two requesters pinning the same anchor and naming the same subject MUST receive identical bytes. Under min_freshness the responder selects the anchor; two requests resolved against the _same_ selected anchor MUST receive identical bytes, and the anchor identification in the response (Section 4.1) is what lets requesters compare notes across resolutions. Caller invariance is the anti-flattering-version property (Section 1.1). It is what makes the artifact _evidence_ rather than a per-audience story: any two requesters — or one requester over two channels — can detect a responder serving divergent versions by comparing artifact digests for the same (subject, anchor) pair, without trusting each other's verification and without any authority adjudicating. A responder MAY refuse a requester outright (Section 4.2); what it MUST NOT do is grant different requesters different bytes for the same anchored subject. Access control is a policy; per-audience evidence is a forgery of the interaction. *Anchor consistency.* Caller invariance would be hollow if a responder could hand each requester its own anchor. All coverage anchors a responder serves for a given evidence stream MUST lie on one mutually consistent append-only history, and the responder MUST be able to produce, on request, a consistency proof between any two anchors it has served for that stream, in the proof format of the deployment's evidence mechanism. The limits of this requirement are discussed in Section 11. Two consequences for implementers: * The artifact serialization MUST be deterministic. An artifact assembled with nondeterministic map ordering, timestamps of assembly, or per-request nonces violates invariance even with honest intent. Deterministic encodings (Section 4.2 of [RFC8949]; [RFC8785] for JSON) are the practical tool. * Verification material (Section 4.1 item 3) is NOT required to be byte-identical across requesters — a consistency proof, for instance, may legitimately depend on which earlier anchor a particular requester holds. Invariance binds the artifact; the proofs bind the artifact to the anchor. Mih Expires 2 May 2027 [Page 21] Internet-Draft Evidence Request October 2026 One subject form needs its own statement. An exchange subject is invariant per (exchange-half digest, anchor) like any other, but no two requesters can hold the same half, so cross-requester comparison is unavailable there. Invariance for exchange is instead checked by the responder's own recorded ask (Section 7) against the artifact it served: the responder's record and the requester's record must name the same artifact digest. The subject does not weaken invariance; it changes who holds the second copy. 6. The Symmetric Ask Nothing in this document distinguishes the party that originally requested an action from the party that performed it. Once both have sealed their halves of an exchange — each citing the other's record by digest — either MAY ask the other for evidence about that exchange, using the exchange subject anchored on its own half. A provider asking its former requester is the same interaction with the roles swapped; no new message, no new state. The consequence is the one property no single-responder interaction can otherwise provide. A responder's log, however well witnessed, proves only the integrity of what the responder chose to write. A counterparty that sealed its own half of every exchange can prove an _omission_ by arithmetic: it holds a signed reply citing (Section 3.1.1) a half the responder now claims not to have. Coverage is a property of the counterparty's record, not of the log, and the symmetric ask is how that record is exercised. Deployments MAY condition interaction on evidence — for example, a policy that serves only to peers whose history card (Section 8.1) verifies against an independently obtained checkpoint. Such a policy is a requiring-party decision and is outside this document; the interaction only makes it expressible. 7. Recording the Exchange Each side SHOULD seal its half of the exchange into its own records: the requester its request, and whichever of the three outcomes followed; the responder the requests it received and the artifacts or refusals it served. Both sides' recording is a SHOULD: requester- side recording is what gives absence any meaning at all, and responder-side recording is the responder's own counter-record when a response it sent never arrived (Section 11). The consequence worth naming: once both the ask and the answer are recordable, *"I asked; they refused" becomes citable material* — a signed refusal in the requester's records, a recorded ask in the responder's — and each party can grade the other's conduct over time Mih Expires 2 May 2027 [Page 22] Internet-Draft Evidence Request October 2026 from its own records, with no authority anywhere in the loop. A requester's policy might treat a counterparty's pattern of policy_declined refusals differently from a pattern of absences; a responder's policy might treat a requester's recorded asks as standing to receive more. This document enables those policies and defines none of them (Section 1.2). 8. Derivation-Scoped Disclosure When derivation names a computation, the computation's declared field set defines the *minimal disclosure* needed to re-derive it: the responder reveals exactly the fields the named computation reads, and nothing more. The responder MUST NOT disclose fields outside the declared set as part of a derivation response, and MUST NOT evaluate a computation whose declared field set it is unwilling to disclose — the correct answer in that case is a refusal, not a silently truncated evaluation. Three disclosure tiers fall out naturally: 1. *Digests-only* — no derivation; subjects and artifacts identified and verified by digest, content never disclosed. Always safe to serve (subject to Section 12 on low-entropy content). 2. *Derivation-scoped* — a named computation's declared fields, and only those. Minimal content disclosure, deliberate, and recorded: the derivation identifier in the recorded request states exactly what was revealed and why. 3. *Full* — the raw evidence bytes. The rare tier, appropriate where the requester's role requires the whole record. 8.1. The History Card This document registers one derivation, history_card/1, defined as follows. For the named evidence stream, the result is the ordered list of tuples (checkpoint, receipts for that checkpoint, consistency proof from the previous checkpoint), from the stream's first checkpoint to the one resolved by coverage. Its declared field set contains no record content: the card discloses commitments, external receipts over those commitments, and the proofs that each commitment extends the last. Its size is linear in the number of checkpoints and independent of the number of records. The history card is the default first question. It is the thing a stranger checks before deciding whether to ask for anything else; it is safe to serve to anyone under the digests-only tier; and it is sufficient to verify any individual record the responder later Mih Expires 2 May 2027 [Page 23] Internet-Draft Evidence Request October 2026 serves, by inclusion proof against a checkpoint the requester already holds. A card that fails to verify — a consistency proof that does not chain, a receipt that does not cover its checkpoint — is treated as an unverifiable artifact (Section 4.5). The derivation registry and definition format for other computations are expected to grow in a subsequent version. [[EDITOR: open: whether to register a second derivation, the result of a sampled recomputation of a subject by a third party.]] 9. Retention Commitments A responder MAY issue a *retention commitment*: a signed statement that a named subject will remain answerable under this interaction until a stated time. It carries: 1. the subject, in one of the forms of Section 3.1, and the evidence stream it belongs to; 2. until: the time after which the commitment lapses, covered by the signature; 3. optionally, a route at which the responder expects to be reachable, and optionally a principal reference (Section 3.7) naming who is answerable, when that differs from the signer; 4. the responder's signature, in the signature format of the deployment's evidence mechanism. A commitment is a promise about _answerability under this interaction_. It says nothing about whether the bytes exist anywhere else, and it does not make the subject available; it makes a later failure to answer attributable to the party that promised. A commitment MAY be carried alongside an artifact response (Section 4.1), published with the responder's checkpoints, or placed in a citing record's reference block as an optional member beside the digest of the thing cited. It MUST NOT appear in a request. A commitment that names a subject by anything other than a digest or a position under a checkpoint is malformed: the digest remains the identity, and the commitment is a route with a promise attached, never an address. Within until, an absence for the committed subject is recorded citing the commitment (Section 4.4). Within until, a refusal carrying not_authorized, coverage_unsatisfiable, request_malformed, or derivation_unsupported reflects a property of the request or of this responder's capabilities, not a failure to honor the commitment, and Mih Expires 2 May 2027 [Page 24] Internet-Draft Evidence Request October 2026 is not a breach. Any other refusal reason — no_such_subject, policy_declined, or deadline_unmet — within until is a broken commitment: the responder promised this subject would remain answerable and is refusing it on a ground the promise foreclosed; the refusal is signed, so the breach documents itself. After until, the correct refusal is retention_expired. The separation this section preserves is the one that a reference field promising only "resolvable" cannot express: that a name staying resolvable and the bytes staying unchanged are two different promises. The digest keeps the second. The commitment, when present, names who is answerable for the first, and for how long. 10. Transport Bindings The interaction is transport-agnostic; a binding maps the request map, the three outcomes, and the recording discipline onto a concrete transport. Bindings are intentionally thin. Two are defined in this section, two more for message-oriented agent protocols in Section 10.2 and Section 10.3 under the rules of Section 10.1, and one is reserved. *Peer-to-peer stream binding.* On a multiplexed peer transport that negotiates named subprotocols at connection time, this interaction is the subprotocol evidence-request/1. One request frame, one response frame; each frame is the deterministic CBOR encoding (Section 4.2 of [RFC8949]) of the maps in Section 3 and Section 4. Absence is the stream closed or timed out without a response frame. The subprotocol identifier is what lets any two peers implementing it interoperate without prior arrangement; a peer that does not offer it has not refused — it has not answered, and the requester records that as absence, not as policy_declined. Message-oriented agent protocols bind the same way, with the request as a named message type and the outcomes that have a reply as reply types (Section 10.1). The identifier evidence-request/1 is a document constant of this specification; it does not require registration in a separate subprotocol registry. *HTTP binding.* Pinned, parameterless requests (a full_history or checkpoints subject under expected_pin) map onto GET of a static resource: the URL identifies the subject, the pin travels as a query parameter or is implied by the resource, and caller invariance is trivially auditable because the resource is the same bytes for every client. Parameterized requests (ranges, correlations, exchanges, derivations, min_freshness) map onto POST with the request map as the body. A GET returns the static resource, which is not an artifact response and carries no envelope; a requester that needs the binding of Section 4.1 items 4 to 6 sends the request, pinned or not, as a Mih Expires 2 May 2027 [Page 25] Internet-Draft Evidence Request October 2026 POST. A responder SHOULD publish a manifest — its evidence stream identifiers, the subject forms and derivations it supports, and where retention commitments (Section 9) can be fetched — so a requester can form a well-formed request without a prior round trip. A refusal is an HTTP response carrying the signed refusal object: a successful transport exchange carrying a refusal answer. Bindings MUST NOT conflate transport-level errors with refusals (Section 4.5). *Registry query.* A registry or query service exposing stored claims can expose this same interaction over its query path, so that a query answer arrives as an anchored artifact, a signed refusal, or a recordable absence rather than as a bare result set. This binding is reserved: its concrete mapping onto a specific query protocol is left to a future companion document rather than specified here. 10.1. Carriage Rules A2A [A2A] and MCP [MCP] carry this interaction as two more adapters of the same exchange. They add no message, no outcome, and no member of any signed object. The rules below apply to both, and to any other message-oriented binding. 1. *Octets, not values.* A carriage moves the request bytes and the reply bytes as opaque octets. It never parses and re-serializes them. Where the carriage is JSON and writes bytes as text, the octets are those obtained by decoding that text. The request digest (Section 4.2 item 1, Section 4.1 item 4) is computed over those decoded octets as received, never over the text and never over a re-serialization. 2. *One request, one digest.* The same request bytes therefore have the same digest over every carriage. A requester that may send one request over more than one carriage SHOULD encode it in deterministic CBOR (Section 4.2 of [RFC8949]) everywhere, as the peer-to-peer stream binding requires. 3. *Two media types, same encoding back.* A request is labeled with one of two media types: application/cbor for deterministic CBOR or application/json for JCS [RFC8785], compared as exact strings with no parameters. Bytes labeled with any other media type are not a request. A responder writes the reply in the encoding of the request and labels it with the request's media type. Mih Expires 2 May 2027 [Page 26] Internet-Draft Evidence Request October 2026 4. *Carriage is not request.* Nothing a carriage adds is part of the request: message and task identifiers, context identifiers, metadata, protocol-version and extension headers, follow-up messages in an interrupted task, and any client identification. None of it is covered by a signature this document defines, and none of it may influence the artifact (Section 5). 5. *Errors are not refusals.* Authentication or authorization in the carriage decides whether a responder answers, never what a given subject under a given anchor yields. A responder that declines puts a signed refusal in the reply position, or sends no reply. A carriage error, task failure, or error flag is never a refusal, and a responder MUST NOT present one as its refusal (Section 4.5). 6. *Classified by the reply bytes.* A requester classifies what it receives by the reply bytes alone. Task states, error flags, and human-readable text never make a reply an artifact response or a refusal, and never make a reply absent. Anything that is not a reply in the carriage's reply position leaves the request pending (Section 4.3) and, once the window closes, is recorded as absence (Section 4.4). 7. *Each reply on its own.* Each distinct reply is classified and verified on its own; a reply delivered more than once under the same carriage identifier is one reply. Two replies to one request digest, over one carriage or several, are compared as any two artifacts are (Section 5). 10.2. A2A Binding This binding uses A2A version 1.0.1 ([A2A]). Field names are A2A's. A2A's JSON bindings write the bytes of a raw part as base64 with padding (Section 4 of [RFC4648]). *Declaration.* A responder that carries this interaction over A2A lists one extension in its Agent Card's capabilities.extensions, with uri exactly https://datatracker.ietf.org/doc/draft-mih-agent- evidence-request/, required set to false, and the responder's manifest (Section 10) as params. A responder MUST NOT advertise this binding under any other URI. The Agent Card SHOULD list application/ cbor and application/json among its default input and output modes. *Request.* The request is one Message with role user, whose parts hold exactly one Part whose raw is the request bytes and whose mediaType is one of the two media types of Section 10.1, and whose extensions contain the extension URI. The requester MUST send A2A version 1.0 and list the extension URI in A2A's extensions service Mih Expires 2 May 2027 [Page 27] Internet-Draft Evidence Request October 2026 parameter; without a version, A2A reads the request as an earlier protocol version. The Message MUST NOT carry a taskId, so that each request starts its own task. If the requester sets accepted output modes, they MUST include the request's media type. A Message that holds the request in any other form (a data or text part, metadata, or a raw part of another media type) carries no request bytes to digest. It is not a request under this binding, and the responder MUST NOT answer it with an artifact response or a refusal. *Reply.* The responder MUST return a Task, not a direct Message. Its reply is one A2A Artifact whose extensions contain the extension URI, with exactly one Part whose raw is the reply bytes and whose mediaType is that of the request. When the responder streams, it MUST send that Artifact whole, in one update that neither appends to an earlier one nor is followed by another chunk. Artifacts with the same artifactId are one reply. An A2A Artifact is a container in A2A's task model; it is not the evidence artifact, and none of its own fields is signed or verified. Both an artifact response and a refusal leave the task completed. A follow-up Message that continues an interrupted task carries no request bytes and is carriage (Section 10.1 rule 4). The requester classifies a task by its reply Artifact, whatever the task state: * a reply Artifact of the form above is a reply; * a reply Artifact of any other form is not a reply; * with no reply Artifact, a task that is submitted, working, waiting for input or authorization, or in an unspecified state is pending; * with no reply Artifact, a task that is completed, rejected, failed, or canceled, an A2A error, and a direct Message are the responder sending no reply. None of them is a refusal. 10.3. MCP Binding This binding uses MCP revision 2026-07-28 ([MCP]). Field names are MCP's. *Listing.* A responder that carries this interaction over MCP lists two tools under exactly these names: evidence_manifest, which takes no arguments and whose structuredContent is the responder's manifest (Section 10), and evidence_request. Mih Expires 2 May 2027 [Page 28] Internet-Draft Evidence Request October 2026 *Request.* The arguments of evidence_request are exactly two members: request, the request bytes in base64url without padding (Section 5 of [RFC4648]), and media_type, one of the two media types of Section 10.1. The tool's input schema admits no other member. The request member MUST NOT be annotated to be copied into an HTTP header, since that would expose the request to intermediaries (Section 12). Arguments that do not have this form (a member missing or extra, request not base64url, another media_type) carry no request bytes to digest, and the responder MUST NOT answer them with an artifact response or a refusal. Arguments that have this form but decode to bytes that are not a well-formed request are a request, and are refused with reason request_malformed. *Reply.* Both an artifact response and a refusal are returned as a complete tool result, with the error flag false, whose structuredContent is a map with reply, the reply bytes in base64url without padding, and media_type, that of the request. A requester reads only structuredContent: a reply in base64url with the request's media_type is the reply, whatever the error flag says. A result asking for further input, with no reply yet, leaves the request pending, and a retry MUST carry the same request and media_type; different bytes are a different request. Anything else (a result without such a reply, a protocol error, an unknown tool) is not a reply, and is never a refusal, whatever its text says. 11. Security Considerations *The coverage anchor is the whole game.* Every checkable property of this interaction flows through the anchor. A response that is not verifiable against an anchor the requester obtained or constrained independently of the responder is a story with a signature on it: internally consistent, attributable, and worth exactly the responder's word. Requesters SHOULD prefer expected_pin with independently obtained anchors wherever the deployment makes anchors available out of band — published checkpoints, transparency-service receipts [RFC9943], mutually recorded prior exchanges. min_freshness responses inherit only whatever independence the responder-selected anchor has from its own witnessing or publication. *Split views: per-requester anchor forks defeat invariance.* Caller invariance binds the artifact to (subject, anchor), not the anchor to a single history: a responder that maintains divergent histories and steers each requester to an anchor on "its" fork — a split-view (equivocation) attack — serves individually verifiable, per-anchor- invariant answers while defeating invariance in substance. The anchor-consistency rule of Section 5 makes any fork a provable violation once two served anchors are compared; but detection ultimately requires that comparison — anchor gossip among requesters, Mih Expires 2 May 2027 [Page 29] Internet-Draft Evidence Request October 2026 or external witnessing of anchors — infrastructure outside this protocol. This protocol constrains the attack but cannot alone close it. *Freshness of an anchor is not recency of evidence.* An anchor's issuance freshness never implies recency or completeness of the evidence it covers: a just-issued anchor can commit to a history omitting everything the responder chose never to record. A time- based min_freshness satisfied by a responder-issued anchor is, absent external witnessing, responder self-attestation about its own clock and log. *Requester-side anchor staleness is a discipline, not a guarantee.* A requester pinning a cached anchor gets exactly what that anchor covers — including nothing the responder has done since. The protocol cannot make a stale pin fresh; it can only make the staleness visible (the anchor is identified in every response). Requesters for whom recency matters must maintain their anchor supply — refreshing pins from independent sources, or using min_freshness and accepting its weaker independence — and that maintenance is operational discipline outside this protocol. *Integrity is not coverage.* This protocol can establish that an artifact verifies against an anchor, and that it is the same artifact for every asker. It *never proves that the responder's evidence is complete coverage of reality*: a responder that simply never recorded an event, or that maintains a second evidence stream it is never asked about, produces perfectly verifiable, perfectly caller- invariant answers with the event absent. No request/response interaction with a single responder can close this; the complement is counterparty-held records — each party to an interaction recording its own half — so that omission by one holder is contradicted by the other's evidence (Section 6). Deployments SHOULD NOT represent a verified artifact response as proof that nothing else happened. *A category declaration declares; it does not prove.* A declaration returned for categories (Section 3.9) is the responder's signed statement of what it offers in each category. It is attributable, and a counterparty's records can contradict it (Section 6), but it is no more complete than anything else the responder chose to record. A requester SHOULD NOT treat a declared "absent" as proof that nothing of that category exists. Mih Expires 2 May 2027 [Page 30] Internet-Draft Evidence Request October 2026 *A principal reference is not authenticated by this document.* Where a deployment binds a request or a commitment to a principal reference (Section 3.7), verifying that binding is the deployment's own mechanism (typically a signature check outside the fields this document defines); this document neither strengthens nor weakens whatever guarantee that mechanism provides. *Refusals and absences carry weight only when recorded.* The accountability properties of Section 7 exist only for parties that actually record. A requester that discards refusals has no citable record of them; the protocol makes the record possible, not automatic. *Absence is unauthenticated; suppression is invisible.* An absence records only the requester's own attempt: an on-path adversary that suppresses a response the responder actually sent produces exactly the same absence as a responder that never answered, so absence carries minimal evidentiary weight against the responder. Responder- side recording (Section 7) is the counter-record for this case, and deployments SHOULD use integrity-protected transports so suppression requires active interference. *Refusal partitioning is the residual per-audience channel.* Caller invariance constrains the artifact, not who receives one: a responder can serve the friendly requester and refuse everyone else — each refusal well-formed, signed, and permitted — recreating a per- audience view through the pattern of refusals. Authorization remains responder policy (Section 1.2); the countermeasure is the recording discipline: signed refusals make a partitioning pattern demonstrable from the accumulated records of the refused. *Signed refusals are commitments.* A responder's refusal is a signed statement it may later be confronted with — including a no_such_subject refusal for a subject the responder later serves. Responders SHOULD treat reason-token selection with the same care as any other signed statement. *A retention commitment is a promise, not availability.* A responder that commits to retention (Section 9) and then loses the bytes has breached. The interaction records the breach; it does not prevent it, and deployments SHOULD NOT present a retention commitment as a guarantee that the evidence will be there. Mih Expires 2 May 2027 [Page 31] Internet-Draft Evidence Request October 2026 *The symmetric ask closes omission, not fabrication.* A counterparty's half (Section 6) proves that an exchange existed and what each side committed to; it does not prove that the content either side recorded is true. Corroboration of content — a second party recomputing the same work — is a different witness and is outside this document. *Routes are attack surface.* A route (Section 3.6) is chosen by the requester and may be wrong, stale, or supplied by an adversary. A requester MUST NOT treat a route as the responder's identity, and MUST authenticate every response by the responder's signature. A response signed by the wrong key is not a response from the responder, whatever route it arrived by. *Denial of service.* Requests are cheap to send; artifact assembly, fresh-commitment issuance under min_freshness, and derivation evaluation are not. Responders MAY apply rate and cost policy freely — refusing with policy_declined is always available and always honest — but MUST NOT let load-shedding take the form of caller-variant artifacts, which would violate Section 5 where refusal would not. 12. Privacy Considerations *Digests-only is the default posture.* The base interaction discloses digests, positions, and anchors — not content. Content disclosure happens only through derivation (Section 8) or a full-tier artifact, is deliberate, and — where the exchange is recorded — leaves a record of exactly what was disclosed, to whom, under which request. *Low-entropy content defeats digest opacity.* A digest of a low- entropy value (an enumerable identifier, a small-range field) can be reversed by dictionary: an observer holding candidate values checks each against the digest. Subjects, correlation identifiers, and digests-only responses over low-entropy content SHOULD therefore be constructed with salting or equivalent hardening, per the conventions of the deployment's evidence format; this document does not define the salt discipline but requires deployments to have one wherever digests are relied on to conceal enumerable content. *Leakage through reason tokens.* The difference between no_such_subject and not_authorized reveals whether the subject exists; other token distinctions leak analogously. A responder MAY answer policy_declined uniformly wherever a more specific token would disclose information its policy protects (Section 4.2). The uniformity is the point: a per-requester choice of token leaks by differentiation exactly what the uniform token conceals. Mih Expires 2 May 2027 [Page 32] Internet-Draft Evidence Request October 2026 *Coverage probing leaks log size.* A size-based min_freshness is a threshold query on current log size — granted at or above the threshold, refused coverage_unsatisfiable below it — so a requester can binary-search it to learn the log's size and, over time, its growth rate, without ever seeing content. Responders for whom activity volume is sensitive can extend the uniform-policy_declined posture to coverage refusals. *History cards leak cadence and volume.* A card (Section 8.1) discloses the number and spacing of checkpoints, and thereby an approximation of activity over time, without any record content. Responders for whom that is sensitive have the same option as for coverage probing: a uniform policy_declined for the derivation. *Exchange subjects reveal a relationship.* An exchange request names a half that only the two parties could hold, so any intermediary that sees the request learns that they interacted. Both parties already know; transport confidentiality is the only mitigation for everyone else. *Correlation identifiers SHOULD be non-identifying.* A correlation subject is visible to the responder and to any transport intermediary; identifiers that name persons or otherwise carry meaning outside the exchange leak that meaning to every party that sees the request. *Carriage metadata reveals the ask.* Over A2A and MCP (Section 10.2, Section 10.3) the carriage itself (an extension header, a tool name, a task) tells an intermediary that an evidence request was made, even when the request bytes are protected. Transport confidentiality is the only mitigation. *The request itself leaks interest.* Asking about a subject reveals that the requester cares about it — to the responder, and to intermediaries on an unprotected transport. Requesters with sensitive interest patterns should weigh the ask itself as a disclosure; transport confidentiality protects against intermediaries but never against the responder. *A principal reference, once bound, is itself disclosure.* Any deployment mechanism that binds a request or response to a principal reference (Section 3.7) discloses that reference to whoever observes the exchange. Whether that reference is itself sensitive — a persistent identifier versus a fresh one-time key — is a property of the host's identity scheme, outside this document's control. Mih Expires 2 May 2027 [Page 33] Internet-Draft Evidence Request October 2026 13. IANA Considerations This document requests that IANA establish a registry titled "Evidence Request Refusal Reasons". The registration policy is Specification Required. Each entry consists of a reason token (lowercase ASCII, underscore-separated), a one-line description, and a reference. The initial contents are: +========================+============================+===========+ | Token | Description | Reference | +========================+============================+===========+ | not_authorized | the responder's policy | This | | | does not authorize this | document | | | requester for this subject | | +------------------------+----------------------------+-----------+ | no_such_subject | the subject does not | This | | | resolve to evidence the | document | | | responder holds | | +------------------------+----------------------------+-----------+ | coverage_unsatisfiable | the responder cannot | This | | | satisfy the coverage | document | | | constraint as stated | | +------------------------+----------------------------+-----------+ | derivation_unsupported | the responder does not | This | | | support the named | document | | | derivation | | +------------------------+----------------------------+-----------+ | policy_declined | the responder declines | This | | | without further | document | | | characterization | | +------------------------+----------------------------+-----------+ | deadline_unmet | the responder cannot | This | | | answer within the stated | document | | | deadline | | +------------------------+----------------------------+-----------+ | request_malformed | the request is not well- | This | | | formed as specified by the | document | | | defining document | | +------------------------+----------------------------+-----------+ | retention_expired | the responder's retention | This | | | commitment for this | document | | | subject has lapsed | | +------------------------+----------------------------+-----------+ Table 5 Mih Expires 2 May 2027 [Page 34] Internet-Draft Evidence Request October 2026 This document further requests a registry titled "Evidence Request Derivations", registration policy Specification Required. Each entry consists of a derivation token (lowercase ASCII, underscore- separated, with a /N version suffix), a one-line description, the declared field set or a reference to it, and a reference. The initial contents are: +================+========================+==========+===========+ | Token | Description | Declared | Reference | | | | fields | | +================+========================+==========+===========+ | history_card/1 | checkpoints, receipts, | none (no | Section | | | and consistency proofs | record | 8.1 | | | for a stream | content) | | +----------------+------------------------+----------+-----------+ Table 6 This document makes no other requests of IANA. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 14.2. Informative References Mih Expires 2 May 2027 [Page 35] Internet-Draft Evidence Request October 2026 [A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification", Version 1.0.1, . [I-D.mih-agent-evidence-layer] Mih, S., "Evidence Layer", Work in Progress, Internet- Draft, draft-mih-agent-evidence-layer-00, October 2026, . [I-D.mih-scitt-agent-action-capsule] Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- capsule-05, September 2026, . [I-D.mih-scitt-checkpointed-local-log] Mih, S., "The Checkpointed Local Log (CLL)", Work in Progress, Internet-Draft, draft-mih-scitt-checkpointed- local-log-02, October 2026, . [I-D.mih-zhang-agent-disclosure-bundle] Mih, S. and Y. Zhang, "AAC Evidence Bundle", Work in Progress, Internet-Draft, draft-mih-zhang-agent- disclosure-bundle-01, October 2026, . [MCP] Model Context Protocol, "Model Context Protocol Specification", 28 July 2026, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Mih Expires 2 May 2027 [Page 36] Internet-Draft Evidence Request October 2026 Appendix A. Example Deployments The properties above are sketched, not proved, against four kinds of deployment. Each is described by capability only, at a length that omits implementation detail; none is a conformance requirement, and none names a specific product or organization. *An enterprise system-of-record* answers audit requests for a business unit's transaction history from a counterparty's compliance function. The same full_history request, pinned against the same published checkpoint, is served identically whether it arrives over the system's internal case-management API or a batch export a partner fetches nightly — the same bytes both paths, exercising caller invariance (Section 5) across transports operated by different teams within one organization. Requests and their outcomes are recorded in the system's own audit log, giving the compliance function a citable record of what was asked and answered, independent of the case file itself. *A peer-to-peer inference mesh* runs a sidecar responder on every serving node, answering checkpoints, record, and exchange subjects over a subprotocol negotiated at connection time. Both halves of every served exchange are sealed — the requester's commitment before sending, the provider's reply citing it — and checkpoints go to a witness no serving node operates. This deployment shape exercises the symmetric ask (Section 6) and the history card as the constant- size default (Section 8.1). *A decentralized social protocol* — clients publish signed events through nodes they do not operate and do not fully trust — uses this interaction for a client to ask a node for the interaction history tied to one of its own signing keys. subject names the key, coverage pins a checkpoint the client obtained from a different node, and the node answers with the same bytes regardless of which node served the request, refuses coverage_unsatisfiable if it has not yet observed enough events to satisfy the pin, or refuses no_such_subject if it holds nothing under that key at all. Because a client can run the same request against several nodes and compare artifact digests, caller invariance (Section 5) turns "my node says X" into something checkable rather than trusted. *A continuous-integration pipeline* requests build-provenance evidence for one artifact from an upstream stage before promoting it: subject names the artifact by its build digest, coverage pins the upstream stage's checkpoint recorded when the artifact was produced, and deadline bounds how long the promotion step will wait before treating the request as absence rather than blocking indefinitely. A stage that cannot produce the provenance in time refuses Mih Expires 2 May 2027 [Page 37] Internet-Draft Evidence Request October 2026 deadline_unmet rather than let promotion discover only a timeout; whether a promotion step proceeds anyway on absence, rather than treating it as a blocked release, is a policy decision this document does not make for it. None of the four sketches above is a claim of conformance or of deployed practice; retention commitments (Section 9) in particular remain a design proposal here, not a description of running code. The divergences a real deployment of any of these shapes would show — different refusal conventions, different freshness expressions, no common recording discipline — are precisely the gaps the normative sections above close. Appendix B. Reference Blocks and This Interaction Evidence formats that cite other artifacts commonly carry a reference block of roughly the shape {relation, identifier, resolver, retention, digest}, in which the identifier is a name in the resolver's system and the digest is optional. Read against this interaction, the required and optional halves swap, and each member maps onto one thing defined here: +================+===================+========================+ | Reference | Maps to | Status under this | | member | | interaction | +================+===================+========================+ | digest | record subject | REQUIRED; the identity | | | | of the cited thing | +----------------+-------------------+------------------------+ | position under | range subject | OPTIONAL; a positional | | a checkpoint | with expected_pin | address, never a | | | | second identity | +----------------+-------------------+------------------------+ | identifier + | route | OPTIONAL; a hint for | | resolver | | reaching a responder | +----------------+-------------------+------------------------+ | retention | retention | OPTIONAL; a signed | | | commitment | promise by a named | | | (Section 9) | party, with an expiry | +----------------+-------------------+------------------------+ Table 7 The inversion this produces is deliberate: a producer that cannot name a resolver may still cite, and a producer that cannot compute a digest may not. A reference that promises only that a name stays resolvable cannot say whether the bytes behind it are the ones present at issue time; a digest can, and a commitment beside it says Mih Expires 2 May 2027 [Page 38] Internet-Draft Evidence Request October 2026 who is answerable for serving them and until when. This appendix defines no reference-block format; it shows how one of the common shapes lands on the interaction so that the two can cite each other without either defining the other. Changes from -00 [[RFC Editor: please remove this section before publication.]] * New Section 3.1.1, "What a Record Carries": which members of a record carry a correlation identifier or cite an exchange half are fixed by the record's evidence format, with the designations for Evidence Layer records and Capsules. * Section 4.1: the artifact response envelope now carries the request digest, an issuance time, and a signature covering both, the artifact digest, and the resolved anchor. Section 10: a GET of a static resource is not an artifact response; the envelope binding needs a POST. * Section 3.2: a non-conforming member value is refused request_malformed before the both-or-neither rule applies. * New Section 3.9: the OPTIONAL categories request field, a category set identifier and category names, OPTIONAL for a responder to implement. Section 5 adds it to the inputs of the artifact when honored, and requires a responder to honor it alike for every requester. coverage is unchanged. * Section 10: new carriage rules (Section 10.1) and two bindings, A2A (Section 10.2) and MCP (Section 10.3). The peer-to-peer stream binding's message-oriented sentence now maps only the outcomes that have a reply to reply types; -00 said "the three outcomes as three reply types", but absence has no reply. * Security and Privacy Considerations: a category declaration declares and does not prove; carriage metadata reveals the ask. * References: RFC 4648 added as normative, A2A and MCP as informative. The Checkpointed Local Log and Evidence Bundle references name their posted revisions; the Evidence Bundle is cited under its current name, draft-mih-zhang-agent-disclosure- bundle (posted -00 cited it under an earlier anchor). Evidence Layer and Agent Action Capsule references, cited by the text added in Section 3.1.1, are new. Mih Expires 2 May 2027 [Page 39] Internet-Draft Evidence Request October 2026 Acknowledgments The author thanks the participants in early discussions that helped shape this model. The evidence formats this interaction carries, and the transparency mechanisms its anchors lean on, are the work of the SCITT and COSE communities ([RFC9943], [RFC9942]); this document exists because those answers made the shape of the ask the remaining gap. Author's Address Steven Mih Action State Group, Inc. Email: spec@actionstate.ai Mih Expires 2 May 2027 [Page 40]