Re: EME compatibility with existing DRM systems

Gilles,

The design of EME is that CDMs do not interact directly with content
license servers*, but instead the license acquisition process is mediated
by the application.

It's hard for the specification to *prohibit* such direct interaction, but
you would likely find that a KeySystem that subverted the design approach
would not be usable with most EME applications.

The reason for this design is to avoid the need for service providers - who
must in practice support multiple DRM systems - to stand up multiple
front-end license servers. Also it avoids the need to delegate application
business logic such as user authentication and authorization to multiple
DRM servers. These functions are properly handled by the application and
the license server is used as a back-end server to provide licenses as
required by the application.

As a result, existing DRM client components will likely need to be wrapped
in some way to form an EME CDM. In the case of Marlin that you describe
below it looks like you need to sign and encrypt the messages using the
credentials you would otherwise use for securing the TLS connection.

I would note that content protection  systems that interact directly with
license servers can be integrated into the video element without using EME
at all. For example Apple HLS supports a form of content encryption which
works in this way. The point of EME is to provide a uniform model so that
applications can easily support multiple DRMs.

*Finally, for completeness, I should note that some DRM components perform
a one-off installation/initialization interaction with a server maintained
by the DRM provider, rather than the service provider. For this reason such
components may need network access.

...Mark

Sent from my iPhone

On May 7, 2013, at 5:35 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:

I found a video of a webinar given for the DTG group a month ago (
http://vimeo.com/62269279), where the speaker gives an overview of the
Encrypted Media Extensions.
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.
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.
So I'd like to explain a concrete specific case for the Marlin DRM system
where the current EME architecture would be suboptimal, or at least require
an implementation to "cheat" a bit with regards to the intended use of the
keymessage/addkey workflow, which assumes that the communication between a
Key System and DRM servers can always be intermediated by the application
by passing it a keymessage to forward to the server and having the
application, then, relay the response in the addkey() call.
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). So there's no keymessage that could be created
by the Key System. The Key System must have a direct TCP connection with
the DRM server in order for the TLS handshake to be done, and the response
to be protected, end-to-end, from the server back to the DRM client.
For Marlin MS3 to be used within the EME framework, I imagine that one
could circumvent the intent of the keymessage/addkey pattern, and pass in
the addkey() response (or the InitData of the createSession call) a payload
containing the URL of the DRM server which the DRM client must talk to, and
that the DRM client would simply go directly to the DRM server, bypassing
the application. That does not sound very clean.

I'd love to hear what people on this email list think about this.

Regards,

-- Gilles