[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 #24 from Mark Watson <watsonm@netflix.com> ---
(In reply to Joe Steele from comment #23)
> (In reply to Mark Watson from comment #22)
> > (In reply to Joe Steele from comment #21)
> > > (In reply to Mark Watson from comment #20)
> > > > (In reply to Joe Steele from comment #19)
> > > > 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.
> > > 
> > > But they are not the same. In the example of stream1 and stream2 that I
> > > gave, passing stream2's initData would only cause the keys for stream2 to be
> > > loaded. Not the keys for stream1, even though those keys were delivered in
> > > the same session. The same is true if stream1's initData was used to load a
> > > session later. This would not be useful in combination with key release, but
> > > would be very useful on its own.
> > 
> > In this case, there is a concept of key grouping that doesn't (yet) have a
> > name.
> > 
> > Let's assume the initData for stream1 contains key id X1 and the initData
> > for stream2 contains key id X2. To play stream1, the server knows that keys
> > X1 and Y1 and needed. To play stream2, the server knows that keys X2 and Y2
> > are needed.
> > 
> > So, what the server has returned are keys X1, Y1, X2 and Y2.
> > 
> > To satisfy your usecase, the client also needs to learn that these are
> > grouped: X1 with Y1 and X2 with Y2. So, then, later if an initData
> > indicating X1 is provided we retrieve from store both X1 and Y1, as the
> > server would have provided.
> > 
> > Likewise, if an initData indicating Y1 is provided we retrieve from store
> > both X1 and Y1.

Sorry, there was a typo there, if the initData indicates X2 then we should find
X2 and Y2.

> 
> Because the initData indicates what keys are needed to "satisfy" the
> request, the client can just use the initData for the content it is trying
> to play without knowing anything about previous sessions.

Not quite. More concretely, let's say stream1 is episode1 and stream2 is
episode2. Each episode has a SD version with key X(1|2) and an HD stream with
key Y(1|2).

So there are four files, four keys and four initData. The intention is that
given any one of the initData, you can get the keys for both the HD and SD
streams. Additionally, the server helpfully chooses to provide the keys for
both episodes.

To be able to look up the right thing from a single initData, the client needs
to know that X1 goes with Y1 and X2 foes with Y2.

> This will not
> negatively affect interop because the client can always try "loading" a
> session using the initData rather than creating a new session and forcing
> request/response network traffic if persistent keys may be in use. 
> 
> The CDM can succeed in loading the session with keys that match the initData
> it was passed, or it can fail to load implying that not enough keys were
> available to satisfy the initData requirements. In that case, the client
> just uses a newly created session instead. 
> 
> > 
> > We need a name for this grouping, otherwise we are not going to be to
> > specify interoperable behaviour. One is tempted to say "license" ...
> 
> I am also tempted. Key and policy bundle does not drop from the tongue quite
> as easily. 
> 
> > 
> > Unless, that is, we require that the initData identify all the keys needed.
> > i.e. the SD streams contains the key ids for both SD and HD streams etc.
> 
> It seems implicit to me that the initData refers to the keys needed for the
> content it is included in. But I don't see the need for it to require keys
> for other content.

It's always been my assumption that the initData refers only to the keys needed
for the individual file in which it is embedded (anything else complicates
packaging). But for adaptive streaming you need the keys for all the bitrates
of the same content and you want to get those in one server round trip.

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

Received on Tuesday, 2 December 2014 23:24:10 UTC