]> b7n0de

Germany kontakt@b7n0de.com

Security AUDIT agent decision receipt in-toto DSSE The architecture for auditing agent delegation and interactions proposed for the AUDIT effort names Interaction Records, Action Records and Authorization Transition Records, and leaves their encoding open. This document shows how an existing signed record, the decision receipt of the open-source proofbundle project, together with its companion outcome receipt, gives three such records exact bytes, a signature and digest bindings that a third party can check offline. The three cases are a human approval, a declined action and an executed action with its result. For each case the document maps the receipt members onto the record types of the architecture, states what the receipt adds and what it does not show, and gives an offline verification procedure. It states one requirement for approvals, that an approval is honoured at most once, also after the record of consumed approvals is rotated. Test vectors for all three cases, each with a counterexample, are included. The document also describes, informatively, how a receipt can be registered with a Transparency Service under RFC 9943 and what a SCITT Receipt then shows and does not show. This document defines no new format, predicate or registry.

Introduction The architecture of asks that auditing link user intent, delegation, authorization and execution, and treats authorization as a state that changes over time. Three of its four record types (its Section 5) matter here. Interaction Records capture user-facing events such as approvals and refusals, Action Records capture events at the boundary where an action took effect, and Authorization Transition Records capture changes in permission state. Its field names are placeholders (its Section 7), and a canonical data model is a work item (WI-1). An Auditor in that architecture does not trust the Agent (its Section 8), so a record helps only when a third party can check it. That needs exact bytes, a signature over them and bindings to inputs and evidence by digest. This document shows that the decision receipt of proofbundle , an in-toto Statement in a DSSE envelope , signed with Ed25519 over a payload in the serialization of , supplies them together with its companion outcome receipt . It does so for three cases that Agent Guard, the gate of the proofbundle plugin for two coding agent hosts, produces ():

1. a human approval of one action (an Interaction Record of an approval and an Authorization Transition Record with the trigger user_approval);
2. a declined action, with its reason and without an effect;
3. an executed action with its result (an Action Record).

The document maps and verifies. It does not propose the decision receipt as the data model of the architecture and does not change the receipts it describes. The mapping of follows revision -01 of ; a later revision of the architecture can change it.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. In this document, these key words apply to a verifier in and in the procedure of , to an Auditor that performs the checks of , to a relying party that lets an action run because of an approval in , and to the use of the test keys of .

Terms

Decision receipt, outcome receipt:

A DSSE envelope whose payload is an in-toto Statement v1 with the predicate type https://b7n0de.com/proofbundle/predicates/decision-receipt/v0.1 or https://b7n0de.com/proofbundle/predicates/action-outcome/v0.1.

Payload bytes:

The bytes obtained by base64 decoding the payload member of the envelope. A DSSE signature covers the pre-authentication encoding of payloadType and these bytes.

Content root:

SHA-256 over the payload bytes. Other digests commit to the byte strings identified by their respective fields.

Approval record:

The record of one human act that approves one action ().

Relying party:

The component that lets an action run because of a decision.

Consumption record:

The durable record in which a relying party notes each approval it has honoured.

Mapping the Three Cases onto AUDIT Records All decision receipts here use the decisionType preActionAuthorization and carry validity with audience, nonce and expiresAt. A decision receipt is the gate's signed view of an event; the human act itself is the approval record, bound by digest. In the tables, IR stands for Interaction Record, ATR for Authorization Transition Record and AR for Action Record, followed by a placeholder field of the architecture. The fields common to all cases map as follows.

event_id

decisionId (outcomeId in an outcome receipt)

trace_id, parent_id

traceContext.traceId, traceContext.parentId

timestamp

decidedAt (performedAt in an outcome receipt)

actor, on_behalf_of

agent.id, principal.id

action

proposedAction (actionType, target, method)

exact action bytes

proposedAction.parametersDigest

authorization.expires_at

validity.expiresAt

delegation_chain

none (delegationRefs is not used here)

record signer

decisionMaker.id, bound to the key by a trust policy

Case 1, a Human Approval A gate asks a person before an action and records the answer. An earlier receipt for the same request, such as one with the verdict ESCALATE, is a separate record; this receipt does not reference it. After the answer the gate decides ALLOW for exactly the approved action. The approval record carries approvalId, approver, session, actionDigest (SHA-256 of the approved action bytes), approvedAt and validUntil. The decision receipt names it in inputSnapshot under the name "approval record". Case 1

Record, field	Decision receipt
IR, approval	approval record, by its digest in inputSnapshot
IR, actor	approver in the approval record, equal to principal.id
ATR, previous_state	not recorded in this receipt; preceding state must be established separately
ATR, new_state	verdict ALLOW for parametersDigest
ATR, trigger	reasonCodes contains user_approval
ATR, actor	approver in the approval record

The scope of the new state is one action, identified by its bytes. A second action, even one with the same name and target, needs a new approval.

Case 2, a Declined Action A gate declines an action because a rule or a person says no. The receipt records the verdict DENY with its reasons. It may say in actionOutcome that the call was blocked, which is the decision maker's own statement. Case 2

Record, field	Decision receipt
IR, refusal	verdict DENY or REFUSE
reason	reasonCodes
action	proposedAction with parametersDigest
no effect	actionOutcome.status blocked (self-asserted); no outcome with status executed names this decision in the supplied set
ATR	none; the state is unchanged

A receipt cannot prove that something did not happen. An observer at the boundary can separately report that it observed no effect. The check in detects a conflicting executed outcome in the supplied set; it does not establish absence of an effect.

Case 3, an Executed Action and Its Result A gate allows an action, the action runs, and an executor or an observer at the boundary records what happened in an outcome receipt signed with its own key. The outcome receipt names the decision by its content root in decisionRef. Case 3

Record, field	Outcome and decision receipt
AR, event_id	outcomeId
AR, parent_id	traceContext.parentId of the referenced decision
decision binding	decisionRef, the content root of the decision
AR, timestamp	performedAt
AR, actor	executor.id
AR, action	requestedActionDigest, equal to parametersDigest
result	status executed, effectDigest
authorization	the decision (ALLOW, validity.expiresAt)
evidence	evidenceRefs of the decision

The architecture asks that Action Records be produced at the boundary where the action took effect. Its WI-1-3 distinguishes the Recorder's signing identity from the recorded Agent's identity where they are operationally separate. checks that the outcome and decision use different keys and that executor.id differs from decisionMaker.id. Those checks alone do not establish operational separation or that the outcome signer observed the boundary.

What the Receipt Adds

• Exact bytes. The payload is its own serialization under . A verifier uses the received payload bytes for the signature input and content root. Canonical serialization is used to check equality and to derive the predicate's subject digest, never to repair or replace the received payload.
• A signature. Ed25519 over the DSSE pre-authentication encoding of the payload type and the payload bytes.
• Binding by digest. The action bytes (parametersDigest), the approval record and other inputs (inputSnapshot), the policy (policyBoundary.policyDigest), evidence (evidenceRefs), the decision itself (decisionRef in the outcome) and the observed effect (effectDigest) are named by SHA-256.
• Stated limits. The member notChecked lists what the decision maker did not check, and decisionChangeConditions lists what would change the decision.

What the Receipt Does Not Do

