Re: Request to add parameters to createSession (bug 17660)

This seems like it would encourage fragmentation across key systems,
which would compromise the usability of the spec for authors.

I'm not sure I understand the reason authentication or other side
channel information couldn't be obtained through more standard means
(e.g. credentialed XHR or query parameters). Further, it seems that
this would not afford any additional protection against client-side
manipulation or forgery. The only effective difference between passing
information in the proposed manner and passing via standard means
appears to be that the former is proprietary to a particular key
system. Is there another motivation for this change which I'm not
seeing?

Our current prototypes have thus far been successful in remaining
format- and key-system-agnostic except in the places where such
parameters are directly required. We do this by wrapping all license
requests and responses in a JSON envelope on an HTTPS request that
provides a consistent, cross-environment, cross-key-system approach to
common tasks such as credential verification, descriptive error
signaling, and request retry. This has greatly simplified our
application infrastructure and license server interface. I would very
much like to maintain that simplicity, and I suspect that the proposed
change would lead us away from that.

On Mon, Oct 15, 2012 at 1:40 PM, Joe Steele <steele@adobe.com> wrote:
> I reopened this bug a few weeks ago because I would like to see a mechanism
> for passing application level parameters down into the CDM when the key
> session is created.
>
> As I said on on of the recent calls, my reasoning is that some CDMs may
> transmit authentication/authorization data in-band (that is via CDM-specific
> mechanisms).
>
> An example of this would be:
>
> <script>
>   function handleKeyNeeded(event) {
>     var video = event.target;
>     var initData = event.initData;
>     var appData = { username: "foo", token: "A53DF98700ABFE11",
> sessionNonce: "DJKGDH+!9861XxbODY1287x===" };
>
>     if (!video.keys)
>       video.keys = MediaKeys("com.example.somesystem");
>     if (!video.keys)
>       throw "Could not create MediaKeys";
>
>     var keySession = mediaKeys.createSession(mimeType, initData, appData);
>     if (!keySession)
>       throw "Could not create key session";
>
>     keySession.onkeymessage="handleMessage(event)";
>   }
>
>   function handleMessage(event) {
>     var keySession = event.target;
>     var message = event.message;
>
>     var xmlhttp = new XMLHttpRequest();
>     xmlhttp.open("POST", "http://.../getkey", false);
>     xmlhttp.send(message);
>     var key = new Uint8Array(xmlhttp.response);
>     keySession.addKey(key);
>   }
> </script>
>
> <video src="foo.dash" autoplay onneedkey="handleKeyNeeded(event)"
> onkeymessage="handleMessage(event)"></video>
>
>
> The appData parameter would be optional and NULL by default. CDM's which do
> not handle this parameter could simply ignore it if passed.
> This is a use-case which would be used by at least one content protection
> mechanism today, possibly more than one.
>
>
> Joe Steele
> steele@adobe.com
>

Received on Monday, 15 October 2012 23:20:57 UTC