Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document lists the design goals and requirements that content protection should support for Web and TV applications. Also this document includes links to concrete proposals that are intended to meet the requirements developed by the Web and TV Interest Group participants. The MPTF is a subset of the Web and TV Interest Group. The goal of MPTF is to discuss requirements placed on the HTML5 video, audio and media interfaces by media formats that used for Web and TV applications. The MPTF also proposes APIs that meet these requirements.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The MPTF is a subset of the Web and TV Interest Group. The goal of MPTF is to discuss requirements placed on the HTML5 video, audio and media interfaces by media formats that are used for Web and TV applications. The MPTF also proposes APIs that meet these requirements. The requirements and use cases in this document are the result of discussion within the Media Pipeline Task Force of the Web and TV Interest Group. This document proposes additions to the HTML5 specification so that user agents can enable authorized access to premium content through a standard set of APIs in an interoperable way. This proposal extends the capability of HTML5's <video> and <audio> elements to allow JavaScript to manage authorized access to premium media streams for playback. The requirements do not limit the particular content protection method. Rather they provice a standardized API as well as a default content protection method to enable both proprietary and open content protection solutions. The Task Force believes all the requirements and use cases listed in this document will be next reviewd and discussed by the HTML Working Group for inclusion in the HTML specification.This document was published by the Media Pipeline Task Force of the Web & TV IG as an Editor's Draft. If you wish to make comments regarding this document, please send them to spec-writers-anonymous@w3.org (subscribe, archives). All feedback is welcome.
Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
A majority of Internet traffic is now streaming video.
However, there are currently no standards or common conventions in HTML to provide the level of content protection required by some content owners. As a result, content owners must support multiple, non-interoperable private content protection solutions.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words must, must not, shall, should and should not in this specification are to be interpreted as described in RFC 2119 [RFC2119].
This specification only applies to one class of product: W3C Technical Reports . A number of specifications may be created to address the requirements enumerated in this document. In some cases the union of multiple parts of different specifications may be needed to address a single requirement. Nevertheless, this document speaks only of conforming specifications .
Conforming specifications are ones that address one or more requirements listed in this document. Conforming specifications should attempt to address should level requirements requirements unless there is a technically valid reason not to do so.
This section list the requirements that conforming specification(s) would need to adopt in order to ensure a common interface and interpretation for the playback and control of protected media. These requirements are the result of an interactive process of feedback and discussion within the Media Pipeline Task Force of the Web and TV Interest Group
The user should not be restricted from accessing content for which legal rights have been obtained.
The content owners control the legal rights to the content. If their rights are not protected, they are less likely to produce the high-value content that drives the commercial video business.
Content distributors also have certain rights and obligations as specified in the agreement. Content must be protected in transit so as not to be intercepted and used without authorization.
Specifically, the choice of container format should not prevent the content protection system from operating.
Support for a baseline content protection solution allows at least one method for protected content to be distributed and used. This method should be unencumbered with IPR.
Specifically, the interface defined by the proposed solution should be implementable in any browser without requiring any privileged information. This scope of this requirement is limited to the interface defined in the proposed solution.
The implementation of content protection must be capable of running within an HTML5 environment. This means any browser supportive of HTML5 will be able to specify the parameters and use the appropriate tags to get the protected content to play back.
Timed text tracks and other features of HTML5 media tags must work with protected media streams as described in this requirements document. The use of any of these features must not disable or prevent the use of a compliant implementation of protected media.
This is the corrolary to the previous requirement. The use of any compliant content protection system must not disable or prevent the use of any particular media element features.
The primary errors must be common across different content protection systems so that the unique details of the protection method are not required to be known in advance
The content protection solution must work with adaptive bit rate streaming as well as traditional non-adaptive streaming methods. This ensures that the content protection systems will work with emerging streaming media types.
Description...
This section is a non-exhaustive list of use cases that would be enabled by one (or more) specifications implementing the requirements listed above. Each use case is written according to the following template:
This use case is intended to illustrate the protection of the rights of users, owners and distributors of digital media according to a mutually supported contract. The use case does not stipulate the terms of any contract, it just requires the specification of features that enable the terms of an anticipated contract. For users, this means specification of features that can accurately determine a user's rights and the features to allow or deny user access to content based on those rights.
For a content owner, this use case requires the specification of features that allow the owner to ensure compensation for the use of content owned by the owner according to the contract between the owner, distributors and users. For the distributor, this use case requires the specification of features that enable the secure distribution of content between owners and users such that the contract between owners and users can be accurately executed and vioation of that contract can be prevented.
Since all systems for providing the protection described above are vulnerable and violation of the protections is potentially lucrative, the system must be flexible enough to evolve to meet changing threats.
Possible implementation:
There is no standard interface to verify a user's right to access premium content. This leads to the implementation of multiple incompatible rights authorization systems and interfaces. What should be standardized is:
In order to obtain access to protected content, the content protection system must be identified and proper credentials need to be provided.
| Low Level | High Level |
|---|---|
| Enable the rights of the user | section 4.1.1.1 User Rights |
| Enable the rights of the content owner | section 4.1.1.2 Owner Rights |
| Enable the rights of the content distributor | section 4.1.1.3 Distributor Rights |
This use case describes the need for a system that is flexible enough to support different implementations of content protection. Specifically, it must not unreasonably limit the container format to a design that excludes common implementations. The system must be flexible enough to multiple content protection systems simultaneously. For example, it must be capble of playing back programming in one supported protection system, then switching to another supported protection system on a subsequent piece of programming.
Possible implementation:
What should be standardized is:
The implementation is dependent upon the the commonality between different container formats and a defining a common way to specify them.
| Low Level | High Level |
|---|---|
| Specify the container format | section 4.1.1.4 Container Format |
This use case describes a baseline CDM (e.g. ClearKey) that can be implemented by a user agent in any browser. A baseline CDM ensures that there is a way for content to be encoded that allows for interoperability between implementations. If a content provider encodes content compatible with the baseline CDM, it should be playable on any client platform.
Possible implementation:
What should be standardized is:
The implementation of this use case is dependent upon the premise of a system that is both secure and implementable with open source code.
| Low Level | High Level |
|---|---|
| Define a mandatory basline content protection method | section 4.1.1.5 Mandatory Baseline |
In this use case, the ability to get access to content is dependent upon the use of compatible content formats and legitimate credentials. These requirements must be implementatable by any browser, including and open source browser, and the implementation must report common errors.
Possible implementation:
What should be standardized is:
None.
| Low Level | High Level |
|---|---|
| Require implementation to be browser-independent | section 4.1.1.6 Browser Independence |
| Require compatibility with HTML5 | section 4.1.1.7 HTML5 Compatibility |
| Require compatiblity with HTML5 media elements | section 4.1.1.8 Media Elements |
In this use case, a player renders encrypted adaptive bit-rate content. The encryption method doesn't limit the ability of the player to play the content. Specifically, the fragmented nature of adaptive bit-rate content doesn't limit the use of the encryption method.
Possible implementation:
What should be standardized is:
None
| Low Level | High Level |
|---|---|
| Playback of encrypted content | section 4.1.1.9 Encrypted Content |
This proposal was jointly developed by Microsoft, Google and Netflix. It is comprehensive and is intended to meet the requirements described in this document.
Note: The latest published version of the Encrypted Media Extensions specification is available at https://www.w3.org/TR/encrypted-media/.
Many thanks to the members of the Media Pipeline Task Force of the W3C Web & TV Interest Group who collaborated to create this requirements document and reviewed the proposal to be submitted to the HTML WG for inclusion in the HTML specification.
No normative references.