Re: EME compatibility with existing DRM systems

On Wed, May 8, 2013 at 9:00 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:

>
> 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.
>

It's the intention that existing DRM systems can be used to build CDMs, but
it's understood that wrapping an existing DRM into a CDM may require some
work. Noone should assume that because an existing DRM generates certain
challenge and licence messages that the keymessages that appear on the EME
wil be exactly the same as those. There are various reasons why you might
want to wrap them in some way for sending to/from the Javascript and it is
a job for the owner of the DRM system to specify how that should be done.

It does sound like this might be more work for Marlin than for some other
existing DRM systems, but I don't see that as a strong reason to change the
EME architecture. The primary advantage of being able to integrate existing
DRM systems is that they come with hard-to-do things like robustness rules,
known IPR situations, security vetting, trust infrastructure etc. Adapting
the message format to the EME architecture is small by comparison.

...Mark





>
> >
> > 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/
>
>
>