A walkthrough in the Interoperable DRM Platform v. 3.0 specification
Leonardo Chiariglione


Executive Summary

This document provides an overview of the DMP and of the Interoperable DRM Platform, v. 3.0 (IDP-3) Technical Specification developed by the Digital Media Project (DMP).

Table of Contents

  Executive Summary
  Table of Contents
1. Introduction
2. The Need for a DRM Standard
3. Value Chain Functions and Requirements
4. Architecture
4.1 Value Chain
4.2 Walkthrough
4.3 Models
4.3.1 Creation Model
4.3.2 Distribution Model
4.3.3 Delivery Model
4.3.4 Device Model
4.3.5 DRM Tool Model
4.3.6 Domain Model
4.3.7 Import/Export Model
4.3.8 Data Model
5. Interoperable DRM Platform
5.1 Represent
5.1.1 Represent Content
5.1.2 Represent Metadata
5.1.3 Represent DCI Signature
5.1.4 Represent DCI Hash
5.1.5 Represent Identifier
5.1.6 Represent Resource
5.1.7 Represent DRM Information
5.1.8 Represent DRM Tool
5.1.9 Represent DRM Tool Body
5.1.10 Represent Rights Expressions
5.1.11 Represent Rights Data
5.1.12 Represent Keys
5.1.13 Represent DRM Messages
5.1.14 Represent Authentication Messages
5.1.15 Represent Device Information
5.1.16 Represent Domain
5.1.17 Represent Domain Protocol
5.1.18 Represent Use Data
5.1.19 Represent Binary XML
5.1.20 Represent Event Report
5.2 Protocols
5.2.1 Protocols to Identify Entities
5.2.2 Protocols to  Authenticate Entities
5.2.3 Protocols to Manage Domains
5.2.4 Protocols to Manage DRM Tools
5.2.5 Protocols to Access
5.3 Package
5.3.1 Package Content as File
5.3.2 Package Content as Stream
6. Use Cases and Value-Chains 
6.1 Open Release
6.2 Open Search
6.3 Home Distribution #1
6.4 Home Distribution #2
6.5 Internet Distribution
6.6 Controlled Peer-to-Peer Distribution
6.7 Smart Retailer
6.8 Personal Photography
6.9 Open Broadcast
6.10 Open Governed Broadcast
6.11 Smart Broadcaster
6.12 Open Governed Interactive Content
7. Registration Authorities
8. Terminology
9. Reference Software
10. End-to-End Conformance
11. Mapping of Traditional Rights and Usages to the Digital Space
11.1 Use Case #1 – Quote TRU
11.1.1 Rationale
11.1.2 Solution case #1
11.1.3 Walkthrough
11.1.4 Recommended actions
12. The next steps
13. Conclusions
14. References

1. Introduction

The Digital Media Project (DMP) is a non-profit Association registered in Geneva, Switzerland. In accordance to its founding principles, DMP promotes the development, deployment, and use of digital media that safeguard

  1. the rights of creators to exploit their works
  2. the wish of consumers to fully maximise the benefits of digital media and
  3. the commercial interests of value-chain players to provide products and services to the end-points of the value chain and to other value-chain users.
The principal means to realise the DMP goals is through the development and publication of Technical Specifications and to contribute them to formal standards organisations.

DMP has taken both seriously. IDP-3.0 is 650 pages and the size of the Chillout reference software is several tens of Megabytes. Most of IDP-3.0 has become an ISO standard as a result of the approval of ISO/IEC 23000-5 Media Streaming Application Format.

Purpose of this paper is to illustrate the goals of the DMP (chapter 2), the main features of the Interoperable DRM Platform v. 3.0 Technical Specification (IDP-3) developed by DMP in furtherance of the stated goals (chapters 3 to 11) and some future DMP activities (chapter 12).

2. The Need for a DRM Standard

Media content has always played an important role in all societies and manifold technologies have been invented and deployed to provide means to store, distribute and consume it. The complexity of these technologies and the drive to enhance their performance have created very complex media content value-chains populated by an ever-growing number of interacting intermediaries, each providing increasingly sophisticated services to the two extremes of the value-chains – creators and end users – as well as to the various intermediaries in between. DMP calls all players in the value chain – creators, intermediaries and end-users – value-chain users or, simply, users.

The latest round of technologies – the digital technologies – have more than ever increased the distribution potential and augmented the end-user experience of media content. However, they have also caused a progressive and unstoppable loss of purpose of the traditional means to manage the value of media content along the value-chains.

Digital Rights Management (DRM) has been advocated by many as the set of technologies that can overcome these difficulties because users are given the possibility to manage media content while it moves along value-chains. DMP agrees that DRM has the potential to combine the benefit of digital technologies with the need for a virtuous circle that motivates creators to continue creating because remuneration is facilitated by DRM technologies. However, as long as DRM systems are implemented as closed and non-interoperable solutions, end users and value-chain users who are prevented from accessing the DRM solutions will feel disenfranchised and object.

Therefore DMP only supports DRM technologies that are interoperable.

Standards can bring benefits to the very special type of communication systems called DRM. However, with the changes forced by digital technologies in the way value-chain users conduct their business, it is hard to define what kinds of standards are required today, let alone to forecast what kind of standards will be needed in the future.

DMP approaches the problem of DRM Interoperability by specifying DRM technologies (called Tools) required to implement “Primitive Functions”, i.e. “smaller” Functions obtained by breaking down the Functions Value-Chain Users perform when they do business between themselves. It is expected that, while Functions may undergo substantial changes as a consequence of the evolution of the media business, Primitive Functions will generally remain stable. Note that words in upper case have the meaning defined in chapter 8 (extracted from IDP-3), unless another meaning is explicitly declared.

Therefore, far from targeting a universal “DRM standard” capable of providing Interoperability between Users in arbitrary Value-Chains or across different Value-Chains, DMP only provides

  1. Specifications of Tools enabling Primitive Functions
  2. Examples of how Value-Chains serving specific goals can be set up using the standard Tools.

As the field of DRM is quite broad, specifications can only be developed in phases, each phase building on the results of the previous phases. DMP has adopted the following rigorous process:

  1. Identify and document Use Cases deemed to be significant;
  2. Identify Primitive Functions employed by the Use Cases;
  3. Develop requirements for Primitive Functions through inputs from relevant Users;
  4. Issue calls for proposals for Tools with the agreed requirements;
  5. Standardise Tools by selecting and documenting the best Tools proposed. DMP favours Tools that have already been developed, standardised or adopted by other bodies, possibly adapting them to DMP needs;
  6. Develop Technical Specifications of how Tools can be assembled to implement the selected Use Cases;
  7. Document how Tools can be used in the selected Use Cases

In subsequent phases, repeat the above for Tools needed to support

  1. New Primitive Functions
  2. Additional functionalities of existing Tools.

DMP calls the ensemble of all standardised DRM Tools “Interoperable DRM Platform (IDP)”. Therefore the IDP is not a proper DRM System standard. Far from being a disadvantage, the IDP provides the following major advantages:

  1. The IDP is industry agnostic;
  2. Users are free to build the Value-Chains that suit their own business models by selecting the Tools most appropriate for them;
  3. The capabilities of a Value-Chain or new Value-Chains can be extended by adding more Tools, possibly through additional standardisation;
  4. Access to standard Tools may have reduced cost because in general Tools have multiple usages and may be provided by multiple suppliers;
  5. Full Interoperability can be achieved within a Value-Chain;
  6. An enhanced degree of Interoperability can be achieved between different Value-Chains;
  7. Innovation can be continuously fed back into the system.

DMP has produced the following Approved Documents (AD):

  1. AD #1 – Value Chain Functions and Requirements [1]: a collection of Primitive Functions derived from today’s media value-chains with corresponding Requirements.
  2. AD #2 - Architecture [2]: a general architecture that represents the digital extension of today’s media value-chains and collects the basic assumptions and technologies underlying the establishment of IDP-enabled Value-Chains.
  3. AD #3 – Interoperable DRM Platform [3]: a collection of technical specification of basic Tools that are needed to implement Primitive Functions.
  4. AD #4 – Use Cases and Value Chains [4]: a collection of all Use Cases that are supported by Tools available along with normative specification of examples of Value-Chains or of portions thereof implementing the Use Cases using the Tools drawn from the IDP Toolkit.
  5. AD #5 – Certification and Registration Authorities [5]: a set of operational rules for Certification Authorities established to Certify Devices and DRM Tools, and Registration Authorities established to Assign Identifiers to Content, DRM Tools, Devices, Users and Domains.
  6. AD #6 – Terminology [6]: a set of terms and corresponding definitions that are used throughout DMP ADs.
  7. AD #7 – Reference Software [7]: a software implementation of IDP Tools distributed, whenever possible, under the Mozilla Public Licence.
  8. AD #8 – End-to-End Conformance [8]: a set of Recommended Practices that Value-Chain Users can reference to ascertain that the Tools employed by other parties conform to DMP Technical Specifications and Technical References.
  9. AD #9 – Mapping of Traditional Rights and Usages to the Digital Space [9]: a set of examples supporting TRUs using DMP Tools possibly complemented by recommendations to appropriate authorities to enable the benefit of TRUs in a DMP-enabled world of digital media.
