open-standards/wai/claim-conformance

claim-conformance

Conformance for typed receipt classes and the soft binding class (§2.4.3–§2.4.12, §2.6, §3.1–§3.2): claim receipts of class energy, lawful-basis, log-inclusion, soft-binding, binding-recovery, measurement, operating-point, stage, delivery-gap and reconstruct-session, and recovery through a soft binding under the ancestor rule.

Each vector declares one outcome: accept — with the claim's link_hash, which pins the canonical form, or for a recovery the ancestor it attests — or reject at a named §3.1 step with a named reason. A verifier that rejects for another reason, or at another step, does not conform.

Files

file	what it is
vectors.json	The corpus. Every vector declares one outcome, and every reason of §3.1 is exercised at least once.
claim_verify.py	A second verifier, written from the extension text, that shares no code with wai-rs.
differential.py	Generates inputs the corpus does not hold, runs both verifiers on them, and reports every input on which their verdicts differ.

Two procedures appear. claim verifies one receipt (§3.1), with optional context the verifier holds: previous (this signer's previous claim, step 5), object (the delivery receipt's content_hash and joules_micro), oer (an OER receipt and its signer keys), declaration (the claim a decision or a recovery record names), publisher (for a recovery record: the key of a verified delivery receipt for the declaration's subject — §2.6.3 makes the declaration context only together with it, so a vector that gives a recovery record one without the other is malformed), and exact_match_algs (the soft-binding algorithms the verifier has a matcher for; the corpus's matcher is byte equality), and figure (the receipt that carries the figure a measurement or operating-point claim names), and gap_object (the object receipt at a delivery-gap claim's coordinates, as the verifier holds it once verified, by inclusion at least: {track_alias, group_id, object_id, content_hash}), and, for a reconstruct-session claim, outputs (its presentations, {unit, layers, decoder, out_digest}), redecoded (what a verifier that decoded presentations again found, {index, out_digest}, the index into outputs), objects (each object received, {content_hash, path, counted, transferred, presented}, counted null for an object not countable), envelopes (each WAI2 envelope the session received and any WAI1 envelope the verifier holds, {envelope}, its bytes in hex; a decoder entry naming one as its object is checked against it, and the classical rendition is read from each WAI2 envelope by §2.4.12's rule) and stage_claims (the wire forms of the stage claims it names). An object context may also carry the class its leaf is labelled with (jwp-receipts §2.2), in energy-measurement §2.7's JSON members, read as that section reads them. A figure context is one of two forms: claim, an energy claim's wire form, viewed under the moq-jwp:claim-link profile; or view, a receipt the verifier has already verified, given as {profile, identity, group, figures: [{index, joules_micro, energy_* members}], signer}, so that neither verifier needs to parse every receipt family a figure profile names. recover runs §3.2 from a declaration, the publisher key taken from a verified delivery receipt, the observed_value, and the object in hand's observed_hash (or null). Both procedures report recovery_signer_mismatch for a declaration the ancestor's publisher did not sign: recover_signer_mismatch and binding_recovery_declaration_not_publishers are the same defect, in a recovery performed and in one recorded.

Everything is synthetic. Keys are Ed25519 from fixed seeds (0x11 publisher, 0x22 meter, 0x33 operator, 0x44 sink, 0x55 resolver, 0x66 relay) and attest nothing; outputs, parameter sets and envelope payloads are synthetic bytes; figures, uncertainties and calibration references are invented; algorithm identifiers, registries, endpoints, logs and calibration certificates use reserved example domains; vocabulary terms are illustrative and no verifier here checks them against a vocabulary.

The acquisition class

An energy claim carries its class as energy-measurement §2.7 writes a class in JSON: energy_provenance, with energy_uncertainty, energy_counter_filtering and energy_calibration_ref present and null where the class has no such evidence. These vectors are about the class and its evidence:

