Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 17 Packages Wiki Activity Actions 108
open-standards/wai/live-conformance/iscc/README.md
Transaction Science fdf3243521 ISCC: the io.iscc.v0 soft binding in a C2PA store, matching on every code, the Meta-Code held to IEP-0002, and the Unicode tables pinned 
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]>
2026-11-10 22:36:11 -05:00

5.1 KiB
Raw Permalink Blame History

live-conformance/iscc — ISCC content identifiers

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