This is the IDP publication record

The IDP-1, IDP-2 and IDP-3 specifications are tightly linked in the sense that the IDP-3 specification contains  (i.e. is a superset of) the IDP-2 specification which contains the IDP-1 specification.

3. Value Chain Functions and Requirements

These are contained in AD #1. In general a Value-Chain is made up of a number of Value-Chain Users exchanging various information types using Devices. Note that, even though the term "Value-Chain" seems to imply a linear or sequential relationship, even in simple Value-Chains this is hardly the case. Therefore the elements of a Value-Chain are
  1. Devices
  2. Data
  3. Device-to-Device Protocols
  4. Data Delivery Protocols (called Package by DMP)

AD #1 documents the requirements upon which the Interoperable DRM specification has been developed. To achieve this, the following process – open to any party – has been invoked:

  1. Ask a broad range of value-chain users to state their needs
  2. Derive Functions from the stated needs
  3. Develop requirements for implementing Functions
  4. Identify prominent use cases used to focus the development of specifications
  5. Issue Call for Proposals for technologies to implement Functions.

All documents produced at each of these steps have been made publicly available for comments on the DMP web site.

Representatives of the following value-chain users have contributed to the process:

  1. Civil Rights Associations
  2. Association of People with Special Needs
  3. Collective Management Societies
  4. Device Manufacturers
  5. Individuals
  6. Producers
  7. Public Service Broadcasters
  8. Sheet Music Publishers
  9. Telecommunication operators
  10. Internet Service Providers.
More specifically AD #1 provides requirements organised along the following categories of Functions
  1. Represent Information
    1. Identifier
    2. Content
    3. Resource
    4. Metadata
    5. DRM Information
    6. DRM Tool Body
    7. DRM Tool
    8. Rights Expression
    9. Rights Data
    10. Key Body
    11. Key
    12. Device Information
    13. Domain Information
    14. Use Data
    15. Resource Format
    16. Binarised XML
  2. Protocols
    1. Assign
    2. Revoke
    3. Authenticate
    4. Verify
    5. Deliver
    6. Manage
    7. Pay
  3. Package
Additionally requirements are provided for the following categories
  1. Process
  2. Test Conformance
  3. Certify
The last two entries relate to the need to test Content and Devices for Conformance, and Certification.

4. Architecture

This is contained in AD #2. The Architecture provides an overview of the operation of a Value-Chain and of the technologies that enable it.

4.1 Value-Chain

A typical Value-Chain (Fig. 1) has the following main components:
  1. Creation (including Adaptation)
  2. Instantiation
  3. Production
  4. Content Provisioning
  5. Service Provisioning
  6. Consumption

Fig. 1 - General schematic case of a Value-Chain

Value-Chains handle objects that represent IP Entities with Intellectual Property (IP) associated to them. In the Figure dotted arrows mean that the output of a User can be Used by the same type of User to make objects representing the same type of IP Entity.

4.2 Walkthrough

For proper management in a Value-Chain it is useful to combine different types of Resources with different types of Metadata and possibly other information types. DMP calls this combination Content. The digital Representation of Content, needed to Use Content on Devices, is called DMP Content Information (DCI).

A User wishing to express conditions to Use a Content Item can associate a Licence to it Granting Permissions under specified Conditions. In this case the Content is called Governed Content. The party Granting Permissions is referred to as Licensor and the party receiving them is referred to as Licensee. A User who does not wish to express Conditions to Use a Content Item can do so by Releasing it without a Licence.

To enable a Device to interpret Permissions without human intervention, a machine readable language called Rights Expression Language (REL) is needed. The Licensee can be a Device, a User or a Domain and the Licence can be Bundled within the Content (i.e. it is part of the DCI) or not Bundled within the Content (i.e. the DCI references an external License). Other Content Elements (e.g. Resources) can be in-line or referenced.

The Content Elements in Governed Content can either be in a form that allows immediate Processing, e.g. for Rendering by a Device (so-called Clear-text) or in a protected (i.e. Encrypted) form. Keys and related DRM information can be conveyed by various means.

When the Device has limited capabilities (as in PAVs) it is useful to be able to make reference to a basic selection of Encryption Tools. However, when the Device does not have such restrictions (as in SAVs) it is important to be able to convey blocks of executable code (called DRM Tools) in a DCI that are required to Process various types of Governed Content.

XML is the technology selected by DMP to Represent Content. XML is very powerful and flexible but Content Represented by means of XML can easily become bulky and unwieldy. Therefore DMP has selected an XML binarisation technology that not only reduces the size of a DCI but also allows simpler Processing in a Device without loss of information.

To Deliver Content between Device Entities it is necessary to Package a DCI (in binary form) and its referenced Resources. Two forms of Delivery are possible: as File (DMP Content File - DCF) and as Stream (DMP Content Broadcast - DCB - in the case of an MPEG-2 Transport Stream, and DMP Content Streaming - DCS - in the case of Real Time Protocol on Internet Protocol).

In general Users require Devices to perform the Functions proper to their role in the Value-Chain. To entrust their Content to a Device, Rights Holders must have assurance that the Device will execute Functions as expected. Device Certification is the process that provides that assurance. This is performed by a number of organisations (Certification Agencies) that are appointed and overseen by a single root authority (Certification Authority) according to a process specified by IDP-3. DMP appoints the Certification Authority after approving the Authority’s Certification policies. The figure below depicts this three-layer arrangement.

Figure 2 – Authorities appoint Agencies that Certify Entities

In general interacting Devices require the establishment of a Trust relationship between them, e.g. when they Deliver Content between them. A precondition for this to be possible is that a Device be Identified. The task of Assigning Identifiers to Devices is performed by a number of organisations (Registration Agencies) that are appointed and overseen by a single root authority (Registration Authority). DMP appoints the Registration Authority after approving the Authority’s Registration policies. The same three-layer arrangement used for Certification is also used for Identification.

Content Items also require Identification. This are Assigned by Agencies appointed according to a process specified by PDP-3. When Identifiers are Assigned appropriate Metadata are also typically generated.

4.3 Models

IDP-3 provides the following models

  1. Creation Model identifying the major entities for which IP is attributed and describing their relationship to the digital objects involved in Content Creation;
  2. Distribution Model identifying and describing the role of the principal Value-Chain Users engaged in distribution;
  3. Delivery Model describing the two basic ways – File and Stream – in which Content can be Delivered between Devices;
  4. DRM Tool Model describing the general operation of DRM Tools in Devices;
  5. Domain Model describing the operation of Domains of Devices and Users;
  6. Device Model identifying and describing the principal Devices employed by Value-Chain Users;
  7. Import/Export Model describing how governed Content can be converted to Governed Content and vice versa;
  8. Data Model identifying and describing the different types of Data specified by DMP.

4.3.1 Creation Model

The Creation Model analyses the steps that lead to a Content Item that can be distributed in a Value-Chain.

  1. Work is the result of an effort undertaken by human(s) that constitutes the logical construct that persists independently of the many possible physical representations of that construct
  2. Adaptation is considered a new Work but is of dependent origination in that its existence depends on the existence of another independent Work
  3. Manifestation is an object or event which is an expression of a Work, e.g. the original manuscript of a musical Work
  4. Instance is an object or event which is an example of an Identified Manifestation, e.g. a unique performance of a specific Manifestation of a musical Work.

The relationships between the 4 elements of the creation model are depicted in the figure below

Fig. 3 - Relationships among elements of the Creation Model

4.3.2 Distribution Model

In the Distribution Model the following Users operate:

  1. Content Providers providing Content to End-Users and Service Providers;
  2. License Providers providing Licenses to End-Users and Service Providers;
  3. DRM Tool Providers providing DRM Tools to End-Users and Service Providers;
  4. Service Providers providing Services to End-Users.

Figure 4 – Conceptual diagram of Distribution Model

Note that a specific Value-Chain need not involve all types of Users indicated in the Figure above.

4.3.3 Delivery Model

A DCI is typically not suitable for Delivering Content between Devices. The Package Function, described later, enables Delivery of a Content Item over a variety of specific Delivery mechanisms. IDP-3 supports Delivery as a File (DCF), on an MPEG-2 Transport Stream (DCB) and on a Real-Time Protocol transport (DCS).

4.3.4 Device Model

The way devices are assembled to perform specific functions depends on the specific value chain. However, IDP-3.0 provides general models for a number of Devices typical of some Value-Chains


Device Name




Device Identification Device


A Device whose Function is to assign Identifiers to other Devices


Content Creation Device


A Device whose Function is to Create DCIs


Content Identification Device