• Accepted: an OnChipCounter figure with a declared uncertainty (2 % over 1 s) and its filtering state Unknown, and with Off; a CalibratedInstrument figure with a declared uncertainty (0.5 % over 1 s) and a calibration reference; a counter graded derived, below what it supports; a 1 µJ figure declared at exactly the resolution floor (288,676 ppm); and a counter graded measured that names an OER receipt grading the same figure measured.
• Rejected at step 4: legacy HwShunt, alone and with evidence beside it (energy_legacy_acquisition); a label in another case (energy_unknown_acquisition); and, as energy_acquisition_evidence, a counter without its uncertainty or without its filtering state (null is not Unknown), with a state outside On/Off/Unknown, or with a calibration reference; an instrument without its reference, with a reference of white space only (a space and U+3000), or with a filtering state; a ModelBased figure with an uncertainty; an uncertainty of zero ppm, of a zero window, or of 2³² ppm; and a 1 µJ figure at 288,675 ppm, one below the floor. An Estimator graded simulated is energy_grade_exceeds_acquisition.
• Rejected at step 2: an uncertainty without its window (missing_required_field), with a coverage factor beside it (unknown_member), with its relative part as a string, written as an array, and a filtering state written as a number (field_type).
• Rejected at step 3: a ModelBased claim rewritten in transit to OnChipCounter with an uncertainty and a filtering state: the class and its evidence are signed.

Reports about a figure: measurement and operating-point

A measurement claim publishes how one figure was measured — its bracket's values as integers, with the liveness facts of each bracket, the build and the power reader — and an operating-point claim records the operating point it was spent at. Both name the receipt that seals the figure by a figure profile (energy-measurement §6.1) and restate the figure with its class. The vectors cover:

• The arithmetic of energy-measurement §6.2: declarations at the least a bracket supports and one ppm below it; a figure at a half microjoule, which rounds up; brackets whose products exceed 128 and 200 bits; a calibrated instrument declaring more than the least; and the declaration a sealing path computes from unrounded samples, which the rule refuses. Those values are checked by claim_verify.py with Python's integers, and the bracket table wai-rs pins in energy_report is recomputed by it too.
• Liveness (§3.1): a bracket whose rail advanced in too few samples; a frozen rail refreshed once, which gives a flat idle bracket and an infinite ratio; a reader holding a stale non-zero value, stepped once by a batch refresh, with its honest facts and with facts claiming every sample live; a flat idle bracket whose facts claim the rail live (a repeated sample is not an advance, so a bracket with sd_uw 0 is never live); a refresh published in two steps in each bracket, which passes a rule of two consecutive advances; facts that describe no sequence; and, accepted, a ModelBased figure whose bracket shows a dead rail, since liveness binds the hardware classes only.
• The power reader (§2.4.8 rule 4): a hardware figure's report that names no reader is refused, with a bracket and without one; accepted, an OnChipCounter report with no bracket that names its reader.
• Every other rule of §2.4.8 rule 5 and §2.4.9, each with its reason, and two defects at once.
• Step 2: derived quantities are never carried (a bracket with its ratio is unknown_member); the opening and build-profile enumerations; integers, terms and absolute URIs where the tables require them.
• Step 6: against an energy claim and against views of a provenance receipt, a delivered object (named by its leaf index and its group), and an energy binding, which no Ed25519 key signs — a measurement claim about it is figure_signer_unknown, an operating-point claim about it is accepted; a report by a key other than the figure's signer; and an operating point recorded against an unmetered or unlabelled figure. A measurement claim checked without the receipt that carries its figure is figure_not_held, whether a stranger or the figure's own signer signed it: only step 6 shows a report is the figure signer's.
• The labelled delivery leaf: an energy claim against an object whose leaf carries a class, agreeing, and disagreeing in figure, class or evidence; an OnChipCounter label with no filtering state reads as Unknown.

What a party observed of a stage set: stage and delivery-gap

A stage claim (§2.4.10) is signed by the party that observed a stage set (staged-delivery §10.2) about its base. A delivery-gap claim (§2.4.11) is signed by a relay about an object it did not forward. The vectors cover:

