Meeting minutes
M&E IG Rechartering
<cpn>
https://
ChrisN: AC Review
closed at the end of the last week. 22 responses in total, with 19
expressions of support as-is.
… 1 reviewer suggested adding coordination with the
publishing activity.
… We're working through that.
Kaz: Main feedback point is that Publishing BG should be the focal point for discussions around publishing. I'll wrap-up the discussion with the commenter.
Multicast Receiver API
ChrisN: Working with
Jake on a charter for establishing a Community Group, following IG
discussions last time.
… More on that soon when the charter is
ready.
Next meetings
ChrisN: Check the slides for upcoming meetings, notably for the Media Timed Events Task Force.
Coalition for Content Provenance and Authenticity (C2PA)
ChrisN: Looking at the trustworthiness of content on the Web.
<cpn>
https://
Judy: My name is Judy
Parnall, colleague of Chris in BBC.
… C2PA is a group under the JDF (Joint Development
Foundation).
… For establishing content provenance
authenticity.
… So that you can actually trace the origin of
media.
… It was established a few years ago. We know that
there are or have been previous attempts at this area.
… This project came from two complementary
projects: Content authenticity initiative (digital media) and
Project Origin (news content)
… We realized quickly that we were trying to tackle
the same issue from a slightly different perspective.
… We're now tyring to establish underlying
standards.
… C2PA is generating specifications and standards
from workflows and requirements.
… We're expecting to develop best practices and
reference implementations for consuming organizations.
… We're trying to broaden the community coming
together.
Charlie: Charlie Halford, I work for BBC as well. Contributor to the technical group in C2PA.
<cpn>
https://
Charlie: Some of the
problems we see. Misinformation can be very subtle.
… [Showing examples: "£14 billion" and
"multi-billion", less subtle]
… Not limited to a particular
platform.
… Wherever there's an open distribution platform,
we see disinformation.
… We feel that media education should play a good
part, but the problem is that we are missing some signals at the
consumer level to help the consumer make informed
decision.
… In a messaging app, what kind of context could we
add? Can we mark it as genuine? What if we don't have any
provenance information? Can we mark it as well?
… We're not going to solve everything. We're hoping
that our platform can be built on by others.
… We're really looking for a positive signal. We
want to encourage customers to look at it.
… We don't want to send negative signals when
missing provenance information.
… Consumer should be able to know if the media
comes from a particular source. They should be able to see media
metadata, it should be possible to preserve the modification
history of an asset.
… And we really want to preserve anonymous
users.
… We're not trying to build DRMs. We do acknowledge
that metadata could be useful downstreams.
… We're not giving opinions on "truth" and on what
info to trust.
… We're really having this applicable across
industries: news, law enforcement, insurance, etc.
Leonard: I do not work for the BBC, but rather for Adobe. I'm the chair of the C2PA Technical WG.
<cpn>
https://
Leonard: Looking at
things that we're trying to build. Also want to raise a couple of
points on how we could/should connect our groups
… As you heard, focus is on attribution: who? what?
how was it done? etc.
… Basically, we want to create a simple structure
that stores the information in a cryptographically verifiable
structure
… All of this information is what is going to make
the provenance for that asset.
… We don't attempt to re-invent any wheel. We'll
only create new things in the absence of prior, battle-tested
techniques.
… We don't want to require cloud storage. We're
supportive of all sorts of techniques, including blockchain, but
won't require any of it.
… Agnostic of the client device, any kind should
work, and of formats, any kind (audio, video, 3D, etc.) should
work.
… Some key terms: "assertion" means statement that
is being made. There may be lots of them for a given
asset.
… These assertions are grouped together in a
"claim". There may be many claims over the lifetime of an
asset.
… A claim can be signed in a "claim
signature".
… And the whole thing gets represented in the
overloaded term "manifest"
… We use a lot of pre-existing technologies out of
the box: JSON, CBOR. We're a big fan of XMP (great open
standard).
… Standard cryptographic solutions such as CMS,
CAdES.
… We're using some in very unique
ways.
… BMFF for everything else.
… [explaining BMFF in JPEG]
… Attached to JPEG, to fragmented MP4, to PDF,
etc.
… There are lots of assertions, that can be fully
extended. ClaimReview comes from schema.org and you can use any of
it.
… We want to enable you to plug any data you want
into our system, and we'll take care of carrying it
around.
… [showing some assertion data examples: precise
location, camera data]
… Again, we use standard metadata
syntax.
… We're in the progress of defining what a claim
looks like, but here is an overview.
… Regarding content binding, that's one of the
areas where we want to work with this group.
… For hard-binding, two different types: file
offset based binding, useful for non-box-based formats such as JPEG
or PDF.
… You don't necessarily understand what they are
and cannot reorder things.
… Separate model to bind to specific functionality
to address situations where some boxes may change or be created
after the fact
… [peaking at hashing BMFF examples]
… [examples show how to leverage the fact that BMFF
is hierarchical]
… When we think about these scenarios, we're
thinking about videos, but also about modern image formats such as
HEIF, AVIF.
… They're constructed the same way, based on
BMFF.
… Issue arises about exposing the BMFF information
to browsers. For JPEG, and PDF, there are places where this can be
sticked to.
… Where do we put it in the BMFF-based
formats?
… One option is to create our own box.
… Another is to go through emsg boxes
… Advantages of emsg boxes: no registration needed
and more importantly, it aligns with HTML5.
… The problem is that this only works today in
video.
… That information is not exposed for
images.
… How do we get that same emsg box through the
browser pipeline into the web application.
… We're happy to start with BMFF based format, but
PNG, SVG, JPEG are not BMFF-based. How do we get that information
into the JavaScript?
… Biggest concern in terms of delivering it to
consumers.
… [showing example of boxes applied to an image,
signature, XML, JSON]
… The one area that we are not currently
addressing: live content. For example a sporting event. How do we
ensure that same authenticity? We're not going to deal with that in
our first batch of deliverables but we know that it's important to
address afterwards.
ChrisN: Thank you, let's open up for questions
Kaz: Thank you very much. There are several possible pieces within the W3C which could be kind of useful for this scenario. Verifiable Claims and Decentralized Identifiers come to mind for example. Also WoT Thing Description data model.
Leonard: I am also a member of the Verifiable Credentials and DID groups. I did not go into that level of details. We specifically support these technologies and are fully aligned.
ChrisN: Some of what you're describing here is embedded content. In the initial example that Charlie presented, it was more the web page.
Leonard: Right now, our
focus is on assets that are contained within a page.
… What we're hoping for when UA have access to the
info, is that it will be used to connect that to other mechanisms
for claim review.
… For instance, Google has already adopted
ClaimReview from schema.org as a way to express
claims.
… The UA could make at these two things and make
sure that they're aligned.
Charlie: Both of the examples I presented had a BBC UI on the right side. But the assets can be embedded in other contexts.
ChrisN: There was some
work some time ago in the Credibility CG, looking at signals that
could be used.
… No longer active, I believe.
Leonard: Right, there was a lot of activity and then it sort of died away.
<leonardr> https://
Igarashi: I am very
interested in this topic. Already read the C2PA whitepaper. Related
to Chris' question, how is that provenance signal used when the
media is displayed by the browser?
… You mentioned that JS could catch the event from
the emsg box. The C2PA whitepaper also describes the case of a
browser with extension that would show the provenance of the
media.
… Which is the most appropriate case?
<igarashi> I have a question on how a provenance signal for media is used when the media is displayed with the browser. The question is related to the use case of "For the case of the end users consuming content via a web browser," in the C2PA white paper.
<igarashi>
https://
Leonard: That's a great
question. The way that we look at it is that we're starting
something very new. The idea that you get some JS bridge is a way
to bootstrap the whole thing. We all believe that the end goal is
native support. That's the most secure approach.
… For things on the Web, as well as for things that
are off the Web.
… At some point in the future, we want to move in
that direction.
… Until we get there, we'll need to workaround
native support.
Igarashi: I have some concern that JS would show the information by itself. User may not trust the JS itself. The browser might be the right entity to show the authenticity information.
Leonard: You're certainly right. The idea is that the page is the host of the media, and you're trusting that host. For instance, you're browsing the BBC and thus trust BBC with the media experience and we can rely on TLS, etc. But that would remain JS, and native support would be better down the road.
Igarashi: Have there been discussions about these browser extensions? And JS API standardization?
Charlie: It would be
much better if we could standardize the API that we essentially
create in a browser extension. The extension intercepted the right
events and we created our own UI.
… The whole execution environment, the API, would
be much better if they were natively supported.
… I have done some prototyping work, but not with
the current C2PA specification.
Igarashi: If you have further information about browser extensions, please share.
Charlie: Certainly, I'll see if I can get a link.
ChrisN: Certainly,
having a JS or browser extension implementation is going to help
moving forward native implementation.
… It would prove the model.
Francois: Is developing a JavaScript API in scope for C2PA, or would you want to develop in W3C?
Leonard: It would have
to come from a W3C group, you're responsible for developing browser
APIs
… W3C is appropriate place for that. The
coordination between the groups is easy to do, happy to help make
that work
ChrisN: In the Color on the Web group, we've been talking about updating the PNG specification for instance. Do you expect changes to such format specifications?
Leonard: It does not
require changes to the PNG spec directly, but we do have a new type
of chunk defined.
… Question is could we get the C2PA chunk
standardized?
… Definitely a conversation that I plan on
having.
ChrisN: Regarding the
use of emsg. We've been working on that in this group. It would be
interesting to see how your use of emsg fits the processing model
that we're developing.
… There is existing support in media players for
surfacing emsg boxes.
… We're looking at native browser implementations
and if you're carrying the assertion information and signature in
the emsg payload, then that would be surfaced to the application
with our current model for it to process it.
… If you're thinking of native support, then that
ties in into that bigger process model that we need to
specify.
Leonard: One thing to discuss with this goup: is emsg only for video? Or does it apply to any BMFF-based format?
ChrisN: We don't own emsg per se in the group.
Leonard: but you own surfacing it to browsers
ChrisN: That's right.
ChrisN: How do we
continue the conversation around this?
… We could come back to it in a future
meeting.
… Or I may join C2PA on behalf of the IG to have a
discussion there.
Leonard: We are ready to engage whenever you guys are.
Kaz: We can hold dedicated calls between the MEIG Chairs and the C2PA guys like we did for the multicast discussion :)
ChrisN: OK, let's plan
to organize a follow-up to go in more details and compile a list of
questions.
… There may be other people from W3C to engage in
this discussion
… Thank you very much for joining us
today!