- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Tue, 07 May 2013 19:36:29 +0200
- To: "Gilles Boccon-Gibod" <bok@bok.net>, "Mark Watson" <watsonm@netflix.com>
- Cc: "public-html-media@w3.org" <public-html-media@w3.org>
- Message-ID: <op.wwp5u3ik6ugkrk@giuseppep-x220>
On Tue, 07 May 2013 16:16:12 +0200, Mark Watson <watsonm@netflix.com> wrote: > Gilles, > > The design of EME is that CDMs do not interact directly with content > license servers*, but instead the license >acquisition process is > mediated by the application. > > It's hard for the specification to *prohibit* such direct interaction, > but you would likely find that a KeySystem that >subverted the design > approach would not be usable with most EME applications. > > The reason for this design is to avoid the need for service providers - > who must in practice support multiple DRM >systems - to stand up > multiple front-end license servers. Also it avoids the need to delegate > application business >logic such as user authentication and > authorization to multiple DRM servers. These functions are properly > handled by >the application and the license server is used as a back-end > server to provide licenses as required by the >application. > > As a result, existing DRM client components will likely need to be > wrapped in some way to form an EME CDM. In the case >of Marlin that you > describe below it looks like you need to sign and encrypt the messages > using the credentials you >would otherwise use for securing the TLS > connection. @Gilles do you think this would be possible in practice or do you see a major issue with this approach? You mention performance issues in your original email, is the difference between the approaches so wide to seriously impact the user experience? > > I would note that content protection systems that interact directly > with license servers can be integrated into the >video element without > using EME at all. For example Apple HLS supports a form of content > encryption which works in >this way. The point of EME is to provide a > uniform model so that applications can easily support multiple DRMs. @Mark I guess that even in that case an EME like approach could be useful to convey information that otherwise needs to be part of a manifest or headers. Of course at that point one could argue if it's worth the change. /g > > *Finally, for completeness, I should note that some DRM components > perform a one-off installation/initialization >interaction with a server > maintained by the DRM provider, rather than the service provider. For > this reason such >components may need network access. > > ...Mark > > Sent from my iPhone > > On May 7, 2013, at 5:35 AM, Gilles Boccon-Gibod <bok@bok.net> wrote: > >> I found a video of a webinar given for the DTG group a month ago >> (http://vimeo.com/62269279), where the >>speaker gives an overview of >> the Encrypted Media Extensions. >> 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. >> 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. >> So I'd like to explain a concrete specific case for the Marlin DRM >> system where the current EME >>architecture would be suboptimal, or at >> least require an implementation to "cheat" a bit with regards to >>the >> intended use of the keymessage/addkey workflow, which assumes that the >> communication between a Key >>System and DRM servers can always be >> intermediated by the application by passing it a keymessage to forward >> >>to the server and having the application, then, relay the response in >> the addkey() call. >> 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). So there's no >> keymessage that could be created by the Key >>System. The Key System >> must have a direct TCP connection with the DRM server in order for the >> TLS handshake >>to be done, and the response to be protected, >> end-to-end, from the server back to the DRM client. >> For Marlin MS3 to be used within the EME framework, I imagine that one >> could circumvent the intent of the >>keymessage/addkey pattern, and >> pass in the addkey() response (or the InitData of the createSession >> call) a >>payload containing the URL of the DRM server which the DRM >> client must talk to, and that the DRM client >>would simply go directly >> to the DRM server, bypassing the application. That does not sound very >> clean. >> >> I'd love to hear what people on this email list think about this. >> >> Regards, >> >> -- Gilles -- Giuseppe Pascale Product Manager TV & Connected Devices Opera Software
Received on Tuesday, 7 May 2013 17:37:04 UTC