Re: [MEDIA_PIPELINE_TF] Common content security requirements

I think a white paper on this would be useful. I think the best way to do
this would be for someone to write a first draft, then integrate comments
from others to make it complete.

-Clarke

On 9/1/11 1:24 PM, "Giuseppe Pascale" <giuseppep@opera.com> wrote:

>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:46:15 UTC