open-standards/wai/live-conformance/bearers
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-10-21 12:56:01 -04:00
..
README.md wai: bearer receipts corpus, second implementation, HTTP index step 6, registry, SPEC §5, CHANGELOG, CI step 2026-10-21 12:56:01 -04:00
vectors.json wai: bearer receipts corpus, second implementation, HTTP index step 6, registry, SPEC §5, CHANGELOG, CI step 2026-10-21 12:56:01 -04:00

live-conformance/bearers — one receipt on every bearer

The corpus of 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.