Leonardo Chiariglione CEDEO.net

In our society, which is increasingly polarized by tense competition, Digital Rights Management (DRM) is seen as either the saviour of businesses trying to survive in the digital age ... or as the scourge of basic human rights. But it should not have to be like that.

This article describes the work of the Digital Media Project (DMP) which is developing an industry-agnostic and scalable DRM standard that can at least reduce the most blatant impositions of DRM. As part of the effort, the DMP is also providing an Open Source Software implementation of the standard that can be exploited to accelerate the deployment of interoperable DRM solutions and to test how Traditional Rights and Usages can be mapped to the digital space for the benefit of end users and entrepreneurs alike.

If I happen to buy a bag of potatoes from a farmer and I use TNT to send it to a customer, TNT will use their set of network-connected computers to manage the delivery of my bag of potatoes to that customer. In other words, TNT will digitally (via computers and networks) manage the rights to my bag of potatoes from the time I hand over the bag to the time when TNT delivers it to my customer. In other words, TNT will digitally manage my rights (to the bag of potatoes), i.e. it will apply DRM. The same argument applies if the Ministry of Finance – for tax purposes – manages some rights to all the real estate properties in a country, by using a huge set of network-connected computers.

For some reason or other, if the bag of potatoes or a piece of land becomes a bunch of digital bits representing a song or a movie, then DRM becomes a major point of contention. Indeed with good reason, because DRM impacts the future of digital content as a business ... and the future of society. But surely this is not a sufficient reason to forfeit rationality. Therefore in this article, the acronym DRM – in spite of it being a source of contention – will be used as originally defined by NIST.

“A system of Information Technology components and services which strives to distribute and control content and its rights”

Of course it should always be kept in mind that DRM operates in an environment driven by law, policies and business models.

DRM may be a point of contention but its use is considered as unavoidable by many. However, an effective use of DRM is only possible if there is common ground where the conflicting interests of many parties are accommodated. Users of a digital media value chain – particularly end users – who have acquired the rights to use a certain piece of content soon discover that there are serious unexpected limitations to what they can or cannot do with the content. They may discover that they have to buy a second copy of the same content – just because ^“it’s another DRM”. The inflexibility and opaqueness of practically-deployed DRM solutions make the users, particularly end users, intolerant of a system that is imposed on them when trying to buy and enjoy their favourite content.

This article addresses DRM from the viewpoint of interoperability and user involvement, through which these and other concerns can be tackled. Many have come to discover the benefits of inter-operability but they forget that standardization has a track record in the area of digital media. Actually, the very success of digital media standardisation is the reason why so many business players see DRM as the means to put the genie back into the bottle.

This article claims that a ^“toolkit” standard for DRM provides the best answer to the challenges of digital media. There is no reason to bring the genie back into the bottle. With DRM interoperability, the genie can very well stay out where it is.

The context of DRM

It is not known what motivated the painters of the Altamira caves to make their paintings and how they wanted other people to treat them, but it is known how Martial, a Latin poet of the 2nd century AD, reacted when he discovered that the person he called ^“plagiarius^” (thief) was telling others that the poet^’s epigrams were his own. It is also known that Ariosto, an Italian poet of the 15^th century, proposed a deal to the Duke of Ferrara of the kind: you fine those who reprint my poems and we share the proceeds.

After those early examples, the law has taken an increasingly important role in setting the rules of how literary works and products should be handled.

• The Queen Anne^’s Act of 1710 [1] “An Act for the Encouragement of Learning, by vesting the Copies of Printed Books in the Authors or purchasers of such Copies, during the Times therein mentioned" provides the foundation of copyright law in the UK.

• The Constitution of the USA empowers the United States Congress: “To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries”.

• The countries of the Union constituted by the Berne Convention for the Protection of Literary and Artistic Works [2] “being equally animated by the desire to protect, in as effective and uniform a manner as possible, the rights of authors in their literary and artistic works^“, agree to mutually protect the rights of literary and artistic works of authors of other countries.

• The signatories to the WIPO Copyright Treaty recognize ^“the profound impact of the develop­ment and convergence of information and communication technologies on the creation and use of literary and artistic works”,