• It does not show that a decision was correct, safe or lawful.
• It does not authenticate the approval. The approval record in this document is not signed by the person it names. A deployment can additionally cite a separately signed approval in inputSnapshot. Validating that signature and establishing its correspondence to the approval record require rules beyond this document. The signed approvals of are one possible source of such evidence.
• It does not show that an effect happened. An outcome receipt shows that its signer stated an effect with a given digest. A digest that cannot be resolved to bytes shows only that a value was written.
• It does not register anything. Transparency in the sense of needs a separate registration and a SCITT Receipt; describes how a receipt of this document can be registered.
• It does not detect a receipt that was never written, unless an observer or a sequence counter is added.
• Its times are the signer's clock.
• It is not an access token. A verified ALLOW is a record of a decision, and the executing system makes its own authorization check.

Evaluation Receipts Are Evidence, Never Authorization A decision may rest on an evaluation result, such as a test suite that passed. A Signed Evaluation Receipt records such a result. It appears in a decision receipt only as an entry of evidenceRefs whose digest is the receipt digest, SHA-256 over its payload bytes, as in . A verifier MUST NOT treat a valid Signed Evaluation Receipt, or its presence in evidenceRefs, as permission for an action. In the records of this document only a decision receipt with the verdict ALLOW, from a key the relying party trusts for decisions, records a permission.

Observations for the Architecture This section is informative. At the places below, the mapping of this section needed a reading of revision -01 of . They are offered as observations and questions, not as requirements.

• Evidence for a human approval. associates Interaction Records with the User; Section says that user-facing systems produce records of prompts and approvals, and Section has the Auditing Service sign records under its own identity. In Case 1, the gate's decision receipt binds an approval record that names a person but is not signed by that person ( and ). What evidence is needed to bind such a record to that person's act of approval, and when is the person's own signature required?
• Previous state. The Authorization Transition Record of , and its work item WI-1-4 (), carries a previous state, a new state, a trigger and an actor in one record. A decision receipt records only the new state for one action and leaves the previous state to other records (). reconstructs authorization from the ordered sequence of such records; is a record without the previous state enough for that?
• Binding an Action Record to its authorization. In the parent_id of an Action Record references the Interaction Record that motivated the action, and the authorization appears as scope and expiry. The outcome receipt of Case 3 names the decision receipt by its content root in decisionRef and takes parent_id from that decision (). The examples of have no member that binds an Action Record to the authorizing decision by digest.
• Refusals before execution. includes model responses and agent-to-agent dialogue among Interaction Records. Its work item WI-1-2 () also includes system events and does not preclude profiles for non-conversational interactions. In Case 2, a gate can decline a proposed action under a rule before execution (). When such a denial is internal to a workflow and is not part of a conversation, is it an Interaction Record, an Action Record of an attempted request, or a different event type?
• Who records an action. has Action Records generated by the Agent, while places them at the boundary where the action took effect. Its work item WI-1-3 () already distinguishes the Recorder's signing identity from the recorded Agent's identity where they are operationally separated. In Case 3 the outcome signer can be an observer that attests the executor's identifier ( and ). How should an Action Record and the Auditor's trust policy identify the Recorder separately from the actor whose action is recorded?

Offline Verification The procedure below needs no network access. Each step either passes or ends the procedure with a failure named by the step. A later step never repairs an earlier failure.

Inputs The verifier needs the envelope bytes of each receipt and the Ed25519 public keys selected by its trust policy for the decision signer and, for Case 3, the outcome signer. It also needs the expected decisionMaker.id and, for Case 3, the expected executor.id whose assertion that policy permits under the outcome-signing key. An outcome signer may be an observer rather than the executor. The verifier supplies an evaluation time T in UTC; it does not take T from a receipt. Expected audience and nonce and the action and effect byte strings are optional inputs. Case 1 requires the approval record bytes. Inputs or evidence whose bytes are not checked remain digest references, not verified contents.

Decision Receipt

1. Envelope. The envelope MUST be valid UTF-8 and parse as one JSON text of that is an object, with no duplicate member names in any object. The envelope bytes MUST NOT begin with the byte order mark U+FEFF, which forbids adding. It MUST contain payload, payloadType and signatures. payloadType MUST be application/vnd.in-toto+json.
2. Payload bytes. Decode payload as base64 into the payload bytes P.
3. Signature. Form PAE = "DSSEv1" SP LEN(type) SP type SP LEN(P) SP P, where SP is one space, LEN is the length in bytes as ASCII decimal without leading zeros, and type is the payloadType. At least one entry of signatures MUST carry a base64 sig that verifies as an Ed25519 signature over PAE under the expected key. The keyid member is not used to select a key.
4. Canonical form. P MUST be valid UTF-8 and parse as one JSON value with no duplicate member names. The serialization of the parsed value under MUST be byte for byte equal to P. A verifier MUST NOT continue with a re-serialized form.
5. Content root. Compute R = SHA-256(P).
6. Statement. _type MUST be https://in-toto.io/Statement/v1 and predicateType the decision receipt type of . subject MUST contain exactly one entry, whose digest.sha256 is SHA-256 over the serialization of predicate; it MUST NOT contain other entries.
7. Members. predicate MUST be a JSON object satisfying the field rules of . It MUST contain schemaVersion, decisionId, decisionType, decidedAt, decisionMaker, agent, principal, proposedAction, inputSnapshot, policyBoundary (with policyDigest), evidenceRefs, decision, notChecked, decisionChangeConditions, privacy and validity. Other predicate members are limited to recordedAt, delegationRefs, actionOutcome and traceContext.decisionMaker, agent, principal, proposedAction, policyBoundary, decision, privacy and validity MUST be objects. decisionId, decisionMaker.id, agent.id and principal.id MUST be non-empty strings. inputSnapshot, evidenceRefs, notChecked and decisionChangeConditions MUST be arrays. decision.reasonCodes MUST be a non-empty array of non-empty strings.schemaVersion MUST consist of "0.1." followed by one or more ASCII decimal digits. decisionType MUST be preActionAuthorization. Every timestamp, when non-null, MUST be an UTC timestamp with a trailing "Z". Every non-null digest MUST be an object with exactly one member, sha256, whose value is 64 lowercase hexadecimal digits. A null is allowed only where the applicable field rules or explicitly permit it.The digests of a decision receipt are the members listed below, each with its full path in predicate, where [] stands for each entry of an array.
   • agent.configurationDigest
   • principal.authnContextRef.digest
   • proposedAction.target.digest
   • proposedAction.parametersDigest
   • proposedAction.parametersSchemaRef.digest
   • inputSnapshot[].digest
   • policyBoundary.policyDigest
   • evidenceRefs[].digest
   • evidenceRefs[].artifactDigest
   • actionOutcome.outcomeRef.digest
   The timestamps of a decision receipt are the members listed below.
   • decidedAt
   • recordedAt
   • policyBoundary.validFrom
   • policyBoundary.validUntil
   • actionOutcome.performedAt
   • validity.expiresAt
   actionOutcome.outcomeRef is an object whose member digest is a digest; it is not itself a digest. evidenceRefs[].typedDigest, where present, is not a digest in this sense either. It MUST be an object whose members are type, digestAlgorithm and digest and optionally purpose; type and purpose MUST be non-empty strings, digestAlgorithm MUST be jcs-sha256-v1, and digest MUST be 64 lowercase hexadecimal digits.