• Accepted: a set requested, committed, delivered and presented at stage 2, four per-frame first layers and a second layer over the four frames; the second layer dropped at a relay, its receipt verified by inclusion, so the stage delivered is 1 and a reader derives that the commitment was not met; a base whose receipt was not verified first, whose layers applied with no evidence and which states no delivered stage, so rule 6 does not apply, and a layer over such a base applied on inclusion evidence; a second layer delivered and late for one frame (partial, deadline-missed); two first layers for one frame, both refused and the frame frozen; the base alone at entropy-consistency, with no stage hash; both layers delivered and refused, which meets a commitment to stage 2 with stage 0 presented; a span past the set refused refines-malformed, which lists its units as stated; and such a layer delivered over its bytes, which delivers nothing to the set.
• Rejected at step 4, each rule with its reason: the vocabulary, a point with a second member, above 255 or empty, and a request with no delivered stage; a stage hash without decode-equivalence and the converse; no unit, a last stage with no unit, a presented stage other than the lowest with units, more misses than units; objects out of order or listed twice, outside the units (and a span past the set refused for a reason decided after it was checked), at layer 0, with a reason where none belongs or none where one does, a reason staged delivery does not define, an object applied on inclusion alone or with no receipt beside a stated delivered stage, a dropped object said to be delivered or counted with bytes, objects that arrived with no bytes, more object bytes than the set's or all of them, and one layer applied twice to a unit; units at a stage no applied object of that layer reaches, a partial first layer counted as though applied to all four frames (with all four at stage 1 or at stage 2), and a second layer applied over frames the first never reached (stage_units_unsupported), with the honest partial layer, late for one frame, accepted beside them; a partial object over one unit; and a delivered stage the objects do not give, among them one over objects that leave a unit uncovered.
• Rejected at steps 1–3: a subject that is a receipt; a status, an evidence or a tier outside its enumeration; presented null; an object without reason; units with a member they do not define; a count written as a string; two defects, read in the table's order; and presented rewritten after signing.
• delivery-gap: accepted against the object receipt at its coordinates, without it, and chained to the relay's previous gap; refused when that receipt names another object (gap_subject_mismatch), when the receipt given is at other coordinates or is given to a claim that is not a gap (context_mismatch), for a reason outside its enumeration, a date that does not exist, or a subject that is a receipt.

What a sink reconstructed: reconstruct-session

A reconstruct-session claim (§2.4.12) is signed by a sink (key 0x44) about the entry object of one session. Most vectors edit one model session: six units. Four are a stage set over a pinned base — the session's entry object, a WAI1 envelope — refined to up to three layers, with two late layer objects never presented; each decoder entry names the object it decoded, so each layer applied has an entry of its own. One unit is decoded from the first rendition of a WAI2 envelope, built by wai-rs's container module, whose classical rendition the sink did not need. The sixth is decoded on the fallback path after a switch and presented late. The vectors cover:

