[Bug 25409] Allow applications to detect whether a key is usable before using it to decrypt content

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25409

--- Comment #1 from David Dorwin <ddorwin@google.com> ---
Below is my proposal, which is adapted from
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092#c1. This bug addresses use
cases other than the original scenario in that bug, and I think we should
considered solutions independent of the outcome of bug 25092.


* Add a simple event named something to the effect of “usablekeyschange”.
* Add an attribute to MediaKeySession: usableKeyIds.
  - readonly attribute Array<Uint8Array> usableKeyIds; // An array of usable
key IDs, which are Uint8Arrays.
* Whenever the set of usable keys in a session changes - whether through a new
license, license expiration, output changes, etc. - the CDM will update the
usableKeyIds attribute and fire the “usablekeyschange” event.
* When an application receives the “usablekeyschange” event (or at any other
time), it checks the usableKeyIds attribute for the usable key IDs.
  - The application should probably stop fetching and providing content
requiring any missing key IDs or request a new license.

Content using key IDs not listed in usableKeyIds does not necessarily fail
(this would be indicated by an error event), but the application should stop
providing such content.

In addition to some of the more obvious use cases, this also addresses some of
the use cases associated with the removed “ready” event (without the ambiguity
that led it to be removed).

It could also address things like license expiration (currently a proposed
error in bug 21798). The only issue is that there is no indication of why a key
ID is not usable. (We might be able to add this later if implementation
experience shows that it is really necessary. Or, we can also fire an “error”
event.)

This may even address the use cases for adding a |capability| parameter to
isTypeSupported() as outlined in bug 24873.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 21 April 2014 22:54:08 UTC