W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Encrypted Media proposal: Summary of counter-proposals

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 9 Mar 2012 09:52:49 +1100
Message-ID: <CAHp8n2kW3Q=wbvYr3uiS-whDM-nhZS2mJyA2=DGzdMVo=EfoJQ@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Mark Watson <watsonm@netflix.com>, Henri Sivonen <hsivonen@iki.fi>, "Tab Atkins Jr." <jackalmage@gmail.com>, Christian Kaiser <kaiserc@google.com>, "<public-html@w3.org>" <public-html@w3.org>
On Fri, Mar 9, 2012 at 9:46 AM, Charles Pritchard <chuck@jumis.com> wrote:
> Regarding: document.getElementById("video")
> .getContext('experimental-ecmd').generateKeyRequest("org.w3.clearkey",
> null);
> On 3/8/2012 1:19 PM, Silvia Pfeiffer wrote:
>> I like this idea a lot. It introduces a generic way to plug extensions
>> into the video and image (and presumably the audio) element with
>> functionality that is chosen through extra mime type parameters. I would,
>> however, suggest not to use "audio/mpeg+keysystem" as the mime type, but
>> rather mime type "audio/mpeg; keysystem=xxx".
> I agree, that is a better use of mime type.
> Here's how I see it playing out across uri, css, dom and xml:
> On the Hixie uri prefix proposal, I'd see: "enc:<keysystem>;key=<optional
> key>,iv=<optional initialization key>:<url>"
> Hixie's proposal serves different needs than the Encrypted Context.
> For the first keysystem, "http".
> The http keySystem processes the Content-Type of the url and uses that as
> the key system attribute.
> For the second keysystem, "aes".
> Hixie's AES block cipher proposal with multiple key lengths.
> For the third keysystem, "chacha",
> From the ChaCha20/20  variant of eSTREAM Salsa20; the basis of the BLAKE
> entry to SHA3.
> The fourth keysystem, "org.w3.clearkey",
> From the Encrypted Media Extension proposal.
> The fifth keysystem, "org.w3.securekey",
> Pass it off to the OS client certificate system to figure things out.
> For example, OSX has keychain.
> The sixth keysystem, "com.netflix.honorarymention",
> From the Encrypted Media Extension proposal, with actual CDM negotiation.
> The enc prefix helps with shorthand static content, like CSS:
>    url(enc:org.w3.securekey:http://cdn.example/encryptedfile.png),
>    url(http://cdn.example/unencryptedfile.png),
> As an example of CSS use, the author could swipe a card and the CSS would
> swap over to encryptedfile.png.
> For DOM, it'll save unneeded requests:
> var a = new Image(); a.src =
> "enc:org.w3.securekey:http://cdn.example/encryptedfile.png"
> For HTML,
> <video><source src="http://site.com/cdmprotected.file" type="video/mpeg;
> keysystem=com.netflix.honorarymention"><source src="loading.mp4"
> type="video/mpeg" /></video>
> <script>video.getContext('experimental-ecmd')...</script>

So, hmm...

if you retain the addition of the keysystem and key in the URL for CSS
and JS, I wouldn't want it moved to @type in HTML media element

Received on Thursday, 8 March 2012 22:53:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:21 UTC