[Bug 17750] Define the behavior MediaKeySession close() and clearing the keys attribute

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

Adrian Bateman [MSFT] <adrianba@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adrianba@microsoft.com

--- Comment #5 from Adrian Bateman [MSFT] <adrianba@microsoft.com> ---
We discussed this bug on the last telcon.

I think there are two parts to this bug. One is how close() might relate to
secure key release. I believe that this should be handled as part of bug 17199,
which should be used to solve the problems for and define secure key release.

Here I think the question is what effect should close() have on a session. For
that I think we have to consider what scenarios close would be used in. close()
is only necessary if we think there is a situation where the JavaScript
application will have a better idea of the desired key lifetime than the CDM.
It would use close() to signal some extra hint that would be used to release
the resources associated with keys. It is not clear that this situation exists
and if we don't have evidence for it then it would be better to leave close()
out until we understand what scenarios it needs to solve.

With our proposal for the MediaKeySession state model, two different
MediaKeySessions could be responsible for acquiring the same key. This means
that calling close() on one session doesn't offer any guarantee that a
particular key is released. In addition, the way many CDMs are likely to be
implemented, keys will be passed to the media engine and their lifetime managed
there.

I propose that we remove the close() method from the MediaKeySession in v1
unless we have a concrete example from on implementer of how they will use it.
In that case, the language of the spec should make close only a hint to the CDM
that may be ignored.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 16 July 2013 14:39:06 UTC