Computer Communications 34 (2011) 129–139

Contents lists available at ScienceDirect

Computer Communications

journal homepage: www.elsevier .com/locate /comcom

Approaching the rights management interoperability problem using intelligentbrokerage mechanisms

Carlos Serrão a,*, Eva Rodriguez b, Jaime Delgado b

a ISCTE-IUL/DCTI/Adetti, Ed. ISCTE, Av. Forcas Armadas, 1649-026 Lisboa, Portugalb UPC/AC/DMAG, Campus Nord Mòdul D6, E-08034 Barcelona, Spain

a r t i c l e i n f o

Article history:Available online 8 April 2010

Keywords:Open systemsRights managementBrokerMiddlewareSecurity

0140-3664/$ - see front matter � 2010 Elsevier B.V. Adoi:10.1016/j.comcom.2010.04.001

* Corresponding author. Tel.: +351 912506066.E-mail addresses: carlos.serrao@iscte.pt (C.

(E. Rodriguez), jaime.delgado@ac.upc.edu (J. Delgado)

a b s t r a c t

The digital content industry is facing significant challenges. One of the most significant challenges is theIntellectual Property protection. This challenge has been addressed technologically by using Digital RightsManagement (DRM) systems that on a first stage ensured the appropriate management over digital content.

However, rights management systems, as they are today, are completely non-interoperable, creatingimmense problems to the digital content final users. Perhaps one of the biggest problems is the fact thatthe same digital content that is governed by different rights management systems cannot be exchangedbetween different rights governance systems.

This paper presents some of the work that has been performed under the framework of the VISNET-II Net-work of Excellence (NoE) to address some of the rights management systems interoperability problems. Theapproach followed by the proposed work consists on the usage of service description and service-orientedarchitectures as a mean to create a common and interoperable environment between the different systems.

� 2010 Elsevier B.V. All rights reserved.

1. Introduction stance the Apple FairPlay). A complete analysis of current DRM

The digital era has created diverse opportunities to the world ofdigital media allowing the provision of services for the end-user ina much easier, faster and interactive manner. However, this hasalso created many new challenges that the more ‘‘traditional” con-tent industry was not prepared to face. One of such challenges isrelated to the intellectual property protection. In this new digitalworld, it is easy to create multiple unauthorized copies of contentand to distribute it almost unlimitedly [8]. This is such a big prob-lem for the content industry that is losing control of their old andwell-established business model.

The content industry, based on the possibilities offered by infor-mation technology has created digital barriers for consumers towardscontent enjoyment, in the form of Digital Rights Management (DRM)and Copy-Protection (C/P) technologies. This was the result of contentindustry’s attempt to maintain the same old business models thatwere not at all adequate for the digital age [8].

Rights management technologies, as they are used today by thecontent industry, share a common set of problems. One of the big-gest problems of these rights management technologies is the factthat they are proprietary. These systems were mostly vertical andnon-interoperable implementations of specific business models,and therefore incompatible among themselves (consider for in-

ll rights reserved.

Serrão), evar@ac.upc.edu.

and content protection technologies can be found in [34]. Non-interoperable rights management systems make digital contenthard to use and are in fact an amplifier of the digital content piracyphenomenon – in the sense that they force consumers to find lessrestrictive alternatives [10]. Moreover, the fact that the end-usersare tied (by their own digital content they have legally acquired)to proprietary systems can be extremely penalizing for them. Ifthe digital content company goes out of business (as this has al-ready occurred [23,24]), the client is most of the times impededfrom accessing his/her content.

The rights management interoperability has been (and contin-ues to be) an interesting and challenging problem to solve. Interop-erability has remain an issue for most of the rights managementsuppliers mostly because these suppliers implemented a verticalbusiness model that included a tight control of the full content va-lue chain, from content formats, to rights expression mechanisms,access controls, end-user devices and content stores. Non-interop-erable rights management systems have their days counted andare part of the past. New, open and interoperable rights manage-ment is essential to create an interoperable digital content marketthat addresses both the concerns of the rights holders and theusers’ expectations [11].

VISNET-II Network of Excellence (NoE) is a project of the sixthFramework Programme formed by 12 leading European organisa-tions. The aim of this NoE is to be a reference in the area of Net-worked Audiovisual Media systems. VISNET-II research activitiesare focussed on the video coding, audiovisual media processing

130 C. Serrão et al. / Computer Communications 34 (2011) 129–139

and security areas. One of the aspects that the VISNET-II Projecthad to deal with was the development of mechanisms to allowthe interoperability of a set of different selected open rights man-agement solutions and Access control environments [15].

This paper addresses and describes a system created to providean interoperable environment between different rights manage-ment solutions, using a service-oriented approach.

This paper starts by introducing the concept of open rightsmanagement solutions and their importance to achieve an interop-erable environment. In the following section, the different mecha-nisms specified and implemented are described and a set ofdifferent common functions defined by the open rights manage-ment solutions are identified. The different scenarios where therights management interoperability environment is deployed arealso presented followed by the final conclusions.

2. Open rights management systems and interoperability

Currently the most used and common rights management solu-tions on the market (commercial solutions, like the Windows Med-ia DRM and Apple FairPlay) are completely closed and non-interoperable [15]. These solutions implement their own verticalbusiness models and do not interoperate: content governed byone is not usable by the other and vice versa [16].

More recently, some interoperability initiatives have startedaddressing some of the interoperability issues of commercial rightsmanagement. One of the most relevant systems that deal withrights management interoperability is Marlin [25]. Marlin is a ver-tical approach to interoperability promoted by a set of commercialcompanies (mostly producers of consumer electronic devices). Inthis part, we will introduce a small section dedicated to the Marlinapproach to interoperability.

The authors of this paper are convinced that interoperability isonly possible for digital rights management, if the different solu-tions are open [15,22]. In this context, openness is only achievableif one of the following requirements is met:

