[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 #18 from David Dorwin <ddorwin@google.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.

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.

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 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.

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.

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

Received on Monday, 10 November 2014 19:48:50 UTC