This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://lists.w3.org/Archives/Public/public-html/2012Feb/0430.html Kornel writes: "Do I understand correctly that once user is authorized CDM gives browser access to the decrypted bitstream of the media being played?" The spec needs to clarify how the UA/CDM collaborate in feeding frames through the media pipeline.
The diagram has led to confusion as it shows the "decrypted frames" being passed back from CDM to the browser. This is one possibility, but there are other possibilities in which the decrypted, encoded frames or decrypted encoded and decoded frames remain within a secure media pipeline provided by the platform. In these cases the browser may be provided only with a reference to the decrypted/decoded frames, or some means of controlling the surface on which they are rendered, but no access to the decrypted media itself. The details of what is supported and how it is achieved are implementation dependent and are not expected to be spelled out in the specification. It is the job of the CDM to communicate, securely, implicitly or explicitly, the type of security provided to it's peer on the server side as an input to authorization decisions: i.e. whether the content requested can be played on the device in question.
I agree with Kornel and Mark's opinion. In order to avoid further/future confusion, the spec should be clarified. I suggest to modify the diagram in the spec by removing the request and response between UA and CDM sending a request to decrypt Frame and sending Frame back OR add a sub-section under Introduction or Goals to address "what's in the scope of the spec and what's not" especially for the diagram which is just an example flow.
Assigned to Mark to work out how to clarify (and what needs to change in the diagram).
Another recommendation for this bug is clarifying the purpose of API in the diagram. Currently the diagram is not explicitly mentioning which API is in the scope of the proposal and which one is not. The decrypted frame API is a great example. The API is not the scope of the proposal but it is one of use cases on how the decrypted frame can be handled. I strongly recommend to add another indicator on the diagram which tells if the API is proposed API from the proposal or not.
Proposal: 1) Modify diagram to include the option where frames are not sent back to the browser but rather are rendered directly 2) Add to the Goals section an additional goal as follows: - Support a range of content security models, including - protection of keys and encoded content, but with decoded frames returned to the browser media stack for standard HTML compositing - direct control of frame rendering by the CDM, potentially making use of a secure media pipeline where available
I Updated the overview figure to clarify frame handling in http://dvcs.w3.org/hg/html-media/rev/954030ed7d36
Modified version of proposal (2), based on offline discussion: "Support a range of content security models, including software and hardware-based models"
http://dvcs.w3.org/hg/html-media/rev/f3492fa3f14c