It is an established fact that those who create artistic and literary works have always looked for means to ^“manage^” them through their life cycle and that laws in most countries have been enacted to make explicit the rights of authors and other intermediaries looking after the distribution of their works.

Abbreviations

 

 

The need for DRM

The adoption of Information and Communication Technologies (ICT) in Business to Business (B2B) environments, to manage the life cycle of content rights, dates back several decades. For instance most Collective Management Societies have been managing the rights to hundreds of thousands of works using mainframes. However, the most significant challenges are created by the use of digital technologies for actual distribution to the end user.

Compact Disc (CD) and Digital Versatile Disc (DVD) provide an almost endless supply of audio and video content in digital form. Music tracks on a CD contain clear-text digital samples, while movies on a DVD are compressed and encrypted. However, it has become easy to decrypt, decompress and re-compress the files using less bit-hungry (standard) algorithms. The same can be done with digital or even analogue TV broadcasts. The latter can be easily turned into digital form and then digitally compressed for distribution.

The internet has shown how it is possible to create new value chains that implement completely new business models. Many of them – the most ^“successful^” – rely on the almost limitless availability of content from the sources mentioned above. On the one hand this is a source of concern to those who hold rights to such content, on the other it also shows that new opportunities exist aplenty, provided it is possible to rely on tools which “keep track” of a piece of content that has been released.

There are several examples of deployment of DRM systems. However, ten years after MP3 first came to the fore, none of these rewards the rights holders in any significant way. There is also no shortage of ^“standards^” for DRM. However, none of these has encountered much success so far. As a result, several legislatures are grappling in a haphazard way with the issue of coexistence between legally-based technology-enforced limitations of some forms of DRM and established user rights.

The deployment examples that exist today on the web are based on technologies that are marginal evolutions of Conditional Access (CA) systems that have been used for decades in pay-TV services, while DRM is a technology that is, at the same time, much more and yet much less than CA. DRM is more than CA because it is meant to cover the entire value chain handling digital assets, while CA typically addresses just the last portion of the value chain (e.g. retailer-end user). DRM is also less than CA because users of a value chain may very well need just management of their digital assets and not protection. An example of the latter, although typically achieved using human-readable licences (hence not digitally), is Creative Commons [3].

The main reason for this lack of progress is the sheer complexity of the issue and its implications for the future. On the one hand, the unilateral adoption of restriction technologies by a business entity risks alienating a large share of the very users the entity is meant to attract and serve. On the other hand, the interoperability approach of standard developers alienates the business users for which the standard is meant. Add the fact that DRM affects all users with their different agendas at the same time, making it impossible to “factorise” the problem and solve it in small bits at a time.

What DRM and how?

If there are DRM standards and they have not succeeded, is there a lesson to learn? The answer is yes and the path to follow is the one trodden by the Digital Media Project (DMP) [4], a not-for-profit organization established in Geneva in December 2003 with the mission to promote continuing successful development, deployment and use of digital media that:

- respect the rights of creators and rights holders to exploit their works;
- the wish of end users to fully enjoy the benefits of digital media, and
- the interests of various value-chain players to provide products and services

... all according to the principles laid down in the Digital Media Manifesto [5].

The Digital Media Manifesto was a grass-roots movement started in July 2003. The Manifesto, published in September 2003 [5], identifies the ^“digital media stalemate” caused by the clash between the possibilities offered by digital technologies and the existing user-unfriendly restrictions on content. The Manifesto identifies a number of actions to overcome the stalemate, some at the policy and some at the technology level. The most important action at the technology level is the development of a ^“DRM standard^” that would enable the creation of horizontal markets with a lower cost of the DRM technology and an easier access to value chains than proprietary DRM solutions could ever hope to achieve, assuming that they ever had in mind to make that possible.

DMP takes a holistic view of DRM as a technology that shall be:

1. Applicable to all types of value chains;

2. Usable at all points of a value chain;

3. Capable of supporting all functions performed in value chains from management to protection;

4. Open to support new functionalities required at a later time.

