Decision Provenance for SCITT: binding software releases and agent actions to the decisions behind them

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 29 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The SCITT use cases [I-D.ietf-scitt-software-use-cases] and the formats a software supply chain already carries, build provenance [SLSA], attestations [IN-TOTO] and bills of materials [SPDX], answer the question "what is this artifact, and how was it built". Registered as Signed Statements in a Transparency Service [RFC9943], with Receipts [RFC9942], they become evidence anyone can check later. None of them answers "who decided to ship it, on what, and under which authority": the release decision is a ticket, a chat message or a button, and the record of it, where one exists, is neither signed by the decider nor bound to the artifact that shipped.¶

The statement profiles written for AI agent actions have the same gap, and are careful to say so. A capsule records an action's disposition [I-D.mih-scitt-agent-action-capsule]; an AgentInteractionRecord its inputs and outcomes [I-D.emirdag-scitt-ai-agent-execution]; a receipt its risk class and verdict [I-D.noa-scitt-ai-agent-receipt]. Each says that its human-approval field is the producer's claim: an enumeration value or an opaque label, not an authenticated act, and that the reasoning behind the action stays private or reduced to a hash.¶

The Decision Provenance Standard [DPS-CORE] records the decision: what was decided, under which charter, which options were considered and with what rationale, and the affirmative human act that closed the record. Its action binding extension [DPS-ACTION-BINDING], a proposal in the Standard's repository, records the stages from a proposed action specification to its execution: what the attachment states the reviewer was shown, what was approved, signed where a signature is carried, what was requested, re-checked and executed, bound to one another by equal digests. Its anchoring extension [DPS-ANCHORING], also a proposal, gives those records evidence that their bytes existed by a given point, and witness checkpoints, including, since its SCITT source, a witness-signed checkpoint registered in a Transparency Service with its Receipt. A deploy pipeline and an AI agent are two executors of decisions; the Standard does not distinguish them.¶

This document does three things. It declares two artifact types so that a build attestation, a release statement or an agent action record may cite, by typed digest reference [I-D.mih-sokolov-scitt-payload-binding], the decision record and the action-binding attachment it executes. It describes how a verifier holding both checks the approval and the binding offline. And it describes the registration of the anchoring extension's checkpoints in a Transparency Service, by reference to the anchoring extension at a fixed commit. Two worked examples: a software release decision, and an agent action capsule citing a decision. Nothing in the architecture [RFC9943], in Signed Statements or in Receipts changes: the decision layer is cited by digest from a statement a service already registers, and its checkpoints are registered as any statement is.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Decision record, action-binding attachment, stage, checkpoint, witness, trust policy and verification report are used as the Standard and its extensions define them. Signed Statement, Transparency Service and Receipt are used as [RFC9943] and [RFC9942] define them. Build attestation, provenance predicate and bill of materials are used as [IN-TOTO], [SLSA] and [SPDX] define them.¶

3. What the decision layer adds

A verifier holding an action record (a release statement, a build attestation, a capsule) and the decision record and attachment it cites can establish, offline:¶

• where the approver's signature is carried, that the approver signed the outcome stage with a key the verifier's own trust policy maps to a named person, in the role person of that policy; the authority reference that points into the deployer's charter stays the issuer's statement unless the verifier checks it against an independent source, such as the permission system;¶

• that the specification the attachment says was shown to the approver, the one approved, the one that was requested, re-checked and executed, are one and the same, by equal digests, or exactly where they differ; for a release, that specification names the artifact digest, the bill of materials digest, the migrations and the rollback;¶

• the options considered and the rationale as the record states them, with the time the rationale was recorded relative to the decision;¶

• and, through the anchoring extension, evidence about when those bytes existed, each source with what it does and does not show: an RFC 3161 token [RFC3161] gives a time from an authority the verifier trusts; a SCITT Receipt states no time, only that the service registered the statement into its log; an OpenTimestamps proof shows only that the bytes existed before a block was mined.¶

It cannot establish that the decision was right, that the action was, or what the reviewer actually saw or read: the check shows what the attachment says was shown; the verification reports of the extensions say so in every result, and this document inherits those limits.¶

4. Where it attaches in the software supply chain

