[Bug 26887] Allowing license servers and CDMs to control data persistence and secure release

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

--- Comment #20 from Mark Watson <watsonm@netflix.com> ---
(In reply to Joe Steele from comment #19)
> (In reply to Mark Watson from comment #17)
> > (In reply to Joe Steele from comment #16)
> > 
> > I think the model we have is as follows:
> > 1) initData maps to a set of key ids, but detecting at the application
> > whether two initData map to the same of different sets of key ids is
> > key-system specific / impossible
> > 2) at a given time the session can contain either
> > (a) the key ids obtained from an initData (it is waiting for a license)
> > (b) the key ids, associated keys and associated policy (it got a license)
> > (c) the key ids and proof of key release
> > 
> > It certainly seems convenient for the application if the CDM can
> > automatically retrieve any session it already has for given initData.
> > Retrieval of sessions by sessionId would then make sense only for:
> > (i) there are several sessions with the same key ids but different license
> > policy
> > (ii) to retrieve the key release information, where again there may be
> > several for the same set of keyids
> > 
> > Would it make sense to make session retrieval *always* driven primarily by
> > the initData / set of key ids, supplemented, when necessary by:
> > - which case you want (a), (b), (c) or "(a) or (b)"
> > - something to disambiguate for cases (b) and (c) between the multiple
> > possible sessions
> > 
> > The disambiguator here is like sessionId but scoped to sessions with the
> > same set of key ids.
> 
> I think we have different mental models here. By saying "retrieve the
> session" you are implying that the CDM is doing a lookup which results in a
> previously persisted session being loaded. That is not what I am saying. 
> 
> Assume that I have a database of persistent licenses. When update() is
> called on a persistent session, I add to that database. When remove() is
> called on a session, I remove from that database. When loadKeys(initData) is
> called on a new session, I look in that database to see if I have matching
> licenses. If I do, I add them to the session. If I do not, I fail. The
> session in this case becomes a convenience for holding transient state only. 

I think this is a distinction without a difference. Whether you think of it as
"retrieving a previously persisted session" or "creating a new session and
loading in some persisted state" doesn't matter if the end result, a session
containing the keys identified by the initData, is the same.

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

Received on Tuesday, 11 November 2014 02:11:09 UTC