DMP is obviously aware that the scope of such a type of standardization makes it difficult if not impossible to provide a ^“one size fits all” standard. Therefore from early on, DMP has worked on identifying DRM “Primitive Functions” i.e. low-level functions that are found recurrently in Functions performed at different points of value chains, and the requirements such Primitive Functions should satisfy. The collection of Primitive Functions and corresponding requirements is contained in Approved Document (AD) #1: ^“Value Chain Functions and Requirements” [6]. This is an informative document in the sense that it is not needed by an implementer of the standard.

DMP intends to define, as a first step, standards for Primitive Functions considered as basic technologies and, as a second step, to assemble appropriate basic technologies representing Primitive Functions to realise fully-fledged Functions. This procedure is not new to standards targeted at similar unstructured uses and the standards enabling the building of such customised solutions are called ^“toolkit standards”.

AD #2: ^“Architecture” [7], also an informative document, describes in general terms how a value chain, as the one depicted in Fig. 1, can be built using the different technologies corresponding to Primitive Functions.

AD #2 also provides general models for:

1. Functions of: Creation; Distribution; Delivery; Import/Export (i.e. moving content in/out of the DMP environment).

2. DRM Tools (i.e. executable code implementing a DRM functionality)

3. Devices (i.e. any device used at any point of a value chain)

4. Domains (i.e. groupings of Devices)

5. Data (i.e. all data types that are needed by Primitive Functions).

Figure 1 -An example value chain

AD #3: ^“Interoperable DRM Platform” [8] is the complete collection of all technologies corresponding to Primitive Functions organised as:

1. Content (i.e. an XML structure of Content Elements);

2. Content Elements that encompass a large variety of data types such as Resources, Metadata, Licences, DRM Tools etc.;

3. Protocols that enable  to communicate (e.g. for a Device to get a Licence from a Licence Provider Device) and to manage Domains (e.g. create a Domain, add  Device etc.);

4. Payloads of those Protocols;

5. Package Content (i.e. the wrapping of Content for the purpose of delivery from a Device to another Device as a file or as a stream).

A toolkit standard is very powerful but has the obvious shortcoming that a designer of a value chain is on his own when he wants to use the standard. The next document provides a solution to this problem.

AD #4: ^“Use Cases and Value Chains” [9] provides a number of Use Cases showing how the Tools standardised in AD #3 can be used to build Value-Chains implementing them. The Value-Chains are normative in the sense that, by implementing the value chains as provided by AD #4, it is possible to interoperate with other implementations that assemble the technologies in a similar way.

In general, Devices have to be certified before they can be allowed to operate on a value chain. As an example, certification constitutes a key assurance for a rights holder to entrust his Content to a Device. In DMP, certification is carried out by a plurality of organisations dedicated to the task of certifying  and other entities. To perform this task, these organisations must be properly accredited by a root authority called Certification Authority.

AD #5: ^“Certification and Registration Authorities” [10] describes the process according to which DMP appoints a Certification Authority and oversees its operation and provides the following elements:

1. Qualification Requirements for a Certification Authority;

2. Procedure to appoint a Certification Authority;

3. Responsibilities of a Certification Authority;

4. Responsibilities of Certification Agencies.

The identification of (i.e. the provisioning of unique numbers to) Content, Devices and Domains is critical. In the case of Devices identification constitutes a key element for trust establishment. The identification task is typically carried out by several organizations that are properly accredited by a root authority. While the operational details of Certification and Registration Authorities/Agencies are different, the process followed in appointing and overseeing them is very similar. DMP appoints the Certification Authority after approving the Authority^’s Certification policies. Fig. 2 depicts this three-layer arrangement. 

Figure 2 - Authorities appoint Agencies that certify Entities

Lastly, AD #6: “Terminology” [11] provides a set of terms and corresponding definitions that are used throughout all ADs.

Implementing DRM

It is one thing to write specification and quite another to implement them and since its early days DMP has decided that its specifications would also be written in a computer language, now called Chillout®, and released as Open Source Software (OSS), under the Mozilla Public Licence V.1.1 [12].

