| Filename | Latest commit message | Latest commit date |
|---|---|---|
1601d35496
§2.4.12, against the envelopes: - An encrypted envelope (SPEC §6.4) is held: its manifest and rendition table are in the clear, so rules 4-9 read them as any held envelope's — the rendition an entry names, its capability, the component rules, a base's layer count, a companion-only capability, a fallback, a layer's refines and span — and leave to the signer only what needs a payload: its digests, a base's units and a layer's WIR1 payload. Rule 9 reads the classical length every well-formed WAI2's table declares, encrypted or not. Vectors: the review's three probes (rendition 9 of two, a relabelled rendition, the WAI2 named with no rendition), a base at two layers, a companion-only capability, a nonconforming refinement, an encrypted layer over an encrypted base (accepted). Re-derived, outside the pinned prefix: session_envelope_encrypted (390) now accepts; the classical-null case is session_envelope_encrypted_classical_unstated (389); session_envelope_inert_ unnamed_accept (397) states the classical length the encrypted table adds. - §2.4.12's signer's statements name whether a refinement's exploded envelope held as its own bytes was received on its own. SPEC §7.1: a component whose capability is a record or a derivation does not conform, in any role (record-or-derivation-as-component), in check_component_ roles and claim_verify.py; pin-conformance/selection.json gains a record and a derivation rendition, and its two companion cases take the new finding. session_roles_record_rendition pins it in the claim corpus. 555 vectors. staged-measurement's countability is cited by its heading (§3), so the section-refs check passes. differential.py adds an encrypted-envelope family. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| listings | ||
| sets | ||
| .gitattributes | ||
| cases.json | ||
| pin_verify.py | ||
| README.md | ||
| selection.json | ||
| static.json | ||
pin-conformance — the parameter-set pin
Vectors for the parameter-set pin (SPEC.md §3.1, §4, §7, §7.1).
Provenance. Generated here by wai_pin_vectors; the parameter-set files under sets/ are stand-in bytes written for the corpus. No media.
Reason-equivalence. A conforming verifier reports exactly the declared outcome for every case:
cases.json— given a pin, a capability, the forms the sink reads (defaultwai.prior.set) and the artifacts it holds, the outcomeokor the one reason SPEC §3.1 names:pin_malformed,form_not_registered,form_unreadable,form_required,prior_not_held,digest_superseded,set_malformed,part_mismatch. A held artifact is afile, or alistingtogether with therootits paths are read below. Paths are relative to this directory. The cases model a sink that holds no key log, so check 5 (prior_revoked,prior_not_authorised) does not run; it is covered by the parameter-set vectors of../signer-conformance/and thekey_loglibrary tests.selection.json— given aWAI2manifest, its payloads, the capabilities the sink advertises and the one-file parameter sets it holds, the rendition SPEC §7.1 picks and the reason for each entry it skips (not_selectable,missing_capability,component_digest_mismatch, or a pin reason); when nothing is picked, the reason for every entry. Where stated, also the companions applied with the pick, and the first component-role finding.static.json— the first finding a verifier makes about a manifest's pins without holding a parameter set (prior_not_applicable,pin_malformed,tier_unregistered,supersedes_malformed,form_not_registered,form_required,tier_exceeds_class, areplicate_*reason), orok. For aWAI2manifest the finding is[entry index, reason].
Listings. Every listings/<name>.sha256 is, byte for byte, the listing of
sets/<name>/: regular files, names that begin with . left out, sorted by path as
bytes. A common checksum utility checks a set against its listing
(cd sets/demo && sha256sum -c ../../listings/demo.sha256). Every file under
listings/bad/ breaks one listing rule and is set_malformed.
Files are compared as bytes; .gitattributes turns off line-ending conversion.
Verifiers.
wai_pin_vectors verify pin-conformance(wai-rs) runs every file through the reference implementation's in-memory pin core (wai::pin::verify_bytes), its selection (WaiMulti::pick) and its static checks (Wai::check_pin,WaiMulti::check_pins). It runs in both corpus loops of the conformance workflow.wai_pin_vectors generate pin-conformancerewrites the listings from the sets.pin_verify.pycheckscases.jsonandlistings/with the Python standard library alone, re-implementing the listing rules and the ordered checks from the SPEC text. It shares no code with wai-rs.