A walkthrough in the DMP Phase II specification
Leonardo Chiariglione

 

Executive Summary

This document provides an overview of the DMP and of the Interoperable DRM Platform, Phase II (IDP-2), the second Technical Specification approved 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
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 Keys
5.1.12 Represent DRM Messages
5.1.13 Represent Authentication Messages
5.1.14 Represent Device Information
5.1.15 Represent Domain
5.1.16 Represent Domain Protocol
5.1.17 Represent Use Data
5.1.18 Represent Binary XML
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. The next steps
9.1 IDP-3 Call for Proposals
9.2 Other IDP ADs
10. Conclusions
11. 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. Purpose of this paper is to illustrate the goals of the DMP (chapter 2), the main features of the the second Technical Specification (IDP-2) approved by DMP in furtherance of the stated goals (chapters 3 to 8) and some related DMP activities (chapter 9).

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 an 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, DMP sees serious problems in the introduction of DRM technologies that are not 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, not to say to forecast what kind of standards will be needed in the future.

DMP approaches the problem of DRM Interoperability by specifying 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-2), 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. DMP has adopted the following rigorous process:

  1. Identify and document Use Cases deemed to be significant;
  2. Identified 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 Tool can be used in the selected Use Cases

In a subsequent phase, 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 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 in 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.
On the 5th of May 2005 DMP has published its 1st 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 9th of February 2006 DMP has approved its 2nd 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 will publish the IDP-2 documents in final form on the 15th of April 2006. The IDP-1 and IDP-2 specifications are tightly linked in the sense that the IDP-2 specification contains (i.e. is a superset of) the IDP-1 specification.

3. Value Chain Functions and Requirements

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 DeliveryProtocols (called Package by DMP)
Accordingly, 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

The Architecture provide 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 Expressions 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 makre 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 of 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 properly appointed and overseen by a single root authority (Certification Authority). 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. When Identifiers are Assigned appropriate Metadata are also typically generated.

4.3 Models

IDP-2 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 deficted 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 enables Delivery of a Content Item over a variety of specific Delivery mechanisms. IDP-2 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

IDP-2 provides general models for a number of Devices typical of some Value-Chain Users

#

Device Name

Acronym

1 Content Consumption Device PAV
2 Content Consumption Device SAV
3 Content Creation Device CCD
4 Content Identification Device CID
5 Content Provider Device CPD
6 Device Identification Device DeID
7 DRM Tool Identification Device TID
8 Domain Identification Device DoID
9 Domain Management Device DMD
10 DRM Tool Provider Device TPD
11 Licence Identification Device LID
12 Licence Provider Device LPD
13 PAV eXternal Device PXD

 Of particular interest are the following Devices

PAV eXternal Device (PXD)

As PAV Devices 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 a it from a Licence Provider Device, add the Licence to the DCI, make a DCF 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)

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

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-2 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 8 – DRM Tools and DRM Tool Packs executed by a DRM Processor

4.3.5 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 9 – An example of Domain

IDP-2 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-2 provides a rich set of data types. The figure below shows one example of Content and its Content Elements

Figure 10 – An example of DCI

5. Interoperable DRM Platform

IDP-2 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

This category comprises 3 Tools: Content, Keys and Rights Expressions.

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-2 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 ToolPack, 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-2 Represent License extends the MPEG-21 REL Dissemination and Capture (DAC) Profile [25], in order to support Domains.

5.1.11 Represent Keys

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

5.1.12 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.13 Represent Authentication Messages

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

5.1.14 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.15 Represent Domain

Represent Domain has a similar role as Represent Device Information.

5.1.16 Represent Domain Protocol

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

5.1.17 Represent Use Data

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

5.1.18 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.2 Protocols

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

5.2.1 Protocols to Identify Entities

IDP-2 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].

5.2.2 Protocols to Authenticate Entities

IDP-2 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 and an Identifier that is specific to the 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 11 - 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 – edit all this section like this.
  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.

