[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 #9 from Mark Watson <watsonm@netflix.com> ---
(In reply to Jerry Smith from comment #8)
> Reply to Mark:
> 
> Are keys used in a session the grouping you really want?  I would think
> you’d want to group key data by a given show or movie that was watched. 
> Secure release would then need to associate some collection of licenses and
> data with that show or movie, and confirm that it was securely deleted, and
> the pipeline that used it securely terminated.  I don’t think
> MediaKeySessions map very cleanly to this.  Do they?
> 

The lowest level grouping is really a license and this is the granularity we
expect for secure proof of key release (unless we had to extend the secure
proof concept to multi-use licenses, which is complex).

I generally assume one session <-> one content item.

> My thought on reusing a persistent license was that the session would be
> initialized with initData, but that the persistent license would be found
> and no messages exchanged.  A keychange (or keyfound) event would be fired
> after the stored keys were loaded.  This wouldn’t require initializing the
> session with IDs from the persisted license itself.

Yes. What I meant above was that both this model and the app explicitly
providing the list of key ids would be supported.

> 
> If multiple valid licenses are stored for a given keyId, then the first
> found might be used.  This assumes that we don’t have a specific scenario
> that cares which license is used.  I’m not sure exactly how this case could
> be created.

It is easy to think of examples where multiple license are present for the same
keys with different properties (e.g. limited viewing 'preview' licenses and
normal ones), but I agree it is not obvious why you might want to store more
than one kind across browser sessions.

> 
> If there are multiple secure release records, would the app not want to
> complete them all before proceeding?  That too assumes there is not a need
> to be specific on completing some secure releases, but not others.  Would it
> be valid for an app to first start playback of secure release content, and
> then go looking for old sessions not released?  That could mix the current
> session in with the old ones.

We only get persisted secure stop information if the regular secure stop
process doesn't complete before browser shutdown. So, to get more than one
ssecure stop information for the same key you would need multiple playbacks in
progress at the same time with the same key.

For our part, we do have use-cases for picture-in-picture with multiple
simultaneous playbacks, but this is always of different content items and
different content items always have different keys in our system. It's not hard
to imagine someone using the same key for multiple content items, though: for
example the same key for some group of related short clips (e.g. news).

We have these corner cases because key id is not really a unique identifier for
the thing we want to refer to, which is a license (in the persistent case) or a
use of a license (playback session) for secure key release. SessionId stands in
for both of these in the existing specification.

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

Received on Wednesday, 1 October 2014 21:22:50 UTC