diff --git a/wai/extensions/transparency.md b/wai/extensions/transparency.md new file mode 100644 index 000000000..baf5810d4 --- /dev/null +++ b/wai/extensions/transparency.md @@ -0,0 +1,111 @@ +# WAI Extension: Transparency Emission + +> Status: Draft. Adds an **external encoding** for WAI receipts so a party with +> no WAI tooling can check them, and a registration profile so a receipt's +> existence is independently witnessed. Strictly **additive**: the JWP receipt +> chain is unchanged, and nothing here replaces it. +> Keywords **MUST**, **MUST NOT**, **SHOULD**, **MAY** are RFC 2119/8174. + +## 1. What is actually missing + +Not verifiability. An Ed25519 signature over a group Merkle root is checkable by +anyone holding the publisher key, and [`jwp-receipts`](jwp-receipts.md) §3 +specifies exactly how. Three properties are missing, and none of them is a +signature property: + +- **Non-equivocation.** Nothing prevents a publisher showing one receipt chain to + one party and a different chain to another. Both verify. +- **Independent timestamping.** A receipt says when the publisher says it was + made. +- **Detectability of suppression.** A receipt that was never shown to anyone + leaves no trace of its absence. + +These are log properties, not envelope properties, and they are why this +extension exists. + +## 2. The move, and its shape + +The family already owns both halves: a transparency log with consistency proofs +exists, and JCR-1 (deterministic CBOR + COSE_Sign1, RFC 9052) is already the +canonical receipt envelope across sibling standards. What nothing in the family +has is a **standardised external encoding** that an outside auditor's +off-the-shelf tooling can verify with no bespoke verifier. + +So the sequence is: bring WAI's receipts onto JCR-1 as its siblings already are, +then emit in the standardised encodings on top. + +- A WAI receipt **SHOULD** be expressible as a JCR-1 envelope. This is alignment + with the family, not a new format. +- An implementation **MAY** additionally emit an RFC 9942 (COSE Receipts) + encoding of a group receipt, and **MAY** use the RFC 9995 COSE Hash Envelope + form where the payload is carried by hash rather than by value. +- These emissions are **additional encodings of the same facts**. An implementation + **MUST NOT** let the JWP chain and an emitted encoding disagree, and where they + do, the JWP chain is authoritative and the emission is in error. + +## 3. What is registered, and what is not + +SCITT registers per-artifact Signed Statements over an HTTP API. WAI emits +per-object receipts at media-group cadence. These cadences do not match, and +forcing them together would put a registration round-trip in the per-object path. + +- An implementation **MUST NOT** register per-object receipts individually. +- An implementation **SHOULD** register the **group** receipt, or periodic + checkpoints over the receipt chain, leaving the per-object receipt exactly + where it is. +- Registration **MUST NOT** be a precondition for a receipt being valid. An + unregistered receipt is a receipt whose existence is unwitnessed, not a receipt + that is wrong. + +The checking party is the **Relying Party** in the terminology of the SCITT +architecture; this extension uses that term rather than coining another. + +## 4. The hash-algorithm constraint + +RFC 9995's `payload_hash_alg` takes an identifier from the COSE Algorithms +registry. **BLAKE3 — which `jwp-receipts` §2.1 uses throughout — does not appear +in that registry.** + +This is a real constraint, not a detail to be waved through: + +- An implementation **MUST NOT** emit a COSE Hash Envelope naming BLAKE3 by an + unregistered or invented identifier. An identifier a Relying Party cannot + resolve defeats the entire purpose of emitting in a standard encoding. +- Until a registration exists, an implementation **MUST** either omit the hash + envelope form, or carry a **second digest** under a registered algorithm + alongside the BLAKE3 commitment, stating plainly that the two cover the same + bytes. +- A dual-hash carry **MUST NOT** be presented as evidence that BLAKE3 is + registered. + +Registering BLAKE3 in the COSE Algorithms registry is a separate action with its +own process, and this extension does not assume its outcome. + +## 5. Stage discipline + +The referenced work is at mixed maturity, and an implementation **MUST NOT** +present any of it as more settled than it is: + +| document | status | +|---|---| +| SCITT architecture (RFC 9943) | Standards Track, published | +| COSE Receipts (RFC 9942) | Standards Track, published | +| COSE Hash Envelope (RFC 9995) | published | +| SCRAPI (registration/resolution API) | approved, in the RFC Editor queue | +| a concrete log profile | Working Group Last Call — **not ratified** | + +An implementation **MUST NOT** describe the log profile as ratified, and +**SHOULD** state which profile it registered against, since a Relying Party +cannot check a proof without knowing the log's rules. + +## 6. What this does not do + +- It does **not** replace the JWP receipt chain, and it does **not** move the + per-object commitment anywhere. +- It does **not** make registration a trust anchor. A Transparency Service + witnesses that a receipt existed at a time; it does not attest that the receipt + is true, and an implementation **MUST NOT** report registration as + verification. +- It does **not** solve key discovery. That is [`jwp-receipts`](jwp-receipts.md) + §7, and a log entry naming a key the Relying Party cannot resolve is still + unresolvable.