wai: live provenance, C2PA 2.4 §19 for room tracks and takes, tied to the JWP receipts #381

Merged

dcharlot merged 11 commits from wai/c2pa-live into main 2026-10-21 07:14:09 -04:00

Conversation 0 Commits 11 Files changed 110 +11979 -45

dcharlot commented 2026-10-21 05:08:43 -04:00

Owner

Copy link

What this is

C2 of the live family: the live video provenance of C2PA 2.4 §19, end to end, for a room's CMAF tracks and a device's CMAF take, tied to WAI's per-object receipts. It registers the record wai.live.provenance.

• Extension wai/extensions/live-provenance.md, with numbered sections, normative text and a reasons table of 33 codes. Each code carries the C2PA 2.4 §15 and §19.7 codes a C2PA validator reports for the same defect, where C2PA checks it.
• Reference wai-rs feature live_provenance (src/live_provenance.rs, plus bmff, jumbf, cose, x509, log and corpus). It writes and verifies everything with no C2PA library and no new dependency.
• Corpus wai/live-conformance/c2pa-live/, written from fixed seeds by wai_live_provenance_vectors: 7 good streams and 38 negatives (612 KB).
• Second implementation wai/live-conformance/c2pa_live_verify.py, standard library only.
• Wiring: a CI step, the REGISTRY entry and its regenerated export, a SPEC §5 paragraph, the CHANGELOG, and the live-conformance README. capture-binding §11 now points here and is implemented.

Design decisions, and why

• The unit. A room track packaged as CMAF travels under draft-ietf-moq-cmsf-01. Each MoQ group is one segment and each object one CMAF chunk; CMSF allows several chunks per object, and this profile requires one.
  • A segment is its C2PA boxes, then its group's objects, and nothing else.
  • So the segment's c2pa.hash.bmff.v3 and the group receipt's Merkle root commit to the same chunks. The spec states the exact correspondence (§8.1).
  • Per-segment manifests name the receipt (link hash, root, leaf count) in a science.transaction.wai.group assertion.
  • Under Verifiable Segment Info, the session key also signs the group receipts. The two signed structures can never be mistaken for each other: a Sig_structure begins 0x84, a group payload moq-jwp:.
  • One verification therefore checks the C2PA hard binding, the receipt root and every object receipt over the same bytes.
• Sequence numbers are each chunk's mfhd; a segment's number is its first chunk's.
  • §19's normative text holds: the number matches mfhd and never decreases.
  • §19.4.1's informative note assumes one chunk per segment. With several chunks, consecutive numbers differ by the chunk count. The spec says so.
• MoQ carriage: a provenance track (<layer>_c2pa, packaging wai-c2pa, named in wai_c2pa_track), not an object property:
  • A manifest store holds a certificate chain, kilobytes on every forwarded copy of an object's header.
  • A track keeps the media objects exactly the chunks a CMSF player plays and the receipts commit to.
  • A subscriber that does not verify can skip the track, and one that does can FETCH a past group by its number. It has the receipts track's form and shares its group numbers.
  • The init segment, with its C2PA box, rides CMSF's inline catalog data.
• AI marking (C2PA §18.15, §18.28; Regulation (EU) 2024/1689 Art. 50(2)): every manifest carries the digital source type and AI disclosures the stream's label gives.
  • The label vocabulary is timed-text's origin (1 human, 2 machine, 3 machine-reviewed), and disclosures are written exactly as timed-text §10.3 writes them.
  • A compositor's output is compositeCapture, composite or compositeSynthetic from its inputs' labels.
  • What is checkable: the marking matches the label the stream states. Whether content is machine-made cannot be decided from its bytes, and the spec says so.
• Two readings of C2PA 2.4, stated in the text:
  • §19.4.1 gives the VSI emsg exclusion offset as 0, where every box holds its size. Offsets count from a box's first byte (§18.6.2), so the exclusion that works is 12, where scheme_id_uri begins. This profile writes 12.
  • §18.25's example prints a signerBinding payload as h''. §13.2.3 reserves nil for detached content, so this profile writes nil.