� Rights management components and functions should beopenly specified, so that the present functionalities could beextended and new ones could be easily integrated.� The open and available implementation of such rights manage-

ment components should exist in an open-source code regime.

If these requirements are not met, the interoperability solutiontends to become proprietary and dependent of a specific supplier(or group of suppliers). These solutions are usually used to offerinteroperability to a limited number of rights management systems.The existence of open specifications and, additionally, open-sourceimplementations allow the extensibility of the interoperabilitysolution to many more different existing (and future) rights man-agement systems.

Some existing rights management systems satisfy such require-ments, however, they have low market expression. The system pre-sented in this paper proposes also a different approach to the rightsmanagement interoperability problem followed by similar initia-tives (such as Marlin or Coral). While in these two systems, the ap-proach to interoperability is mostly client-centric, our system isservice and server-centric. The approaches to interoperability dif-fer in their philosophy:

� The client-centric interoperability approach, refers to rightsmanagement interoperability systems that force any other solu-tion seeking interoperability to produce changes in their ownlogic to comply to a specific interoperation scenario – this iswhat is offered by Marlin, for instance.

� The service and server-centric approach, refers to rights manage-ment interoperability solutions that do not interfere (or interferevery little) with the existing ones. All the adaptation and supportto the interoperable mechanisms occur at the service descriptionlevel or at the server level to accommodate the requirements ofeach system seeking for interoperability – this is the approachthat is followed by the system presented in this paper.

The work and the system presented in this paper are the result of anon-going related work on the field of rights management solutionsand on the definition of open and interoperable rights managementsolutions.

For the work presented here, a limited set of different openrights management solutions were considered: OpenSDRM [6],MIPAMS [12] and OMA-DRM [21]. A small description of each ofthese open rights management solutions is presented in the fol-lowing sections. Also a small description of the Marlin interopera-bility initiative is presented.

2.1. OpenSDRM

The Open and Secure Digital Rights Management system(OpenSDRM) [29] is an adaptable DRM architecture [6]. This archi-tecture can be configured for use with several business models anddifferent types of content. OpenSDRM deploys a traditional DRMsolution for content rights protection and can be applied for pub-lishing and trading of digital multimedia content (Fig. 1) [30].

OpenSDRM architecture it is based on MPEG-4 IPMP Extensions(MPEG-4 IPMP ‘‘hooks” extended with OPIMA specifications).Emerging at that time MPEG-21 components such as Digital ItemIdentification (MPEG-21 DII) have also been used. OpenSDRMwas developed primarily in the scope of the MOSES project. MOSESwas an FP5 EC project where a number of companies around theworld joint their efforts in implementing the MPEG-4 IPMP Exten-sions framework and at the same time validate it by developingbusiness models and applications for secure content exchange be-tween embedded devices [16]. This DRM solution is composed ofseveral optional elements covering the content distribution valuechain, from content production to content usage [31]. It covers sev-eral major aspects of the content distribution and trading: contentproduction, content preparation and registration, interactive con-tent distribution, content negotiation and acquisition, strong actorsand user’s authentication and conditional visualisation/playback.Even though the MOSES project refers explicitly to MPEG-4 file for-mat as the content format, this infrastructure was designed withthe concern to be adaptable and applicable to all types of contentand business models (both for download, streaming or even broad-casting) [5,6].

2.2. MIPAMS

Multimedia Information Protection And Management System(MIPAMS) [1–3] is an architecture to manage multimedia informa-tion taking into account DRM and protection.

MIPAMS is a service-oriented DRM platform [32,33] and all itsmodules have been devised to be implemented using web servicestechnology, which provides flexibility and enables an easy deploy-ment of the modules in a distributed environment, while keepingthe functionality independent from the programming languageand enabling interoperability (Fig. 2).

MIPAMS encompasses an important part of the whole contentvalue chain, from content creation and distribution to its consump-tion by final users.

In the MIPAMS architecture context, we can define two impor-tant concepts: Components and Actors. An Actor is a user (personor an organisation) that uses a Component. A Component is mod-

Fig. 1. The OpenSDRM rights management system.

Registration Server

Supervision Server

Governance Server

Content Server

Certification Authority

Protection Server

Adaptation Server

Trusted Client

Inte

rmed

iary

Reporting

Protection Information

Certification

Certification

Verification, Reporting

Reporting

License Production and

Storage

Content Adaptation

Content Protection, Protection Information

Generation and Storage

Authorisation

Authentication, Certification, Verification, Reporting

Authorisation, License Download,

Protection Information

Browse and Select Content

Protection Tools Download

User

Fig. 2. The MIPAMS architecture.

C. Serrão et al. / Computer Communications 34 (2011) 129–139 131

ule or set of software tools that offers a subset of DRM-relatedfunctionalities and which interacts with other components.

2.3. OMA-DRM

This is the DRM system defined by the Open Mobile Alliance(OMA), a forum of more than 200 industry partners leading activ-ities on the mobile communications environment. This system is

implemented by mobile devices provided by the different manu-facturers and has to be interoperable among them [20,21].

The scope of OMA-DRM (Open Mobile Alliance-DRM) [20] is toenable the controlled consumption of digital media objects byallowing content providers the ability, for example, to manage pre-views of DRM Content, to enable super-distribution of DRM Con-tent, and to enable transfer of content between DRM Agents. TheOMA-DRM specifications provide mechanisms for secure authenti-

Fig. 3. OMA-DRM generic architecture. Fig. 4. iRMBroker operational environment.

132 C. Serrão et al. / Computer Communications 34 (2011) 129–139

cation of trusted DRM Agents, and for secure packaging and trans-fer of usage rights and DRM Content to trusted DRM Agents (Fig. 3).

OMA-DRM defines a set of Actors and Components in its referencearchitecture. The most relevant are the DRM Agent (DRM A), ContentIssuer (CI), Rights Issuer (RI), User and Off-device Storage [21].

