[Bug 25218] Allow license management directly via MediaKeySession

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

--- Comment #8 from Joe Steele <steele@adobe.com> ---
(In reply to Mark Watson from comment #7)
> I believe that as far as the EME API is concerned, a MediaKeySession
> contains a content key or keys, each associated with a key id.
> 
> Concepts such as licenses and domains are not modeled in our API. I think
> the question here is do they need to be ? If they are not, this does not
> mean such concepts to do exist in any given CDM, it's just that they are not
> visible on the API and the CDM is left to do whatever it chooses with them.

The question of whether to model licenses and domains in our API is mostly
irrelevant to this issue. The issue I am raising can happen in the most basic
use case - a single encrypted stream being played back across multiple browsers
with license request every time. 

> 
> Specifically, I would expect that if a license is a vehicle for
> communicating keys to the CDM, then any given license remains in the CDM
> until all the keys that it contains are released, unless we explicitly
> expect the keys to be persisted, in which case the license may be persisted.
> Likewise, if a DRM has a concept of 'domain' and licenses are associated
> with domains then the state associated with a domain needs to live for at
> least long as the licenses associated with it, but again could be persisted
> for longer than that if the CDM chooses.
> 
> This is not to say a CDM MUST operate in the way described above: all we say
> in EME is that there are keys and key ids and they live in sessions.
> Everything else is up to the CDM.

By assuming that we can manage content keys effectively just by managing the
session (which the loadSession() and release() appear to do), we are assuming
that the session contains only content keys. If a CDM requires non-content keys
delivered within the session to function in even the most basic capacity, then
a CDM is forced to break compliance to function. 

My basic premise here is that there are REQUIRED keys other than content keys
that get delivered to the CDM via the update() mechanism. 

I see four options:

1) We can allow for managing keys directly rather than sessions. That is my
proposal above, which I do not believe introduces a lot of additional
complexity. This would also allow support for domains and key chaining in CDMs
that use them. 

2) We provide a separate set of APIs for downloading non-content keys. This
data would not be part of the media playback session. This would not support
key chaining or domains, since those would usually be delivered during a media
playback session, but it would support bootstrapping keys delivered at first
playback. I think this is a more complex mechanism. 

3) We allow the CDM to download keys either via a direct network connection or
via some browser specific mechanism. In either case the key acquisition is not
under control of the web application. This seems to be against the spirit of
EME. It would also introduce a non-deterministic element into the playback from
the applications point of view.

4) We can force some CDMs to behave in non-standard ways. This is the fallback
position CDMs will use if nothing else can be agreed on. I am trying to avoid
this as this will make it even harder to build cross-browser implementations.

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

Received on Tuesday, 29 April 2014 17:04:04 UTC