{minutes} HTML WG media telecon 2013-07-16 - EME status and bugs discussion

http://www.w3.org/2013/07/16-html-media-minutes.html


Joe Steele

________________________________

[http://www.w3.org/Icons/w3c_home]<http://www.w3.org/>

HTML Media Task Force Teleconference
16 Jul 2013

Agenda<http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0010.html>

See also: IRC log<http://www.w3.org/2013/07/16-html-media-irc>

Attendees

Present
glenn, markw, +1.760.533.aaaa, joesteele, +44.303.040.aabb, davide, paulc, pladd, +1.212.512.aacc, [Microsoft], adrianba, JoeHallCDT, ReimundoGarcia, johnsim, +1.425.202.aadd, ddorwin, pal
Regrets
Chair
paulc
Scribe
joesteele
Contents

 *   Topics<http://www.w3.org/2013/07/16-html-media-minutes.html#agenda>
    *   Role Call<http://www.w3.org/2013/07/16-html-media-minutes.html#item01>
    *   Previous Minutes<http://www.w3.org/2013/07/16-html-media-minutes.html#item02>
    *   Review actions and issues<http://www.w3.org/2013/07/16-html-media-minutes.html#item03>
    *   EME status & bugs<http://www.w3.org/2013/07/16-html-media-minutes.html#item04>
    *   outstanding bugs<http://www.w3.org/2013/07/16-html-media-minutes.html#item05>
    *   Bug 21855 - Avoid network traffic and duplicate sessions for the same key(s)<http://www.w3.org/2013/07/16-html-media-minutes.html#item06>
    *   Bug 21854 - Define MediaKeySession life cycle states and/or events<http://www.w3.org/2013/07/16-html-media-minutes.html#item07>
    *   ACTION-24: Resolve 17203 independent from 17199 (Adrian)<http://www.w3.org/2013/07/16-html-media-minutes.html#item09>
    *   ACTION-25: And John S to work on corner cases for bug 17673 (David)<http://www.w3.org/2013/07/16-html-media-minutes.html#item10>
    *   ACTION-26: Implement bug 19096 in the editor's draft (Adrian)<http://www.w3.org/2013/07/16-html-media-minutes.html#item11>
    *   ACTION-27: Add comments to bug 17750 summarising the recent discussion of close (Adrian)<http://www.w3.org/2013/07/16-html-media-minutes.html#item12>
    *   Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available<http://www.w3.org/2013/07/16-html-media-minutes.html#item13>
    *   Bug 21869 - Need clarity on stored keys for CDMs<http://www.w3.org/2013/07/16-html-media-minutes.html#item14>
 *   Summary of Action Items<http://www.w3.org/2013/07/16-html-media-minutes.html#ActionSummary>

________________________________

<trackbot> Date: 16 July 2013
<paulc> zakim., what is the code?
63342
<scribe> Scribe: joesteele
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0010.html

Role Call
Previous Minutes
<paulc> http://www.w3.org/2013/07/02-html-media-minutes.html

Review actions and issues
<paulc> ISSUE-1?
<trackbot> ISSUE-1 -- Consider moving the Clear Key definition into a separate specification -- raised
<trackbot> http://www.w3.org/html/wg/media/track/issues/1

paulc: tracking for now
EME status & bugs
paulc: looked last night and saw updated on July 2nd
<paulc> Editor's draft: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

paulc: any changes since then?
adrianba: changed this morning as usual
outstanding bugs
paulc: only 15 this morning
<paulc> http://tinyurl.com/7tfambo

Bug 21855 - Avoid network traffic and duplicate sessions for the same key(s)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855#c5

paulc: wanted people to look at comment #5
... did not see any updates as of last night
... was a long weekend maybe no body got to it
adrianba: this is dependent on the next one 21854
... we are also waiting for feedback on this one
... couple of meetings since the proposal -- hoping to close this soon
... assigned to me but can't do any action on it yet
Bug 21854 - Define MediaKeySession life cycle states and/or events
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c9

paulc: we asked David to look, minutes say he volunteered
markw: still waiting for internal feedback
ddorwin: should be a transition from READY to ERROR -- question to the group
... not ready for feedback yet
... will update next time
paulc: at next mtg will reverse the order
adrianba: comment on Davids questions
... not sure what situation would cause this to happen
... no objection to happening
... would most likely signal an error against the element, if you are in READY should be no activity that would lead to an ERROR
markw: could imagine output protection could fail
<adrianba> Mark's comment -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c10

markw: we should have a CLOSED state for the key release messsages
adrianba: lump that comment in with the general design need for secure key release
<ddorwin> +1
adrianba: haven't resolved how we manage the exchange during the winddown of the browser
joesteele: could see a transition from READY to ERROR from output protection as David said or because of an invalid key encountered during key rotation
markw: I think the status on the secure key release is that it is not required to be mandatory that the browser or window is closing
... discussion is about the mechanism to store the reporting of these messages
... will update the bug with relevant details
ddorwin: saving the data can be just as complicated as sending the actual key release message
... wanted to make sure I understand the event usage so all on the same page
... <will paste this in a second>
<ddorwin> • Event usage:
<ddorwin> ◦ It seems that an application would wait for a keymessage and keyready event.
<ddorwin> ◦ If keymessage is received, do a normal license exchange.
<ddorwin> ◦ If keyready is received, there is nothing more to do.
<ddorwin> ◦ If a normal license exchange occurred, the subsequent keyready could be ignored (similar to keyadded today).
adrianba: it depends on if the application wants to use keyready to do something
... e.g. present a message to the user
... another is the solution for 21875 - if you have 2 separate sessions where initdata is mapped to the same key - could use that
... to move on
paulc: outstanding on David -- more data for you -- will be at the top of the next agenda
... any further discussion?
ACTION-24: Resolve 17203 independent from 17199 (Adrian)
ACTION-24?
<trackbot> ACTION-24 -- Adrian Bateman to resolve 17203 independent from 17199 -- due 2013-07-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/24

adrianba: change I made was that in the introductions <finding link now>
... which was to the section 1.2.3
... on sessionID
<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#session-id

adrianba: change I made was remove the language about sessionID being optional
... and removed old language from previous non-object oriented design
... request for others to review for old language
<ddorwin> Changes look good. (I didn't look for other references to optional.)
paulc: so this is closed?
<adrianba> close ACTION-24
<trackbot> Closed ACTION-24 Resolve 17203 independent from 17199.
adrianba: pending review
paulc: reopen this bug if you have concerns
ACTION-25: And John S to work on corner cases for bug 17673 (David)
ACTION-25?
<trackbot> ACTION-25 -- David Dorwin to and John S to work on corner cases for bug 17673 -- due 2013-07-09 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/25

ddorwin: did not get a chance to summarize my notes or revisit prior bug, should have notes this week
<paulc> ACTION-25 due July 19
<trackbot> Set ACTION-25 And John S to work on corner cases for bug 17673 due date to 2013-07-19.
ACTION-26: Implement bug 19096 in the editor's draft (Adrian)
ACTION-26?
<trackbot> ACTION-26 -- Adrian Bateman to implement bug 19096 in the editor's draft -- due 2013-07-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/26

adrianba: this was straightforward request to add the new type attributes to the media keyneeded event
<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#events

adrianba: added the type attribute and then noted that the format of the initdata would depend on that type
... should be self-explanatory but let me know if you want changes
<ddorwin> Changes look good.
<adrianba> close ACTION-26
<trackbot> Closed ACTION-26 Implement bug 19096 in the editor's draft.
ACTION-27: Add comments to bug 17750 summarising the recent discussion of close (Adrian)
ACTION-27?
<trackbot> ACTION-27 -- Adrian Bateman to add comments to bug 17750 summarising the recent discussion of close -- due 2013-07-09 -- PENDINGREVIEW
<trackbot> http://www.w3.org/html/wg/media/track/actions/27

<adrianba> My comments -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750#c5

adrianba: added the comments
paulc: should we look now?
adrianba: summarized the comments I made around close in previous meetings
... essentially said there is two parts to close
... one is key release
... second is effect on a session
... don't think we need close, UNLESS application has a better idea of key life cycle than the CDM
... no specific guarantees
markw: haven't reviewed but would like to do so
... think there are cases where the app knows better what the lifecycle is -- need to check with security folks
joesteele: so only need close if the application can know better than the CDM what the life cycle is?
adrianba: yes -- not sure this is the case
... only needed if the JS app could provide additional context for the CDM -- the app can provide the hint
... if the CDM is fully capable of managing the keys, then don't need this
joesteele: need some more time to think about this as well
markw: agree with Adrians rationale, we need a clear example of when the JS app would know better so we have a common understanding
... would expect that if the media element is destroyed, that could cause the removal of all keys
... might depend on the type of the CDM specific key
... but need to check into the this case
ddorwin: reading the bug again, most of the discussion is on the close method
... but also the issue of clearing the keys attribute
... need to figure out what the corner cases or end-of-lifes cases for media sourcesgoing away
... maybe src changes should just clear the media keys
paulc: so several people are going to review and add comments, we will pick up at next mtg
<adrianba> close ACTION-27
<trackbot> Closed ACTION-27 Add comments to bug 17750 summarising the recent discussion of close.
Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
paulc: was there an attempt to have an action here? was discussed at previous mtg
... adrian any progress on this?
adrianba: this was the group -- not me
paulc: should we spend time on this now?
adrianba: not sure
paulc: move on then
Bug 21869 - Need clarity on stored keys for CDMs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869#c8

paulc: only bug updated without an existing ACTION
<adrianba> joesteele: we had a bunch of discussion on this - when we discussed whether CDM should have storage there was a difference of opinion
<adrianba> ... seemed like david took the position that the JS application should be involved in any storage
<adrianba> ... sounded like the proposal was that this was an active thing - no storage without the JS being involved
<adrianba> ... i'm arguing for the opposite
<adrianba> ... data should be treated like cookie data
<adrianba> ... app can deny storage of data but if it doesn't intervene the data will be stored
<adrianba> ... will put CDMs on the same footing as servers
<johnsim> +q
<adrianba> ... would that be acceptable - proposed an API in the bug
johnsim: have a concern about this
... up till now the CDM behavior has been isolated from the application
... typical for key stored or not stored depending on the license server being talked to
... we seem to be violating the distinction between what the app is doing and what the CDM is doing
... would need a detailed review of this with security team
... should be between the CDM and the licens eserver
adrianba: would like to push a little harder on what John just said
... not obvious what we mean by storage here
... should be no barrier to what CDM should do
... is storage in memory storage? on disk storage? always on makes a difference?
... not sure what we mean by storage here
<ddorwin> The CDM does decryption, etc. It is not intended to be like a local server. There are numerous storage APIs with permission handlers, and we should not add another. If an application wants to persist data to disk, it probably already has a lot of key system knowledge.
adrianba: don't think there should be constraints here
ddorwin: CDM has specifically a narrow purpose
... should reuse existing services if this is needed
... main point seems to be to avoid key system specific information, but that will exist any way
adrianba: only point that I disagree is that the spec does not need to handle this, not trying to define a generic storage mechanism
... purely for the CDM to decide
markw: what kinds of requirements that folks have that could not be met by storing the key message and response
<Zakim> ddorwin, you wanted to ask What's not normal for CDMs?
markw: could have reusable licenses if you want to
ddorwin: joe said something that was not normal for CDMs? can restate?
<adrianba> markw: the response might be encoded with a time senstive key
johnsim: what is the requirement that is not being met?
<adrianba> joesteele: to david's question - there are a bunch of CDMs that require storage (some named examples ???)
<adrianba> ... that's what i meant by normal as part of their usual operation
<adrianba> paulc: even if they require storage, given that the CDM is opaque do we have to say anything
<adrianba> joesteele: i could agree that this might be something that doesn't need to be described
<adrianba> ... but after discussing with some browser vendors
<adrianba> ... if there is not a specific requirement in the spec to allow storage of data, it will not be allowed
<adrianba> johnsim: so you mean the CDM is enclosed in the browser and doesn't have access to anything unless the browser allows it
<adrianba> joesteele: yes, and in this model we would be blocked
<adrianba> ... given the discussion about CDM having unfettered access to the system
<adrianba> ... one answer is to restrict what CDMs can do
<adrianba> ... I don't mind sandboxes but a number of CDMs cannot function without storage
markw: do think that CDMs will need to have access to storage - could be limited and browser mediated
... particularly for key release storage
... question was really what they need to store
<adrianba> joesteele: for our DRM we have a unique key to be downloaded to be functional at all
<adrianba> ... it is possible to function if you download every time
<adrianba> ... but that would be a multi-second delay for every attempt to play
<adrianba> ... because of not storing this key
<adrianba> ... for secure key release we also need to store this information
<adrianba> ... as state information and not input/output data
<adrianba> ... the secondary problem of storing license could potentially be stored as key request/key response
<adrianba> ... but this is a roundabout way of storing the data
paulc: think this has been useful -- better understanding of the use case Joe is talking about
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869#c8

thanks for scribing Adrian!
paulc: not time for another bug
... if we come to the next mtg with these actions and bugs done, would be helpful to have editors nominate some additional bugs
... next meeting is July 30th
... if someone could start the discussion on some set of bugs for the next meeting, that would be good as well
... given lots of outstanding actions, can't set the bar that high
... but would like a set of bugs for the next meeting
... thanks to the scribes
... bye all
s/coul dhave/could have/
Summary of Action Items
[End of minutes]
________________________________
Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.138 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2013-07-16 16:10:17 $
________________________________