The DRM Agent represents a trusted entity in a device. This en-tity enforces permissions and constraints associated with DRMcontent, controlling the access and usage of DRM content.

2.4. Marlin

The aim of Marlin [25,26] is to create a DRM system that inter-operates among devices from different vendors. It is based on pre-vious work developed by Intertrust in Networked Environment forMedia Orchestration (NEMO) [27] and Octopus [28] projects.Whereas the first is a secure messaging architecture based onweb services for digital media distribution and rights management,the latter is a software toolkit for developing lightweight DRM sys-tems based on elementary graph theory.

In Octopus, there are nodes for entities in a DRM scheme thatrepresent users, domains, devices and subscriptions (licenses)[26].A device has rights over a content governed by a subscriptionif there is a series of links that connect the device to a subscriptionthrough a user. Those links are created by e-commerce systems,which are Marlin compliant [26]. To determine if a user has rightsover the content, there must be a series of links that connect theuser to a subscription. The subscription node points to the contentobject, which contains on one hand a control program written in abyte-code language called Plankton and the keys used to decryptthe content. In this way, when a user wants to exercise a right overa content, the Marlin client will run the control program associatedto that content to determine whether he is authorised or not bychecking if there are existing links from the client node to theuser’s identity [26].

From an interoperability point of view, any device willing toimplement the Marlin interoperability layer have to be imple-mented according to the specific Marlin defined SDKs and APIs.

3. Rights management interoperability architecture

Designing and building an interoperability layer between differ-ent rights management solutions can be a painful achievement[16]. In order to achieve the interoperability between the selectedopen rights management systems, the authors of this paper de-

signed a brokerage based-architecture that will enable selectedinteroperable operations between the different rights managementsystems [9].

The interoperable Rights Management Broker (from this pointon referred as iRMBroker) is composed of a different set of modulesthat provide interoperability at three distinct levels: (a) betweendigital rights; (b) between digital objects and digital media; and(c) across protection information. Moreover, the iRMBroker man-ages users’ roles in different rights management systems.

The objective of this iRMBroker is to enable the interaction ofdifferent rights management systems in a fully interoperable envi-ronment (Fig. 4) established between them. The iRMBroker acts asan intermediate module passing rights management related mes-sages and allowing operations to be invoked between the differentrights management systems.

In order for this scenario to be possible, the following approachhas been followed:

1. Identify which are the most relevant architectural componentsand rights management operations that are common to theselected open rights management systems.

2. Create generic mapping functions between the different ‘‘com-mon” rights management functions.

3. Implement an ‘‘orchestration” of the identified generic rightsmanagement functions in a distributed interface.

4. Implement a public and open interface that maps between onespecific rights management solution and the generic functionon the middleware brokerage component.

Using this approach, it is possible to use a specific rights manage-ment functionality provided by one specific rights managementsolution (DRM A) on another (DRM B) through the mediation ofthe iRMBroker.

From an architectural point of view, the iRMBroker implemen-tation will require two basic assertions:

(a) The iRMBroker public interface is available to all the rightsmanagement solutions seeking interoperability throughthe iRMBroker.

(b) Each of the specific rights management solutions will alsoimplement a public and open interface of the functions theyinternally provide.

Such a brokering environment will be established through the ser-vice-oriented architecture paradigm [14]. The above-mentioned

Fig. 5. iRMBroker internal modules.

C. Serrão et al. / Computer Communications 34 (2011) 129–139 133

interfaces are described using the Web-Services Description Lan-guage (WSDL) and the access to such interfaces is made throughSimple Object Access Protocol (SOAP) messages (Fig. 5). This wasspecific to the implementation followed, but other technical op-tions, such as REST, could also be possible.

The main role of the iRMBroker consists in the redirection of theseveral requests from the different rights management systems tothe appropriate one. Internally to the iRMBroker, a mapping is pro-duced between the Common Generic WSDL interface (CGWi) andthe specific Rights Management Solution WSDL interface. Thisway, the broker will know which service to invoke and which mes-sage to route, when a generic request is received.

The iRMBroker is responsible for the implementation of the fol-lowing core middleware services:

1. Digital Media Formats Converter, that will be used to convertbetween the different types of content used on the differentrights management governance regimes.

2. Digital Rights Translation, that will be used to convert betweenthe different types of rights expression mechanisms and expres-sions used by the different rights management solutions.

3. Protection information manager, that will be used to convertbetween the different protection information mechanisms thatresponsible for the digital content protection, and that are spe-cific of the rights management solution used.

4. Roles manager, which will be used to manage the different sys-tem actor roles on the selected rights management systems.

As a basic requirement of the depicted solution, a generic mappingbetween the different rights management solutions (which are innature, open) and the broker functionalities must exist. This mapping,implemented as a set of ‘‘connectors” make possible the interactionbetween the different rights management system elements (Fig. 5).

The redirecting mechanism that is described in this paper, isonly possible due to the fact that each of the participating openrights management solutions integrates a common interface thatimplements the mapping between the different generic functions(as they are specified by the Common Generic WSDL interface)and the internal functions of the broker. Another crucial aspect ofthis interoperability solution is the establishment of a commontrust environment between the different brokerage participants[13]. This trust environment is absolutely crucial to allow the differ-ent rights management functionalities to be trustworthy and topermit the exchange of operation information and digital contentin a secure and trust environment. This trustworthy environmentis facilitated by the iRMBroker. The iRMBroker requires the registra-tion of each of the participants (the different open rights manage-ment systems that wish to interoperate need to be registered) on

the brokerage mechanism. Therefore each of the open rights man-agement solutions that use the iRMBroker services will need toget ‘‘certified” by the broker. When this step is concluded, a digitalcredential is issued to the requesting rights management solution.

The interoperability layer established between the differentrights management solutions creates a common trust environmentbetween the different elements. The major objectives of this trustenvironment is to provide the following:

