先週のW3C TPAC（Technical Plenary and Advisory Committee）の中で行われたHTML Working GroupのF2F（顔合わせ）ミーティング（2011/11/3-4）の要約がW3C Blogに掲載されています。その中にDRMの仕様の標準化をW3Cの中で検討できないかという議論が行われたようです。以下はW3C Blogの抜粋です。
DRM
There is a discussion brought to the HTML WG by the WebTV task force to know if there is a possibility to add a mechanism to protect content. There is no resolution yet. On this same topic, an interesting article has been published on the history of the different systems proposed in the past.
from Open Web Platform Weekly Summary – 2011-10-31 – 2011-11-06 – W3C Blog
Web標準でDRMの仕様ができるならこりゃすごい話だと思い、どんな議論がされていたのか、少し追ってみました。
上で要約されているHTML Working GroupのF2Fミーティングの議事録が公開されています。その議事録を読むとDRMについての議論はWeb and TV Interest GroupのMedia Pipeline Task Forceが作成したRequirement Document Draft（要求文書案）という要望リストをベースに進められたようです。ですので、DRMについての議論も映像コンテンツの保護を目的するDRMが中心になっているのではないかと思われます。
では、議事録を紹介するまえにこの要求文書案の該当部分を先に抜粋します。
Content Security and Digital Rights Management
The delivery of premium media over an unsecured network such as the Internet requires the protection of proprietary and copyrighted content. Standardized support for content protection requires the following.
R9. Security and Digital Rights Management Identification (Dropped. No change necessary)
The media element interface should support the specification of content protection and digital rights management formats (e.g. DECE Ultraviolet, DTCP-IP, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)
R10. Security and Digital Rights Management Parameters (LC bug #13333 and #13625)
The media element interface should support secure specification of content protection and digital rights management parameters (e.g. subscription requirements, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)
R11. Security and Digital Rights Management Feedback (Gap? Do we just need to agree on common identifiers?)
The media element interface should support the feedback of relevant content protection and digital rights management information (e.g. supported DRMs, DRM ready, need to reactivate license, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)
frome Requirement Document Draft
上のR9はすでに検討から外れましたが、R10とR11が残っています。この２つの要求について11/3のF2Fミーティングで議論が進められたようです。その該当部分の議事録が以下です。
R10
… getting DRM system information
… exchange DRM related messages
… ref: OIPF DAE specification
… R11. Content Protection Feedback and Errors
Tantek: are the slides in the respective bugs?
Clarke no but they could be
ACTION Clarke add contents from the slides of the presentation to each specific bug
[trackbot] Sorry, couldn’t find user – Clarke
MW: Different conclusions though, might be components exposed through the web interface, pass through for parameters is different than webarch that hides platform/device specific things
… re: content protection
… some devices have content protection, some dont’
… my question to the group is: is it acceptable to introduce this capability to the web platform (pass thru), or some other strategy?
Anne: the last time this was discussed on WHATWG list
… least controversial suggestion was API feed bits into the video stream
… DRM would be implemented at the application level
MW: you can’t implement the DRM in the JS
… needs to be implemented in trusted execution environment
[karl] there is nothing secure in life. useless pun.
MW: objective of DRM is not to make it impossible but difficult, for some well defined values of difficult
… need these capabilities in the trusted computing layers
… below the video element
Anne: we are already at the place where you have H264 decoding in JS
… I was just stating the last thing that was discussed on this topic that had some traction beyond we don’t want to go there.
John Simmons of Microsoft: Echoing what Mark said.
… key takeaway
… DRM systems are going to be used on video delivered to devices
… people who develop DRM understand those constraints
… e.g. can’t implement in JS
… key question is whether HTML will be able to accomodate DRM protected content
… or continue like silos today
… which prevent large scale growth of internet television that we’d like to see
MV: related to 179
… there are these two proposals
… 1. for parm
… 2. not use it
… data- and x- are supposed to be prohibited from use
… but no change proposal says use those
… didn’t make sense
… details are in the issue 179 two alternate proposals
… can anyone comment?
PC: project change proposal?
… original change proposal
MV: just above the blue box
… furthermore the data-* mechanism etc.
… can’t be used
… but then in Sylvia’s counter proposals says to use them.
… does the quoted text need clarification
… or is it just a misunderstanding?
Hixie: the data-* attributes are intended to only be used by scripts in the page, not by the user agent
… if you have something the user agents would use, then either we would add it to the language
… or if it was experimental we would use x-* syntax
… e.g. webkit has x-webkit-*
Adrien: the misunderstanding was how x- attribute might be used on the way to standardization
… e.g. like it’s done with vendor prefixing in CSS.
… in order that those experimental implementations don’t drive actual content, we use a vendor prefix
… the proposed standard doesn’t have a vendor prefix
… the vendor prefixes are a temporary measure to experiment while standard is being agreed.
MV: concrete case is UPnP
… available spec
… but no support for it
… slightly different model UPnP video vs. regulary HTML video access
… a separate group UPnP could publish use x-upnp-* params, and encourage others to
Hixie: if they’re writing an actual standard they wouldn’t use x-
… just upnp-
MV: so ok for them to just use upnp- ?
Hixie: I wouldn’t recommend it, would prefer to come to the group
MV: I agree primary idea is bring these in bug 13625 (13635?) also tracks separate attribute
[pimpbot] 11http://www.w3.org/Bugs/Public/show_bug.cgi?id=13625 b.lund, P2, NEW, 13There is no way to pass audio and video content metadata to the user agent that is required in some cases for playback.
PC: I want to point people to the conformance clause in HTML5
… It says you can conform by pointing to HTML5 and other set of additional specifications
… a vertical industry could say you conform to HTML5 and this other specification
… too many people believe you want to force everything into the HTML5 spec.
… I want to support Ian’s view that if something is generic we want that discussion and get that in
… or at least know about it
… so that we can detect when something becomes emergently generic
Hixie: I agree
… the conformance section really it says what’s been true of any spec
MW: I wouldn’t encourage people to write extensions. we have an interest in strongly discouraging separate extension. we don’t want fragmentation.
… if you look at OIPF and HDTV you have 100s of 1000s of pages of stuff
… a uniform platform, that should be our goal
Hixie: in practice as people do start writing specs that start extending HTML in that way, it probably means we failed, but in reality it might happen anyway
from HTML WG f2f — 03 Nov 2011
DRMについての議論がどこまで続いているのか、よくわかりませんでしたので多めに抜粋してあります。
この会議ではClarke Stevens氏がどうもDRMについて、提案をしたらしいのです（おそらく）。そのClarke氏が使用したスライド資料がどうも見つかりませんので、議論はちょっと追いにくいのですが、「HTMLやJavaScriptでやったもんかな〜（疑問）」「HTMLがDRMで保護されたコンテンツに適応できるのか」みたいな意見が出たみたいです。どんな結論がでたのかはよく分かりませんが、おそらく出なかったのではないかと。個人的には有料のWebサイトというものがありえるのではないかと思うので是非議論をすすめてほしいと思うところです。今後、どのように進展していくのか興味深いところです。
さらにWeb and TV Interest GroupのメーリングリストでこのDRMに関する議論を遡ることができます。
・Web and TV Interest GroupのMLのDRMに関するやりとり