[Bug 24082] Several issues discussed in the TF point to the need for defined extensibility points in EME

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082

--- Comment #4 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #1)
> I will provide some examples, since I raised this initially. The use cases
> that I am concerned about all involve passing information that is not known
> at the time the content is being packaged and therefore will not be part of
> the initData. 
> 
> I see two major areas here:
> 1) Information/instructions required to playback
Should "playback" be replaced with "acquire a license"?

The examples below all seem related to authentication and authorization. From
the EME Abstract:
“The common API supports a simple set of content encryption capabilities,
leaving application functions such as authentication and authorization to page
authors.”

> 2) Information/instructions to manage cached state
These sound like control messages, which are different than the message passing
of update() and keymessage. I don’t think extending createSession() and/or
update() is the right solution for control messages.

> Some examples of #1 are:
> - in-band authentication, where the authentication tokens are carried within
> the key request protocol
Can you provide more details? What authentication tokens? Where do they come
from? How is this different from the third item below?

> - domain join requests, where the domain being joined is selected by the web
> application
How do domains work in an interoperable way and within origin boundaries? (It's
probably better to discuss this in a separate thread rather letting it get lost
in this bug.) What parameters are necessary to join a domain?

> - web application authentication tokens
Do you mean cookies or the sign-in tokens that might be stored in them? If so,
why do these need to be passed to the CDM, especially when the application is
going to end up sending the message to the [license] server.

> Some examples of #2 are:
> - clear all cached state
Can you give an example where the application would need to do this? Couldn't
it just release() the sessions it knows about?

> - domain leave requests, where the domain being left is selected by the web
> application
Can you provide more details? (Again, probably in a separate thread.) Why
doesn't release() work?

> It is desirable to be able to perform some of these operations prior to
> actually playing content, for example while the user is selecting a movie,
> in order to reduce the time to starting playback. However since the actions
> being requested may require network communications, it may make more sense
> to hang this additional parameter off of the createSession() call instead of
> the constructor to avoid adding another call/response channel directly to
> the MediaKeys.
What specifically is missing? We have release() (and the ability to respond
with messages) and loadSession(), so is it the creation that's a problem?

> I would imagine performing a domain join using this mechanism to look
> something like this:
> 
> var extra = { 'action':'join', 'domain':'Lambda Lambda Lambda' }
> var mediaKeys = new MediaKeys("com.example.cdm");
> video.setMediaKeys(mediaKeys);
> var session = mediaKeys.createSession("video/mp4", initData, extras);
Do you really want to combine a domain join request with the processing of meta
data? Aren't these two separate operations, possibly with separate "sessions".

> The structure of the extra parameter can be completely CDM specific. If it
> is passed when not appropriate, it can be completely ignored. If a
> particular entry is not understood, we can decide whether that means an
> error or not. I am not sure where that error would go, but it would be
> useful to have an error thrown.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 3 March 2014 22:54:57 UTC