[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 #25 from Joe Steele <steele@adobe.com> ---
(In reply to Mark Watson from comment #24)
> (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.

I am not clear why the initData would not reference both keys? In a case where
separate keys are used for separate bitrates, I expect both keys will be
referenced in the initData and both would be found via the local lookup.
Otherwise I would expect that different bit rates would have separate initData. 

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

That is an optimization we should allow for, but I don't see why this needs to
be explicit in the spec. I don't believe everyone manages adaptive content keys
in this manner. If other retailers want to comment on this, it would be useful.

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

Received on Tuesday, 9 December 2014 21:59:34 UTC