Re: [MEDIA_PIPELINE_TF] Common content security requirements

Sent from my iPhone

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.

It should definately not be left to plugins o the existing sort - that is no advance on the situation today.

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

Received on Thursday, 1 September 2011 14:23:25 UTC