� The trust between the rights management (RM) solution andthe iRMBroker, to ensure that an non-authorized rights man-agement solution (or an attacker trying to mimic one) will nottry to short-circuit the security established.� To ensure a common trust point on the iRMBroker.� To ensure the global trust between the different RM solutions

using the iRMBroker brokerage mechanisms.

A group of steps are required to establish trust. This trust establish-ment mechanism is processed in the following way (this is commonin any public-key cryptography schema):

1. Both the RM solution and the iRMBroker hold a key pair: for the

RM solution KpubRM ; Kpriv

RM

� �and for the iRMBroker Kpub

iRMBroker;�

KpriviRMBrokerÞ. Both the entities will have to ensure that their pri-

vate keys are never compromised in any manner.2. The RM solution contacts the iRMBroker and requests the enrol-

ment on the broker.3. iRMBroker receives the request and asks for some specific

enrolment data from the RM solution – this data includes thename and the provider of the RM solution, a description ofthe RM solution (that includes the WSDL description of thefunctionalities provided by the RM solution) and also (option-ally) some contractual data. It requests also the public-key fromthe requester.

4. The RM solution computes a key pair KpubRM ;K

privRM

� �. The private

key KprivRM

� �is securely stored while the public is prepared to

be sent to the iRMBroker.5. The RM solution sends the requested enrolment data and the

public-key KpubRM

� �to the iRMBroker.

6. The iRMBroker verifies all the enrolment data sent by the RMsolution.

7. If the data are properly validated then the iRMBroker creates anew digital certificate for the requesting RM solution

CertiRMBrokerRM

� �. This certificate contains the identification of

the RM solution as well as its public-key.8. The iRMBroker registers this information and sends the answer

back to the RM solution.9. The RM solution receives the answer and store the digital certif-

icate issued by the iRMBroker.

The process described above establishes the trust basis for all fur-ther operations that are conducted through the iRMBroker middle-ware. All the other operations require that the requesting party tosend their credentials to be properly accredited as an entity thatcan be trusted on the system.

3.1. Digital media formats converter

Different rights management systems often use different for-mats of digital objects. Open Mobile Alliance-DRM uses the DRMContent Format as the way to encapsulate the digital objects, MIP-AMS uses MPEG-21 DIDL whereas OpenSDRM is independent ofany content format. Therefore, it is evident that a mechanism is

134 C. Serrão et al. / Computer Communications 34 (2011) 129–139

necessary to permit the translation between different digital con-tent formats. In the proposed system, this will be also one of theroles of the iRMBroker Digital Media Formats Converter – convert-ing from one specific format to another.

In a typical governed digital content scenario, a Rights Manage-ment solution ‘‘A” (DRM A) wants to access content formatted inanother rights management format (DRM B). The following se-quence details how the interaction will occur between the differ-ent elements:

1. ‘‘DRM A” has obtained content in ‘‘DRM B” format. DRM A doesnot know how to handle this format.

2. ‘‘DRM A” contacts the iRMBroker and requests that specific con-tent item to be converted to a ‘‘DRM A” friendly format. By this,the rights governance solution requests that the broker toobtain the digital content in a format that is understood bythe requesting rights management solution.

3. iRMBroker verifies the ‘‘DRM A” credentials and validates them.4. iRMBroker tries to verify if it is able to identify the rights man-

agement system that generated the content.5. iRMBroker requests to ‘‘DRM B” the raw digital content access

on the object.6. ‘‘DRM B” unpacks the content and returns the raw digital

content.7. iRMBroker requests to ‘‘DRM A” to package the raw content in a

‘‘DRM A” friendly format.8. iRMBroker returns to ‘‘DRM A” the converted item.9. ‘‘DRM A” can now use the item.

The iRMBroker provides the necessary redirection (Fig. 6) function-alities to handle content conversions from different formats.

It is important to note that iRMBroker is not a translation service.It would be virtually impossible for a single entity to act as ‘‘global”and ‘‘universal” converter for each of the available formats. Rather,the iRMBroker acts as a middleman that routes the translation re-quests to the appropriate rights management regimes that are ableto access, produce and manipulate the digital object.

Depending on each specific and particular case, this translationusually process involves two different phases:

1. Using the appropriate RM regime to be able to unprotect thecontent and get access to the raw content format.

2. Using the appropriate RM regime to be able to re-protect andpackage the raw content in the appropriate format.

The conversion of formats implies that the different interoperablesolutions need to implement internally the translation mechanisms.These mechanisms provide the following:

Fig. 6. Converting from one rights management format regime to the other.

� A mechanism that transforms from raw content to protectedcontent:� A content protection mechanism that takes content encryp-

tion keys and protects the content.� A content packaging mechanism that takes a set of rights,

rules and a specific format and applies to the encrypted con-tent a specific organization and packaging.

� The result from this operation is the protected packaged con-tent that is specific of a given rights management solution.

� A mechanism that accesses the protected content and returnsthe raw content:� A content un-packaging mechanism that takes the protected

packaged content and using the appropriate format, rulesand rights extracts the protected content from the packaging.

� A content unprotection mechanism that takes the contentencryption keys and extracts the raw content.

� The result from this operation is the raw unprotected andun-packaged content.

3.2. Digital rights translator

This section provides a description of the operations imple-mented by the license translator module with the goal of achievinginteroperability between the different licenses of the open rightsmanagement systems considered [12] for interoperability testingthrough the usage of an intelligent broker (MIPAMS, OpenSDRMand OMA-DRM).

MIPAMS uses a rights expression mechanism that is based onthe MPEG-21 REL [7,19], while OMA-DRM is based on ODRL. Inthe case of OpenSDRM, the existence of license template mecha-nisms makes this solution independent of any specific rightsexpression language [17].

