- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Thu, 1 Sep 2011 08:45:49 -0600
- To: Giuseppe Pascale <giuseppep@opera.com>, "juhani.huttunen@nokia.com" <juhani.huttunen@nokia.com>
- CC: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
> -----Original Message----- > From: Giuseppe Pascale [mailto:giuseppep@opera.com] > Sent: Thursday, September 01, 2011 8:07 AM > To: Bob Lund; juhani.huttunen@nokia.com > Cc: public-web-and-tv@w3.org > Subject: Re: [MEDIA_PIPELINE_TF] Common content security requirements > > Bob, > the pointed I tried to raise during the call is basically along the line > of what Juhani wrote below. > My question was indeed: do we really need to have a <video> element DRM > aware? Or could be <video> be DRM agnostic in the same way as it is > codec agnostic? I think how codec is handled the model I have in mind. HTML5 video is codec agnostic but not codec ignorant, e.g. canPlayType, <source> resource selection. I think it is important that <video> be able to play protected content. I am not advocating a particular content protection scheme. > And more: if extensions are needed with the only purpose of > communicating with a DRM agent running on the machine, can this be done > simply with <object>s? > > If a specific DRM require a specific <object> it will be up to another > group (outside W3C) to either provide an implementation or a standard > interface for such a plugin. Use of <object> loses the capabilities of <video>. > > > /g > > > On Wed, 31 Aug 2011 16:41:51 +0200, <juhani.huttunen@nokia.com> wrote: > > > Hi Bob, > > > > You sent last week an e-mail on the Common content security > requirements to the HNTF. I assume that was targeted to MPTF reflector > instead, as the discussion points relate to the last week's MPTF telco. > There I was interested to give more comments on the Common content > security requirements as referred to in ISSUE [40] to ISSUE [43]. > However, there was time to discuss shortly just on Req. 2.2. > > > > My main points in the telco were that it would be beneficial to have > support for protected content with HTML5 but the most appropriate > solution requires careful thinking. I also commented that many of the > proposed Common content security requirements 2.x are seem to be out-of- > scope as requirements for W3C. More specific comments are in the > following (with [JHu]). > > "This is a list of common content security technical requirements > derived from the related use-cases > > > > 1. General Web Delivery Requirements > > * If Web users are to have access to a wide range of content, > the Web delivery platform must provide support for the property rights > of content owners." > > [JHu]: The idea to have better support to protected content > availability through Web interface makes sense. Whether the requirement > 1.1 is the exact formulation for this purpose should be discussed. > > > > 1. "User-agent Requirements > > * The HTML5 user-agent needs to support one or more digital > rights management (DRM) systems[1]." > > [JHu]: It is not in the W3C scope to define how many and which DRM > systems UA should support. UA may or may not support DRM systems. > > > > * "If the user-agent doesn't have support for a DRM required by > the content it should be able to download an available module that > supports playback of content using that DRM." > > [JHu]: Again this is out-of-scope for W3C (see the previous answer). > Ideally, and outside W3C scope, it would be nice to have downloadable or > swappable DRMs (when needed). However, the DRM SW module would need a > proper HW support in the device, where the DRM module would be > downloaded, to ensure the necessary security. In practice, there is no > working solution for a secure, downloadable DRM, that would apply > uniquely with several DRM systems (AFAIK). > > > > * "The device platform may provide hardware-based root-of-trust > which should be available for use by the DRM module." > > [JHu]: This is out-of-scope for W3C. In addition, this is not > realistic requirement because there is no generic HW-based root-of-trust > (ROT). The ROT is always DRM vendor or technology specific. > > > > * "Web content and DRM modules should be able to determine the > level of trust of the device." > > [JHu]: Requirements for DRM modules is out-of-scope for W3C. Besides > that the proposed requirement can't be guaranteed as that is DRM > technology specific. > > [JHu]: Overall, requirements 2.x are not in the scope of > W3C and should rather be removed. A suitable approach could be to have > DRM support in the form of 'plugin' in HTML5 something like according to > a proposal in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10902: > > "HTML-intended DRM plugins should implement an interface that mimics > that of the video element. The scrambled media resource, located in an > embed element, should then be handled by the DRM plugin, which should > trigger an error event on the corresponding embed element if viewing of > the resource is not allowed." > > > > 1. "HTML5 Media Element Requirements > > * Web content should use the video and audio element interfaces > to playback DRM protected content. All of the features that exist for > the video and audio element should be available when playing protected > content, e.g. have child track elements, be assignable to a media > controller object. > > * The HTML media resource selection algorithm should include > resource selection based on user agent DRM support. > > * Web content should be able to determine certain DRM-related > playback events and errors. > > * Web content should be able to determine which DRMs are > supported by the user-agent. > > * The DRM solution needs to work for content accessed directly > by a URL or via a URL to a media presentation description (a.k.a. > manifest file)." > > [JHu]: My understanding is that this set of requirements target to > define the specific parameters to enable the protected content > consumption and control through the Web interface. The role and exact > formulation of these kind of requirements may require further > discussion. > > > > -Juhani > > > > > -- > Giuseppe Pascale > TV & Connected Devices > Opera Software - Sweden
Received on Thursday, 1 September 2011 14:47:15 UTC