wai: actually write the C2PA manifest the energy binding describes #79

Merged

dcharlot merged 2 commits from wai/c2pa-emitter into main 2026-09-07 00:10:39 -04:00

Conversation 0 Commits 2 Files changed 6 +2946 -46

dcharlot commented 2026-09-04 06:14:41 -04:00

Owner

Copy link

energy_binding and reconstruction_binding define assertion shapes. Nothing emitted them — the extension document was describing a manifest that did not exist anywhere. This adds c2pa_emit, which signs a real asset with the C2PA SDK and puts all three assertions in the manifest, behind an off-by-default feature.

Four things that only surface when you actually try

Each is now normative in §6 of extensions/energy-binding.md.

A reconstruction is not c2pa.created. C2PA 2.x requires every created action to carry a digitalSourceType, and that vocabulary describes how the content came to exist — captured, human-drawn, model-generated. A decoder does not know that; it reconstructed pixels from a codestream and whatever was encoded could have been any of them. Reaching for trainedAlgorithmicMedia because a codec has a neural stage would assert that a compressed photograph is AI-generated content, which is false, and nothing in the vocabulary means "decoded; origin not visible from here". A decode is a conversion: the codestream is a parentOf ingredient, the manifest opens it, c2pa.converted records what was done, and no action claims a source type at all.

The codestream has to travel with it. The whole construction turns on a verifier re-decoding. A manifest carrying the reconstruction digest but not what produces it hands over a digest and no way to reach it. The digest says which decode the joules describe; the parent ingredient says what to decode to get there.

The assertions are created, not gathered — C2PA's own distinction between a claim the signer stands behind and material merely carried along, the same distinction the acquisition ladder draws inside the figure. Load-bearing, not editorial: a validator looks for the inception action among created assertions, so leaving the actions assertion gathered (what add_action does on its own) yields a manifest that signs happily and every validator then rejects as assertion.action.malformed — on the far side of a signature.

Signed is not trusted. An ephemeral certificate reaches Valid, never Trusted. untrusted_local_signer is named for its limit.

The rule the SDK cannot enforce

Third-party assertion bodies are opaque to C2PA, so it will sign a manifest whose energy figure is measured over one decode while the reconstruction assertion commits to another — the self-refutation §2 describes — and the result validates. ReconstructionManifest::new refuses that pair at construction, before a signature can cover it, and recover applies the same rule on the way back in.

recover also reports the unaccompanied standard assertion — perfectly valid C2PA, refused here — as its own error rather than a generic absence, because that is the exact situation the companion exists to be distinguished from.

Assertion bodies are parsed from the same to_json functions the extension documents pin, so the emitter cannot drift from the specified shape.

Verification

7 tests, signing a real PNG and reading the manifest back with an independent Reader. The trust test pins the single failure code as well as the verdict, so a real defect cannot hide behind the expected one — not hypothetical: the missing inception action was found exactly that way. cargo tree -i c2pa under --features provenance finds nothing, so the default build is untouched.

🤖 Generated with Claude Code

