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

Executive Summary

Table of Contents

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.

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).

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.

• On the 5^th of May 2005 DMP has published its 1^st IDP specification (IDP-1), designed to enable the implementation of digital media services based on Portable (i.e. without network and broadcast access) Audio and Video (PAV) Devices.
• On the 9^th of February 2006 DMP has approved its 2^nd IDP specification (IDP-2), designed to enable the implementation of digital media services based on Stationary (i.e. with network and broadcast access) Audio and Video (PAV) Devices. DMP has published the IDP-2 documents in final form on the 15^th of April 2006.
• On the 20^th of July 2007 DMP has approved version 3.0 of the IDP specification significantly expanding technology support and adding new parts

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

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.

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

1. Process
2. Test Conformance
3. Certify

4. Architecture

4.1 Value-Chain

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

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

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

5.1 Represent

5.1.1 Represent Content

Represent Content provides the means to:

• Convey Identifiers of Content and Content Elements
• Associate DMP-specific information and Metadata with Content and Content Elements
• Associate DRM Information with Content and Content Elements including
  • DRM Tools
  • Licenses
  • Device Information
  • Key
• Associate digital signatures with the DCI
• Associate hash values with the DCI

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

5.1.4 Represent DCI Hash

5.1.5 Represent Identifier

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:

• To Grant the Right to Use Content (e.g. Device D can Play Content Item X five times)
• To attribute properties to a Principal (e.g. Device D belongs to Domain B)
• To Govern the Use of DRM Tools (DRM Tool T can only work on Devices Certified by Agency A)

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:

• Time-independent Keys, i.e. keys that do not need to be synchronised to the Content Delivery
• Time-dependent Keys, i.e. keys that are synchronised to timely packet delivery, for instance for the timely decoding of streamed content.

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

• The usage of a Digital Item by a Device, e.g. the rendering of Resources associated with a Digital Item
• The occurrence of Events related to the Device itself, e.g. when a Device connects to another Device.

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

• Event Report Request (ERR)
• Event Report (ER).

An ERR is used to specify:

• Conditions that must be fulfilled in order for the reportable Event to “occur”;
• The syntax/format of the information contained within an Event Report (ER) that is to be reported when the reportable Event occurs;
• The intended recipient(s) of the Event Report (Devices or Users that need to be notified when the reportable Event occurs);
• Parameters related to delivery of the Event Report (e.g. transport mechanism and protocol, delivery timing constraints, priority, etc.).

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:

• An Event Report Request (ERR) is delivered to a Device;
• The ERR is parsed;
• The Device waits for Events to occur;
• Events that have occurred are trapped by the Event Watchdog;
• the Event Watchdog checks to see if the Events need to be reported on, according to the ERR’s that the Device has received;
• When all of the Event conditions associated with an ERR have been fulfilled, the Device proceeds to construct an ER containing the data fields specified in the ERR;
• The Device dispatches the resulting ER towards the recipient Device(s) specified by the ERR.

5.2 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:

• Setting up a Domain described by Domain Information
• Creating Domain Contexts for Devices and Users
• Managing membership of Device and User in a Domain, i.e. joining, renewing and leaving
• Controlling the Use of Content within the Domain.

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

5.3.1 Package Content as File

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

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

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

6.7 Personal Photography

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

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

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.

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.
 
Chillout 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:

• Represent: a set of classes to generate and parse the XML structures defined by the DMP Technical Specifications;

• Package: a set of classes to generate and parse the DCF and DCS;

• Protocols: a set of classes to generate and parse the messages exchanged by two Devices performing the Protocols, and providing the functionality to send and receive such messages

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;

• Security manager: module incorporating all those functionalities such as secure storage of digital Certificates and Licenses, performing signature operations, etc...

• DRM Processor: module parsing the DRM Information in a DCI, instantiating and managing the required DRM Tools, etc...

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: 

• chillout_auxiliary: library of classes encapsulating the functionalities that every device must have when operating in a real environment. This library is not normative, as these modules may be replaced by those a developer needs.

• chillout_ccd: The Content Creation Device is an application allowing a User (e.g. an author) to create Content: the DCI and the DCF.

• chillout_cid: The Content Identification Device is a server application issuing identifiers to new content items created by a SAV or a CCD

• chillout_core: library providing the functionalities needed to Represent (a set of classes to generate and parse the XML structures defined by IDP), to Package (a set of classes to generate and parse the DMP Content File and Streaming formats) and to perform the Protocols (a set of classes to generate and parse the messages exchanged by two devices performing the Protocols)

• chillout_cpd: The Content Provider Device is a server application allowing Content creators/distributors/publishers to make available their Content via a streaming protocol or downloaded as a file.

• chillout_did: The Device Identification Device is a server application providing Digital Certificates to other Devices upon request.

• chillout_dmd: The Domain Management Device is a server application allowing, among the other functionalities, Domain Administrators to create Domains where Governed and un-Governed Content can be Accessed by any Device or User part of them, and Devices and Users to subscribe to them

• chillout_lpd: The License Provider Device is a server application issuing Licences to Devices or Users, Granting them the Right to use Content.

• chillout_sav: The Stationary Audio and Video Device is an application capable of playing audio-visual Governed and un-Governed Content either stored in files or streamed over network Protocols. By means of a browser integrated in the application, users can browse a Content Provider Devices' portal to select content for real time streaming or file download.

• chillout_tpd: The DRM Tool Provider Device is a server application providing DRM Tool Bodies (modules performing DRM functions such as Decryption, watermarking, etc.) to a SAV or a CCD upon request.

• maven-plugins: A folder containing source code not developed by Chillout which is needed for the correct installation of the Chillout software

• mpegtools: A folder containing MPEG reference software which is used by Chillout code, among which the Digital Item Streaming [29] reference software.

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:

• JDK 5.0 or above

• A Subversion client

• Apache Maven

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:

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

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".

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/