With its specifications implemented as OSS, DMP expects that a vast community of users and developers will be formed around a DRM software that is openly accessible, satisfies disparate user requirements, is robust and capable to evolve. Moreover, the fact that the code can be inspected by anyone should convince those who have been brainwashed by various no-DRM initiatives in the last few years that a standard DRM - an open technology to manage and protect content - is no evil; instead it provides an answer to quite natural user demands, can improve media life and enable a fair exploitation of digital media.

A digital media value chain is a network of business players (called users) who perform functions on the media flowing through it using  to perform the functions on the digital media. Fig. 3 exemplifies a rather general case of a value chain. In the figure:

• Devices with a yellow colour provide identifiers to  or Content;

• The Device with a blue colour is used to make Content;

• Devices with a green colour provide the respective Content Elements;

• Devices with a red colour are End-User ;

• The Device with a brown colour manages Domains;

• The device with a purple colour is a non-DMP device.

The numbers on the diagram indicate the different Protocols required for  to communicate.

Figure 3 - Some typical  in a value chain

Like other Open Source Software projects, Chillout is written in Java. The reasons for choosing Java is that it is an outstanding language, with excellent cross-platform capabilities that is supported by many international companies operating in various fields. On the other hand, any other programming language could be chosen instead of Java and, actually, more initiatives aiming to develop parallel implementa­tions of Chillout in other languages such as .NET are about to start.

Chillout is structured in four layers, as shown in Fig. 4.

Figure 4 Chillout software layers

 The high level description of each layer follows:

• The Java Platform Layer provides the Java running environment on which Chillout  depend on. It comprises the Java Development Kit (JDK) plus a number of add-ons provided by third parties, such as the Apache Tomcat servlet container [13] to power web applications, the Apache Axis [14] SOAP implementation which provides web-service capability, the EJBCA [15] which provides a Certificate Authority for authentication and authorization, and the Java Media Framework [16] for rendering media resources, etc.

• The Core library of classes implements the Primitive Functions. This software is normative as it is the computer language version of the textual specification and the two are meant to be tech­nically aligned.

• The Auxiliary library of classes encapsulates the functionalities that every device must have when operating in a real environment.

• The Applications: a set of sample applications with the purpose of showing how to use the Core and Auxiliary libraries. This includes a number of , such as an end user Device, a Content Creation Device, a License Provider Device, a Content Provider Device, etc.

The separation of Chillout software in layers allows any user wishing to set up or become part of a media Value Chain to replace any Auxiliary module with his own proprietary ones, without the need of modifying the core library, if he wishes to do so. In the future, thanks to the power of Open Source Software, it is expected that a plethora of ^“product level” Auxiliary modules could be part of the larger Chillout ecosystem.

AD #7: ^“Reference Software” [17] is the document containing the reference software.

All open standards managed by a community need an open and fair regime so that a provider of  can have an implementation tested for conformance. In the case of a DRM environment, having a device successfully tested for conformance is the first step before the device can be certi­fied.

Chillout is providing the tools to be included in AD #8: “End-to-End Conformance” [18], using which, it will be possible to carry out conformance testing for Content and Content Elements, Protocols and Package Tools and Devices.

What DRM can do?

One way to look at interoperable DRM is with the eyes of an incumbent who thinks that some of the old ways of doing business with media can be replicated in the digital space with DRM. A more promising way, however, to look at the technology is with the eyes of somebody who wants to support the rich set of experiences that users of media have collected in what DMP has called ^“Traditional Rights and Usages” (TRU), i.e. the set of rights, exceptions and customs that developed in the history of media and are an integral part of the media users' experience. DMP calls this effort ^“mapping of TRUs to the digital space^” although, already in the analogue space, the status of TRUs was not always clear and therefore much less can be expected in the digital space. Yet another – more business oriented – way of putting interoperable DRM to good use is to try and exploit TRUs to make Digital Media Business Models (DMBMs) whose attractiveness has already been put to the test, in some form or other, in the analogue world.

All these different ways to look at interoperable DRM play a vital role in the ultimate acceptance of DRM. Unless a positive action is made to inject dynamism into a system, we may easily find out that the only DMBMs offered to users are stereotypes of business models that were already worn out in the analogue space. Indeed, all DRM systems (including a standard one) are unbalanced in favour of rights holders and can easily lead to stagnation, because rights holders tend to behave conservatively. The ultimate result can very well be outright rejection by the end users.