8. Signer. decisionMaker.id MUST be the identifier the trust policy binds to the key of step 3.
9. Validity. validity MUST carry a non-empty array of non-empty audience strings, a non-empty nonce string and an expiresAt timestamp. decidedAt MUST NOT be later than T, and T MUST be strictly earlier than expiresAt. Where an expected audience is given, audience MUST contain it; where an expected nonce is given, nonce MUST equal it.
10. Action bytes. Where the action bytes are given, their SHA-256 MUST equal proposedAction.parametersDigest.sha256.

Checks per Case

Case 1, approval.

decision.verdict MUST be ALLOW and decision.reasonCodes MUST contain user_approval. inputSnapshot MUST contain exactly one entry whose name is "approval record"; it may contain other entries. The approval record bytes A MUST be supplied, MUST hash to that entry's digest, and MUST be their own serialization.A MUST be a JSON object containing approvalId, approver, session, actionDigest, approvedAt and validUntil. approvalId, approver and session MUST be non-empty strings. actionDigest MUST have the digest form of and MUST equal proposedAction.parametersDigest. approver MUST equal principal.id. approvedAt and validUntil MUST be UTC timestamps with a trailing "Z". The bounds approvedAt <= decidedAt <= T < validity.expiresAt <= validUntil MUST hold.

Case 2, declined.

decision.verdict MUST be DENY or REFUSE. Where actionOutcome is present, its status MUST be notAttempted, blocked or refused, and performedAt and outcomeRef MUST be absent or null.

Case 3, executed.

decision.verdict MUST be ALLOW. The outcome receipt MUST have status executed and MUST pass against this decision.

Outcome Receipt

1. Apply steps 1 to 5 of separately to the outcome envelope with the expected outcome-signing key, obtaining payload bytes Q. Retain the decision receipt's content root R for the binding check below.
2. _type MUST be https://in-toto.io/Statement/v1 and predicateType the outcome receipt type. subject MUST contain exactly one entry, whose digest.sha256 is SHA-256 over the serialization of predicate; it MUST NOT contain other entries, as in step 6 of .
3. Members. predicate MUST be a JSON object satisfying the field rules of . It MUST contain schemaVersion, outcomeId, decisionRef, executor, requestedActionDigest, status and performedAt. Other predicate members are limited to effectDigest, actualActionDigest, responseDigest, policyPurpose, receiverRefs, sequence, recordedAt, limitations, traceContext and validity.schemaVersion MUST consist of "0.1." followed by one or more ASCII decimal digits. outcomeId MUST be a non-empty string. executor MUST be an object with a non-empty id string. status MUST be executed, refused, failed or partial. Each non-null timestamp MUST be an UTC timestamp with a trailing "Z". Each non-null digest MUST be an object with exactly one member, sha256, whose value is 64 lowercase hexadecimal digits. A null is allowed only where the applicable field rules permit it.The digests of an outcome receipt are the members listed below, each with its full path in predicate, where [] stands for each entry of an array.
   • decisionRef
   • requestedActionDigest
   • actualActionDigest
   • responseDigest
   • effectDigest
   • receiverRefs[].digest
   • receiverRefs[].artifactDigest
   The timestamps of an outcome receipt are the members listed below.
   • performedAt
   • recordedAt
4. Binding. decisionRef.sha256 MUST equal the content root R of the decision receipt that passed , and requestedActionDigest MUST equal its parametersDigest.
5. Identity and separation. executor.id MUST equal the expected executor identifier supplied under . The verifier's trust policy MUST permit the outcome-signing key to attest that identifier. That key MUST differ from the decision maker's key, and executor.id MUST differ from decisionMaker.id. These checks do not establish that the two keys are controlled by operationally independent parties.
6. Result. status executed MUST come with a non-null effectDigest. Where effect bytes are supplied, effectDigest MUST be present, whatever the status, and their SHA-256 MUST equal effectDigest.sha256.
7. Time. performedAt MUST NOT be earlier than the decision's decidedAt and MUST be strictly earlier than its validity.expiresAt.

Checks over a Set of Receipts An Auditor that holds the receipts and approval records of a run can check two properties that no single receipt shows. The Auditor MUST obtain the relying party's consumption scope from its audit context or trust policy; that scope is not inferred from an approvalId alone. First, within that scope, no two distinct ALLOW decision payloads, identified by different content roots, may cite approval records with the same identity (approvalId, actionDigest and session). Such a pair violates ; additional copies or signatures of one payload do not. Second, no outcome receipt with status executed may name, in decisionRef, the content root of a receipt with the verdict DENY or REFUSE. Both checks are only as complete as the set of receipts the Auditor holds. The first check does not detect two executions that reuse one ALLOW receipt without producing another decision receipt.

What a Pass Shows A pass shows that the holder of the decision maker's key signed exactly these payload bytes. Where action bytes are supplied under , their SHA-256 matches proposedAction.parametersDigest.sha256. In Case 1, the SHA-256 of the required approval record bytes matches the digest.sha256 value of the unique inputSnapshot entry whose name is "approval record". For Case 3, a pass also shows that the holder of a different key, which the trust policy permits to attest the expected executor.id, signed an outcome with status executed bound to that decision. It does not show that the signer's statements are true, that the approval came from the named person, that the outcome signer observed the boundary, that no other receipt exists, or that the keys were not misused. Those questions belong to the trust policy, to signed approvals, to observers and to transparency registration ().

Registering a Receipt with a Transparency Service This section is informative. It describes how the receipts of this document can be registered with a Transparency Service under . It defines no format, predicate type, media type or registry and adds no requirement to those of . Registration. In SCITT a Signed Statement is a COSE_Sign1 message whose protected header carries CWT Claims with an Issuer Claim and a Subject Claim (). A decision receipt or an outcome receipt can be registered in two ways. Its envelope bytes can be the payload of a Signed Statement. Or, as allows for Statements too large or too sensitive to send to a Transparency Service, the Signed Statement can be made over a hash, here the content root of the receipt. This document does not define how a Signed Statement indicates the hash, its algorithm or its content type; that belongs to a deployment's profile and to the Registration Policy of the Transparency Service (). gives one example Signed Statement for each of the two ways, with a SCITT Receipt for each. Issuer. The Issuer of the Signed Statement is the entity identified by its iss Claim, whose key signs the COSE_Sign1 (Sections and of ). It can be the decision maker or the outcome signer, or another party such as the Auditing Service of . The Client that registers a Signed Statement need not be its Issuer (). The Issuer's COSE signature is separate from the DSSE signature of the receipt. The COSE signature authenticates the Signed Statement's protected header and payload. The DSSE signature covers the pre-authentication encoding of the receipt's payloadType and decoded payload bytes, not the DSSE envelope as a whole. or checks that DSSE signature and its signer. What a SCITT Receipt shows. During Registration the Transparency Service verifies the Issuer's signature and applies its Registration Policy (Sections and of ). It registers the Signed Statement before it releases a Receipt (), and the Receipt demonstrates inclusion of the Signed Statement in the Verifiable Data Structure of the Transparency Service and can be verified without online access to it (). The Transparency Service records the Registration time when it adds the Signed Statement (). What it does not show. Registering a Statement proves only that it was produced by an Issuer, not that it is accurate (). Issuers can register some Statements and not others (), so a Receipt for one receipt says nothing about a receipt that was never registered. The Subject Claim lets Relying Parties identify the Transparent Statements registered for a Subject (), not receipts that were never registered. Unless the Registration Policy says otherwise, the order of the Verifiable Data Structure need not be the order of issuance (). A Receipt does not change what the checks of show, and it does not make an ALLOW an authorization. Verification. A verifier checks the SCITT Receipt for the particular Signed Statement, including its inclusion proof, using the verification key of a Receipt Issuer it trusts and the verification rules for the applicable Verifiable Data Structure (Sections and of ). It establishes the binding from the registered Signed Statement to the envelope bytes or content root used in the following checks. If the Signed Statement's COSE payload is detached and this binding depends on the Issuer's signature, it verifies that signature. It then applies of this document to the receipt. Where the envelope bytes are the Signed Statement's payload, it checks those bytes; where the Signed Statement is made over the content root, it checks an envelope whose computed content root equals the registered value. This latter comparison binds the decoded DSSE payload, not the envelope bytes or the DSSE signature, and does not establish that the DSSE signature existed when the content root was registered. permits verification of a Receipt without rechecking the Issuer's signature on the Signed Statement; this does not dispense with the binding just described. The signatures of the decision maker and of the outcome signer are checked by in either case.

