[Bug 25218] Allow license management directly via MediaKeySession

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

--- Comment #6 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #5)
> (In reply to Joe Steele from comment #0)
> > We have been having a lot of discussion about how key lifecycle should be
> > managed. I will throw another proposal out there which can meet all the
> > needs I have heard expressed so far. 
> 
> Can you be more specific about the requirements this addresses? I'm assuming
> these are related to the key chaining and domain key scenarios.

The current loadSession() and remove() APIs do not discriminate between content
keys and non-content keys. This proposal should allow applications which need
to load keys or remove keys to do so without impacting other keys that may be
present as a side effect of requesting the content keys. 

> 
> EME is currently designed around key sessions, which represent "the lifetime
> of the license(s)/key(s) [they] contains and associates all messages related
> to them." This proposal seems to be a departure from that. An API could be
> designed around keys, licenses, or something else, but that is not currently
> the case with EME.

Yes. This proposal is attempting to rectify an issue arising from the current
definition of key session, namely that content keys and non-content keys are
lumped together. 

> 
> Some potential issues:
> * Are loaded/queried keys really part of the session?

Loaded keys would become part of the session they are loaded in. Queried keys
may be part of the session, or may be available for loading into the session. 

> * What if they are associated with a persisted session ID?

I don't think the idea of a persisted session id is useful, so this is
independent of that concept. 

> * What if that key is contained in a license that contains other keys? 

I would expect that a license provider which needed to release keys would not
bundle keys corresponding to unrelated key IDs in the same license. 

> Are they loaded too?

If the license contains keys corresponding to multiple key IDs I would expect
only the key corresponding to the key ID being loaded to become available for
decryption. 

> What if only one of the keys is released?

I would expect releasing a key ID to be equivalent to releasing a license,
which would free any keys in that license. 

> 
> Does this proposal really solve the underlying requirements or use cases?

I believe so. This allows for applications to release individual keys based on
key ID and get appropriate notifications. This allows for non-content keys
acquired during a session to be ignored by the application. 

> Are there ways to achieve the same goals without effectively adding a second
> set of APIs? 

This proposal replaces loadSession() with loadKey() and release() with
releaseKey(). 

The only additional api would be queryKey() which would allow applications to
manage key/license storage rather than delegating it to the CDM. It would be
useful for the Ultraviolet use case, but could be handled separately if we
decide not to support that use case.

I am open to other suggestions. 

> If the application needs to know about the different keys anyway, why not 
> put them in different sessions and figure out a way for them to interact?

The problem is that the session can also contain keys acquired in order to
unwrap the content keys. Since the application does not know about these keys
(and should not) the application has no way of knowing to acquire them in a
separate session. I will send out some sample key flows as I see them which
should explain the issue better.

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

Received on Monday, 7 April 2014 22:58:12 UTC