Encrypted Media Extensions

4. Key Release

4.1. Introduction

This section is non-normative.

The above sections provide for delivery of key/license information to a Content Decryption Module. This section provides for management of the entire key/license lifecycle, that is, secure proof of key release. Use cases for such proof include any service where is it necessary for the service to know, reliably, which granted keys/licences are still available for use by the user and which have been deleted. Examples include a service with restrictions on the number of concurrent streams available to a user or a service where content is available on a rental basis, for use offline.

Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified. The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed. Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received. This acknowledgement must also be in the form of a CDM-specific message.

The mechanism for secure proof of key release operates outside the scope of any media element. This is because proof-of-release messages may be cached in CDMs after the associated media elements have been destroyed. Proof-of-key-release messages are subject to the same origin policy: they shall only be delivered to scripts with the same origin as the script which created the media element that provided the key/license.

4.2 Persistent storage of key release messages

The CDM should maintain an origin-specific persistent store containing information about sessions for which keys which have been deleted, each associated with a sessionId.

Such a store could, for example, consists of a frequently updated list of sessions with keys. By comparing this list with the CDM's list of actually present keys, the CDM can determine the set of keys that have been deleted since the last update of the store.

4.3 Providing a key release message

Whenever a key is deleted, the following steps shall be run:

1. Update the persistent store to indicate that the key associated with the sessionId has been deleted and the time at which this occurred.

2. Construct a proof of key release message, containing proof that the keys and licenses associated with the session were deleted and the time at which they were deleted.

Furthermore, the following step SHOULD be run:

3. queue a task to fire a simple event event named keymessage at the MediaKeySession object containing the message constructed at step one.

   It is expected that in several scnearios, such as key deletion due to browser shutdown, it may not be possible to fire the keymessage event.

4.4 Acknowledging receipt of a key release message

Proof of receipt of the secure proof of key release by the server shall be provided within KeySystem-specific messages using the update method of MediaKeySession. The following steps are added to step 2, substep 4 of the update procedure:

1. For each acknowledgement of receipt of a secure proof of key release in key:

   1. Remove the information associated with sessionId from the persistent store.

4.5 Retrieving stored key release messages

Step 2 of the procedure for the createSession method of MediaKeys is modified by the introduction of a new step after step 1 as follows:

1. If type is equal to the special string "keyrelease", then the retrieve a MediaKeySession with released key(s) procedure shall be executed and the following steps aborted.

4.5.1 Retrieving a MediaKeySession with released keys

When the 'retrieve a MediaKeySession with released key(s)' procedure is to be executed the following steps are run:

1. Create a new MediaKeySession object

   1. Let the keySystem attribute be keySystem

   2. Let the sessionId attribute be null

2. Add the new object to an internal list of session objects

3. Schedule a task to generate a key release message, providing the new MediaKeySession object

   The user agent will asynchronously execute the following steps in the task:

   1. Let cdm be the cdm loaded in the MediaKeys constructor

   2. Let defaultURL be null

   3. Use cdm to retrieve a key release message and follow the steps for the first matching condition from the following list:

      If a key release message is sucessfully generated

      1. Set the MediaKeySession object's sessionId attribute to the sessionId returned by the CDM.

      2. Let keyrelease be the proof of key release message generated by the CDM.

      3. Let defaultURL be the URL returned by the CDM, or null if no URL was returned

      Otherwise

      1. Create a new MediaKeyError object with the following attributes

         • code = the MediaKeyError code returned by the CDM

         • systemCode = a Key System-specific value, if provided by the CDM, and 0 otherwise

      2. Set the MediaKeySession object's error attribute to the MediaKeyError object created in the previous step

      3. queue a task to fire a simple event named keyerror at the MediaKeySession object

      4. Abort the current task

   4. queue a task to fire a simple event named keymessage at the new object

      The event is of type MediaKeyMessageEvent and has:

      • message = keyrelease

      • destinationURL = defaultURL

4. Return the new object to the caller

4.5.2 CDM retrieving a key release message

When a CDM is required to retrieve a key release message it shall perform the following steps:

1. If the persistent store is empty, or if all sessionId values in the persistent store already have MediaKeySession objects associated, then return an error indication with code MEDIA_KEYERR_NOT_FOUND and abort the following steps.

2. Let sessionId be the oldest sessionId in the persistent store for which no MediaKeySession object exists.

3. Generate a proof of key release message, keyrelease, for sessionId.

4. If the persistent store contains a URL associated with sessionId let defaultUrl be that URL.

5. Return sessionId, keyrelease and defaultUrl.