Re: EME compatibility with existing DRM systems

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?

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