Field Rules Step 7 of and step 3 of apply the rules of this section. lists every member of the predicate of a decision receipt that this document admits, and every member of the predicate of an outcome receipt, each with its full path in predicate, where [] stands for each entry of an array. The rules follow the strict v0.1 form of and and their machine schemas, restricted to the members this document admits; where is stricter, the table gives the stricter rule. This section states these rules itself, and its tables follow those documents as they stand at commit e1fec86351b216af369a2e6ac106dcc41aaf4b4c of , where the machine schemas are the same as in version 6.4.0. In the column Type, a digest is an object with exactly one member, sha256, whose value is 64 lowercase hexadecimal digits; a timestamp is an UTC timestamp with a trailing "Z"; typedDigest has the form given in step 7 of ; a string is any JSON string, and a non-empty string has at least one character; a boolean is one of the JSON values true or false; any value is any JSON value. The type object admits only the members listed for it, and the type open object admits any members. The type names preActionAuthorization and outcome allow only the JSON strings "preActionAuthorization" and "outcome", respectively. The type "0.1." and one or more digits means a string consisting of "0.1." followed by one or more ASCII decimal digits. The notes (1) to (4) follow the tables. Required yes means that the member MUST be present whenever the object or array entry that contains it is present. Null yes means that the member may be null. Everywhere else a null is not allowed, also inside an open object and in an array of any values. A member that the table does not list for an object that is not open is not allowed, at the top level of predicate as well. Members of the predicate of a decision receipt

Member	Type	Required	Null
schemaVersion	"0.1." and one or more digits	yes	no
decisionId	non-empty string	yes	no
decisionType	preActionAuthorization	yes	no
decidedAt	timestamp	yes	no
recordedAt	timestamp	no	no
decisionMaker	object	yes	no
decisionMaker.id	non-empty string	yes	no
decisionMaker.version	any value	no	yes
agent	object	yes	no
agent.id	non-empty string	yes	no
agent.version	string	no	no
agent.configurationDigest	digest	no	no
principal	object	yes	no
principal.id	non-empty string	yes	no
principal.authnContextRef	object	no	no
principal.authnContextRef. uri	string	no	no
principal.authnContextRef. digest	digest	no	no
delegationRefs	array of any values	no	no
proposedAction	object	yes	no
proposedAction.actionType	string	yes	no
proposedAction.target	object	no	no
proposedAction.target.name	string	no	no
proposedAction.target.uri	string	no	no
proposedAction.target. digest	digest	no	no
proposedAction.method	string	no	no
proposedAction. parametersDigest	digest	(1)	no
proposedAction. parametersRef	open object	(1)	no
proposedAction. parametersSchemaRef	object	no	no
proposedAction. parametersSchemaRef.uri	string	no	no
proposedAction. parametersSchemaRef.digest	digest	no	no
inputSnapshot	array of objects	yes	no
inputSnapshot[].name	string	no	no
inputSnapshot[].uri	string	no	no
inputSnapshot[].digest	digest	yes	no
inputSnapshot[].mediaType	string	no	no
policyBoundary	object	yes	no
policyBoundary. policyEngine	non-empty string	yes	no
policyBoundary.policyId	non-empty string	yes	no
policyBoundary. decisionPath	non-empty string	yes	no
policyBoundary. policyDigest	digest	yes	no
policyBoundary. bundleRevision	string	no	no
policyBoundary.validFrom	timestamp	no	no
policyBoundary.validUntil	timestamp	no	no
evidenceRefs	array of objects	yes	no
evidenceRefs[].relation	string	yes	no
evidenceRefs[].digest	digest	yes	no
evidenceRefs[]. artifactDigest	digest	no	no
evidenceRefs[].uri	string	no	no
evidenceRefs[]. predicateType	string	no	no
evidenceRefs[].typedDigest	typedDigest	no	no
decision	object	yes	no
decision.verdict	(2)	yes	no
decision.reasonCodes	non-empty array of non-empty strings	yes	no
decision. humanReadableSummary	string	no	no
decision.obligations	array of any values	no	no
decision.allowedScope	array of any values	no	no
notChecked	array of objects or strings	yes	no
notChecked[].field	string	no	no
notChecked[].reason	string	no	no
notChecked[].impact	string	no	no
decisionChangeConditions	array of objects	yes	no
decisionChangeConditions[]. conditionType	string	no	no
decisionChangeConditions[]. description	string	no	no
decisionChangeConditions[]. requiredEvidenceType	string	no	no
actionOutcome	object	no	no
actionOutcome.status	(3)	no	no
actionOutcome.performedAt	timestamp	no	yes
actionOutcome.outcomeRef	object	no	yes
actionOutcome.outcomeRef. uri	string	no	no
actionOutcome.outcomeRef. digest	digest	no	no
traceContext	open object	no	no
privacy	object	yes	no
privacy.rawInputsIncluded	boolean	yes	no
privacy.redactionProfile	string	no	no
privacy.erased	array of any values	no	no
privacy.masked	array of any values	no	no
validity	object	yes	no
validity.audience	non-empty array of non-empty strings	yes	no
validity.nonce	non-empty string	yes	no
validity.expiresAt	timestamp	yes	no

Members of the predicate of an outcome receipt

Member	Type	Required	Null
schemaVersion	"0.1." and one or more digits	yes	no
outcomeId	non-empty string	yes	no
decisionRef	digest	yes	no
executor	object	yes	no
executor.id	non-empty string	yes	no
executor.keyId	string	no	no
requestedActionDigest	digest	yes	no
status	(4)	yes	no
performedAt	timestamp	yes	no
effectDigest	digest	no	no
actualActionDigest	digest	no	no
responseDigest	digest	no	no
policyPurpose	outcome	no	no
receiverRefs	array of objects	no	no
receiverRefs[].relation	non-empty string	yes	no
receiverRefs[].digest	digest	yes	no
receiverRefs[].receiverId	string	no	no
receiverRefs[]. receiverKeyId	string	no	no
receiverRefs[]. artifactDigest	digest	no	no
sequence	object	no	no
sequence.runId	non-empty string	yes	no
sequence.seq	integer, 0 or more	yes	no
recordedAt	timestamp	no	no
limitations	array of strings	no	no
traceContext	object	no	no
traceContext.traceparent	string	no	no
validity	object	no	no
validity.audience	array of any values	no	no
validity.nonce	string	no	no

