This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From v0.1: The proposal currently allows addKey() to be called without calling generateKeyRequest(). This has the advantages that simple use cases, especially for Clear Key Simple Decryption, are fairly straightforward and simple. The disadvantages are that user agents need to support multiple flows and applications written for the simple case are different than those written for the more general case. In addition, some container formats may not support the simple case (i.e. if initData is not easily-parsable to obtain a key ID). It is an open question whether allowing the simple solutions is worth the effects. See this example <http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-disallow-addkey-only-example> for an illustration of the impact on simple applications. --------------------------------- With this change, the example in 7.1 would go from: <script> function load() { var video = document.getElementById("video"); var key = new Uint8Array([ 0xaa, 0xbb, 0xcc, ... ]); video.addKey("org.w3.clearkey", key, null); } </script> <body onload="load()"> <video src="foo.webm" autoplay id="video"></video> </body> to: <script> function load() { var video = document.getElementById("video"); video.generateKeyRequest("org.w3.clearkey", null); } function handleMessage(event) { if (event.keySystem != "org.w3.clearkey") throw "Unhandled keySystem in event"; var video = event.target; var key = new Uint8Array([ 0xaa, 0xbb, 0xcc, ... ]); video.addKey("org.w3.clearkey", key, null, event.sessionId); } </script> <body onload="load()"> <video src="foo.webm" autoplay id="video" onkeymessage="handleMessage(event)"></video> </body>
Also see http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#issue-needkey-simple-event-example for the possible impact of this and other proposed changes.
We should prioritize resolving this since it affects the basic API.
After working on an implementation, I think we should make this change. Benefits include: * Simplifies user agent implementation - there is one API where a CDM can be instantiated. * We can eliminate the keySystem parameter from addKey() and clearKeyRequest() * Less confusion in the application and user agent related to the potential for the value to change, such as in addKey() and clearKeyRequest() calls. * It fits nicely with an object-oriented design, such as the one proposed in bug 16613.
I think "to" part is better. But I wonder how the key is generate?: from example it seems you generate a key using uinit8array([xx,xx,xx,....]). Do you mean the key is hardcoded in webpage? everybody can see or modify it? I have thought that the key may be generated by event cast by generateKeyRequest, then we use e.data fetch the key for following processing.And the key in the data is not visible to user or can not be recorgnize by user.
(In reply to comment #4) > I think "to" part is better. > But I wonder how the key is generate?: > from example > it seems you generate a key using uinit8array([xx,xx,xx,....]). > Do you mean the key is hardcoded in webpage? everybody can see or modify it? The examples use Clear Key where the key is actually in the clear. Other key systems might use licenses or otherwise encrypt the data passed to addKey(). > I have thought that the key may be generated by event cast by > generateKeyRequest, then we use e.data fetch the key for following > processing.And the key in the data is not visible to user or can not be > recorgnize by user. generateKeyRequest() generates a message to send to the key server to request the key. This might be a "license request". The application sends this message to the server, which will reply with a key/license, which the application provides to the CDM with addKey(). See the response above about protecting the key.
One option is that the user agent should fire an INVALID_STATE_ERR if addKey() or cancelKeyRequest() are called before an appropriate (i.e. same keySystem) successful call to generateKeyRequest(). However, should we also require a valid session ID (bug 17203), which would also require that generateKeyRequest() had been called? Note that the current draft says to throw an INVALID_ACCESS_ERR if sessionId is unrecognized. However, that assumes the session ID check is synchronous, which may not make sense (bug 16550). This discussion may be moot depending on the specific solution to bug 16613.
Addressed by the object-oriented API (bug 16613). The key request is generated by createSession(), which creates the object that has the addKey() method.