- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 17 May 2013 07:48:01 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Niels Thorwirth <nthorwirth@verimatrix.com>, "public-html-media@w3.org" <public-html-media@w3.org>
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