Nothing here replaces a build attestation, a provenance predicate or a bill of materials; they say what was built, and they say it well. The decision layer sits beside them and is linked to them in both directions by digests:¶

• The action specification the approver sees, carried in full in the attachment, names the artifact by its digest, the bill of materials by its digest, and the build by its identifier. A verifier that holds the SLSA provenance or the SBOM recomputes those digests and reads whether the release that was approved is the artifact that was built.¶

• A release statement registered in a Transparency Service, or the build attestation itself where its format allows additional references, cites the decision record and the attachment by the typed digest references of Section 5. The Receipt over that statement then covers the references, that is the two digests, beside the artifact's; the decision documents themselves travel beside the statement or are obtained from the issuer.¶

• A Transparency Service that registers the anchoring extension's witness checkpoints (Section 7) gives each checkpoint over one issuer's chain of release decisions a Receipt from the same service the artifacts use. A Receipt shows the statement's inclusion; the anchoring extension does not yet check that the log only grew, so this is not evidence of an append-only history of decisions.¶

The stages an action-binding attachment records map onto a release pipeline without change: the proposal is the release candidate as the assistant or the pipeline drafted it; the review is the release manager's reading of it; the outcome is the approval under the release charter, signed by the release manager where a signature is carried; the request is the deploy job; the re-check is the permission or policy gate just before deployment; the attempt and the result are the deployment and what the target reported. A change of the artifact digest between the approval and the attempt fails the binding, by construction.¶

5. Artifact types for typed digest references

The Canonical Payload Binding [I-D.mih-sokolov-scitt-payload-binding] defines a typed digest reference, {type, purpose, digest_alg, digest}, and leaves artifact types to the consuming profile; the Agent Action Capsule profile [I-D.mih-scitt-agent-action-capsule] (section 9.1) asks that a declared type name carry a URI or reverse-DNS prefix. This document uses two, both declared in the Standard's repository under its own namespace, org.decisionprovenancestandard [DPS-NAMES]. The repository declares each name, what it identifies and which digest it uses; this document does not restate the digest rules and only says how the references are carried. A name never changes meaning; a different digest rule would get a new name.¶

6. Verification

A verifier that holds the citing record, the decision record, the attachment and its own trust policy:¶

1. resolves each typed digest reference as CPB describes, and stops at Failed for a digest that does not match;¶

2. runs the action binding reference check on the attachment with the record, which reports the stages' consistency, the issuer signature where there is one, the time, and the pairing of the report with its documents;¶

3. runs the signatures check on the approver's signature over the outcome stage, where one is carried beside;¶

4. where it holds the artifact, the build attestation or the bill of materials, recomputes the digests the approved specification names and reports each agreement on its own;¶

5. reads the result dimension by dimension; it MUST NOT merge them into one pass or fail, and it MUST NOT report more than those checks find.¶

