This proposal extends
HTMLMediaElement [HTML5] 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 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.
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 working group maintains a list of all bug reports that the editors have not yet tried to address; there are also open bugs in the previous bug tracker. This draft highlights some of the pending issues that are still to be discussed in the working group. No decision has been taken on the outcome of these issues including whether they are valid.
Implementors should be aware that this specification is not stable. Implementors 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.
Bug 20944 - The specification should do more to encourage/ensure CDM-level interoperability.
This document was published by the HTML Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to firstname.lastname@example.org (subscribe, archives). All comments are welcome.
Publication as a Working 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.
This document is governed by the 1 September 2015 W3C Process Document.
This section is non-normative.
This specification enables script 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 enables content providers to develop a single application solution for all devices.
Supported content is encrypted per container-specific "common encryption" specifications, enabling use across key systems.
Supported content has an unencrypted container, enabling metadata to be provided to the application and maintaining compatibility with other
A generic stack implemented using the API is shown below. This diagram shows an example flow; other combinations of API calls and events are possible.
Content Decryption Module (CDM) is 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.
All messages and communication to and from the CDM, such as between the CDM and a license server, MUST be passed through the user agent. The CDM MUST NOT make direct out-of band network requests. All messages and communication other than those described in Origin-Independent Individualization MUST be passed through the application via the APIs defined in this specification. Specifically, all communication that contains application-, origin-, or content-specific information or is sent to a URL specified by the application or based on its origin, MUST pass through the APIs. This includes all license exchange messages.
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 a CDM and identify the source of a key-related event. User agents MUST support the Common Key Systems. User agents MAY also provide additional CDMs with corresponding Key System strings.
A Key System string is always a reverse domain name. Key System strings are compared using case-sensitive matching. It is RECOMMENDED that CDMs use simple lower-case ASCII key system strings.
For example, "com.example.somesystem".
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.
A Key Session, or simply Session, provides a context for message exchange with the CDM as a result of which key(s) are made available to the CDM.
Sessions are embodied as
Each Key session is associated with a single instance of Initialization Data provided in the
Each Key Session is associated with a single
MediaKeys object, and only media element(s) associated with that object may access key(s) associated with the session.
MediaKeys objects, CDM instances, and media elements MUST 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.
Key IDs MUST be unique within a session.
A Session ID is a unique string identifier generated by the CDM that can be used by the application to identify
A new Session ID is generated each time the user agent and CDM successfully create a new session.
Each Session ID SHALL be unique within the browsing context in which it was created.
For session types for which the Is persistent session type? algorithm returns
true, Session IDs MUST be unique within the origin over time, including across browsing sessions.
The underlying content protection protocol does not necessarily need to support Session IDs.
Unless otherwise stated, key refers to a decryption key that can be used to decrypt blocks within media data.
Each such 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 MUST only be provided to the CDM via an
update() call. (They may later be loaded by
load() as part of the stored session data.)
A key is considered usable if the CDM is certain the key is currently usable to decrypt media data
For example, a key is not usable if its license has expired.
Authors SHOULD encrypt each set of stream(s) that requires enforcement of a meaningfully different policy with a distinct key (and key ID). For example, if policies may differ between two video resolutions, stream(s) containing one resolution should not be encrypted with the key used to encrypt stream(s) containing the other resolution. When encrypted, audio streams SHOULD NOT use the same key as any video stream. This is the only way to ensure enforcement and compatibility across clients.
A key is associated with a key ID that is a sequence of octets and which uniquely identifies the 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.
A key is considered to be known to a session if the CDM's implementation of the session contains any information - specifically the key ID - about it, regardless of whether the actual key is usable or its value is known.
Known keys are exposed via the
Keys are considered known even after they become unusable, such as due to expiration or if they are removed but a record of license destruction or record of key usage is available. Keys only become unknown when they are explicitly removed from a session and any license release message is acknowledged.
For example, a key could become unknown if an
update() call provides a new license that does not include the key and includes instructions to replace the license(s) that previously contained the key.
A license is key system-specific state information that includes one or more key(s) - each associated with a key ID - and potentially other information about key usage.
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 a CDM to generate a license request.
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 the format of the accompanying Initialization Data. 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 [EME-REGISTRY] provides the mapping from Initialization Data Type string to the specification for each format.
When the user agent encounters Initialization Data in the media data, it provides that Initialization Data to the application in the
initData attribute of the
The user agent MUST NOT store the Initialization Data or use its content at the time it is encountered.
The application provides Initialization Data to the CDM via
The user agent MUST NOT provide Initialization Data to the CDM by other means.
Initialization Data MUST be a fixed value for a given set of stream(s) or media data. It MUST only contain information related to the keys required to play a given set of stream(s) or media data. It MUST NOT contain application data, client-specific data, user