[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 #6 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #4)
> (In reply to Joe Steele from comment #1)
> > 1) Information/instructions required to playback
> Should "playback" be replaced with "acquire a license"?

Yes, but I want to be clear that this is not information necessarily associated
with a specific piece of content. 

> 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.”

This would in no way remove control from the hands of the page authors. It does
remove some of the constraints around how authentication and authorization are
conveyed to the server.

> 
> > 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.

These are control messages from the application, not from the server. And these
are specifically control messages which should require user interaction.

> 
> > 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?

This is an example I raised before in meetings. In the Access ecosystem, which
handles standalone applications as well as web-based ones, authentication
tokens (username+password, etc.) can be captured by the application and
included in the license request. This way they are encrypted by the DRM
subsystem and are not subject to in-transit attacks. I don't want to argue the
merits of point-to-point SSL versus message-based encryption here. We can take
that offline. My point is that this is something we would like to support.

> 
> > - 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?

This is a long discussion and mostly captured by other threads. The parameters
required in this case would be the domain name, a user-friendly name to
associate with the application/device and potentially authentication tokens. 

> 
> > - 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.

I don't mean cookies specifically, although I suppose you could use it for
that. The example I was thinking of was one-time fields in the page associated
with the cookies. If they are sent to the server inside the license request,
they can be signed/encrypted using the DRM sub-system which allows the server
to then double-check them against the cookies or headers received. I can think
of other examples as well. 

> 
> > 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?

Yes. If the user is on a public computer and wants to clear any cached state
before leaving. Releasing the sessions will not necessarily clear cached data. 

> 
> > - 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?

This is related to cacheing. It may be costly to join a domain (in terms of
user  time and/or effort). Therefore it makes sense to cache the results once
you have done it. It does not make sense to throw that work away just because
the user has left the page or closed the browser. 

> 
> > 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 was responding to the extra parameter being on the constructor, rather than
on the createSession() call itself. The constructor may be called prior to any
content being downloaded, so a key session may not be created. Since for some
of my uses cases, I need network communications, I need a key session. Am I
mistaken? I think with an extra parameter in both cases we are covered.

> 
> > 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".

In our case the information about the domain to be joined is carried in the
metadata. So it must be processed at the same time. That metadata may be
entirely independent of a content stream however. 

> 
> > 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 23:58:34 UTC