- From: <bugzilla@jessica.w3.org>
- Date: Wed, 01 Oct 2014 00:07:16 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26887 --- Comment #6 from Jerry Smith <jdsmith@microsoft.com> --- Reply to David: It should be sufficient to establish that the license server model is valid. That it’s already used by more than one established DRM system argues that is the case. I am asserting that it should be allowed. We believe a license with a persistent attribute always be stored (outside of inprivate), and that the license server model can fully allow the app to participate in the decisions that lead up to that happening. There is no loss of app control. Apps can be given the ability to identify and remove persistent licenses from the CDM license store, which would give them further control over what has been stored and whether it should be retained and reused. If the license server and app work together on determining whether a subscription, rental or purchase license should be issued, it’s hard to see further utility of the app also declaring a sessionType, particularly if the session itself is restricted to managing messages as we believe it should be. For automatic re-use, the CDMs could go from generateRequest (or perhaps a renamed method) to fire keychange (or a new variant or renamed version of this event), bypassing the messages. This doesn’t seem a great departure from the current model, and would allow apps to be aware that a persisted license was reused. The previous discussion on keyIds concluded that a given license may contain multiple keys used for a stream. That suggests that some other license or objectId may be needed. That doesn’t invalidate the suggestion that Ids be retrievable from the CDM, and that those support use cases for both managing persistent licenses and securely releasing others. Reply to Mark: There need not be a message exchange when a persistent license is reused, but its use should probably be detectable by the app. Also, it makes sense to me that apps should be able to query stored licenses and potentially delete ones for specific content. I don’t see great advantage though in having the app declare that licenses may or may not be stored. The app and service have full control over this without requiring a redundant API control that broadly controls storage. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 1 October 2014 00:07:17 UTC