<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