- From: <bugzilla@jessica.w3.org>
- Date: Mon, 29 Sep 2014 17:33:33 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887 --- Comment #2 from Jerry Smith <jdsmith@microsoft.com> --- Here's a proposal for discussion: Background: ========== We believe the license server model is not just valid, but likely the superior approach to managing persistent data. It doesn’t fit well with our current notions of sessionType, load session or remove. sessionId has become overloaded, since sessions themselves should be able to come and go as needed to support messaging. It’s possible to have multiple sessions and sessionIds for a single keyId. In hindsight, we think we may have gotten it wrong when we decided to make sessionId mandatory in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17203. Proposal: ======== At some point, we do need to address Mark’s comments about Ids, and the ability to group Ids under a single identifier for convenience. For now, let’s start at a higher level. 1. We should delete sessionId and related operations from the spec. 2. Sessions themselves should be limited to coordinating messages, nothing more. 3. The license server model gives apps plenty of control over persistence and secure release. The first will be based on a transaction that the app will often initiate, and the latter will likely be baked into the general operation of some websites. In both cases, the app doesn’t need to enable data storage. The CDM should accommodate the storage requirements of the license and use persisted licenses automatically for playback. 4. Apps need a way to identify content that has not satisfied secure release requirements and complete the process. 5. Apps may need to ability to identify and delete persistent licenses. IDL: === - Add a method to enumerate specific types of Ids from the CDM. This could be keyIds or something else. The app should know the type of Id it is retrieving. enum IdType (type1, type2, …); interface MediaKeys { Promise<sequence<DOMString>> getStoredIds(IdType); } - Add a method to prepare the session to operate on a returned Id. This would not imply that the session has been fully prepared for playback, but that it is positioned to handle messages related to a specific Id. The primary action that would be taken on returned Ids may be remove. Retain the current remove for that purpose. interface MediaKeySession : EventTarget { Promise<bool> prepare(DOMString storedId); Promise<void> remove(); } Usage: ===== - Secure release – general: o License issued by server is tagged for secure release o One or more secure release licenses are issued during playback of specific content o At playback completion, the app calls getStoredIds with a type associated with secure release o One or more Ids are returned o App calls prepare() and remove() to delete each Id - Secure release – resumption: o Playback session is abruptly interrupted, leaving secure release requirements pending o On the next browser session to the same media site, app calls getStoredIds with a type associated with secure release o One or more Ids are returned o App calls prepare() and remove() to delete each Id - Secure release – variation o App calls getStoredIds after the start of playback and stores returned Ids for later use - Manage persistent licenses: o App calls getStoredIds with a type associated with licenses o App calls prepare() and remove() to delete each specific persistent Id that should be deleted Pending based on discussion: =========================== - IdType details - Secure release app tracking and grouping of Ids -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 29 September 2014 17:33:40 UTC