A Device whose Function is to Assign Identifiers to DCIs and other Content Elements


Content Provider Device


A Device whose Function is to make Content available for distribution


License Provider Device


A Device whose Function is to provide Licences


Role Verification Device


A Device whose Function is to Verify that a certain Function is compatible with a certain Role


DRM Tool Provider Device


A Device whose Function is to provide DRM Tools


Domain Management Device


A Device whose Function is to Manage Domains


Domain Identification Device


A Device whose Function is to Assign Identifiers to Domains


Content Consumption Device


A Device whose Function is to consume Content (with network access)


PAV eXternal Device


A Device whose Function is to interface a PAV with the rest of the DMP environment


Content Consumption Device


A Device whose Function is to consume Content (without network access)

Of particular interest are the following Devices

PAV eXternal Device (PXD)

As PAV (Portable Audio-Visual) Devices target of IDP-1 do not have network or broadcast connections to Access Content or License, they have to rely on a PXD (or a SAV), that in turn is connected to a network or broadcast channel. The following figure depicts the relationship between the four relevant Devices.

Figure 5 – Operation of a PAV eXternal Device (PXD)

When a PXD has a DCI without a Bundled Licence, it will obtain it from a Licence Provider Device, add the Licence to the DCI, make a DCF, namely a file that can be moved between Devices, and then transfer it to the PAV DEvice.

Stationary Audio and Video Device (SAV)

The general model of a SAV is provided by the Figure below

Figure 6 – Stationary Audio and Video Device (SAV)

IDP-3 explores ways to provide hardware-based security. The first method considered is based on the work carried out by The Trusted Computing Group (TCG), an organisation that has issued specification of a trusted computing platform consisting of two stacks. The first is the software stack called “Trusted Software Stack (TSS)” and the second is the hardware stack called “Trusted Platform Module (TPM)”.

The figure below shows how devices can be interconnected in a value chain.

Figure 7 – Some typical Devices in a Value-Chain

4.3.5 DRM Tool Model

To explain the DRM Tool Model it is necessary to expand part of the SAV Device Model, as in the following figure

Figure 8 – Handling of DRM Tools in a Device

The Device receives Content in Packaged form (DCF/DCB/DCS) and extracts a DCI. Resources referenced in a DCI are either locally Stored as a DCF or Processed in a Resource decoding pipeline. If Resources are protected, they are converted to a form that allows decoding at one of the Control Points. These are points where Resources can be subject to Decryption.

DRM Tools required to e.g. Decrypt Resources may be natively embedded in a Device and executed by the DRM Processor when such DRM Tools are required to Use Content. Alternatively DRM Tools may be Delivered as part of a DCI. If the DCI does not contain the required DRM Tool, the DRM Processor tries to Access it from the local Secure Storage. If the required DRM Tool is not found there, the DRM Processor Accesses the missing DRM Tool from the DRM Tool (or Service) Provider.

In addition to individual DRM Tools, IDP-3 gives the possibility to convey DRM Tool Packs in a DCI. A DRM Tool Pack is composed of a DRM Tools Agent and a set of DRM Tools called DRM Tool Group. A DRM Tool Pack may contain all the DRM Tools required or require other DRM Tools external to the Tool Pack. The figure below depicts the general case of a DRM Processor that can execute a number of DRM Tool Packs and DRM Tools using a standard set of DRM Messages.

Figure 9 – DRM Tools and DRM Tool Packs executed by a DRM Processor

4.3.6 Domain Model

In many cases it is useful to define groups of Devices or Users sharing some common properties. These groups are called Domains. Using Domains it becomes possible to implement more flexible Licensing modalities, e.g. to License a Content Item to all Devices or Users in a Domain. A Domain is managed by a special Device called Domain Management Device.

The figure below represents a possible Domain configuration with:

  1. Two SAV Devices belonging to two different End-Users;
  2. One PAV Device belonging to another End-User connected to the network via a PXD;
  3. One SAV Device belonging to another End-User and remotely connected to the other Devices in the Domain via the Internet.

Figure 10 – An example of Domain

IDP-3 enables a variety of possibilities in managing Domains, e.g.

  1. Create a Domain
  2. Renew a Domain
  3. Delete a Domain
  4. Join a Device/User
  5. Renew a Device/User
  6. Leave a Device/User

4.3.7 Import/Export Model

If a Device needs to access governed content from a value-chain, e.g. when a SAV accesses governed content broadcasted with a license expressed using the RMPI Rights Expression Language (note small initial letters), a Device performs the following steps:

  1. accesses content
  2. translates license into a License
  3. makes DCF using the received Resources, Metadata and the License just made
  4. Stores DCF.

Using a similar process a DCF with an appropriate License can be Exported to a device.

4.3.8 Data Model

IDP-3 provides a rich set of data types. The figure below shows one example of Content and its Content Elements

Figure 11 – An example of DCI

5. Interoperable DRM Platform

The specification is provided by AD #3. IDP-3 provides the key technologies that are required to implement the walkthrough above. These are grouped in 3 categories: Represent, IProtocol and Package.

5.1 Represent

IDP-3 provides a standard Representation of a number of Elements, among which are: Content, Metadata, Identifier, DRM Information, DRM Tool, Rights Expression, Rights Data, Keys, DRM Messages, Domains etc.

5.1.1 Represent Content

Represent Content provides the means to:

The DCI is an XML structure, based on a DMP-defined subset of the MPEG-21 Digital Item Declaration Language (DIDL) [20], and extended by several DMP namespaces to express DMP-specific information. The DMP extends the DIDL with a profile of MPEG-21 IPMP Components [23] to convey various Governed Resources and a set of DMP defined namespaces covering the Representation of general and Governed Content Elements.

5.1.2 Represent Metadata

The IDP-3 gives the freedom to place any Metadata scheme desired into the designated location in the DCI.

In addition DMP natively supports a specific type of Metadata taken from the TV-Anytime Content Description Schema described in [11]. In order to suit the DMP requirements of describing resources to the End User, the DMP Metadata profile has been derived from the TV-Anytime Content Description by defining a smaller version of the TVAMain element that does not include the UserDescription table. It includes the remaining elements namely: CopyrightNotice, ClassificationSchemeTable and ProgramDescription. However, ProgramDescription has also been reduced by defining a dmp:ProgramDescriptionType based on the TV-Anytime ProgramDescriptionType but including only the TV-Anytime elements ProgramInformationTable, GroupInformationTable and CreditsInformationTable.

The TV-Anytime elements not included in the DMP profile are defined as optional in the TV-Anytime specification, and so instance documents conforming to the DMP profile are compatible with the larger TV-Anytime specification.

5.1.3 Represent DCI Signature

The DCI may be signed by some Users who took part in its creation or modified it. A signature is contained in a dmp2rc:DCISignature element. This element can host a number of digital signatures (dsig:Signature) along with the URI of the issuer (dmp2rc:IssuerID).

5.1.4 Represent DCI Hash

In order to allow for the authentication of the DCI integrity without relying on a signature and the associated Key distribution, a DCI may be simply hashed such that a comparison of a newly generated hash with that of an earlier stored version by another party can be made. Although the hash value itself will need to be recalculated, a hash value can be conveyed in the DCI along with the associated algorithm. A number of hash values are contained in a dmp2rc:DCIHash element

5.1.5 Represent Identifier

Identifiers for Content or Content Elements are expressed according to a DMP profile of MPEG-21 Digital Item Identification [22]. The Identifier element contains the Uniform Resource Identifier (URI) of the Content or Content Element is referring to, while the RelatedIdentifier element expresses the URI to which the Identifier is related, for example the identification of an abstraction of the work (e.g. a composition as an abstraction of a sound recording). As a License can be represented as a DCI, License Identification is achieved as for Content Identification. DRM Tool ID syntax should conform to ‘xsd:anyURI’ format. This is the same format as for Tool and Tool Pack (see below), but with the appropriate parent elements. Two types of Device Identification are supported: those provided with a Certificate (Certificate-based Identification) and those without (Device info-based Identification). In the former case an X.509 Certificate is utilised as Device Identifier while in the second a unique Identifier is generated based on the Device information.

5.1.6 Represent Resource

A Resource is Represented in the DCI by the element did:Resource, The data type of the Resource represented by the did:Resource element is identified by the mimeType attribute, as defined in IETF RFC 2045 [34]. A Resource is either defined in a did:Resource element by reference, specifying the Resource’s URI in the ref attribute, or by value, including it inline. The encoding attribute specifies the encoding format used when the Resource is included by value in the DMP2_DIDL XML document. Lastly, the contentEncoding attribute, if present, specifies the content-encoding(s) as defined in IETF RFC 2616 [35] indicating what additional content-encodings have been applied to the Resource.

5.1.7 Represent DRM Information

DRM Information relates to the Governance of Content or Content Elements. It includes

  1. The Representation of the DRM Tools required to Access Content
  2. Any initialisation and configuration data for them, possibly including Decryption Keys and information related to DRM Tool Management
  3. Placeholders for Licenses when these are Bundled within the DCI.

