[Bug 25218] Allow license management directly via MediaKeySession

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

--- Comment #18 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #17)
> (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.

>From algorithm step 1.2.1:
Note: the release() method is intended to act as a hint to the user agent that
the application believes the session is no longer needed. ** However, the CDM
determines whether resources can now be released. ** 

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

A CDM would not load a session when provided a key ID. The CDM would load a
cached key based on the key ID into an empty session created by the
application. 

> * The application may not know all key IDs contained in the session/license.

This is why I like your proposal in bug 25409. This would provide exactly the
information the application needs. 

> * If a session is loaded by a single key ID then destroyed, this may
> (unexpectedly) destroys the license for other key IDs

I would not expect the CDM to load a "session" which could contain multiple
keys, but instead load a single key into an empty session.

> * Modifying individual keys may not be supported by CDMs.

I am not sure what this means. If you mean that a CDM may not support splitting
out keys into separately loadable chunks, that could be a problem. 

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

Even in the absence of multiple keys or licenses in a session, I don't think
that the session is the right way to model this problem. I think if we say
session==license we will paint ourselves into a corner. 

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

The application may want to manage it in the scenario I described above. If the
application wants to hide the cost of acquiring such keys while the user is
doing media selection for example, it would start up a session using some
generic initData and close it once those keys are acquired. However that
session does not contain any content keys and would therefore be not in
compliance with the spec's definition of a "session". That session should also
never be released or at least the application should not expect that releasing
it will have any impact.

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

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