open-standards/wai/live-conformance/keys/README.md
Transaction Science eec5d8dfa0 wai: key release, the proxy form of wai.video.keys (extensions/key-release.md)
The scheme (cenc, cbc1, cens, cbcs; the HLS methods AES-128, SAMPLE-AES,
AES-256-GCM) and the key delivery (HLS key URI, Clear Key, a content protection
system by its system ID) of each released key; the commitment list WKL1 derived
from a CPIX document, so the proxy copies each key_commit and holds no key; the
entitlement WKE1 bound to a device key and the device's proof over each request;
the release decision as a pure function of signed inputs (freshness, replay, key
periods, offline licences and renewals); the release ticket WKT1 for a clear
delivery, so the proxy never relays a key; verification of a proxy's log.

The key_release module of wai-rs (feature key_release), its unit tests, and the
corpus live-conformance/keys/, generated from fixed seeds by
wai_key_release_vectors and checked by tests/key_release.rs.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-25 21:28:20 -04:00

3.6 KiB

live-conformance/keys — key release

The corpus of extensions/key-release.md §12: logs of a signing proxy, each over commitment lists (WKL1) derived from CPIX documents, with the outcome its verification reaches (§10).

Log equivalence. For each vector, a conforming key-release verifier given its authorities, proxies, lists (each named in the top-level lists, as hexadecimal of its bytes), its cpix documents (each the file file, with the index in lists of the list it is derived from), its log (form-2 wai.video.keys receipts in the JSON of §8.2, in the order the proxy signed them) and its tickets (WKT1, hexadecimal) reaches the outcome the vector states:

  • refuse: the reason (§11) and where, at: ["list", i], ["cpix", i], ["receipt", i] or ["ticket", i] (§10.2);
  • accept: for each receipt (§10.3), its identity, decision (§7.2) and released; the keys it released, each its kid and key_commit; and its licence_expiry and renewal.

A verifier that reaches another outcome, reason, place or fact does not conform.

The accepted logs give: streaming releases over two content protection systems, forwarded and answered (release_drm, one receipt carrying a metered figure with its class); an HLS key file and Clear Key releases by ticket, the key never relayed by the proxy (release_hls_key_uri, release_clear_key); every refusal of §7.2 checks 1 to 7 (refusals, expired_entitlement); key rotation over three periods (rotation); offline licences, their renewal, their count, their lapse and their clamp to the entitlement (offline); and granted requests the licence server refused or did not answer (upstream_refused). Each n_ vector is a negative control, refused with a reason of §11; together they give every reason.

Provenance. Generated here: wai_key_release_vectors gen writes every file from logs authored in code, from fixed seeds. Each principal's Ed25519 key (the key holder, the entitlement authority, an untrusted authority, the proxy, an untrusted proxy, two devices) is SHA-256 of a fixed label; each content key, KID and session is SHA-256 of a fixed label, truncated. Every time is a constant (the corpus's t0 is 2026-10-25T00:00:00Z), every origin is an .example name (RFC 2606), the three system IDs are values of the DASH-IF registry of content protection system identifiers, and Ed25519 signing is deterministic (RFC 8032), so every file is the same bytes on every machine. The CPIX documents are written for the corpus with their keys in the clear (CPIX §8.1 calls that not recommended outside a test); the encrypted one holds a cipher value that is SHA-256 of a fixed label and decrypts to nothing. The licence challenges and licences are fixed strings, never a content protection system's messages. The generator asserts that each vector reaches the outcome it was written to have, and that the corpus gives every reason of §11 and every decision of §7.2, before it writes. No recorded data.

Layout

  • vectors.json: t0, principals (the keys, by name, informative), lists and vectors.
  • film.cpix.xml, episode.cpix.xml, channel.cpix.xml: the CPIX documents the lists are derived from (channel with three key periods); encrypted.cpix.xml, a document whose key is encrypted (cpix_unsupported); broken.cpix.xml, one that is not well-formed (cpix_malformed).

The second implementation is ../key_release_verify.py, written from the extension's text and sharing no code with wai-rs:

python3 -I live-conformance/key_release_verify.py live-conformance/keys