The notes of the tables are as follows. (1) proposedAction MUST carry parametersDigest, parametersRef or both. (2) decision.verdict is ALLOW, DENY, REFUSE, ESCALATE, DEFER or OBSERVE. (3) actionOutcome.status is notAttempted, blocked, refused, attempted, executed, failed or unknown. (4) status is executed, refused, failed or partial. adds rules per case, and steps 8 to 10 of and steps 4 to 7 of add rules across members.

Approvals Are Honoured At Most Once An approval in Case 1 frees one action once. For live use, the relying party MUST apply the time bounds of with its own current time as T. A historical audit time MUST NOT make an expired approval usable. A relying party that lets an action run because of an approval:

1. MUST honour each approval at most once;
2. MUST key its consumption state by the identity of the approval (approvalId, actionDigest and session), not by the bytes of one copy of the approval record. Copies or reissues with other metadata count as the same approval and MUST NOT extend its original validUntil. Extending that validity requires a new approval act and a new approvalId;
3. MUST mark the approval as consumed durably before it either allows the action to run or releases a signed ALLOW that cites the approval;
4. MUST treat an approval recorded as consumed in any current, rotated, archived or compacted representation as consumed for as long as item 6 requires that state to be retained;
5. MUST NOT honour an approval unless it can consult a complete, durable view of the consumption state required by this section. Rotation, archiving or compaction MAY replace earlier generations if all entries still required by item 6 are preserved. Missing or unreadable state whose required entries have not been preserved elsewhere MUST cause refusal;
6. MAY drop an entry only after the approval's original validUntil, plus the clock skew the relying party allows, has passed and no copy of that approval can still be honoured.

Rotation is the step where this requirement is most easily lost. A record that is full is moved aside so that new approvals can be written; if the relying party then reads only the new generation, approvals of the old one may become usable again. Items 4 and 5 preserve the consumed state without requiring a particular storage format. A decision receipt for Case 1 binds the approval record by digest, so can expose distinct ALLOW decisions for the same approval identity. Preventing reuse of an approval or of an already issued ALLOW remains the relying party's duty.

Implementation Status This section is given per and is to be removed by the RFC Editor before publication. proofbundle 6.4.0 is on PyPI with the classifier "Development Status :: 4 - Beta"; its tag v6.4.0 is commit 699545521ec5ef479bb84e61fe7461fc79ed558c of . There the decision receipt predicate is described as shipped since version 2.1.0 and the outcome predicate as experimental. In the seven command line runs reported in , the four passing vectors returned exit code 0, the invalid signature of V1-bad returned 1, and the non-canonical payload of V2-bad and the decision binding mismatch of V3-bad each returned 2. These results do not specify the command line interface's complete exit-code contract. Agent Guard is the name used here for the preview in plugins/proofbundle of the same repository, inspected at commit 8bb289c8b41d32c54734155fc00756231093bc2a. This inspected revision is not the release tag v6.4.0. Its public README names the preview the proofbundle plugin for Claude Code and Codex. In the inspected code, the configured receipt pilot uses a separate signing service for preActionAuthorization decisions with verdict ALLOW, DENY or ESCALATE for the writes it supports. An observer signs outcome receipts for effects it matches to decisions. The runbook assigns the observer to an operator account separate from the agent session. The approval path requires an explicit operator configuration and is not enabled under Codex. It binds an approval to the command bytes and its session. Its time check accepts the approval from 60 seconds before the recorded answer, to allow for clock skew, through 15 minutes after it. For a write covered by the receipt pilot, the hook obtains a signed ALLOW before recording its own use of the approval and allowing the command. These are observations of the source and runbook, not a live Agent Guard execution measured for this document. The seven DSSE test vectors described in were produced with proofbundle 6.4.0 from PyPI and test keys, not by Agent Guard. For an approval, the inspected pilot writes released_by_owner among its reason codes where those vectors write user_approval. It does not put the approval record's digest into inputSnapshot, may add the digest of configured closing rules there, sets no traceContext or actionOutcome, and leaves evidenceRefs empty. Those vectors therefore do not demonstrate that the preview produces Case 1 receipts conforming to this document. At the inspected commit, the signing service keeps its record of honoured approvals without eviction and refuses a new approval when the record holds 4096. The runbook has an operator rotate a full record, with the service stopped, by copying it into the folder honoured-releases of the records and then removing it. The service treats an approval named in the current record or in any file of that folder as honoured, before its decision and again under its lock before it releases the signature. If that folder or a file in it is a symbolic link, is owned by an account other than root or the service's own, or is writable by another account, or if a file there does not read as a record, the service releases no signature in the configuration in which it honours approvals. The hook keeps its own record of the approvals it has used, keyed by an identity that excludes the answer time, and treats a copy of a used approval as used whatever answer time it carries. When the record holds 1024 uses, the hook removes only uses recorded more than 15 minutes and 60 seconds earlier, after which the copy that was used is no longer within its window, and keeps a digest of each removed identity, which it does not remove; a copy of such an identity is refused. If the record is still full, would exceed 512 KiB, contains a field the hook does not know, or cannot be read or written, the hook does not honour the approval. In both layers the validity window is taken from the answer time of the copy in use, and neither keeps an original validity per identity. For an identity that has not yet been used, a copy with a later answer time therefore opens a later window; item 2 of does not permit that. At the earlier commit ba8466d1a04334a5d83b3eaa12e30a464cc9d686, the signing service did not read archived records and the hook removed its oldest use without checking that entry's age; both were gaps relative to . No conformance of Agent Guard to and no enforcement of single use in a running host is claimed from these source-level observations. The separate Go checker supplied with the vectors and the proofbundle 6.4.0 command line interface agree on acceptance or rejection of all seven vectors. This comparison does not establish complete equivalence of the verifiers, conformance of Agent Guard to Sections 3 and 4, or enforcement of single use in a running host. No later implementation revision is assessed here. This information is given per and does not constitute endorsement.

Relation to Other Work defines one in-toto predicate type, signed in DSSE with canonical bytes, that carries an authorization decision and the observed effect together with a derived agreement between them, and offers it as a data model for AUDIT records. This document keeps decision and outcome in two receipts signed under different keys and maps three cases onto the architecture; the consumption-state input that names concerns the same kind of state as . lets records carry a sequence number, so that a record withheld from a party that holds a later record of the same series can be detected (); the decision receipts of this document carry no such member (). also derives the agreement between decision and effect inside one record (), where this document compares two receipts through decisionRef (). specifies permissions that a principal signs with a passkey and action receipts signed by the agent, linked to earlier receipts and appended to a log by a recorder. It also defines a passkey-signed approval of one action. Such an approval could supply additional evidence for Case 1. Citing it by digest does not replace the approval record or the checks of ; this document defines no mapping from that format to the approval record. In each action receipt carries its place in a chain; every receipt after the first also names the preceding receipt by digest. It is signed with the agent's keys or, for a helper, with the keys in the to member of its delegation (). Here the decision maker signs a decision receipt and the executor or an observer signs an outcome receipt (); a verifier checks that executor.id differs from decisionMaker.id (). does not define a chain of decision receipts. defines a verdict record that states a result on a claim and cites its evidence by digest, in any receipt format. A decision or outcome receipt of this document can be such evidence, and a verdict record can state the result of the procedure of . Following , a verdict record cites a receipt of this document as an evidence item by the SHA-256 over its exact envelope bytes; the content root R of step 5 of is a different digest, over the payload bytes, which a verdict record cites at most by citing those payload bytes as an item of its own. defines a data format for agent conversation records protected by COSE signatures, which names as a candidate for Interaction Records. A signed conversation record can be cited by digest as additional input. Establishing which entry records a human approval and how it corresponds to the action, approver, session and validity of Case 1 requires a mapping not defined here. The approval record and the checks of still apply. SCITT registers Signed Statements with a Transparency Service, which returns Receipts. describes how a decision or outcome receipt can be registered and what a Receipt then shows.

