open-standards/wai/live-conformance/c2pa-envelope/README.md

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

The corpus of 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.