MEIG monthly call 1 June 2021

01 June 2021


Barbara_Hochgesang, Charlie_Halford, Chris_Lorenzo, Chris_Needham, Francois_Daoust, Gary_Katsevman, John_Riviello, Judy_Parnall, Kaz_Ashimura, Kazuhiro_Hoya, Leonard_Rosenthol, Nigel_Megitt, Pierre-Anthony_Lemieux, Takio_Yamaoka, Tatsuya_Igarashi
Chris_Lorenzo, Chris_Needham, Tatsuya_Igarashi
cpn, tidoust

Meeting minutes

M&E IG Rechartering

<cpn> https://docs.google.com/presentation/d/1mbEN8lzSOgkRDJsa3xeRSL1HpUQlg_x6p3RBdGgsP-0/edit <- Chris's slides

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://www.w3.org/2011/webtv/wiki/images/2/2f/C2PA_introduction.pdf <- Judy's slides

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://www.w3.org/2011/webtv/wiki/images/5/50/W3C_presentation_-_reqs_pub_v2.pdf <- Charlie's slides

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://www.w3.org/2011/webtv/wiki/images/5/5c/C2PA_for_MEIG-opt.pdf <- Leonard's slides

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://www.w3.org/community/credibility/ - CredWeb

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://drive.google.com/file/d/11c41iTwq7z-nMMMPQLE5GZ6gJmc_llJ1/view

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!

Minutes manually created (not a transcript), formatted by scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).