[encrypted-media] Key System divergence on setServerCertificate() fallback behavior (#573)

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

== Key System divergence on setServerCertificate() fallback behavior ==
EME spec has a special [requirement on setServerCertificate()](https://www.w3.org/TR/encrypted-media/#dom-mediakeys-setservercertificate:~:text=setServerCertificate(),message%22%20Event%20algorithm.):

> [Key Systems](https://www.w3.org/TR/encrypted-media/#dfn-key-system) that use such certificates **MUST** also support requesting the certificate from the server via the [Queue a "message" Event](https://www.w3.org/TR/encrypted-media/#dfn-queue-a-message-event) algorithm.

This is followed by a NOTE:

> This method (`setServerCertificate()`) allows an application to proactively provide a server certificate to implementations that support it to avoid the additional round trip should the [CDM](https://www.w3.org/TR/encrypted-media/#dfn-cdm) request it. **It is intended as an optimization, and applications are not required to use it.**

What this means is that, if the key system uses server certificate, the application could call `setServerCertificate()` to explicit set the server certificate. But this is an optimization instead of a requirement. If the application doesn't call `setServerCertificate()`, the key system MUST support a mechanism to request the certificate via the `message` event.

However in practice, this is not universally supported by key systems. Different key systems have their own way and it's hard to change the implementation, especially at this point.
- For Widevine, this is supported. If a server certificate is required, but setServerCertificate() is NOT called, the CDM will generate a "server certificate request" in the "message" event, where the server will return the server certificate, and then resume the normal license exchange. This is compliant to the requirement above.
- For PlayReady, if setServerCertificate() is not called, the key system will not try to request the certificate from the server, and will use some alternatives for the license exchange.
- For FairPlay, if setServerCertificate() is NOT called, [license exchange will just fail](https://github.com/shaka-project/shaka-player/issues/1940). (Need to double check with Apple owners.)

This requirement was presumably introduced for backward compatibility with legacy applications not calling `setServerCertificate()`. The problem is this specification is disconnected from reality: major key systems are not compliant. This discrepancy will cause unexpected failures for applications that _do follow_ the spec. Moreover, any key system that does implement this behavior will be perpetually burdened with supporting it, defeating the original purpose of a temporary backward compatibility measure.

With that I suggest to change the spec language to be something like:

> For [Key Systems](https://www.w3.org/TR/encrypted-media/#dfn-key-system) that use such certificates, applications SHOULD call `setServerCertificate()` to explicit set the server certificate. Otherwise, license exchange may fail.

> NOTE: Some key system also supports requesting the certificate from the server via the [Queue a "message" Event](https://www.w3.org/TR/encrypted-media/#dfn-queue-a-message-event) algorithm. However, this is not supported by all key systems that use such certificates.

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


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

Received on Friday, 24 October 2025 19:50:27 UTC