EME compatibility with existing DRM systems

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