DRM Information is expressed in XML and is based on MPEG-21 IPMP Components [23].

5.1.8 Represent DRM Tool

DRM Tools are software modules performing one or more DRM Functions such as Authentication, Decryption, watermarking, etc. and Represent DRM Tool describes how to indicate within DRM Information which DRM Tool or DRM Tools are required to Access the Content.

Represent DRM Tool is a DMP-specified profile of MPEG-21 IPMP Components [23] and MPEG-2/4 IPMP Extensions to allow the Representation of single DRM Tools. An extension of same allows the Representation of DRM Tool Packs.

5.1.9 Represent DRM Tool Body

Represent DRM Tool Body specifies the Representation of specific information associated with DRM Tool embodiments. When signaled, such Tool embodiments are instantiated on a Device to enable Access to the Governed Content.

5.1.10 Represent Rights Expressions

Represent Rights Expressions specifies how to express usage rules associated with Content that in turn map onto specific Device behaviour consistent with the semantics of the Rights Expressions.

DMP Licenses may be used for different purposes; a non-exhaustive list is given below:

The IDP-3 Represent License extends the MPEG-21 REL Dissemination and Capture (DAC) Profile [25], in order to support Domains.

5.1.11 Represent Rights Data

Represent Rights Data (RRD) is the digital Representation of the Ontology of IP Entities and associated actions taken upon them as well as those taken on their corresponding digital representations as described in the DMP Creation Model. RRD employs the Ontology Web Language (OWL).

With RRD the Creation Model is formalised so that IP Entities may be represented digitally irrespective of whether or not they were originally digital in nature. Thus, the RRD represents rights associated with IP in the analogue space such as First-Fixation (see nelow), Mechanical-reproduction and Public-communication and associates those rights to corresponding digital functions over Resources. In this way and for example, the Right to make an Instance would correspond to the Right of First-Fixation, the Right to make an Instance-Copy to the Right of Mechanical-reproduction and the Right to stream in a multicast to the Right of Public-communication. Thus, the actions associated with for example REL that are conceived to control access to Resources can be associated for example with the higher level Rights associated to IP regardless of whether the IP is represented in an analogue or digital form.

5.1.12 Represent Keys

Represent Keys states how to Represent two different types of Keys:

5.1.13 Represent DRM Messages

Represent DRM Messages provides the means to Represent Information exchanged between different components on a Device, such as two DRM Tools or a DRM Processor and a DRM Tool.

DRM Messages are a translation of messages originally defined in the MPEG-2 and MPEG-4 IPMPX standards (see [14] and [11]) from a binary representation to XML.

5.1.14 Represent Authentication Messages

Represent Authentication Messages defines two Messages which can be employed to achieve Authentication between two Entities, e.g. two Devices. These are: dmp2ram:InitAuthentication and dmp2ram:MutualAuthentication. IDP-3 specifies the Syntax of these messages, while their semantics is specified in [14], where these Messages were originally defined.

5.1.15 Represent Device Information

Represent Device Information specifies the Tools used to Represent the technical characteristics of a Device. This can be used to negotiate between a Device and a DRM Tool Provider for the correct DRM Tools. Represent Device includes information such as type of operating system, memory, CPU, etc.

5.1.16 Represent Domain

Represent Domain has a similar role to Represent Device Information.

5.1.17 Represent Domain Protocol

Represent Domain Protocol specifies the messages exchanged in Protocols to Manage Domain.

5.1.18 Represent Use Data

Represent Use Data provides a digital Representation of Use Data for the purpose of managing Domains.

5.1.19 Represent Binary XML

This Tool enables the transformation of XML documents, representing any of the Entities in this "Represent" section, to a binary format for transmission, processing or storage.

DMP selects the XML binarisation technology called BiM standardised by MPEG-B part 1 [28].

5.1.20 Represent Event Report

Represent Event Report (RER) provides a right holder the means to monitor usage of his content. This is achieved by specifying “reportable events” at creation time, detecting the occurrence of any such event at a Device and, when an event has been detected, perform the actions specified at creation time. These events may relate to

In order to allow the specification of reportable events, Event Reporting introduces the concepts of

An ERR is used to specify:

A general model which reflects the functional aspects of ERR handling and the subsequent creation of ER’s is shown in the figure below where the set of functional blocks can provide the overall Event Reporting functionality.

Figure 12 - Event reporting at a Device

The general model of Event Reporting is as follows:

5.2 Protocols

IDP-3 provides the following Protocols:
  1. Protocols to Identify Entities
  2. Protocols to Authenticate Entities
  3. Protocol to Access
  4. Protocols to Manage Domain
  5. Protocols to Manage DRM Tools

5.2.1 Protocols to Identify Entities

IDP-3 currently specifies Protocols to Identify Devices. The Protocol comprises the generation protocol and exchange protocol. Two kinds of Device Identification are supported:

  1. Device info-based identification” in which a Device Identification Device generates the Device Identifier using some vendor specific information such as vendor ID, model ID or product serial number;
  2. Certificate-based identification” in which a X.509 certificate [30] is utilised for Device Identifier. Identifiers are uniquely generated by a Device Identification Device run by a Registration Agency [5].

IDP-3 also includes several Protocols to Identify Content and Content Elements.

5.2.2 Protocols to Authenticate Entities

IDP-3 currently specifies Protocols to Authenticate Devices. Two kinds of Device Authentication are supported: 

  1. Devices having unique Certificates
  2. Devices that are uniquely Identified by Data

5.2.3 Protocols to Manage Domain

A Domain is set up by a Domain Management Device (DMD) at the request of a Domain Administrator, a User who is responsible for Use of Content on all Devices by all Users. The Domain is Identified by a Domain Identification Device (DID). This DomainID is composed of the DMD ID which has a unique for all DMDs and an Identifier of the Domain within that DMD.

The DMD makes the Domain Information and Stores it on the DMD. For each Device or User joining the Domain the DMD makes a Domain Context for Device or User and Delivers it to the appropriate Device or User.

A Device or a User requests a License Provider Device (LPD) to Provide a License for Content to be Used in a Domain. The License, possibly Bundled within the Content, is Delivered to a User or a Device (SAV or PAV, the latter via PXD). To be able to Use Domain-bound Content a Device or User must check that the Domain Context Stored in the Device or User matches the Domain Context in the License of the Domain bound Content.

The functionality of the “Protocols to Manage Domain” Protocols includes:

Figure 13 - Overview of Manage Domain

In summary to set up a Domain the following sequence of steps is required:

  1. The Domain Administrator requests an account ID and a password from a DMD
  2. The DMD creates a new Domain and Registers the Domain with a DID
  3. The DID issues a dmp2rd:DomainID
  4. The DMD creates the Domain Information
  5. To join the Domain a Device or User Authenticates itself to the DMD and sends the account ID and password to DMD
  6. The DMD creates and Delivers the Domain Context for Device or User to the Device or User.

The DMD maintains a list of Devices and Users in all registered Domains managed. Every time a new Device or User joins a Domain, the Device Manager adds the Device ID or User ID to the corresponding Device or User list.

In order to manage the simultaneous usage of Content Items in a Content Grouping by the Devices or Users, an LPD may employ Content Group IDs in a License. Multiple Content Group IDs may appear within a License. Where required, it is possible to limit the number of Content Groups permitted within a Domain.

5.2.4 Protocols to Manage DRM Tools

Manage DRM Tools is a set of Protocol between the DRM Processor and DRM Tools or between DRM Tools. When the DRM Processor parses the DCI and finds a Content Element Governed by a DRM Tool, it will look for the appropriate Tool Body identified by the DRM Tool ID signalled in the DCI. After employing the Local DRM Tool Access Protocol, the DRM Processor knows the pathname of the file corresponding to the required DRM Tool or DRM Tool Pack. At this point the DRM Processor instantiates the DRM Tool.

The Managing of a DRM Tool by the DRM Processor involves the exchange of DRM Messages between a DRM Processor and a DRM Tool according to a Messaging API which is particular to each Device. The DRM Processor chooses the DRM Tool which is characterised by the Messaging_API_ID supported by the Device it is part of.

The DRM Tool receiving DRM Messages will obtain from the container Message the information about the Context ID of the Sender (the “Sender” element) and the Context ID of the DRM Tools (the “Recipient” element).

The instantiation of a DRM Tool involves the connection of the DRM Tool instance in a specific Control Point and with a specific Sequence Code.

5.2.5 Protocols to Access

IDP-3 provides Protocols to Access Content Elements, namely

  1. Content with Bundled License
  2. Licenses
  3. DRM Tools
  4. Keys

These Content Elements may be Packaged for Delivery as File or Stream for Use by a PAV Device (via PXD) or a SAV Device. Stecifically the following is provided

  1. Protocol to Access Content as File
  2. Protocol to Access License as File
  3. Protocol to Access DRM Tool Body as File
  4. Protocol to Access DRM Tool Body as Stream
  5. Protocols to Access Key as Stream
  6. Local License Access Protocol
  7. Local DRM Tool Body Access Protocol

