open-standards/wai/extensions/provenance.md
Transaction Science cd6dcf41bb SPEC §7 Signatures: the one Ed25519 rule, cited by the receipt extensions
Every Ed25519 signature WAI defines is verified strictly, in order: a canonical
key, a key not of small order, S < L, R not of small order, and the cofactorless
equation with R compared byte for byte. OER/2's chain signature keeps the rule
oer-receipts §5 settles. jwp-receipts §3.1 step 3, http-delivery's playlist
receipt and packaging's receipt cite it instead of restating it; the worlds,
avatars, feeds, spatial-audio, haptics, volumetric, score, film, provenance,
ternary and quantum receipt texts cite it where they name their signature.
CHANGELOG records the sweep.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-07 14:39:04 -04:00

102 lines
5 KiB
Markdown

# WAI Extension: Asset Provenance
> Status: Draft. Lever 4 — content-addressing + receipts + measured
> energy for content that cannot be reduced to instructions. WAI does not
> reconstruct the asset; it carries the opaque bytes and a signed,
> energy-accounted lineage. Conformance is **content-hash-equivalence**
> (recompute, compare) + signature validity. Reference impl: the
> `provenance` feature of `wai-rs`; tooling: `wai_prov`; live sink:
> wai.transaction.science/provenance.
Keywords **MUST**, **MUST NOT**, **SHOULD**, **MAY** are RFC 2119/8174.
## 1. Scope and model
A `wai.asset.provenance` object is **not a content capability** — it is a
JWP receipt profile *about* a carried asset, the way `jwp-receipts` is.
The asset itself declares an ordinary capability (`wai.image.jpeg`,
`wai.audio.flac`, …) and WAI carries it unchanged; the provenance receipt
adds three things the carried bytes do not have on their own:
1. **Tamper-evidence** — the asset is content-addressed
([`asset_content_hash`], BLAKE3 over the complete WAI envelope); a
verifier recomputes it and compares.
2. **Lineage** — an ordered chain of processing **steps**, each binding
its input and output content hashes, signed as one group.
3. **Energy accounting** — each step carries its measured/declared
microjoules; the receipt totals them.
This is the "verifies whatever it carries" half of the thesis, for the
content the reconstruct half cannot touch. WAI never decodes the asset —
a sink hands the bytes to whatever native element renders that media.
In scope: the step model, the `AssetReceipt` group, the verification
obligations. Out of scope: a transport; a capture device; the asset's own
codec (it is opaque here).
## 2. The step
A `ProvStep` is one transformation in the asset's lineage:
| field | meaning |
|---|---|
| `op` | operation, e.g. `"origin.synthesize"`, `"encode.jpeg"`, `"derive.thumbnail"` |
| `input_hash` | content hash of the input (all-zero for an originating step) |
| `output_hash` | content hash of the output |
| `work` | exact deterministic work (pixels, samples) |
| `joules_micro` | measured/carried microjoules; `0` is the unmetered marker, never 0 J ([energy-measurement](energy-measurement.md) §2) |
Step content hash:
`BLAKE3("wai:prov-step\x01" || op_len | op | input | output | work | joules)`.
## 3. The receipt (`AssetReceipt`)
A JWP group: the asset's content hash is the identity, the per-step
hashes are the Merkle leaves (JWP's exact `moq-jwp:merkle-{leaf,node}`
domains), and one Ed25519 signature covers a profile payload carrying the
asset hash, the declared `media` + `capability`, the Merkle root, the
step chain, and the total joules. It chains across edits via
`parent_receipt_hash`, like the worlds / audio / haptic / splat receipts.
## 4. Conformance
> A conforming verifier MUST: (a) recompute the asset's content hash and
> require it equal the receipt's `asset_hash`; (b) require the step chain
> be linked — each step's `input_hash` equals the previous step's
> `output_hash`, and the final `output_hash` equals `asset_hash`; (c)
> recompute the Merkle root from the step hashes; (d) verify the Ed25519
> signature as SPEC §7 *Signatures* requires. A failure at any point is a failure — the asset is reported
> unverified, never "probably fine".
There is no tolerance parameter: the content hash matches or it does not.
## 5. Energy is measured, never invented
`joules_micro` per step is **carried** from a meter, exactly as the other
receipts carry it: `wai_prov` measures the real CPU energy of each encode
(IOReport via macmon, no sudo) and signs the figure. An unmetered step
carries the unmetered marker `0`, which a reader presents as unmetered and never
totals as zero joules. The receipt never derives energy it did not measure.
Each step's figure carries its acquisition class as an optional label
([energy-measurement](energy-measurement.md) §2.8), because the steps of one
lineage can be metered by different parties in different ways. A labelled step
binds its class into its leaf hash; a step with no label keeps its legacy leaf
and its figure is unlabelled. `wai_prov` labels each encode it measures
`OnChipCounter`, with its declared uncertainty, and records an encode whose
measurement fails the §4 ratio or the power reader's liveness (§3.1) as
unmetered, and writes a measurement report for each step it measured
(energy-measurement §6). `total_joules_micro` carries no class of its own, and a
total over steps that include an unmetered one covers only the measured steps
(`Partial`).
## Appendix
The reconstruct classes prove WAI can ship a world, a sound, a body, a
volume as instructions and have every sink rebuild them identically.
Provenance proves the complement: for the photograph that is just a
photograph, WAI still adds something a bare file cannot — a tamper-evident
identity, a signed lineage, and an honest energy ledger — without ever
pretending to understand the pixels. Carries whatever it can reconstruct;
verifies whatever it carries.
[`asset_content_hash`]: ../wai-rs/src/world/mod.rs