Re: EME compatibility with existing DRM systems

On May 7, 2013, at 10:57 PM, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Tue, May 7, 2013 at 6:58 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:
>> There is one question that came up during the webinar regarding whether a
>> Key System implementation is "allowed" to interact directly with a DRM
>> server, without going through the user agent and application with a
>> keymessage event.
>> The speaker's response was that he wasn't sure whether it was specifically
>> forbidden or not, but that he couldn't see why it would be needed.
> 
> Doing so would clearly go against the fundamental design of EME and
> fail to benefit from the design of EME. The main benefit being that
> when key server communications go from EME to JS to XHR (and back),
> the user's session cookie goes along the XHR communication, so there's
> no need to build a second session management mechanism for the DRM
> system.
> 
> So that's a benefit for cases like Netflix where there is a concept of
> login. For cases without login, the benefit is that XHR is subject to
> the Same Origin Policy, so if a rogue site copies the video and the
> JavaScript program, the Same Origin Policy prevents the JavaScript
> program copied to another site from obtaining keys from the key server
> of the site from which the video and the JavaScript program were
> copied. (And the CDM prevents the playback of the video if keys
> weren't obtained.) This should address the concern voiced e.g. by the
> BBC representative about ensuring that video content appears in its
> intended context instead of being embedded by rogue sites.
> 
> (Of course, enforcing the Same Origin Policy is the task for the
> browser and in the EME model the browser is treated as un-trusted by
> the content rights holders. It wouldn't make sense to be worried about
> rogue sites that'd depend on rogue browsers for operation that'd rely
> on the original key server instead of cracking the DRM. The users
> trust the browsers for the privacy and to make a browser rogue in a
> way that would allow the violation of the Same Origin Policy would
> mean compromising user privacy, so it's unlikely that users would want
> to obtain rogue browsers like that just to view content that would be
> loginless *anyway* in the context of another site than the original.)
> 
>> He also mention in the talk that one of the goal of the EME spec was to at
>> least allow existing DRM systems to be supported through the proposed
>> architecture.
> 
> It's more like being able to use existing robustness solutions, the
> name recognition of existing solutions and possibly existing license
> rule systems than about being able to use existing solutions
> wholesale, since, as you note, EME implies remapping the license
> server communication protocol to fit into EME messages.
> 
>> In the lightweight, "on-demand", mode of Marlin, called MS3, which is often
>> used when there is no persistent license delivered (a non-persistent
>> lightweight license is sent back to an authenticated client, just for use
>> within the context of a streaming session), the client needs a direct,
>> non-intermediated, communication with a server.
>> For scalability reasons, the protocol between the DRM client and the server
>> is based on a mutually-authenticated TLS session, not on a signed/encrypted
>> data payload that can be relayed (like a SOAP message could be in the case
>> of PlayReady for example).
> 
> In that case, MS3 would not work with EME as-is (without defeating the
> fundamental architecture of EME).
> 
> However, MS3 is already the third flavor of Marlin (after the original
> and Broadband). Given the willingness of the Marlin Developer
> Community to develop different flavors already, it shouldn't be a big
> deal to develop an EME flavor of Marlin such that user identification
> would be based on session cookies picked up by XHR and the other
> semantics of the communications that currently go over the MS3 TLS
> pipe would be mapped to EME key messages.

Third flavor? Maybe you mean second.
While it "wouldn't be a big deal" to come up with one more Marlin spec to shoe-horn the system this way, Marlin works like a standards body, and as such we all know that it takes time and effort to get all parties involved to agree on new specs, publish them, and wait for implementers to implement them. 
There is already a large deployment of Marlin MS3 clients, with well-tested client implementations and servers. Its use has been standardized in several nationwide specifications, in conjunction with other standards like HbbTV. It would be very hard to tell those deployments that they now have to go back to the drawing board and implement something new!
I was under the impression that one of the goal of the EME extensions was to be able to standardize interfaces that could be implemented with *existing* DRM systems, not require new DRM systems to be created. It seems that this either isn't a goal, or is a goal that has been missed.

> 
> A relevant question, of course, is whether such a flavor is actually
> being developed. Is such a flavor in development?
> 
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/

Received on Wednesday, 8 May 2013 16:02:45 UTC