Attendance:

Guests:

• Leonard Rosenthol, Adobe Senior Principal Architect / C2PA Technical Working Group chair

Discussion:

• Introduction to CAI & C2PA - presentation by Leonard Rosenthal, C2PA 

  • Related issue: https://github.com/AcademySoftwareFoundation/openexr/issues/1497 

  • Slide deck download link: https://github.com/AcademySoftwareFoundation/openexr/files/12433844/Intro.to.CAI-C2PA.pdf

  • Misinformation is rampant in today's world.

  • AI generated media, outcry related to being able to identifying 

  • Worldwide legislation is being put into place

  • 2 Entities 

    • C2PA - standards body

      • LF Joint Dev Foundation project

      • develops specifications.

      • Membership: Intel, Sony, MS, Adobe, etc...

      • Liaisons with various standard bodies ISO, etc...

    • CAI Content Authenticity Initiative - responsible for building tools

      • focused on education and implementation

      • Membership: over 1700 entities, incl. media outlets, news outlets

  • 3 foundation Pillars

    • Provenance

      • not guess what is fake, provide information about what is truth

      • another signal for detection: who, what, where, why, how

    • Education

    • Policy

      • work with governments and industries

    • Do not do detection

      • do not believe this is a viable solution

  • Design goals

    • Create minimum novel technology, rely on existing tech

    • Do not require cloud storage or distributed blockchain

    • Maintain audit trail across multiple tools

    • Work on all standard asset formats

  • Specification v1.3 available online : https://c2pa.org/specifications/

  • CAI 

    • Open source SDK, used by many software and hardware vendors

    • Adobe, Microsoft, Nikon, Sony

  • C2PA Specification

    • Model for storing information in cryptographically verifiable and tamper-proof package

    • Digitally signed, connects to a defined trust model.

    • Core components in "blob" 

    • C2PA Manifest Store / Content Credentials

      • Box based data format (JMBF - jpeg metadata box-based format)

      • Assertions

        • various facts or statements such authorship

        • Content bindings - cryptographic hashing

        • Creative work, Actions (what user did), 

        • Ingredients, Thumbnails, and more

      • Credentials 

      • Data Boxes - additional information

      • Claim 

      • Claim signature

      • Manifest - verifiable unit

  • Nick: does the hashing/cryptography introduce any international concerns - 

  • Leonard: no, hashing does not introduce any issues

  • C2PA Manifests

    • Can refer to external assets and data

    • C2PA manifests can be embedded into many image, videos, audio and document formats

      • images: jpeg, png, gif, webP, avif, heic/heif, tiff, dng, svg

      • videos: mp4, mov, avi, bmff

      • audio: flag, mp3, wav, bwf

      • docs: pdf

    • Can be stored anywhere but embedded is preferred.

    • Each step of process can create a manifest - e.g. Creation, Editing, Publishing, Sharing, Viewing

    • final asset may have multiple assets which represent the history of the asset

  • Establishing a Trust Model

    • Modelled on same approach to trust as PDF and the Web

    • Doesn't matter if certificate expires, matters if it was valid when you used it

    • Enhancing Trust with Trust Signals, trust isn't binary, it's contextual

• Q&A

  • Kimball's question: OpenEXR relatively dependency free, is it possible to implement authentically without introducing a new 3rd party dependency or implement in our code tabula rasa?

  • Leonard: would not recommend doing the cryptography and digital signatures on own, otherwise everything else can be implemented anew in the library

•  

  • Larry: what is the current implementation in?

  • Leonard: available in Rust and in JavaScript - secure, easily deployable across clients and servers, also builds as a library with C and C++ bindings.

•  

  • Nick: USD will transitively take on dependencies introduced into OpenEXR - would not be good to introduce Rust toolchain dependency.

  • Leonard: we are interested in connecting with USD, aware of 2 proprietary C++ implementations so it is doable. Crypto though should depend on another library

•  

  • Larry: the OpenEXR is basically a format, does it just need a way to store a manifest in the file metadata or...

  • Leonard: MVP would be read/write blog into OpenEXR file, standard mechanism for hashing the data in the file. Don't have to do that in your library just would save library users the effort. The rest is C2PA specific, could be ignored and left to client. Client makes it, OpenEXR facilitates sticking it into the file. 

•  

  • Larry: wonder what the current format will allow us to do. When do we have to do the hash, you give all the metadata then you send the pixels, then compress. 

  • Leonard: in other cases, do a 2-pass operation, create the metadata block leave a hole then create the file. Can figure out the size of the manifest ahead of time, size of compressed blocks.

•  

  • Nick: how does authenticator understand that manifest has been inserted

  • Leonard: In addition to hash there are the ranges that the hash covers. Lists the bytes that it has hashed. Manifest does not have to be in a particular place in the file. Each format defines where to find it in their format. 

•  

  • Larry: OpenImageIO high level, the complexity sort of explodes at this level. Not altering the image... many innocuous thing that copy pixel verbatim from one to another. Copy file, leave pixels identical, change the compression. Would have to be rerun and added to the manifest. At what level should the logic live, when do have to regen a manifest. What lives in OpenEXR library, what lives in OpenImageIO library, etc...

  • L: no single answers. Common metaphor that most use today: abstract out the file format -  get all the manifest data, client doesn't worry about the formats. Client has the manifest of file when opened, then maintains its own "working store", user saves (or does other finishing operation) - take original manifest, all the other data, feed it back into library requesting new manifest for the file.  

•  

  • Nick: if USD has common metadata location and name but doesn't know how to create it, package asset, feed it into another program to add the manifest then produce the authenticated asset.

  • L: that's what is done in other formats as well. Didn't have to modify the other formats. No way to do arbitrary binary blobs in OpenEXR, which is why Leonard reached out. We do this with fonts, adding provenance to fonts, internal guts are in C2PA then working with OpenType committee to standardize where the blob will be found in the font formats.

•  

  • Larry: storing and naming blob is easy part, need a way to tell OpenEXR library and tell me the offset, where is it located, what is the span. Currently not a way to get that out of the EXR library. Some modifications will be needed in the API to be able to pass requisite information.

  • Nick: could be more metadata, write in the location and length. Would be great to facilitate this in OpenEXR format.