28de796b42
SPEC §3.1's check 5 now has two parts. Revocation runs at every sink that holds a key log, for every capability a pin applies to: a set whose digest is in the revoked_modules of the head the sink reaches from any anchor it holds is refused with prior_revoked. It needs no grant, status or clock, so it no longer waits on the relying party holding the capability to jwp-receipts §7.9, and it is reported as prior_revoked whichever check of §7.9 a grant fails first, offline or with no grant included. Authorisation is still the relying party's choice per capability. SPEC §3.1 and §4, jwp-receipts §7.9 and the CHANGELOG say so. An envelope that pins no set no longer escapes check 5. The neural registry, given a key log, checks the set an unpinned decode reads under each digest a pin over it could name (the file's SHA-256 for a one-file set, and each listing beside it), and dispatch falls back when it is refused. PinAuthority gains check_unpinned for this. A family receipt now needs energy/<class> for each class its figures carry, as Item::from_family already derived: the §7.5 row, the corpus README, signer_verify.py and the corpus reader now agree. Item::for_group and Item::for_family are crate-internal, the corpus's builders, and the docs say that from_family takes signer_id and time from its caller. signer-conformance gains vectors for a revoked set whose grant fails at check 4, a revoked set with no grant, a set with no grant, and a family receipt with two classes, regenerated by wai_signer_vectors gen; both verifiers reproduce every verdict, and every earlier vector keeps its declared outcome. The CI library tests cover the revocation part at a sink that does not hold the capability to §7.9, and the neural key-log gate covers the unpinned decode. Docs say that a key log naming the subject's origin holds for one envelope. ModelRegistry's key_log field is private, which the CHANGELOG records. The pin corpus README says its cases model a sink with no key log. The parameter-set entry's refusal list names check 5's two reasons, and the did:web label test is described by the files it reads. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2.8 KiB
2.8 KiB
pin-conformance — the parameter-set pin
Vectors for the parameter-set pin (SPEC.md §3.1, §4, §7, §7.1).
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.