Security Considerations Key binding. A receipt is only as trustworthy as the verifier's choice of keys and its policy for the identities those keys may attest. checks decisionMaker.id; checks the expected executor.id under the outcome-signing key. An observer's signature over an executor identifier is not the executor's own signature. A key held in the recorded Agent's process gives an Auditor that does not trust that Agent little assurance. The inspected Agent Guard design uses separate service accounts as described in . Key compromise. Whoever holds the signing key of a decision maker or of an outcome signer can produce receipts with any decidedAt or performedAt, since these times come from the signer's clock, as the paragraph on clocks below says. A check under does not tell such a receipt from one signed before the key was compromised or replaced. Which keys are accepted for which identity and for which period is set by the verifier's trust policy, not by this document; likewise leaves revocation strategies for compromised keys out of its scope (). A time anchor outside the signer helps, if it was set before the compromise. Where the envelope bytes are the payload of a registered Signed Statement (), a Receipt for it shows that the DSSE signature existed when that Signed Statement was registered, and the Transparency Service records the Registration time (). Where the Signed Statement is made over the content root, the comparison binds the decoded DSSE payload, not the envelope bytes or the DSSE signature, and does not establish that the DSSE signature existed when the content root was registered (). The rules of keep a relying party from honouring one approval more than once; they do not prevent the holder of a compromised decision maker key from signing receipts that cite approvals with new identities. Exact bytes. A verifier that re-serializes a payload before checking it can be led to accept bytes that were never signed, or to compute another content root. Step 4 refuses such payloads, and vector V2-bad tests it. Replay. An ALLOW for one action must not free another, and an outcome that names another decision must not count as the result of this one. parametersDigest binds the action bytes, validity binds audience, nonce and expiry, decisionRef binds the outcome, and requires the relying party to prevent reuse of an approval. V1-bad tests rejection of changed payload bytes under an unchanged signature. V3-bad tests rejection of an outcome bound to a different decision. The seven vectors do not test consumption-state retention or rotation; F13 in tests rotation. Self-assertion. actionOutcome in a decision receipt and an outcome receipt whose effect cannot be resolved are statements of their signers. A digest that is present but cannot be resolved to bytes was chosen by the signer. Suppression. A decision maker can fail to write a receipt for a decision it does not want seen. Independent observers at the boundary, as the architecture requires for Action Records, reduce this risk. Registration with a Transparency Service helps address selective registration when Relying Parties accept a Signed Statement only if they can discover and verify a Receipt for that Signed Statement from a Transparency Service they trust (Sections and of ). This document does not ensure that a receipt is produced for every decision. A SCITT Receipt shows inclusion of the registered Signed Statement, not that every receipt was registered (). Completeness presupposes an expectation of which receipts ought to exist, and this document does not define that expectation. Gaps. For outcome receipts, defines an optional member sequence, with a run identifier and a counter that an executor can opt into (its sections 4 and 7); admits that member. A verifier that holds numbered outcome receipts of a run can report a gap in the numbers it has. Such a gap can reflect withholding or delivery delay; the numbers alone do not establish its cause. Those sequence numbers alone do not show whether receipts above the highest observed number have been withheld, and a run without the member leaves no such trace (compare ). The profile of defines no sequence counter or chain of decision receipts. Records that a Service or Tool emits at the boundary where an action took effect () can expose an effect for which the Auditor has no matching decision receipt. Clocks. decidedAt and performedAt come from the signers' clocks. Ordering against outside events needs a timestamp or a transparency registration. A verified time-stamp token under for a hash of the envelope bytes is, like a registration (), an anchor outside the signer for a verifier that trusts the time-stamping authority. It supports the assertion that those bytes existed no later than genTime plus the applicable accuracy (). If the accuracy field is absent, the accuracy may be available through other means, such as the TSA policy; its absence does not establish zero uncertainty.

Privacy Considerations The example receipts in carry digests of action bytes, approval records and effects rather than those bytes, and the example decision receipts set privacy.rawInputsIncluded to false. The field rules of allow that member to be true and permit raw content in other admitted members, such as a decision receipt's open traceContext object. A successful check under does not establish that raw inputs are absent. A digest of a short or predictable input, such as a command line, can be found by trying candidate inputs; a deployment that must hide such inputs keeps the receipts as private as the inputs, or adds a secret salt to the digested bytes. Identifiers such as principal.id, agent.id and traceContext link a person's actions across services, as describes; pairwise or opaque identifiers reduce that linkage. Registration shows that the registered Signed Statement existed by the time of registration, not when the decision was taken. Where that Statement is made over the content root, it does not establish that the receipt's DSSE signature existed at that time (). Where the envelope bytes are the payload of a registered Signed Statement (), readers of that payload can read the receipt with its identifiers and digests. Registering a Statement over the content root avoids including the receipt's envelope bytes in that Statement, but the Signed Statement still carries its Issuer and Subject Claims and the Transparency Service records the Registration time (Sections and of ). Access to the registered data and any detached payload depends on the Transparency Service and any Adjacent Services; Issuers and Clients assess their privacy and security posture before registration ().

IANA Considerations This document has no IANA actions.

References Normative References Secure Systems Lab in-toto project Informative References proofbundle project proofbundle, tag v6.4.0, docs/predicates/decision-receipt.md proofbundle project proofbundle, tag v6.4.0, docs/predicates/action-outcome.md Python Package Index Action State Group proofbundle project

Test Vectors The seven DSSE vectors described in were generated with proofbundle 6.4.0 from PyPI. All vectors and keys in this appendix are for testing only. Each key seed is SHA-256 over a public ASCII label, so that every byte can be rebuilt; these keys MUST NOT be used for any real receipt. Ed25519 is deterministic, so the signatures below follow from the seeds and the payloads.

Test Keys and Inputs Each key is given by its label, Ed25519 seed (hex), public key (base64) and keyid. The key labelled gate-1 signs the decision receipts; the key labelled observer-1 signs the outcome receipts. For these tests, the trust policy accepts decisionMaker.id gate-1 under the gate-1 key and permits the observer-1 key to attest executor.id forge:agent-42-bot. The key label observer-1 does not assert that the observer is the executing account. Each input is given by a name, its bytes, its size and its SHA-256. "\n" stands for one line feed byte. The bytes of ap, a3 and e3 are the serialization under of the JSON value shown, on one line and without white space. In ap, SHA-256(a1) stands for the JSON string of the 64 lowercase hexadecimal digits of the SHA-256 of a1. pol is the policy named by every policyDigest. B is the payload of vector P1 of , Appendix A.2.1, cited by V3-decision.

