Re: Digests, signatures and chunk extensions

On 02/12/2022 11:47, Lucas Pardue wrote:
> While MICE might require that a tree of parts constructed over a 
> complete resource, I'm not sure if Sam's use case requires that 
> property. Instead a similar but simpler "progressive integrity" 
> content encoding (PrICE), where the content self-describes part 
> boundaries and their digests without chaining, might fit the need. The 
> benefit of including this type of thing inside the content encoding is 
> that it can pass across intermediaries and HTTP versions without 
> having to worry about re-encoding chunks or adding new frames.

This is a really good point.

And to address another comment made in reference to my use case and how 
you wouldn't use this for live streaming, we as a broadcaster may use 
3rd parties to help deliver our content. Some of these 3rd parties may 
be CDNs that we have a commercial agreement with, others may be just 
consuming our content (manifests, media segments) and offering it via 
their own system, or perhaps being distributed by means outside of a 
traditional HTTP connection [1][2]. The authenticity can travel as 
metadata along all these chains, be it as a HTTP Content-Digest and 
Signature pair, or some other mechanism.

In this age of deepfakes et al, the ability to prove the authenticity of 
media objects that are notionally coming from $Broadcaster$ actually are 
coming from them is seen as a valuable commodity. And at the same time, 
we're under pressure to reduce the latency incurred by adaptive media 
streaming, so we really need a solution that can do both.

Insert joke about the PrICE being right here...

Best regards,
-Sam

[1]: 
https://www.etsi.org/deliver/etsi_ts/103700_103799/103769/01.01.01_60/ts_103769v010101p.pdf
[2]: https://dvb.org/?standard=native-ip-broadcasting

Received on Friday, 2 December 2022 17:01:14 UTC