The dominant conclusion: "confusion and negative experiences over Digital Rights Management (DRM) is costing billions of dollars in revenue leakage." "Negative user experience" isn't helping much, either.
Speaking to the roots of the problem, Patrick Parodi, chairman of the Mobile Entertainment Forum (MEF) emphasized that revenue is being lost "because of side-loading and the fact that traditional media companies, such as the record labels, are holding back with their copyrights when it comes to mobile distribution until there is a stable DRM system."
And it is not only fear that is causing this, but that mobile operators offer two different types of file formats for PC and mobile downloads.
Tom McLennan, manager of Vodafone music said that OMA DRM 2.0 would help bridge this gap, enabling subscription based business models that are more palatable to stakeholders as well as more easily deployable.
Will it? I think now might be a good time and place for us to understand the distinctions between OMA DRM 1.0 and 2.0.
For that, let's go to Wikipedia:
OMA DRM 1.0 - Started in November 2002 and approved in June 2004: Basic DRM standard without strong protection. Specifies three main methods: Forward Lock, Combined Delivery (combined rights object / media object), and Separate Delivery (separated rights object + encrypted media object). Forward lock prevents the user from forwarding content such as ringtones and wallpapers on their phone. The content can be distributed using e.g. HTTP or MMS.
OMA DRM 2.0 - Started in July 2004 and approved in March 2006: Extension of the DRM 1.0 separate delivery mechanism. Each participating device in OMA DRM 2.0 has an individual DRM PKI certificate with a public key, and the corresponding private key. Each Rights Object (RO) is individually protected for one receiving device by encrypting it with the device public key. The RO in turn contains the key that is used to decrypt the media object. Delivery of Rights Objects requires a registration with the Rights Issuer (RI, the entitiy distributing Rights Objects). During this registration, the device certificate is usually validated against a device blacklist by means of an Online Certificate Status Protocol (OCSP) verification. Thus, devices known to be hacked can be excluded once they try to register with an RI and receive new ROs for content access.