Accordingly, the only conversion that this module will need toprovide occurs between the MPEG-21 REL and ODRL. Since thereare no guarantees that conversion services will be provided byany of the referred DRM systems, it is thus necessary that this func-tionality is internally implemented by the iRMBroker (Fig. 7). How-ever, if some of the specific rights management solutions providethese rights expression conversion mechanisms, the iRMBrokerwill use them instead.

In order to achieve these conversion functionalities, the iRM-Broker passes the requests from the different RM solutions to en-able the translation of rules/rights from the different rightsmanagement regimes and formats. The different rights manage-ment solutions need to implement the appropriate conversionmechanisms that allow the interoperability between the differentformats. There may exist some situations in which a direct andcomplete conversion cannot be entirely achieved, due to the lackof rules/rights expressiveness in some language formats. In suchcases, two strategies are possible. Either simply the conversion is

Fig. 7. Converting between different rights management licenses formats.

C. Serrão et al. / Computer Communications 34 (2011) 129–139 135

denied or the conversion occurs but some expressiveness, and inconsequence some rights may be loss. This is not a decision ofthe iRMBroker itself, but a decision of the different solutions andof the business models that are implemented.

This rules/rights translation process may involve the followingoperations:

� Rules/rights un-boxing and unprotection.� Rules/rights format interpretation.� Raw rules/rights extraction.

Once these mechanisms are internally implemented by the differ-ent interoperating rights management solutions, they will providethe functionalities to migrate from one specific rules/rights regimeto another. These mechanisms expose different functionalities:

� Translation from raw rules/rights to protected and formattedrules/rights:� Formats the raw rules and rights selected for a particular

purpose according to a given format.� Protects the access to certain parts of the formatted rules/

rights (either preventing modification or visualization) usingthe appropriate methods and/or keys.

� Boxes or shields the set of formatted rules/rights, preventingthem from being modified, using an appropriate signaturemechanism.

� The result of this mechanism is the rules/rights formattedprotected and formatted on a specific manner.

� Translation from a given protected and formatted rules/rights tothe extraction of the raw rules/rights:� This mechanism takes the protected and formatted rules/

rights and verifies the signatures to validate that they havenot been tampered and modified.

� Unprotects the protected parts of the set of rules/rights usingthe appropriate keys and methods.

� Analyses the format and extracts the set of rules/rights usingthe appropriate format parsing tools.

� The result of this operation is the raw rules/rights.

3.3. Protection information manager

This section of the paper provides a small description of theoperations that the protection information translator module willhave to implement to provide interoperability between the differ-ent rights management systems.

Fig. 8. Interoperability scenario betwe

As it was previously referred, in the MIPAMS rights manage-ment system, the Digital Objects are protected following the ISO/IEC 21000-4 [18] standard specification. Then, they can be pro-tected at any level of granularity, from a complete Digital Objectto a specific digital resource; and the information describing theprotection tools used is associated to the specific protected partof the Digital Object. In the OMA-DRM system, digital objects areprotected as defined in the OMA-DRM specification. Finally, inthe OpenSDRM system the mechanism used to protect informationis dependent on the different situations and scenarios.

3.4. Roles manager

The Roles Manager module from the interoperability rightsmanagement broker manages the roles of users of the differentrights management systems. In all these systems, authenticationof users involves the correct users identification and users rolesassignment and management. These identifications and rolesmay be significantly different from rights management solutionsto rights management solutions.

The interoperability rights management broker will be respon-sible for the validation of the provided user identification tokenand for assigning to the user the role (s) that he/she has in the sys-tem that manages the governed content he/she is trying to accessand use.

4. Application scenarios

The proposed solution has been designed to be used in a widevariety of applications, where different rights management sys-tems needs to interoperate. Main areas of use include collaborativeapplications, e-Services, multimedia content management applica-tions, etc. Of all those mentioned, this section describes how theproposed system works on two of them: virtual collaborationand video surveillance.

To test the rights management interoperability functionalitiesthat were implemented in the iRMBroker, it was designed andimplemented a specific set of application scenarios. Having thisin mind, the project team has developed a prototype to enablethe different rights management systems to interoperate in a Vir-tual Collaboration and Video Surveillance applications scenarios.

However, before the above complex scenarios are further ex-plained we will examine a simpler one based on OpenSDRM andMIPAMS. In a first developed scenario two different rights manage-

en the OpenSDRM and MIPAMS.

Fig. 9. Interoperability VC scenario between OpenSDRM and OMA-DRM.

136 C. Serrão et al. / Computer Communications 34 (2011) 129–139

ment solutions were considered – OpenSDRM and MIPAMS. TheiRMBroker, in this scenario, allowed the OpenSDRM client to useMIPAMS formatted content without understanding and parsingthe content.

The OpenSDRM client that previously received MIPAMS gov-erned digital content uses the iRMBroker to gain access to the con-tent and to render it. In this operation, the OpenSDRM rightsmanagement system contacts the iRMBroker and sends the loca-tion of the MIPAMS formatted content to it. The broker operateswith the CGWi interface of the MIPAMS rights management solu-tion to perform the necessary processes and to obtain the protec-tion information related to the object (Fig. 8).

The OpenSDRM client player has obtained a MIPAMS formattedand governed content. This content formatted as an MPEG-21 Dig-ital item [4], is basically composed of relevant metadata and the ci-phered resource. To obtain the necessary protection information,to perform the authorization process and to obtain the content torender, the OpenSDRM client player should implement a full MIP-AMS client, but this is a heavy process and the client will grow witheach new DRM system added to which interoperability is required.

This is a poor way to achieve the interoperability between thedifferent DRM systems and therefore not the solution that has beenfollowed on this work. To avoid the OpenSDRM client to performthis process, iRMBroker will enable the OpenSDRM to obtain thecontent in a format that is completely transparent for OpenSDRM,and will abstract OpenSDRM from the required operations to per-form to obtain such content.

This process (Fig. 8) can be summarised in the following steps:

1. The OpenSDRM Client player receives and wants to render aMIPAMS formatted and governed content.

2. The OpenSDRM Client, invokes the iRMBroker, passing the con-tent URI (Uniform Resource Identifier) and a set of credentials(obtained upon registration).

3. The iRMBroker validates the OpenSDRM platform, identifies theMIPAMS digital governed content pointed by the URI, the MIP-AMS platform location and validates the credentials presented.

4. The iRMBroker, invokes the appropriate MIPAMS instance,through the publicly available CGWi operations.

5. The MIPAMS Servers will perform the necessary Authorisationprocess and will retrieve the protection information (aboutthe digital governed content).

6. If the authorization process has succeeded, MIPAMS will extractthe raw content, deciphering it using the protection informationobtained.

7. The obtained raw unprotected content will be ciphered by MIP-AMS with some credentials, and with an algorithm supportedby the OpenSDRM client – this credentials will be made avail-able to OpenSDRM in a protected format, through theiRMBroker.

8. The OpenSDRM client obtains the content ciphered and the cre-dentials and keying material to decipher it.

9. The OpenSDRM client deciphers the content and renders it.

This basic scenario demonstrates clearly how the iRMBroker andthe CGWi implemented at each of the open rights managementsolutions interoperating, can be used to provide the necessary inter-operability between different digital governed content types.

4.1. Virtual collaboration scenario

This section presents how the DRM interoperability prototypeworks in Virtual Collaboration (VC) applications. In this Virtual Col-laboration scenario, three different organizations – Aa, Bb and Cc –have setup a collaborative working environment using the iRMBrok-er prototype to allow them to work together on a distributed project

to design and produce a new widget, in which each organization usesits own rights management solution. The ‘‘Aa” organization protectsand applies a governance mechanism to their digital content usingthe MIPAMS rights management solution. On its turn, the ‘‘Bb” orga-nization uses the OpenSDRM rights management solution while the‘‘Cc” organization uses OMA-DRM (Fig. 9).

The collaborative widget production process consists of threedifferent phases: design, review and production. During the designphase, a specification document is jointly produced by designers inthe ‘‘Aa” and ‘‘Bb” organizations over a defined number of weeks.At the end of this period, a final version of the document is readyfor review by the project managers from all the involved organiza-tions. After reviewing it, the document is finally released to allowthe engineers from ‘‘Bb” and ‘‘Cc” organizations to start workingon the production of a widget prototype. The production of thiswidget is considered to be highly commercially sensitive by theorganizations involved in the process. Therefore, all the differentstages of the document production process will have to ensure thatthe document is properly protected and governed, by a specificrights management system.

During the widget design phase of the project, the design docu-ment, which contains the specifications for the widget, is pro-duced. In the following walk-through, we consider that ‘‘Alice”, adesigner in organization ‘‘Aa” wishes to work on the current designdocument. In this use case, we assume that ‘‘Alice” was registeredin the system as a designer of organization ‘‘Aa”. ‘‘Alice” possessesa license that entitles her the ‘‘Aa” organisation designer role. Onthe other hand, the widget design document has been created bya ‘‘Bb” organisation designer and it is protected and governed bythe OpenSDRM rights management system.

This use case initiates when ‘‘Alice” downloads the protectedand governed design document, opens it with her specific viewingtool, which includes the appropriate plug-in, and tries to load thewidget design document.

The steps that are involved in the management of the designdocument use case, are the following (Fig. 10):

1. ‘‘Alice” authenticates herself in the system, first using herusername and password, and obtaining an authenticationtoken that will be later used to authenticate her while inter-acting with other services.

2. ‘‘Alice” tries to load the widget design document on her spe-cific tool.

3. The MIPAMS client invokes the iRMBroker, passing the designdocument or its URI and a set of credentials. The iRMBroker val-idates the MIPAMS platform, identifies the OpenSDRM content(design document) and the OpenSDRM platform location, andvalidates the credentials presented. The iRMBroker, invokesthe appropriate OpenSDRM instance, through the publiclyavailable CGWi operations. The OpenSDRM system performsthe authorization process and retrieves the protection infor-

Fig. 10. Design phase use-case – positive authorisation.

C. Serrão et al. / Computer Communications 34 (2011) 129–139 137

mation (about the content). If the authorization process hassucceeded (‘‘Alice” is a designer from ‘‘Aa” organization), theOpenSDRM system extracts the raw content, deciphering itusing the protection information obtained. The obtained rawunprotected content will be ciphered with some credentials,and with an algorithm supported by the MIPAMS client – thesecredentials will be made available to the MIPAMS rights man-agement system in a protected format.

4. As the authorization process has succeeded (‘‘Alice” is in facta designer of ‘‘Aa” organisation), the MIPAMS client obtainsthe ciphered content and the credentials to access it.

5. The MIPAMS client deciphers the content.6. The MIPAMS client renders it (the unprotected document is

loaded).7. ‘‘Alice” makes some changes in the design document and

attempts to save the new version of the document.8. The trusted module requires authorisation to the Gover-

nance server.9. The authorisation is positive, since ‘‘Alice” is an ‘‘Aa” organiza-

tion designer and she has the rights to modify the document.10. Governance server sends the pertinent action report to

Supervision server, denoting the positive authorisation.11. Supervision server confirms the storage of the report.12. Governance server generates and stores the usage license for

the new version of the design document based on the termspresent in the license governing the original content.

13. Governance server notifies the positive authorisation resultto the client trusted module and returns the identifier ofthe new license.

14. The trusted module uses one of the protection tools it has toprotect the content, generates a protection key for the con-tent and generates the protection information that will beassociated to the Digital Item (DI).

15. The trusted module registers the protection key in the Pro-tection server.

16. The client trusted module creates a new DI. It contains theprotected version of the document, a reference to the licensegoverning the protected content, the protection informationand the processing information.

17. The DI is stored in the Content Server.18. Confirmation is sent to the user

