Re: [EME] Exposing key status to applications

HI David, all,

I spoke with out HTML5 player team their basic feedback is that they would much
rather have list of all known keys and their status. Although one can
derive "invalid keys" from the facts of passing it it, and it not being
available... having a clear indication of what keys are known and what
their status is makes it much easier to troubleshoot, especially
troubleshoot from logs without repro.

Personally, I would think a simple API that would achieve this would look
like a Key ID -> Status map that can be synchronously accessed, with events
when it changes. So, if session is my MediaKeySession, I would be able to
do things like

var mykeystatus = session.keys[ myKeyId ];

and

for ( keyId in session.keys ) { ... }

I would also expect assignments to this map or to its members throw
exceptions, so we do not have to worry about copying it, others making
changes etc.

Is this possible with JS / WebIDL ?

...Mark


On Thu, Sep 25, 2014 at 2:31 PM, David Dorwin <ddorwin@google.com> wrote:

> tl;dr: We are seeking feedback from application authors on the best way to
> provide them with information about key availability (based on license
> policies).
>
> *Background*
> With the introduction of promises to EME, most errors are reported by
> rejecting the promises returned by the methods. The remaining "errors" are
> related to key validity issues, such as expiration and output protection.
> Bug 26372 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372> was
> filed to identify a solution. The current proposals involve providing
> status/reason information via an extension to the "keyschange"
> event/getUsableKeyIds() mechanism currently defined in the spec.
>
> *Questions for **Application Authors*
>
>    1. Would you prefer to have just a list of valid/usable keys or to
>    have a list of all known keys with an indication of whether they are valid
>    (and the reason for those that are not)?
>    2. How important is it to have access to the status per-key [ID] vs.
>    just the reason for a change in the available keys?
>    3. How would you prefer to receive/obtain key status information?
>       1. Simple event and calling a method
>       2. Per-status change event containing all affected keys with the
>       same status
>       3. Per-key per-status change event
>       4. Via change records (similar to Object.observe(); see Option 5
>       below)
>    4. Would you prefer key IDs to be provided as binary ArrayBuffers
>    (i.e. Uint8Array) or a base64url-encoded string?
>    - Context: Although it feels natural to represent the binary ID in an
>       ArrayBuffer, it's unclear whether this is the best solution for
>       applications. If the application wants to track events, it might be simpler
>       to just compare and/or index by a base64url-encoded representation of the
>       key ID. It may even use this format to communicate to the server. Returning
>       a DOMString or string representation in a JSON Object may make more sense
>       for applications and avoid unnecessary conversions. Since the purpose of
>       this event/method is to allow the application to understand and manage the
>       returned data, I think it's important that the data is easy for the
>       application to use. Of course, the application can always convert an
>       ArrayBuffer to whatever type it needs.
>
>
> Note: In a key rotation scenario, keys from the past that are removed
> would also be removed from any list of key IDs to avoid an indefinitely
> growing list.
>
> *Example Options*
> The following are a sampling of options that have been proposed in no
> particular order.
>
> See comments 17 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c17>
>  and 22 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c22> for
> some of the analysis so far.
>
> In all cases, there is an enum that looks something like this:
> enum MediaKeyStatus { "valid", "expired", "outputprohibited", ... };
>
> *Option 1: "keyschange" event contains a reason for the change*
> IDL:
> *interface MediaKeysChangeEvent : Event {*
> *  readonly attribute MediaKeyStatus reason;*
>
> *};*
>
> function handleKeysChange(event) {
>   *// Process event.reason.*
>   event.target.getUsableKeyIds().then(
>     function(keyIdSequence) {
>       // Process keyIdSequence and respond appropriately.
>     }
>   );
> }
>
> *Option 2: *getKeyStatuses() provides a status for each key
> IDL:
> Promise<sequence<TBD>> getKeyStatuses();
>
> function handleKeysChange(event) {
>   event.target.getKeyStatuses().then(
>     function(keyIdStatusList) {
>       for (var i = 0; i < keyIdStatusList.length; i++) {
> *        if (keyIdStatusList[i].id == ... && keyIdStatusList[i].status !=
> "valid")*
>         {
>           // Do something.
>         }
>       }
>     }
>   );
> }
>
> *Option 3: **"keyschange" event contains a reason for the change and a
> list of all keyIds **affected by this specific change** (getUsableKeyIds()
> is removed)*
> IDL:
>
> *interface MediaKeysChangeEvent : Event {*
> *  readonly attribute MediaKeyStatus status;*
> *  readonly attribute sequence<ArrayBuffer> keyIds;*
> *};*
>
> function handleKeysChange(event) {
>   for (var i = 0; i < event.keyIds.length; i++) {
> *    if (event.keyIds[i] == ... && event.status != "valid")*
>     {
>       // Do something.
>     }
>   }
> }
>
> *Option 4: **"keychange" event is fired for each key whose status changes
> and contains the key ID and status *
> IDL:
> interface MediaKeyChangeEvent : Event {
> *  readonly attribute ArrayBuffer id;*
>   readonly attribute MediaKeyStatus status;
> };
>
> function handleKeyChange(event) {
> *  if (event.id <http://event.id> == ... && event.status != "valid")*
>   {
>     // Do something.
>   }
> }
>
> *Option 5: Object.observe()-like records*
> The exact IDL and mechanism are TBD, but the goal would be to have records
> that look something like the following:
>
> { object: keyList, type: 'add', name: '0123456789abcdef', value: 'valid' },
> { object: keyList, type: 'update', name: '0123456789abcdef', value:
> 'expired', oldValue: 'valid' },
> { object: keyList, type: 'add', name: 'abcdef0101010101', value:
> 'outputnotallowed' },
> { object: keyList, type: 'delete', name: '0123456789abcdef', oldValue:
> 'expired' },
> { object: keyList, type: 'update', name: 'abcdef0101010101', value:
> 'valid', oldValue: 'outputnotallowed' },
>