- From: <bugzilla@jessica.w3.org>
- Date: Tue, 16 Jul 2013 16:58:03 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199 --- Comment #17 from Mark Watson <watsonm@netflix.com> --- Here is an update on this topic, as promised on the call today: Originally, the secure proof of key release feature required key release messages to be generated immediately the key was released. Feedback from browser implementors indicated this was difficult in a variety of shutdown/page close scenarios. As a result we revised the proposal so that key release on close is not required. Before FPWD, there was a discussion as to whether secure proof of key release required any normative specification. That is, whether it could be implemented with the existing primitives in a similar way to, for example, heartbeat. This question is unresolved. Until recently, the only aspect of secure proof of key release that I believed required normative specification was the mechanism to recover persisted unacknowledged sessions when a page re-loads. For example, a special type value for use in createSession that would recover a persisted session for which the secure proof of key release was unacknowledged. This type value would need to be specified in order to have an interoperable solution. With the introduction of the CDM state machine, I think it is clearer that normative specification is required. Specifically, there is a need for a state where the key release message has been sent but not acknowledged and a state where the key release has been acknowledged. For example PENDING-CLOSE and CLOSED. It's possible that the existing PENDING state could be used for PENDING-CLOSE. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 16 July 2013 16:58:04 UTC