jwp-receipts: typed claims, key discovery, and a second binding class #84

Merged

dcharlot merged 1 commit from wai/receipt-classes-and-key-discovery into main 2026-09-10 12:21:02 -04:00

Conversation 0 Commits 1 Files changed 1 +129

2026-09-10

Transaction Science

jwp-receipts: typed claims, key discovery, and a second binding class ...

Three holes, all in the receipt layer, all found by the landscape survey and
verified against this file.

1. THE RECEIPT ANSWERS ONE QUESTION (§2.4.3). `group` and `object` say what was
   delivered, by whom, at what energy cost. Three other bodies now issue
   per-object signed artifacts answering different questions over the same
   objects: a lawful-basis declaration bound to a media service (ABNT NBR 25608
   §8.8), a transparency-log inclusion proof (RFC 9942 COSE Receipts), and a
   recovered-binding assertion (C2PA soft binding). Rather than grow a field set
   per question, `kind: "claim"` carries a class discriminator and a class-scoped
   body on the same chain.

   The rules are about refusal, not carriage: a verifier MUST reject a class it
   does not know rather than ignore it; the class MUST NOT be inferred from the
   body's shape; where a claim and a delivery receipt disagree the verifier MUST
   reject rather than choose; and a claim carries the authority of its signer and
   no more — `class` says what is asserted, never that it is true.

2. EVERY SIGNATURE PRESUMED THE VERIFIER ALREADY HELD THE KEY (§7). `signer_pubkey`
   rides in the receipt, which makes the signature checkable but not trustworthy —
   a forger supplies a key as easily as a signature. For a party who was never on
   the delivery path that presumption fails, and every guarantee in §6 fails with
   it. Adds a REQUIRED `signer_locator` (cert-uri / trust-record / did), borrowing
   the design H.274's `dsci` SEI already uses rather than inventing a third shape.

   A verifier that cannot resolve it MUST report "signature-valid,
   identity-unconfirmed" — a materially weaker statement that MUST NOT be
   reported as verification. The locator MUST be inside the signed payload: one a
   relay can rewrite is one an attacker can rewrite.

3. A RECEIPT DID NOT SURVIVE NORMAL DISTRIBUTION (§8). The hard binding is BLAKE3
   over envelope bytes, destroyed by any transcode, remux or platform re-encode.
   Those are not attacks; they are what distribution does. With one binding class
   a re-encode left no recovery path: receipt intact, object no longer matching,
   nothing connecting them.

   Adds an explicitly weaker second class — a soft binding computed from the
   samples plus a resolution endpoint — with the ancestor rule as its centre: a
   recovered receipt attests THE ANCESTOR the object was derived from, not the
   object in hand, and an implementation that cannot express that distinction
   MUST NOT implement soft binding at all. A recovery presented as a hard binding
   is worse than no recovery, because it launders a transformation nobody
   attested.

No new cryptography and no new transport. §1 already anticipated a MoQT object
header as a carrier, which is the slot #80 §4.4 identifies.

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

0058478ad0

• View at this point in history

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