Re: EME compatibility with existing DRM systems

On Fri, May 10, 2013 at 4:15 PM, Niels Thorwirth
<nthorwirth@verimatrix.com>wrote:

>  ** **
>
> 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 ?
>
The bug discussions says just what I said earlier in the thread. This model
is supported in existing HTML, without EME.

> ****
>
> ** **
>
> 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?
>
You can have both "one DRM that works with EME differently from all the
others" and "interoperability enabled by EME". They're mutually
inconsistent. The interoperability enabled by EME, such as it is, comes
exactly from having the common interaction/key exchange model, and common
encryption.



> ****
>
> ** **
>
> > 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.
>
I'll wait for your answers to Henri's questions here.

> ****
>
> ** **
>
> >  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?
>
Yes, because it provides no advantage in terms of interoperability compared
to the status quo. The point of EME is to enable this common interaction
model and to encourage use of common encryption so that service providers
can more easily support the multiple DRM systems needed to address the
whole universe of devices.

As one data point, our service supports multiple DRM systems today. Each
time we add a new one we have asked the DRM vendor to support an
interaction model similar to EME and each time they have been happy to do
that. On that basis, I feel it is not a big deal to ask DRM vendors to
support the EME interaction model in return for integration with EME. On
the other hand, I feel it is a big deal to ask service providers to deal
with multiple architecturally dissimilar DRMs each of which attempts to
subsume a different subset of application functionality, together with its
actual DRM (robust key exchange and decryption) functions. We are moving
from a world where the architectural dissimilarity of different DRM systems
effectively forces a service provider to choose a single DRM and then only
devices supporting that DRM can access the service to a world in which it
becomes simple for services to target multiple DRMs. This frees devices
from the requirement to support multiple DRMs in order to access different
services. This model has been a stable aspect of the EME proposal since the
first discussions over two years ago and also follows the common encryption
model established by DECE well before that, whose membership includes a
wide variety of DRM vendors.

...Mark

> ****
>
> ** **
>
> ** **
>
> Best,****
>
> Niels****
>
> ** **
>
> ______________________________________________________________****
>
> Niels Thorwirth, Executive Director Advanced Technology ** **
>
> Verimatrix, Inc., 6825 Flanders Drive, San Diego, CA 92121****
>
> ** **
>