Re: The role of MP4 pssh boxes in EME

FYI, https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027 is tracking the
definition of a generic Initialization Data solution for ISO Base Media
File Format and/or Common Encryption. This will be used for Clear Key, but
it could also be adopted or supported as an additional format by commercial
key systems.

David


On Thu, May 9, 2013 at 4:29 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Wed, May 8, 2013 at 5:49 PM, Mark Watson <watsonm@netflix.com> wrote:
> > However, most existing DRM systems need some kind content-specific
> > "initialization data" that is used to generate the license challenge
> message
> > and that contains more than just the KeyID.
> >
> > ISO defined the PSSH box to allow this initialization data to be
> embedded in
> > files.
>
> So looking at the PlayReady XML document in a pssh box and the JSON
> document (for another system? Widevine?) in another pssh box, they
> both carry the following data:
> Key ID - this should be covered by the CENC layer already.
> Algorithm being AES-CTR - this should be implied from CENC already.
> Key length being 16 bytes - this should be implied from CENC using
> 128-bit AES-CTR.
> Vendor being YouTube - surely YouTube doesn't tell itself that it's
> YouTube.
> Movie id - surely the key id should be unique within YouTube so that
> yet another id isn't needed for lookup; there are enough bits in the
> key id not to worry about collisions if the id minting is at all
> reasonable.
>
> Additionally, the PlayReady XML doc carries the following information
> not present in the JSON document:
> Checksum - dunno of what, but surely TCP has taken care of data
> arriving over the network intact.
> License acquisition URL - surely YouTube's JS code (hopefully served
> over https) should know the URL of YouTube's PlayReady server instead
> of relying on content (potentially served without https) telling it
> what license server URL to use.
>
> So all the pssh data look logically unnecessary to me.
>
> > It would be a good question to ask the DRM vendors whether they really
> > *need* this DRM-specific header, or whether they could also operate in a
> > mode where the Initialization Data contains only the DRM-independent
> Common
> > Encryption information (specifically the KeyID - which is specified in
> the
> > Track Encryption Box and cenc sample group descriptions).
>
> This list seems to have a pretty broad representation of DRM vendors
> these days, so let's ask here:
>
> DRM vendors, what do you need the pssh data for (in the EME case where
> presumably YouTube's JS app knows the URLs of YouTube's license
> servers and presumably Netflix's JS app knows the URLs of their
> license servers, etc., and the Same Origin Policy would block access
> to random off-Origin license server URLs anyway [without CORS])?
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>