Bug 19208 - Keymessage event not needed when Key System already has Key
Keymessage event not needed when Key System already has Key
Status: RESOLVED DUPLICATE of bug 21855
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
PC Windows 3.1
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-02 14:32 UTC by johnsim
Modified: 2013-04-26 21:38 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description johnsim 2012-10-02 14:32:57 UTC
If a session is created activating a Key System CDM and the key storage for that Key System already contains the key associated with the Key ID, then there is no need for the keymessage event. 

If this is correct, this is inconsistent with the current draft of the specification. 

The proposal would be to add the following sentence to the last paragraph of the ISOBMFF Container Guidelines:

Likewise, if createSession() activates a Key System CDM and the key storage for that Key System already contains the key associated with the Key ID, then there is no need for the CDM to generate a keymessage event.
Comment 1 David Dorwin 2013-01-02 22:45:41 UTC
Is the intent to have a valid MediaKeySession without any messages being passed? If so, how would the application know that the session is ready/valid?

Does it make more sense to try to avoid firing events that most likely result in the creation of an unnecessary MediaKeySession? This won't avoid messages in all cases, but it would probably address the most common cases.
Comment 2 David Dorwin 2013-01-02 23:05:06 UTC
We should also consider the case where the key is already available via whatever means but is not represented by a (active) session. Is this allowed? If so, how will the application know that the session is ready? Should keyadded be fired with no keymessage?

Is it possible that a service/application would want to differentiate between different PSSH's (or other Initialization Data) containing the same key ID? (Or no key ID?) Maybe this is not a good idea and thus not allowed.
Comment 3 Mark Watson 2013-01-03 00:19:28 UTC
It seems like a key in the CDM should always be associated with a session - specifically the one that created it.

How about the following:

When createSession is called, if the CDM discovers that there is already a key+session that matches the initData, there are two possibilities:
(i) there already exists a MediaKeySession object for this session
(ii) there is no existing MediaKeySession object for this session

For (i), perhaps we should just return the existing MediaKeySession ?

For (ii), a new MediaKeySession object should be created for this session and that object should be in the same state that it was last time a MediaKeySession existed for that session.

We could consider having a readystate attribute on the MediaKeySession. The states I can think of are NOT_READY, READY, ERROR and CLOSED:
NOT_READY: the session does not yet have the key material called for by the initData
READY: the session has the key material called for by the initData
ERROR: an error occured
CLOSED: close() was called or the session was otherwise closed and the key(s) destroyed

[We would need to add a final state for secure proof of key release, say COMPLETE]

I think the MediaKeySession definitely has these states. Whether we need to expose them I am not sure: you generally don't wait for the MediaKeySession to be READY before streaming data, as the key might not be needed right away.

The script can tell is the state is NOT_READY or ERROR by the receipt of a keymessage or keyerror. The transition from NOT_READY to READY is marked by the keyadded event. But you cannot know if the state is READY on creation, except by the absence of the keymessage. This doesn't seem very robust.
Comment 4 David Dorwin 2013-01-03 00:42:07 UTC
(In reply to comment #3)
> When createSession is called, if the CDM discovers that there is already a
> key+session that matches the initData, there are two possibilities:
> (i) there already exists a MediaKeySession object for this session
> (ii) there is no existing MediaKeySession object for this session

I don't think scenario (ii) should happen. If the MediaKeySession object has been destroyed, the keys related to that session should have been deleted. This is the equivalent of calling close(). Thus, only (i) should be possible.

> For (i), perhaps we should just return the existing MediaKeySession ?

We previously discussed returning an existing MediaKeySession object, but it raises a lot of questions and involves the particularly thorny issue of synchronous calls to the CDM. See http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0133.html
Comment 5 Mark Watson 2013-01-03 01:15:23 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > When createSession is called, if the CDM discovers that there is already a
> > key+session that matches the initData, there are two possibilities:
> > (i) there already exists a MediaKeySession object for this session
> > (ii) there is no existing MediaKeySession object for this session
> 
> I don't think scenario (ii) should happen. If the MediaKeySession object has
> been destroyed, the keys related to that session should have been deleted.
> This is the equivalent of calling close(). Thus, only (i) should be possible.

That's fine for me.

I can imagine scenarios where you need (ii) - for example licenses for offline use. In those cases, closing the browser doesn't delete the key from the CDM.

> 
> > For (i), perhaps we should just return the existing MediaKeySession ?
> 
> We previously discussed returning an existing MediaKeySession object, but it
> raises a lot of questions and involves the particularly thorny issue of
> synchronous calls to the CDM. See
> http://lists.w3.org/Archives/Public/public-html-media/2012Jun/0133.html

Ok, yes, I see.

The thread doesn't quite conclude, though.

One option is that we require that the application knows whether a new license exchange is required or not. If the application creates a new MediaKeySession with the same initData it's because it really wants a new license exchange for those same keys (for some reason). In that case we would close this bug with WONTFIX.

Another option would be to allow multiple MediaKeySession objects to refer to the same underlying key information. In this case the keyadded would be fired on the newly created MediaKeySession - i.e. it autonomously transitions from NOT_READY to READY when the CDM has processed the initData and determined that it already has the keys.

In this second case we need to deal with the possibility of multiple MediaKeySession JS objects referring to the same key. Do they refer to the same session ?

We might want to allow the sessionId attribute to be null when the object is first created and only obtain a value when the first message is fired. This would allow the sessionId to be determined asynchronously by the CDM.
Comment 6 Adrian Bateman [MSFT] 2013-02-12 13:44:15 UTC
*** Bug 20964 has been marked as a duplicate of this bug. ***
Comment 7 David Dorwin 2013-03-10 05:16:30 UTC
Is the goal of this bug to avoid creating a duplicate session? If so, would it be better to address this in bug 16553?

I don't think we can guarantee that the CDM knows whether it has all the keys associated with the Initialization Data provided to createSession(). The best we might be able to do is determine whether a license request (keymessage) for the exact same Initialization Data has been sent. We might be able to get closer to the original bug summary by checking existing sessions that have received a license to see if they were started with identical Initialization Data.

Still, there might be legitimate use cases where an application really wants a new request. As with bug 16553, how much burden is it on an application to compare (and possibly track) Initialization Data to avoid calling createSession() multiple times for the same data?
Comment 8 Adrian Bateman [MSFT] 2013-04-23 17:10:42 UTC
(In reply to comment #7)
> Is the goal of this bug to avoid creating a duplicate session? If so, would
> it be better to address this in bug 16553?

Yes, I think the goal is to avoid duplicate sessions, but I think we wanted to avoid having firing needkey interact with a CDM. The initData may contain information for more than one key system.
Comment 9 David Dorwin 2013-04-24 18:14:11 UTC
This was discussed in the March 12th telecon, but no decision was reached. Adrian has an action [2] to discuss this with John.

[1] http://www.w3.org/2013/03/12-html-media-minutes.html#item05)
[2] https://www.w3.org/html/wg/media/track/actions/10
Comment 10 David Dorwin 2013-04-26 21:38:18 UTC
We will address the general issue in bug 21855.

*** This bug has been marked as a duplicate of bug 21855 ***