open-standards/wai/live-conformance/c2pa-identity

live-conformance/c2pa-identity — trust lists, soft bindings, the ISCC soft binding and identifier, and identities

The corpus of extensions/c2pa-binding.md §9.2: C2PA Manifest Stores beside stored WAI envelopes that carry, after the three assertions of §4.1, soft bindings of wai-mark:tent64 (§4.8), the ISCC soft binding io.iscc.v0 and the ISCC identifier (§4.9) and the Creator Assertions Working Group's identity assertions (§4.10), verified against trust lists pinned by digest (§6.4); and what a verifier states of each.

Files. vectors.json lists the vectors, each its name, envelope, store, receipts (as in c2pa-envelope/), claimLists and identityLists (the trust lists its verifier is configured with, each its file, the uri and type the verifier names it by, and the digest it pinned), robustness (the robustness record and claims its verifier was given, in order) and expect. trust/ holds the lists in the form the C2PA Trust List is published in; robustness/ the record of wai-mark:tent64 over the corpus's first two pictures, the claim of every attack it shows survived, and a claim of one attack more; objects/ the four envelopes, the receipts, and for each envelope its first good store, as an origin serves them (a second good store over one envelope is in its vector's own directory). A file another vector already wrote is named by that vector's path. anchors is empty: every anchor comes from a list. time is the instant T.

Equivalence. A conforming verifier given a vector's files and T reaches the outcome expect states (§6): for refuse, the reason of §7 and the code §7 gives it (c2pa, the C2PA 2.4 code for §7.1's reasons and the Identity Assertion's for an identity's, null where §7 gives none); for accept, what §6.3 states, among it the trustLists that held the claim signer's anchor, the softBindings, the isccBinding (its alg, its sequence in its canonical form as iscc, and its generator), the iscc identifier in its canonical form and the identities with the identity list that held each anchor.

The vectors.

• Good: bound-full (a soft binding, the ISCC identifier and the creator's identity over the hard binding, the actions, the WAI assertion and the soft binding), bound-two-identities (the publisher's identity referencing the creator's), bound-identity-only (the unmarked picture's store with one identity), bound-identity-deterministic (the same store with the identity signed over the payload's core deterministic encoding, the form a writer may ask for; every other identity of the corpus is signed over the payload's members in the schema's order, §4.10's default, and each accepted identity's signed says which), bound-iscc-binding (the first picture's store with its watermark's soft binding, the ISCC soft binding, the identifier and the creator's identity over the three assertions and both soft bindings), bound-iscc-binding-only (the unmarked picture's store with the ISCC soft binding alone: an Image-Code, a Data-Code and an Instance-Code) and bound-featureless-picture (a picture of one grey: the ISCC soft binding holds a Data-Code and an Instance-Code and no Image-Code, and the identifier holds the featureless Image-Code).
• An identity's signature is refused (identity_signature_mismatch) when it is the creator's under the publisher's certificates (identity-credential-swapped), over the payload's members in a third order, which is neither serialization of §4.10 (identity-signed-third-order), or over a payload with another role than the one the assertion holds (identity-signed-other-members).
• One negative for each reason of §7.2, and three of §7.1's credential_untrusted: a signer under an anchor no list holds, an anchor its list withdrew, and an anchor whose trust starts after T; each name says its defect.
• The ISCC soft binding's negatives, iscc-binding-*: computed from another envelope; its Data-Code the envelope's and its Instance-Code that of the envelope with one bit changed, which iscc §5 would match and §6.2 step 11 refuses; a unit missing; units of 64 bits; a featureless Image-Code included (iscc_mismatch, each); its sequence cut by a byte; its value the sequence's text; no generator; a second ISCC binding; the ISCC binding before the watermark's (manifest_malformed, each); and the watermark's robustness claim named as its own (soft_binding_unevidenced).

Provenance. wai_c2pa_identity_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 four test anchors; the lists are the corpus's own; the pictures are rings and ramps the generator draws, two of them marked with wai-mark:tent64, and one picture of a single grey, each written as PNG by the packaging corpus's still writer, so each store states the source type algorithmicMedia. The robustness record's table is the harness's (robustness-evidence §6), run over the two unmarked pictures, and is reproduced by anyone who holds them.

Checked by. wai_c2pa_identity_vectors verify and tests/c2pa_identity.rs in wai-rs (every file regenerates byte for byte and no other is here; every vector gets its outcome; every reason of §7.2 refuses one), and ../c2pa_live_verify.py, the second implementation, written from the extension's text, which reads the lists and the identity assertions itself, detects the mark with _wai_mark.py, verifies the robustness evidence with robustness_verify.py and recomputes the ISCC units with iscc_verify.py, requires every mutated copy of a good vector to be refused, and requires every one of its own checks, dropped, to be caught.

Read by a C2PA SDK's validator. Every good store here that carries an identity assertion is given to a C2PA SDK's validator beside its envelope, with the certificates of the vector's trust lists as its anchors for claim signers and for identity credentials, by the test the_sdks_validator_accepts_the_stores_the_store_writer_writes of c2pa_emit::identity_corpus (wai-rs, features c2pa_emit,c2pa_envelope; it runs in the conformance workflow's c2pa-emitter job). Of each store whose identities are signed over the schema's order the validator's state is trusted, it reports the claim signature validated, the data hash matched and no failure code, and for each identity assertion cawg.x509.credential.trusted, cawg.x509.signature.validated and cawg.identity.well-formed. Of bound-identity-deterministic it reports cawg.x509.signature.mismatch and nothing else: that validator does not verify the core deterministic encoding (c2pa-binding §4.10). It reads the claim, the hard binding, the hashed URIs and the identity assertions; the soft bindings, the ISCC assertions and WAI's own assertion it carries as assertions whose hashes it checks and whose content it does not judge.