Re: Authentication and EME functional split

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> 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.

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.

>
> 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
>
> On Nov 28, 2012, at 4:48 PM, Mark Watson <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
>
>
>
>
>
>
>