| Internet-Draft | Verdict Records | November 2026 |
| Wright | Expires 6 May 2027 | [Page] |
This document defines a verdict record: a statement, bound to its issuer, of a result reached on a claim, together with the evidence the result relies on and the rule by which the result can be re-derived. Evidence is cited by digest and can be a receipt or record in any format, such as a SCITT Receipt or an Agent Action Capsule. The document defines how a checker checks a verdict record and what such a check does and does not show. It defines no receipt format and changes none.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
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.¶
Several formats record that something happened or that something was said. A SCITT Signed Statement, registered on a Transparency Service, yields a Receipt [RFC9943]. An Agent Action Capsule records one agent action and its disposition [I-D.mih-scitt-agent-action-capsule]. A Signed Evaluation Receipt records one evaluation result [I-D.gruszka-signed-evaluation-receipts]. Each records an act or a statement; a Receipt is issued by the Transparency Service on which the statement is registered.¶
This document defines a companion to those formats: a verdict record, which states a result reached on a claim and cites such receipts and records as its evidence. It does not define how evidence is captured, and it does not replace any receipt format.¶
A verdict record names the rule that produced its result. Where the rule is mechanical, any checker that holds the evidence can re-run it and compare. Where no mechanical rule can re-derive the result, the record says so, and a check then shows only what the result was based on, and when.¶
A check of a verdict record never shows that a claim is true. It shows that the issuer asserted the result, on the stated evidence, under the stated rule.¶
An architecture for auditing agent interactions [I-D.kuehlewind-audit-architecture] describes an Auditor that determines whether recorded behaviour matched the user's intent and the authorization in force, and whether recorded evidence supports or contradicts a claim. A verdict record is one way to record such a determination, so that a party that trusts neither the agent nor its operator can check what it was based on. The records that architecture defines can be its evidence.¶
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.¶
writer member.¶
judgement means that no mechanical rule can re-derive the result. A rule name other than judgement SHOULD identify the version of the specification it names, so that a changed rule has a new name.¶
A verdict record is a JSON object [RFC8259] in canonical form. In canonical form, object members are sorted by name, compared as sequences of Unicode code points; there is no whitespace outside strings; strings escape only the quotation mark, the reverse solidus and control characters, and write every other character as its UTF-8 bytes; numbers are integers; and arrays keep their order. Re-serializing the parsed record MUST give the same bytes.¶
A verdict record MUST be strict JSON: valid UTF-8 that does not start with a byte-order mark, in which no object at any depth has the same member name twice and no escape forms a lone surrogate. A checker MUST refuse JSON nested deeper than 32 levels at any point; the record itself is at level 1, and each object or array inside it adds one level.¶
An integer is written as an optional minus sign and digits only, with no leading zero, no fraction and no exponent, and lies between -(2^53 - 1) and 2^53 - 1. A time is UTC, written YYYY-MM-DDTHH:MM:SS.ffffffZ with exactly six fraction digits. Hex is lowercase, two characters per byte, with no prefix. A member of the wrong JSON type is refused at the step that reads it. Bytes that break the rules of this section, or a record that breaks Section 2.2 other than in evidence and check, are refused before any step runs: the state is refused and the report names the rule broken.¶
The digest of a verdict record, and of an evidence item, is the SHA-256 hash [FIPS180-4] of its exact bytes, written in hex. This document defines no salted or hiding form of digest.¶
A verdict record has exactly the members below. No other member is allowed. The members v, kind, key, version, writer and body MUST be present. A record without evidence or check can be parsed, but fails step 1 or step 2 of Section 4.3.¶
v:kind:key:version:supersedes:writer:actor:type ("person" or "system") and id, and for a system also model and model_version.¶
act_time:evidence:sha256, the digest of the item (Section 2.1), and format, a string that names the format by whose rules the item is verified (Section 7).¶
check:An object with exactly the members rule (a string, the name of the rule), inputs (optional) and result (the result the rule gave).¶
The member inputs is an object. Each of its members names one input of the rule, and its value says where the checker reads that input:¶
body. The input is that member's value.¶
evidence, an integer index into the evidence array, optionally the member pointer, and no other member. With no pointer, the input is the digest the checker computes from the item it holds for that entry. With pointer, a JSON Pointer [RFC6901], the input is the value at that pointer in the item's bytes, parsed as strict JSON by the rules of Section 2.1; the item need not be in canonical form.¶
An issuer SHOULD bind an input to evidence rather than copy a value from an evidence item into body: a copy is the issuer's statement, while a bound input is read from the cited bytes.¶
body:kind. It holds the claim (Section 2.3) and any values the rule reads from body.¶
The member body.claim names the claim the verdict is about. It is an object with exactly one of two members: text, a string that states the claim, or ref, an evidence entry (as in evidence) for the record or receipt that carries the claim. When ref is used, the same entry MUST also appear in evidence.¶
This document does not define how a verdict record is signed, time-stamped or made available. From the container that carries the record, a checker needs three things: the exact bytes of the record; a key that bound those bytes, shown to belong to the party the record names in writer; and an upper time bound, a time no later than which the record existed, which the checker establishes itself.¶
A SCITT Signed Statement whose payload is the verdict record, registered on a Transparency Service whose Receipt the checker verifies, is one such container [RFC9943].¶
If the container does not show the record, the state is held, with the reason (Section 4.4).¶
When a step cannot run, the check goes on with its other steps. If a later step FAILs, the check FAILs at that step. Otherwise it is NOT RUN at the first step that could not run.¶
Two checkers that implement this document and hold the same inputs MUST give the same result and name the same step. No step reads the checker's clock.¶
Every input that a step relies on MUST come from outside the issuer's reach. In this document an input is outside the issuer's reach in two ways only: the checker computes it from bytes it holds (a digest, a signature, or the re-run of a rule), or it is the checker's own input (its policy (Section 4.5), its trust anchors, this document, and the rule specifications it holds). A checker MUST NOT take its own inputs from the record or from the issuer.¶
A statement made by the issuer alone, such as the content of the record, can be reported. It MUST NOT make a step PASS that would otherwise not pass.¶
A step MUST NOT rely on the absence of a statement that the issuer or the presenter could withhold.¶
One exception: under the default policy (Section 4.5), step 3 can rely on a value in body that check.inputs names. That value is the issuer's statement, and the report names each such input, so a reader can see which inputs came from the issuer.¶
Step 1. The member check MUST be present. It MUST name a rule and give a result. The rule judgement is allowed only for kinds that the checker's policy lists; otherwise step 1 FAILs.¶
Step 2. The member evidence MUST be an array of entries as in Section 2.2. For each entry, the checker MUST hold an item whose digest equals the entry's sha256; if it does not, step 2 is NOT RUN, naming the entry.¶
Each item is verified by the rules of the format its entry names. An item that does not verify, or whose format the checker's policy does not list, is not relied on: step 2 is then NOT RUN, naming it.¶
An item that is itself a verdict record is checked by this section, as a record of its own, and verifies only when its own state is released. Where an item's verification gives it an upper time bound, that bound MUST NOT be later than the upper time bound of the record that cites it; if it is later, step 2 is NOT RUN. The checker's policy sets how deep such citations are followed: the record being checked is at depth 0, so following one citation needs a depth of 1 or more. Beyond that depth, step 2 is NOT RUN.¶
Step 3. If the rule is not judgement, the checker MUST hold the rule's specification. It resolves each input that check.inputs names (Section 2.2) and re-runs the rule on them. If an input is bound to an evidence item the checker does not hold, or that step 2 does not rely on, step 3 is NOT RUN. If an input cannot be resolved (no such member of body, no such evidence entry, a binding object with another member, a pointer that does not resolve, or an item that is not JSON by the rules of Section 2.1), or is of the wrong JSON type, that is a FAIL of this step, not a result of the rule. If one input cannot be read for the first reason and another for the second, the step FAILs. If the checker's policy reads inputs from evidence only (Section 4.5), an input read from body makes step 3 NOT RUN. The result MUST equal check.result; if it does not, step 3 FAILs.¶
The check passes when steps 1 to 3 PASS.¶
A checker reports the record's state: released, when steps 1 to 3 PASS; held, when no step FAILs and at least one is NOT RUN; refused, when a step FAILs; or no verdict, when the checker's own policy is invalid. With the state it reports each step's result and, for each step that FAILed or did not run, the step and, where it did not run, the input it needed. Under the default policy the report also names each rule input read from body (Section 4.2).¶
A checker MUST NOT report any word or member that speaks for the whole record and that a reader could take as "this is true", such as verified, valid, true, trusted, correct, proven, confirmed or OK. A summary line, where one is printed, names the state and every step's result.¶
A state speaks as of the record's upper time bound. The report states that time, and the SHA-256 digest of the checker's policy (over its canonical form, Section 2.1) and of each set of trust anchors it used, so that another checker can see what the state rests on.¶
A checker's policy is its own input. It lists the kinds for which judgement is allowed, the evidence formats the checker can verify, and the depth of citation it follows, as an integer of 0 or more. It can also state that rule inputs are read from evidence only; by default they are read from body or from evidence, as each input says. A policy that lacks one of the first three, or states any of them in a form other than these, is invalid, and a checker whose policy is invalid gives no verdict.¶
Reading inputs from evidence only means that step 3 reads bytes the record cites by digest, not values written into body. Those bytes are outside the issuer's reach only as far as their verification in step 2 shows that another party made them. A record may still carry values in body; under this policy an input bound to body makes step 3 NOT RUN (Section 4.3), and other values in body play no part in the check.¶
A released verdict record shows that its issuer asserted the result, on the stated evidence, under the stated rule, no later than its upper time bound. It never shows that the claim is true.¶
For the rule judgement, a check shows only what the result was based on, and when. It does not show that the judgement is correct.¶
The values in body that a rule reads are the issuer's statement. A check does not show that they are true. An input bound to an evidence item shows only that the rule read the cited bytes; it does not show that what those bytes state is true.¶
A check does not show that the issuer kept its key secret, or that no other version of the record exists beyond those the checker holds. Nor does it show that no evidence item has been withdrawn (Section 6).¶
A check does not show that the evidence a record cites is all the evidence there was, or that the issuer wrote a record for every result it reached. A verdict record provides no completeness property. Where completeness matters, it comes from outside the record: from the container, or from the formats of the evidence items, for example a sequence that makes an omitted record visible.¶
A result can change: evidence arrives late, a cited item is withdrawn or superseded, or the rule or policy changes. A verdict record does not change. A reassessment is a new record. An issuer that reassesses its own result writes a new version of the same key, whose supersedes is the digest of the earlier version; both versions remain checkable. A party that reassesses another issuer's record writes a record of its own and cites the earlier record as evidence. If it cites the earlier record with the format "verdict-record/1", the new record is released only while the earlier one is; to reassess a record that is no longer released, it cites the earlier record's bytes under another format.¶
Where a record cites another verdict record, the cited record is checked each time the citing record is checked, and the citing record relies on it only if the cited record is released; otherwise step 2 is NOT RUN (Section 4.3). A change that alters the state of a cited record therefore reaches every record that cites it, to the depth the checker follows, the next time that record is checked. Because the check is deterministic (Section 4.1), such a change comes only from a change in the items the checker holds or in its own inputs, such as its trust anchors or policy. No notice is sent to the citing records. The aim is comparable to truth maintenance [DOYLE79], but nothing keeps justification links: the dependency is recomputed when a record is checked. A later version of a cited record does not by itself change the state of the earlier version; how a checker that holds a later version should treat a citation of the earlier one is an open question (Appendix B).¶
Because no step relies on the absence of a statement (Section 4.2), a checker cannot conclude that an evidence item has not been withdrawn. A withdrawal, retraction or revocation changes a check only where the verification rules of the item's format take it as input, or where the checker's trust anchors or policy change; no step of Section 4.3 reads it otherwise.¶
Receipts and records made by other formats, such as SCITT Signed Statements and Receipts [RFC9943], Agent Action Capsules [I-D.mih-scitt-agent-action-capsule] and Signed Evaluation Receipts [I-D.gruszka-signed-evaluation-receipts], enter a verdict record as evidence items. A verdict record adds no property to them and requires none of them.¶
The format member of an evidence entry is a media type [RFC6838] where one is registered for the item, and otherwise a URI that names the specification of the item's format. For an item that is itself a verdict record, the format is the string "verdict-record/1". A checker verifies an item only by the specification so named.¶
The digest in an evidence entry is the digest of the exact bytes that the item's format verifies. For a format whose items are signed envelopes, such as COSE_Sign1 or DSSE, those bytes include the envelope. Some formats identify an item by a different digest, for example a digest of the envelope's payload; that digest does not replace the one a verdict record uses. An issuer that wants to relate the two can cite the payload as an item of its own.¶
A verdict record is its issuer's statement. Its result can be wrong, and a mechanical rule can be re-run correctly on values that are false. A released state is a statement about what was asserted and on what evidence, not about the claim.¶
A presenter can withhold evidence items or later versions of a record. Because no step relies on the absence of a statement that could be withheld (Section 4.2), withholding can leave a step NOT RUN but cannot make a step PASS.¶
The rule judgement admits any result. A checker's policy limits it to the kinds for which the checker accepts a result that no rule re-derives.¶
The check is deterministic and reads no clock (Section 4.1), so two checkers holding the same inputs report the same state.¶
Every evidence item is given to the checker in full. An issuer ought to consider, before citing an item, whether it is fit to pass to every party that may check the record.¶
Key compromise, revocation and the trustworthiness of time sources are properties of the container (Section 3) and are outside the scope of this document.¶
This document has no IANA actions. A later version may ask IANA for registries of record kinds, rule names and evidence format names, which this version lists in Section 2.2, Section 4.3 and Section 7.¶
The record below is a decision by a model on a claim carried by another record. Its rule is judgement, so a checker re-runs no rule; it holds both evidence items, verifies each by its own format, and reports the state. Long lines are folded for display as described in [RFC8792]; the record itself has no whitespace and no line breaks.¶
The claim record cited by both body.claim.ref and the first evidence entry is these bytes:¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
{"made_by":"builder.example","statement":"Release 2.1 of example-ser\
vice passed its acceptance suite."}
¶
The verdict record, with whitespace added for display:¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"act_time": "2026-10-23T10:00:00.000000Z",
"actor": {
"id": "checker-7",
"model": "example-model",
"model_version": "1",
"type": "system"
},
"body": {
"claim": {
"ref": {
"format": "application/json",
"sha256": "f4747f1fa1ad63eaad90e41b587794f8f5c82f9215b9a8e23\
a6c204edabc7d48"
}
}
},
"check": {
"result": "supported",
"rule": "judgement"
},
"evidence": [
{
"format": "application/json",
"sha256": "f4747f1fa1ad63eaad90e41b587794f8f5c82f9215b9a8e23a6\
c204edabc7d48"
},
{
"format": "https://datatracker.ietf.org/doc/draft-gruszka-sign\
ed-evaluation-receipts/",
"sha256": "0c964f45c450a0253fc09eb2316e6ad271944be201c46ebf2c5\
d40e529f35306"
}
],
"key": "verdict-0001",
"kind": "model-decision",
"supersedes": null,
"v": "verdict-record/1",
"version": 1,
"writer": "verifier.example"
}
¶
Its digest, over its canonical bytes, is:¶
2a85c94e39c56f50185b3b69b8f56026946364631799774a83b4f93399841c45¶
This record checks two delegation hop records from [I-D.durga-agenttrust-trace-verification], contributed by that document's author.¶
Its rule, named urn:example:verdict-record:rule:hop-continuity-attenuation:v1 for this example, applies items 2 and 3 of Section 5 of that document and not the other checks of that section. It takes exactly four inputs: parent_hash and parent_digest, which are strings, and parent_scopes and child_scopes, which are arrays of strings. Its result is "attenuated_and_linked" when parent_hash equals parent_digest and every member of child_scopes is a member of parent_scopes, and "not_attenuated_or_not_linked" otherwise. Here parent_digest is the digest of the cited bytes, which equals that document's SHA256(JCS(hop)) only when the item is already in JCS form, as these are. Each input is bound to an evidence item, so body holds only the claim, and a checker that reads inputs from evidence only (Section 4.5) can re-run the rule.¶
The parent hop, evidence item 0:¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
{"expires_at":1793463600,"granted_scopes":["mcp:tool:erp.ledger.read\
","mcp:max_rows:100"],"issued_at":1793460000}
¶
The child hop, evidence item 1:¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
{"expires_at":1793463600,"granted_scopes":["mcp:tool:erp.ledger.read\
"],"issued_at":1793460000,"parent_record_hash":"1336337e88adc67853b8\
0b4998363210dc5c0797cc7b7c722128cecc56a38c14"}
¶
The verdict record, with whitespace added for display:¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
{
"act_time": "2026-10-31T18:00:00.000000Z",
"actor": {
"id": "agenttrust-trace-checker",
"model": "none",
"model_version": "0",
"type": "system"
},
"body": {
"claim": {
"text": "hop[1] preserves SHA-256 parent_record_hash continuit\
y and monotonic scope attenuation from hop[0]"
}
},
"check": {
"inputs": {
"child_scopes": {
"evidence": 1,
"pointer": "/granted_scopes"
},
"parent_digest": {
"evidence": 0
},
"parent_hash": {
"evidence": 1,
"pointer": "/parent_record_hash"
},
"parent_scopes": {
"evidence": 0,
"pointer": "/granted_scopes"
}
},
"result": "attenuated_and_linked",
"rule": "urn:example:verdict-record:rule:hop-continuity-attenuat\
ion:v1"
},
"evidence": [
{
"format": "https://datatracker.ietf.org/doc/draft-durga-agentt\
rust-trace-verification/",
"sha256": "1336337e88adc67853b80b4998363210dc5c0797cc7b7c72212\
8cecc56a38c14"
},
{
"format": "https://datatracker.ietf.org/doc/draft-durga-agentt\
rust-trace-verification/",
"sha256": "8886795d4403b5cd8820eb813ee0724f1d6d5d383124364b09c\
dc5020639e00c"
}
],
"key": "agenttrust/trace/hop-1",
"kind": "check-run",
"supersedes": null,
"v": "verdict-record/1",
"version": 1,
"writer": "agenttrust-reference-verifier"
}
¶
Its digest, over its canonical bytes, is:¶
62017940a8ddddd5ddd7ff46c8ff2a6ce79dfcccb775d767b8dff8db0ebe19ed¶
The hops carry no signature, which the format of [I-D.durga-agenttrust-trace-verification] requires. A checker that applies that requirement reports held, at step 2. A checker that verified these hop records without a signature, which this document does not yet define (Appendix B), and that held the rule's specification above, would report released. If the child hop widened the scopes, the re-run would give a different result and the record would be refused; if the checker did not hold the child hop, the record would be held. Test vectors for these cases are being added to the test vectors for this document (Appendix B).¶
This section is to be removed before publication.¶
This section is to be removed before publication.¶
body; a checker's policy can read inputs from evidence only (Section 2.2, Section 4.3, Section 4.5).¶
body, and a record whose copies disagreed with its cited evidence was still released; under -02 that remains so unless the checker's policy reads inputs from evidence only.¶
This section is to be removed before publication.¶