5.3 Package

To deliver Content between Users it is necessary to Package Content in files or streams.

5.3.1 Package Content as File

IDP-3 provides Tools to Package Content in Files. The file contains the DMP Content Information (DCI) with some or all of the Resources it references in ‘Boxes’ defined by the ISO Base Media File Format and the MPEG-21 File Format [25]. The link between the DCI (containing Metadata and Governance information) and the Resources is done through the Item Location Box (iloc), which specifies the physical location in the file of a Resource described in the DCI.

This is represented in the figure below.

Figure 14 – Conceptual diagram of DMP Content Format (DCF)

5.3.2 Package Content as Stream

A number of transport mechanisms may be employed to transmit a DCI between Devices, e.g. the MPEG-2 Transport Stream (MPEG-2 TS) and the Real-Time Protocol over User Datagram Protocol over Internet Protocol (RTP/UDP/IP). When using these transmission protocols, Content must be packetised and then transmitted incrementally to the receiving Device. This includes packetisation of the Content Elements in the DCI.

IDP-3 specifies the means to incrementally transmit a DCI and its component Content Elements, either referenced or included, in a piece-wise fashion and with temporal constraints in such a way that a receiving Device may incrementally Use the DCI. At the receiving end, a potentially fragmented DCI is received, where, for instance, some parts may have been removed or transformed at the transmitting end according to some rules.

Package Content as a Stream is based on MPEG-21 Digital Item Streaming (DIS) [28]. The DIS standard specifies a Bitstream Binding Language (BBL) using which it is possible to describes how a DCI may be broken down for transmission and then mapped to the transmission channels of interest: MPEG-2 Transport Streams and RTP/UDP/IP.

There are two basic types of BBL document: Instance and Binding descriptions.

  1. Instance describes the streaming instructions for a DCI and contains references to the DCI and any other resources of the DCI. References may be URIs, or pointers to the location of the URI within the DCI.
  2. Binding provides the abstract mapping of the DCI or part thereof to the particular set of output streams (MPEG-2 TS and RTP/UDP/IP). Bindings are instantiated as part of an Instance, which provides the URI references for the fragments of Content to which the Binding(s) are to be applied.

Binding is a set of abstract Bitstream Binding Language instructions which map a DCI into a collection of packets to be output to one or more handlers, as shown in the Figure below.

Figure 15: Streaming a DCI using Digital Item Streaming

6. Use Cases and Value-Chains

These are provided by AD #4. IDP-3 provides a number of Use Cases showing how the IDP-3 Tools can be used to build Value-Chains implementing them. The Value-Chains are normative. This does not mean that IDP-3 inhibits different assemblies of Tools for the same or similar purpose, but only that Users who implement the Use Case by assembling the Tools as specified in AD #4 will be able to interoperate with other Users who will assemble the Tools in a similar way. Here is a brief introduction to some of the Use Cases considered.

6.1 Open Release

This Use Case shows how it is possible to Release Content, e.g. on the web, in a Governed fashion, but without applying protection technologies. Open Release can, for example, enable a Creator to Release Content now with a very broad License of use without jeopardising future opportunities of other forms of Release.

6.2 Open Search

This Use Case builds on the previous Use Case and envisages a Content search service that utilises the rich Metadata associated with Open Release Content and their terms of License to provide different services, such as searching of a content item on a certain subject with a certain Licence.

6.3 Home Distribution #1

This Use Case envisages new forms of Content Use in the home that leverages on the existence of Domains (e.g. corresponding to a family) and sub-Domains (e.g. corresponding to the set of Devices belonging to one member of a family).

6.4 Home Distribution #2

This Use Case shows how it is possible, by using robust DRM technologies, to disassociate distribution of Content from its original a consumption model in a way that easily maps to alternative existing models.

6.5 Internet Distribution

This Use Case shows how it is possible to lower the entry threshold to Content distribution by applying IDP-3 technologies presuming that DMP Devices have been broadly deployed.

6.6 Controlled Peer-to-Peer Distribution

This Use Case shows how it is possible to use IDP-3 Tools and build a community using a peer-to-peer network to share different types of Content such as User Generated Content released with, say, an Open Release Licence, and other professional Content released with, say, a more stringent Licence.

6. Smart Retailer

This Use Case shows how different retailing strategies can be implemented by using the flexibility of Rights Expression Language (REL).

6.7 Personal Photography

This Use Case shows how IDP-3 Tools can be used to enhance privacy in the specific case of distribution of personal photographs.

6.9 Open Broadcast

In this Use Case a light-weight form of content governance is applied to a digital TV broadcast service that may satisfy some concerns of Content Providers and Service Providers while not affecting the End User experience negatively.

6.10 Open Governed Broadcast

This Use Case shows how it is possible to go beyond the current business models adopted by some Service Providers based on proprietary Conditional Access systems and set up Value-Chains that rely on an open, horizontal market of Interoperable Devices.

6.11 Smart Broadcaster

This Use Case collects a number of ways to broadcast TV Content using a broad variety of Licenses.

6.12 Open Governed Interactive Content

In this Use Case the distribution of interactive video Content, such as Video on Demand, carried by RTP/UDP/IP is considered.

7. Certification and Registration Authorities

This is provided by AD #5. Entities such as Devices (e.g. Creation Devices, Consumption Devices and Domain Managers) and DRM Tool Bodies have to be Certified before operation on the IDP. As an example, Certification constitutes a key assurance for a Rights Holder to entrust his Content to a Device. Certification is carried out by a plurality of organisations dedicated to the task of Certifying Entities. To perform this task these organisations must be properly accredited by a root authority called Certification Authority. IDP-3 describes the process according to which DMP appoints a Certification Authority and oversees its operation. Further it 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 task of Identifying Entities such as Content, Devices and Domains is a critical one, e.g. in the case of Devices, where Identification constitutes a key element of Trust establishment. This Identification task is typically carried out by several organisations 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 supervising them is very similar.

8. Terminology

This is provided by AD #6. IDP-3 provides a set of terms and corresponding definitions that are used throughout the ADs. Providing these terms with consistent meanings will hopefully overcome the problem of DRM being a new field that impacts many existing fields with their own established and sometimes conflicting terminologies.

Access (Content)

The Function executed by a Device when making Content available so that the Device can execute Functions on it

Adapt (Content)

The Function of restricting the attributes of a Content Item, e.g. by reducing the Permissions in a License

Adapt (Resource)

The Function of modifying the attributes of a Resource, such as converting 5-channel music to 2-channel music, or sub-sampling a high-definition video to a standard-definition video, etc.


A Work that is derived from another Work  


A User who produces an Adaptation

Annotate (Resource)

The Function of a User who

  1. References a specific Fragment of a Resource and

  2. Links the reference to another Fragment Created by the User

Approved Document

Any of the following types of DMP documents

  1. Recommended Action

  2. Recommended Practice

  3. Technical Reference

  4. Technical Specification

Assign (Identifier)

The Function of allotting an Identifier to an Entity


The Function of proving the identity of an Entity to a Device or User


The Function that supports

  1. Duplication of Content

  2. Duplication of Rights Expression in case this is a Stateless Rights Expression, and

  3. Moving of the duplicate(s) to another location that is not a Device

Binarised XML

XML data converted to binary form in a lossless fashion


The Function that Delivers Content to a Device in a point-to-multipoint modality


The Function of binding two sets of Data


The process whereby a Certification Agency issues a Certificate


A token attesting that an Entity has passed the tests of a Certification Agency

Certification Agency

A User appointed by a Certification Authority to Certify Entities

Certification Authority

A User appointing and overseeing Certification Agencies


Data that can be Processed as is by a Device


The terms and obligations under which Permissions in a License can be exercised


The status of a Content or Device Entity that has been judged to positively meet the requirements of a Technical Specification


A DMP-defined structure of Content Elements

Content Element

Any of the following Data types: Resource, Metadata, Content, License, DRM Information, DRM Tool, DRM Tool Pack and Use Data

Content Entity

Any of the following Entities: Content and Content Elements

Content Interoperability

The capability of governed content to be used by a device within the terms of a license. DMP Governed Content is Interoperable with DMP Devices

Content Item

A particular instance of Content

Content Provider

A User who Delivers Content to another User

Control Point

A point in a Device under the control of a DRM Tool, e.g. in a Resource decoding pipeline
Copy The Function by which Device A Stores Content in Device B, preserving the original Content in Device A


A User who generates a Work and makes its first Manifestation, also referred to as author


Information describing the security attributes of an Entity


Information converted to digital form


The Function of bringing previously unprocessable Data to a processable form using a Key


The Function of erasing a Content Item Stored on a Device


The Function of transferring Content between any two or more Devices using a transport mechanism (file download, broadcast transport protocol or network streaming protocol)

