Re: EME compatibility with existing DRM systems

Henri, thanks for your comments. My replies inline below. 


On Sat, May 11, 2013 at 2:15 AM, Niels Thorwirth
<nthorwirth@verimatrix.com> wrote:

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

Treating DRMs that open a side channel and don't need the EME API
surface as distinct codecs for the purpose of the existing
canPlayType() method and the <source> selection algorithm.

[NT2] Wouldn't that circumvent the idea to co-exist interoperably with other DRM system in e.g. the same DASH file and for the DRM to be codec independent? Those functions are helpful as part of the EME for all DRMs, I believe, but handling the keymessages  through the js app should be optional. 

> [NT] It may be desirable or necessary for authentication and authorization
> to be handled by the DRM client

Why might it be desirable (other than reusing existing side channel-based DRMs)?
Why might it be necessary?
[NT2]: 2 cases where the DRM would handle the authentication ( as replacement or addition to user credentials):  
* Device ID (the device is registered once for use with a service and credentials) - hardware-based security model 
  or
* Presence of another authenticated device (e.g. presence of authenticated cable connection grants service access) 
This could also go through the application but the point here is that the application does not always have to deal with the authentication.
These methods may be desirable or required and have HW or network level access that  the UA may not have. 

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

Supporting only one DRM scheme would be even more harmful to
interoperability than supporting a multi-DRM solution like EME. I
think the W3C should reject requirements arising from single-DRM
scenarios.
[NT2] Agreed, my point is that if more DRM systems are enabled, the service provider would have a broader choice. The need to go through the js app also for keymessages, as I understand it, is motivated by the desire to enable a single DRM server front end and that will still be an option for service providers to choose amongst all DRMs that offer this. Not enforcing this in the specification will enable more DRMs, including existing deployments and standards.  

> I see another significant advantage of supporting existing DRM systems and
> that is broad reach and quick adoption of EME.

It might lead to broach reach and quick adoption of *DRM* but not
*EME*, since making the communications between the CDM and the license
server mediated by the browser and the JS app is the fundamental
design of EME.

[NT2] this may be a main point I am missing, since I am fairly new to the discussion and I appreciate more input. 
I do understand how the parsing in the application level of DRMs (as enabled by e.g. DASH/cenc) is helpful to allow coexistence of multiple DRMs protecting a single file and allowing the application the choice of the best fit in  a standard way, but don't understand why the exclusion of side-channel communication is required for this.

Best, 
Niels
______________________________________________________________
Niels Thorwirth, Executive Director Advanced Technology 
Verimatrix, Inc., 6825 Flanders Drive, San Diego, CA 92121
--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 14 May 2013 20:54:49 UTC