4.2. Video surveillance scenario

This new section describes how the rights management interop-erability prototype works in Video Surveillance application scenario.In this chosen video surveillance scenario, a magistrate wants to re-view the video of a robbery in an ATM machine of a bank branch. Theimages have been recorded by the video surveillance system of thebank, and a protected version of the video is stored in a central data-base. The magistrate, who is reviewing the case at home, wants toview the images in his PDA, which supports the OMA-DRM contentformat, while the rights management system chosen by the bankto manage digital video surveillance content is the MIPAMS rightsmanagement system. The next image (Fig. 11) sketches a possiblearchitecture for the proposed scenario. In this scenario, the magis-trate has a PDA, which has an OMA-DRM player. The MIPAMS system

Fig. 11. Interoperability video-surveillance scenario between MIPAMS and OMA-DRM.

138 C. Serrão et al. / Computer Communications 34 (2011) 129–139

Content Server has recorded and stored a protected version of thevideo.

In the depicted use-case, the magistrate, ‘‘John”, downloads theprotected and governed video surveillance contents, and tries toaccess them from his PDA. In the following walk-through, we as-sume that ‘‘John”, the magistrate, was registered in the system.Then, he has a license that gives him the magistrate role (Fig. 12).

The video-surveillance video visualisation use-case, is depictedon the following steps:

1. ‘‘John” authenticates himself in the system, first using hisusername and password, and obtains and authenticationtoken that will be later used to authenticate him when inter-acting with other services.

2. ‘‘John” tries to view the video in his PDA.3. The OMA-DRM Client invokes the iRMBroker, passing URI of

the video and a set of credentials.

Fig. 12. Video visualisation use-c

4. The iRMBroker validates the OMA-DRM platform, identifiesthe MIPAMS content (video) and the OMA-DRM platformlocation, and validates the credentials presented.

5. The iRMBroker, requests authorization to the GovernanceServer of the MIPAMS system, through the publicly availableCGWi operations.

6. The Governance Server of the MIPAMS system performs theauthorisation process.

7. As the authorization process has been positive (John has per-missions to view the video), the Protection Server of theMIPAMS system sends to the Content Server the protectioninformation.

8. The Content Server of the MIPAMS system extracts the rawcontent from the Digital Item, deciphering it using the pro-tection information obtained. The obtained raw unprotectedcontent will be ciphered with some credentials, and with analgorithm supported by the OMA-DRM client – these cre-dentials will be made available to OMA-DRM system in aprotected format.

9. The OMA-DRM Client obtains the content ciphered and thecredentials to obtain it.

10. The OMA-DRM Client deciphers the content.11. The OMA-DRM player renders it (the unprotected video is

played).

5. Conclusions

One of the ‘‘Achilles Heel” that has been frequently pointed outto the current existing rights management solutions, is the factthat these solutions are mostly dedicated to the implementationof vertical, closed and outdated digital content business models,that are particularly harmful for the digital content end-users, lim-iting their own content user-experience. At the same time these

ase – positive authorization.

C. Serrão et al. / Computer Communications 34 (2011) 129–139 139

rights management solutions are not working at all in the benefitof the content providers and authors, and hardly prevent that con-tent access rules and rights management rules to be circumventedby a decided and motivated user.

This serious rights management problem is caused by the factthat current existing rights management solutions do not interop-erate. They are closed in their own nature, and make digital gov-erned content hard to use. This is a situation that has to changesooner or later.

Interoperability between the different rights managementsolutions was one of the topics addressed by the VISNET-II pro-ject in order to create governed digital content application sce-narios, where a homogeneous rights management environmentwas setup to ensure the interoperability of the different distrib-uted participating entities. The work and the system presentedin this paper represent the result of research and the develop-ment being made by the authors in the rights management fieldfor several years.

The authors of this paper conceptualized, designed and imple-mented a structural rights management architecture, based onthe establishment of an intelligent brokerage mechanism, callediRMBroker, capable of providing smart routing mechanisms be-tween the different functionalities exposed by the selected openrights management solutions.

The work conducted in the project and described in part on thispaper was based on the assumption that the rights managementsolutions would expose their internal functionalities to the use ofthird parties. Therefore, for this work, a set of open rights manage-ment solutions were selected, and a mapping of the common func-tions between all of them was created. These common functional-ities were exposed by a common gateway WSDL interface that wasused for the iRMBroker to invoke the different operations on the na-tive rights management platform.

In order to make everything work, a common trust environmenthad to be created in such a way that each of the different rightsmanagement solutions would have to be trusted to each other.The iRMBroker assumed the role of registering the different rightsmanagement solution and issued the necessary trust credentials toall of them. This way it would be possible for a governance solutionto trust operations to be carried by any of the other DRM systemsregistered with iRMBroker.

After this intelligent brokerage mechanism was created, basedon a service-oriented architecture where the different functional-ities of the open rights management were publicly exposed, a setof use-case scenarios was setup to test the solution and to provethat it worked on the real world.

The authors of this work are strongly convinced that rightsmanagement is extremely important in order open media marketto blossom in our days. Interoperability can only be achieved, ifthe different rights management systems, open their functional-ities interfaces in such a way that it would be possible for thesedifferent solutions to exchange functions between them, allow-ing the implementation of more horizontal and homogeneousdigital content business models that are more inline with thereal needs of the consumers and the digital content industry va-lue chain.

This work presented an important approach to the rights man-agement interoperability problem, based in the creation of a com-mon interoperability enabler, using a common service-orientedparadigm to provide the necessary abstraction mechanisms to pro-vide transparent interoperability – the iRMBroker.

References

[1] V. Torres, J. Delgado, et al., An implementation of a trusted and secure DRMarchitecture, in: On the Move to Meaningful Internet Systems 2006: OTM 2006

Workshops (IS’06), Lecture Notes in Computer Science, vol. 4277, Springer,Berlin, 2006, pp. 312–321.