Delivery System

A system designed to enable Delivery of Content between Devices


Data that describe the properties of a Resource


A combination of hardware and software or just an instance of software that allows a User to execute Functions

Device Entity

Any of the following Entities: Device, User and Domain

Device Information

Data characterising a Device, e.g. CPU, OS etc.

Device Interoperability

The capability of a device to exchange data with other devices across standard interfaces, using standard protocols, and to be processed by the devices exchanging the data in a predictable fashion. DMP Devices are Interoperable

DMP Content Broadcast (DCB)

DMP Content Information Packaged for Delivery as Broadcast

DMP Content File (DCF)

DMP Content Information Packaged for Delivery as File

DMP Content Information (DCI)

The digital Representation of Content

DMP Content Broadcast (DCS)

DMP Content Information Packaged for Delivery as Streaming

DMP DRM System

A set of Devices that manage, possibly protect and Use Content in an Interoperable fashion. A DMP DRM system implementation allows Devices to Use Content from another DMP DRM System implementation even though the latter may use different technologies

DMP Information

Data used to describe Content and Content Elements not related to Governance


A set of Devices sharing some common attributes, such as personal or group ownership that is appropriate for various business models

Domain Context Information

Data characterising a Domain that is Stored in a Device for the purpose of Managing and Licensing Use of Content in Domains

Domain Information

Data characterising a Domain that is Stored in a Domain Management Device, e.g. the list of Devices, Users, Domain Key etc.

Domain Management

The set of Functions that relate to the

  1. Creation, renewal and deletion of Domains
  2. Joining, renewing and leaving a Domain by Devices and Users
  3. Licensing of Content to Domains

DRM Information

Data that describe Governance of Content

DRM Message

A message exchanged between DRM Tool Bodies, DRM Processor and Devices

DRM Processor

A module within a Device Certified by a Certification Agency as being Trusted for executing DRM-related Functions

DRM System A system of Information Technology components and services which strives to distribute and control content and its rights. This operates in an environment driven by law, policies and business models.
DRM Tool An algorithm which implements one or more DRM Functions

DRM Tool Agent

Executable code that instantiates, initialises, Authenticates, and supervises any operation performed between DRM Tools within a DRM Tool Group

DRM Tool Body An executable computer code that implements a DRM Tool

DRM Tool Group

A combination of DRM Tools

DRM Tool Pack

Executable code that comprises a DRM Tool Group and its DRM Tool Agent


The Function of Modifying a Content Item, such as by adding, deleting, or altering pieces of Content in a Content Item


The Function of making Data unprocessable unless a Key is available to bring the Data to a processable form


A User in a Value-Chain who ultimately consumes Content


Any of the following: Intellectual Property Entities, Content Entities and Device Entities


A Device or set of interconnected Devices. An Environment can interact with other Environments using Protocols and can also interact with the outside of the Environment through appropriate interfaces using protocols


The End-User’s emotional and economic result of Using Content


The Function of making available a Content Item to a non-DMP DRM system


Content Entity which is Stored on a Device


The Function of Storing a Manifestation of a Work


The geographic area, typically delimited by political boundaries, intended to be covered by a broadcast signal


A time-marked portion within a Resource


Any action implemented with DMP-specified technologies

Governed Content

A Content Item that is at least Identified


The Function of a User asserting to another User the Permission to Use a Content Item under specified Conditions


The Function of Assigning a unique signifier that establishes the identity of Entities


The unique signifier Assigned by Identification


The Function of Accessing a governed content item from a non-DMP DRM system


An object or event which is an example of an Identified Manifestation (e.g. a File)


A User who produces an Instance


The state of a Content Item when the information contained has not been altered or corrupted

Intellectual Property (IP)

A property created through efforts of a predominantly intellectual nature that can be generally protected by copyright or similar laws


The Data interchange point between

  1. Devices
  2. Devices and devices
  3. Devices and Users
  4. Devices and Delivery Systems


The ability of a User to technically execute Functions through Interfaces and Protocols, based on open specifications, with predictable results

IP Entities

Concepts that are Represented by Content to which Intellectual Property is attributed, namely: Work, Adaptation, Manifestation, Instance


The geographic area over which a given set of laws is enforced


Data used by a cryptographic method to make Clear-text Data Encrypted or, conversely, Encrypted Data Clear-text

Key Management

The set of processes employed to create, authenticate, issue, distribute, store, recover, and revoke Keys


The Function of Moving a Content Item Stored in one Environment for temporary Use into another Environment


The Function by which a User Grants Permissions to Use a Content Entity


Data Representing the Permissions to a Content Entity under given Conditions expressed by Rights Expressions that are Granted by one User to another User


The User to whom another User Grants Rights


The User who Grants Rights to another User


The establishment of a relationship between two Fragments


An object or event which is an expression of a Work


Data that describe Content and Content Elements

Move The Function by which Device A Stores Content in Device B deleting the original Content in Device A

Package (Content)

The Function of Processing Content for the purpose of Delivering it between Devices


The Function of looking for useful Data in Data


The Function of suspending the Rendering of a Resource by a User


A type of Instantiator


The ability to execute Functions on a Content Item


The technology infrastructure that enables Users to Use Content


The Function of Rendering a Resource


A principle accepted by a group of Users

Primitive Function

 A Function typically embedded in more than one Function


The User to whom Permissions are Granted

Private Key

A Key used to Encrypt Data that only the corresponding Public Key can Decrypt or Decrypt data Encrypted by the corresponding Public Key


The Function of transforming Data executed by a Device


A description of Data formats and rules a Device must follow to exchange those Data with other Devices

Public Key

A Key used to Encrypt Data that only the corresponding Private Key can Decrypt or Decrypt data Encrypted by the corresponding Private Key


The Function of making Content available to other Users


A User who selects Content and makes it available to other Users


The Function of referencing or extracting a Content Item from another Content Item

Rate (Content)

The Function of measuring the Use of a Content Item by a set of Users


The Function of Assigning an Identifier to an Entity and keeping a record of it

Registered Content

Content to which an Identifier has been Assigned by a Registration Agency

Registration Agency

A User appointed by a Registration Authority to Assign Identifiers

Registration Authority

A User managing Identifier name spaces, and appointing and overseeing Registration Agencies


The Function of a Producer who makes a Content Item available to other Users, e.g. at commercial terms


The Function of converting a Resource to a human-perceivable form


The Function of Moving a Content Item that was Used in one Environment for Use in another Environment in an exchange based on a Value-Expression for a given period of time


The Function of expressing information in a form that can be processed by a Device


Data, whose Representation is not specified by DMP (e.g. an MP3 file or an executable code), that can be Processed by a Device

Resource Type

A Resource such as video, audio, audio-visual, text, synthetic audio, 2D/3D graphics etc.


The Function of Moving Content and the associated Stateless Rights Expression, if any, to the Device from which Backup had been performed


A User who sells or Licenses Content to an End-User


The Function of removing the ability of a Device to Use Content or recalling a Content Item


The Function of restarting the Rendering of a Resource


A consequence of ownership of Intellectual Property by legal prescription

Rights Data

The semantic of Functions that relate to Permissions e.g. Rights Data of Copy is the semantic of Copy in a Device

Rights Expression

Data that can be Processed to obtain the list of Functions that can be performed on a Content Item and the Conditions under which they can be performed

Rights Holder

A User who has Rights to License Content


A description of the structure and rules an XML document must satisfy

Secure Authenticated Channel (SAC)

A Delivery System that is secure and Encrypted


A set of Functions executed by a User on Content that is valuable for another User or Users


Data Encrypted with a private Key and appended to other Data typically for the purpose of guaranteeing the Integrity of the Data

Stateless Rights Expression

A Rights Expression that does not include any Use counts or overall Use duration etc.


The Function by which Device A Delivers Content to Device B for the purpose of retaining it in Device B for Use at a different point in time


The Function of Delivering Content to a Device where the transferred Content is processed for Rendering only and not Stored

Super Distribution

A mechanism that

  1. Allows an End-User to distribute Content to recipient End-Users or Devices through potentially insecure delivery systems and
  2. Enables the End-Users of the recipient Devices to obtain a Rights Expression for the said Content


The Function of incorporating pre-existing musical or literary musical Work into a determined audio-visual Work (e.g. publicity message)


The Function of Licensing Works or Content for Publication or Distribution by more than one Publisher or Distributor, typically simultaneously

Technical Specification

A type of Approved Document containing normative clauses. Its use in Devices, Contents and Services may require business agreements between relevant Users. Such business agreements are outside of DMP


The geographical area under the Jurisdiction of a sovereign state


A technology capable of implementing a Function

Trick Modes

Any of the following Functions, or Functions of a similar type, performed on a Content Item during Rendering by a User:

  1. Fast forward
  2. Slow motion
  3. Freeze frame
  4. Fast reverse
  5. Slow reverse


