c2pa-binding §4.9: a store of wai.asset.c2pa may carry the envelope's ISCC as the C2PA soft
binding io.iscc.v0 of IEP-0020, beside the identifier: the Image-Code of the envelope's picture
(where it is not featureless), the Data-Code and the Instance-Code of its bytes, with the
generator named in bindingMetadata. It has its own assertion shape and its own verify step: the
units are computed again from the envelope and the binding is held to them, each equal
(iscc_mismatch); it is the last of the soft bindings (manifest_malformed otherwise) and names no
robustness claim (soft_binding_unevidenced).
iscc §5: matching compares a binding's Data-, Text-, Audio-, Video- and Meta-Codes with the
asset's unit of the same type where the validator holds the input, under a threshold for each
type, the decision in integers; a pair of Meta-Codes is reported and never a match.
iscc §4.9: IEP-0002 was read. The meta element is read as a data URL (RFC 2397, base64) or a
JSON object in the JSON Canonicalization Scheme (RFC 8785), numbers as ECMA-262 writes them,
computed exactly; the text says where the IEP is silent or differs from the public vectors.
tools/wai_iscc_unicode_tables.py pins the SHA-256 of the tables it writes; --check and
tests/iscc.rs hold the committed tables to it, and CI runs both. No runner image carries a
Python of Unicode 17.0.0, so CI checks the pin; a Python that does also regenerates.
Corpora c2pa-identity/ (three good stores and eleven negatives more; the vectors it held keep
their bytes) and iscc/ are regenerated; c2pa_live_verify.py and iscc_verify.py compute all of it
again and drop each new check in turn.
Co-Authored-By: Claude <[email protected]>
fdf3243521