[encrypted-media] Clarify definition and intent of "replacement algorithm" in update() (#583)

xhwang-chromium has just created a new issue for https://github.com/w3c/encrypted-media:

== Clarify definition and intent of "replacement algorithm" in update() ==
## Description
The EME specification currently mentions a "replacement algorithm" in the notes for the `update()` method (https://www.w3.org/TR/encrypted-media/#dom-mediakeysession-update):

> 1. "The **replacement algorithm** within a session is Key System-dependent."
> 2. "It is RECOMMENDED that CDM implementations support a standard and reasonably high minimum number of keys per MediaKeySession object, including a standard **replacement algorithm**... 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 (e.g., adaptive streams, various audio and video tracks) using different keys."

However, the term "replacement algorithm" is not defined anywhere in the current specification. This makes it ambiguous for implementers and the behavior unpredictable for web developers.

## Historical Context

Research into the early drafts of the EME spec (circa 2012–2013) reveals that the "replacement algorithm" was intended to refer to key cache eviction policies (specifically LRU - Least Recently Used) to support seamless Key Rotation.

The related text existed in the first commit of the EME spec in 2012 ([8f067598985f3c8dc3832482626537a8f98e74b7](https://github.com/w3c/encrypted-media/blob/8f067598985f3c8dc3832482626537a8f98e74b7/encrypted-media.html)). From the text, it seems that it's for the case that a key for a key ID already existed, and we need to replace that key when update() is called. The following is the quote from the initial EME draft (converted from xml):

> If `key` contains a key or license, store the key.
> 
> 1.  Let `key ID` be null.
> 2.  If `sessionId` is not null and refers to a session with [Initialization Data](#initialization-data) that contains a key ID, let `key ID` be that ID.
> 3.  If `key` is not null and contains a key ID, let `key ID` be that ID.
> 4.  If `initData` is not null and contains a key ID, let `key ID` be that ID.
> 5.  Store the key by following the steps for the first matching condition from the following list:
>     *   **If `key ID` is not null:**
>         1.  Clear any key not associated with a key ID.
>         2.  If a key already exists for `key ID`, delete that element.
>         3.  Store the key and/or license in `key` indexed by `key ID`. The replacement algorithm is [Key System](#key-system)-dependent.
>     *   **Otherwise:**
>         1.  Clear all stored keys.
>         2.  Store the key and/or license in `key` with no associated `key ID`.

> Notes: It is recommended that CDM providers support a standard and reasonably high minimum number of cached keys/licenses (with IDs) per media element as well as a standard replacement algorithm. 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, such as adaptive streams or various audio and video tracks using different keys.

## The Problem
Because this context is now buried in decade-old commits, mailing lists and issue threads, the current spec text is confusing.

It's unclear whether "replacement" simply means overwriting a key with the same key ID, as the text suggested, or some eviction algorithm which is related to "reasonably high minimum number of cached keys/licenses" and "key rotation".

I'd suggest the working group to discuss this and update the notes to make it clear and better matching the current `update()` algorithm.

Please view or discuss this issue at https://github.com/w3c/encrypted-media/issues/583 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 4 May 2026 21:19:18 UTC