W3C home > Mailing lists > Public > public-html-media@w3.org > November 2012

Authentication and EME functional split

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 29 Nov 2012 00:48:19 +0000
To: "<public-html-media@w3.org>" <public-html-media@w3.org>
Message-ID: <8CD99FB4-844B-468A-9FC7-B737570FAC3C@netflix.com>

I wanted to expand on my point about key-systemspecific authentication and the functional split in the EME interface that we discussed on the call this week.

An objective of EME is that it should be possible to support architectures where the client application is keysystem independent. This means that the functionality provided by the CDM and the interaction model is defined by the EME specification and is the same for all CDMs (supporting a given feature). In this architecture the application protocol(s) implemented by the client application are keysystem-independent and (amongst other things like user authentication and authorization) tunnel the CDM keymessages via an application server to some back-end license server.

There's clearly a desire to also support architectures where the the client application communicates with a license server directly. Assuming the license server is keysystem-specific, the client application obviously contains keysystem-specific logic and protocol functions - probably a JS library from the keysystem vendor. Just as in the first case, the protocol used to communicate with the server may include authentication and authorization capabilities.

My point about functional split is that in this second architecture, authentication and authorization are still handled by the client application implementing the license server protocol, not by the CDM. The license server protocol needs to be factored in a similar manner, so that application layer information is separated from the opaque-to-application keymessages. For example if the license server response is required to indicate "authentication required", this indication should be *outside* the keymessage. The username and password information should equally be outside the keymessage in this protocol.

The Microsoft proposal to enable applications to tunnel opaque-to-keysystem information within the keymessages enables implementation of the above model without a need to separately secure the application-layer material in the license server protocol. However, that information must still be opaque to the keysystem - and therefore usable with any keysystem - otherwise we introduce application-visible keysystem-specific behavior below the EME API.

For the "tunneling" mechanism, I think we may need to support tunneling on any keymessage. Thus the createSession and update methods should both support "send-in-tunnel" information and there should be an event which can report "received-in-tunnel" information.

Received on Thursday, 29 November 2012 00:48:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:57 UTC