Statements The payload bytes of each vector are the serialization under of a Statement {"_type": "https://in-toto.io/Statement/v1", "predicateType": P, "predicate": D, "subject": [{"name": N, "digest": {"sha256": H}}]}, where H is SHA-256 over the serialization of D. For a decision receipt P is the decision receipt type and N is "decision:" followed by decisionId; for an outcome receipt P is the outcome receipt type and N is "outcome:" followed by outcomeId. Each predicate is given as a list of assignments that starts from the predicate named in its first line, {} being the empty object. An assignment sets the member at the path to the JSON value shown. A path is a sequence of member names joined by dots, where a decimal index i in square brackets after a name selects element i of an array; missing objects on the path are created, and an assignment to element i of an array with i elements appends it. Members not named keep their value. SHA-256(x) stands for the JSON string of the 64 lowercase hexadecimal digits of the SHA-256 of input x, and R(V) for that of the payload bytes of vector V. V1-bad has the payload bytes of V1-good with every occurrence of the hexadecimal SHA-256 of a1 replaced by that of a1x, and keeps the signature of V1-good. V2-bad has as payload bytes the output of Python's json.dumps(s, sort_keys=True) for the Statement s of V2-good, with a space after each comma and colon, and is validly signed over them by gate-1.

Results Every envelope is {"payload": base64 of the payload bytes, "payloadType": "application/vnd.in-toto+json", "signatures": [{"keyid": keyid of the signer, "sig": signature}]}. Each block below gives the vector, the evaluation time T, the expected result with the exit code of the proofbundle 6.4.0 command line interface, the payload size and signer, the SHA-256 of the payload bytes (the content root where the payload is canonical) and the signature in base64 on two lines. The expected audience is observer-1 and the expected nonce is the decisionId. decision verify ran with --strict, --aud, --nonce and --verification-time T; outcome verify with --strict, --expected-decision-ref R(V3-decision) and --decision-maker-id gate-1. The payload bytes of V1-good, V2-good, V3-decision, V3-good and V3-bad and the inputs ap, a3, e3 and B are each equal to three serializations of their parsed value: Python's json.dumps with sort_keys=True, separators=(",", ":") and either setting of ensure_ascii; the rfc8785 package 0.1.4 for Python; and the independent JavaScript implementation . The values contain no floating-point numbers and no characters outside ASCII, which keeps these serializations equal. The payload of V2-bad differs from all of them, as intended. Each result is that of one procedure. V1-good is judged by with Case 1 of , using a1 and ap; V1-bad fails at step 3 of , before any check of Case 1. V2-good is judged by with Case 2, using a2; V2-bad fails at step 4 of . V3-good is judged as Case 3, by for V3-decision and for V3-good, with e3 as effect bytes and forge:agent-42-bot as expected executor.id; V3-bad fails at step 4 of . V3-decision is judged by the same Case 3 procedure as V3-good and passes. The exit code of proofbundle decision verify for V3-decision reflects alone.

Signed Statements for Registration This appendix gives one Signed Statement for each way of registration in , both for V2-good. Statement A carries the envelope bytes as its payload. Statement B is made over the content root and uses, as one example of a profile, the COSE Hash Envelope of with a detached payload; other profiles are possible. These Signed Statements were built from the specifications cited here, not with proofbundle. The SCITT Receipts for A and B at the end of this appendix were generated for illustration with the library scitt-cose 0.5.0 , and no Transparency Service issued them. The envelope bytes are the serialization under of the V2-good envelope of , 2590 bytes with SHA-256 0e60fbbf36ddc6691cdf0fb2b1faea70d23d02d0da7653f449ec60f2f820e71e. The test key issuer-1 of the Issuer is built like the keys of and given by its label, Ed25519 seed (hex) and public key (base64). Its kid is the COSE Key Thumbprint of with SHA-256 over the required parameters kty 1 (OKP), crv 6 (Ed25519) and x. Both Signed Statements are COSE_Sign1 messages of with tag 18, an empty unprotected header and an EdDSA (-8) signature of by issuer-1 over the Sig_structure of . Their CBOR uses the core deterministic encoding of . The protected headers carry the CWT Claims (label 15) of with iss "https://issuer-1.example" and sub "decision:dec-0002", the subject name of V2-good. They are shown below in diagnostic notation, with kid standing for the value above. In B, label 258 (payload_hash_alg) is -16 (SHA-256) and label 259 (payload_preimage_content_type) is the payloadType of the envelope, whose decoded payload is the preimage. B carries no content type (label 3), as requires for a Hash Envelope. A is encoded as the bytes given below, followed by the envelope bytes, the two bytes 0x58 0x40 and the signature. B has a detached payload, the content root R(V2-good) of , and is given in full. A verifier that holds the issuer-1 key decodes each Signed Statement, checks that alg is EdDSA, that kid is the thumbprint of that key and that iss is as expected, and verifies the signature, for B over the detached payload. Both pass. Two counterexamples fail at the signature. In the first, the byte at offset 12 of the envelope bytes in A, the first character "e" of the base64 payload, is replaced by "f". In the second, B is checked with a detached payload whose first byte is 0xec instead of 0xed. The binding of then holds for V2-good. The payload of A equals its envelope bytes, and the payload of B equals its content root and differs from R(V2-bad). On those envelope bytes, proofbundle 6.4.0 decision verify with the arguments of exits 0. For these Receipts, a local registration in the manner of first verified the Issuer signature of each Signed Statement, for B over the detached payload, and checked that its protected header carries kid and CWT Claims with iss and sub (). It accepted A and then B as the two entries of a Merkle Tree of , each entry being the bytes of the Signed Statement. Neither nor defines what a Transparency Service takes as an entry; the bytes of the Signed Statement are the choice of this example, and other services enter, for example, a hash of them. It rejected A with the changed byte, B with the changed detached payload, and a variant of A without sub. The Receipts are COSE_Sign1 messages of with vds 1 (RFC9162_SHA256), a detached payload, the root of that tree, and an EdDSA signature by the test key receipt-issuer-1, built like the keys of . Their CWT Claims carry the iss given below and the sub of the Signed Statement, and their kid is the COSE Key Thumbprint of the receipt-issuer-1 key. Both Signed Statements have the same sub and both Receipts sign the same root, so the two Receipts share their protected header and signature and differ only in their inclusion proofs. Their protected header keeps the label order in which scitt-cose writes it (395, 15, 4, 1), not the deterministic order of ; the signature covers the bytes as given. A verifier computes the leaf hash, SHA-256 over the byte 0x00 followed by the entry (), applies the inclusion path of the Receipt to obtain the root (), and verifies the signature over that root with the receipt-issuer-1 key (). Both Receipts pass. Four counterexamples fail at the signature, namely A with the Receipt for B, B with the Receipt for A, the Receipt for A with one byte of its inclusion path changed, and the Receipt for A checked with the issuer-1 key instead of the receipt-issuer-1 key.

