[Bug 25218] Allow license management directly via MediaKeySession

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

--- Comment #20 from David Dorwin <ddorwin@google.com> ---
(In reply to Mark Watson from comment #19)
> > > 
> > > 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.
> 
> Ah. I had imagined that such a bootstrap step would take place the first
> time you tried to play back content. The session would be created using the
> initData and the bootstrap would take place together with or before the
> license exchange.
> 
> My assumption here is that such bootstrapping is needed only once when the
> CDM is first used and perhaps once each time any persistent store is cleared.
> 
> If you have a bootstrap step which is needed for every browsing session,
> this is a different matter.

I agree with what Mark said above.

> Still, it is not clear to me that because a keymessage response does not
> contain any content keys this is not compliant to the specification. There
> are any number of error cases where the keymessage response does not contain
> any content keys. In your example, the keymessage contains all the content
> keys identified in the initData (i.e. none).
> 
> Also, it's not clear that releasing this 'bootstrap' session would release
> the bootstrapped state. In fact I would assume it would not. Same as if the
> bootstrap was done at the beginning of a 'real' session, that state that it
> establishes is still available to future sessions.

Agreed - the bootstrapped key would *not* be considered part of the session and
you would have a compliant real session containing the content key(s).

This also happens in the background without the application needing to know the
details of a specific implementation of a specific key system.


If an application wanted to implement a key-system specific optimization for
the very first playback on a subset of platforms, it seems what you really need
is one of the following:
1) MediaKeys.bootstrap() to do the one-time non-session-related work.

2) To know whether this process has already occurred.
If not, you could initiate a dummy license request to cause the bootstrapping
to occur. The resulting session would be a compliant session but with a useless
license based on the initData provided.

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

Received on Wednesday, 30 April 2014 22:20:36 UTC