[2] V. Torres, E. Rodríguez, et al., Use of standards for implementing a multimediainformation protection and management system, in: Automated Production ofCross Media Content for Multi-Channel Distribution (AXMEDIS 2005), IEEEComputer Society, 2005, pp. 197–204.

[3] V. Torres, C. Serrão, M. Dias, J. Delgado, Open DRM and the future of media,IEEE Multimedia 15 (2) (2008).

[4] ISO/IEC, ISO/IEC, second ed., IS 21000-2 – Digital Item Declaration.[5] C. Serrão, A. Serra, M. Dias, J. Delgado, Secure license management –

management of digital object licenses in a DRM environment, in:Proceedings of the International Conference on Security and Cryptography(SECRYPT2007), Barcelona, Spain, 28–31 July, August, 2007.

[6] C. Serrão, M. Dias, P. Kudumakis, From OPIMA to MPEG IPMP-X – a standard’shistory across R&D projects, in: Special Issue on European Projects in VisualRepresentation Systems and Services, Image Communications, vol. 20, issue 9-10, Elsevier, Amsterdam, 2005, pp. 972–994.

[7] Xin Wang, T. DeMartini, B. Wragg, M. Paramasivam, C. Barlas, The MPEG-21rights expression language and rights data dictionary, IEEE Transactions onMultimedia 7 (3) (2005) 408–417.

[8] Bill Rosenblatt, Bill Trippe, Stephen Mooney, Digital Rights Management:Business and Technology, Wiley, New York, 2001.

[9] Jaime Delgado, Víctor Torres, Silvia Llorente, Eva Rodríguez, Rights and trust inmultimedia information management, in: Communications and MultimediaSecurity, 2005, pp. 55–64.

[10] Richard Gooch, Requirements for DRM systems introduction – therequirement for DRM, in: Digital Rights Management, 2003, pp. 16–25.

[11] Ku, William, Chi-Hung Chi, Survey on the technological aspects of digital rightsmanagement, in: Information Security, 2004, pp. 391–403.

[12] J. Prados, E. Rodriguez, J. Delgado, Interoperability between different rightsexpression languages and protection mechanisms, in: Automated Productionof Cross Media Content for Multi-Channel Distribution, 2005. AXMEDIS 2005,2005.

[13] C. Serrão, V. Torres, J. Delgado, M. Dias, Interoperability mechanisms forregistration and authentication on different open DRM platforms,International Journal of Computer Science and Network Security 6 (12)(2006) 291–303.

[14] C. Serrão, M. Dias, J. Delgado, Using service-oriented architectures towardsrights management interoperability, in: Proceedings of the International JointConferences on computer, Information and Systems Sciences and Engineering(CISSE06), University of Bridgeport, USA, 2006.

[15] H. Bar-El, Y. Weiss, DRM on open platforms may be possible after all, in:Proceedings of the Second IEE (Ref. No. 2004/10660) Secure MobileCommunications Forum: Exploring the Technical Challenges in Secure GSMand WLAN, 2004, 2004, pp. 2/1–2/5.

[16] D. Geer, Digital rights technology sparks interoperability concerns, Computer37 (12) (2004) 20–22.

[17] J. Kim, S. Hwang, K. Yoon, C. Park, MPEG-21 IPMP, in: International Conferenceon Information Technology and Applications (ICITA2002), Bathurst, Australia,2002.

[18] MPEG-21-IPMP, ISO/IEC IS 21000-4 Intellectual Property Management andProtection, International Standard, ISO/IEC JTC 1/SC 29/WG 11, 2006.

[19] MPEG-21-REL, ISO/IEC IS 21000-5 Rights Expression Language, InternationalStandard, ISO/IEC JTC 1/SC 29/WG 11, 2004.

[20] OMA, Digital rights management, Technical specification, Open MobileAlliance, 2006.

[21] OMA, DRM architecture, Technical specification, Open Mobile Alliance, 2006.[22] C. Serrão, M. Dias, J. Delgado, Bringing DRM interoperability to digital content

rendering applications, in: Advances in Computer, Information, and SystemsSciences, and Engineering: Proceedings of the International Conference onTelecommunications and Networking, first ed., Kluwer Academic Publishers,Dordrecht, 2005, pp. 323–329.

[23] A. Kingsley-Hughes, Walmart to pull plug on DRM servers, ZDNet, 2008.Available from: <http://blogs.zdnet.com/hardware/?p=2661>.

[24] M. Kirkpatrick, The Final Days of DRM: Yahoo Music Store Closing, Will EatYour Purchased Music, ReadWriteWeb, 2008. Available from: <http://www.readwriteweb.com/archives/yahoo_music_store_closing.php>.

[25] Marlin web-site. Available from: <http://www.marlin-community.com/>,visited on March 2010.

[26] Marlin Developer Community, Marlin Architecture Overview, Marlin, 2006.[27] Marlin Developer Community, Role of NEMO in Merlin, Marlin, 2006.[28] Marlin Developer Community, Role of Octopus in Marlin, Marlin, 2006.[29] OpenSDRM web-site. Available from: <http://www.opensdrm.org>, as visited

in March 2010.[30] OpenSDRM specifications, OpenSDoRM API Specification, 2007.[31] OpenSDRM source-code. Available from: <http://sourceforge.net/projects/

opensdrm/>, as visited in March 2010.[32] E. Rodriguez, J. Delgado, et al., Report on DRM-based content protection final

integration, VISNET-II Deliverable D314. Available from: <http://www.visnet-noe.org/>, December 2007.

[33] MIPAMS web-site. Available from: <http://dmag.ac.upc.edu/> as visited in March 2010.[34] DRM and content protection technologies reference table. Available from:

<http://www.giantstepsmts.com/DRM%20Reference%20Dec%2009_pdfsalesleads.pdf>, as visited in March 2010.