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

We need a name for this grouping, otherwise we are not going to be to specify
interoperable behaviour. One is tempted to say "license" ...

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.

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

Received on Tuesday, 2 December 2014 00:26:37 UTC