Re: [MEDIA_PIPELINE_TF] Common content security requirements

All,

I very much support many of the comments made by Juhani about scope: especially that standardization of a DRM system likely should not be attempted in W3C.

What I do think is reasonable is to define how the HTML5 video element can play protected content when the platform does support a content protection system (that can play the content). But we should not expect to define how platforms come to support protection systems, what systems they might support or what the properties of those systems are, only to the extend needed to interact with them through HTML when they are there. As I mentioned on the call, I think introducing such a complex topic as downloadable DRM before even getting past the initial hurdle of the very existence of protected content is, well, ambitious.

I disagree that the "root of trust" issue is out of scope for W3C. We have discussed at the W3C "Identity in the browser" workshop how secure device identity can be (safely) integrated with other secure identity requirements. This can, and in my view should, be addressed completely independently of DRM (and there are other applications for establishing a level of trust with a device, for example banking). So it may be out of scope for the web&tv group, specifically.

And finally, as presented at the Web&TV workshop, I think it's of value if we can decouple as much functionality as possible from the 'closed' DRM realm. Specifically, encryption can be dealt with in a common way (in particular, MPEG have a new standard for this) and authentication and authorization can and should be dealt with by the application, not the DRM.

...Mark



On Aug 31, 2011, at 8:47 AM, Clarke Stevens wrote:

Some additional comments form me [Clarke] below.

-Clarke

From: "juhani.huttunen@nokia.com<mailto:juhani.huttunen@nokia.com>" <juhani.huttunen@nokia.com<mailto:juhani.huttunen@nokia.com>>
Date: Wed, 31 Aug 2011 08:41:51 -0600
To: Bob Lund <B.Lund@CableLabs.com<mailto:B.Lund@CableLabs.com>>
Cc: "public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>" <public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>>
Subject: [MEDIA_PIPELINE_TF] Common content security requirements

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.
[Clarke]I think the point that IS in scope is that HTML5 should support a means of specifying the use of a DRM system. In other words, we don't define the DRM, but we provide a way for HTML5 to use DRM-protected content by specifying the required DRM system.

    *   “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).
[Clarke]I think the idea that a user might obtain support for a DRM that isn't already embedded in the system is a good requirement. If we determine that the requirement is unimplementable, that is another issue. I'm not sure we can make that determination yet.


    *   “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."

[Clarke]This approach should certainly be considered.

 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