|Value-Chain Functions and Requirements||A collection of Primitive Functions derived from today’s media value-chains with corresponding Requirements.|
|Architecture||A general architecture that describes some of the digital extensions of today’s media value-chains and collects the basic assumptions and technologies underlying the establishment of IDP-enabled Value-Chains.|
|Interoperable DRM Platform||A collection of technical specifications of basic Tools that are needed to implement Primitive Functions.|
|Use Cases and Value Chains||A collection of Use Cases along with normative specifications of examples of (portions of) Value-Chains implementing the Use Cases using the Tools drawn from the IDP Toolkit.|
|Certification and Registration Authorities||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.|
|Terminology||A set of terms and corresponding definitions that are used throughout the IDP and provided to overcome the problem of DRM being a field that impacts many other fields with their own established and sometimes conflicting terminologies.|
|Reference software||A software implementation of IDP Tools distributed, whenever possible, under the Mozilla Public Licence.|
|End-to-End Conformance||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.|
|Mapping of Traditional Rights and Usages to the digital space||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.|
In the following a summary description of the 9 ADs constituting the Interoperable DRM Platform specification will be provided.
AD #1 documents the requirements upon which the Interoperable DRM specification has been developed. DMP has followed a clear process, open to any party, to develop requirements:
- Ask a broad range of value-chain users (see below) to state their needs
- Derive Functions (i.e. what the platform should enable) from the stated needs
- Develop requirements for implementing Functions
- Identify prominent use cases used to derive and test requirements
- Issue Call for Proposals for technologies that 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:
- Civil Rights Associations
- Association of People with Special Needs
- Collective Management Societies
- Device Manufacturers
- Public Service Broadcasters
- Sheet Music Publishers
- Telecommunication operators
- Internet Service Providers.
The Architecture document provides an overview of the operation of a Value-Chain and of the technologies that enable it.
A typical Value-Chain has the following main components:
- Creation (including Adaptation)
- Content Provisioning
- Service Provisioning
Figure 1 – General schematic case of a Value-Chain
Value-Chains handle objects that represent IP Entities with Intellectual Property (IP) associated to them. In Figure 1 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.
For proper management in a Value-Chain it is useful to create combinations of different types of Resources with different types of Metadata and possibly other information types that DMP calls Content. DMP calls the digital Representation of Content, needed to Use Content on Devices, 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 (set of Devices or Users) 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 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 it is important to be able to convey in a DCI blocks of executable code (called DRM Tools) 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 is intended to provide such an 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.3. DMP appoints the Certification Authority after approving the Authority’s Certification policies. The figure below depicts this three-layer arrangement.
Fig. 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. These are Assigned by Agencies appointed according to a process specified by IDP-3.3. When Identifiers are Assigned appropriate Metadata are also typically generated.
IDP-3.3 provides the following models
- Creation Model identifying the major entities for which IP is attributed and describing their relationship to the digital objects involved in Content Creation;
- Distribution Model identifying and describing the role of the principal Value-Chain Users engaged in distribution;
- Delivery Model describing the two basic ways – File and Stream – in which Content can be Delivered between Devices;
- DRM Tool Model describing the general operation of DRM Tools in Devices;
- Domain Model describing the operation of Domains of Devices and Users;
- Device Model identifying and describing the principal Devices employed by Value-Chain Users;
- Import/Export Model describing how governed Content can be converted to Governed Content and vice versa;
- Data Model identifying and describing the different types of Data specified by DMP.
AD #3 of IDP-3.3 provides the key technologies that are required to implement the walkthrough above. These are grouped in 3 categories: Represent, Protocol and Package.
IDP-3.3 provides a standard Representation of a number of Elements:
- Represent Content
- Represent Metadata
- Represent DCI Signature
- Represent DCI Hash
- Represent Identifier
- Represent Resource
- Represent DRM Information
- Represent DRM Tool
- Represent DRM Tool Body
- Represent Rights Expressions
- Represent Rights Data
- Represent Keys
- Represent DRM Messages
- Represent Authentication Messages
- Represent Device Information
- Represent Domain
- Represent Domain Protocol
- Represent Use Data
- Represent Binary XML
- Represent Event Report
The Represent Content technology is the DMP Content Information (DCI) that is based on the MPEG-21 Digital Item. Figure 3 offer a pictorial representation
Figure 3 – The DMP Content Information
IDP-3.3 provides the following Protocols:
- Protocols to Identify Entities
- Protocols to Authenticate Entities
- Protocol to Access
- Protocols to Manage Domain
- Protocols to Manage DRM Tools
To deliver Content between Users it is necessary to Package Content in files or streams.
AD #4 of IDP-3.3 provides a number of Use Cases showing how the IDP-3.3 Tools can be used to build Value-Chains implementing them. The Value-Chains are normative. This does not mean that IDP-3.3 inhibits different assemblies of Tools for the same or similar purpose, but only that Users who implement the Use Case by assembling the Tools as specified in AD #4 will be able to interoperate with other Users who will assemble the Tools in a similar way.
Here is a brief description of some of the Use Cases considered.
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. Open Release was contributed to MPEG and became the Open Access Application Format (ISO/IEC 23000-7).
Controlled Peer-to-Peer Distribution: This Use Case shows how it is possible to use IDP-3.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.
Personal Photography: This Use Case shows how IDP-3.3 Tools can be used to enhance privacy in the specific case of distribution of personal photographs.
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 and Service Providers while not affecting the End User experience negatively.
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 an assurance for a Rights Holder to entrust his Content to a Device. Certification is carried out by a plurality of organisations dedicated to the task of Certifying Entities. To perform this task these organisations must be properly accredited by a root authority called Certification Authority. IDP-3.3 describes the process according to which DMP appoints a Certification Authority and oversees its operation. Further it provides the following elements
- Qualification Requirements for a Certification Authority
- Procedure to appoint a Certification Authority
- Responsibilities of a Certification Authority
- Responsibilities of Certification Agencies
The task of Identifying Entities such as Content, Devices and Domains is a critical one, e.g. in the case of Devices, where Identification constitutes a key element of Trust establishment. This Identification task is typically carried out by several organisations that are properly accredited by a root authority. While the operational details of Certification and Registration Authorities/Agencies are different, the process followed in appointing and supervising them is very similar.
AD #6 of IDP-3.3 provides a set of terms and corresponding definitions that are used throughout all 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.
AD #7 – 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 the goal of the Chillout project.
Chillout is organised in the following structure:
- Core library: library of classes implementing the Primitive functions defined in the Technical Specification. This software is normative as much as the Technical Specification
- 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.
- 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 Operating Systems.
Figure 4 – DMP Reference software layers in Chillout
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.
AD #8 – 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:
- Has a given Content or Device Entity been made correctly according to the Technical Specifications?
- 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 are in a position to:
- 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;
- Take an implementation of 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;
- 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;
In order to build Value-Chains that Users can entrust their assets to because they expect that they will be Used as mandated, 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.
AD #9 – Mapping of Traditional Rights and Usages to the Digital Space
The objective of AD #9 is to provide illustrative examples of:
- 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
- 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:
- A rationale for the TRU/DMBM
- One or more than one solution enabling support of the selected TRU/DMBM, each with
- A walkthrough complemented with the list of IDP Tools required
- Additional actions that may be required to enable TRU/DMBM support.
Below is a sample TRU handling Use Case #1 – Quote TRU. 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.
Tim wants to show 10 seconds from time code 1h 15m 25s of “My best quote of the year”, a movie that is only available as protected Content. Tim performs the following sequence of steps:
|Tim||Obtain||License||To quote 10 seconds of “My best quote of the year”||Negotiate License|
|Tim||Make||DCI||Using a Content Creation Device (CCD). The DCI includes
|Tim||Register||DCI||Protocol to Identify Content||3.1.2|
|Tim||Upload||DCI||To Content Provider Device||CCD-CPD Protocol||3.7|
|CPD||Make||DCF||Package Content as File||4.1.2|
There are several ways in which this TRU can be actually implemented. Here follows a non-exhaustive list
- 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
- 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
- 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
- A User may offer to send Quotes of the movie to a number of friends and be paid for the effort