This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current communication model (section 1) assumes that the application communicates with the license server. In today's deployments, this is not always the case. There are at least two models in the industry: 1. The CDM generates a Key Request and does not rely on a specific communication protocol but rather lets the application communicate with the license server to deliver the request and eventually get the encrypted key back (i.e. license). 2. The CDM includes its own communication protocol to the license server. In this case, the application does not need to go through the 'generateKeyRequest -> Get Key -> addKey' sequence but can simply call retrieveKey and the CDM handles the rest. The Encrypted Media Extension proposal should support both of these models.
If the UA already knows everything it needs to instantiate a CDM and retrieve a license then this API is not needed and is out of scope. HTML5 media elements already implicitly support this scenario and there are already implementations of this. See Bug 16543.
The html media element already support the option 2, and the retrieveKey does not need to be defined in W3C, it is not a JS API. (In reply to comment #0) > The current communication model (section 1) assumes that the application > communicates with the license server. In today's deployments, this is not > always the case. There are at least two models in the industry: > 1. The CDM generates a Key Request and does not rely on a specific > communication protocol but rather lets the application communicate with the > license server to deliver the request and eventually get the encrypted key back > (i.e. license). > 2. The CDM includes its own communication protocol to the license server. In > this case, the application does not need to go through the 'generateKeyRequest > -> Get Key -> addKey' sequence but can simply call retrieveKey and the CDM > handles the rest. > The Encrypted Media Extension proposal should support both of these models.
Discussed in telcon: http://www.w3.org/2012/07/10-html-media-minutes.html#item06 Resolving WORKSFORME - the internal implementation of this kind of content protection model is out of scope for a JavaScript API. HTML5 already supports implicit content protection if the UA desires.
This bug was previously closed but the closure was later invalidated (3) by explicitly removing the ability of a CDM to implement an independent key management protocol. (See Abstract: " The common API supports a simple set of content encryption capabilities, leaving application functions such as authentication and authorization to page authors. This is achieved by requiring content protection system-specific messaging to be mediated by the page rather than assuming out-of-band communication between the encryption system and a license or other server.") The current communication model forces the communication between the License Server and CDM to go through the Application. However, in order to enable some protection systems, direct communication between the CDM and a License Server is required. According to the Web & TV Interest Group requirements document for content protection (1) the goal is to standardize an interface that supports "any content protection system to be used to protect content". Also EME '1.1 Goals' states as a design goal: "Support a range of content security models, including software and hardware-based models". We do believe that the direct communication option will enable broader EME applications and support and that this option does fit within the current EME (earlier bug 17615 (2) was closed as out of scope) and would not limit any existing use cases. The proposed change is to remove the limitation by reverting the introduced addition (3) and to make the first iteration of the key messages in 'Introduction' dotted, as they are in the second iteration. We don’t see any other mandatory changes. (1) https://dvcs.w3.org/hg/webtv/raw-file/tip/mpreq/cpreq.html#u1.-support-authorized-access-to-content (2) https://www.w3.org/Bugs/Public/show_bug.cgi?id=17615 (3) https://dvcs.w3.org/hg/html-media/rev/1ca7610af922
As I said previously, there is nothing in the HTML5 that prevents a media element from directly communicating to a license server. However, EME is founded on the message exchange pattern. If you do not need to exchange messages then EME doesn't add any value and you can already do what you want. In fact, I believe there were already existing implementations that did this and that was in part what prompted the change to the introduction. We wanted to make sure we were not saying that EME is the only way to support this use case.
*** Bug 25434 has been marked as a duplicate of this bug. ***