### `wai.live.provenance`: C2PA 2.4 live video provenance for room tracks and takes, tied to the JWP receipts

- **The extension** ([live-provenance](extensions/live-provenance.md)) registers the record
  `wai.live.provenance`: C2PA 2.4 §19's live video provenance, written exactly as §19 defines
  it, for a room's CMAF tracks and a device's CMAF take. A room track packaged as CMAF travels
  under `draft-ietf-moq-cmsf-01`, each MoQ group one segment and each object one CMAF chunk.
  A segment is its C2PA boxes followed by its group's objects and nothing else, so the
  segment's `c2pa.hash.bmff.v3` and the group's JWP receipt commit to the same chunks; the
  segment's sequence number is its first `mfhd`'s, following from the receipts' leaf counts.
- **Both methods.** Per-segment C2PA Manifest Boxes: each manifest holds the hard binding, the
  actions, `c2pa.livevideo.segment` (the stream identifier and the manifest before it) and a
  group assertion naming its receipt by link hash and root. Verifiable Segment Info: an `emsg`
  of version 0 per segment carrying a COSE_Sign1 by a session key over the segment-info map;
  the session keys, OKP Ed25519 keys bound to the claim signer's certificate, are delivered in
  the initialization manifest and rotated by a manifest in a segment, and the session key also
  signs the group's receipts. A take uses both at once, its device's key the session key, and
  its stream identifier its take id's, as capture-binding §11 had them.
- **The profile.** One manifest per store; EdDSA throughout, deterministic as C2PA §13.2.1
  recommends for streaming; an X.509 chain of version 3 Ed25519 certificates with
  `c2pa-kp-claimSigning`; four whole-box exclusions in every hash; every manifest identifier
  derived from the stream, the manifest's role and the segment's sequence number. Two readings
  of C2PA 2.4 are stated: the VSI box's exclusion offset is 12, where `scheme_id_uri` begins,
  since the 0 §19.4.1 prints compares a box's size; and a `signerBinding` is detached with a
  `nil` payload, as §13.2.3 requires, where §18.25's example prints `h''`.
- **AI disclosure.** Every manifest carries the IPTC digital source type and one
  `c2pa.ai-disclosure` per model that the stream's label gives, as timed-text §10.3 gives them
  for captions; a compositor's output is `compositeCapture`, `composite` or
  `compositeSynthetic` from its inputs' labels and carries their models' disclosures. A stream
  labelled machine-made without the marking is refused. This is the machine-readable marking
  Regulation (EU) 2024/1689 Article 50(2) describes, stated as an engineering requirement.
- **Dynamic and redundant packaging.** C2PA 2.4 treats content packaged on request as live
  (§19.2.1) and recommends deterministic signatures for it, naming ISO/IEC 23009-9 (§13.2.1).
  With derived identifiers, deterministic CBOR and Ed25519, every byte of a segment is a
  function of its group's objects, the stream and the claim signer's key: packagers that share
  a key write the same segment, and packagers that do not chain across a failover, their
  segments' objects under the publisher's one receipt. Checking two encoders' outputs by
  re-encoding under a `replicate` capability is stated as not in this revision.
- **Repository receipts** (C2PA 2.4 §18.27). A registered initialization segment keeps its
  manifest box as `original` and ends with an `update` box: an update manifest whose one
  ingredient is the parent, with the parent's validation results, and whose
  `c2pa.repository-receipt` carries, as the repository's proof, an RFC 9942 receipt of
  inclusion of the parent's manifest hash in the repository's RFC 9162 log, verified against
  the repository's key.
- **Carriage.** Over HTTP, the segment files. Over MoQ, each segment's C2PA boxes ride a
  provenance track, `<layer>_c2pa` (`packaging` `wai-c2pa`, named in `wai_c2pa_track`), whose
  group *g* is segment *g*'s C2PA boxes, so the media objects stay the chunks a CMSF player plays
  and the receipts commit to; the initialization segment rides the catalog's inline data.
- **Thirty-three reasons**, from `segment_malformed` to `segment_missing`, each with the C2PA
  2.4 §15 and §19.7 codes a C2PA validator reports for it, where C2PA checks it.
- **Reference and corpus.** `wai-rs` feature `live_provenance` (`src/live_provenance.rs` and
  its `bmff`, `jumbf`, `cose`, `x509` and `corpus` modules), with no C2PA library and no new
  dependency. `live-conformance/c2pa-live/`, written from fixed seeds by
  `wai_live_provenance_vectors` over the packaging corpus's AV1 floor: a camera track under each
  method (the session key rotated at its third segment), a track labelled machine-made, a
  compositor's output, a take, a failover between two packagers and a registered stream; and
  one negative per reason, among them a segment whose bytes
  changed, a missing segment and a reordered one, a manifest bound to the wrong receipt, a
  stream identifier that differs, an expired and a time-stamping end entity, and a machine-made
  track without its disclosure. Checked by `tests/live_provenance.rs` and by
  `live-conformance/c2pa_live_verify.py`, a second implementation that shares no code with
  `wai-rs` and requires every mutated copy of a good vector to be refused. The corpus's
  initialization segments, the registered one with its update manifest included, also validate
  in the C2PA command-line tool; the tool opens no media segment (`c2pa-live/README.md`). The
  registry lists the record and the catalog values `wai-c2pa` and `wai_c2pa_track`.
- **capture-binding §11** now points here for the C2PA side of a take, and is implemented.