A state where Entities enable Users to execute Functions on Governed Content

Trust Management

The set of mechanisms by which Trust can be established, preserved and severed

Update (Content)

The Function of changing a Content Item in a Device


The execution of a Function on a Content Item by a Device

Use Case

A description of a specific case involving the establishment and operation of a Value-Chain that can be implemented using the Tools specified in Approved Documents

Use Context

The association of a Content Item with other Content Items and the circumstances of Use

Use Data

Data documenting the Functions performed by a Device Entity on a Content Item and the associated context


Any person or legal entity in a Value-Chain connecting (and including) Creator and End-User. For the purpose of the current phase of Approved Documents a User is represented by a device or by a User Identity on the Device (e.g. username/password).

User Data

Data related to a User


A group of interacting Users, connecting (and including) Creators to End-Users


The equating of any two groupings of Content Items and/or Services


The Function of assessing the Integrity of

  1. A Content Item
  2. A Device


The Function of a Creator that discontinues any and all Licenses to Use one or more of his Works


A creation that retains intellectual or artistic attributes independently of its Manifestations

9. Reference software

The DMP Reference Software provides a normative reference software implementation of the DMP specification. This is written in Java and is available in source code under the terms of the Mozilla Public License Version 1.1 and is currently under development by the Chillout project.
is organised in the following structure: 

1.      Core library: library of classes implementing the Primitive functions defined in the Technical Specification. This software is normative as much as the Technical Specification and provides the functionalities needed to:

2.      Auxiliary library: library of classes encapsulating the functionalities of a number of modules which a Device may have as a hardware or software implementation. This library is not normative, in real Devices, these modules are supposed to be replaced by proprietary ones. However the interfaces made available by some or by all the components of this library may become part of the DMP Technical Specification. A preliminary list of the modules part of the Auxiliary library is given below;

3.      Applications: a set of sample applications with the purpose of showing how to use the classes part of the Core and Auxiliary library and to provide a number of demonstrators of the DMP functionalities. This category includes a number of Devices: SAV, CCD, LPD, CPD, CID, TPD, DID, DMD. This library also includes testing applications such as those for testing Protocols, well-formedness of DCI, License, etc. The figure below shows the list of all available Devices and a possible way of inter-connecting them.

Chillout Devices currently run on Windows, Mac and Linux Operative Systems.

The figure below shows the relationship between the software libraries described above.  

Figure 16 – DMP Reference software layers

The DMP Reference Software is available from the Chillout Subversion repository. The code can be downloaded by any computer using a Subversion client, and it can be automatically built by Apache Maven 2 project management tool.

The figure below shows the Chillout Subversion repository when explored with a Subversion client:

Figure 17 – Overview of the Chillout software repository

The following modules are currently available in the trunk remote folder: 

In addition to the Project Object Model (POM) describing the whole software, each individual module has its own POM containing the instructions needed by Maven to build it.

The Chillout software needs a number of software tools in order to be compiled on a computer. These are:

Each individual module also requires a number of libraries in order to be compiled; these are downloaded automatically by Maven when it is executed. In addition to these, each module may require additional external software in order to run, such as the Apache Tomcat servlet Container, Apache Ant, etc. Further details on the software dependencies for each module will be given in the sections describing all modules individually.

10. End-to-End Conformance

DMP Approved Documents provide Tools and guidance to Users on how to employ the DMP-specified Tools to set up Value-Chains. However, DMP Approved Documents #1 to #7 are in general not sufficient to respond to the following basic questions: 

  1. Has a given Content or Device Entity been made correctly according to the Technical Specifications?
  2. Can the Device Entity that has passed the test of Question 1. be safely admitted to a Value-Chain, i.e. it does not compromise its integrity?

Being able to respond to the first question is a pre-requisite for building Interoperable Value-Chains based on Devices that are independently manufactured and Use independently Created Content. This is the first purpose of AD #8. The goal is achieved through the use of methodologies, test suites and software to test Entities for Conformance to the Technical Specifications.

By using this material Users will be in a position to:

  1.  Take a content item, feed it to a reference Consumption Device, i.e. a Consumption Device whose Conformance has been positively assessed, observe the performance of the Device and judge whether the content item is a Content Item;
  2. Take a protocol, install it on a device, observe the performance of the Protocol running on a reference Device that sends reference Content, i.e. Content whose Conformance has been positively assessed and judge whether the implementation of the protocol is a Protocol;
  3. Take a device, e.g. a content consumption device, connect it to a number of reference Devices, e.g. Content Provider Device, Domain Management Device etc., and judge whether the implementation of the content consumption device conforms to the Technical Specifications by observing its performance when subjected to a number of test suites;
  4.  Etc.

In order to build Value-Chains that Users can entrust their assets to, with an expectation that they will be Used as expected, Users require means to obtain responses to the second question. This is a primary function of the Certification Authority and Agencies whose general role is described in AD #5 – Certification and Registration Authorities. Therefore AD #8 only provides general elements that help provide responses to Question 2, with the understanding that complete answers to this question with a level of satisfaction suitable for business practices in a specific environment can only be obtained from Certification Agencies.

11. Mapping of Traditional Rights and Usages to the Digital Space

DMP specifications provide interoperable technologies that help Use Governed Content (i.e. Content that is at least Identified). Some of these technologies (i.e. Identification) do not require Rights Holders’ Permissions, others (i.e. Licenses) provide a more complete set of possibilities to manage Content throughout the Value-Chain requiring Rights Holders’ Permissions.

Traditionally Users have had many ways of enjoying content they purchase or access some of which do not require rights holders’ permission. Some of these media usages are backed by law in some jurisdictions, some others are dealt with as exceptions to the law and some others are practices currently exercised simply because the state of technology enables them.

DMP feels that solutions that are based on the Interoperable DRM Platform (IDP) could be seen as a poor proposition, in spite of being superior to other DRM solutions thanks to the Interoperability they provide, because the experience gained from them may be perceived by Users as inferior to the current digital or even to the analogue experience.

DMP calls Traditional Rights and Usages (TRU) the ensemble of usages made possible by laws and exceptions or simply practiced by the general public. The DMP community has gone to a great pain collecting and studying as many TRUs as possible (88).

The objective of AD #9 is to provide illustrative examples of:

  1. Support of uses similar to those that users were accustomed to in the analogue age but using the technologies in the IDP and without compromising the integrity of a Value Chain that is based on it
  2. New innovative ways of offering and consuming digital media largely inspired by TRUs that DMP calls Digital Media Business Models (DMBM).

For each TRU/DMBM supported the following is provided:

  1. A rationale for the TRU/DMBM
  2. One or more than one solution enabling support of the selected TRU/DMBM, each with
    1. A walkthrough complemented with the list of IDP Tools required

    2. Additional actions that may be required to enable TRU/DMBM support.

Note that

  1. The DMP has no intention to debate, define or promote the legal status of any of the specific examples of TRU support;
  2. The ways to support a TRU can be manifold. The fact that one has been selected does not imply that DMP has a preference for that particular TRU support and anybody is encouraged to provide alternative solution cases following the template used in this Approved Document. These will be discussed by DMP in an open forum and, if considered technically sound, added to the next version;
  3. The DMP intends to add more TRUs/DMBMs or just more solution cases in future releases of this Approved Document;
  4. Full support of some TRUs may require technologies that are not yet in the IDP Tool kit (indicated in italics) but whose addition may already be under investigation;
  5. In most cases a practical implementation of the solutions presented might require a third party action, e.g. legislation, in order to determine the conditions under which a User is entitled to get a License as opposed to ask for a License;
  6. By identifying a third party action, the DMP does not intend to suggest that such an action necessarily be undertaken.

Below is a sample TRU handling

11.1 Use Case #1 – Quote TRU

11.1.1 Rationale

An important feature of digital vs. analogue media is the low threshold of entry to creation because virtually anybody is in a position to create Content of high (technical) quality using inexpensive devices and software. With more and more Content that is being posted it becomes important for persons in their capacity of Creators to be able to make Quotes from Content that has been Released, possibly in a format that employs technical protection measures.

11.1.2 Solution case #1

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.

11.1.3 Walkthrough

Tim performs the following sequence of steps:





IDP Tool





To quote 10 seconds of “My best quote of the year”

Negotiate License




Using a Content Creation Device (CCD). The DCI includes

  • Tim’s Content

  • The 10 seconds of the movie

  • The License obtained for Quoting the movie

Represent Content





Protocol to Identify Content





To Content Provider Device

CCD-CPD Protocol





Package Content as File


11.1.4 Recommended Actions

There are several ways in which this TRU can be actually implemented. Here follows a non-exhaustive list

  1. In a given Jurisdiction the law may oblige Rights Holders to allow a User to make a limited number of Quotes of a given Content Item each with a maximum duration
  2. In a given Jurisdiction a subscriber to a movie service may be entitled to make a limited number of Quotes of a given maximum duration
  3. The Rights Holder of “My best quote of the year” may wish to promote his movie using the technology analysed in the walkthrough giving away a limited number of Quote Licences
  4. A User may offer to send Quotes of the movie to a number of friends and be paid for the effort
  5. ....

