Marlin DRM

Marlin is an initiative started by Intertrust Technologies, Philips, Sony, Samsung and Panasonic to develop open standards for interoperable DRM technology (Keoh 2011). The Marlin architecture specifies technologies for building DRM into consumer devices and services, which incorporates two important platform technologies known as the Octopus DRM architecture and Networked Environment for Media Orchestration (NEMO) framework (Marlin 2011). Octopus is a set of specifications and a reference implementation for a simple, open, and flexible DRM engine of core DRM functions to determine whether access should be granted in a given set of conditions, while NEMO combine SOAP (Simple Object Access Protocol) web services with SAML (Security Assertion Markup Language) authorizations to provide end-to-end message integrity and confidentiality protection, entity authentication, and role-based service authorization (Marlin 2011).

Figure 11. Marlin DRM sample interaction (Marlin 2011)

Figure 11 illustrates a sample DRM system interaction. Starting from Step 1, a user uses a client application to browse content published in a web store, which is the front end of all the operations that provide information and choices for the end user.

Once the user selects the preferred content in Step 2, the web store tells the client application where and how to obtain the content by providing an action token that specifies all the DRM-related steps required prior to content playback. In Step 3 the web store also exchanges data related to the user purchase with its back office, which is usually responsible for managing user accounts, license information, performing database transactions, etc. The client application obtains the content from the content server in Step 4. The client application in Step 5 passes an action token to an API provided by the Wasabi SDK, which is an example Marlin client implementation developed by Intertrust which encapsulates all Octopus DRM related functions on the client side. In Step 6 the Wasabi API will process the action token and deliver service requests with business tokens to the Bluewhale server, which is an example Marlin server implementation developed by Intertrust and Sony.

The communication (Step 6 and Step 9) between a Marlin Client (Wasabi in this case) and a Marlin server (Bluewhale in this case) is always via Marlin protocols based on NEMO and the service requests and responses between client and server contain Octopus objects. The Bluewhale server in Step 7 sends server-to-service requests with business tokens to the back office of the web store. The back office applies the business logic and in Step 8 returns the information required by the Marlin server, which in this case is the Bluewhale server. If the negotiation between Bluewhale and back office goes successfully, the Bluewhale server in Step 9 sends a response to the Wasabi SDK with a license to the content. Once both content and its associated license are present on the client application side, the user in Step 10 can request playing of the content. The client application in Step 11 asks the Wasabi SDK to determine whether the license allows the content to be played. If so, the Wasabi SDK decrypts and plays the content with the client application.

Figure 12. Octopus license structure (Marlin 2011)

There are essentially four types of Octopus objects: content, license, node, and link.

The content object represents the multimedia content that is encrypted with a content key. License object specifies the controls that govern the use of the content (Keoh S.L. 2011). As illustrated in Figure 12, a license object is a collection of the following objects:

ContentKey includes encrypted key data.

Protector binds content objects to ContentKey objects.

Control includes and protects the control program.

Controller binds ContentKey objects and control objects.

Metadata provides information to describe the conditions required by the license.

Unlike traditional DRM systems, Octopus does not use a REL to represent usage rules (Boccon-Gibod et al. 2009). Instead, it uses a semantic-free procedural approach, which represents all rules by executable programs expressed as a sequence of bytecodes for a small virtual machine called Plankton. To evaluate a rule, Octopus prepares the inputs for the rule and then executes the byte code. The result of execution determines whether the requested action on the content is granted or denied. Using control program separates the protection of the content from the governance of the content. It provides great flexibility and extensibility in defining

usage rights for the end users and reduces implementation efforts on the client side (Boccon-Gibod et al. 2009).

Figure 13. An example directed graph of Octopus's nodes and links (Marlin 2011)

Besides the license object and content object, Octopus also defines two other important objects: node object and link object. Node and link objects are used to express the relationships between devices the user owns, subscriptions and user’s accounts with the service providers in the form of a directed graph (Keoh 2011). In Figure 13, nodes are illustrated as circles and links between nodes are shown as arrows. Figure 13 indicates that device A belongs to the user Bob, and device B and C belong to both Bob and Carol. Bob subscribes to the video subscription service.

Whether a device is permitted to access content is determined by the control program in the license. Within the control program, the service provider will specify a target node. If the target node is reachable via a link or a chain of links from the device node, then the device node can play the content. Usually, a target node is a user node. In a subscription case, a target node can be a subscription node. Octopus uses a cryptographic scheme called Scuba to leverage the existence of the node and link topology in order to facilitate the distribution of content keys to the client node for consumption. As illustrated in Figure 14, each node is assigned with a set of

Figure 14. Octopus link and node objects (Boccon-Gibod et al. 2009)

With the Octopus DRM engine, Marlin supports various business models. Simple business models, such as pay-per-use, rental, and purchase, can be easily supported by customized control programs defined in license objects. Subscription model and domain usage can be supported with link and node objects. Marlin also specifies dynamic media zones as an extension to the core specification which provides support for the description of different types of zones in media presentation, such as advertisement zones that enables the advertisement business model (Marlin 2011).

In temporary sharing case, Marlin (2011) demonstrates how to achieve temporary sharing with an example use case to play a purchased movie at the friend’s place by using a temporary link node.

Marlin (2011) also proposes a mobile delivery solution called OMArlin to enable interoperable download, streaming, sharing, and consumption of content between OMA and Marlin DRM systems. OMArlin uses the OMArlin content format which is based on OMA content format. An OMArlin content file can contain both OMA rights objects and Marlin licenses, as well as information needed to retrieve a license from a Marlin server or a rights object from an OMA rights issuer. OMArlin also

embraces domains which can contain both devices with OMA DRM agents and devices with Marlin DRM clients.

According to Intertrust (2016), Marlin has been adopted by several national initiatives and standards bodies, such as YouView (www.youview.com) in the UK, TivùOn! (dgtvi.tivu.tv/bollino-tivuon.aspx) in Italy, and the IPTV Forum Japan (www.marlinusers-japan.org). Some of the popular Internet TV services also use Marlin technology. For example, AcTVila (www.actvila.jp) in Japan and HbbTV (www.hbbtv.org) groups in France and Spain have selected Marlin as one of their DRM options. Some standards-based ecosystem, such as Ultraviolet (www.myuv.com) have approved Marlin for distributing premium Hollywood content.