Since its earliest days, the DMP engaged in a thorough analysis of a large number of TRUs. The result of this analysis is contained in [19] where 88 TRUs are analysed in detail. Currently DMP is developing a document called “Mapping of TRUs to the digital space” that is expected to become AD #9 [20]. The document is actually split in two parts. One part deals with TRUs in a way that can easily be supported as a continuation of TRUs in the digital space. The second part collects together examples of DMBMs, mostly derived from TRUs, that are considered to have a merit per se as DMBMs and not because their origins can be traced back to TRUs (and claims then be made that there are some legal grounds for mapping them to the digital space).

The table below provides a list of some TRUs identified by DMP, with a short description:

One way to support the ^“TRU to Quote^” (as defined above) is exemplified by the following use case:

Tim wants to show 10 seconds from time code 1h 15m 25s of “My best quote of the year”, a movie that is only available as protected Content. Tim could perform the following sequence of steps:

Note that the mechanism through which Tim obtains a licence can be manyfold: buying it as a gift to a friend, getting it for free as part of a subscription, being paid for it as part of a promotional campaign, mandated by law as ^“Right to quote^” ...

Using Chillout®, it is possible to set up (a portion of) a value chain corresponding to this particular TRU and experiment with it. Typically this would require:

• A Content Provider Device (for movie content);

• A Licence Provider Device capable of negotiating, making, providing and, depending on the type of release, accepting licences from Tim;

• A device to negotiate the licence and make the DCI;

• Possibly other  depending on the type of release that is envisaged.

While there is ground to claim that a ^“TRU to quote^” only exists for some types of media, usages and countries, for other TRUs there is less ambiguity. However, the set-up described above – built using Chillout® – can very easily be expanded to cover DMBSs that would be applicable to, say, user-generated content where the creator wants to retain a higher degree of control than is possible today with most websites handling such types of video content.

Beyond DRM

The importance of DRM has further grown in the last few months. The draft version of a French law – that forced the opening of proprietary DRMs in order to overcome probably the most unpopular aspect of DRM – made headlines. No matter what were the good intentions of those who proposed this formulation of the law, it is clear that forcing the opening of a successful DRM system looks a lot like a sure way to discourage entrepreneurs from trying to establish a successful business.

In Italy, a grass-roots initiative called Digital Media in Italia (dmin.it) [21] has taken a different approach in its proposal aimed at ^“maximizing the flow of digital media^” [22]. The document proposes to act on (a) content offer modalities, (b) broadband network access and (c) on-line payment systems. It does so by seeking to harmonise two often contrasting requirements: the entrepreneur’s freedom of action and the consumer’s freedom to access content, not necessarily for free, with the device of his choice.

The first prong of the proposal ^“content offer modalities^” is centred on an interoperable Digital Rights Management (iDRM) specification adopted at national level. The specification is publicly available, implemented in OSS and not prescriptive of particular business models. In other words it supports innovative business models by enabling all legitimate intermediation roles, including the simple use of management, as opposed to protection, techniques. A service provider employing a proprietary technology to offer content, for which it has rights for a given distribution platform, must also offer them on the same platform using the iDRM technology under conditions that are non-discriminatory if compared with its proprietary offer so that a consumer can access it using a device that is available on the open market.

The second prong of the proposal ^“broadband network access^” acknowledges the current trend of broadband telecommunications operators to offer bundled and/or unbundled access services to their networks, choosing the technical characteristics that suit the operator^’s needs. However, a subscriber to the network – a content/service provider, an intermediary or an end-user – has the right to request and obtain from the operator a ^“service-agnostic” access to the ^“Big Internet” with technical characteristics that are already offered by the operator at conditions that are non-discriminatory if compared with other offers of the operator. On their side, operators have to guarantee network service interoperability by agreeing between them and supplying specific quality of service (QoS) levels at peering points so as to offer network users appropriate QoS levels.