12. The next steps

IDP-3 is the third release of the Interoperable DRM Platform and represent a pretty mature specification. However the work is not finished and the work to be carried out is shown below.

  1. New technologies for IDP-3.1 AD #3
    1. New domain management technologies
    2. New protocols
      1. To Validate Device ID
      2. To query the CRAu to know which Agency issued a given Identifier
      3. To query the RRD ontology
    3. Hardware-based security (TCP/TPM, USB keys)
  2. New reference software for IDP-3.1 AD #7 for
    1. Core Library
    2. Auxiliary Library
    3. Applications
  3. Demonstration software for IDP-3.1 AD #7 (or AD #10) for
    1. Media Streaming MAF
    2. Web, IP and Mobile (WIM) TV
    3. Others
  4. Proposal of DMP technologies and solutions to standards bodies
    1. Web, IP and Mobile (WIM) TV
    2. Chillout for MPEG eXtensible Middleware
  5. Promotion of DMP
    1. The WIM TV trial at Beijing Olympics

13. Conclusions

IDP-3 is the result of an effort that has lasted 4 years. The first 6 months were covered by the activity that led to the Digital Media Manifesto [10] and to the establishment of the Digital Media Project. The next 16 months produced IDP-1 (April 2005). IDP-2 started in January 2005 with the IDP-2 Call for Proposals and the specifications were approved in February 2006. IDP-2.1 was approved in January 2007 and IDP-3 was approved in October 2006.

Currently there is a large number of initiatives trying to provide some DRM standards. They can be classified as follows

  1. Initiatives that are designed to serve the needs of a particular industry
  2. Initiatives focusing on a particular point in the value-chain
  3. Initiatives trying to develop a "DRM conversion box".
DMP stands out as the only initiative that has produced a DRM standard with the following features
  1. Industry agnostic
  2. Covering the entire value-chain
  3. Tool based
  4. With reference software
  5. With support to traditional rights and usages

14. References

1.      Digital Media Project; Approved Document No. 1 – Technical Reference: Use Cases; 2005/04

2.      Digital Media Project; Approved Document No. 2 – Technical Reference: Architecture; 2005/04

3.      Digital Media Project; Approved Document No. 3 – Technical Specification: Interoperable DRM Platform; 2005/04

4.      Digital Media Project; Approved Document No. 4 – Technical Specification: Value-Chains; 2005/04

5.      Digital Media Project; Approved Document No. 5 – Technical Reference: Registration Authorities; 2005/04

6.      Digital Media Project; Approved Document No. 6 – Technical Reference: Terminology; 2005/04

7.      Digital Media Project; Approved Document No. 7 – Technical Specification: Reference Software, 2006/01

8.      Digital Media Project; Approved Document No. 8 – Recommended Practice: End-to-End Conformance, 2006/01

9.      Digital Media Project; Approved Document No. 9 – Recommended Action: Mapping of Traditional Rights and Usages to the Digital Space, 2006/01

10.  The Digital Media Manifesto, http://www.dmpf.org/manifesto/, 2003/09/30

11.  The Digital Media Project, Procedures of Work, http://www.dmpf.org/project/procedures_of_work.htm

12.  ISO/IEC 13818-1, Information technology — Generic coding of moving pictures and associated audio information — Part 11: IPMP on MPEG-2 systems

13.  ISO/IEC 14496-12, Information technology – Coding of audio-visual objects (MPEG-4) – Part 12: ISO base media file format

14.  ISO/IEC 14496-13, Information technology — Coding of audio-visual objects — Part 13: Intellectual Property Management and Protection (IPMP) extensions

15.  ISO/IEC 15938-1, Information technology – Multimedia content description interface (MPEG-7) – Part 1: Systems

16.  ISO/IEC 15938-2, Information technology – Multimedia content description interface (MPEG-7) – Part 2: Description Definition Language

17.  ISO/IEC 15938-5, Information technology – Multimedia content description interface (MPEG-7) – Part 5: Multimedia Description Schemes

18.  ISO/IEC 15938-9, Information technology – Multimedia content description interface (MPEG-7) – Part 9: Profiles and Levels

19.  ISO/IEC 15938-10, Information technology – Multimedia content description interface (MPEG-7) – Part 10: Schema Definition

20.  ISO/IEC 15938-11, Information technology — Multimedia content description interface — Part 11: MPEG-7 profile schemas

21.  ISO/IEC 21000-2, Information technology – Multimedia framework (MPEG-21) – Part 2: Digital Item Declaration

22.  ISO/IEC 21000-3, Information technology – Multimedia framework (MPEG-21) – Part 3: Digital Item Identification

23.  ISO/IEC 21000-4, Information technology – Multimedia framework (MPEG-21) – Part 4: IPMP Components

24.  ISO/IEC 21000-5, Information technology – Multimedia framework (MPEG-21) – Part 5: Rights Expression Language

25.  ISO/IEC 21000-5 Amd 2, Information technology – Multimedia framework (MPEG-21) – Part 5: Rights Expression Language, Amendment 2, Dissemination & Capture Extension (DACX) Profile

26.  ISO/IEC 21000-5 Amd 3, Information technology – Multimedia framework (MPEG-21) – Part 5: Rights Expression Language, Amendment 3, Open Access Content (OAC) Profile

27.  ISO/IEC 21000-7, Information technology – Multimedia framework (MPEG-21) – Part 7: Digital Item Adaptation

28.  ISO/IEC 21000-9, Information technology – Multimedia framework (MPEG-21) – Part 9: File format

29.  ISO/IEC 21000-15, Information technology – Multimedia framework (MPEG-21) – Part 15: Event Reporting

30.  ISO/IEC 21000-18, Information technology – Multimedia framework (MPEG-21) – Part 18: Digital Item Streaming

31.  ISO/IEC FDIS 23000-5, Information technology – Multimedia Application Format (MPEG-A),  Media Streaming Application Format

32.  ISO/IEC 23000-7, Information technology – Multimedia Application Format (MPEG-A), Open Access Application Format

33.  ISO/IEC 23001-1, Information technology – MPEG Systems Technologies (MPEG-B) – Part 1: Binary MPEG format for XML

34.  ITU Recommendation X.509 | ISO/IEC 9594-8 – Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks, 03/00

35.  ETSI TS 102 822-3-2 V1.3.1 (2006-01); Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 2: System aspects in a uni-directional environment

36.  ETSI TS 102 822-5 v1.1.1; Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime Phase 1"); Part 5: Rights Management and Protection (RMP) Information for Broadcast Applications

37.  IETF RFC 1737, K. Sollins and L. Masinter, Functional Requirements for Uniform Resource Names, December 1994.

38.  IETF RFC 2045 N. Freed and N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part one: Format of Internet Message Bodies.

39.  IETF RFC 2141 R. Moats, URN Syntax, May 1997.

40.  IETF RFC 2616  R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee "Hypertext Transfer Protocol – HTTP/1.1"

41.  IETF RFC 2459, R. Housley, W. Ford, W. Polk, D. Solo, " Internet X.509 Public Key Infrastructure Certificate and CRL Profile", January 1999.

42.   “XML-Encryption Syntax and Processing” - W3C Recommendation 10 December 2002. http://www.w3.org/TR/xmlenc-core/.

43.  “XML-Signature Syntax and Processing” - W3C Recommendation 12 February 2002. http://www.w3.org/TR/xmldsig-core/.

44.  “XML SchemaXML Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004”, http://www.w3.org/2001/XMLSchema

45.  W3C Candidate Recommendation, “XML Path Language (XPath) 2.0”, 3 November 2005, http://www.w3.org/TR/xpath20/

46.  OWL Web Ontology Language (http://www.w3.org/TR/owl-features/)

47.  The Chillout project, http://chillout.dmpf.org

48.  The Mozilla Public License Version 1.1, http://www.mozilla.org/MPL/MPL-1.1.html

49.  The Subversion project, http://subversion.tigris.org/

50.  The Chillout software repository, http://dmp.jdl.ac.cn/svn/chillout

51.  The Apache Maven project, http://maven.apache.org/

52.  The Maven Project Object Model, http://maven.apache.org/pom.html

53.  The Java SE Development Kit (JDK), http://java.sun.com/javase/downloads/index.jsp

54.  Java Media Framework API (JMF), http://java.sun.com/products/java-media/jmf/

55.  The Apache Tomcat project, http://tomcat.apache.org/index.html

56.  The Apache Ant project, http://ant.apache.org/

57.  Java Architecture for XML Binding, http://java.sun.com/webservices/jaxb/

58.  The JUnit testing framework, http://www.junit.org/index.htm

59.  The Apache Ant project, http://ant.apache.org/

60.  Apache Derby, http://db.apache.org/derby/