Closed hackerfactor closed 2 years ago
lrosenthol
commented
2 years ago Remove the XMP dependency.
We have done that (made it optional instead of required) in the upcoming revised draft.
That said, however, the way you detect any type of JUMBF block in an APP11 marker is by the UUID of the outermost JUMBF superbox. This allows for a JPEG-1 file to contain multiple JUMBF-based extensions such as JPEG-360 + C2PA or JPSec + JLink.
lrosenthol
commented
2 years ago @hackerfactor can you review the 0.8 draft that is online and make sure that you are OK with the fix for this?
lrosenthol
commented
2 years ago The solution for this has been included into the upcoming 1.0 specification. Thanks for the recommendations.
lrosenthol
commented
2 years ago Published.
The JPEG standard expects APP segments to be application dependent and defined per environment. https://www.w3.org/Graphics/JPEG/itu-t81.pdf Section B.2.4.6, PDF page 48 / spec page 44.
The basic intent defines independence between APP blocks:
If you don't know how to handle a specific APP block, such as the "ICC_Profile", then you can ignore it when rendering. Rule: All APPs are optional. Exception: JPEG's APP14 "Adobe" may be required for the color transformation definition.
If you don't handle EXIF, then you can still handle the ICC_Profile, JFIF, or other APP blocks that you do support. Rule: APP blocks are independent. Even if EXIF or XMP mentions that there should be an ICC_Profile, the ICC_Profile block is not required. Exception: Adobe's XMP includes checksums that cover other segments. For example, XMP:tiff:NativeDigest and XMP:exif:NativeDigest contains a checksum over the EXIF block.
(Not to point fingers at Adobe, but the only exceptions that I can recall, where the APP doesn't follow the independence set by the standard, comes from Adobe.)
The problem: In the C2PA draft spec, there is a dependency between the XMP and JUMBF app blocks. XMP:dcterms:provenance points to the JUMBF provanence record. If you don't see this record, then you don't know if the JUMBF contains a provanence record or if it contains other JP2K data.
My recommendation: Remove the XMP dependency. Instead, have a well-defined top-level JUMBF record that defines the first provance claim in the chain. If you want to evaluate the provance, then you just need to handle one type of APP block -- the JUMBF -- and only if it has the flag that denotes the start of the provance chain.