MPTF/HTML Content Protection Requirements
- 1 Requirement Document Draft
- 1.1 Abstract
- 1.2 Status of This Document
- 1.3 Introduction
- 1.4 Conformance
- 1.5 Terminology
- 1.6 Requirements
- 1.7 Use cases
- 1.8 Security
- 1.9 Categorization of Requirements and next steps
- 1.10 Related works (informative)
Requirement Document Draft
(ONLY THE EDITOR SHOULD CHANGE THIS DOCUMENT)
This section contains the draft for a requirements document as discussed by the Media Pipeline TF. This is a best-effort attempt to summarize the consensus reached so far by the TF but is still to be considered a draft subject to change at any time.
Status of This Document
This document is merely a public working draft of requirement(s) for potential W3C recommendations. It has no official standing of any kind and does not represent the support or consensus of any standards organization.
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, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [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 a conforming specification.
A conforming specification is one that addresses one or more requirements listed in this document. A conforming specification should attempt to address requirements marked with the keywords "should" or "may" unless there is a technically valid reason not to do so.
- programme (program)
A programme (program) comprises a single period of audio visual content. It is usually expected to be labeled in content directories or television programme guides as a single entity. This might include an episode of a television programme, a radio programme, or a movie.
For the purposes of this document, a device is any piece of equipment connected to the home network. Note that this is a generic term that includes also television definition below.
A device that presents programme content from a variety of sources - such as received via broadcast (cable, satellite, terrestrial), on-demand streaming services, or streamed from other devices in the home (e.g. PVR). Within the scope of this document, it is presumed that a television is connected to the home network.
For the purposes of this document, a service is any functionality available on a device, such as the ability to playback audio/video content, record content, print documents etc.
An individual resource that adheres to a certain content type, ranging from short static documents to long essays or reports with rich multimedia. For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a document is rendered to the user. These terms are not meant to imply a visual medium; they must be considered to apply to other media in equivalent ways.
- content item
For the purposes of this document, the term “content item” refers to metadata describing or more binary versions of media. The media described by an item may either be stored or streamed. A single content item may refer to multiple media binaries that represent different formats for the content being described.
- channel item
For the purposes of this document, the term “channel item” refers to an “item” describing a streaming source. A channel item may contain metadata describing the channel source such as channel number, distribution network, etc. A channel may not be available on the home network, i.e. the “channel item” may refer to a channel that can only be locally tuned. In these cases “channel item” metadata will not provide network addressing information (URLs) to connect to the channel source.
- record task (item)
For the purposes of this document, the term “record task item” refers to an item which contains metadata describing a pending or completed network recording operation. “Record task items” are created by a network recording service and allow network record service clients to control pending recording operations. Additionally, “record task items” include metadata describing the status of the recording request and the identity of “content items” that represent the results of network recording operations.
This section enumerates the requirements that conforming specification(s) would need to address to enable content to be delivered to authorized users and reasonably withheld from unauthorized use according the the agreements between the authorized users, the content owners and the content delivery agents. These requirements are directly motivated by the #Use cases described in this document and are based on an interactive process of feedback from the discussions in the Media Pipeline Task Force of the Web & TV IG. This document and the Media Pipeline Task Force take no position on the specifics of the agreements between the authorized users, the content owners and the delivery agents except that the range of points in the agreements must be reflected in the features of the technical requirements. The technical requirements should be flexible enough to anticipate some changes in the agreements over time.
Compatibility with widely deployed standards
Several channel and content protection systems (e.g. DTCP-IP, HDCP, HTTPS, , M-DNS/DNS-SD) are in popular use today for enabling the legitimate use of content an preventing the illigitimate use of content through digital content storage and distribution systems. A conforming specification shall set out requirements for an API that would enable interaction with those existing protocols.
Control and Communication
Control of content players
Conforming specifications should enable applications to know what content that can be presented by a device or service on the home network and control the playback of that content presented, in such a way that the application does not have to handle:
- issues of codec, container format, or transport protocol compatibility
- differences in the mechanisms by which content is delivered to the rendering device (e.g. received from broadcast vs. streamed from a media server)
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:
Ux. <TITLE> Original Proposal: ISSUE-n Description: * high level description/overview of the goals of the use case * Schematic Illustration (devices involved, work flows, etc.) (Optional) Motivation: * Explanation of benefit to ecosystem * Why were you not able to use only existing standards to accomplish this? Dependencies: * other use cases, proposals or other ongoing standardization activities which this use case is dependent on or related to Requirements: * List of requirements implied by this Use Case.
U1. Service User Interface
Original Proposal: ISSUE-??
Description: An application ...
- the application ...
Motivation: There is ...
Dependencies: In order to ...
|Low Level||High Level|
|Determine list of...||#Service ...|
|Determine list of ...||#Service ...|
|Send a message to ...||#Service ...|
|Listen to ...||#Service ...|
Tracker : ISSUE-??
Enabling application access ...
This section lists possible threats that a conforming specification may have to deal with and possible solutions to reduce risks for the user. This section is not intended as an exhaustive list of problems and solutions but is intended to provide some directions for further investigation
- Malicious attacks
- An external server can ...
- 3rd party visibility into ...
The list of techniques listed in this section are not mutually exclusive but can be combined to provide more flexibility in handling user security.
Home Network access allowed only to Trusted applications
- In order for ...
Categorization of Requirements and next steps
One of the deliverable of the Media Pipeline Taskforce, according to its charter, ...
This section summarizes the consensus of the TF about the desirable next steps and also to try to give an indication of relative priorities of the identified requirements.
The MPTF has made an attempt to categorize requirements based on the priority of addressing them to enable some of the use cases that are already available via other technologies or that are felt particularly important to have an enhanced user experience. All identified requirements are considered important by the Task Force; so the criteria followed is more the degree to which each requirements enables use cases that cannot be covered today rather than a value judgment of the importance of one requirement versus another (which differs by individual). By this "enablement" criterion, a feature that enables more use cases is higher priority than a feature that enables a limited subset of use cases.
The following requirements underpin most (all) of the use cases listed in this document, so they are considered the starting point for a technical work:
A close analysis and discussion of the use-cases and requirements described in this document, lead the group to conclude that ...
The MPTF believes that ...
During his work, ...
Related works (informative)
This section include references to related works (prototypes, draft APIs, etc.) that have been produced by IG participants and are related to the use cases outlined in this document. Note that this section is informative and that the Web and TV IG does not endorse any of the works listed in this section. Nevertheless the Web and TV IG thinks that these related works contain useful ideas that could be discussed and expanded by a working group writing specifications addressing requirements enumerated in this document.