Leonard Rosenthol

@fmeschbe you are reading the wrong spec. The core JSON spec is [RFC 7159](https://tools.ietf.org/html/rfc7159) and the relevant section is [6](https://tools.ietf.org/html/rfc7159#page-6). There is very clearly says: > This specification allows implementations...

You should look at [pandoc](pandoc.org)

> the definition of the extraction tool/version is part of the normative specification Mandating a specific tool only works *if and only if* you also tie it to a version...

This is where standards such as XMP (ISO 16684-1), Dublin Core, EXIF, etc. come into play...

What about supporting multihash (https://multiformats.io/multihash/) which would (a) allow implementors to choose the right algorithm for their implementation and (b) support forward thinking (since all hashes will be broken at...

My point though @titusz is that there is already a standard for this - see my link in the previous comment. There is no reason to reinvent the wheel

What about defining the algorithm that would be used instead of a specific implementation? It would help to look at various binary formats and see what is the most important...

You need to be *very careful* about this from a PII perspective, as filenames are frequently loaded with information that may be personalized and could expose unwanted information.

As chair of the Technical Working Group for the C2PA, I fully support this proposal. (all conflicts of interest recognized ;).

To follow up a bit on one of @brogdonm 's comments... >C2PA is included in many different assets already. When looking at the [embeddable formats](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_embeddable_formats) in the C2PA 1.3 specification,...