[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

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #1 from Mark Watson <watsonm@netflix.com> ---
We should consider what a superset of the different models (if they are really
that different) would look like.

On the one hand, the interaction between CDM and license server _must_ be able
to control:
- whether licenses are persisted across browser sessions
- whether key release messages are generated

On the other hand, there is a desire for the client side application to also
play a role in enabling persistence of any state (both licenses and key release
state), for the CDM state in these respects to be visible to the application
and for the CDM / application interaction model to be consistent across CDMs.
It is also necessary that we can associate key release messages with the
original session at the client, since server state needed to process those
messages may be stored on the client.

I think it's clear that the license server can require key release messages and
can prohibit license persistence. I do not see any harm in the client
application being able to prohibit license persistence either, though perhaps
it should not be able to prohibit persistence of key release information ?

As I argued in another post, we do need some concept on the API for a group of
keys that are related - specifically those keys that will be persisted or
released as a group. In the key release context, this has always been the
session, identified by the sessionId, since the very earliest key release
proposals.

We can certainly decouple the existing session from this grouping for release /
persistence purposes, making the existing session completely ephemeral, but
some form of identifier needs to be attached both to the original process that
delivered a license and the key release process.

Finally, a superset would provide visibility to the client application of what
the CDM is doing. If it is persisting the license, then the application should
be told of this and told how it can obtain the license again later (whether
this is by calling create with the same initData or load with some provided
identifier seems like a detail here). Equally, if key release information is
being persisted, the application should be made aware of this and given
instructions for how to obtain it later.

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

Received on Tuesday, 23 September 2014 15:01:50 UTC