Re: [Moq] [EXTERNAL] Re: Encrypted Media Metadata

[Ted Hardie <[e-mail]>]

Howdy,

Snipping a bunch to focus on thing:

On Thu, Jul 21, 2022 at 9:41 PM Deen, Glenn <[e-mail]> wrote:

>
> Metadata is any data that is not the core media data stream. For instance
> EIDR IDs for the content would be content data as could be things like age
> ratings date first released and even artwork for display in guides.
>
> Encoding data could be info about the encoded media. Remember the encoded
> media may be encrypted and so metadata is used to tell info about the media
> without requiring decrypting the media.
>
> The charter currently says:

The working group will define MoQ so that the media publication protocol
can leverage on-path relays, caches or replication points wherever
applicable to improve the delivery performance. Media will be encrypted,
possibly end-to-end encrypted for certain use cases. The keying mechanisms
for media confidentiality is however outside the scope of this working
group. Even when media is end-to-end encrypted, the relays can access
metadata needed for caching (such as timestamp), making media forwarding
decisions (such as drop or delay under congestion) and so on.

My understanding, though, is that the unencrypted metadata mentioned are
focused on those required for effective delivery; that's why the examples
in that section are timestamps and media forwarding based on congestion.
Unencrypted metadata about the content seems to me a different class of
data.  EIDR is, for example, basically a mapping to the content identity.
That data I would expect to be part of the encrypted part of MoQ for
privacy reasons; I'd expect the same for closed captions, for the same
reason.    To speak frankly, given the privacy concerns in relation to QUIC
(hello, spin-bit enthusiasts), I really don't see those being unencrypted
as likely to fly.

I propose we update this as follows:
OLD:

Media will be encrypted, possibly end-to-end encrypted for certain
usecases. The keying mechanisms for media confidentiality is however
outside the scope of this working group. Even when media is end-to-end
encrypted, the relays can access metadata needed for caching (such as
timestamp), making media forwarding decisions (such as drop or delay under
congestion) and so on.

 NEW

Media and content-specific metadata such as EIDR and age rating will be
encrypted, possibly end-to-end encrypted for certain usecases. The keying
mechanisms for their confidentiality is however outside the scope of this
working group. Even when media is end-to-end encrypted, the relays can
access metadata needed for caching (such as timestamp), making media
forwarding decisions (such as drop or delay under congestion) and so on.

That gets us a specific mention of the content-specific metadata, avoids
getting into a fight over privacy sensitive information, and re-confirms
that the metadata needed for forwarding decisions is available.

What do folks think?

Ted
>
>
>
> -glenn
>
>
>
> regards,
>
>
>
> Ted
>
>
>
>
>
> And add “metadata transport” as a bullet, so as to suggest that metadata
> is a first class data element being included.
>
>
>
> -glenn
>
>
>
> On 7/21/22, 2:16 AM, "Ted Hardie" <[e-mail]> wrote:
>
>
>
> Hi Glenn,
>
>
>
> I think I follow your core concern, but I'm a little confused about how to
> reflect it in the charter in ways that don't start to assume the solution
> space.  From your perspective are you looking for an elaboration to one of
> these bullets:
>
>
>
> The media publication protocol will be a push protocol for sending media
> including audio, video, and timed metadata, such as closed captions and cue
> points. The common protocol for publishing media over ingest and
> distribution will support:
>
> ·         one or more media formats,
>
> ·         an interoperable way to request media and encodings,
>
> ·         rate adaption strategies based on changing codec rates,
> changing chosen media encoding/qualities,
>
> ·         cache friendly media mechanisms
>
> So that they specifically mention the metadata in, for example, the bullet
> about requesting media and encodings?  Or are you looking to add a bullet
> here?
>
>
>
> If you have charter text in mind, or can develop some, that would be most
> helpful.
>
>
>
> thanks,
>
>
>
> Ted
>
>
>
> On Sun, Jul 17, 2022 at 2:10 PM Deen, Glenn <Glenn_Deen=
> [e-mail]> wrote:
>
> I get the sense from the proposed charter Media Metadata is currently
> treated sort of monolithically in terms of access to it, its
> encryptability, and its use in different workflows.  Metadata is quite rich
> as a part of the media delivery workflow and is getting increasingly
> important and extensive as media transport and media types evolve.  I
> propose that it needs more specific focus in the group.
>
>
>
> Metadata data and access to it is something that maybe should be
> considered a distinct type of media content on its own along with having
> distinct from the transported media authenticated access and encryption
> considerations that are independent of the media being transported.
>
>
>
> This could possibly be part of the “coordinated or cooperative” middle
> boxes that Lucas has mentioned in his not on the thread “Re: [Moq] "MoQ
> Architecture" question from Spencer's mail”
>
>
>
> Metadata should be more distinctly mentioned in the charter along with
> perhaps a couple of documents that specifically cover Metadata
> authentication and encryption and Metadata Use Cases by both end points and
> middle boxes.
>
>
>
> -glenn
>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/moq__;!!CQl3mcHX2A!EqjB0ptNCUvf7xVMkakLbxPdk_Gx4kKd1I17Jbo4Lq6nWX6RncjNeI9A4VKBUT10uMHrJ2ZWirqKdVczWg$>
>
> --
> Moq mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/moq
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/moq__;!!CQl3mcHX2A!CzxU8cpr_zzDMsnFPYMZkWSooAvTMCCaJJY_zf9GCnu8vkR2Ag2zSRflIyNP6T0VD3XODEt8Xov5WofwFXs$>
>