[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 #10 from David Dorwin <ddorwin@google.com> ---
I mostly agree with what Mark says in Comment #1 and Comment #5. I also believe
that the current spec addresses most of the issues and use cases he discusses
or can be easily extended to address specific needs.

For example, I don't necessarily object to a mechanism to retrieve stored
session IDs from the CDM or even searching for sessions in other ways. Although
all such proposals have been associated with eliminating sessionId, I think
that's achievable in the current model if desired.


(In reply to Mark Watson from comment #1)
> 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 ?

An important clarification on the second sentence:
In the current model, the application doesn't really prevent persistence of a
license that requests it. Instead, the application tells the user agent and CDM
what it expects and prevents incompatible licenses from being requested (and
issued).


The normative, transparent, and interoperable |sessionType| value allows the
user agent to make decisions and provide proper responses early. Among other
things, this prevents the server from issuing an unusable license. (If an
unusable offline or key release license is issued, the CDM would need to
immediately reject it and make sure a "release" receipt reaches the server or
the user might lose some rights.)

sessionType also serves as a check that the application and server are in
agreement. While one might assume this to be true, I have seen such
misconfiguration (of a PlayReady server) in production. This may be
increasingly likely when multiple different license servers are being used.

An application's use of a persistent session type is also an acceptance of
responsibility that does not come with use of temporary session(s). For
example, managing key release messages or calling remove(). This is another
reason that simply giving applications "the ability to identify and remove
persistent licenses from the CDM license store" after the fact is insufficient
- applications that don't care about or expect licenses to be persisted won't
be designed to clean up persistent licenses.

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

Received on Thursday, 2 October 2014 02:19:58 UTC