Re: EME compatibility with existing DRM systems

Sent from my iPhone

On May 17, 2013, at 3:18 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

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

+1

Couldn't have said it better myself.

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

Received on Friday, 17 May 2013 14:48:31 UTC