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

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

The corpus of [`extensions/c2pa-binding.md`](../../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.