| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
|
||
| .. | ||
| README.md | ||
| vectors.json | ||
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) andobjects, each objectreceiptwith itsenvelopein hexadecimal where the verifier holds the bytes (a sink), ornull(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 thebearerclass andbearer_ida 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:refuseand the group'sreason; orverdictwith each object's verdict, each claim's (declared,counted,joined reason=…,set-aside reason=…, orreject step=… reason=…), thestatus,sinks,whole,received_byfor each object, and for each declaration that stands itsbearer_id,bearer,sinks,energyandper_receiver_upper_bound, then thesinkcheck and theassertion'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.