• Accepted: the model unmetered and metered under OnChipCounter, each against every context: its presentations, re-decodes of byte-exact presentations that match, the objects received, its base's WAI1 envelope and the WAI2 envelope, and the stage claim it names; the model with no context, and with its stage claim but neither presentations nor objects; a session with no classical length beside an envelope whose second rendition is WAI's own; a classical rendition of two other video capabilities; a base forgotten under the record budget and decoded again with no layer sent again (staged-conformance/'s record_budget, its envelopes and the stage claim of each epoch as the sink's observer states them), naming both epochs' claims and only the first's; output trees of 1 to 33 leaves, half through a decoder whose replicate class makes it byte-exact and half through one checked for membership only, each re-decoded (the second with another digest, which is not checked); the caps of switches and missed presentations, written in full and up to the cap; and a measurement claim on a metered session's figure, under moq-jwp:claim-link, by the session's key.
• Rejected at step 4, each rule with its reason: units, leaves and paths that do not add up, a root without leaves or leaves without a root, three workers, a decoder identifier of the wrong grammar, a tier without a pin or one SPEC §3.1 does not define, module statuses that do not fit, a rendition past 65535, an entry twice or with no leaves, a refinement entry pinned above its class's tier, switches between one path and itself, for an unlisted reason, out of order, or written in another number than their total (or 1024), missed presentations with no deadline, above the leaves, written in another number than missed (or 256), zero microseconds late or out of order, a stage set listed twice, more bytes discarded than counted, a classical length without its source or with an unregistered one, and a figure of zero or of every acquisition-class defect.
• Rejected at steps 1–3: a subject that is a receipt; a missing and an unknown member; media, framing, a host profile and a decoder path outside their grammar or enumeration; a count written as a string; the host read before the decoders; an energy object missing a member; and a figure written into an unmetered session after signing.
• Rejected at step 6: a presentation whose output differs, a list one short, a (unit, layers) twice (session_output_mismatch); leaves moved between entries, a presentation naming an entry that does not exist, entries out of first-use order, paths and units that the presentations do not give, a missed presentation never made (session_output_inconsistent); a byte-exact re-decode that differs (session_output_irreproducible), and a byte-exact entry relabelled to a class checked for membership only by each route — the base's WAI1 entry, a WAI2 entry with its rendition kept or nulled, a capability another received envelope has — refused against the envelope of the object it names, as is an entry naming a rendition whose envelope is not held (session_source_mismatch); an entry object never received (session_entry_not_received); an entry's object, or an envelope held, the session did not receive (session_source_not_received); objects whose counted, uncounted or discarded bytes differ (session_counted_mismatch); an encrypted envelope, a WAI1 envelope with no manifest members and bytes of neither magic (session_envelope_unreadable); a second rendition of a capability the session decoded, of another media, WAI's own, a companion, a record, a parameter set, a neural codec, an unregistered string, or a text capability in a text envelope — none a classical rendition the session did not need — and a length one byte off (session_classical_mismatch); a stage claim whose signature is broken (context_invalid), signed by another key, or not named (context_mismatch); a stage claim counting more units at stage 2 than the session presented there, a set placed so that one of its units was never presented, units presented at stages no applied layer reaches — among them units presented through a first and a second layer the claim lists as late and a first layer it lists as refused — a stage claim about a base the session never received, objects received that hold none of the layers it says arrived, and the forgotten base's session naming only its last epoch's claim, which lists no layer, or presenting a unit past both epochs' layers (session_stage_disagrees); a session context given to a stage claim; and a measurement claim on an unmetered session, which carries no figure.

Steps 1 and 2: types, and the order a body is read in

§3.1 step 2 checks exactly the type a member table gives, member by member in the table's order; whatever a class's rules add to a type is step 4's, with the rule's own reason. Step-4 vectors pin that boundary from the rules' side: a zero figure (energy_zero_figure), a zero work count (energy_zero_work), an empty basis (lawful_basis_purpose_without_basis) and an http endpoint (soft_binding_endpoint_not_https). Others pin what the text settles on the other side, each signed again after its edit so the edit is its only defect:

• Step 1: a byte-order mark before the text is malformed (RFC 8259 lets a parser ignore one); a class written as a number is field_type, not unknown_class.
• Step 2, types: an empty alg is not a term; an endpoint with no scheme is not an absolute URI; a work unit holding U+3000, a White_Space character outside ASCII, is not a term. Each is field_type at step 2: alg is a term, not a string left whole to step 4's registry form; an endpoint's type is an absolute URI, and only https is step 4's; a term's white space is Unicode's White_Space, not ASCII's.
• Step 2, order: a lawful-basis body whose record names neither record is field_type, since record is read first; a declaration whose vocabulary has no scheme and whose purpose has no basis is field_type, since the table reaches vocabulary first and its encoding is checked as it is read; and one whose first purpose's term holds a space and whose second carries an extra member is field_type, since each purpose is read whole before the next. A reader that checks every purpose's members before the other members, or every encoding after every member, reports these two as missing_required_field and unknown_member.

The OER receipts

The OER receipts in oer contexts are sealed with wai-rs's OER module (its canonical form and content address), and read and verified by each verifier's own OER verifier under oer-receipts: the reference verifier (../oer-conformance/oer2_verify.py) reports the valid ones valid, the one altered after sealing as receipt_id_mismatch and receipt_hash_mismatch, and as malformed the six whose figure is not a quantity oer-receipts §4 reads or whose body holds a number §4 forbids: joules_total as a decimal string of 35 significand digits, as the JSON number 0.0120005, as -0.0, as the integer 2⁵³, spelt +0.012000, and as true. Two valid ones state the claim's figure and grade but are not about its object (an unrelated object, and the object's hash spelt in uppercase); step 6 rejects both.

