D-Lib Magazine
June 2001

Volume 7 Number 6

ISSN 1082-9873

Digital Rights Management (DRM) Architectures


Renato Iannella
Chief Scientist
IPR Systems

Red Line


1. Introduction

Digital Rights Management poses one of the greatest challenges for content communities in this digital age. Traditional rights management of physical materials benefited from the materials' physicality as this provided some barrier to unauthorized exploitation of content. However, today we already see serious breaches of copyright law because of the ease with which digital files can be copied and transmitted.

Previously, Digital Rights Management (DRM) focused on security and encryption as a means of solving the issue of unauthorized copying, that is, lock the content and limit its distribution to only those who pay. This was the first-generation of DRM, and it represented a substantial narrowing of the real and broader capabilities of DRM. The second-generation of DRM covers the description, identification, trading, protection, monitoring and tracking of all forms of rights usages over both tangible and intangible assets including management of rights holders relationships. Additionally, it is important to note that DRM is the "digital management of rights" and not the "management of digital rights". That is, DRM manages all rights, not only the rights applicable to permissions over digital content.

In designing and implementing DRM systems, there are two critical architectures to consider. The first is the Functional Architecture, which covers the high-level modules or components of the DRM system that together provide an end-to-end management of rights. The second critical architecture is the Information Architecture, which covers the modeling of the entities within a DRM system as well as their relationships. (There are many other architectural layers that also need to be considered, such as the Conceptual, Module, Execution, and Code layers [HOFMEISTER], but these architectures will not be discussed in this article.)

This article discusses the Functional and Information Architecture domains and provides a summary of the current state of DRM technologies and information architectures.

2. Functional Architecture

The overall DRM framework suited to building digital rights-enabled systems can be modeled in three areas:

  • Intellectual Property (IP) Asset Creation and Capture: How to manage the creation of content so it can be easily traded. This includes asserting rights when content is first created (or reused and extended with appropriate rights to do so) by various content creators/providers.
  • IP Asset Management: How to manage and enable the trade of content. This includes accepting content from creators into an asset management system. The trading systems need to manage the descriptive metadata and rights metadata (e.g., parties, usages, payments, etc.).
  • IP Asset Usage: How to manage the usage of content once it has been traded. This includes supporting constraints over traded content in specific desktop systems/software.

While the above models comprise the broad areas required for DRM, the models need to be complemented by the Functional Architecture that provides the framework for the modules to implement DRM functionality (see Figure 1).


Flowchart of DRM Functional Architecture

Figure 1 - DRM Functional Architecture



The Functional Architecture stipulates the roles and behavior of a number of cooperating and interoperating modules under the three areas of Intellectual Property (IP): Asset Creation, Management, and Usage.

The IP Asset Creation and Capture module supports:

  • Rights Validation - to ensure that content being created from existing content includes the rights to do so.
  • Rights Creation - to allow rights to be assigned to new content, such as specifying the rights owners and allowable usage permissions.
  • Rights Workflow - to allow for content to be processed through a series of workflow steps for review and/or approval of rights (and content).

The IP Asset Management module supports:

  • Repository functions - to enable the access/retrieval of content in potentially distributed databases and the access/retrieval of metadata. The metadata covers Parties, Rights and descriptions of the Works. (See the Information Architecture section of this article for more details.)
  • Trading functions - to enable the assignment of licenses to parties who have traded agreements for rights over content, including payments from licensees to rights holders (e.g., royalty payments). In some cases, the content may need to go through fulfillment operations to satisfy the license agreement. For example, the content may be encrypted/protected or packaged for a particular type of desktop usage environment.

The IP Asset Usage module supports:

  • Permissions Management - to enable the usage environment to honor the rights associated with the content. For example, if the user only has the right to view the document, then printing will not be allowed.
  • Tracking Management - to enable the monitoring of the usage of content where such tracking is part of the agreed to license conditions (e.g., the user has a license to play a video ten times). This module may also need to interoperate with the trading system to track usage or to record transactions if there is payment due for each usage.

Together, these three modules provide the core functionality for DRM systems. The modules have been described only at a high level, and they would also need to operate within other, existing e-business modules (such as shopping carts, consumer personalization, etc.) and Digital Asset Management modules (such as version control, updates, etc.). Additionally, the modules would support interoperability, trust, standard formats, openness and other such principles described in an article by John Erickson in D-Lib Magazine's April 2001 issue [ERICKSON].

Ideally, these modules would be engineered as components to enable systems to be built in a modular fashion. However, this implies a set of common and standard interfaces/protocols between the modules that does not yet exist. As DRM matures, the industry will move towards such standardization. For example, a DRM trading protocol is under development in the OpenEBook Forum's Rights & Rules Working Group for ebook vendors [OEBF].

