fdf3243521
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]>
67 lines
5.1 KiB
Markdown
67 lines
5.1 KiB
Markdown
# live-conformance/iscc — ISCC content identifiers
|
||
|
||
The corpus of [`extensions/iscc.md`](../../extensions/iscc.md) §6: the ISO 24138 codes WAI computes,
|
||
held to the standard's public test vectors, and WAI's own cases of pre-processing and matching.
|
||
|
||
**Files.**
|
||
|
||
- `public.json`, not generated: the public test vectors, one case to a line, whose SHA-256 the
|
||
extension pins. Its `image`, `audio`, `instance`, `code`, `seq_encode`, `seq_decode`, `data`,
|
||
`video`, `text` and `meta` sections are transcribed from the ISCC reference implementation's
|
||
conformance data, version 1.5.0 (a JSON file whose SHA-256 is
|
||
`1609adb921983baf83f9aaf049ab8dc23f828c214f57c29e2bf852346c678eff`, published under the Apache
|
||
License 2.0 by the ISCC Foundation): each case's name, its inputs (a 32 × 32 grey picture, a
|
||
Chromaprint fingerprint, bytes in hexadecimal, units, frame signatures, a text, a name with a
|
||
description and a meta element) and its expected output. A `meta` case's `meta` is the meta
|
||
element as the source file gives it, `{"dataUrl": …}` or `{"json": …}`, the JSON object as the
|
||
text the source file writes it in; its `payload` is the bytes §4.9 reads of it, in hexadecimal,
|
||
which for a JSON object are the bytes the source file's own output states; `metaRead` is that
|
||
output's `meta`, the data URL; and `titleRead`, `descriptionRead` and `metahash` are its `name`,
|
||
`description` and `metahash`. Its `iep20_*` sections are typed from IEP-0020 §10.1 and §10.2 as fetched on
|
||
10 November 2026: the four-unit sequence with its bytes, canonical form and base64, Table 2's
|
||
sequences a decoder refuses (each with the table's reason), the sequence it accepts, and Table
|
||
3's featureless Image-Codes with their bits set per segment.
|
||
- `vectors.json` and `pictures/`, written by `wai_iscc_vectors gen` from fixed seeds: each
|
||
picture's size, the SHA-256 of its 32 × 32 picture (§4.3), its Image-Code of 256 bits and
|
||
whether it is featureless; `thresholds`, one for each type that can be a candidate match;
|
||
and each match of a soft binding (`binding`, an ISCC-SEQ in hexadecimal) against an asset: its
|
||
bytes, a picture's PNG (`asset`) or a `buffer` by `length` and `seed` with the bytes at `flip`
|
||
complemented, and the inputs the validator holds for it (`text`; `audio`, a fingerprint;
|
||
`video`, frame signatures by `frames` and `seed`; `seed`, a `title`, a `description` and a
|
||
`payload`), under the case's own `thresholds` where it states them, with what §5 states:
|
||
`exact`, `matched`, `score` and each pair compared; and the generated cases of §4.6 to §4.9: `data` (a buffer by `length`
|
||
and `seed`, its `chunks`' lengths and its Data-Code), `video` (frame signatures by `frames` and
|
||
`seed`, and their Video-Code), `text` (a text, its `collapse`, its `characters` and its
|
||
Text-Code) and `meta` (a `title`, a `description` and a `payload`, what §4.9 reads of them, the
|
||
`metahash` and the Meta-Code; where the case gives a meta element, `meta` as above, the
|
||
`payload` read of it and `metaRead`, its data URL), every code of 256 bits; and `metaRefused`,
|
||
meta elements §4.9 refuses, each with its `reason`.
|
||
|
||
**Equivalence.** A conforming implementation computes every public vector's code, refuses or
|
||
accepts every sequence as stated, and gives every picture and match the values `vectors.json`
|
||
states (§6).
|
||
|
||
**Provenance.** The pictures are ramps, discs and bars the generator draws, written as PNG by the
|
||
packaging corpus's still writer; one is the first picture with one pixel altered after a binding
|
||
was computed from it, and one a single pixel.
|
||
|
||
**Checked by.** `wai_iscc_vectors verify` and `tests/iscc.rs` in `wai-rs`, and `../iscc_verify.py`,
|
||
the second implementation, written from the extension's text and the IEPs, which also requires
|
||
every mutated copy to be caught and every one of its own checks, dropped, to be caught.
|
||
|
||
**The four codes' tables.** The minhash, gear and winner-take-all tables are in the extension's
|
||
Annex A, transcribed from the reference implementation's source, version 1.5.0 (Copyright
|
||
2016-2026 Titusz Pan, Apache License 2.0), each source file named there by its SHA-256. The
|
||
Rust implementation holds them in `wai-rs/src/iscc/tables.rs`, and the Python one reads them
|
||
from the extension. The Rust implementation's Unicode data (`unicode_tables.rs`, of the Unicode
|
||
Character Database 17.0.0, Unicode License v3) is written by
|
||
`tools/wai_iscc_unicode_tables.py`; the Python one uses its own library's.
|
||
|
||
**Not cross-checked.** The JSON objects' payloads beyond the public vectors' four (the members'
|
||
order, the numbers' digits, the strings' escapes) are held to the two implementations here and to
|
||
RFC 8785 Appendix B's samples, which both replay in their own tests, not to another canonicaliser.
|
||
The pictures' Image-Codes, and so the matches of pictures, are WAI's pre-processing's
|
||
(§4.3); they are held to the two implementations here, not to another ISCC tool, whose
|
||
pre-processing differs (iscc §4.3). The public vectors are the cross-check of the transform, the
|
||
codec and the other codes. The generated texts' collapses are held to two Unicode libraries that
|
||
may be of different versions (iscc §4.7); they hold only characters assigned by Unicode 6.0.
|