Re: EME compatibility with existing DRM systems

On May 7, 2013, at 7:16 AM, Mark Watson <watsonm@netflix.com> wrote:

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

That's understood. But doing that would defeat the purpose of the design of the Marlin MS3 protocol and its performance characteristics.
One of they key reasons why MS3 works over TLS the way it does is that it allows service providers to leverage existing software and hardware infrastructure to scale the DRM processing: TLS is a well known protocol, which has become a commodity. By choosing to leverage TLS as an authenticated, encrypted channel, service providers can delegate the crypto processing to off-the-shelf hardware and software solutions that implement plain-old TLS.
When using a model where message signing and encryption is done at a different layer (which, by the way, is done for other Marlin protocols, such as Marlin BB), all that off-the-shelf-ness goes out the window, and you're back to needing vendor-specific server software to implement the crypto processing of the messages.
It would be a huge step backward if using EME meant not being able to take advantage of web-standard protocols like TLS. That would seem to be going in the exact opposite direction from what organizations like W3C usually strive for: more common standards, less vendor-specific technology.

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