# live-conformance/bearers — one receipt on every bearer

The corpus of [`extensions/bearer-receipts.md`](../../extensions/bearer-receipts.md) §11, in one
file, `vectors.json`.

**Provenance.** Generated here by `wai_bearer_vectors gen` (`wai-rs`, feature
`bearer_receipts`), from Ed25519 keys on fixed 32-byte seeds, constant times, and envelopes
whose payloads are opaque test bytes written by the generator; no media and no input from
outside this repository.

`keys` names every key by its role, as 64 lowercase hexadecimal digits: the publisher's
(`publisher`, `did:web:publisher.example#d1`) and a second key of its origin (`publisher_d2`),
three sinks (`sink_a`, `sink_b`, `sink_c`, each signing under its `did:key`), the root of the
publisher's key log, and the root and key of a log forged on the bearer.

`cases` (§6, §7) are each one group as a verifier holds it:

- `group`: the group receipt (jwp-receipts §2.4.1) and `objects`, each object `receipt` with its
  `envelope` in hexadecimal where the verifier holds the bytes (a sink), or `null` (a relying
  party);
- `claims`: the transmission and reconciliation claims, each in its canonical wire form, each
  signer's in the order of its chain;
- `sink`: `null`, or the `bearer` class and `bearer_id` a verifier that is a sink received over
  (§6.5); `assertion`: `null`, or a statement offered (§6.4): `{"status": "transmitted",
  "bearer"}` or `{"status": "delivered", "sinks"}`; `count_only`: `null`, or the keys a relying
  party counts, having confirmed them (§7);
- `outcome`: `refuse` and the group's `reason`; or `verdict` with each object's verdict, each
  claim's (`declared`, `counted`, `joined reason=…`, `set-aside reason=…`, or `reject step=…
  reason=…`), the `status`, `sinks`, `whole`, `received_by` for each object, and for each
  declaration that stands its `bearer_id`, `bearer`, `sinks`, `energy` and
  `per_receiver_upper_bound`, then the `sink` check and the `assertion`'s result.

`same_receipt` names the three cases that carry one group and its object receipts, byte for
byte, on each bearer class; a verifier requires their object verdicts to be the same.

`offline` (§8) are each an `item` to confirm — a `group` with its `objects`, or a `claim` — and
the key `logs` the sink holds, each with its `origin`, the `log` document, and `via`: `pinned`
(provisioned in advance) or `bearer` (arrived over the bearer). `outcome`: `confirm`, with each
log's outcome (`anchored`, `held`, `anchor_on_bearer`), the item's `confirmation` and its energy
figure's where it has one, as jwp-receipts §7.4 reports them; or `refuse` with the item's own
refusal.

Everything is synthetic. Keys attest nothing; figures are invented; bearer instances use the
example URN namespace (`urn:example:`) and origins a reserved example domain. Each case states
the outcome it was written to have, declared in the generator, never copied from a verifier.

`wai_bearer_vectors verify` and `tests/bearer_receipts.rs` check that the file regenerates byte
for byte and that `wai-rs` reaches every stated outcome. `../bearer_verify.py` is the second
implementation, written from the extension's text, which also mutates copies of the corpus and
drops each of its own checks in turn and requires each to be caught.
`../../claim-conformance/claim_verify.py bearer vectors.json` reads every transmission and
reconciliation claim through jwp-receipts §3.1 steps 1–4.