Failure Vectors Each vector below defines a failing test case based on a passing vector of and names its expected first failing check for the stated inputs and procedure. For F10 and F13, receipt verification passes and the relying party refuses the approval under ; the vector names the item of on which the refusal rests. The payloads are derived as in , where a line "remove P" removes the member at path P, and signed with the test keys of . F11 and F12 change a member of the Statement outside predicate, as stated below. F4, F5 and F13 reuse the envelope of V1-good or V2-good and differ from it only in an input of the verifier. F15 is the receipt of vector P1 of , a Signed Evaluation Receipt whose signature verifies under the issuer test key of ; forbids a verifier to treat it as permission. F15 tests the first half of that rule; the second half, not to treat the presence of a Signed Evaluation Receipt in evidenceRefs as permission, is a rule for the relying party that has no check step and no vector of its own. The other vectors were generated from the definitions in this document, not with proofbundle. The approval record ap2 is ap with a later validUntil, and c1 is the consumption state of a relying party that has honoured ap, as an array of approval identities. c2 is the consumption state of a relying party that has rotated its record, as an object whose members are its generations, each an array of approval identities; its current generation is empty and its rotated generation holds the identity of ap. All three are the serialization of the JSON value shown. The decision vectors are checked like their base vectors in , by with Case 1 of using a1 and ap, or with Case 2 using a2, with expected audience observer-1 and the decisionId as expected nonce. F5 is checked with a1 instead of a2. F10 is checked with ap2, and then by a relying party under that holds c1. F11, F12 and F15 are checked like V2-good, and F13 and F14 like V1-good; F13 is then checked by a relying party under that holds c2. F6 to F8 are checked by against V3-decision at T 2026-10-15T09:11:00Z, with e3 as effect bytes and forge:agent-42-bot as expected executor.id. F7 has status refused and no effectDigest; because e3 is supplied as effect bytes, F7 fails at the second sentence of step 6 of , which applies whatever the status. F11 and F12 have the predicate and the subject of V2-good. In F11 the Statement member _type is "https://in-toto.io/Statement/v0.1"; in F12 the member predicateType is "https://b7n0de.com/proofbundle/predicates/decision-receipt/v0.2". Each block gives the vector, the evaluation time T, the step at which it fails, the exit code of the proofbundle 6.4.0 command line interface for the command of , and, for a new payload, its size and signer, the SHA-256 of the payload bytes and the signature in base64 on two lines. The block of F15 gives the size and SHA-256 of the receipt of P1 of instead. Failure vectors and proofbundle 6.4.0

Vector	Fails at	Exit	proofbundle 6.4.0
F1	step 7 of 3.2	2	rejects
F2	step 7 of 3.2	2	rejects
F3	step 8 of 3.2	0	accepts
F4	step 9 of 3.2	2	rejects
F5	step 10 of 3.2	0	accepts
F6	step 5 of 3.4	0	accepts
F7	step 6 of 3.4	0	accepts
F8	step 7 of 3.4	0	accepts
F9	Case 1 of 3.3	0	accepts
F10	Section 4, item 2	0	accepts
F11	step 6 of 3.2	2	rejects
F12	step 6 of 3.2	2	rejects
F13	Section 4, item 4	0	accepts
F14	Case 1 of 3.3	0	accepts
F15	step 1 of 3.2	1	rejects

The proofbundle 6.4.0 commands used here receive no action bytes, effect bytes, expected executor.id or consumption state, and no expected decisionMaker.id. They reject F1, F2, F4, F11, F12 and F15 and return exit code 0 for the other nine command-line inputs. The procedures specified here reject F3, F5, F6, F7, F8, F9 and F14. F10 and F13 instead pass receipt verification and are refused by the relying party under . F10 is refused with c1 under item 2, because ap2 is a copy of ap with other metadata and so the same approval. F13 is refused with c2 under item 4, because ap is recorded as consumed only in the rotated generation. Their acceptance by these commands does not test consumption-state enforcement. F9 shows why checking only the decision's expiry is insufficient. At the stated T of 09:16 the decision passes step 9 of , while the approval expired at 09:15. Its validity.expiresAt exceeds the validUntil of ap, so the Case 1 time-bound condition of is violated independently of T.

Changes This section is to be removed before publication.

Changes from -04 Step 1 of cites for the JSON text of the envelope and rejects envelope bytes that begin with a byte order mark. Step 6 of requires exactly one subject entry and no other entries, and step 2 of states the same rule for outcome receipts. Step 6 of states that the check of supplied effect bytes applies whatever the status, and says that F7 fails at its second sentence. Item 6 of names the clock skew of the relying party. names, for F10 and F13, the item of on which the relying party refuses, and adds the consumption state c2 and the failure vectors F11 to F15, for a wrong _type, a wrong predicateType, an approval recorded as consumed only in a rotated generation, reasonCodes without user_approval in Case 1, and a Signed Evaluation Receipt presented as a decision receipt (). distinguishes the existence of the registered Signed Statement from the time of the decision and states that registration over the content root does not establish that the receipt's DSSE signature existed at registration time. names Case 3 as the procedure for V3-decision. states that F15 tests the first half of the rule of and that its second half has no check step and no vector of its own. points to F13 for rotation. The reference cites revision -02. states that a verdict record of cites a receipt of this document by the SHA-256 over its envelope bytes, and that the content root is a different digest. The reference cites revision -02.

Changes from -03 New gives one example Signed Statement for each way of registration in , signed with a new test key, and a SCITT Receipt for each, generated with a library for illustration, and points to it. The informative references add RFC 8949, RFC 9052, RFC 9053, RFC 9162, RFC 9597, RFC 9679, RFC 9942, RFC 9995 and scitt-cose. step 7 and step 3 list by full path the members that are digests and timestamps, and step 7 gives the form of evidenceRefs[].typedDigest. names the procedure that decides each vector. states that the entry of the tree is the choice of the example. New gives failure vectors for steps 7 to 10 of , Case 1 of , steps 5 to 7 of and . New gives the field rules of both predicates as tables, step 7 of and step 3 of refer to it, and and are informative references. The field rules distinguish JSON booleans from string literals. Step 1 of rejects duplicate member names in DSSE envelopes. identifies the first failing check for each stated test procedure, distinguishes the relying-party check for F10, and explains that F9 violates the Case 1 time-bound condition independently of T. and distinguish the provenance of the seven DSSE vectors from that of the new examples. clarifies that the field rules do not establish the absence of raw inputs. Case 1 of allows inputSnapshot entries other than the approval record, and states which digests a pass checks against bytes.

Changes from -02 adds, for and , what this document does differently. The paragraph on clocks in adds that a time-stamp token under over the envelope bytes is an anchor outside the signer. New lists places where the mapping needed a reading of , as observations and questions. adds a paragraph on finding missing outcome receipts through the sequence member of , and on boundary records for decisions.

Changes from -01 to -02 The submissionType attribute is removed from the rfc element. The Abstract states that the document describes, informatively, how a receipt can be registered with a Transparency Service under RFC 9943 and what a SCITT Receipt then shows and does not show. states to whom the key words apply. adds a paragraph on what a receipt still shows when a signing key of a decision maker or outcome signer is compromised or replaced. describes what each way of registration in reveals and distinguishes access to the registered Signed Statement from access to a detached payload.

Changes from -00 to -01 Added , an informative description of how a decision or outcome receipt can be registered with a Transparency Service under , what a SCITT Receipt then shows and what it does not. , the end of , and the paragraph on suppression in refer to . adds that completeness presupposes an expectation of which receipts ought to exist, which this document does not define. The introduction states that the mapping follows revision -01 of . Sections 3.1 to 3.5, 4 and 5 and the test vectors of are unchanged.

Acknowledgments The author used AI tools to help draft this document and to generate and cross-check its examples. The author reviewed the entire text and is responsible for it. Citing adjacent work in the References does not imply that its authors endorse this document.