Re: EME compatibility with existing DRM systems

Mark, Henri et al.,

I'd also like to chime in this discussion in support of Gilles' argument.



We had requested this communication channel in a previous bug report:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615
that was resolved with the reply that this model is supported, has that changed afterwards ?



Also, responding to some of your previous arguments:



> You can implement the direct DRM client to DRM server messaging solution today without EME.

[NT]  I believe, in that case we'd lose the desired interoperability enabled by the EME where the JS client has visibility into the different DRMs supported by the content and the client and can chose a best match on a broad range of devices, or is there another way to coexist with other EME DRMs?



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

[NT] It may be desirable or necessary for authentication and authorization to be handled by the DRM client and I believe that options should not be prohibited. If it's not required or desired it's still the choice of the service provider to use the fitting DRM systems, e.g. those that are able to support a single front end license server.



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

[NT]  The choice of the security protocol is a fundamental component of the DRM systems, that affects scalability and basic security. These 'hard-to-do' items are all affected by the change in this protocol, i.e. that has a possible effect on the IP, robustness rules and security vetting of established, tried implementations that have been deployed and evaluated with existing security protocols in place.

I see another significant advantage of supporting existing DRM systems and that is broad reach and quick adoption of EME. Changing the protocol renders deployed Key Systems incompatible to interact with a CDM and renders existing key server incompatible to support CDMs along with other services, this would be the case for e.g. TV integrations of our ViewRight client.



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

[NT]  While this is an advantage it's not the only approach to eliminate the copy attack, e.g. after an initial provisioning/initialization, the device ID or other permanent security credential could be used that would serve the same purpose. It can be seen as the DRM's responsibility to prevent that copy attack which would take the burden of enforcing the Origin Policy away from the service provider and would enable more flexibility and alternative best practices.



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

[NT] While there are reasons for either approach in different deployment scenarios, is there a fundamental reason not enable the flexibility and allow more existing DRMs to operate in the EME structure using different communication approaches?





Best,

Niels



______________________________________________________________

Niels Thorwirth, Executive Director Advanced Technology

Verimatrix, Inc., 6825 Flanders Drive, San Diego, CA 92121