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