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

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

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

Received on Tuesday, 2 December 2014 23:13:39 UTC