RE: [MEDIA_PIPELINE_TF] Common content security requirements



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