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

dcharlot commented 2026-09-07 06:01:29 -04:00

Owner

Copy link

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.
• Detectability of suppression — a receipt never shown leaves no trace of its absence.

Those are log properties, not envelope properties.

The move

Align onto JCR-1 as the sibling standards already are, 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, 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.

The hash constraint (§4) — the part that would have been quietly wrong

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 it.

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.

Stage discipline (§5)

Architecture and COSE Receipts published; hash envelope published; SCRAPI approved, in the RFC Editor queue; the concrete log profile in Working Group Last Call — which MUST NOT be described as ratified.

§6: this 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.

Ingest queue item 7 (#80 §3.6).

🤖 Generated with Claude Code

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. - **Detectability of suppression** — a receipt never shown leaves no trace of its absence. Those are **log** properties, not envelope properties. ### The move Align onto JCR-1 as the sibling standards already are, 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, 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. ### The hash constraint (§4) — the part that would have been quietly wrong 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 it.** 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. ### Stage discipline (§5) Architecture and COSE Receipts **published**; hash envelope **published**; SCRAPI **approved, in the RFC Editor queue**; the concrete log profile in **Working Group Last Call — which MUST NOT be described as ratified.** §6: this 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. Ingest queue item 7 (#80 §3.6). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-09-07 06:01:30 -04:00

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

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]>

dcharlot force-pushed wai/transparency-emission from 704158c362 to 803bf7f021 2026-09-10 10:26:18 -04:00 Compare

dcharlot merged commit 3c1d7178b2 into main 2026-09-10 12:23:16 -04:00

dcharlot referenced this pull request from a commit 2026-09-10 12:23:17 -04:00

Merge pull request 'transparency: an external encoding, and a witness for the receipt chain' (#89) from wai/transparency-emission into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!89

No description provided.