The Functional Architecture is only part of the solution to the challenges of DRM. Rights Management can become complex remarkably quickly. As a result, DRM systems must support the most flexible information model possible to provide for these complex and layered relationships. The Information Architecture provides this.

3. Information Architecture

The Information Architecture deals with how the entities are modeled in the overall DRM framework and their relationships. The main issues that require addressing in the development of a DRM Information model include:

  • Modeling the entities
  • Identifying and describing the entities, and
  • Expressing the rights statements

3.1 Modeling the entities

It is important to adopt a clear and extensible model for the DRM entities and their relationship with other entities. Existing work in this area includes the <indecs> project [INDECS]. The basic principle of the <indecs> model is to clearly separate and identify the three core entities: Users, Content, and Rights as shown in Figure 2. Users can be any type of user, from a rights holder to an end-consumer. Content is any type of content at any level of aggregation. The Rights entity is an expression of the permissions, constraints, and obligations between the Users and the Content. The primary reason for this model is that it provides the greatest flexibility when assigning rights to any combination or layering of Users and Content. The Core Entities Model also does not constrain Content from being used in new and evolving business models.

Flowchart of DRM Information Architecture

Figure 2 - DRM Information Architecture - Core Entities Model



This model implies that any metadata about the three entities needs to include a mechanism to relate the entities to each other.

The Content itself also needs to be modeled. Again, there has been some existing work in this area from the International Federation of Library Associations [IFLA]. The key principle in the modeling of Content is that Content contains many "layers" from various intellectual stages or evolution of its development. Such a model will enable clearer (i.e., more explicit and/or appropriate) attribution of rights information. For example, the IFLA model allows Content to be identified at the Work, Expression, Manifestation, and Item layers. At each of these layers, different rights and rights holders may need to be supported as shown in Figure 3.


Flowchart of DRM Information Architecture - Content Model

Figure 3 - DRM Information Architecture - Content Model



The layers of the Content defined as Work (a distinct intellectual or artistic creation) and Expression (the intellectual or artistic realization of a work) reflect scholarly or creative content. On the other hand, the other layers of Content, defined as Manifestation (the digital embodiment of an expression of a work) and Item (a single exemplar instantiation of a manifestation), reflect physical or digital form.

As an example, consider "The Name of the Rose". The Work, by Umberto Eco, would be the idea of the events that took place in an isolated Benedictine monastery and include descriptions of the concepts and main ideas, features, or characters. The Expressions of the Work could then include:

  • The original text by Umberto Eco
  • The English translation of the original text
  • The screenplay by Andrew Birkin

The Manifestations of the "English translation" Expression could include:

  • The hardcover book published by Harcourt Brace in 1983
  • The softcover book published by Harvest Books in 1994
  • The digital audio book published by Audio Renaissance in 1995

The Items of the "book" Manifestations could include:

  • A physical hardcover book purchased from Book-A-Zone retail store
  • A digital file purchased from Digital-Word e-book online store

The important point in this style of content modeling is that at any of the points in the IFLA model, different rights holders can be recognized.

Another aspect that may affect rights is when Content is made of many parts. Some of these parts may have different rights associated with them that need to be recognized in the aggregated content.

3.2 Identifying and describing the entities

All entities need to be both identified and described. Identification should be accomplished via open and standard mechanisms for each entity in the model. Both the entities and the metadata records about the entities must be identifiable. Open standards such as Uniform Resource Identifiers [URI] and Digital Object Identifiers [DOI] and the emerging ISO International Standard Textual Work Code [ISTC] are typical schemes useful for Rights identification.

Content should be described using the most appropriate metadata standard for that genre (for example, the EDItEUR ONIX standard [ONIX] for books (physical and electronic) and the IMS Learning Resource Meta-data Information Model [IMS] for educational learning objects). It is also critical that such metadata standards do not themselves try to include metadata elements that attempt to address rights management information, as this will lead to confusion regarding where to describe such rights expressions. For example, the ONIX standard has elements for a number of rights holders (e.g., Authors and Publishers) and Territories for rights and single Price information. (The latter poses a problem in setting multiple prices depending on what rights are traded). In such cases, following the <indecs> model should take precedence.

To describe Users, vCard [VCARD] is the most well-known metadata standard for describing people and (to some extent) organizations. An additional and important part of the Rights model is to articulate the role that the User has undertaken with respect to Content. A comprehensive list of roles can be found in the MARC Relators code list [MARC].

3.3 Expressing rights statements

The Rights entity allows expressions to be made about the allowable permissions, constraints, obligations, and any other rights-related information about Users and Content. Hence, the Rights entity is critical because it represents the expressiveness of the language that will be used to inform the rights metadata.

Rights expressions can become complex quite quickly. Because of that, they are also modeled to understand the relationships within the rights expressions. This has been evidenced in the Open Digital Rights Language [ODRL] and a paper by Carl A. Gunter et al. [GUNTER].

