Marlin MS3 Architecture Options

Flexibility for Marlin MS3 Architecture

Looking through the Marlin MS3 (Marlin Simple Streaming Server) specifications, it is apparent that there are a number of ways of setting this up. The chief difference would seem to be whether or not to run the MS3 server as a standalone server or integrated into another server. Once again, within these options, there are still other variants in the way the service is set up.

In principle, Marlin MS3 provides a simple, lightweight way for a client application to access protected content. The client and server elements use parts of the Marlin codebase to ensure that the client and server are valid devices (as attested by the credentials in their respective certificates) and to securely transfer the decryption key and usage rights from the server to the client.

In all cases, the service provider decides on the usage rights and the back-end systems process the content to add encryption and identification metadata. The content can be served by either streaming or file serving from a traditional edge device. The implementation differences manifest themselves most clearly in the mechanism used to transfer the rights information to the client.

In the standalone model of deployment, the Marlin MS3 server runs as an entirely separate server (or cluster of servers), separated from the business logic manifested in the portal server. At first, this might seem somewhat odd: how could a completely standalone server know what rights to embed in the access statement? The somewhat ingenious answer is that it doesn’t, the business logic (rights, etc) is still managed by the portal server and passed to the Marlin MS3 server via the client. In this scenario, the portal server makes the decision to grant access to the client and the terms under which this is done and wraps this up in a business token which it then passes to the client. The business token effectively contains instructions, encrypted and readable only by the Marlin MS3 server, on the type of access statement to produce. The client can then present the business token to the Marlin MS3 server and in return receives a stream access statement SAS. The Marlin code in the client can then decrypt this SAS and obtain the decryption key and usage rights.

In integrated mode, there is a direct coupling between the Marlin MS3 server components and the business logic. In this mode of operation, the portal server issues a SAS directly to the client without going through the business token exchange step. Such a setup requires that the Marlin MS3 SAS generation code be included in the portal’s implementation.

There are still more variations on how to implement the Marlin MS3 server in standalone mode. The SDK supplied from Intertrust comes with test standalone implementation, an Apache module and a CGI module that can be used in any web server that supports the common gateway interface.

Ultimately, the most suitable type of Marlin MS3 implementation will depend on the scale of the deployment, the level of integration required and the amount of engineering effort available to implement the solution. The standalone approach can offer an easier path to deployment but has the overhead the extra server/client exchange. The integrated approach would ultimately result in a more elegant implementation but requires more integration effort. With both approaches, there are a number of ways in which the solution can be scaled.