[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 #3 from David Dorwin <ddorwin@google.com> ---
(In reply to Jerry Smith from comment #2)
> We believe the license server model is not just valid, but likely the
> superior approach to managing persistent data.

How is it superior? I expected this claim to be supported below. As described
below, I believe this model actually seems to create more problems than it
addresses.

Regardless of the methods and identifiers used:
* The application should control whether data is persisted because it is
responsible for managing it once persisted.
* The UA should be able to disallow persistence (i.e. in private browsing
modes).
* Behavior should be deterministic and consistent.

Separately, I've been thinking about private browsing modes and how the UA can
support "stateless" licenses while rejecting other types of requests. (In some
cases, pretending to be stateful is bad for the user because, for example, it
can use up device counts or license counts (key release case).) It's not
possible for UAs to address such scenarios if they have no control or insight
into whether a session will use storage.

|sessionType| is also useful because it allows CDM implementations to generate
different requests if necessary.

> At some point, we do need to address Mark’s comments about Ids, and the
> ability to group Ids under a single identifier for convenience.

What type of IDs would be grouped? Key IDs? Stored IDs? I think Mark's use case
is 1:1 for license:storage. The need to group (key?) IDs in the proposed case
seems to be a symptom of a problem.

> 1. We should delete sessionId and related operations from the spec.
> 2. Sessions themselves should be limited to coordinating messages, nothing
> more.

Does this mean there could be multiple licenses per session? Could
generateRequest() be called multiple times per session? If so, does the session
concept have any value in this model?

> 3. The license server model gives apps plenty of control over persistence
> and secure release.  The first will be based on a transaction that the app
> will often initiate, and the latter will likely be baked into the general
> operation of some websites.  In both cases, the app doesn’t need to enable
> data storage.  The CDM should accommodate the storage requirements of the
> license and use persisted licenses automatically for playback.

My point is that the app SHOULD control data storage just as it does for all
other web APIs.

"[Using] persisted licenses automatically for playback" essentially means that
persistent licenses are added to a key pool, which will be used for all
subsequent playbacks.
Issues:
* That should be clear from the API.
* This takes control away from the application, which may actually wish to
fetch a new license.
* ow is the application supposed to know what to do when it gets an "encrypted"
event? (This event is generated by the UA and has no information about the
available keys. Also, initData does not necessarily identify all the key IDs
the application would fetch.)

Automatic use also creates API problems (as long as we have the concept of a
session). The CDM could use keys without a session being created. If use of a
key/license triggers a message, there would be no session to send it to. If
there are multiple sessions, how would the CDM decide which to send the message
to?

> - Add a method to enumerate specific types of Ids from the CDM.  This could
> be keyIds or something else.  The app should know the type of Id it is
> retrieving.

It sounds like you're talking about license management based on key ID. This
and the issues it presents have previously been discussed in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25218#c17

Another alternative, retrieval via Initialization Data, is also problematic as
previously discussed in
http://lists.w3.org/Archives/Public/public-html-media/2014Jul/0030.html

> - Add a method to prepare the session to operate on a returned Id.  This
> would not imply that the session has been fully prepared for playback, but
> that it is positioned to handle messages related to a specific Id.  The
> primary action that would be taken on returned Ids may be remove.  Retain
> the current remove for that purpose.

I would assume that all IDs retrieved above can be use to "prepare". That means
other keys could be affected, there could be multiple licenses with the same
ID, etc.

>   interface MediaKeySession : EventTarget {
> 
>   Promise<bool> prepare(DOMString storedId);
>   Promise<void> remove();
>   }

Is prepare() the equivalent of the current load() method except that it doesn't
load keys for playback?

Would prepare() work the same as the current generateRequest() and load() where
the result is that the MediaKeySession now represents the |storedId|? If not,
remove() would not be sufficient as defined.

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

Received on Monday, 29 September 2014 20:25:01 UTC