Re: ACTION-5: key release

On Tue, Sep 4, 2012 at 4:22 PM, Mark Watson <watsonm@netflix.com> wrote:

> http://www.w3.org/html/wg/media/track/actions/5
>
> All,
>
> The status of this action is that I have provided a proposal as a comment
> to the bug [1]. For ease of reference I've copied the proposal here, but
> please make comments in the bug, or on the call today.
>
> …Mark
>
> If key release is supported, then
> (i) when the MediaKeySession.close() method is called, the session enters a
> "key release pending" state and a keymessage event is fired on the
> MediaKeySession, containing the key release object
> (ii) when the application receives the key release acknowledgement from the
> server the session is updated with this message using the addKey() method
> (or
> update(), if we rename it as per bug 18531 [2]). The MediaKeySession
> enters a
> "key release complete" state
> (iii) a new method is added to MediaKeys: MediaKeySession?
> retrieveClosedSession() which will retrieve a MediaKeySession object in
> the key
> release pending state. Subsequent calls to this method will retrieve
> further
> sessions in the 'key release pending state' until none are left (we could
> consider returning a list of MediaKeySession objects). A keymessage event
> is
> fired on each MediaKeySession retrieved with this method containing the key
> release object.
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
> [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18531
>

I replied based on earlier discussions related to the object-oriented API.
The text is below. The main difference relates to retrieving stored key
release proofs.

Comments on Comment 4:
 * (i) and (ii): Do we need to define official states or are those
non-normative?
 * (i) and (ii): I don't think the key release is "pending" or "complete"
(it
is the ack is pending or complete). Would "provided" and "ACKed" be better
names?
 * (iii): I would prefer to avoid adding more methods, especially since not
all
implementations will support key release. I propose a solution below.

The active key session stuff in (i) and (ii) seems fine. For stored
sessions, I
propose reusing CreateKeySession() - To get stored key release proofs, pass
"keyrelease" as the "type" parameter to createSession().^ The new session
object is populated with the relevant information (keySystem, sessionId),
and a
keymessage with the key release proof is fired at it. The application could
make the same call repeatedly until an exception occurs, which indicates
that
there are no such sessions.^^ A simple example to obtain a single proof is
shown below.
    var mediaKeys = new MediaKeys("com.example.somesystem");
    try {
      var releasedSession = mediaKeys.createSession("keyrelease");
      releasedSession.onkeymessage="handleKeyRelease(event)";
    }

It should probably be made clear that this is an optional recommendation for
how to support key release use cases (similar to the recommendations for
heartbeat). The details of proof storage, etc. are implementation-dependent,
but stored sessions must only ever be provided to the same origin.


^ This requires minor modification of step 1 of the current
CreateKeySession()
algorithm because the second parameter is not present.
^^ An alternative to this call-until-exception flow would be to expose a
list
of MediaKeySessions from MediaKeys (potentially useful for other scenarios?)
then have createSession("keyreleases") populate that list. The application
would need to immediately iterate through the list and add a handler to each
object.