Skip to content

spec: add an assurance-neutral references block (#197) #198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
imran-siddique merged 1 commit into from
Aug 22, 2026
+32 −0
Merged

spec: add an assurance-neutral references block (#197) #198

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions spec/trace-v0.2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,6 +124,7 @@ The Trust Record is the unit of evidence. All fields are required unless marked
| `data_class` | Classification of inputs and outputs | Classification label bound to per-call execution |
| `tool_transcript` | MCP / A2A tool calls invoked, parameters classified, responses filtered | MCP / A2A protocol transcripts bound to TEE measurement |
| `origin` | OPTIONAL. Where the evidence came from, when that is not this runtime. See §3.1.1. | — |
| `references` | OPTIONAL. Facts outside this record that it points at. Assurance-neutral: see §3.1.2. <!-- CHANGED: #197 - new optional assurance-neutral reference block --> | — |
| `build_provenance` | How the running code and model were built | SLSA Provenance v1.0 |
| `appraisal` | Verifier's appraisal of evidence | EAR (EAT Attestation Results) |
| `transparency` | Inclusion proof on append-only log | SCITT Receipt URI |
Expand Down Expand Up @@ -159,6 +160,37 @@ A Trust Record normally describes an execution and is produced by the runtime th

**This block does not launder assurance in either direction.** It cannot raise a record: nothing about naming your producer makes unattested evidence attested. It cannot lower one either: a record with a hardware platform and a verified quote is what it is, whether or not it says `origin: self`.

#### 3.1.2 `references`: facts this record points at

<!-- CHANGED: #197 - new subsection -->

`origin` records where evidence *came from* and can lower assurance. `references` records what a record *points at* and cannot. Those are different questions and the spec previously had only the first, so any record that needed to reference something external had to use `origin` and take `runtime.platform: "software-only"` with it.

A `references` entry is a pointer, not evidence. What the signature attests is that this record points there, not the truth of what it points at. The pointer is produced inside the boundary that produced the record; the target is not.

| Field | Required | Meaning |
|---|---|---|
| `rel` | yes | Relationship type. Registered set, see below. |
| `id` | yes | Identifier of the referenced fact within the resolver's system. |
| `resolver` | yes | Identifier of the party obliged to resolve `id`. |
| `retention` | no | Period for which `resolver` undertakes to keep `id` resolvable, as an ISO 8601 duration. |
| `digest` | no | Digest of the referenced object, when the producer holds it at issue time. |

Registered `rel` values:

- **`authorized-intent`**. An authorization decided before execution, held in another system.
- **`approval-outcome`**. An attributable human approval attached to a step-up or defer decision.
- **`behavior-trace`**. A behavioural record of what the agent did, of which this record is the environment evidence.

1. `references` MUST NOT affect `runtime.platform`. A record carrying `references` and no `origin` block is `self` and carries whatever platform value it actually earned.
2. The record signature MUST cover `references`, under the canonicalisation in §3.2.2.
3. A verifier MUST NOT reject a record because an entry in `references` cannot be resolved, and MUST NOT treat a resolved reference as attested evidence.
4. A producer that cannot name a `resolver` MUST omit the entry rather than emit one with an empty or self-asserted resolver.

Rule 3 is what makes the block safe to add. A reference that could invalidate a record would hand whoever controls the target a way to invalidate evidence they do not hold, and a reference that counted as evidence would be the assurance laundering §3.1.1 exists to prevent.

**Unsettled, and deliberately named rather than hidden.** `retention` states an undertaking and nothing in this specification enforces it. A reference is worth only the ability to resolve it later, and transparency-log practice shows that gap is real rather than theoretical: a record can remain valid and become unreachable when the index that addressed it is removed. §7 open question 3 covers the same ground for `transparency` and the two should be resolved together.

### 3.2 Wire format

**Envelope:** EAT (RFC 9711) — JWT (JSON, human-readable contexts) or CWT/CBOR-COSE (constrained and high-throughput contexts).
Expand Down