• Dynamic packaging and REaP (coordinator input, checked against C2PA 2.4 §5.3.1, §13.2.1 and §19.2.1):
  • Every manifest identifier is a UUIDv4 derived from (stream, role, sequence number). CBOR and Ed25519 are deterministic.
  • Packagers that share a key therefore write byte-identical segments.
  • Packagers that do not share a key still chain across a failover, and both packagers' objects verify under the publisher's one receipt.
  • The camera-failover vector shows this. ISO/IEC 23009-9 could not be read; it is cited only as C2PA names it.
  • Follow-up, not in this PR: verifying that two encoders produced the same objects, by re-encoding under a replicate-tier capability. It needs the source and an encoder that is a pure function of it. This is stated in §1 and §10.3.
• Repository receipt (C2PA 2.4 §18.27; coordinator input):
  • A registered init segment keeps its box as original and ends with an update box, per Appendix A.5.3. No offset moves.
  • The update manifest holds a c2pa.ingredient.v3 naming the parent by hashed URIs, with the parent's validationResults (required by §18.16.12.4.3).
  • It also holds a JSON c2pa.repository-receipt. Its repository-specific proof is an RFC 9942 receipt of inclusion of the parent manifest's hash in the repository's RFC 9162 log, verified against the repository's key.
• Agreement with D1 (#379) and the synthesis origin claim.
  • D1's deriving-edge §6.1 names an input's manifest store as a parentOf ingredient. This PR's update manifest uses parentOf for its parent, and §10.3 now says a packager that re-segments or re-encodes a stream makes a new stream naming the source manifests as parentOf ingredients (c2pa.repackaged/c2pa.transcoded), as deriving-edge §6.1 has it. Packaging the same objects derives nothing.
  • The synthesis origin claim (wai/synthesis, unpushed, read in its worktree) keeps §9's mapping where the two overlap: digitalCapture/screenCapture; trainedAlgorithmicMedia for machine, compositeWithTrainedAlgorithmicMedia for reviewed; and compositeCapture/compositeSynthetic/composite for a compositor, by the same rule.
  • One difference for the lead: D1 cites C2PA 2.2 (actions as §18.14), while this PR cites 2.4, where actions are §18.15.
• C2PA SDK crate not used. Its licence was read (MIT OR Apache-2.0), but neither version 0.90 nor 0.91 implements §19: no c2pa.livevideo.segment, no session keys, no Verifiable Segment Info. The needed parts are implemented directly.
• Certificates. An Ed25519 test anchor, intermediate and end entity are derived from seeds, with c2pa-kp-claimSigning and id-kp-documentSigning. Names carry an organization, because the independent validator fails a claim signature whose subject has none.
• Media. The corpus re-cuts the packaging corpus's committed AV1 floor (video-base-01) into chunks of at most 15 frames, one group per piece, so every segment starts at a key frame. The library takes the media as input, so nothing outside the crate is compiled in.

Checks (all on the build host through rb unless marked local)

check	command	result
unit tests	cargo test --locked --no-default-features --features live_provenance --lib live_provenance::	17 passed
corpus test	cargo test --locked --no-default-features --features live_provenance --test live_provenance	3 passed (regenerates byte for byte; every vector's outcome; every reason refuses one; §12 equals Reason::ALL and both code columns)
corpus bin	wai_live_provenance_vectors verify ../live-conformance/c2pa-live	PASS, PASS
capture-binding test (its text changed)	cargo test --locked --no-default-features --features capture_take --test capture_take	4 passed
registry	cargo test --locked --no-default-features --lib codecs::registry; wai registry export --check	14 passed; up to date
clippy	cargo clippy --locked --no-default-features --features live_provenance --all-targets	no note in any touched file
lockfile	cargo metadata --locked --offline	ok (no dependency added)
Python second implementation (local)	python3 -I live-conformance/c2pa_live_verify.py live-conformance/c2pa-live	every vector agrees; 62 mutated copies of good vectors, 62 refused
other live verifiers (local)	events, rooms, takes, compose, recordings, captions, metering, steering, moderation, ads, watermark, e2ee	all PASS
repo checks (local)	check-tests-in-ci.py, check-workflow-concurrency.sh, check-spec-refs.py, check-wai-section-refs.py, check-no-vanity-metrics.sh, test-public-text-checks.sh, check-comparative-prose.sh, check-orphan-sources.py	all 0

check-public-names.sh needs the private denylist, which is not set locally; CI runs it.

Independent C2PA validator

The C2PA command-line tool 0.27.22 (MIT OR Apache-2.0; licence read) was installed on the build host and run with the corpus anchor.

file	the tool reports	this corpus states
every good init segment, including the registered one (active manifest = the update manifest, ingredient validated)	Trusted; bmffHash.match, hashedURI.match, claimSignature.validated, signingCredential.trusted	accept
cert-untrusted	signingCredential.untrusted	refused
cert-expired	signingCredential.expired, a code C2PA 2.4 does not list	refused, claimSignature.outsideValidity (§15.8's name)
cert-wrong-eku (time-stamping EKU only)	Trusted: the tool's default EKU list includes time-stamping and OCSP signing	refused, credential_invalid (§14.5.1.1–2)
update-ingredient	ingredient.manifest.mismatch	refused
repository-receipt-forged	Trusted: the tool does not check the repository's own proof	refused
manifest-malformed	"claim version is too new"	refused
any media segment	does not open it (expects ftyp first)	—

So the tool independently confirms the JUMBF store, the claim, the COSE signature, the X.509 chain and the BMFF hash over the moov. It cannot verify §19 media segments, segment-info maps or session keys; those are checked by the two implementations here.

Falsifications (each committed first, then broken, then restored)

check dropped	where	result
hard binding	Rust	cargo test --test live_provenance exit 101 (bytes-changed-manifests got receipt_mismatch)
receipt root	Rust	receipt-other-objects got object_receipt_invalid. This falsification first passed silently, which is why the vector was added.
repository receipt signature	Rust	repository-receipt-forged accepted → FAILED
hard binding, root, continuity, EKU, AI disclosure, superseded session key, VSI hash, object receipt, segment identifier derivation, repository signature	Python, each dropped in turn	exit 1 each, naming the vector and the reason no vector is refused for
one byte of a committed segment	corpus	Python exit 1 on every vector that uses that file

What is NOT done

• Time-stamps (§10.3.2.5) and OCSP; consistency proofs between repository tree heads; the 23009-9 segment-indexing alternative; external manifests and manifestUri; the Merkle form of the BMFF hash.
• Re-encoding verification of redundant encoders (replicate tier): stated as a follow-up.
• Takes: this PR writes and verifies the C2PA side and the take assertion. Checking commit against the room's take_commit events stays capture-binding §9's.
• No room-level check of which principal holds a receipt key (jwp-receipts §7).
• The WAI site's references row still needs editing to say capture-binding §11 is implemented; that is the sites slice's file.

🤖 Generated with Claude Code

## What this is C2 of the live family: the live video provenance of C2PA 2.4 §19, end to end, for a room's CMAF tracks and a device's CMAF take, tied to WAI's per-object receipts. It registers the record `wai.live.provenance`. - **Extension** `wai/extensions/live-provenance.md`, with numbered sections, normative text and a reasons table of 33 codes. Each code carries the C2PA 2.4 §15 and §19.7 codes a C2PA validator reports for the same defect, where C2PA checks it. - **Reference** `wai-rs` feature `live_provenance` (`src/live_provenance.rs`, plus `bmff`, `jumbf`, `cose`, `x509`, `log` and `corpus`). It writes and verifies everything with no C2PA library and no new dependency. - **Corpus** `wai/live-conformance/c2pa-live/`, written from fixed seeds by `wai_live_provenance_vectors`: 7 good streams and 38 negatives (612 KB). - **Second implementation** `wai/live-conformance/c2pa_live_verify.py`, standard library only. - **Wiring**: a CI step, the REGISTRY entry and its regenerated export, a SPEC §5 paragraph, the CHANGELOG, and the live-conformance README. capture-binding §11 now points here and is implemented. ## Design decisions, and why - **The unit.** A room track packaged as CMAF travels under `draft-ietf-moq-cmsf-01`. Each MoQ group is one segment and each object one CMAF chunk; CMSF allows several chunks per object, and this profile requires one. - A segment is its C2PA boxes, then its group's objects, and nothing else. - So the segment's `c2pa.hash.bmff.v3` and the group receipt's Merkle root commit to the same chunks. The spec states the exact correspondence (§8.1). - **Per-segment manifests** name the receipt (link hash, root, leaf count) in a `science.transaction.wai.group` assertion. - **Under Verifiable Segment Info**, the session key also signs the group receipts. The two signed structures can never be mistaken for each other: a Sig_structure begins `0x84`, a group payload `moq-jwp:`. - One verification therefore checks the C2PA hard binding, the receipt root and every object receipt over the same bytes. - **Sequence numbers** are each chunk's `mfhd`; a segment's number is its first chunk's. - §19's normative text holds: the number matches `mfhd` and never decreases. - §19.4.1's informative note assumes one chunk per segment. With several chunks, consecutive numbers differ by the chunk count. The spec says so. - **MoQ carriage: a provenance track** (`<layer>_c2pa`, `packaging` `wai-c2pa`, named in `wai_c2pa_track`), not an object property: - A manifest store holds a certificate chain, kilobytes on every forwarded copy of an object's header. - A track keeps the media objects exactly the chunks a CMSF player plays and the receipts commit to. - A subscriber that does not verify can skip the track, and one that does can FETCH a past group by its number. It has the receipts track's form and shares its group numbers. - The init segment, with its C2PA box, rides CMSF's inline catalog data. - **AI marking** (C2PA §18.15, §18.28; Regulation (EU) 2024/1689 Art. 50(2)): every manifest carries the digital source type and AI disclosures the stream's label gives. - The label vocabulary is timed-text's `origin` (1 human, 2 machine, 3 machine-reviewed), and disclosures are written exactly as timed-text §10.3 writes them. - A compositor's output is `compositeCapture`, `composite` or `compositeSynthetic` from its inputs' labels. - What is checkable: the marking matches the label the stream states. Whether content is machine-made cannot be decided from its bytes, and the spec says so. - **Two readings of C2PA 2.4, stated in the text:** - §19.4.1 gives the VSI `emsg` exclusion offset as 0, where every box holds its size. Offsets count from a box's first byte (§18.6.2), so the exclusion that works is 12, where `scheme_id_uri` begins. This profile writes 12. - §18.25's example prints a `signerBinding` payload as `h''`. §13.2.3 reserves `nil` for detached content, so this profile writes `nil`. - **Dynamic packaging and REaP** (coordinator input, checked against C2PA 2.4 §5.3.1, §13.2.1 and §19.2.1): - Every manifest identifier is a UUIDv4 derived from (stream, role, sequence number). CBOR and Ed25519 are deterministic. - Packagers that share a key therefore write byte-identical segments. - Packagers that do not share a key still chain across a failover, and both packagers' objects verify under the publisher's one receipt. - The `camera-failover` vector shows this. ISO/IEC 23009-9 could not be read; it is cited only as C2PA names it. - **Follow-up, not in this PR:** verifying that two encoders produced the same objects, by re-encoding under a `replicate`-tier capability. It needs the source and an encoder that is a pure function of it. This is stated in §1 and §10.3. - **Repository receipt** (C2PA 2.4 §18.27; coordinator input): - A registered init segment keeps its box as `original` and ends with an `update` box, per Appendix A.5.3. No offset moves. - The update manifest holds a `c2pa.ingredient.v3` naming the parent by hashed URIs, with the parent's `validationResults` (required by §18.16.12.4.3). - It also holds a JSON `c2pa.repository-receipt`. Its repository-specific proof is an RFC 9942 receipt of inclusion of the parent manifest's hash in the repository's RFC 9162 log, verified against the repository's key. - **Agreement with D1 (#379) and the synthesis origin claim.** - D1's deriving-edge §6.1 names an input's manifest store as a `parentOf` ingredient. This PR's update manifest uses `parentOf` for its parent, and §10.3 now says a packager that re-segments or re-encodes a stream makes a new stream naming the source manifests as `parentOf` ingredients (`c2pa.repackaged`/`c2pa.transcoded`), as deriving-edge §6.1 has it. Packaging the same objects derives nothing. - The synthesis origin claim (`wai/synthesis`, unpushed, read in its worktree) keeps §9's mapping where the two overlap: digitalCapture/screenCapture; trainedAlgorithmicMedia for machine, compositeWithTrainedAlgorithmicMedia for reviewed; and compositeCapture/compositeSynthetic/composite for a compositor, by the same rule. - One difference for the lead: D1 cites C2PA **2.2** (actions as §18.14), while this PR cites **2.4**, where actions are §18.15. - **C2PA SDK crate not used.** Its licence was read (MIT OR Apache-2.0), but neither version 0.90 nor 0.91 implements §19: no `c2pa.livevideo.segment`, no session keys, no Verifiable Segment Info. The needed parts are implemented directly. - **Certificates.** An Ed25519 test anchor, intermediate and end entity are derived from seeds, with `c2pa-kp-claimSigning` and `id-kp-documentSigning`. Names carry an organization, because the independent validator fails a claim signature whose subject has none. - **Media.** The corpus re-cuts the packaging corpus's committed AV1 floor (`video-base-01`) into chunks of at most 15 frames, one group per piece, so every segment starts at a key frame. The library takes the media as input, so nothing outside the crate is compiled in. ## Checks (all on the build host through `rb` unless marked local) | check | command | result | |---|---|---| | unit tests | `cargo test --locked --no-default-features --features live_provenance --lib live_provenance::` | 17 passed | | corpus test | `cargo test --locked --no-default-features --features live_provenance --test live_provenance` | 3 passed (regenerates byte for byte; every vector's outcome; every reason refuses one; §12 equals `Reason::ALL` and both code columns) | | corpus bin | `wai_live_provenance_vectors verify ../live-conformance/c2pa-live` | PASS, PASS | | capture-binding test (its text changed) | `cargo test --locked --no-default-features --features capture_take --test capture_take` | 4 passed | | registry | `cargo test --locked --no-default-features --lib codecs::registry`; `wai registry export --check` | 14 passed; up to date | | clippy | `cargo clippy --locked --no-default-features --features live_provenance --all-targets` | no note in any touched file | | lockfile | `cargo metadata --locked --offline` | ok (no dependency added) | | Python second implementation (local) | `python3 -I live-conformance/c2pa_live_verify.py live-conformance/c2pa-live` | every vector agrees; 62 mutated copies of good vectors, 62 refused | | other live verifiers (local) | events, rooms, takes, compose, recordings, captions, metering, steering, moderation, ads, watermark, e2ee | all PASS | | repo checks (local) | `check-tests-in-ci.py`, `check-workflow-concurrency.sh`, `check-spec-refs.py`, `check-wai-section-refs.py`, `check-no-vanity-metrics.sh`, `test-public-text-checks.sh`, `check-comparative-prose.sh`, `check-orphan-sources.py` | all 0 | `check-public-names.sh` needs the private denylist, which is not set locally; CI runs it. ## Independent C2PA validator The C2PA command-line tool 0.27.22 (MIT OR Apache-2.0; licence read) was installed on the build host and run with the corpus anchor. | file | the tool reports | this corpus states | |---|---|---| | every good init segment, including the registered one (active manifest = the update manifest, ingredient validated) | `Trusted`; `bmffHash.match`, `hashedURI.match`, `claimSignature.validated`, `signingCredential.trusted` | accept | | `cert-untrusted` | `signingCredential.untrusted` | refused | | `cert-expired` | `signingCredential.expired`, a code C2PA 2.4 does not list | refused, `claimSignature.outsideValidity` (§15.8's name) | | `cert-wrong-eku` (time-stamping EKU only) | `Trusted`: the tool's default EKU list includes time-stamping and OCSP signing | refused, `credential_invalid` (§14.5.1.1–2) | | `update-ingredient` | `ingredient.manifest.mismatch` | refused | | `repository-receipt-forged` | `Trusted`: the tool does not check the repository's own proof | refused | | `manifest-malformed` | "claim version is too new" | refused | | any media segment | does not open it (expects `ftyp` first) | — | So the tool independently confirms the JUMBF store, the claim, the COSE signature, the X.509 chain and the BMFF hash over the `moov`. It cannot verify §19 media segments, segment-info maps or session keys; those are checked by the two implementations here. ## Falsifications (each committed first, then broken, then restored) | check dropped | where | result | |---|---|---| | hard binding | Rust | `cargo test --test live_provenance` exit 101 (`bytes-changed-manifests` got `receipt_mismatch`) | | receipt root | Rust | `receipt-other-objects` got `object_receipt_invalid`. This falsification first passed silently, which is why the vector was added. | | repository receipt signature | Rust | `repository-receipt-forged` accepted → FAILED | | hard binding, root, continuity, EKU, AI disclosure, superseded session key, VSI hash, object receipt, segment identifier derivation, repository signature | Python, each dropped in turn | exit 1 each, naming the vector and the reason no vector is refused for | | one byte of a committed segment | corpus | Python exit 1 on every vector that uses that file | ## What is NOT done - Time-stamps (§10.3.2.5) and OCSP; consistency proofs between repository tree heads; the 23009-9 segment-indexing alternative; external manifests and `manifestUri`; the Merkle form of the BMFF hash. - Re-encoding verification of redundant encoders (`replicate` tier): stated as a follow-up. - Takes: this PR writes and verifies the C2PA side and the take assertion. Checking `commit` against the room's `take_commit` events stays capture-binding §9's. - No room-level check of which principal holds a receipt key (jwp-receipts §7). - The WAI site's references row still needs editing to say capture-binding §11 is implemented; that is the sites slice's file. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 10 commits 2026-10-21 05:08:43 -04:00

wai: live provenance, C2PA 2.4 §19 for room tracks and takes, tied to the JWP receipts ... d14be54e17

The extension live-provenance.md registers wai.live.provenance: the per-segment
C2PA Manifest Box method and the Verifiable Segment Info method, written as C2PA
2.4 §19 defines them for a CMAF track carried under draft-ietf-moq-cmsf-01, where a
segment less its C2PA boxes is its MoQ group's objects, so the segment's hard
binding and the group receipt's Merkle root commit to the same chunks. Session keys
rotate in a segment's manifest and also sign the group receipts.

wai-rs feature live_provenance writes and verifies it with no C2PA library: BMFF,
JUMBF, COSE_Sign1 with EdDSA, the claim signer's X.509 chain, and the receipts
through jwp_delivery. The corpus live-conformance/c2pa-live/ has five good streams
and a negative for each of the thirty reasons.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: live provenance certificates name an organization ... 7258ddb230

A C2PA validator in use reports the signer by the subject's organization and fails
the claim signature of a certificate without one, so every name of the corpus's
certificates is an organization and a common name; the extension's profile says so.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: c2pa_live_verify.py, the live provenance corpus's second implementation ... 424354f1ea

Written from live-provenance.md and the texts it reads, with the standard library
alone: deterministic CBOR, ISO BMFF and the BMFF hash, the JUMBF store, COSE_Sign1,
X.509 DER with the profile and chain, session keys and segment-info maps, and the
JWP group and object receipts, with Ed25519 and BLAKE3 from claim-conformance. It
gives every vector the corpus's outcome, place and codes, reads §12's table, and
requires every mutated copy of a good vector to be refused.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: a live provenance vector whose receipt alone names other objects ... 531f5997f1

The group receipt of camera-vsi's second group is signed over its first chunk with
one byte changed, so only the receipt's root disagrees with the segment: without
§11.4 step 6's root check a verifier refuses it for another reason.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: live provenance, derived manifest identifiers, dynamic packaging and repository receipts ... 0c19c60ad9

C2PA 2.4 extends live video to dynamically packaged content and recommends
deterministic signatures for streaming (§19.2.1, §13.2.1, naming ISO/IEC 23009-9);
it adds the repository receipt assertion (§18.27). Every manifest identifier is now
derived from the stream, a role and the segment's sequence number, so packagers that
share a key write identical segments and packagers that do not chain across a
failover. The initialization manifest may carry an update manifest with the parent
as ingredient and a c2pa.repository-receipt whose proof is an RFC 9942 receipt of
inclusion in an RFC 9162 log, verified against the repository's key.

Three reasons: manifest_id_mismatch, update_manifest_invalid and
repository_receipt_invalid; a failover vector, a registered vector and their
negatives; c2pa_live_verify.py reads all of it from the text. The CI step, the
registry entry and its export, SPEC §5, the CHANGELOG, the live-conformance README
and capture-binding §11 come with it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: live provenance, clippy-clean ... a2fecd6259

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: live provenance, the update manifest's ingredient states the parent's validation results ... 399ba16b25

C2PA 2.4 §18.16.12.4.3 requires validationResults in a v3 ingredient with an
activeManifest, and an independent validator refuses one without it; the writer
records the success codes a valid parent gives and the verifier recomputes them.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai: live provenance text, CHANGELOG, SPEC §5 and the corpus README brought to the dynamic packaging and repository receipt work ... 9d285a0c06

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge remote-tracking branch 'origin/main' into wai/c2pa-live 1d35e354c2

wai: live provenance §10.3 names the deriving edge's ingredient rule for a packager that derives ... e77a94dec2

Re-segmenting a stream, or writing its objects into another layout or codec, makes a
new stream that names the source segments' manifests as parentOf ingredients, as
deriving-edge §6.1 has an edge name its inputs' stores; packaging the same objects
into this profile's segment derives nothing.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request from a commit 2026-10-21 05:12:20 -04:00

deriving edge: cite C2PA 2.4 (§A.3.2, §18.15 actions); edge-conformance in the decoded-output exclusion list

dcharlot added 1 commit 2026-10-21 07:13:54 -04:00

Merge remote-tracking branch 'origin/main' into wai/c2pa-live ... de742cb9bf

# Conflicts:
#	wai/CHANGELOG.md

dcharlot merged commit 85369c1f4c into main 2026-10-21 07:14:09 -04:00

dcharlot referenced this pull request from a commit 2026-10-21 07:14:11 -04:00

Merge pull request 'wai: live provenance, C2PA 2.4 §19 for room tracks and takes, tied to the JWP receipts' (#381) from wai/c2pa-live into main

dcharlot referenced this pull request 2026-10-21 12:39:33 -04:00

wai: proof that an ad was presented — a player-signed presentation claim, and a spend that counts only presented impressions (E7) #398

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!381

No description provided.