- From: <bugzilla@jessica.w3.org>
- Date: Sat, 17 May 2014 01:25:24 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434 niels t <nthorwirth@verimatrix.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nthorwirth@verimatrix.com --- Comment #7 from niels t <nthorwirth@verimatrix.com> --- As discussed in the last call, to clarify the intend of using a side channel while supporting EME: The intent is to allow interoperability in the selection of the CDM and content decryption but allows flexibility in how the license is retrieved: The application may use needkey, isTypeSupported() and CreateSession() and the CDM may use initData, but will not GetLicense via the Application but contact a license server directly. We don’t see a change in the current normative section to support this mode. To Mark's points: 1) Agreed on the importance and the CDM should still respect the same origin policies 2) Also agreed on consistent behavior. The resulting workflow exists already for the case where the license is already present, e.g. persistent or embedded. Also, the application will still select the CDMs it supports and can ignore other choices. 3) Not sure what the old model is. It does not have a basis for interoperability that we want to achieve. If it’s plugins, they are allowing direct communication and are widely used. As a DRM provider we would disagree that the required modifications are simple, since, for example, it has implications on security and IPR. Regarding the initial proposal, the Web & TV Interest Group requirements document for content protection mandates "an interface to allow any content protection system to be used to protect content" – so this should also apply to content protection that is deployed by hundreds of operators today. If this was the basis for defining requirements for EME, I’d argue there should rather be compelling reasons to exclude some content protection system from the EME. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Saturday, 17 May 2014 01:25:31 UTC