[Bug 17750] Define the behavior MediaKeySession close() and clearing the keys attribute

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

--- Comment #33 from Joe Steele <steele@adobe.com> ---
(In reply to David Dorwin from comment #32)
> (In reply to Joe Steele from comment #31)
> > Having said this -- I don't know how I will support this yet. I am not happy
> > with the idea of tying a set of opaque key server responses to a session. It
> > is unclear how applications will be able to determine which sessions to load
> > or release without having visibility into the key server responses. This
> > either restricts the key server severely in what keys it can return OR it
> > places an additional burden on the application to be parse key responses to
> > determine exactly what it in them. I don't have a better proposal at this
> > point though.
> 
> What is "this" that you need to support? I don't follow this paragraph or
> how it relates to this bug and close().

The "this" I was referring to is "clearing keys associated with a session".
Once keys are persistently cached for Access DRM, you lose all concept of the
session they were retrieved in. 

Thinking through supporting this -- the CDM will have to persist the session id
along with any keys so it can look it up later to destroy it. My gut tells me
that content providers will either always use release() or they will never use
it. But since I can't be sure of that, I have to allow for both cases. This
means that I can't clear all persistent licenses I have when I see a release, I
have to be selective and clear just the ones tied to this session. And I have
to mark shared keys differently (per comment 18) to avoid clearing those as
well.

So just to be clear -- 
1) CDMs will have to store licenses in two groups segmented by session id and
no-session (i.e. shared). 
2) CDMs should abort any current request processes when close() is received
3) CDMs should clear licenses associated with the current session off disk and
in memory when release() is received.

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

Received on Monday, 31 March 2014 16:10:26 UTC