[Bug 25218] Allow license management directly via MediaKeySession

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

--- Comment #17 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #16)
> One of my concerns is that there seems to be some disagreement about what is
> considered in the session. The spec
> (https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-
> media.html#dom-release) seems clear that the CDM has flexibility in deciding
> what is considered part of the session and what is not.

What specific text are you referring to? I don't read this algorithm that way.

<snip>
> My second concern is that even if we get agreement that the CDM can make the
> call on what is considered in the session and thus affected by loadSession
> and release(), the session is the wrong level of granularity. 
> 
> The session contents are CDM-specific by design. The KID is a generic
> well-known entity specified by the media format. It seems clear to me that
> loading and releasing keys should rely on the generic well-known entity
> rather than the more nebulous CDM-specific one. This would avoid the whole
> question of what is in the session.

Does it help to think of a session as a "license"? That seems like a well-known
concept. Or a "set of keys"? Since sessions are created from one set of
initData, each can really only have one "license" (at a time), though it can be
updated/renewed/replaced over time.

The problems with providing access by key ID include:
* It is necessarily unique like the session ID. (How does the CDM know which
session to load when provided a key ID?)
* The application may not know all key IDs contained in the session/license.
* If a session is loaded by a single key ID then destroyed, this may
(unexpectedly) destroys the license for other key IDs
* Modifying individual keys may not be supported by CDMs.


I don't think we've thoroughly explored the use cases and how these might be
resolved in ways that don't involve multiple types of keys/licenses in the same
session. Having a multiple licenses in a session and addressing each one
individually seems to defeat the purpose of having objects. I think we can
provide a better model for applications.

As an example, I don't think it makes sense for the result of the one-time
bootstrapping in comment #14 to be considered part of the session. Presumably,
the application never needs to manage such a key. However, something like a
domain license, which the application can join and leave, should probably be
exposed as its own session.

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

Received on Wednesday, 30 April 2014 21:28:34 UTC