`energy_binding` and `reconstruction_binding` define assertion **shapes**. Nothing emitted them — the extension document was describing a manifest that did not exist anywhere. This adds `c2pa_emit`, which signs a real asset with the C2PA SDK and puts all three assertions in the manifest, behind an off-by-default feature. ## Four things that only surface when you actually try Each is now normative in §6 of `extensions/energy-binding.md`. **A reconstruction is not `c2pa.created`.** C2PA 2.x requires every created action to carry a `digitalSourceType`, and that vocabulary describes how the *content* came to exist — captured, human-drawn, model-generated. A decoder does not know that; it reconstructed pixels from a codestream and whatever was encoded could have been any of them. Reaching for `trainedAlgorithmicMedia` because a codec has a neural stage would assert that a compressed photograph is AI-generated content, which is false, and nothing in the vocabulary means *"decoded; origin not visible from here"*. A decode is a **conversion**: the codestream is a `parentOf` ingredient, the manifest opens it, `c2pa.converted` records what was done, and no action claims a source type at all. **The codestream has to travel with it.** The whole construction turns on a verifier re-decoding. A manifest carrying the reconstruction digest but not what produces it hands over a digest and no way to reach it. The digest says *which* decode the joules describe; the parent ingredient says *what to decode to get there*. **The assertions are `created`, not `gathered`** — C2PA's own distinction between a claim the signer stands behind and material merely carried along, the same distinction the acquisition ladder draws inside the figure. Load-bearing, not editorial: a validator looks for the inception action among created assertions, so leaving the actions assertion gathered (what `add_action` does on its own) yields a manifest that signs happily and every validator then rejects as `assertion.action.malformed` — on the far side of a signature. **Signed is not trusted.** An ephemeral certificate reaches `Valid`, never `Trusted`. `untrusted_local_signer` is named for its limit. ## The rule the SDK cannot enforce Third-party assertion bodies are opaque to C2PA, so it will sign a manifest whose energy figure is measured over one decode while the reconstruction assertion commits to another — the self-refutation §2 describes — and the result validates. `ReconstructionManifest::new` refuses that pair at construction, before a signature can cover it, and `recover` applies the same rule on the way back in. `recover` also reports the **unaccompanied standard assertion** — perfectly valid C2PA, refused here — as its own error rather than a generic absence, because that is the exact situation the companion exists to be distinguished from. Assertion bodies are parsed from the same `to_json` functions the extension documents pin, so the emitter cannot drift from the specified shape. ## Verification 7 tests, signing a real PNG and reading the manifest back with an independent `Reader`. The trust test pins the single failure code as well as the verdict, so a real defect cannot hide behind the expected one — not hypothetical: the missing inception action was found exactly that way. `cargo tree -i c2pa` under `--features provenance` finds nothing, so the default build is untouched. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-09-04 06:14:41 -04:00

wai: actually write the C2PA manifest the energy binding describes ... b894903916

`energy_binding` and `reconstruction_binding` define assertion *shapes*. Nothing
emitted them. A shape no implementation writes is a proposal, and the extension
document was describing a manifest that did not exist anywhere — so this adds
`c2pa_emit`, which signs a real asset with the C2PA SDK and puts all three
assertions in the manifest, behind an off-by-default `c2pa_emit` feature.

Writing it turned up four things that only surface when you try, each of which
is now normative in §6 of the extension:

**A reconstruction is not `c2pa.created`.** C2PA 2.x requires every created
action to carry a `digitalSourceType`, and that vocabulary describes how the
*content* came to exist — captured, human-drawn, model-generated. A decoder does
not know that; it reconstructed pixels from a codestream and whatever was encoded
could have been any of them. Reaching for `trainedAlgorithmicMedia` because a
codec has a neural stage would assert that a compressed photograph is
AI-generated content, which is false, and nothing in the vocabulary means
"decoded; origin not visible from here". A decode is a **conversion**: the
codestream is a `parentOf` ingredient, the manifest opens it, `c2pa.converted`
records what was done, and no action claims a source type at all.

**The codestream has to travel with it.** The whole construction turns on a
verifier re-decoding. A manifest carrying the reconstruction digest but not what
produces it hands over a digest and no way to reach it. The digest says which
decode the joules describe; the parent ingredient says what to decode to get
there.

**The assertions are `created`, not `gathered`** — C2PA's own distinction between
a claim the signer stands behind and material merely carried along, which is the
same distinction the acquisition ladder draws inside the figure. Load-bearing,
not editorial: a validator looks for the inception action among created
assertions, so leaving the actions assertion gathered (what `add_action` does on
its own) yields a manifest that signs happily and every validator then rejects as
`assertion.action.malformed` — on the far side of a signature.

**Signed is not trusted.** An ephemeral certificate reaches `Valid`, never
`Trusted`. `untrusted_local_signer` is named for its limit.

