[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 #19 from Joe Steele <steele@adobe.com> ---
(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. 

(In reply to David Dorwin from comment #18)
> (In reply to Joe Steele from comment #16)
> 
> > Here is the example I tried to give in the TPAC --
> > 
> > The application tries to play stream1 and provides initData1. The CDM makes
> > a key request based on initData1. The license server returns a set of keys
> > that includes keys needed for stream1 AND stream2. Later on the application
> > tries to play stream2 and provides initData2. Without parsing the PSSH
> > boxes, the application has no way of knowing that it already has the keys
> > available. It could try to load all the previous sessions. Or it could call
> > generateKeyRequest(initData2) and make the unnecessary license request.
> > However if an API was available to load keys based on initData alone, the
> > CDM could make that determination and not require a license request.
> 
> It's unclear whether your stream1 and stream2 are for the same title or
> different title. We have given up on gracefully handling the former for the
> basic streaming case (bug 25268) and settled on requiring application or
> server logic. It's reasonable to expect that persistent licenses will
> require application logic, especially for such complex scenarios as
> different titles.

stream1 and stream2 are different titles. E.g. different episodes of a TV
series. 

> 
> In the different titles scenario, the application needs to do more of the
> work. This is already a complex application involving multiple (related?)
> titles and persistent licenses. The CDM should not be a replacement for
> application logic.

In general I agree here. Except that as I was attempting to point out, this is
logic that the CDM can potentially perform orders of magnitude more efficiently
than the application. 

> 
> In the current spec, the application would need to know that session "6789"
> contains the keys for stream1 and stream2. If we allowed initData to be an
> index, the application would need to know that it can load the keys for
> either stream using initData1. For this scenario, there isn't much
> difference.

I don't understand what "allowing initData to be an index" means. An index to
what?

> 
> However, "generateKeyRequest(initData2)" seems to imply that the CDM would
> crack open the initData to get the key IDs then look for these key IDs. I do
> not think we should add this complexity to the clients when applications can
> handle this themselves in an interoperable way.

The problem with generateRequest() is that it assumes a keyrequest will be
generated. Step 7 of the algorithm does not state what to do if the CDM
determines that a key request is not needed because the available keys are
already present. In that case, step 11 should not be called. If we were to fix
that (e.g. skip step 11 if step 7 does not result in a message being produced)
then the name of the method seems odd. It should be something more like
generateRequestIfNeeded. That would be a return to something more like
createSession() was originally (which I preferred).

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

Received on Tuesday, 11 November 2014 02:01:57 UTC