New electronic distribution channels for content, offer new service types for customers and provide new business opportunities for content providers. However the acceptance of these new distribution channels depends on robust mechanisms to protect the interests of the various stakeholders in the value chain. These mechanisms are known as Digital Rights Management (DRM).  DRM must fulfil a number of requirements in order to meet the needs of the stakeholders in the industry and keep up with the expectations of the customers. This paper describes an open DRM architecture, which supports interoperability of DRM technologies.

Digital rights management refers to the control and protection of digital intellectual property, including documents, images, video and audio. DRM limits what a user can do with the content he bought. To date, several proprietary DRM systems are on the market, and so far nobody can safely predict, which of them will become a standard. This situation has already led to some products on the market, addressing the DRM interoperability issue. DRM frameworks are used to ‘translate’ between different DRM systems by:

• A common interface for content packaging, i.e. encryption and specification of usage rules for different DRM systems.

• The possibility for a user to choose between different media players i.e. to watch a video with the Microsoft or Real player.

As a compromise, common DRM frameworks only synchronise the content between different DRM systems and operate the underlying DRM systems in parallel, to give the user the opportunity to play the content with the media player of choice. Consequently, they do not add any functionality to the underlying DRM systems and still have the same restrictions as the underlying DRM systems.

The Eurescom project OPERA (P1207) is specifying and prototyping an open DRM architecture, enabling the interoperability between different DRM systems. The OPERA architecture adds two additional capabilities to common DRM frameworks:

• The usage license is independent of the underlying DRM system.

• The usage license is bound to a user instead of, as is common with existing solutions, to a device.

OPERA directly integrates major DRM systems and uses already available DRM frameworks. On top of these technologies the OPERA license management system supports the following concepts:

• Secure authentication of the user over a telecom provider network (SIM card or phone number). Authentication is additionally possible over other authorisation services, e.g. Liberty or Passport.

• The usage rules are built upon a license model, which every DRM system can handle. The ‘play-once’ license is assumed to be the lowest common denominator for each DRM system.

This means that the system distinguishes between licensees of the underlying DRM systems and ‘OPERA licenses’. While the OPERA licenses support several usage rules, OPERA itself needs only a ‘play-once’ license from the underlying DRM systems. The advantages of this approach are:

• Independent license management, which facilitates the content import for content providers.

• Support for a wide range of usage rules, even though they are not available on the target DRM system.

• Automated license recovery for every connected DRM system even though the DRM system itself is not able to recover licenses.

• Secure storage of the valuable licenses and content for the user.

• Independence from the end user device.

The OPERA-Portal

OPERA system overview

The open DRM architecture aims at standardised interfaces and processes so that interoperability of DRM systems can be achieved. In addition to the focus being on interoperability, the OPERA system also ensures that several usage scenarios are supported by the system in spite of the fact that each underlying DRM system may not support all the usage scenarios. The goal is to achieve a user-based content registration system, which integrates the major DRM systems and frameworks. OPERA uses available technologies and adds its own license management system on top of them. The OPERA license management system – referred to as the OPERA server – is able to assign content to a user, who is registered in the system, and manage a range of usage rules. The OPERA server can provide any level of complex business model independent of the usage models supported by the underlying DRM systems.

The main components of the system are depicted in figure 1.

Figure 1 System overview

Client components

• The Opera Proxy is responsible for connecting the user to the Opera server and adds the users authentication information to the incoming license request from the Player. This component is a core OPERA component.

• The player or viewer application allows users to consume the content they bought. This component depends on the particular DRM system used. This component is a third party component on which the OPERA system depends.

Server components

• The license management layer (OPERA server) is responsible for the management of the rights the users have obtained. These are described through an OPERA license and are stored in a database on a per-user basis. This component is a core OPERA component.

• The license delivery layer is responsible for delivering the licenses of the underlying proprietary DRM-systems to the user’s device. Examples for such systems are DMDfusion and the DWS (Digital World Services) system. This component is a third party component that the OPERA system depends on.

• The enforcement layer is realized by one of the proprietary DRM-systems available on the market. It is called enforcement layer because these systems enforce the compliance to the license agreement by using mechanisms like encryption. This component is a third-party component on which the OPERA system depends.

• The content management layer represents the content utility interface and a media asset management system. For the OPERA system the focus is on the additional possibility to specify usage rules in the OPERA server. This component is not part of the OPERA system but is needed for a running system.

Additional components

• The shop application is used to buy content over a web-based application. The OPERA management layer also uses the shop to verify that the user who requests the license really bought a license for the content. This component is not part of the OPERA system but is needed for a running system.

• The payment application is often part of the shop application but may also be a separate application, e.g. T-Pay or FirstGate. This component is not part of the OPERA system but is needed for a running system.

• The content delivery system should support both download and streaming capability. This component is not depicted in figure 1.

Conclusions

The OPERA architecture describes a system that enables interoperable digital rights management. The OPERA server and OPERA proxy mediate between multiple available DRM systems. The value of the architecture to service providers and network operators is that the components of the architecture have well defined and open interfaces. Hence, DRM system information and usage information is accessible to these service providers and operators. This is a significant departure from the current state where such information is not easily accessible. The OPERA architecture also provides a roadmap for the integration of different DRM systems. This could also facilitate the integration of emerging DRM solutions based on open standards into the OPERA system.

More information about the project can be found at: www.eurescom.de/public/projects/P1200-series/p1207/