An LPD may employ Content Group IDs in a License to manage the simultaneous usage of Content Items in a Content Grouping by the Devices or Users. 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 its own Context ID (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-2 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-2 provides Tools to Package Content in Files. The file contains the 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, which specifies the physical location in the file of a Resource described in the DCI.

This is represented in the figure below.

Figure 12 – 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-2 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 document, 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 the Figure below.

Figure 13: Streaming a DCI using Digital Item Streaming

6. Use Cases and Value-Chains

IDP-2 provides a number of Use Cases showing how the IDP-2 Tools can be used to build Value-Chains implementing them. The Value-Chains are normative. By giving a normative value to Value-Chains DMP does not imply that the Use Cases can only be implemented as specified in IDP-2. DMP simply intends to provide example implementations so that those Users who assemble the Tools as specified will be able to interoperate with other Users who will assemble the Tools in a similar way. Here is a brief introduction to the 7 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 enhanced services.

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 to disassociate distribution of Content using robust DRM technologies from a consumption model that easily maps to 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-2 technologies once DMP PAV Devices have been broadly deployed.

6.6 Controlled Peer-to-Peer Distribution

This Use Case shows how it is possible to use IDP-2 Tools and build a community sharing self-produced Content on a peer-to-peer network with other professional Content.

6. Smart Retailer

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

6.7 Personal Photography

This Use Case shows how IDP-2 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, 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 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 video Content carried by RTP/UDP/IP is considered.

7. Certification and Registration Authorities

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-2 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 their appointment and oversseing is very similar.

8. Terminology

IDP-2 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.

Adaptation

A Work that is derived from another Work  

Adaptor

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

Authenticate

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

Backup

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

Broadcast

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

Bundle

The Function of binding two sets of Data

Certification

The process whereby a Certification Agency issues a Certificate

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

Clear-text

Data that can be Processed as is by a Device

Condition

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

Conformance

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

Content

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

Creator

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

Credentials

Information describing the security attributes of an Entity

Data

Information converted to digital form

Decrypt

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

Delete

The Function of erasing a Content Item Stored on a Device

Deliver

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

Descriptor

Data that describe the properties of a Resource

Device

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

Domain

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

Edit

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

Encrypt

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

End-User

A User in a Value-Chain who ultimately consumes Content

Entity

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

Environment

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

Experience

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

Export

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

File

Content Entity which is Stored on a Device

Fixate

The Function of Storing a Manifestation of a Work

Footprint

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

Fragment

A time-marked portion within a Resource

Function

Any action implemented with DMP-specified technologies

Governed Content

A Content Item that is at least Identified

Grant

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

Identify

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

Identifier

The unique signifier Assigned by Identification

Import

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

Instance

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

Instantiator

A User who produces an Instance

Integrity

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

Interface

The Data interchange point between

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

Interoperability

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

Jurisdiction

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

Key

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

Lend

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

License

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

Licence

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

Licensee

The User to whom another User Grants Rights

Licensor

The User who Grants Rights to another User

Link

The establishment of a relationship between two Fragments

Manifestation

An object or event which is an expression of a Work

Metadata

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

Parse

The Function of looking for useful Data in Data

Pause

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

Performer

A type of Instantiator

Permission

The ability to execute Functions on a Content Item

Platform

The technology infrastructure that enables Users to Use Content

Play

The Function of Rendering a Resource

Policy

A principle accepted by a group of Users

Primitive Function

 A Function typically embedded in more than one Function

Principal

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

Process

The Function of transforming Data executed by a Device

Protocol

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

Publish

The Function of making Content available to other Users

Publisher

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

Quote

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

Register

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

Release

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

Render

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

Rent

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

Represent

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

Resource

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.

Restore

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

Retailer

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

Revoke

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

Rewind

The Function of restarting the Rendering of a Resource

Right

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

Schema

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

Secure Authenticated Channel (SAC)

A Delivery System that is secure and Encrypted

Service

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

Signature

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.

Store

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

Stream

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

Synchronise

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

Syndicate

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

Territory

The geographical area under the Jurisdiction of a sovereign state

Tool

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

Trust

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

Use

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

User

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

Value-Chain

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

Value-Expression

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

Verify

The Function of assessing the Integrity of

  1. A Content Item
  2. A Device

Withdraw

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

Work

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

9. The next steps

IDP-2 is the second release of the Interoperable DRM Platform. The set of technologies assembled and their integration has been a major task and a broad range of opportunities for Value-Chain Users is opened by IDP-2. However the work is not finished as will be shown below.

9.1 IDP-3 Call for Proposals

GA09 has issued a Call for Proposals for General DRM Technologies for Digital Media Value Chains. Submissions should be made by the 20th of April 2006. Below is a list of technologies requested.

Represent

Protocols

Miscellanea

9.2 Other IDP ADs

In addition DMP is currently developing the following ADs:

  1. AD #7 – Reference Software [7]: a software implementation of IDP Tools. DMP strives to provide the reference software as Open Source, with a license aligned to established practices. When this is not possible DMP provides the reference software with a “modify, use and distribute” license.
  2. 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.
  3. AD #9 – Mapping of Traditional Rights and Usages to the Digital Space [9]: a set of example support of 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.

10. Conclusions

IDP-2 is the result of an effort that has lasted 2.5 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 have produced IDP-1 (April 2005). IDP-2 started in January 2006 with the IDP-2 Call for Proposals and the specifications were approved in February 2006. Responses to the IDP-2 Call for Proposals are due in April 2006 and the IDP-3 specification is planned to be 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 is producing DRM standards 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

11. 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 (MPEG-2) — 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 (MPEG-4) – 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-5, Information technology – Multimedia content description interface (MPEG-7) – Part 5: Multimedia Description Schemes
  17. ISO/IEC 15938-9, Information technology — Multimedia content description interface — Part 9: Profiles and levels
  18. ISO/IEC 15938-10, Information technology – Multimedia content description interface (MPEG-7) – Part 10: Schema Definition
  19. ISO/IEC 15938-11, Information technology — Multimedia content description interface — Part 11: MPEG-7 Profile Schemas
  20. ISO/IEC 21000-2, Information technology – Multimedia framework (MPEG-21) – Part 2: Digital Item Declaration
  21. ISO/IEC 21000-3, Information technology – Multimedia framework (MPEG-21) – Part 3: Digital Item Identification
  22. ISO/IEC 21000-4, Information technology – Multimedia framework (MPEG-21) – Part 4: IPMP Components
  23. ISO/IEC 21000-5, Information technology – Multimedia framework (MPEG-21) – Part 5: Rights Expression Language
  24. ISO/IEC 21000-7, Information technology – Multimedia framework (MPEG-21) – Part 7: Digital Item Adaptation
  25. ISO/IEC 21000-9, Information technology – Multimedia framework (MPEG-21) – Part 9: File format
  26. ISO/IEC 21000-18, Information technology – Multimedia framework (MPEG-21) – Part 18: Digital Item Streaming
  27. ISO/IEC 23001-1, Information technology – MPEG Systems Technologies (MPEG-B) – Part 1: Binary MPEG format for XML
  28. ITU-T Recommendation X.509 | ISO/IEC 9594-8 Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks, March 2000
  29. European Telecommunication Standard TS 102 822 – 3-1 Part 3: Metadata; Sub-part 1: Metadata schemas
  30. IETF RFC 1737, K. Sollins and L. Masinter, Functional Requirements for Uniform Resource Names, December 1994.
  31. IETF RFC 2045, N. Freed and N. Borenstein, Multipurpose Internet Mail Extensions, November 1996
  32. IETF RFC 2141 R. Moats, URN Syntax, May 1997
  33. 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, June 1999
  34. W3C Recommendation, “XML-Encryption Syntax and Processing”, 10 December 2002. http://www.w3.org/TR/xmlenc-core/. [FC] is this reference still needed?
  35. W3C Recommendation, “XML-Signature Syntax and Processing”, 12 February 2002. http://www.w3.org/TR/xmldsig-core/
  36. W3C Recommendation, “XML SchemaXML Schema Part 1: Structures, Second Edition, 28 October 2004”, http://www.w3.org/2001/XMLSchema