As shown in Figure 4, Rights expressions should consist of:

  • Permissions (i.e., usages) - what you are allowed to do
  • Constraints - restrictions on the permissions
  • Obligations - what you have to do/provide/accept
  • Rights Holders - who is entitled to what


Flowchart of DRM Information Architecture - Rights Expression Model

Figure 4 - DRM Information Architecture - Rights Expression Model



For example, a Rights expression may say that a particular video can by played (i.e., a usage permission) for a maximum of 10 times (i.e., a count constraint) in any semester (i.e., a time constraint) for a $10 fee (i.e., an obligation to pay). Each time the video is played, John, Mary, and Sue (the rights holders) receive a percentage of the fee. Usually, if a right is not explicit in an expression, it means that the right has not been granted. This is a critical assumption made by Rights languages and should be made clear to all Users.

For an example of a rights language, see the Open Digital Rights Language [ODRL]. ODRL lists the many potential terms for permissions, constraints, and obligations as well as the rights holder agreements. As such terms may vary across sectors, rights languages should be modeled to allow the terms to be managed via a Data Dictionary and expressed via the language.

4. Example of DRM Implementation

Second generation DRM software is now providing some of the Architectures described in this article in deployed solutions. A typical example from the E-book sector is the OzAuthors online ebook store [OZAUTHORS]. OzAuthors is a service provided by the Australian Society of Authors in a joint venture with IPR Systems. Their goal is to provide an easy way for Society members (including Authors and Publishers) to provide their content (ebooks) to the market place at low cost and with maximum royalties to content owners.

Figure 5 shows the OzAuthors' interface for the specification of Rights information. In this example, the "Usage Rights and Pricing" allows the content provider to specify “Read” and/or “Print” permissions, pricing, and security options for the ebook. Additionally, a number of pages can be specified as a free preview. The second part of the interface allows the content provider to specify all the rights holders, their roles, and their percentage of the royalty split. Each time the ebook is sold, the rights holders will automatically receive the indicated amount.


Screenshot of OzAuthors - Rights Interface web page

Figure 5 - OzAuthors - Rights Interface


All of this information is encoded in XML using the ODRL rights language. This encoding will enable the exchange of information with other ebook vendors who support the same language semantics, and will set the stage for complete and automatic interoperability.

5. Conclusion

DRM standardization is now occurring in a number of open organizations. The OpenEBook Forum [OEBF] and the MPEG group [MPEG] are leading the charge for the ebook and multimedia sectors. The Internet Engineering Task Force [IETF] has also commenced work on lower level DRM issues, and the World Wide Web Consortium [W3C] held a DRM workshop recently. Their work will be important for the entire DRM sector, and it is also important that all communities be heard during these standardization processes in industry and sector-neutral standards organizations.

Digital Rights Management is emerging as a formidable new challenge, and it is essential for DRM systems to provide interoperable services. Solutions to DRM challenges will enable untold amounts of new content to be made available in safe, open, and trusted environments. Industry and users are now demanding that standards be developed to allow interoperability so as not to force content owners and managers to encode their works in proprietary formats or systems. The Architectures presented in this article are fundamental to that interoperability and openness.


[DOI] Digital Object Identifier

[EBX] Electronic Book Exchange Working Group

[ERICKSON] "Information Objects and Rights Management", John S. Erickson, D-Lib Magazine, April 2001 Volume 7 Number 4

[GUNTER] Models and Languages for Digital Rights, Carl A. Gunter, Stephen T. Weeks, and Andrew Wright. InterTrust Star Lab Technical Report STAR-TR-01-04, March, 2001

[HOFMEISTER] Applied Software Architectures. C Hofmeister, R Nord, & D Soni. Addison-Wesley, 2000.

[IETF] IETF Internet DRM Working Group

[IFLA] Functional Requirements for Bibliographic Records, IFLA Study Group on the Functional Requirements for Bibliographic Records, (Approved September 1997) K . G. Saur München, 1998.

[IMS] IMS Learning Resource Meta-data Information Model (Version 1.1)

[INDECS] Interoperability of data in e-commerce systems

[ISTC] ISO International Standard Textual Work Code

[MARC] MARC Code List for Relators

[MPEG] ISO/IEC Moving Picture Experts Group

[ODRL] Open Digital Rights Language

[OEBF] OpenEBook Forum

[ONIX] EDItEUR ONIX International Standard

[OZAUTHORS] OzAuthors Online Ebook Store

[URI] Uniform Resource Identifiers (URI): Generic Syntax, IETF RFC2396

[VCARD] RFC 2426 vCard Profile

[W3C] Digital Rights Management Workshop

Copyright 2001 Renato Iannella

Top | Contents
Search | Author Index | Title Index | Back Issues
Previous Article | Next Article
Home | E-mail the Editor


D-Lib Magazine Access Terms and Conditions

DOI: 10.1045/june2001-iannella