Last update: 2011/08/21
Looking inside the IDP specification.
The IDP specification is a set of 9 documents addressing many, but unfortunately not all, the areas envisaged by the Digital Media Manifesto.
Title |
Description |
| A collection of Primitive Functions derived from today’s media value-chains with corresponding Requirements. | |
| 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. | |
| A collection of technical specifications of basic Tools that are needed to implement Primitive Functions. | |
| 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. | |
| 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. | |
| 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. | |
| A software implementation of IDP Tools distributed, whenever possible, under the Mozilla Public Licence. | |
| 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 Approved Documents (AD) constituting the Interoperable DRM Platform specification will be provided.
AD #1 documents the requirements upon which the Interoperable DRM specification has been developed. To achieve this, DMP has invoked the following process open to any party:
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:
A typical Value-Chain has the following main components:
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 Fig. 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 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 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 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. This are Assigned by Agencies appointed according to a process specified by PDP-3. When Identifiers are Assigned appropriate Metadata are also typically generated. IDP-3.3 provides the following models
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.
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.
Fig. 3 - 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 ConformanceDMP 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:
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:
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:
For each TRU/DMBM supported the following is provided:
Below is a sample TRU handlingUse Case #1 – Quote TRUAn 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:
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
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
|
Represent Content |
2.1 |
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