Seven vectors state a figure step 6 reads at its edges, as oer-receipts §4 reads a quantity and compares it exactly: 0.0120005, exactly half-way, which admits 12,000 and 12,001 µJ; the same decimal written 1.20005e-2; the integer 1, one joule; and two figures written with 34 significand digits, the most a decimal string holds — one exactly half-way, and one (0.0120004 followed by twenty-six nines) below half-way only in its last digits, which is 12,000 µJ and not 12,001, although rounding it to 28 significant digits would make it a tie.

Signatures

Seven vectors test §3.1 step 3 beyond an ordinary bad signature.

• Six satisfy the verification equation — the cofactorless one, and so the cofactored one — with the key decoded leniently (y reduced mod p, the sign bit ignored when x = 0) and S reduced mod L. The generator asserts this for each. Step 3 refuses them on two different grounds:
  • RFC 8032's own rules, which step 3 restates: the identity key written with its sign bit set, and written with y = p + 1, each with a signature made without a private key (§5.1.3 decoding refuses both encodings; the point they spell is also of small order, so step 3's choice refuses them too); and S replaced by S + L (§5.1.7 requires S < L).
  • The choices step 3 fixes: the identity key and a key of order 8, each "signed" with no private key, and a genuine key signing with R the identity. An RFC 8032 verifier that accepts keys and R of small order accepts these three.
• One does not (signer_key_y_not_reduced): a key of large order written with y = p + j. Nobody can sign for that point, so the vector carries another key's signature, which fails the equation under any decoding (the generator asserts that too). It pins only the reason — bad_signer_key, not signature_verify_failed — and does not show that a lenient verifier would accept a forgery.

The cryptography package's Ed25519 on its own is more lenient than RFC 8032's decoding. Called on each vector's key, signature and signing input (cryptography 50.0.1 over OpenSSL 3.6.4, Python 3.14.7, macOS on arm64), it accepted five of the six that satisfy the equation — both non-canonical spellings of the identity and the three vectors of the second group — and of the seven refused only S + L and the y = p + j vector. claim_verify.py therefore makes step 3's decoding, order and range checks itself, and leaves only the equation to cryptography.

Running

# wai-rs: the canonical fixture, byte-identical regeneration, and every vector
cargo run --no-default-features --features receipt_claims --bin wai_claim_vectors -- verify ../claim-conformance

# the second verifier (needs Python 3 and `cryptography`)
python3 claim_verify.py

# the two verifiers' verdicts on generated inputs the corpus does not hold
cargo build --no-default-features --features receipt_claims --bin wai_claim_vectors
python3 differential.py <target-dir>/debug/wai_claim_vectors [--random N] [--seed S] [--keep FILE]

CI runs the first on the conformance matrix (Linux x86_64, Linux arm64, macOS arm64), and the second and third on the linux runner, with a fixed seed, in .github/workflows/wai-conformance.yml.

