52 lines
3.4 KiB
Markdown
52 lines
3.4 KiB
Markdown
# 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.
|