# live-conformance/c2pa-envelope — the C2PA binding of a stored envelope

The corpus of [`extensions/c2pa-binding.md`](../../extensions/c2pa-binding.md) §9: C2PA Manifest
Stores beside stored WAI envelopes, each with the JWP group receipt and object receipt its
verifier is given; the trust anchor every vector is verified under; and what a verifier states of
each.

**Files.** `vectors.json` lists the vectors, each its `name`, `envelope`, `store` (or `null`, a
store not served), `receipts` (a JSON file of `group`, the group receipt the verifier was given
for the store's `receipt`, and `object`, the envelope's object receipt, each in jwp-receipts
§2.4's JSON form or `null`) and `expect`. The good envelopes, their stores and their receipts sit
as an origin serves them: `objects/<cid>.wai` and, beside it, `objects/<cid>.c2pa` (§5.1). A file
whose bytes another vector already wrote is named by that vector's path, so a negative holds only
the files it changed. `anchor.der` is the trust anchor for `c2pa-kp-claimSigning`, and `time` the
instant *T* (§6.1).

**Equivalence.** A conforming verifier given a vector's files, the anchor and *T* reaches the
outcome `expect` states (§6):

- `refuse`: the `reason` of §7 and the C2PA 2.4 §15 code §7 gives it, `c2pa`, `null` where §7
  gives none;
- `accept`: what §6.3 states: the envelope's `form`, `contentHash` and `capabilities`, the
  `manifestId`, the `sourceType`, the `signer` (the SHA-256 of the claim signer's end-entity
  certificate), the group receipt's link hash (`receipt`) and publisher key (`publisher`), its
  `trackAlias` and `groupId`, and the object receipt's `objectId`, hashes in lowercase
  hexadecimal.

**The vectors.**

- Good: `wai1-bound`, a store bound to a `WAI1` of one `wai.image.png`, and `wai2-bound`, a store
  bound to a `WAI2` of the same picture at two sizes, each entry with its `id` and `sha256`. Both
  envelopes are objects 0 and 1 of one group receipt in the labelled payload, unmetered.
- One negative for each reason of §7, and for some reasons more than one; each name says its
  defect.

**Provenance.** `wai_c2pa_envelope_vectors gen` writes every file but this one from fixed seeds:
every key is SHA-256 of a label and no key is one anyone holds; the certificates are issued under
the corpus's own test anchor; the pictures are gradients the generator draws, written as PNG by
the packaging corpus's still writer, so each store states the source type `algorithmicMedia`.

**Checked by.** `wai_c2pa_envelope_vectors verify` and `tests/c2pa_envelope.rs` in `wai-rs`
(every file regenerates byte for byte and no other is here; every vector gets its outcome; every
reason refuses one; §7 lists the reference's codes), and `../c2pa_live_verify.py`, the second
implementation, written from the extension's text, which also requires every mutated copy of a
good vector to be refused and every one of its own checks, dropped, to be caught by the corpus.

**An independent C2PA validator.** The good vectors' stores were also read with the C2PA Rust
library (the `c2pa` crate, version 0.91.7, which shares no code with this corpus's reference) on
2026-11-09, each handed to it as a sidecar with its envelope
(`Reader::with_manifest_data_and_stream`, the envelope's format given as
`application/octet-stream`), with `anchor.der` its trust anchor and `c2pa-kp-claimSigning` and
`id-kp-documentSigning` its accepted extended key usages:

- both stores validate against their envelopes, state `Trusted`, with `signingCredential.trusted`,
  `claimSignature.validated`, `claimSignature.insideValidity`, `assertion.hashedURI.match` for
  each of the three assertions, and `assertion.dataHash.match`; the store, the claim, its
  signature, the certificate chain and the data hash over the whole envelope are therefore read
  the same way by an implementation that shares nothing with this one;
- with one byte of either envelope changed, the library reports `assertion.dataHash.mismatch`,
  the code §7 gives `hard_binding_mismatch`, and the state `Invalid`.

The library does not read the WAI assertion or the receipts, which the two implementations
above check.