The Marlin development group released its first set of specifications on Monday, which are available to anyone who signs an evaluation agreement. Marlin is a specification for DRM that can be used on a variety of devices. The development group was first announced over a year ago; its members are Intertrust, Sony, Philips, Matsushita, and Samsung. They expect to make their software available on a community-source basis.
Marlin represents the approach to DRM taken by the consumer electronics (CE) community, particularly makers of portable media players. They represent an "axis of power" in digital media; other axes include Microsoft (with Windows Media DRM), Apple (FairPlay), and the mobile phone makers (OMA DRM).
The idea of Marlin is to create DRM that interoperates among devices from different vendors -- in this case, Sony, Philips, Samsung, and Panasonic (Matsushita). This is a rather unusual step for Sony, which typically prefers to build proprietary technologies and position them as "premium" to the rest of the market. But Sony needs to recover from its existing unsuccessful strategy that includes its own audio format (ATRAC) and DRM (OpenMG), and has not fared well against Apple's iPod and iTunes.
Much of the groundwork for Marlin comes from Intertrust, which is owned by Sony and Philips. Intertrust contributed two primary technology components, Octopus and Nemo. The latter is a secure messaging architecture that enables web services to be built around components in a digital media distribution and rights management scheme. Nemo also figures in the closely-related Coral DRM interoperability project.
Octopus is the most technologically interesting part of Marlin. It is essentially a software toolkit for constructing lightweight DRM systems based on elementary graph theory. The basic idea is this: there are nodes for entities in a DRM scheme that represent users, devices, domains (groups of devices, such as those in one's home), and subscriptions (usage licenses). Marlin-compliant media e-commerce systems create links between the nodes. The primary mode of authentication in Marlin is the user; if there is a series of links that connects a device through a user to a subscription, then the device has rights to the content governed by the subscription.
A subscription node points to a content object that has keys to decrypt content and a control program that determines specific rights to the content. Control programs are written in a bytecode language called Plankton. When a user wants to exercise rights to content on a Marlin client (Marlin-compliant device), the device runs the control program associated with the content. The control program checks to see if there are links from the Marlin client node back to the user's identity. It can also check things like device characteristics (e.g., resolution, fidelity) and data variables (e.g., counters for number of plays). If everything checks out, then the control program enables the content to be decrypted and rights exercised.
The dynamic nature of nodes and link construction/destruction enables Marlin to support many complex paradigms of content usage: for example, if you bring a portable video player loaded with content to your friend's house, then you can make the player a temporary member of your friend's domain so that she can play your videos on her wide-screen TV. In general, Marlin is more flexible than the PC-centric Windows Media DRM schemes for portable and network devices.
One notable aspect of Marlin is that its device eschews the use of rights expression languages (RELs); the functionality to determine what rights a user or device has to content is bound up in the links, nodes, and control programs rather than in a descriptive grammar. Intertrust's technologies have never relied on RELs, even though they are used in some DRMs today, such as the DRM in Microsoft eBook technology (based on XrML from ContentGuard, which is part-owned by Microsoft) and OMA DRM (based on ODRL).
Speaking of OMA DRM, another interesting aspect of Marlin is that it includes an OMA Gateway, which effects interoperability with OMA DRM 2.0 by a Marlin-compliant device (Marlin client) to act as an OMA DRM Agent. From a strategic standpoint, this opens the door for the "mobile phone" axis to interoperate with the "portable player" axis -- which makes perfect sense, given that mobile handsets are adding increasingly sophisticated media playing capabilities.
Marlin has many more features; it is quite a complex piece of technology, one that justifies the year-plus worth of work put into it. At the same time, its graph-theory design is elegantly simple and one of the most fundamental advances in DRM technology to come along in some time.
However, such complexity comes at a price. Marlin's method of authentication is user-centric, as opposed to device-centric, albeit with the ability to establish users' "ownership" of devices. The problem is that user authentication with portable devices can be an expensive proposition; it entails adding hardware/software to portable devices for users to establish their identities.
The normal case that the Marlin group envisions is that the user registers a device with a Marlin registration service, after which the device stores some notion of the user's identity. The user need not authenticate herself to the device after that. This requires, at a minimum, that each Marlin-compatible device be able either to connect to another device (such as a PC) through which the user can register it, or that each device have its own way of connecting to the registration service.
But this scheme could result in a device being registered to one user and then passed around to other users -- or lost, or stolen, the effect of which is similar to one's phone card being stolen. A stronger scheme would need to involve some way for the user to authenticate herself to the device on an ongoing basis, perhaps with a fingerprint or smartcard reader. Some content owners may only be willing to license their content for use with such devices, and a Marlin control program could check for the presence of such capabilities and of the user's authentication.
The bottom line is that the Marlin device companies will need to develop devices that can both connect to registration services (not hard through a USB or Bluetooth connection) and store user identity information securely enough so that users are not concerned with identity theft and content owners are not concerned with cloning hacks.
Yet if the Marlin group members succeed in building reasonably-priced compatible devices and well-stocked content services, then they will have succeeded in creating a digital content ecosystem that can compete with those of Microsoft and Apple. A seamless bridge to the mobile phone/OMA world should increase those chances for success.
Events
IE 7
Firefox 2.0
