RE: [MEDIA_PIPELINE_TF] Common content security requirements

Juhani,

Thanks for your comments. See responses inline.

Regards,
Bob

From: juhani.huttunen@nokia.com [mailto:juhani.huttunen@nokia.com]
Sent: Wednesday, August 31, 2011 8:42 AM
To: Bob Lund
Cc: 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.
[Bob: Agreed]


 1.  "User-agent Requirements

    *   The HTML5 user-agent needs to support one or more digital rights management (DRM)
[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.
[Bob: I don't think the primary question at this point is whether this is in scope for W3C, whose scope changes over time, especially we hope, in the area of DRM. With regard to multiple DRMs, if a UA is going to play protected content it will need to support associated content protection. It is highly unlikely that there will be a single content protection scheme adopted by the industry so if a user is to have access to the widest variety of content it would be desirable for a UA  to be able to support multiple schemes. I think it is useful for the MPTF to first agree on what the requirements are to support the use case. We can then decide how they might be pursued.]


    *   "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). [Bob: see above] 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 [Bob: The use cases consider various degrees of HW support. Protected content is today being delivered to PCs without HW support], 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). [Bob: Once we agree on requirements I think it would be the role of a subsequent activity to see how, and to what extent, this could be done]

    *   "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.[Bob: see response to your comment 1] 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. [Bob: Until a common encryption/multiple DRM scheme was defined for UltraViolet that didn't exist either. In the end you may be right but isn't it worth investigating first?]

    *   "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. [Bob: see response to your comment 1] Besides that the proposed requirement can't be guaranteed as that is DRM technology specific.  [Bob: You may be right that the expression of level of trust is DRM specific. This doesn't make it impossible to specific an API that makes this available nor does it make it not valuable]
            [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 [Bob: we should be as specific as possible about "mimics the video element"]. The scrambled media resource, located in an embed element [Bob: this is one approach, another approach is an element that explicitly implements the <audio>, <video> elements and supports plugin], 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." [Bob: this may or may not be the extent of the API. I think we should discuss requirements first]

 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.  [Bob: Agreed]

-Juhani