Re: Authentication and EME functional split

I replied in the other thread, but I will reply here as well. ;-)

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

On Dec 10, 2012, at 10:08 PM, David Dorwin <ddorwin@google.com<mailto:ddorwin@google.com>> wrote:

I replied to the examples email, but I wanted to comment in the context of this discussion as well. See below.

On Sun, Dec 9, 2012 at 6:20 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:
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.

As I read the examples, it is not the key message from the CDM but the response from the server that indicates authentication is required. It would then be the second key message from the CDM that might indicate the need for authentication. Since you're already paying the price of one server roundtrip, the server could just as easily tell communicate its needs to the application directly.

[steele] This would either require the application to have a-priori knowledge of what the this license server wants or have a standard way that license servers request authentication from the application. Neither of those are feasible IMO.


Since the application knows the key system, it could communicate in a key system-specific way with the server. This means that it could wrap the key message in another protocol and receive the response (authentication request) in that same protocol (rather than in an opaque message for the CDM). In the examples email, the application needs to be able to interpret authentication requests from the CDM (on behalf of the key server). It seems it could just as easily interpret commands from the server.

[steele] Yes, agreed that the application could communicate with the server in a key-system specific way once it knows the key system. I pointed out in an earlier email that this could require security code/keys that the application does not have or that we would not want exposed.


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