The emitter enforces one rule the SDK cannot. Third-party assertion bodies are
opaque to C2PA, so it will sign a manifest whose energy figure is measured over
one decode while the reconstruction assertion commits to another — the
self-refutation §2 describes — and the result validates.
`ReconstructionManifest::new` refuses that pair at construction, before a
signature can cover it, and `recover` applies the same rule on the way back in.
`recover` also reports the unaccompanied standard assertion — perfectly valid
C2PA, refused here — as its own error rather than a generic absence, because that
is the exact situation the companion exists to be distinguished from.

Assertion bodies are parsed from the same `to_json` functions the extension
documents pin, so the emitter cannot drift from the specified shape.

Verified: 7 tests, signing a real PNG and reading the manifest back with an
independent `Reader`. The trust test pins the single failure code as well as the
verdict, so a real defect cannot hide behind the expected one — which is not
hypothetical: the missing inception action was found exactly that way.
`cargo tree -i c2pa` under `--features provenance` finds nothing, so the default
build is untouched.

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

dcharlot added 1 commit 2026-09-04 06:34:39 -04:00

wai: run the C2PA emitter in CI, and drop its system-crypto dependency ... 008b8a0620

Two gaps in the emitter as first written, both of the same kind: a claim with
nothing checking it.

**The tests never ran.** `c2pa_emit` is off by default and the four-platform
`cargo-classes` job builds a fixed feature list that does not include it, so the
seven tests compiled locally and nowhere else. A feature no workflow enables has
no coverage at all — the suite passes and the tests in it simply do not run.
This adds a job that enables it.

One platform, deliberately. Everything the existing matrix exists to prove is
about byte-identical reconstruction across architectures; a signed manifest makes
no such claim and would not become more true for being emitted on four machines.

**It linked system OpenSSL.** The c2pa SDK defaults to an openssl backend plus
four HTTP stacks. Every wai workflow is built on "pure Rust, no system
dependencies" — that is what lets the conformance matrix run on Linux, macOS and
Windows with no setup — and an openssl-linked optional feature quietly puts a
system library back in the crate's reach. Switched to the SDK's
`rust_native_crypto` backend with `default-features = false`, which also drops
the reqwest/ureq/wstd/wasi chain that local emission never uses. `openssl`,
`openssl-sys`, `reqwest` and `ureq` are all absent from the graph, and the seven
tests pass unchanged.

Both properties are now asserted rather than assumed, because both are the kind
that decay silently:

- a step fails if `openssl` or `openssl-sys` ever reaches the `c2pa_emit` graph,
  since an openssl-linked build would still pass every test here while making
  the crate undistributable to a bare runner;
- a step fails if `c2pa` ever becomes reachable from `provenance`, since that
  would hand a large dependency tree to consumers who wanted only the binding
  types, and falsify the "off by default" claim in the extension.

The guards were checked to discriminate, not merely to pass: `cargo tree -i` was
confirmed to detect a dependency that IS present, so a guard that silently
stopped working could not read as a green check.

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

dcharlot force-pushed wai/c2pa-emitter from 008b8a0620 to 3e9b129728 2026-09-04 06:37:32 -04:00 Compare

dcharlot force-pushed wai/c2pa-emitter from 3e9b129728 to 8348a6e5b3 2026-09-04 06:38:03 -04:00 Compare

dcharlot force-pushed wai/c2pa-emitter from 8348a6e5b3 to 237257b2ad 2026-09-06 06:25:43 -04:00 Compare

dcharlot force-pushed wai/c2pa-emitter from 237257b2ad to d5ec1abe1b 2026-09-06 06:26:12 -04:00 Compare

dcharlot merged commit c05ae9a1b2 into main 2026-09-07 00:10:39 -04:00

dcharlot referenced this pull request from a commit 2026-09-07 00:10:40 -04:00

wai: actually write the C2PA manifest the energy binding describes (#79)

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!79

No description provided.