See also: IRC log
<marie> Breakout session: Content Protection
ralph: what is possible in HTML5 & what limitations?
what needs to be specified beyond what is there now.
mav: summarized current state wherein browser vendors can choose to support or not support DRM within their video element
mark watson: one problem: requires multiple DRM servers
mark watson: second problem is multiple authentication
mark w: solution discussed in berlin was to have user auth in JS and pass encrypted key exchange stream via new std JS API to DRM/codec engine underneath UA
mark w: this reduces DRM to just key exchange and moves user auth & business logic to JS app
mark w: cache coherence drives need for common encryption format
ralph: 1. arm doesn't fit open source model 2. content should be free 3. mandating specific DRMs can't be done at W3C
... we need to work within those limitations
mav: another objection repeated is that DRM is not completely secure
mark w: drm not security through obscurity - it may be tied to hardware in a very secure way
ralph: need to develop APIs like what mark w suggested
... also need std error for DRM failures
mark w: commercial services on the web need more detailed error codes in general, not just regarding DRM. CSRs cannot resolve issues with current one or two error codes.
eric: need precise error codes, not general open-ended errors, so that all UAs act the same.
mark w: it would help a commercial website to have more detailed error because we have the resources to follow-up
eric: that helps big websites, but not the web platform.
clarke: is Web&TV IG MPTF approach to ask for more detailed events appropriate?
john simmons: we need to be very precise in the errors if it goes into the spec.
john s: so that a typical script app could handle the error in a useful way
eric: in answer to the question: how to get this done: enter a bug against the spec with a very specific change to the spec.
... who will be the expert to do the detailed spec?
ralph: mark w. suggested there are, say, 20 specific network errors that could be defined in a precise way.
jan: OIPF has defined a state model for DRM and standardized events and APIs. These could be used as starting point.
mav: none have been submitted
jan: but they could be submitted and are flexible enough.
john s: a significant number of companies were involved in looking a requirements for integrating DRM into browser in a generic way. (not saying it can be lifted directly.)
john s: when i ask who are the experts, many are in the room now.
john s: One long standing issue has been incompatibility of DRM with open source. Latest standards in common encryption and DASH have made DRMs more of a commodity function.
john s: can now enable a web client to receive an large number of internet channels, with DRM being the last missing standardized element. enormous opportunity to the "broadcast" industry & the internet industry.
john s: devices we use on the internet need to be smarter and must include some standardized, horizontal authorization. Microsoft focus is on how to build standard internet television receiver. current projects include oath.
john s: real question: how to enable internet receivers on the browser side - in the specific case - what needs to be defined in for protected content? OIPF interesting work.
eric: most people driving html5 don't understand media: so you need a very precise proposal
mark w: also believe proposals that reference external proposals, don't succeed as well
eric: depends how you reference external std. just saying another spec says this is important isn't enough.
clarke: another key is you need to get participation from DRM companies
alexandre bertails: all these issues are an overlap with the identity group
mark w: identity related, but not the same. app needs both.
<marie> marv: concrete proposal to write
<marie> mark va: let's start 2 projects then
mav: suggests starting two MPTF efforts: 1. video error codes 2. encrypted key exchange tunnel API
<Tryphoon> Missing Part at the beginning of the session:
<Tryphoon> HTML4: DRM was part of the plugin space
<Tryphoon> In HTML5
<Tryphoon> it can be built as part of the video element, but it is up to the browser vendor to implement. e.g. H.264 + FairPlay as a mime-type and put the support in the browser as you ship it and respond to the mime-types that can be played.
<Tryphoon> * But have no idea if any browser is planning to do anything like that. Seems to leave a big hole for browsers that are shipped only in Open Source code.
<Tryphoon> Third possibility: a browser could define its own plug-in due to media type.
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/mark s/mark w/ Succeeded: s/jahn/john/ Succeeded: s/xxx/alexandre bertails/ No ScribeNick specified. Guessing ScribeNick: mav Inferring Scribes: mav WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: HTML4 Mohammed Tryphoon W3C W3C1 arronei clarke csmithpeters dowan eric eric_carlson frankolivier giuseppe jan left manyoung_ marie mark marv mav noriya ralph si-wei tvjunkie_ webcp You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 02 Nov 2011 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]