Re: EME compatibility with existing DRM systems

On May 7, 2013, at 10:36 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:

> On Tue, 07 May 2013 16:16:12 +0200, 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.
> 
> @Gilles 
> do you think this would be possible in practice or do you see a major issue with this approach?
> You mention performance issues in your original email, is the difference between the approaches so wide to seriously impact the user experience?

While this is possible in principle (Marlin does define several protocols, some of which use the same crypto credential for message-oriented exchanges rather than channel-oriented communications), but doing so would preclude the use of the Marlin MS3 protocol, which has the advantage of being scalable on off-the-shelf hardware and software stacks, by being based on a published standard as opposed to closed implementation (which, by the way, also means that service providers can implement MS3 servers for free with a simple web server, which I would argue should be welcome in a context where we are trying to make it easier for services to work with DRM, not more difficult).

> 
> 
> 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.
> 
> @Mark
> I guess that even in that case an EME like approach could be useful to convey information that otherwise needs to be part of a manifest or headers. Of course at that point one could argue if it's worth the change.
> 
> /g
> 
> 
> 
> *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
> 
> 
> 
> --
> Giuseppe Pascale
> Product Manager TV & Connected Devices
> Opera Software