[encrypted-media] generateRequest may result in keys being usable when no key request needs to be sent

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

== generateRequest may result in keys being usable when no key request
 needs to be sent ==
This does not seem to be adequately covered by any of the existing 
issues/bugs.
This is related to 
[bug#27093](https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093).

The issue here is that the initData passed to the CDM in combination 
with other keys it already has may be enough to make the keys usable 
required for the media. When this happens there is no need to send a 
message to the application containing a license request. This has at 
least the following implications for the text:

**6.2 Methods, generateRequest**

*"11. Run the queue a "message" event algorithm on the session, 
providing "license-request" and message."*

Since keys may already be usable, the CDM may instead run the Update 
Key Statuses algorithm. E.g. 

*"11. If keys specified in the initData are not already available, run
 the queue a "message" event algorithm on the session, providing 
"license-request" and message. Otherwise run the Update Key Statuses 
algorithm."*

**6.6.2 Update Key Statuses**

*"This can happen as the result of a load() or update()"*

This list should be augmented with *generateKeyRequest*. 

**6.8 Session Storage and Persistence**

*"The CDM SHOULD NOT store session data, including the Session ID, 
until update() is called the first time. Specifically, the CDM SHOULD 
NOT store session data during the generateRequest() algorithm. This 
ensures that the application is aware of the session and knows it 
needs to eventually remove it."*

This text seems wrong to me. If the application has opened a session 
with a "persistent" modifier, it should call remove() on that session 
if it wants to clean it up. It should not make assumptions about what 
data might be cached related to the session. I would be happy if this 
text was removed completely. 







See https://github.com/w3c/encrypted-media/issues/41

Received on Tuesday, 10 March 2015 17:15:40 UTC