[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 #17 from Mark Watson <watsonm@netflix.com> ---
(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.

Ok, this a good example, but is it different in character from the case where
the initData in a video file also contains the key ids for the associated audio
? We have said that the application is supposed to know what to expect in this
respect, because it has metadata about the content that tells it what to
expect.

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.

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

Received on Monday, 10 November 2014 17:12:03 UTC