This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25536 - Make persisted session removal more explicit
Summary: Make persisted session removal more explicit
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-02 19:56 UTC by David Dorwin
Modified: 2014-05-07 23:17 UTC (History)
4 users (show)

See Also:


Attachments

Description David Dorwin 2014-05-02 19:56:49 UTC
The name release() was intended to be ambiguous [1] along with the close event, but the ambiguity is problematic for applications. There was always the problem that an application could not call release() to indicate it no longer needed a key now without always destroying it. In the current stored license example [2], we can also see that the ambiguity makes it impossible for the application to know whether a session has really been removed (or just closed by the CDM for other reasons).

I propose a simple change that removes the ambiguity and returns release() and close to a single consistent meaning.

* Add a new method to MediaKeySession: Promise<any> remove();
  - Called to remove persisted session data.
  - The returned promise is resolved only after the CDM has destroyed the session data, including the session ID, including after potential message exchange.
  - For sessions without persisted session data, reject the promise with "InvalidAccessError".
* release() now always means the app is done with the session so the CDM can close it. (It does *not* destroy persisted session data.)
* The close "event" is fired when the session is no longer used by the CDM. It should also be fired at some TBD point during the remove() process.

Given the new behaviors, it may also make sense to rename release() - possibly to close(). Then we'd need to rename the "close" attribute to "closed" or something else. (The name "close" was selected because it is consistent with other events; since it is now a promise, maybe this is less important.) Suggestions?

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750#c16
[2] https://dvcs.w3.org/hg/html-media/raw-file/97f675a78a34/encrypted-media/encrypted-media.html#example-stored-license
Comment 1 Mark Watson 2014-05-02 22:49:56 UTC
To check I understand, whether the keys get destroyed at this time depends on the properties of the session: whether it is persist-able or not, right ?
Comment 2 David Dorwin 2014-05-02 22:51:36 UTC
(In reply to Mark Watson from comment #1)
> To check I understand, whether the keys get destroyed at this time depends
> on the properties of the session: whether it is persist-able or not, right ?

This is the current behavior when release() is called. Is that what you mean by "at this time"?
Comment 3 Mark Watson 2014-05-06 15:54:08 UTC
Yes. The proposal looks good to me.
Comment 4 Joe Steele 2014-05-06 21:21:57 UTC
This seems reasonable. +1
Comment 5 David Dorwin 2014-05-07 23:17:15 UTC
Changes implemented in https://dvcs.w3.org/hg/html-media/rev/5a3cac55ca65