Re: EME compatibility with existing DRM systems

On Tue, May 14, 2013 at 11:50 PM, Niels Thorwirth
<nthorwirth@verimatrix.com> wrote:
>> 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?

It would not. You'd still use a single CENC media file identifying the
codec as H.264 in the media file even though you'd use several
pseudo-codec identifiers in canPlayType(). Anyway, side channel DRMs
have had their opportunity, since side channel DRMs wouldn't have
needed EME in order to integrate with HTML5.

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

In the case of a hardware-assisted CDM, the CDM could show
cryptographic proof of possession of device-specific key material in
the EME messages emitted by the CDM. You don't need a side channel for
this.

However, it's worth noting that exposing proof of possession of
device-individualized key material is the sort of privacy problem that
browsers try to avoid. It would basically amount to a hyper cookie: a
persistent uniquely-identifying value exposed to multiple sites.

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

What makes a side channel better for this case? In any case, I think
the W3C should not address use cases of this nature since coupling
content access with the mechanism for achieving Internet connectivity
is against Network Neutrality.

> These methods may be desirable or required and have HW or network level access that  the UA may not have.

EME is designed to enable hardware-assisted CDMs. As for network
access, as long as the relevant crypto operations are performed by the
CDM, it shouldn't matter for robustness that network access is
UA-mediated.

> [NT2] Agreed, my point is that if more DRM systems are enabled, the service provider would have a broader choice.

The assumption is not that browsers support N DRMs to give service
providers choice to pick one. Instead, the assumption is that the
number of DRMs supported by a given browser configuration is smaller
than the number of DRMs supported by a streaming service provider to
give users a broader choice of browser configurations that can be used
with the streaming service.

> 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

Also, having the JS app mediate the network communications over XHR
enables picking up session cookies, which removes the need for a
second system for managing user login.

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

The use of UA and JS app-mediated networking instead of side channel
networking is not about enabling multiple DRM schemes to use common
media files. It is about making user login and the decision to let a
particular logged-in user see a particular video part of the streaming
service's server-side application logic that is independent of DRM
schemes.

First of all, picking up login cookies in XHR makes login work the
same way it works in all other Web apps out there. Then the
server-side application logic can use the information about which
logged-in the user the key request is associated with to make the
decision if the key request should be satisfied. After the application
logic has made the decision that the logged-in user is authorized to
receive the keys for the particular video, only then is there a need
for the server-side application logic to talk to DRM scheme specific
server-side code to get the response formulated in the relevant DRM
scheme-specific way. Of course, the DRM scheme-specific code might end
up rejecting the key request anyway due to the CDM not being
authorized even though the user would be.

Maximizing the code commonality between different DRM schemes on the
server side has the potential to make it more feasible for service
providers to support a broader range of DRM schemes, which would allow
compatibility with a broader range of clients, which would be good for
users compared to a given service being tied to a particular DRM
scheme.

Now, this obviously totally ignores domains as a concept handled by
the DRM clients. But domain-awareness in the CDM would be pretty
pointless when the content is streamed and the user doesn't need to
move "purchased" DRMed files between devices. A given CDM can be
considered to be part of the user's domain for as long as the browser
the CDM is integrated with presents a valid login cookie. Fancier
things across multiple user accounts could be implemented entirely on
the server-side. Therefore, it's OK and even desirable to make the CDM
unaware of user accounts, domains and stuff like that.

--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 17 May 2013 10:17:45 UTC