Content Decryption Module (CDM)

Content Decryption Module (CDM) is the client component that provides the functionality, including decryption, for one or more Key Systems. Note 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.

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 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. Note For example, "com.example.somesystem". Note 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.

Key Session

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 MediaKeySession objects. Each Key session is associated with a single instance of Initialization Data provided in the generateRequest() call. Each Key Session is associated with a single MediaKeys object, and only media element(s) associated with that MediaKeys object may access key(s) associated with the session. Other 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 for decryption once the session has been closed, including when the MediaKeySession object is destroyed. All license(s) and key(s) associated with a Key Session which have not been explicitly stored MUST be destroyed when the Key Session is closed. Key IDs MUST be unique within a session.

Session ID

A Session ID is a unique string identifier generated by the CDM that can be used by the application to identify MediaKeySession 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. 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. Note The underlying content protection protocol does not necessarily need to support Session IDs.

Key

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.) Note 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.

Usable For Decryption

A key is considered usable for decryption if the CDM is certain the key is currently usable to decrypt one or more blocks of media data. Note For example, a key is not usable for decryption if its license has expired. Even if its license has not expired, a key is not usable for decryption if other conditions (e.g., output protection) for its use are not currently satisfied.

Key ID

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.

Known Key

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 keyStatuses attribute. 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. Note 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.

License

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.

Initialization Data

Note 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-INITDATA-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 encrypted event. 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 generateRequest() . 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-specific data, or executable code. Initialization Data SHOULD NOT contain Key System-specific data or values. Implementations MUST support the common formats defined in [ EME-INITDATA-REGISTRY ] for each Initialization Data Type they support. Note 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 client devices that do not support the common formats.

Associable Values

Two or more identifiers or other values are said to be associable if they are identical or it is possible - with a reasonable amount of time and effort - to correlate or associate them. Otherwise, the values are non-associable . Note For example, values created in the following ways are associable: Using a trivially-reversible hash function.

Sharing a prefix or other subset

Replacing random value N with N+10

XORing the origin with a fixed value (because it is trivially reversible) In contrast, two values that are completely unrelated or cryptographically distinct, such as via a cryptographically strong non-reversible hash function, are non-associable. Two or more identifiers or other values are said to be associable by an entity if it is possible - with a reasonable amount of time and effort - for the referenced entity or set of entities to correlate or associate them without participation of additional entity(ies). Otherwise, the values are non-associable by an entity . Two or more identifiers or other values are said to be non-associable by the application if they are non-associable by an entity where the entity is set that includes the application, all other applications, and other entities such as servers that they use or with which they communicate. Otherwise, the values would be considered associable by the application , which is forbidden.

Distinctive Value

A Distinctive Value is a value, piece of data, implication of the possession of a piece of data, or an observable behavior or timing that is not shared across a large population of users or client devices. A Distinctive Value may be in memory or persisted. Note Examples of Distinctive Values include but are not limited to: Distinctive Identifiers

Distinctive Permanent Identifiers

Other identifiers

Session IDs

Licenses

Other session data Note While a Distinctive Value is typically unique to a user or client device, a value does not need to be strictly unique to be distinctive. For example, a value shared among a small number of users could still be distinctive.

Permanent Identifiers

A Permanent Identifier is a value, piece of data, implication of the possession of a piece of data, or an observable behavior or timing that is indelible in some way or otherwise non-trivial for the user to remove, reset, or change. This, includes but is not limited to: A hardware or hardware-based identifier

A value provisioned in the hardware device in the factory

A value associated with or derived from the operating system installation instance

A value associated with or derived from the user agent installation instance

A value associated with or derived from the CDM or other software component

A value in a configuration file or similar semi-permanent data, even if generated on the client

Client or other user account values A Distinctive Permanent Identifier is a Permanent Identifier that is distinctive. When exposed outside the client, Distinctive Permanent Identifiers and values derived from or otherwise related to them MUST be encrypted. Distinctive Permanent Identifiers MUST NOT ever be exposed to the application, even in encrypted form. Note While a Distinctive Permanent Identifier is typically unique to a user or client device, a Distinctive Permanent Identifier does not need to be strictly unique to be distinctive. For example, a Distinctive Permanent Identifier shared among a small number of users could still be distinctive. Note A Distinctive Permanent Identifier is not a Distinctive Identifier because it is not derived or generated (within the scope of this specification). Note distinctiveIdentifier controls whether Distinctive Permanent Identifiers may be used. Specifically, Distinctive Permanent Identifiers may only be used when the value of the distinctiveIdentifier member of the MediaKeySystemAccess used to create the MediaKeys object is "required" .

Distinctive Identifier

Use of Distinctive Identifiers and Distinctive Permanent Identifiers

An implementation, configuration, instance, or object uses Distinctive Identifier(s) if, at any time during its lifetime or the lifetime of related such entities, it exposes, even in encrypted form, one or more Distinctive Identifier(s), information about them, or values derived from or otherwise related to them outside the client. This includes but is not limited to providing such a value to the application and/or license, individualization, or other server. An implementation, configuration, instance, or object uses Distinctive Permanent Identifier(s) if, at any time during its lifetime or the lifetime of related such entities, it exposes, even in encrypted form, one or more Distinctive Permanent Identifier(s), information about them, or values derived from or otherwise related to them outside the client. This includes but is not limited to providing such a value to an individualization server. Such values MUST NOT be provided to the application. An implementation, configuration, instance, or object uses Distinctive Identifier(s) or Distinctive Permanent Identifier(s) if it uses Distinctive Identifier(s) and/or uses Distinctive Permanent Identifier(s). Note distinctiveIdentifier controls whether Distinctive Identifiers and Distinctive Permanent Identifiers may be used. Specifically, such identifiers may only be used when the value of the distinctiveIdentifier member of the MediaKeySystemAccess used to create the MediaKeys object is "required" .

Cross Origin Limitations

During playback, embedded media data is exposed to script in the embedding origin. In order for the API to provide Initialization Data in the encrypted event, media data MUST be CORS-same-origin with the embedding page. If media data is cross-origin with the embedding document, authors SHOULD use the crossorigin attribute on the HTMLMediaElement and CORS headers on the media data response to make it CORS-same-origin.

Mixed Content Limitations

During playback, embedded media data is exposed to script in the embedding origin. In order for the API to provide Initialization Data in the encrypted event, media data MUST NOT be Mixed Content [ MIXED-CONTENT ].

Time

Time MUST be equivalent to that represented in ECMAScript Time Values and Time Range [ ECMA-262 ]. Time will equal NaN if no such time exists or if the time is indeterminate. It should never have the value Infinity . Note Time generally represents an instant in time with millisecond accuracy; however, that alone is not a sufficient definition. The defined Time Values and Time Range reference adds other important requirements.

Expiration Time

The time after which key(s) will no longer be usable for decryption.

Browsing Profile

A User Agent on a given machine may support execution in a variety of different contexts or modes or temporary states that are expected to behave independently with respect to application-visible state and data. In particular, all stored data is expected to be independent. In this specification we refer to such independent contexts or modes as "Browsing Profiles". Note Examples of such independent contexts include if the user agent is running in different operating system user accounts or if the user agent provides the capability to define multiple independent profiles for a single account.

Valid Media MIME Type