Re: [MEDIA_PIPELINE_TF] Common content security requirements

On Thu, 01 Sep 2011 16:45:49 +0200, Bob Lund <B.Lund@cablelabs.com> wrote:

>
>
>> -----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.
>
agree on this.

>> 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>.
>
I'm not talking about an object for the rendering, only for the extra bits  
of information you want to communicate with the underlying platform.

Anyway, could I propose for this group to put together some kind of white  
paper on what could be done, distinguishing between what really needs to  
be in html from what could ideally be not part of the spec? I think many  
of you have some concrete ideas (Mark even presented them in Berlin) so  
having something written down could be a starting point for a more focused  
discussion (?)

/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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Thursday, 1 September 2011 19:24:37 UTC