Meeting minutes
Introductions
Chris: Welcome,
especially to Andy and Leonard. I wanted to organise this,
following the presentation
… Andy gave to DASH-IF, where the question arose
about browser integration, particularly for
… video streaming on TV devices which have more
limited compute capacity, and so would a native implementation be
beneficial
… So I'm interested to hear your thoughts on that,
and how C2PA works and potential impacts.
Andy: I run the Content
Authenticity Initiative at Adobe
… C2PA is a Linux Foundation project. I represent
Adobe on the steering committee
… I oversee our open source efforts at CAI. It's a
free implementation of the C2PA spec
Andy: And implementations in Adobe tools, which are based on the open source
Leonard: I'm the CAI
architect for Adobe, and chairing the technical work at C2PA
… I represent Adobe at W3C
Content Credentials
Andy: There's an open source DASH player
Slideset:
https://
Andy: I'll give some background on what Content Credentials is, then Leonard will describe the specs in more detail, and potential next steps at W3C
Andy: Two images:
generative AI, fake or synthesized photos, are a thing to be
concerned about
… The images fooled forensic experts for a
while
… Around the same time was a photo of the Pentagon
on fire, moved the US markets briefly
… C2PA, understanding image and video provenance as
a fundamental building block
… We've been working on it for 4 years. The spec is
moving quite quickly
Andy: It seeks to
address the problem of video, audio, image transparency. C2PA
doesn't concern itself with detection. Detecting manipulation by AI
or other means is an arms race
… We have engagement with policymakers on what
regulations should require
… Education about why it's important, how it works,
and what it's not. Not about truth, it's about context and trust.
Lock icon in the browser
… Show where things came from
Andy: Facts about how media was made. Cryptographic data bound to the device, no PII. Editing in Photoshop or Premiere, capture details about what was changed
Andy: Details about who
published it might be captured, in a C2PA extension
… We'll focus on news, but also applies to creators
who want to indicate they don't use AI
Andy: CR symbol may
soon be as recognisable as the copyright symbol
… Level 2 overlay, click to show the provenance
chain
Andy: There's UX
guidance, the approach to video (uses video.js and dash.js),
there's a blue segment, then it turns red, to show it's been
tampered with
… The manifest contains the data. Election
integrity
Andy: CP2A steering
committee members. It's a real SDO, under the Linux JDF
… It has the W3C IPR policy, and open as we can
be
Andy: Google and OpenAI
joined, more interesting ones to come
… v2.1 draft is soon to be published
Andy: Published a
whitepaper in 2020, describing the basis. Then C2PA was formed,
aligned on not inventing multiple standards
… Last year, implementations, e..g, from Leica,
on-device signing. Others from Sony, Nikon. Microsoft election
integrity product, to let candidates sign content
… News from social media companies. OpenAI
implementation for DALL-E and SORA
… Browser integration critical for next stage of
deployment
Leonard: The spec is
for content credentials - this is the end-user term. The internal
term we use is 'C2PA manifest'
… We're at v2.1 spec in public review. Three
reasons we went to public review. There are significant changes in
2.1 where we want public feedback
… Also feedback from orgs like W3C. I talked with
Dom at W3C to figure out what that process will be
… We're discussing doing a formal TAG review, and
how it fits into the web, securely, philosophically
… Enable us to come together to solve
provenance
… Taking the standard through the ISO fast track.
It'll be like Unicode and ICC Profiles, where C2PA will continue to
maintain the standard and ISO will publish
… Group meets in November, when we'll have v2.1
final
Leonard: Before
defining the spec, we set design goals
… These are the key ones. Don't invent anything
new, use existing standards. Don't require cloud storage, or even
being online
… Also applies to digital ledgers or blockchains,
we're agnostic
… It has to work across the history of an asset,
multiple tools and vendors. Has to work for all asset formats:
audio, video, images, documents, AI models
… It's being used in areas we didn't envision,
supply chain data, also financial groups who see it as a general
mechansim for establishing provenance of something
Leonard: Core
technologies we built on: JSON-LD, CBOR, CMS (digital signatures),
COSE. Also JUMBF from JPEG, universal box format. It's a
BMFF-compatible serialisation model for extending JPEG, but
format-agnostic
… That's how we bundle the data in a C2PA
manifest
Leonard: Let's look
inside a manifest. There's a manifest store: one or more manifests
that describe the history. Each has 3 major chunks: assertion
store, claim, claim signature
… Box structure. Example UI shows data from the
manifest, let users understand the provenance
… Assertions are individual pieces of information.
Hard binding, hashes, how to securely bind the manifest to the
content
… There are 4 or 5 hashing methods, depending on
the format. For BMFF or other boxed based formats, like RIFF or
TIFF, we support a box-based hashing
… For BMFF you can say which boxes are included and
which are excluded. Works nicely for non-fragmented MP4 or small
assets
… When there are multiple mdat boxes (pre-computed
data that's streamed, come to live streams later)
… It allows you to have hashes of smaller chunks,
per the DASH demo earlier, you can show per-chunk whether it's
modified
… If relevant, you can add actions, which tell the
user what took place: was it created from scratch, what edits took
place
… Ingredients, where you compose assets from
different assets, e.g., bringinig in audio, video,
captions
… Each ingredient could have provenance, so you get
a tree through each to the final asset
… If you go to contentcredentials.org you'll see
examples
… Other kinds of metadata. XMP, IPTC, metadata,
include in the tamper-evident package
… All the assertions are individually hashed,
included in the claim, with info about the claim generator (the
hardware or software that does this job)
… Then sign with an X.509 certificate. You have a
merkle tree, hashes of hashes, in the JUMBF serialisation, and
embedded in the asset
Leonard: There's
functionality specific to generative AI. Identify whether the
entire asset or a portion of it came from gen AI
… IPTC source type, regions of interest (spatial or
temporal)
… You can be specific, e.g., Adobe has an AI that
does lip-syncing and translations, so you can identify that gen AI
was used, and to do the lip-sync and not anything else
… We have ingredients and recipes. A prompt,
information about the model, and the tools used
Leonard: In C2PA we
focused on the how and not the who - the camera, software tools,
this is the recipe for how the manifest came to be
… Info about human and organisation identity was in
the 1.0 standard, based on W3C verifiable credentials
… We didn't have the expertise. So we partnered
with CAWG, it's separate, not affiliated with C2PA, but we have
good relationship
… They focused on org and human identity problem in
the C2PA ecosystem, things connected to authorship and
ownership
… There's a "do not train" assertion, also in
CAWG
… CAWG focuses on the how and now who
Leonard: Trust model,
X.509 certificates, same as the web and PDF. Same algorithms, SHA
hashing, elliptic curves, etc
… We've extended with hardware attestation, as
creation can be done in hardware, on camera, or Google Pixel
phones
… We need to make sure hardware devices can have
secure attestations.
… There's also soft bindings to address
durability
Leonard: C2PA has its
own trust list, like there's a trust list from the CA Browser
Forum
… IPTC and Project Origin has its own trust
list
Leonard: If all data is correct, the manifest is well formed, if it passes the trust list, it's valid
Leonard: Put all this
together, you have trust signals. It's not binary, not true or
false. Each person makes their own trust decision
… As a human, look at the information, and decide
if you trust the asset. This is key to our thinking
Leonard: We support
many file formats. Lots of work done in video and imaging, but
audio less so. We want community interset, support for audio
formats
… Can be referenced in the cloud, blockchain,
DLT
… Link headers in a HTTP request to
connect
Leonard: We're working on durable content credentials, to discover removed credentials
Leonard: Core spec is
normative. We have 8-10 informative docs, from task forces
… Andy chairs the conformance TF, we have one on
AI/ML, another on live video, actively working
… Watermarking, and user experience
Ver. 2.1 Guidance & Informative docs
Leonard: Extensions: CAWG, IPTC
Discussion
Francois: You mentioned focusing on how, not who. If BBC produce a media asset, they describe how the asset came to be, but how is it tied to BBC?
Leonard: C2PA focuses
on the core spec. Other groups build extensions for the C2PA
ecosystem. One group is CAWG, building the identity component
… It will incorporate the identity, so BBC would
use their credentials (verifiable credentials or X.509) to
establish their identity
… There are representatives from BBC working in
CAWG on this.
Leonard: Identity is key, but C2PA wasn't well set up to do it, so left that to CAWG
Andy: Think of these in combination: C2PA trust list, ensures conformance, then the identity is added and takes responsibility for signing. Both signatures are bound to the asset
Kaz: Thank you for presenting. C2PA can handle live streaming, the mechanism supports chunk by chunk?
Leonard: You can do individual chunk-based manifests, it's heavy but doable, but we think one manifestfor the whole streaming data
Alicia: You mentioned policy. Would help to understand the goals, what are you looking for from them?
Andy: C2PA isn't a
policy-making organisation, but we are called on to give input.
Regulators see value in this. But we tell them it's not a panacea,
so we explain what it isn't more than what it is
… Catalysts to make this ubiquitous. Browser
support, mobile device support, and policy makers for AI, as
watermarking not enough. NIST in the US, there's an executive order
to figure out standards to apply to AI and the disinformation
problem
… When provenance is required, on AI transparency,
we want legislators indicate this is the standard to
adopt
Leonard: We're not
pushing, but there to support. EU has text and data mining
requirements, so W3C has a TDMRep group. That group and us have
been helping EU to describe the concept of opting-out from AI
training.
… We participate as one of many, to help
policymakers understand, define terminolgoy for their
needs
Andy: Social media is another catalyst
Alicia: You mentioned mobile devices. Is that like browser support, in applications, new metadata captured in all pictures? What are the implications?
Andy: It's
privacy-preserving metadata
… Someone with a C2PA device, can provide data from
moment of capture. But doesn't imply that gets used for all
capture, it's opt-in
Alicia: Authors proving something not made with AI? Sounds like proving a negative, how does it work? Could be a picture of a picture
Leonard: The user
doesn't state they didn't use AI, they used what type of camera,
etc, was used. EXIF isn't tamper evident
… Nothing is tamper proof, so we say tamper
evident
Alicia: You're putting trust in technology for what's really a social problem
Leonard: It is a social problem. If you trust a news source, you trust their video, but if you don't trust them, this technolgy won't create the trust
Chris: You mentioned the trust model is based on the same approach as the web. But it has different roots of trust, compared to the web PKI, with CA Browser Forum?
Leornard: We've been trying to use the same model, just has different trust anchors.
Chris: And then with CAWG and presumably other industries creating their own trust anchors, there's a combinatorial issue.
Leonard: C2PA is the
only required list, other browsers may choose to support others.
Within C2PA we've talked about potential uses in different
industries, each with its own trust roots.
… But everyone has to do the 'well-formed' part,
but the signer may not be one we recognise. So if BBC isn't in the
main list, we can show it's from them but can't verify it's from
them. It's not perfect but helpful.
Chris: What would be the next steps? You mentioned the TAG review, should we wait on the outcome of that? It seems straightforward to look at where the potential integration points in the web platform are, e.g., embedding images, MSE for video playback, etc. A document that captures all these questions and considerations could be useful.
Leonard: Nobody is thinking about APIs, even exposing EXIF or IPTC metadata has been controversial. I think this might be worthwhile, possibly as input into the TAG review. Also DASH integration, what does it mean for the Web?
Chris: You mentioned considerations for audio, what's needed there?
Lornard: It's more format related than anything. For MP4 we looked at regular vs fragmented MP4. We don't have the equivalent for audio, e.g., how does it work for MP3 or FLAC?
Alicia: MP3 is complicated, there is some hack, though, like using invalid packets. This is how ID3 tags work.
Chris: How much of the
provenance detail should a user interface show to be understandable
for regular people? There could be a lot of detail in the
manifest.
… If it's summarised, who decides what's included
and the level of detail, does the creator have any control over
this? From a browser integration, is it something that's left to UI
decisions, or specified?
Leonard: We've been
very clear that creator has no control, for security purposes,
etc.
… We don't want to mandate something that may not
fit the verifier's UI experience. Instragram displays differently
to TikTok, and LinkedIn.
… They choose how to display. Browser is a
different question, do they get flexibility.
… There are at least 3 browser plugins already that
integrate C2PA. One from Truepic, Digimarc, Microsoft. It's work
looking at those
Alicia: How does the 'who' work? What could the user see, e.g., imagine watching a YouTube clip of the news?
Leonard: C2PA itself is
focusing on "how". https://
… It's one way to present the information, not
mandated. An ingredient image may have no credentials.
… We can see how it was modified, e.g., using an AI
tool, color adjustment.
… "Issued By Adobe" means it's an Adobe
certificate. We're moving towards having a "Produced by Photoshop"
certficate, and working on the terminology.
… Everything is opt-in except the hash.
Leonard: Regarding "who", the CAWG is working on that. Verified by Verifiable Credentials or social media accounts.
Alicia: If someone signs an image, how is that done? I'm concerned by the "Issued by Adobe" part.
Leonard: They way it
will work, Adobe will have Photoshop as an implementation, we'll
send it to the conformance lab, verify it complies to the standard,
then it will be issued a certificate by the CA, which goes with
Photoshop.
… We make it so it's not easily extracted, but
that's an implementation choice. If you have an OSS implementation,
we wouldn't issue a cert to all of GIMP, for example, but each
user's GIMP. We're working through the specifics.
Alicia: Makes more sense to have a cert issued to a person's instance?
Leonard: We're not
issuing individual users a cert. It would be issued to Photoshop,
not your copy of Photoshop.
… The difference between Photoshop and GIMP is that
only Adobe can produce a Photoshop binary, whereas anyone can
produce a GIMP that's modified.
… Better to store in an HSM in the cloud, so the
cert is secured that way.
Alicia: And for using an individual identity?
Leonard: If you verify with Adobe, you could potentially upload your credentials, then Adobe Cloud could include them. Or any other company, with their products, could do that.
Chris: We're over time, so thank you to Leonard, and you all, for staying to continue the discussion. Let's keep in touch to figure out the next steps.
Leonard: Please reach out me if you have any questions
[adjourned]