- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 8 May 2013 08:57:35 +0300
- To: Gilles Boccon-Gibod <bok@bok.net>
- Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
On Tue, May 7, 2013 at 6:58 AM, Gilles Boccon-Gibod <bok@bok.net> wrote: > There is one question that came up during the webinar regarding whether a > Key System implementation is "allowed" to interact directly with a DRM > server, without going through the user agent and application with a > keymessage event. > The speaker's response was that he wasn't sure whether it was specifically > forbidden or not, but that he couldn't see why it would be needed. Doing so would clearly go against the fundamental design of EME and fail to benefit from the design of EME. The main benefit being that when key server communications go from EME to JS to XHR (and back), the user's session cookie goes along the XHR communication, so there's no need to build a second session management mechanism for the DRM system. So that's a benefit for cases like Netflix where there is a concept of login. For cases without login, the benefit is that XHR is subject to the Same Origin Policy, so if a rogue site copies the video and the JavaScript program, the Same Origin Policy prevents the JavaScript program copied to another site from obtaining keys from the key server of the site from which the video and the JavaScript program were copied. (And the CDM prevents the playback of the video if keys weren't obtained.) This should address the concern voiced e.g. by the BBC representative about ensuring that video content appears in its intended context instead of being embedded by rogue sites. (Of course, enforcing the Same Origin Policy is the task for the browser and in the EME model the browser is treated as un-trusted by the content rights holders. It wouldn't make sense to be worried about rogue sites that'd depend on rogue browsers for operation that'd rely on the original key server instead of cracking the DRM. The users trust the browsers for the privacy and to make a browser rogue in a way that would allow the violation of the Same Origin Policy would mean compromising user privacy, so it's unlikely that users would want to obtain rogue browsers like that just to view content that would be loginless *anyway* in the context of another site than the original.) > He also mention in the talk that one of the goal of the EME spec was to at > least allow existing DRM systems to be supported through the proposed > architecture. It's more like being able to use existing robustness solutions, the name recognition of existing solutions and possibly existing license rule systems than about being able to use existing solutions wholesale, since, as you note, EME implies remapping the license server communication protocol to fit into EME messages. > In the lightweight, "on-demand", mode of Marlin, called MS3, which is often > used when there is no persistent license delivered (a non-persistent > lightweight license is sent back to an authenticated client, just for use > within the context of a streaming session), the client needs a direct, > non-intermediated, communication with a server. > For scalability reasons, the protocol between the DRM client and the server > is based on a mutually-authenticated TLS session, not on a signed/encrypted > data payload that can be relayed (like a SOAP message could be in the case > of PlayReady for example). In that case, MS3 would not work with EME as-is (without defeating the fundamental architecture of EME). However, MS3 is already the third flavor of Marlin (after the original and Broadband). Given the willingness of the Marlin Developer Community to develop different flavors already, it shouldn't be a big deal to develop an EME flavor of Marlin such that user identification would be based on session cookies picked up by XHR and the other semantics of the communications that currently go over the MS3 TLS pipe would be mapped to EME key messages. A relevant question, of course, is whether such a flavor is actually being developed. Is such a flavor in development? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 8 May 2013 05:58:03 UTC