25f011dac1
A hop sent to a third party's endpoint is work the router did not do. Its OER/2 receipt says the hop served or failed; nothing WAI defines says what was sent, to whom, what came back, or what the provider bills, so an implementation carries that in a record of its own that WAI's verifier cannot read. `wai-route-third-party-hop`, signed by the router and named by its digest: the provider and its API origin, whose account the hop ran on (never the key), the provider's id for the work, each exchange (method, URL without its query, times, status, the bodies by SHA-256 and length, the response where it was JSON, with links' queries removed), the outputs by name and content hash, the usage the provider bills, in the endpoint's unit, and what it reported charging, in its own terms. A verification document may carry the records beside its receipts (§7.2 step 9). Each is held to the route record's signer and job, to its attempt and that attempt's candidate, and when it served, its outputs to what the hop's receipt names and the attempt's count. No route record changes, since the record names the receipt the route record already names. routes corpus: 126 -> 202 vectors, from fixed seeds, every control refused at its own place. route_record_verify.py verifies each from the text, shares no code with wai-rs, and catches each of its 85 checks dropped and all 1,051 mutated copies. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2.3 KiB
Route record corpus
The conformance corpus of wai.route.record: one file,
vectors.json, written by wai_route_record_vectors gen from fixed seeds (extension §10).
Each vector is a verification document (§7.1) — the request, the price book, the policy and the record, each as its text, the hops' OER/2 receipts of minor version 1 as their texts and the key they are published under — with the outcome §7.3 gives it. The accepted vectors are routed and sealed by the reference; each refused one is a control of one defect, its record signed again over the defect where the defect is not in the signature, and the generator refuses to write a corpus whose control is refused for any reason or at any place but its own.
The vectors of version 1 come first, then those of version 2 (extension §3.4), whose names
begin v2_ but for the controls that pair a record with a price book of the other version:
a price book that prices each operation of an endpoint and states its measured failures, the
ranking by the expected cost and time to first byte per successful job, and the served hop's
outputs, to which its receipt is held. The outputs are the content hashes of fixed byte
strings standing for the envelopes a hop delivered; the verifier reads only their content
hashes. Then those of version 3 (§3.4), on version 2's price book, whose names begin v3_ but
for the control that pairs one with a price book of version 1: the served hop's outputs stated
by their count and root, to which its receipt is held, 5,000 of them in one record the size of
the others. Then those of the third-party hop record (§6.2), whose names begin third_party_:
each document carries the records beside the receipts, under route records of versions 2 and
3, with each rule of §6.2 broken once.
# wai-rs: regenerates byte for byte, and every vector gets its outcome
cargo run --no-default-features --features route_record --bin wai_route_record_vectors -- verify ../live-conformance/routes
# the second implementation, written from the extension's text (needs `cryptography`, which the
# OER/2 reference verifier uses for the hop receipts)
python3 -I ../route_record_verify.py live-conformance/routes
keys names the router's key and the hops' key; both come from fixed seeds and attest nothing.