discussion of new Content Protection Proposal (Netflix, Google, Microsoft)

discussing the proposal from Microsoft, Google and Netflix

Mark: please walk us through the proposal

-- wait until I am in front of my computer

clark: Adrian -- how about you

having some feedback

clark: have been anticipating this proposal -- submitted to HTML group and our group for our perspective
... any comments on this proposal?

ph: since this was submitted to HTML group -- this is intended for HTML5

kilroy: yes to make it available to HTML -- but not part of the monolithic document
... could be a parallel document

MarkW: could be published as a separate spec -- kind of an extension
... what do we do with features that don't make the HTML5 cut?
... not resolved where this would go yet

<Clarke> Actual proposal: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

ph: not clear when HTML5 would repsond -- just wanted to double check on the planning

<inserted> (HTML issue-179)

MarkW: this was meant to respond to this issue: (what issue#?)

<ph> markw: was submitted on this specific issue since content protection was mentioned in this issue - but expect longer discussion, not

glenn: this is an orthogonal proposal not related to 179 except for parameter expression

MarkW: should I give an overview?

<mark> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

based in part on the Netflix proposal -- incorporates work others were also doing -- not complete

hopefully there will be some discussion

-- giving an overview of the doc now

MarkW: application is in charge of passing the authentication to the backend
... user agent is just passing the data through
... clearKey is basic encryption
... not part of the proposal how the CDM gets embedded or whether it is software or hardware
... could also include coding and/or rendering of the media
... represents the secure media pipeline on the device

MarkW: not returning the decrypted frame to the browser
... the rest is the details of key exchange

-- discussion of the key exchange

MarkW: the keymessage is sent to the license server and received back to hand to the CDM
... may be multiple key exchanges
... also an extension to the canPlayType()

clarke: concern I have seen raised -- belief that the frames would be available unencrypted

MarkW: the diagram is a little misleading here -- looks like it comes back to the browser but is dependent on the CDM
... you can imagine a system where it would come back but the frames would not be well protected then
... a CDM like that would be useful for some content -- not all
... some content would not fall into this category - where decoder is tied closer to the CDM
... decrypted frames do not come back to the user agent there
... that is an unsolved problem right now
... if decrypted frames are not coming back -- overlay would be the simplest implementation
... would prefer if frames could be properly composited
... would need for user agent to be able to talk to the graphics hardware to do the compositing properly
... can imagine this never happening for strongly protected content

Jason: is this akin to the hardware accellerated video tag?

mav: some questions about comparisons with the previous proposal
... previous proposal has been removed -- that is not good
... would like to see it put back

MarkW: should be able to see it in the history

mav: should have a label to make it more accessible
... the keys did not pass thru JS in the old proposal, now they do?

MarkW: in both proposals the messages pass through JS
... perhaps the name is wrong - is not necessarily a "key"
... for clearKey the message is actually a key

mav: would suggest that this should be further clarified

<adrianba> here is the old proposal: http://www.w3.org/2011/webtv/wiki/index.php?title=MPTF/Netflix_Content_Protection&oldid=1870

mav: description of the hardware support is brought in would be good with diagrams

joesteele says +1

jasonlewis: is the clearkey meant to be like HLS?

MarkW: is it akin to that in that the message is just the key
... how key is applied depends on the container format
... different from HLS in that the user agent is sending the request in HLS - with clearKey it is the JS application sending the request

joesteele: sending control messages to the CDM?

MarkW: not in this proposal except for key release in section 4
... the main reason for not having generic messages, it does not describe how the system works
... should be possible to have a JS app which just knows the message passing bit
... some preference has been expressed for exposing more features
... key release facilitates managing the key life cycle
... you may need to know how may keys are extant, or charge for the content on a rental basis
... could be managed from the JS app layer, but could be gamed by modifying the JS
... key release mechanism allows for a secure mechanism for managing the keys
... this is outside the purview of the HTML media element

joesteele: what about birth of life?

MarkW: could call the generateKeyReq early on to help this
... it is assumed that the CDM needs some data about the media to be initialized
... possible you could do this

joesteele: will send these notes to the HTML list

Clarke: procedural note -- how should we best handle comments like this?

MarkW: since it was proposed to that group -- send comments to that group

Clarke: : maybe we could come to agreement in this group and submit one set of comments

MarkW: this should get included in the formal system

Clarke: encourage people to participate in the HTML WG as well on this

glenn: note that the proposal was in response to ISSUE-179 -- not clear that it is proposed as an extension to HTML5
... not clear we are chartered to propose specs yet
... how is this work being done?

MarkW: proposal is submitted to the HTML WG

Clarke: we are chartered to provide comments

<adrianba> the html wg made a call for html.next proposals - this was discussed at TPAC too

<adrianba> right now we've simply submitted an informal proposal document for discussion

glenn: not following procedure currently - who did this come from?

<adrianba> i hope that this will be adopted as an editor's draft in the group

MarkW: came in as a proposal from Google

glenn: not clear as a reader of the proposal

MarkW: some behind the scenes coordination going on

glenn: does this IG need to bless this proposal or provide input?

mav: do not need to bless but should provide input

+1

kaz: thought we had our own ISSUE-40 for this?
... should this IG continue discussion on ISSUE-40 and bring the conclusion to HTML WG?
... or should we discuss ISSUE-179 and bring that discussion to HTML WG?

Clarke: should address, likely to be other issues we do not directly raise with HTML WG
... we have an opportunity to provide feedback

kaz: clarifying our scope would be fine

glenn: I am possibly ok with that -- a little concerned still with connection between ISSUE-179 and this proposal
... some confusion in the WG still
... led people to believe that 179 is concerned with content protection and it is not

kaz: if you have a concern with 179 it should be raised in the HTML WG -- we should focus on 40

-- agreement

glenn: expected actions from us on this proposal?

Clarke: we hope so - asked Mark to present to this group

thanks

<adrianba> HTML WG chairs review of ISSUE-179 is here: http://lists.w3.org/Archives/Public/public-html/2012Feb/0298.html

jasonlewis: re: the issue in the draft spec -- how do we add our own issues to this draft?

clarke: raise issues on the wiki - which may not match those in the proposal
... if authors then want to bring back to the proposal -- that would be great

s/athos/authors/

clarke: any other comments?
... closing the call
... add any issues to the wiki
... thanks everyone

<kaz_> [adjourned]