转自：https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Abstract
This proposal extends HTMLMediaElement providing APIs to control playback of protected content.
The API supports use cases ranging from simple clear key decryption to high value video (given an appropriate user agent implementation). License/key exchange is controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies.
This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implemented as a common baseline.
The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server.
Status of This Document
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/.
Implementers should be aware that this specification is not stable. Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the mailing list mentioned below and take part in the discussions.
This document was published by the HTML working group as an Editor's Draft. Please submit comments regarding this document by using the W3C's (public bug database) with the product set to HTML WG and the component set to Encrypted Media Extensions. If you cannot access the bug database, submit comments to public-html-media@w3.org (subscribe, archives) and arrangements will be made to transpose the comments to the bug database. 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.
Note: It is an open issue whether and how the spec should do more to encourage/ensure CDM-level interop. See Bug 20944.
Note: This specification contains sections for describing security and privacy considerations. These sections are not final and review is welcome.
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.
Table of Contents
- 1. Introduction
- 2. Media Element Extensions
- 3. Events
- 4. Algorithms
- 5. Simple Decryption
- 6. Security Considerations
- 7. Privacy Considerations
- 8. Examples
- 9. Revision History
1. Introduction
This section is non-normative.
This proposal allows JavaScript to select content protection mechanisms, control license/key exchange, and implement custom license management algorithms. It supports a wide range of use cases without requiring client-side modifications in each user agent for each use case. This also enables content providers to develop a single application solution for all devices. A generic stack implemented using the proposed APIs is shown below. This diagram shows an example flow: other combinations of API calls and events are possible.
1.1. Definitions
Text in this font and color is non-normative.
1.1.1. Content Decryption Module (CDM)
The Content Decryption Module (CDM) is a generic term for the client component that provides the functionality, including decryption, for one or more Key Systems.
Implementations may or may not separate the implementations of CDMs or treat them as separate from the user agent. This is transparent to the API and application. A user agent may support one or more CDMs.
1.1.2. Key System
A Key System is a generic term for a decryption mechanism and/or content protection provider. Key System strings provide unique identification of a Key System. They are used by the user agent to select the Content Decryption Modules and identify the source of a key-related event. Simple Decryption Key Systems are supported by all user agents. User agents may also provide additional CDMs with corresponding Key System strings.
A Key System string is always a reverse domain name. For example, "com.example.somesystem". Key System strings are compared using case-sensitive matching. It is recommended that CDMs use simple lower-case ASCII key system strings.
Within a given system ("somesystem" in the example), subsystems may be defined as determined by the key system provider. For example, "com.example.somesystem.1" and "com.example.somesystem.1_5". Key System providers should keep in mind that these will be used for comparison and discovery, so they should be easy to compare and the structure should remain reasonably simple.
1.1.3. Key Session
A Key Session, or simply Session, represents the lifetime of the license(s)/key(s) it contains and associates all messages related to them. Sessions are embodied asMediaKeySession objects. Each Key session is associated with a single instance of Initialization Data provided in the createSession() call.
Each Key Session is associated with a single MediaKeys object, and only media elements associated with that object may access key(s) associated with the session. Other MediaKeysobjects, CDM instances, and media elements may not access the key session or use its key(s). Key sessions and the keys they contain are no longer usable by the CDM for decryption when the session is closed, including when the MediaKeySession object is destroyed.
1.1.4. Session ID
A Session ID is a unique string identifier generated by the user agent or CDM that can be used by the application to identify MediaKeySession objects. (The underlying content protection client or server do not necessarily need to support Session IDs.)
A new Session ID is generated each time the user agent successfully initializes a MediaKeySession object. It must be valid before the MediaKeySession enters the PENDING or READYstates and the user agent fires the associated events.
Each Session ID shall be unique within the browsing context in which it was created. (Note: Some use cases may require that Session IDs be unique within the origin over time, including across browsing sessions.)
1.1.5. Key
Unless otherwise stated, key refers to a decryption key that can be used to decrypt blocks within media data. Each key is uniquely identified by a key ID. A key is associated with the session used to provide it to the CDM. (The same key may be present in multiple sessions.) Such keys may only be provided to the CDM via an update() call. (They may later be loaded by loadSession() as part of the stored session data.)
1.1.6. Key ID
A key is associated with a key ID, which uniquely identifies a key. The container specifies the ID of the key that can decrypt a block or set of blocks within the media data.Initialization Data may contain key ID(s) to identify the keys that are needed to decrypt the media data. However, there is no requirement that Initialization Data contain any or all key IDs used in the media data or media resource. Licenses provided to the CDM associate each key with a key ID so the CDM can select the appropriate key when decrypting an encrypted block of media data.
1.1.7. License
A license is a key system-specific message that includes one or more decryption key(s) - each associated with a key ID - and potentially other information about key usage.
1.1.8. Initialization Data
Key Systems usually require a block of initialization data containing information about the stream to be decrypted before they can construct a license request message. This block could be a simple key or content ID or a more complex structure containing such information. It should always allow unique identification of the key(s) needed to decrypt the content. This initialization information may be obtained in some application-specific way or provided with the media data.
Initialization Data is a generic term for container-specific data that is used by CDMs to generate a license request. Initialization data found with the media data is provided to the application in the initData attribute of the needkey event.
The format of the initialization data depends upon the type of container, and containers may support more than one format of initialization data. The initialization data type is a string that indicates what format the initialization data is provided in. Initialization data type strings are always matched case-sensitively. It is recommended that initialization data type strings are lower-case ASCII strings.
The Encrypted Media Extensions Stream Format and Initialization Data Format Registry provides the mapping from initialization data type string to the specification for each format.
1.1.9. Cross Origin Support
During playback, embedded media data is exposed to script in the embedding origin. In order for the API to fire needkey and message events, media data must be CORS-same-originwith the embedding page. If media data is cross-origin with the embedding document, authors should use the crossorigin attribute on the media element and CORS headers on themedia data response to make it CORS-same-origin.
DRM你又赢了：其API纳入HTML5标准
作为一名开发者，如果你发布的是一款多媒体应用，通常情况下，你需要在其中添加DRM（数字内容版权加密技术），但不幸的是，过去HTML5是无法加入DRM的。现在情况则完全不同了。W3C今天发布了一份加密媒体扩展工作草案（EME），将支持DRM多媒体数字内容，浏览器将无需使用Flash或Silverlight。
EME并不是DRM标准，EME定义了一系列API，允许JavaScript和HTML与解密/保护模块进行交互。将DRM API纳入HTML5标准，将有助于保护和交付网络视频等多媒体内容。
不过对此也有反对声。EFF（国际电子前沿基金会）认为“网络需要成为一个通用的生态系统，并且应基于开放标准，任何地方的任何人都可以在未经允许和商洽的情况下，完全平等地使用，然而EME却与此理念背道而驰”。EFF认为，EME可能会导致内容提供方强制要求用户安装第三方专属软件，甚至是特定硬件或操作系统。为此，EFF与FSF(自由软件基金会)等组织，曾在一个月之前，敦促其成员签署请愿书，抗议W3C将DRM API纳入EME规范。
Arstechnica认为，请愿书的永远没有任何意义。即使W3C决定放弃EME，也会有一些DRM的倡导者会致力于此，比如Netflix、Google、Microsoft等巨头，它们也终将会建立一个共同的平台来推动它。将DRM赶出W3C只能获得精神上的胜利，而对于现实没有任何影响。
EME的反对者声称，EME也在加速Flash和Silverlight的消亡。然而事实上，Silverlight已经停止所有的开发项目。而Flash仍在积极开发后续产品，Adobe此前也发布了其未来的10年计划，但同时，该公司还大力投资于HTML5工具，在开发者使用Flash的前提下，确保他们有使用HTML5的软件。
另外，Adobe已经停止了移动Flash插件的研发工作。尽管移动互联网市场正蓬勃发展，但有89%的人都是在PC上浏览网页，而且其中绝大多数人都安装了Flash。
在iOS、Android、Windows Phone等移动平台上，有许多应用都支持DRM。其中，Android和Windows Phone平台甚至提供各种API和功能，来协助实现DRM。
扫一扫
3184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