The reference checks, their cases and their vectors are in the repository under extensions/*/tests; this document does not restate them.¶

7. Checkpoints in a Transparency Service

A witness's checkpoint over a chain of decision records is a signed statement whose payload is the checkpoint's signed bytes under the anchoring extension's shared rule, with its Receipt, as the anchoring extension defines under "A transparency service as a checkpoint source" at commit 5b0534d. This document adds no rule; it names what a Transparency Service operator and a verifier need:¶

• the statement's protected header [RFC9052]: alg -19, kid the witness key's reference, CWT claims [RFC9597] iss the key's holder and sub the chain;¶

• the leaf: the statement's bytes as registered; a Transparent Statement is carried with its receipts taken out;¶

• what a Receipt shows: that the service signed the statement into its log at a tree size; not the log's consistency, which the extension reports as not checked in this version; and the extension reads no registration time from it;¶

• the registration policy is the operator's [RFC9943]. A verifier never relies on it: it accepts only statements from the witness keys and chains its own trust policy lists for that service. A service may mirror that list in its policy.¶

8. Worked examples

9. Open questions

This revision is a base for discussion. The questions its author would like the working group's reading on:¶

• Whether a decision record should itself be registered as a Signed Statement, with the decision identifier as its subject, rather than only cited by digest from the statements that execute it. The anchoring extension registers checkpoints over chains of records, not the records; registering a record would be a new rule, made in the repository.¶

• Whether the two artifact type names of Section 5 belong in a registry, if the Canonical Payload Binding establishes one, and under which policy; today the Standard's repository declares them under its own namespace.¶

• Which media type or CoAP Content-Format, if any, a checkpoint payload should carry when registered, and whether the vendor tree is the right place (Section 11).¶

• Whether a Transparency Service should recognise witness checkpoints in its registration policy by their witness keys, as a verifier does in its trust policy, or treat them as any statement from any issuer.¶

10. Security Considerations

Where the approver's signature is carried, the decision layer authenticates the approver's act and binds it to the executed specification; an authority reference stays the issuer's statement unless checked against an independent source; it does not establish the truth of the decision's inputs, nor that the artifact a specification names is safe: that stays with the build attestations and the reviews they record. A relying party that needs a signed approval requires one in its own configuration and does not accept an unsigned attachment: anyone holding a signed attachment can remove its signature and present it as unsigned, and only a seal beside it shows that. Keys and sources of trust come from the verifier's own trust policy, never from the artifacts. A Receipt states no time; an OpenTimestamps proof shows only that bytes existed before a block was mined; only an RFC 3161 token from an authority the verifier trusts gives a time bound. The anchoring extension's security considerations apply.¶

11. IANA Considerations

This document registers no media type in this revision. A later revision may register, in the vendor tree, a media type for the checkpoint payload, with the Steward of the Decision Provenance Standard as change controller; the content type stays optional in the anchoring extension.¶

12. References

Acknowledgments

Yohay Etsion, Founding Steward of the Decision Provenance Standard, for discussion. The authors of the capsule, payload binding, AI agent execution and action receipt drafts, whose care in stating what their records do not prove made the junction clear.¶

Appendix: the worked examples

The files are kept with this document's source (https://github.com/laurent-star/dps-scitt-decision-layer, examples/release-decision/ and demo/); the digests below let a reader check them.¶

• Decision record DR-2026-0412 (record schema of the reference files 5.2.0, state closed): "Ship claims-intake 2.3.1 to production on 2026-10-23", three options considered, the first chosen; affirmed by the release manager on 2026-10-23T14:20:00Z. seal_hash: 34ba302a668e9200017a1083a92e88773dab1ca620faeaac8cd8bb7747596ba5.¶

• Action-binding attachment (0.3.0, unsigned in this example): seven stages, proposal by the release assistant, review and approval by the release manager under the release charter, without signature in this example, request, re-check, attempt, observed result; one specification, digest 19ade2a46319ac6622333cd6731ac400ed11daa7d6955b5daa5864da91c2b711, carried in full, naming build 2.3.1+git.5d1c9f0, the artifact digest, the SBOM digest, migration 0042 and the rollback. Attachment digest: 5086c7674db770c6d01592ba697722a2fb468c16d1d5ab9226a7b5217c4bc1a8.¶

• The action binding reference check on the attachment with the record: specification digests, record statements, action binding, stage order, authorisation re-check, observed results and rationale provenance verified; execution state attempted, result succeeded; issuer signature and time not checked, as the attachment is unsigned.¶

• A capsule (format 4, action_type decide, disposition accept by a human, effect confirmed) citing both by typed digest references in references[] with citation_purpose ran_under and acted_on: capsule_id 8ffac39fe42e5d1b9dcbff838ec5c3aad749a3e8a32e3157791297f5f325b6e7; the capsule library (0.12.0) parses it strictly and its Class 1 verification passes with two informational findings (an effect type and a domain outside the seeded values); a verifier of the Standard resolves both references to the documents it holds.¶

The two references as the capsule carries them, wrapped as [RFC8792] describes:¶

NOTE: '\' line wrapping per RFC 8792

[
 {
  "type": "org.decisionprovenancestandard.decision_record",
  "digest_alg": "SHA-256",
  "digest": "34ba302a668e9200017a1083a92e88773dab1ca620faeaac8cd8\
bb7747596ba5",
  "citation_purpose": "ran_under"
 },
 {
  "type": "org.decisionprovenancestandard.action_binding_attachment",
  "digest_alg": "SHA-256",
  "digest": "5086c7674db770c6d01592ba697722a2fb468c16d1d5ab9226a7\
b5217c4bc1a8",
  "citation_purpose": "acted_on"
 }
]

Author's Address