transparency: an external encoding, and a witness for the receipt chain #89

Merged

dcharlot merged 1 commit from wai/transparency-emission into main 2026-09-10 12:23:16 -04:00

Conversation 0 Commits 1 Files changed 1 +111

2026-09-10

Transaction Science

transparency: an external encoding, and a witness for the receipt chain ...

What WAI lacks is not verifiability. An Ed25519 signature over a group Merkle
root is checkable by anyone holding the publisher key, and jwp-receipts §3 says
exactly how. Three properties are missing, and none is a signature property:
non-equivocation (nothing stops a publisher showing different chains to different
parties — both verify), independent timestamping (a receipt says when the
publisher says it was made), and detectability of suppression (a receipt never
shown leaves no trace of its absence). Those are LOG properties.

The family already owns both halves — a transparency log with consistency proofs
exists, and JCR-1 is already the canonical receipt envelope across sibling
standards. What nothing in the family has is a standardised external encoding an
outside auditor's off-the-shelf tooling can verify with no bespoke verifier. So:
align onto JCR-1, then emit RFC 9942 (COSE Receipts) and, where the payload rides
by hash, RFC 9995 (COSE Hash Envelope) on top.

Strictly additive. The JWP chain is unchanged, emissions are additional encodings
of the same facts, and where an emission and the chain disagree the chain is
authoritative and the emission is in error.

CADENCE (§3). SCITT registers per-artifact Signed Statements over an HTTP API;
WAI emits per-object receipts at media-group cadence. Forcing them together would
put a registration round-trip in the per-object path, so: MUST NOT register
per-object receipts individually; SHOULD register the group receipt or periodic
checkpoints; and registration MUST NOT be a precondition for validity — an
unregistered receipt is unwitnessed, not wrong. Uses "Relying Party" from the
SCITT architecture rather than coining another term.

THE HASH CONSTRAINT (§4), which is the part that would have been quietly wrong.
RFC 9995's `payload_hash_alg` takes an identifier from the COSE Algorithms
registry, and BLAKE3 — which jwp-receipts §2.1 uses throughout — does not appear
in it. So an implementation MUST NOT emit a hash envelope naming BLAKE3 by an
invented identifier; until a registration exists it MUST either omit that form or
carry a second digest under a registered algorithm alongside the BLAKE3
commitment; and a dual-hash carry MUST NOT be presented as evidence that BLAKE3
is registered. Registering it is a separate action with its own process and this
text does not assume the outcome.

STAGE DISCIPLINE (§5). The referenced work is at mixed maturity and the table
says so: architecture and COSE Receipts published, hash envelope published,
SCRAPI approved and in the RFC Editor queue, and the concrete log profile in
Working Group Last Call — which MUST NOT be described as ratified.

§6 states what this is not: it does not replace the chain, does not make
registration a trust anchor (a Transparency Service witnesses that a receipt
existed, not that it is true), and does not solve key discovery — that is
jwp-receipts §7, and a log entry naming an unresolvable key is still
unresolvable.

Ingest queue item 7 (#80 §3.6).

Co-Authored-By: Claude Opus 5 <[email protected]>

803bf7f021

• View at this point in history

2026-09-10 10:24:58 -04:00