Re: [EME] Key Release

On Jun 11, 2012, at 11:57 PM, David Dorwin wrote:

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

The Key Release portion (http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-release) of the proposal hasn't received a lot of feedback, so I'd like to start a discussion about it.

Section 4.1 gives a good overview of the problem. Briefly, the goal is the provide the application with secure proof that a key is no longer present on the client ("released"). The application must also be able to ACK proofs. One particular thing to note is that proofs are not related to any particular media element. In addition, the current API proposal does not associate key release with HTMLMediaElement or any other object.

Some possible topics for discussion:
 * Multiple KeyReleaseManagers could be created, but they would all represent the same data. How might we make KeyReleaseManager global or a singleton?

I would like to better understand what is the "normal" way to do this ? Should this be window.mediakeyreleasemanager ? What are the issues with that ?

 * While not related to HTMLMediaElement from an API point of view, key release would need to be tightly integrated with the implementation underlying the rest of the proposal, which is related to HTMLMediaElement.
   - What is the impact on implementations?
   - How might we more closely associate key release with HTMLMediaElement and/or the rest of the EME implementation?

If it makes a significant difference for implementations then this could be dealt with using methods on HTMLMediaElement, with the consequence that you might need to create a "dummy" HTMLMediaElement to get access to the proof of key release messages.

 * How might representing sessions as objects (https://www.w3.org/Bugs/Public/show_bug.cgi?id=16613) affect the design?

I think it makes it clearer, since the "proof of key release" messages are created (and stored in the CDM) exactly when a  "session" is destroyed. In fact they become "proof of session destruction" instead.

…Mark