OMA DRM 2.0 is backward compatible with OMA DRM 1.0 but goes considerably beyond it in the functionality it supports.  OMA DRM 1.0 was designed for a world of simple, low-cost devices with not much memory, no trusted system clocks, and no sophisticated content rendering capabilities - that is, it was designed to support ring tones and wallpaper graphics.  OMA DRM 2.0, in contrast, is designed for more powerful devices that have the ability to play higher-resolution audio (such as actual music tracks) and video, send content to other devices and storage, and so on.

OMA DRM 2.0 adds two primary elements to OMA DRM 1.0's security model.  One is public-key encryption for protecting the symmetric keys used to encrypt content - a feature that is common in DRM technologies for PCs.  Another is a scheme - yet to be specified, but probably digital certificates or cryptographic digests - for ensuring the integrity of the content itself.  A third added security element, the ability to authenticate devices, is up to the CMLA; see below.

The new standard also adds the ability to support richer content business models, such as stateful rights (e.g., play N times) and, more significantly, the ability to copy content to other devices that a person owns, including backup storage.  Definitions of problematic concepts like "device ownership" and "backup" are left to implementers; of course, content owners are free to grant such rights or not, as they choose.  These business models are expressible in OMA DRM 2.0's rights expression language (REL), which - as before - is based on a subset of ODRL from IPR Systems.

The CMLA, formerly known as Project Hudson, is a complementary effort to OMA DRM 2.0.  Its membership includes companies that span the entire content value chain, from content (Warner Bros. film studios) to wireless carriers (mmo2) to chips (Intel) to devices (Nokia, Matsushita, Samsung) to software (RealNetworks). Its primary purpose is to establish a trust model on which to base OMA DRM implementations - that is, a framework for allowing devices to communicate their authenticated identities to content services as well as to ensure that those devices are impervious to being spoofed (e.g., the identities copied and misused by a third party) or tampered with (e.g., so that perfect cleartext copies of digital content can be made from them). 

To do this, the CMLA has to establish key and digital certificate distribution services, compliance rules and testing tools for vendors to use to ensure that their devices are trustworthy, and legal backstops for devices that are either noncompliant or hacked. 

The essential bargain that CMLA proposes to technology vendors is this: you license OMA technology from us and agree to abide by our compliance policies -- on pain of injunctive and financial penalties -- and in return, we will supply cryptographic materials to your devices and vouch for the devices' trustworthiness to content providers, who will then presumably license content for use on your devices; we will also provide a single licensing point for content providers, so that you don't have to cut separate deals with each one.  Nothing has been said yet about the financial terms, if any, that will be attached to the CMLA's licensing regime. 

Many vendors of devices, client software, and server software are jumping on this very fast-moving bandwagon.  Software vendors that have announced intention to implement OMA DRM 2.0 include RealNetworks, Lockstream, Sun Microsystems (through its Pixo acquisition), NDS, OpenWave, Germany's CoreMedia, and the Netherlands' DMDSecure. (Microsoft is a member of the working group but has not announced intent to launch any compatible products.) Most of the prominent mobile device makers have also pledged support, and already there are over 50 mobile devices on the market that are OMA DRM 1.0 compatible.

The breathtaking rapidity with which OMA DRM is progressing in the market, compared to other DRM-related standards initiatives, arises from one primary factor: mobile devices' simplicity and relative immaturity as content-rendering devices, compared to PCs and other more complex content-rendering form factors.  The modest profile of the target devices for OMA DRM 1.0 implied that the spec should also be very modest, allowing only a narrow range of content distribution models.  That, in turn, made the OMA DRM 1.0 spec something that could be finalized and moved into the market very quickly. 

OMA DRM 2.0 is more complex because it is intended to apply to devices with more capabilities and more security features.  It's amazing what you can do with security when you have a "walled garden" environment instead of a pourous minefield like the PC. 

But it's also a tribute to the efforts of the OMA DRM working group, which chose the paths of near-term practicality and cooperation over those of over-engineered grandiosity and posturing recalcitrance.  As they progress in their efforts, and as mobile content business models grow from their current minuscule state to becoming a bigger part of the overall content distribution market, they should bring security to content owners while freeing up device makers and service providers to offer up content services that appeal to consumers.

As for the CMLA, it looks great on paper, but we are concerned with two elements of its plan.  One is the timeline, which looks insanely aggressive: although the OMA DRM 2.0 spec is not expected to be finalized until close to mid-2004 (which represents slippage from an earlier stated goal of the first quarter of 2004), the CMLA intends to be operational enough to work with devices to be sold in the 2004 year-end holiday season.  Did someone say "SDMI"? 

Our other concern with the CMLA is in the economics.  The services that the CMLA intends to provide do not come for free, and we will be amazed if content providers (or anyone else, for that matter) agree to subsidize them, apart from in-kind donations of equipment and employees' time.  At the end of the day, accepting the CMLA's licensing terms will cost device makers money, in addition to the money they will need to spend on security technology such as OMA DRM 2.0 rights language processors and tamper-proof internal clocks.  If the costs (not to mention the legal liabilties) are too high, device makers will balk at taking the license, and the viability of the scheme will be threatened; if too low, its effectiveness may be in jeopardy.  Nevertheless, we hope to be able to report on many CMLA-compliant content services by New Year's Day 2005.