The third prong ^“on-line payment systems” establishes that an operator who offers virtual account services (points, credits etc.) should also offer services for transactions connected with digital media. These must be interoperable – based on a nationally-defined specification – with services offered by other virtual account operators. Transactions are effected between virtual accounts where each account is supported by one or more payment mechanisms, e.g. bank account, credit card, prepaid card, electronic purse etc. To reduce transaction costs, synchronisation of a virtual account with its supporting monetary instrument is not performed at each transaction but on a periodic basis, or on demand.

Conclusions

Society, in spite of the investments made to make digital technologies, has been largely caught unprepared to handle the necessary adaptations required by digital media. The result has been the stalemate identified by the Digital Media Manifesto where rights holders are robbed of their properties, end users cannot safely enjoy digital media and intermediaries have a hard time finding the business opportunities they look for because of too many uncertainties.

The protection variety of DRM has so far been an elusive mermaid. The implementations made provide benefits in very few cases and generally leave many unhappy, particularly the end users – who should have a bigger say, as they foot the bill of the entire value chain. The Digital Media Project has provided an industry agnostic and scalable DRM standard that can at least reduce the most blatant impositions of DRM, such as forcing an end user to buy the same content twice if this is to be used on two different  and, for intermediaries, the ability to easily set up arbitrary value chains. It is also providing an Open Source Software implementation of the standard that can be exploited to accelerate the deployment of interoperable DRM solutions and to test how Traditional Rights and Usages can be mapped to the digital space for the benefit of end users and entrepre­neurs alike. Digital Media in Italia is moving the notion of interoperable DRM one step further by integrating it with two more enabling technologies: broadband network access and payment systems and considering the changes required in the Italian legislation.

References

[1]      The Queen Anne’s Act of 1710: http://www.copyrighthistory.com/anne.html

[2]      Berne Convention for the Protection of Literary and Artistic Works: http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html

[3]      Creative Commons: http://creativecommons.org/

[4]      The Digital Media Project: http://www.dmpf.org/

[5]      The Digital Media Manifesto: http://www.chiariglione.org/manifesto/dmm.htm

[6]      DMP Approved Document No. 1 – Technical Reference: Value-Chain Functions and Require­ments, Version 2.1: http://www.dmpf.org/open/dmp0911.zip

[7]      DMP Approved Document No. 2 – Technical Reference: Architecture, Version 2.1: http://www.dmpf.org/open/dmp0912.zip

[8]      DMP Approved Document No. 3 – Technical Specification: Interoperable DRM Platform, Version 2.1: http://www. dmpf.org/open/dmp0913.zip

[9]      DMP Approved Document No. 4 – Technical Specification: Use Cases and Value Chains, Version 2.1: http://www.dmpf.org/open/dmp0914.zip

[10]  DMP Approved Document No. 5 – Technical Specification: Certification and Registration Authorities, Version 2.1: http://www.dmpf.org/open/dmp0915.zip

[11]  DMP Approved Document No. 6 – Technical Reference: Terminology, Version 2.1: http://www.dm pf.org/open/dmp0916.zip

[12]  Mozilla Public License Version 1.1: http://www.mozilla.org/MPL/MPL-1.1.html

[13]  The Apache Software Foundation, Apache Tomcat: http://tomcat.apache.org/

[14]  The Apache Software Foundation, Apache Web Services Project Axis: http://ws.apache.org/axis/

[15]  The J2EE Certificate Authority: http://ejbca.sourceforge.net/

[16]  Java Media Framework API: http://java.sun.com/products/java-media/jmf/

[17]  DMP Approved Document No. 7, WD 7.0 – Technical Specification: Reference Software: http://www.dm pf.org/open/dmp0917.zip

[18]  DMP Approved Document No. 8, WD 4.0 – Recommended Practice: End-to-End Conformance: http://www.dm pf.org/open/dmp0918.zip

[19]  Collection of TRU templates: http://www.dmpf.org/open/dmp0270.zip

[20]  DMP Approved Document No. 9, WD 4.0 – Recommended Action: Mapping of Traditional Rights and Usages to the Digital Space: http://www.dmpf.org/open/dmp0919.zip

[21]  Digital Media in Italia: http://www.dmin.it/

[22]  Digital Media in Italia, Proposal for intervention aimed at giving Italy a leading position in the ^“digital media^” sector: http://www.dmin.it/proposta/proposta-en.htm