differential.py writes its inputs in the corpus's format with no declared outcome and runs each verifier's verdicts mode (wai_claim_vectors verdicts <file>, claim_verify.py verdicts <file>), which prints one verdict per input. Its families: JSON numbers and strings at the limits of what parsers accept, nesting depth, calendar dates, URI authorities, acquisition classes with every combination of label, uncertainty, filtering state and calibration reference around energy-measurement §2.3–§2.5's rules (calibration references of every White_Space character, and of U+001C, U+001F, U+200B and U+FEFF, which are not White_Space), OER figures near a half-microjoule and at the edges of oer-receipts §4's quantities, OER receipts whose sums and floors sit at §6's tolerances, OER receipts holding numbers §4 forbids in a body (-0, fractions, exponents, integers beyond I-JSON's range) in members of every kind, a delivered object's microjoules spelt as the corpus never gives them, context receipts that do not themselves verify, bodies of every class with one defect from a fixed list and with every pair of those at two different positions (a member, or a member of a nested object), where the order §3.1 step 2 reads a body in decides the reason, and, with --random N, a seeded random sample of dates, endpoints, figures, sums and class combinations, and of sessions: each built from a random presentation list as an honest sink states it, then given a defect or two in the body or in a context (units, leaves and paths off by one, switches and missed presentations past their caps, a null deadline with misses, presences that disagree, decoder indices out of range, leaves moved between entries, entries out of first-use order, outputs dropped or changed, re-decodes that match and that do not, objects counted otherwise, every acquisition class), checked against its presentations, objects, WAI2 envelopes and a stage claim. Further session families: sessions that pass steps 1–5 against a stage claim whose first layer applied to some units and arrived late for others, presented at one to three layers, with objects that hold or lack the set's base and layers (both bounds of §2.4.12's check); sessions naming one to three stage claims of one set, as a sink that forgot its base names one per epoch, each listing first and second layers of every status, sometimes one named a unit further on, presented within and past what the claims holding each unit applied; the missed presentations and switches written at, around and past their caps; WAI2 envelopes whose manifests readers may read otherwise (members of the wrong type, pins that are not pins, security members, duplicate members, numbers and nesting past every range, byte-order marks, lone surrogates) and whose framing is short or long, and the base's WAI1 envelope likewise, with a capability and a fallback the base's entry does or does not name — each with the session signed again so the entry names that envelope as its object; random sessions whose entries name their envelopes, a layer of their own or another object, with envelopes and objects that hold them or not; and every registered capability as an envelope's second rendition, in the session's media and in its own. Separately, each value that makes a whole file unreadable under oer-receipts §4 — a number beyond the double range, NaN, an unpaired surrogate escape, a repeated member name, nesting past 64 levels — goes in a file of its own beside readable twins, and the two verifiers must both refuse the file or give it the same verdicts. It exits 0 only if the two verdict lists are identical, every file is read or refused alike, and neither verifier crashed; any difference exits 1, at whatever step.

Both verifiers read a corpus-format file as oer-receipts §4 reads a vector document, since it holds OER receipts: wai-rs with oer::load, claim_verify.py with the OER reference's load. A difference where one side reports energy_oer_invalid is marked, since its cause is in the two OER verifiers rather than the claim rules, but it counts the same. Those two are compared on their own by ../oer-conformance/fuzz_differential.py.

What each check can and cannot show

The expected outcomes are declared per vector in the generator (wai-rs, claim_receipt::corpus), not copied from a verifier's output. The signed bytes, though, are produced by the same module that verifies them, so a canonicalisation defect would be baked into every signature and link hash and then confirmed. Two checks close that:

• The canonical fixture. An OnChipCounter claim given with members out of order at three levels, whitespace, and \u escapes in the input text. Its canonical bytes, signature and link hash were computed by claim_verify.py fixture — Python's JSON serialiser with members ordered by UTF-16 code units, cryptography's Ed25519, and BLAKE3 written from its specification — and are pinned as literals in wai-rs (check_canonical_form), which wai_claim_vectors verify checks first. Reversing the member order, or changing the signing domain, fails it.
• The second verifier. claim_verify.py reports every vector's declared outcome and every pinned link hash, including a claim whose canonical form spans three BLAKE3 chunks, and checks that the fixture it computes equals the literals in wai-rs. Its §3.1 step 3 checks other than the equation — RFC 8032 key decoding, the order of the key and of R, and S < L (which cryptography also checks) — are written from the curve's definition; the equation is cryptography's. Its acquisition-class rule is written from energy-measurement §2.3–§2.5, where wai-rs admits the class through crate::energy_class.

The corpus shows the two verifiers agree on its vectors and nothing more. differential.py checks agreement on inputs no vector declares an outcome for: that the two read the same inputs the same way. It does not show that either reading is the extension's, and it covers only the families it generates.

The second verifier and the differential were written by the same author as wai-rs, in a different language with no shared code. They catch disagreements in canonical form, hashing, signatures and the reading of JSON, dates, hosts, classes and figures; they are weaker evidence against a misreading of the extension that both verifiers share. Two of the order vectors above (lawful_basis_vocabulary_before_purposes, lawful_basis_purposes_in_order) exist because of one: both verifiers once read a declaration's purposes before its other members, which §3.1 step 2 does not say, and agreed with each other throughout. It was found by reading the text against the code; neither check could have shown it.

Regenerating

cargo run --no-default-features --features receipt_claims --bin wai_claim_vectors -- gen ../claim-conformance

Ed25519 signing is deterministic and the seeds are fixed, so the output is byte-identical on every machine; verify fails if the pinned file differs from it.