Re: Authentication and EME functional split

My objection is that in some case (which I outlined for ACTION-7), the first indication to the application of the need for authentication is the key message from the CDM. In those cases, the message from the CDM needs to contain enough information to allow the application to do the authentication required. Since the license server is the server expecting the authenticated credentials, this is a natural place to expect to get the authentication requirements from.

There seems to be a feeling that this is a key-system specific issue, but I believe I can replicate the same issue with all of the major key-systems expected to be implemented. I think I agree with you on the tunneling proposal, but I am not clear how that will solve this problem.

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

On Nov 28, 2012, at 4:48 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

All,

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.

…Mark