RE: [MEDIA_PIPELINE_TF] Common content security requirements



> -----Original Message-----
> From: Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: Thursday, September 01, 2011 1:11 PM
> To: Mark Watson
> Cc: Bob Lund; juhani.huttunen@nokia.com; public-web-and-tv@w3.org
> Subject: Re: [MEDIA_PIPELINE_TF] Common content security requirements
> 
> On Thu, 01 Sep 2011 16:22:11 +0200, Mark Watson <watsonm@netflix.com>
> wrote:
> >
> > On Sep 1, 2011, at 7:09 AM, "Giuseppe Pascale" <giuseppep@opera.com>
> > wrote:
> >
> >> 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?
> >
> > Something is needed to expose the available content protection systems
> > to the JavaScript application, allow it to select one, and, IMO,
> > transparently transport the content protection's request/response
> > exchange to/from the application.
> >
> > Since it's all triggered by playing a protected source in a
> > MediaElement, it makes sense to add this to the MediaElement.
> >
> Of course in theory what you say make sense, but in practice would a
> "standarized" object be a major drawback for an application? At least in
> a first phase.
> 
> Few thing may still make sense to have from start in html, for example
> an extension to canPlay() to check for drm support like it was proposed
> by someone on the bug 10902 linked below.
> 
> > It should definately not be left to plugins o the existing sort - that
> > is no advance on the situation today.
> >
> agree with you but on the other end it looks like the easiest way
> forward.

I think a critical requirement is that protected content be playable via the video element in order to take advantage of all the video element related features that have been created in HTML5. Use of the existing plugin mechanism wouldn't seem to meet this requirement.

Bob
> 
> /g
> >> 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?
> >
> > That's more of a detailed HTML design question.
> >
> >>
> >> 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.
> >>
> >>
> >> /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:23:19 UTC