This proposal extends [[!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.
The working groups maintains a list of all bug reports that the editors have not yet tried to address. 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 specification contains sections for describing security and privacy considerations. These sections are not final and review is welcome.
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.
Content Decryption Module (CDM) is a generic term for the client component that provides the functionality, including decryption, for one or more .
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 covered in the following paragraph 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.
Application- and origin-independent messages related to per-client initialization (or reinitialization) that are sent to a fixed non-application-dependent URL MUST be handled by the user agent and MUST NOT be passed to the application via the APIs. The related message exchange and operations MUST be performed by the user agent via the user agent's network stack.
For example, an initialization, provisioning, or individualization process for a client device that involves communicating with a server hosted by the user agent or CDM vendor and does not contain application- or origin-specific information MUST be performed by the user agent without involving the application. The same applies to reinitialization, reprovisioning, or reindividualization.
For implementations that support per-origin initialization, such messages MUST be passed to the application via the APIs. Such messages MUST NOT contain non-origin-specific per-client information, such as unique client identifiers. As with all other uses of the APIs, responses passed to the CDM MUST NOT contain executable code.
To preserve the privacy properties of per-origin initialization, applications and key system servers should not defer initialization to a non-origin-specific server. See Individualization.
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 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 . Sessions are embodied as objects. Each Key session is associated with a single instance of provided in the call.
Each Key Session is associated with a single object, and only media element(s) associated with that object may access key(s) associated with the session. Other objects, 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 object is destroyed.
A Session ID is a unique string identifier generated by the that can be used by the application to identify objects.
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. Session IDs for sessions MUST be unique within the 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 . 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 via an call. (They may later be loaded by as part of the stored session data.)
A key is considered usable if the CDM is certain the key is currently usable for decryption.
For example, a key is not usable if its license has expired.
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 . 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 or . Licenses provided to the CDM associate each key with a key ID so the can select the appropriate key when decrypting an encrypted block of media data.
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.
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 .
Initialization Data is a generic term for container-specific data that is used by a to generate a license request. Initialization data found with the is provided to the application in the attribute of the 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 [[EME-REGISTRY]] provides the mapping from initialization data type string to the specification for each format.
Initialization Data MUST be a fixed value for a given set of stream(s) or . It MUST only contain information related to the keys required to play a given set of stream(s) or . It MUST NOT contain application data, client-specific data, user-specific data, key(s), or executable code.
Initialization Data SHOULD NOT contain Key System-specific data or values. Implementations MUST support the common formats defined [[EME-REGISTRY]] for each they support.
Use of proprietary formats/contents is discouraged, and supporting or using only proprietary formats is strongly discouraged. Proprietary formats should only be used with pre-existing content or on pre-existing devices that do not support the common formats.
During playback, embedded media data is exposed to script in the embedding . In order for the API to provide in the event, MUST be with the embedding page. If is cross-origin with the embedding document, authors SHOULD use the attribute on the and CORS headers on the response to make it .
During playback, embedded media data is exposed to script in the embedding . In order for the API to provide in the event, MUST NOT be Mixed Content [[!MIXED-CONTENT]].
Requests access to the specified .
When supportedConfigurations
is specified, the combination specified by at least one of its elements must be supported.
The resulting MediaKeySystemAccess will correspond to the first such elment.
Any permission checks or user interaction, such as a prompt, SHOULD be performed before resolving the promise.
If the keySystem
is not supported or not allowed (in one at least one of the supportedConfigurations
, if specified), the promise is rejected.
Otherwise, it is resolved with a new MediaKeySystemAccess object.
If keySystem is an empty string, return a promise rejected with .
If supportedConfigurations was provided and is empty, return a promise rejected with .
If the of the calling context's is not an [[!MIXED-CONTENT]]:
Bug 26332 - The availability of this API on unauthenticated origins is an open issue. It has been proposed that such access not be allowed at all or be allowed only in specific circumstances. It is likely that there will be scenarios where access from an unauthenticated origin is not allowed. It is also an open issue whether and how the impact of serving audio/video media over secure transport can be mitigated.
If keySystem is not one of the supported by the user agent, return a promise rejected with . String comparison is case-sensitive.
Let promise be a new promise.
Run the following steps asynchronously:
If keySystem is not supported or not allowed in the of the calling context's , return a promise rejected with .
Bug 25923 - It is TBD whether rejecting the promise is the correct behavior or whether the promise should instead be resolved with null
.
If supportedConfigurations
was not provided, resolve the promise with a new MediaKeySystemAccess object, execute the following steps:
Let access be a new MediaKeySystemAccess object, and initialize it as follows:
Resolve promise with access and abort these steps.
For each element of supportedConfigurations
:
Let combination be the element.
For each dictionary member in combination:
If the member’s value cannot be satisfied together in combination with the previous members, continue to the next iteration of the loop.
Unrecognized dictionary members are ignored per [[WebIDL]], and will never reach this algorithm. Thus, they cannot be considered as part of the combination.
If keySystem is supported and allowed in the of the calling context's in the configuration specified by the combination of the values in combination, execute the following steps:
Let access be a new MediaKeySystemAccess object, and initialize it as follows:
Resolve promise with access and abort these steps.
There were no supported combinations in supportedConfigurations
.
Return promise.
Except for sessions, the need and ability to store state is Key System implementation-specific and may vary by feature used.
Bug 25923 - The structure of the DOMString
members may change. If it is, other methods may be added.
Implementations SHOULD NOT add members to the this dictionary. Should member(s) be added, they MUST be of type MediaKeysRequirement, and it is RECOMMENDED that they have default values of to support the widest range of application and client combinations.
This dictionary MUST NOT be used to pass state or data to the CDM.
The MediaKeySystemAccess object provides access to a .
The MediaKeys object represents a set of keys that an associated HTMLMediaElement can use for decryption of during playback. It also represents a CDM instance.
For methods that return a promise, all errors are reported asynchronously by rejecting the returned Promise. This includes [[!WebIDL]] type mapping errors.
The steps of an algorithm are always aborted when resolving or rejecting a promise.
If this object was created by a MediaKeySystemAccess object that was created with a value of and sessionType is not , throw .
If sessionType is not supported by the corresponding to the attribute, throw .
Return session.
Provides a server certificate to be used to encrypt messages to the license server.
Key Systems that use such certificates MUST also support requesting the certificate from the server via the .
This method allows an application to proactively provide a server certificate to implementations that support it to avod the additional round trip should the CDM request it. It is intended as an optimization, and applications are not required to use it.
If serverCertificate is an empty array, return a promise rejected with a new .
If the corresponding to the attribute does not support server certificates, return a promise rejected with .
Let certificate be a copy of the contents of the serverCertificate parameter.
Let promise be a new promise.
Run the following steps asynchronously:
Let cdm be the cdm during the initialization of this object.
Use the cdm to process certificate.
Resolve promise.
Return promise.
The MediaKeySession object represents a key session.
For methods that return a promise, all errors are reported asynchronously by rejecting the returned Promise. This includes [[!WebIDL]] type mapping errors.
The steps of an algorithm are always aborted when resolving or rejecting a promise.
The for this object and the associated key(s) or license(s).
The time, in milliseconds since 01 January, 1970 UTC, after which the key(s) in the session will no longer be usable to decrypt , or NaN
if no such time exists, as determined by the CDM.
Signals when object becomes closed as a result of the being run. This promise can only be fulfilled and is never rejected.
Generates a request based on the initData.
If this object's uninitialized value is false, return a promise rejected with .
Let this object's uninitialized be false.
If initDataType is an empty string, return a promise rejected with .
If initData is an empty array, return a promise rejected with .
If the corresponding to media keys's attribute does not support initDataType as an , return a promise rejected with . String comparison is case-sensitive.
Let init data be a copy of the contents of the initData parameter.
Let session type be this object's session type.
Let promise be a new promise.
Run the following steps asynchronously:
If the init data is not valid for initDataType, reject promise with .
Let sanitized init data be a validated and sanitized version of init data.
The user agent MUST thoroughly validate the before passing it to the CDM. This includes verifying that the length and values of fields are reasonable, verifying that values are within reasonable limits, and stripping irrelevant, unsupported, or unknown data or fields. It is RECOMMENDED that user agents pre-parse, sanitize, and/or generate a fully sanitized version of the . If the format specified by initDataType support multiple entries, the user agent SHOULD remove entries that are not needed by the CDM.
Let session id be the empty string.
Let message be null.
Let cdm be the CDM loaded during the initialization of media keys.
Use the cdm to execute the following steps:
If the init data is not supported by the cdm, reject promise with .
Follow the steps for the first matching condition from the following list:
The returned license must not be persistable.
The returned license may be persistable.
The license server determines the type of license that is returned, either persistent or non-persistent. A persistent license cannot be added to a non-persistable session.
Let session id be a unique string.
If session type is , the ID MUST be unique within the the of this object's over time, including across Documents and browsing sessions.
Let message be a request for the requested session type generated based on the init data, which is interpreted per initDataType.
For example, a license request.
The cdm MUST NOT use any stream-specific data, including , not provided via the init data.
The cdm SHOULD NOT store session data, including the session ID, at this point. See .
Let this object's callable be true.
Resolve promise.
Return promise.
Loads the data stored for the specified session into this object.
If this object's uninitialized value is false, return a promise rejected with .
Let this object's uninitialized be false.
If sessionId is an empty string, return a promise rejected with .
If this object's session type is not , return a promise rejected with .
If the corresponding to media keys's attribute does not support loading previous sessions, return a promise rejected with .
Let promise be a new promise.
Run the following steps asynchronously:
Let sanitized session ID be a validated and/or sanitized version of sessionId.
The user agent should thoroughly validate the sessionId value before passing it to the CDM. At a minimum, this should include checking that the length and value (e.g. alphanumeric) are reasonable.
Let expiration time be NaN
.
Let message be null.
Let message type be null.
Let cdm be the CDM loaded during the initialization of media keys.
Use the cdm to execute the following steps:
If there is no data stored for the sanitized session ID in the origin, resolve promise with false
.
Let session data be the data stored for the sanitized session ID in the origin. This MUST NOT include data from other origin(s) or that is not associated with an origin.
If there is an unclosed session in any representing the session data, reject promise with .
In other words, do not create a session if a non-closed persistent session already exists for this sanitized session ID in any browsing context.
Load the session data.
If the session data indicates an expiration time for the session, let expiration time be the expiration time in milliseconds since 01 January 1970 UTC.
If the CDM needs to send a message:
Let this object's callable be true.
If the loaded session contains usable keys, run the on the session.
The algorithm MAY also be run later should additional processing be necessary to determine with certainty whether one or more keys is usable.
If message is not null, run the on the session, providing message type and message.
Resolve promise with true
.
Return promise.
Provides messages, including licenses, to the CDM.
If this object's callable value is false, return a promise rejected with .
If response is an empty array, return a promise rejected with .
Let response copy be a copy of the contents of the response parameter.
Let promise be a new promise.
Run the following steps asynchronously:
Let sanitized response be a validated and/or sanitized version of response copy.
The user agent should thoroughly validate the response before passing it to the CDM. This may include verifying values are within reasonable limits, stripping irrelevant data or fields, pre-parsing it, sanitizing it, and/or generating a fully sanitized version. The user agent should check that the length and values of fields are reasonable. Unknown fields should be rejected or removed.
Let cdm be the CDM loaded during the initialization of the object that created this object.
Let message be null.
Let message type be null.
Use the cdm to execute the following steps:
If the format of sanitized response is invalid in any way, reject promise with .
Process sanitized response, following the stipulation for the first matching condition from the following list:
When sanitized response contains key(s) and/or related data, cdm will likely cache the key and related data indexed by key ID.
The replacement algorithm within a session is -dependent.
Keys from different sessions SHOULD be cached independently such that closing one session does not affect keys in other sessions, even if they have overlapping key IDs.
It is RECOMMENDED that CDM implementations support a standard and reasonably high minimum number of keys per object, including a standard replacement algorithm, and a standard and reasonably high minimum number of objects. This enables a reasonable number of key rotation algorithms to be implemented across user agents and may reduce the likelihood of playback interruptions in use cases that involve various streams in the same element (i.e. adaptive streams, various audio and video tracks) using different keys.
If the set of usable keys changed, run the on the session.
The algorithm MAY also be run later should additional processing be necessary to determine with certainty whether one or more keys is usable.
If the expiration time for the session changed, run the on the session, providing the new expiration time.
If a message needs to be sent to the server, execute the following steps:
If message is not null, run the on the session, providing message type and message.
Resolve promise.
Return promise.
Indicates that the application no longer needs the session and the CDM should release any resources associated with this object and close it.
The returned promise is resolved when the request has been processed, and the attribute promise is resolved when the session is closed.
If this object's callable value is false, return a promise rejected with .
If the has been run on this object, return a resolved promise.
Let promise be a new promise.
Run the following steps asynchronously:
Let cdm be the CDM loaded during the initialization of the object that created this object.
Use the cdm to execute the following steps:
Resolve promise.
Return promise.
Removes stored session data associated with this object.
If this object's callable value is false, return a promise rejected with .
If this object's session type is not , return a promise rejected with .
If the has been run on this object, return a promise rejected with .
Let promise be a new promise.
Run the following steps asynchronously:
Let cdm be the CDM loaded during the initialization of the object that created this object.
Use the cdm to execute the following steps:
Process the remove request.
This MAY involve exchanging message(s) with the application.
Unless this step fails, the CDM MUST have cleared all stored session data associated with this object, including the , before proceeding to the next step.
A subsequent call to with the value would fail because there is no data stored for that session ID.
Run the following steps asynchronously once the above step has completed:
Return promise.
Bug 26372 - getUsableKeyIds() may be replaced.
Gets the key IDs for keys in the session that the CDM knows are currently usable to decrypt .
If this object's callable value is false, return a promise rejected with .
Let promise be a new promise.
Run the following steps asynchronously:
Let cdm be the CDM loaded during the initialization of the object that created this object.
Use the cdm to execute the following steps:
Resolve promise with a new sequence object, each element of which contains one element of usable key ids.
The MediaKeyMessageEvent object is used for the event.
Events are constructed as defined in [[!DOM]].
Implementations MUST NOT require applications to handle message types. Implementations MUST support applications that do not differentiate messages and MUST NOT require that applications handle message types. Specifically, Key Systems MUST support passing all types of messages to a single URL.
This attribute allows an application to differentiate messages without parsing the message. It is intended to enable optional application and/or server optimizations, but applications are not required to use it.
In some implementations, objects may not fire any events until the object is associated with a media element using .
Event name | Interface | Dispatched when... |
---|---|---|
keyschange | There has been a change in usable keys in the session. | |
message | MediaKeyMessageEvent | The CDM has generated a message for the session. |
The Queue a "message" Event algorithm is run when the CDM needs to queue a message event to a object. Requests to run this algorithm include a target object, a message type, and a message.
The following steps are run:
The Usable Keys Changed algorithm is run when the CDM changes the set of keys in the session that may be used for decryption. This can happen as the result of an call or some other event. Requests to run this algorithm include a target object.
The following steps are run:
The Update Expiration algorithm is run when the CDM changes the expiration time of a session.
This can happen as the result of an call or some other event.
Requests to run this algorithm include a target object and the new expiration time, which may be NaN
.
The following steps are run:
The Session Close algorithm is run when the CDM closes the session associated with a object.
The CDM may close a session at any point, such as in response to a call, when the session is no longer needed, or when system resources are lost. Keys in other sessions SHOULD be unaffected, even if they have overlapping key IDs.
The following steps are run:
The methods report errors by rejecting the returned promise with a . The following DOMException names from WebIDL [[!WebIDL]] are used in the algorithms. Causes specified specified in the algorithms are listed alongside each name, though these names MAY be used for other reasons as well.
Name | Possible Causes (non-exhaustive) |
---|---|
NotSupportedError |
The existing MediaKeys object cannot be removed. The key system is not supported. The key system is not supported on insecure origins. The initialization data type is not supported by the key system. The session type is not supported by the key system. The initialization data is not supported by the key system. The operation is not supported by the key system. |
InvalidStateError |
The existing MediaKeys object cannot be removed at this time. The session has already been used. The session is not yet initialized. The session is closed. |
InvalidAccessError |
The parameter is empty. Invalid initialization data. The operation is not supported on sessions of this type. Invalid response format. A persistent license was provided for a "temporary" session. |
QuotaExceededError |
The MediaKeys object cannot be used with additional HTMLMediaElements. A non-closed session already exists for this sessionId. |
This section provides an overview of session stroage and persistence that complements the algorithms.
If this object's session type is not , the user agent and CDM MUST NOT persist a record of or data related to the session at any point. This includes license(s), key(s), and the .
The remainder of this section applies to sessions, which are OPTIONAL for implementatations to support.
Persisted data MUST always be stored such that only the of this object's can access it. In addition, the data MUST only be accessible by the current profile of this user agent - other user agent profiles, user agents, and applications MUST NOT be able to access the stored data.
The CDM SHOULD NOT store session data, including the Session ID, until is called the first time. Specifically, the CDM SHOULD NOT store session data during the algorithm. This ensures that the application is aware of the session and knows it needs to eventually remove it.
The CDM MUST ensure that data for a given session is only present in one active unclosed session in any . In other words, MUST fail when there is already a representing the session specified by the sessionId parameter, either because the object that created it via is still active or it has been loaded into another object via . A session MAY only be loaded again after the has not been run on the object representing it.
An application that creates a session SHOULD later remove the stored data using . The CDM MAY also remove sessions as appropriate, but applications SHOULD NOT rely on this.
See the Security Considerations and Privacy Considerations sections for additional considerations when supporting persistent storage.
This section specifies additions to and modifications of the [[!HTML5]] when the Encrypted Media Extensions are supported.
For methods that return a promise, all errors are reported asynchronously by rejecting the returned Promise. This includes [[!WebIDL]] type mapping errors.
The steps of an algorithm are always aborted when resolving or rejecting a promise.
The being used when decrypting encrypted for this media element.
Indicates what the media element is waiting for, if anything (indicated by the and events). This is described in the .
Event handler for the event MUST be supported by all HTMLMediaElements as both a content attribute and an IDL attribute.
Provides the to use when decrypting media data during playback.
If mediaKeys and the attribute are the same object, return a resolved promise.
If this object's attaching media keys value is true, return a promise rejected with .
Let this object's attaching media keys value be true.
Let promise be a new promise.
Run the following steps asynchronously:
If mediaKeys is not null, it is already in use by another media element, and the user agent is unable to use it with this element, let this object's attaching media keys value be false and reject promise with .
If the attribute is not null, run the following steps:
If the user agent or CDM do not support removing the association, let this object's attaching media keys value be false and reject promise with .
If the association cannot currently be removed, let this object's attaching media keys value be false and reject promise with .
For example, some implementations may not allow removal during playback.
Stop using the CDM instance represented by the attribute to decrypt and remove the association with the media element.
If the preceding step failed, let this object's attaching media keys value be false and reject promise with .
If mediaKeys is not null, run the following steps:
Let this object's attaching media keys value be false.
Resolve promise.
Return promise.
Support for clearing or replacing the associated object during playback is a quality of implementation issue. In many cases it will result in a bad user experience or rejected promise.
As a best practice, applications should create a MediaKeys object and call before providing (for example, setting the attribute). This avoids potential delays in some implementations.
The MediaEncryptedEvent object is used for the event.
Events are constructed as defined in [[!DOM]].
Event name | Interface | Dispatched when... | Preconditions |
---|---|---|---|
encrypted | MediaEncryptedEvent | The user agent encounters in the . | is equal to or greater.
It is possible that the element is playing or has played. |
The following steps are run when the media element encounters in the during the :
Let initDataType be the empty string.
Let initData be null.
If the is and not mixed content, run the following steps:
Let initDataType be the string representing the of the Initialization Data.
Let initData be the Initialization Data.
While the media element may allow loading of "Optionally-blockable Content" [[MIXED-CONTENT]], the user agent MUST NOT expose Initialization Data from such media data to the application.
is not changed and no algorithms are aborted. This event merely provides information.
The attribute will be null if the media data is not or is mixed content. Applications may retrieve the Initialization Data from an alternate source.
Continue Normal Flow: Continue with the existing media element's .
The following steps are run when the media element encounters a block of encrypted during the :
If the media element's attribute is not null, run the following steps:
Let cdm be the CDM loaded during the initialization of the media keys.
If there is at least one created by the media keys on which the has not been run, run the following steps:
This check ensures the cdm has finished loading and is a prequisite for a matching key being available.
Let the block key ID be the key ID of the current block.
The key ID is generally specified by the container.
Use the cdm to execute the following steps:
Let available keys be the union of keys in sessions that were created by the media keys.
Follow the steps for the first matching condition from the following list:
Let block key be the matching key.
If multiple sessions contain a usable key for the block key ID, which key to use is -dependent.
Use the cdm to decrypt the block using block key.
Follow the steps for the first matching condition from the following list:
Not all decryption problems (i.e. using the wrong key) will result in a decryption failure. In such cases, no error is fired here but one may be fired during decode.
Bug 26372 - It is TBD whether anything should happen in this case.
Otherwise, there is no key for the block key ID in any session so continue.
Run the following steps:
These steps are reached when there is no usable key for the block.
For frame-based encryption, this may be implemented as follows when the media element attempts to decode a frame as part of the :
Let encrypted be false.
Detect whether the frame is encrypted.
Decode the frame.
Provide the frame for rendering.
The Queue a "waiting" Event algorithm is run when the CDM needs to queue a waiting event to a object. Requests to run this algorithm include a target object.
The following steps are run:
The Attempt to Resume Playback If Necessary algorithm is run when one or more keys becomes available. If playback is blocked waiting for a key, it resumes playback if a necessary key has been provided. Requests to run this algorithm include a target object.
The following steps are run:
The following steps are added to change algorithms in Playing the media resource:
Media data processed by a CDM MAY be unavailable through Javascript APIs in the usual way (for example using the CanvasRenderingContext2D drawImage() method and the AudioContext MediaElementAudioSourceNode). This specification does not define conditions for such non-availability of media data, however, if media data is not available to Javascript APIs then these APIs MAY behave as if no media data was present at all.
Where media rendering is not performed by the UA, for example in the case of a hardware protected media pipeline, then the full set of HTML rendering capabilities, for example CSS Transforms, MAY be unavailable. One likely restriction is that video media MAY be constrained to appear only in rectangular regions with sides parallel to the edges of the window and with normal orientation.
All user agents MUST support the common key systems described in this section.
This ensures that there is a common baseline level of protection that is guaranteed to be supported in all user agents, including those that are entirely open source. Thus, content providers that need only basic protection can build simple applications that will work on all platforms without needing to work with any content protection providers.
The "org.w3.clearkey"
uses plain-text clear (unencrypted) key(s) to decrypt the source.
No additional client-side content protection is required.
This Key System is described below.
The following describe how Clear Key supports key system-specific capabilities:
The method: Implementations MAY support associating the object with more than one .
The MediaKeySystemOptions: There are no supported capability values.
The following describe how Clear Key implements key system-specific behaviors:
The generated message is a JSON object encoded in UTF-8 as described in License Request Format.
The request is generated by extracting the key IDs from the init data.
The "type" member value is the value of the sessionType parameter.
The attribute is a numerical value representable by a 32-bit integer.
The response parameter is a JWK Set as described in License Format.
sanitized response is considered invalid if it is not a valid JWK Set with at least one valid JWK key of a valid length for the media type.
The method always returns all key IDs that have been provided via .
: Implementations MAY support any combination of registered Initialization Data Types [[EME-REGISTRY]].
Implementations SHOULD support the "keyids"
type and other types appropriate for content types supported by the user agent.
This section describes the format of the license request provided to the application via the attribute of the event.
The format is a JSON object containing the following members:
When contained in the ArrayBuffer attribute of a object, the JSON string is encoded in UTF-8 as specified in the Encoding specification [[!ENCODING]]. Applications MAY decode the contents of the ArrayBuffer to a JSON string using the [[!ENCODING]].
The following example is a license request for a temporary license for two key IDs. (Line breaks are for readability only.)
{ "kids": [ "67ef0gd8pvfd0", "77ef0gd8pvfd0" ], "type": }
This section describes the format of the license to be provided via the response parameter of the method.
The format is a JSON Web Key (JWK) Set containing representation of the symmetric key to be used for decryption, as defined in the JSON Web Key (JWK) specification [[!JWK]].
For each JWK in the set, the parameter values are as follows:
The JSON object MAY have an optional "type" member value, which MUST be one of the values. If not specified, the default value of is used. The algorithm compares this value to the sessionType.
When passed to the method as the ArrayBuffer response parameter, the JSON string MUST be encoded in UTF-8 as specified in the Encoding specification [[!ENCODING]]. Applications MAY encode the JSON string using the [[!ENCODING]].
The following example is a JWK Set containing a single symmetric key. (Line breaks are for readability only.)
{ "keys": [{ "kty":"oct", "alg":"A128KW", "k":"GawgguFyGrWKav7AX4VKUg" "kid":"67ef0gd8pvfd0", }], "type": }
For more information on base64url and working with it, see the "Base64url Encoding" terminology definition and "Notes on implementing base64url encoding without padding" in [[JWS]]. Specifically, there is no '=' padding, and the characters '-' and '_' MUST be used instead of '+' and '/', respectively.
User Agent and Key System implementations must consider , , responses (i.e. data passed to ), licenses, key data, and all other data provided by the application as untrusted content and potential attack vectors. They must use appropriate safeguards to mitigate any associated threats and take care to safely parse, decrypt, etc. such data. User Agents SHOULD validate data before passing it to the CDM, especially if the CDM does not run in the same (sandboxed) context as the DOM (i.e. rendering).
Implementations MUST NOT return active content or passive content that affects program control flow to the application. For example, it is not safe to expose URLs or other information that may have come from media data, such as is the case for the passed to . Applications must determine the URLs to use. The attribute of the event can be used by the application to select among a set of URLs if applicable.
User Agents are responsible for providing users with a secure way to browse the web. Since User Agents may integrate with third party CDM implementations, CDM implementers must provide sufficient information and controls to user agent implementers to enable them to properly asses the security implications of integrating with the Key System.
Unsandboxed CDMs (or CDMs that use platform features) and UAs that use them must be especially careful in all areas of security, including parsing of key and media data, etc. due to the potential for compromises to provide access to OS/platform features, interact with or run as root, access drivers, kernel, firmware, hardware, etc., all of which may not be written to be robust against hostile software or web-based attacks. Additionally, CDMs may not be updated with security fixes as frequently, especially when part of the OS, platform or hardware.
User agents may choose to only support the EME APIs and/or specific Key Systems (i.e. based on privacy and security risks) on secure origins. This is especially important if a user agent chooses to support a Key System implementation that cannot be sufficiently sandboxed or otherwise secured. Such user agents should also properly handle Mixed Content [[MIXED-CONTENT]] to avoid potential exposure to insecure content. See also Use Secure Origin and Transport.
If a user agent chooses to support a Key System implementation that cannot be sufficiently sandboxed or otherwise secured, the user agent should ensure that users are fully informed and/or give explicit consent before loading or invoking it. See also User Alerts / Prompts.
The presence or use of Key Systems on a user's device raises a number of privacy issues, falling into two categories: (a) user-specific information that may be disclosed by the EME interface itself, or within messages from Key Systems and (b) user-specific information that may be persistently stored on the users device.
User Agents should take responsibility for providing users with adequate control over their own privacy. Since User Agents may integrate with third party CDM implementations, CDM implementers must provide sufficient information and controls to user agent implementers to enable them to implement appropriate techniques to ensure users have control over their privacy, including but not limited to the techniques described below.
Concerns regarding information disclosed by EME and Key Systems fall into two categories, concerns about non-specific information that may nevertheless contribute to the possibility of fingerprinting a user agent or device and user-specific information that may be used directly for user tracking.
Malicious applications may be able to fingerprint users or user agents by detecting or enumerating the list of Key Systems that are supported and related information. If proper origin protections are not provided this could include detection of sites that have been visited and information stored for those sites. In particular, Key Systems MUST not share key or other data between origins.
CDMs, especially those implemented outside the user agent, may not have the same fundamental isolations as the web platform. It is important that steps be taken to avoid information leakage, especially across origins. This includes both in-memory and stored data. Failure to do so could lead to information leakage to/from Incognito/Private Browsing sessions, across profiles, and even across different browsers, applications, and operating system user accounts.
To avoid such issues, user agent and CDM implementations MUST ensure that:
User-specific information may be obtained over the EME API in two ways: through detection of stored keys and through Key System messages.
Key Systems may access or create persistent or semi-persistent identifiers for a device or user of a device. In some cases these identifiers may be bound to a specific device in a secure manner. If these identifiers are present in Key System messages, then devices and/or users may be tracked. If the mitigations below are not applied this could include both tracking of users / devices over time and associating multiple users of a given device. If not mitigated, such tracking may take three forms depending on the design of the Key System:
If a Key System permits keys to be stored and to be re-used between origins, then it may be possible for two origins to collude and track a unique user by recording their ability to access a common key.
Finally, if any user interface for user control of Key Systems presents data separately from data in HTTP session cookies or persistent storage, then users are likely to modify site authorization or delete data in one and not the others. This would allow sites to use the various features as redundant backup for each other, defeating a user's attempts to protect his privacy.
There are a number of techniques that can be used to mitigate these risks of tracking without user consent:
While these suggestions prevent trivial use of this feature for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user during a session, and can then pass all this information to a third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, and if identifiers are not per-origin, then a profile can still be created.
It is important to note that identifiers that are non-clearable, non-origin-specific or hardware-bound exceed the tracking impact of existing techniques such as cookies or session identifiers embedded in URLs.
Thus, in addition to the various mitigations described above, if a browser supports a mode of operation intended to preserve user anonymity, then User Agent implementers should carefully consider whether access to Key Systems should be disabled in this mode. For example, such modes MAY prohibit creation of MediaKeySystemAccess objects that are or use a (either as part of the CDM implementation or because the application them).
Identifiers are sometimes obtained via a process called individualization or provisioning. In all cases, implementations should avoid sending per-origin information to centralized servers since this could create a central record of all origins visited by a user or device.
Per-origin individualization (resulting in a per-origin identifier) can - with appropriate precautions - provide better privacy than other individualization models. To preserve the benefits of such a design and to avoid introducing other privacy concerns:
Such implementations should not use identifiers for a device or user of a device in the individualization process.
Such implementations and the applications that support them should also avoid deferring or forwarding the individualization process to a central server or other server not controlled by the application author.
Key Systems may store information on a user's device, or user agents may store information on behalf of Key Systems. Potentially, this could reveal information about a user to another user of the same device, including potentially the origins that have used a particular Key System (i.e. sites visited) or even the content that has been decrypted using a Key System.
If information stored by one origin affects the operation of the Key System for another origin, then potentially the sites visited or content viewed by a user on one site may be revealed to another, potentially malicious, site.
There are a number of techniques that can be used to mitigate these privacy risk to users:
User agent and CDM implementations that allow the CDM to persist data:
In order to protect identifiers and other information discussed in previous sections, user agents MAY choose to only support the EME APIs and/or specific Key Systems (i.e. based on privacy and security risks) on secure origins. This is especially important if a user agent chooses to support a Key System implementation that exposes identifiers or other such information without effectively anonymizing it in transit (i.e. without encrypting identifiers).
Regardless of user agent limitations, applications should use secure transport (e.g. HTTPS) for all traffic containing messages from the CDM (i.e. all data passed from events and to ).
All user agents should properly handle Mixed Content [[MIXED-CONTENT]] to avoid exposure to insecure content or transport when the user agent or application wish to enforce secure origin and transport.
This section contains example solutions for various use cases using the proposed extensions. These are not the only solutions to these use cases. Video elements are used in the examples, but the same would apply to all media elements. In some cases, such as using synchronous XHR, the examples are simplified to keep the focus on the extensions.
In this simple example, the source file and clear-text license are hard-coded in the page. Only one session will ever be created.
<script> function load() { var video = document.getElementById("video"); if (!video.) { navigator.("org.w3.clearkey").then( function(keySystemAccess) { var promise = keySystemAccess.(); promise.catch( console.error.bind(console, "Unable to create MediaKeys") ); promise.then( function(createdMediaKeys) { return video.(createdMediaKeys); } ).catch( console.error.bind(console, "Unable to set MediaKeys") ); promise.then( function(createdMediaKeys) { var initData = new Uint8Array([ ... ]); var keySession = createdMediaKeys.(); keySession.addEventListener("", handleMessage, false); return keySession.("webm", initData); } ).catch( console.error.bind(console, "Unable to create or initialize key session") ); } } ); } function handleMessage(event) { var keySession = event.target; var license = new Uint8Array([ ... ]); keySession.(license).catch( console.error.bind(console, "update() failed") ); } </script> <body onload="load()"> <video src="foo.webm" autoplay id="video"></video> </body>
This example selects a supported using the method then uses the from the to generate the license request and send it to the appropriate license server. One of the supported key systems uses a serverCertificate, which is provided proactively.
<script> var licenseUrl; var serverCertificate; // Returns a Promise<MediaKeys>. function createSupportedKeySystem() { someSystemOptions = [ { : "webm", : "video/webm; codecs='vp8, vorbis'" } ]; clearKeyOptions = [ { : "webm", : "video/webm; codecs='vp8, vorbis'" } ]; navigator.("com.example.somesystem", someSystemOptions).then( function(keySystemAccess) { licenseUrl = "https://license.example.com/getkey"; serverCertificate = new Uint8Array([ ... ]); return keySystemAccess.(); } ).catch( function(error) { // Try the next key system. navigator.("org.w3.clearkey", clearKeyOptions).then( function(keySystemAccess) { licenseUrl = "https://license.example.com/clearkey/request"; return keySystemAccess.(); } ); } ).catch( console.error.bind(console, "Unable to instantiate a key system supporting the required combinations") ); } function handleInitData(event) { var video = event.target; if (video.mediaKeysObject === undefined) { video.mediaKeysObject = null; // Prevent entering this path again. video.pendingSessionData = []; // Will store all initData until the MediaKeys is ready. createSupportedKeySystem().then( function(createdMediaKeys) { video.mediaKeysObject = createdMediaKeys; if (serverCertificate) createdMediaKeys.(serverCertificate); for (var i = 0; i < video.pendingSessionData.length; i++) { var data = video.pendingSessionData[i]; makeNewRequest(video.mediaKeysObject, data.initDataType, data.initData); } video.pendingSessionData = []; return video.(createdMediaKeys); } ).catch( console.error.bind(console, "Failed to create and initialize a MediaKeys object") ); } addSession(video, event., event.); } function addSession(video, initDataType, initData) { if (video.mediaKeysObject) { makeNewRequest(video.mediaKeysObject, initDataType, initData); } else { video.pendingSessionData.push({initDataType: initDataType, initData: initData}); } } function makeNewRequest(mediaKeys, initDataType, initData) { var keySession = mediaKeys.(); keySession.addEventListener("", licenseRequestReady, false); keySession.(initDataType, initData).catch( console.error.bind(console, "Unable to create or initialize key session") ); } function licenseRequestReady(event) { var request = event.; var xmlhttp = new XMLHttpRequest(); xmlhttp.keySession = event.target; xmlhttp.open("POST", licenseUrl); xmlhttp.onreadystatechange = function() { if (xmlhttp.readyState == 4) { var license = new Uint8Array(xmlhttp.response); xmlhttp.keySession.(license).catch( console.error.bind(console, "update() failed") ); } } xmlhttp.send(request); } </script> <video src="foo.webm" autoplay ="handleInitData(event)"></video>
Initialization is much simpler if encrypted events do not need to be handled during MediaKeys initialization. This can be accomplished either by providing the in other ways or setting the source after the MediaKeys object has been created. This example does the latter.
<script> var licenseUrl; var serverCertificate; var mediaKeys; // See the previous example for implementations of these functions. function createSupportedKeySystem() { ... } function makeNewRequest(mediaKeys, initDataType, initData) { ... } function licenseRequestReady(event) { ... } function handleInitData(event) { makeNewRequest(mediaKeys, event., event.); } createSupportedKeySystem().then( function(createdMediaKeys) { mediaKeys = createdMediaKeys; var video = document.getElementById("v"); video.src = "foo.webm"; if (serverCertificate) mediaKeys.(serverCertificate); return video.(mediaKeys); } ).catch( console.error.bind(console, "Failed to create and initialize a MediaKeys object") ); </script> <video id="v" autoplay ="handleInitData(event)"></video>
This is a more complete example showing all events being used.
Note that handleMessage()
could be called multiple times, including in response to the call if multiple round trips are required and for any other reason the Key System might need to send a message.
<script> var licenseUrl; var serverCertificate; var mediaKeys; // See previous examples for implementations of these functions. // createSupportedKeySystem() additionally sets renewalUrl. function createSupportedKeySystem() { ... } function handleInitData(event) { ... } // This replaces the implementation in the previous example. function makeNewRequest(mediaKeys, initDataType, initData) { var keySession = mediaKeys.(); keySession.addEventListener("", handleMessage, false); keySession.addEventListener("", handleKeysChange, false); keySession..then( console.log.bind(console, "Session closed") ); keySession.(initDataType, initData).catch( console.error.bind(console, "Unable to create or initialize key session") ); } function handleMessageResponse(keySession, response) { var license = new Uint8Array(response); keySession.(license).catch( function(err) { console.error("update() failed: " + err); } ); } function sendMessage(type, message, keySession) { var url = licenseUrl; if (type == ) url = renewalUrl; xmlhttp = new XMLHttpRequest(); xmlhttp.keySession = keySession; xmlhttp.open("POST", url); xmlhttp.onreadystatechange = function() { if (xmlhttp.readyState == 4) handleMessageResponse(xmlhttp.keySession, xmlhttp.response); } xmlhttp.send(message); } function handleMessage(event) { sendMessage(event., event., event.target); } function handleKeysChange(event) { event.target.().then( function(keyIdSequence) { // Process keyIdSequence and respond appropriately. } ).catch( console.error.bind(console, "Failed handling usable keys change") ); } function handleError(event) { // Report and do some bookkeeping with event.target. if necessary. } createSupportedKeySystem().then( function(createdMediaKeys) { mediaKeys = createdMediaKeys; var video = document.getElementById("v"); video.src = "foo.webm"; if (serverCertificate) mediaKeys.(serverCertificate); return video.(mediaKeys); } ).catch( console.error.bind(console, "Failed to create and initialize a MediaKeys object") ); </script> <video id="v" autoplay ="handleInitData(event)"></video>
This example requests a persistent license for future use and stores it. It also provides functions for later retrieving the license and for destroying it.
<script> var licenseUrl; var serverCertificate; var mediaKeys; // See the previous examples for implementations of these functions. // createSupportedKeySystem() additionally sets : in each options dictionary. function createSupportedKeySystem() { ... } function sendMessage(message, keySession) { ... } function handleMessage(event) { ... } function handleError(event) { ... } // Called if the application does not have a stored sessionId for the media resource. function makeNewRequest(mediaKeys, initDataType, initData) { var keySession = mediaKeys.(); keySession.addEventListener("", handleMessage, false); keySession..then( function() { console.log("Session " + this. + " closed"); }.bind(keySession) ); keySession.(initDataType, initData).then( function() { // Store this. in the application. }.bind(keySession) ).catch( console.error.bind(console, "Unable to create or initialize a persistable key session") ); } // Called if the application has a stored sessionId for the media resource. function loadStoredSession(mediaKeys, sessionId) { var keySession = mediaKeys.(); keySession.addEventListener("", handleMessage, false); keySession..then( console.log.bind(console, "Session closed") ); keySession.(sessionId).then( function(loaded) { if (!loaded) { console.error("No stored session with the ID " + sessionId + " was found."); // The application should remove its record of |sessionId|. return; } } ).catch( console.error.bind(console, "Unable to load or initialize the stored session with the ID " + sessionId) ); } // Called when the application wants to stop using the session without removing the stored license. function closeSession(keySession) { keySession.(); } // Called when the application wants to remove the stored license. // The stored session data has not been completely removed until the promise returned by remove() is fulfilled. // The remove() call may initiate a series of messages to/from the server that must be completed before this occurs. function removeStoredSession(keySession) { keySession.().then( function() { console.log("Session " + this. + " removed"); // The application should remove its record of this.. }.bind(keySession) ).catch( console.error.bind(console, "Failed to remove the session") ); } // This replaces the implementation in the previous example. function handleMessageResponse(keySession, response) { var license = new Uint8Array(response); keySession.(license).then( function() { // If this was the last required message from the server, the license is // now stored. Update the application state as appropriate. } ).catch( console.error.bind(console, "update() failed") ); } createSupportedKeySystem().then( function(createdMediaKeys) { mediaKeys = createdMediaKeys; var video = document.getElementById("v"); if (serverCertificate) mediaKeys.(serverCertificate); return video.(mediaKeys); } ).catch( console.error.bind(console, "Failed to create and initialize a MediaKeys object") ); </script> <video id="v" src="foo.webm" autoplay></video>
Version | Comment |
---|---|
10 October 2014 | Converted to ReSpec. |
3 September 2014 | Reorganized by object. |
27 August 2014 | Moved license request generation and session loading to MediaKeySession. |
18 August 2014 | Produced candidate WD. |
14 April 2014 | Use promises. |
1 April 2014 | Moved Container Guidelines to the Encrypted Media Extensions Stream Format and Initialization Data Format Registry. |
3 February 2014 | Produced candidate WD. |
17 September 2013 | Produced candidate WD. |
6 May 2013 | Produced updated candidate FPWD. |
14 January 2013 | Produced candidate FPWD. |
16 August 2012 | Converted to the object-oriented API. |
0.1b | Last non-object-oriented revision. |
0.1a | Corrects minor mistakes in 0.1. |
0.1 | Initial Proposal |