1 Value Chain Functions and Requirements

1.1 Introduction

DMP is developing a series of specifications for Interoperable DRM called Interoperable DRM Platform (IDP) where each phase of the IDP specifications is indicated by a sequential number. The open IDP specifications enable Users to technically execute Functions using standard Protocols through standard Interfaces with predictable results.

Because there is such a broad variety of value-chains there can hardly be a “universal DRM system” to develop specifications for. Therefore it is expected that there will be a range of “implementations” of DRM systems designed to satisfy the needs of specific value-chain users. The DMP specifications can be used to realise the digital equivalent of the media value-chains that exist today, but also to make value-chains that have no obvious equivalent with today’s value-chains.

This unpredictable environment requires a different type of standardisation than used for other standardisation efforts, e.g. video coding, that typically apply to well-defined environments. The DMP approach is based on protocols for lower-level functions (called Primitive Functions) between value-chain users. If Primitive Functions are well defined existing and possibly new Functions can be built as combinations of Primitive Functions. In the future new Functions could also be built using existing and new Primitive Functions.

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

1. Ask a broad range of value-chain users to state their needs

2. Derive Functions from the stated needs

3. Develop requirements for implementing Functions

4. Identify prominent use cases used to focus the development of specifications

5. Issue Call for Proposals for technologies to implement Functions.

All documents produced at each of these steps have been made publicly available for comments on the DMP web site at http://www.digital-media-project.org/.

So far representatives of the following value-chain users have contributed to the process:

1. Civil Rights Associations

2. Association of People with Special Needs

3. Collective Management Societies

4. Device Manufacturers

5. Individuals

6. Producers

7. Public Service Broadcasters

8. Sheet Music Publishers

9. Telecommunication operators.

This document is work in progress as it is the starting point for the series of interoperable DRM specifications that DMP plans to develop. Those wishing to comment on or contribute to future versions of this Approved Document No. 1 are requested to forward their submissions to Marc Gauvin (mgauvin@sdae.net). Submissions are typically discussed within the Ad hoc Group on Requirements for Interoperable DRM Platform, whose email reflector is idp-ied-rq@dmpf.org. To subscribe to the email reflector follow the instructions.

This Approved Document No. 1 contains

1. The list of Value-Chain Users identified so far by DMP, and whose requirements the DMP expects to support (Chapter 2)

2. The list of General Requirements underpinning the DMP process (Chapter 3)

3. The table a Primitive Functions identified with indication of which IDP Phase supports the given Primitive Function (Chapter 4)

4. The full list of Functional Requirements of Primitive Functions (Chapter 5).

1.2 Value-Chain Users

#	Value-Chain User	Acr.	Definition
1.	Creator	CRE	A User who creates a Work and generates its first Manifestation
2.	Performer	PRF	A User who interprets a Manifestation of a Work making an Instance
3.	Registration Authority	RAU	A User managing Identifier name spaces, and appointing and overseeing Registration Agencies
4.	Registration Agency	RAG	A User appointed by a Registration Authority to Assign Identifiers
5.	Collective Management Society	CMS	A User who provides collective representation to its members, e.g. Authors, Performers, Publishers etc.
6.	Producer	PRD	A User who produces Content
7.	Publisher	PBL	A User who selects Content and makes it available to other Users
8.	Syndicator	SND	A User who manages and places Content to Retailers using a variety of purchasing options
9.	Metadata Resolution provider	MRP	A User who resolves, i.e. maps between disparate sets of Metadata
10.	Repository	RPS	A User who offers Services to long-term Store, Identify, describe, locate, Access, manage, and Validate Content and its Metadata
11.	Monitoring Service provider	MNP	A User who processes Use Data to provide information
12.	Marketer	MKT	A User who provides promotional, sale enhancement, brand enhancement and merchandising Services
13.	Aggregator	AGG	A User who provides procuring, packaging, presenting, cataloguing, archiving and indexing Services typically to Retailers
14.	Retailer	RTL	A User who sells or Licenses Content to an End-user
15.	Technology provider	TCP	A User who provides technology to make Devices
16.	Technology licensing provider	TLP	A User who provides Device Manufacturers with a license to utilise patented technology to make Devices
17.	Device Manufacturer	DVM	A User who manufactures or assembles hardware and/or software components to make Devices
18.	Connectivity provider	CNP	A User who provides point-to-point or point-to-multipoint connectivity between Users
19.	Network Service provider	NTP	A User who provides Internet Protocol (or equivalent) services and typically various other services above it, e.g. quality of service
20.	Tool provider	TOP	A User who sells or Licenses Tools to Users
21.	Certificate Authority	CRA	A User who issues digital Certificates used to create digital Signatures and public-private Keys
22.	Certification Authority	CAU	A User appointing and overseeing Certification Agencies
23.	Certification Agency	CAG	A User appointed by a Certification Authority to Certify Devices or DRM Tools
24.	Clearing House	CLH	A User who collects Value Expressions from other Users to distribute to Right Holders for the purchase of Use Rights over a given instance of Content
25.	Payment Service provider	PSP	A User who provides the infrastructure for financial transactions
26.	End-User	ENU	The last User in a Value-Chain
27.	Reseller	RSL	A User who possesses the Right to control the disposition and transfer of Content from End-users to different End-users
28.	Public Authority	PBA	A User who provides rules relating to the Use of Content and taxation on transactions related to Content.

1.3 General requirements

1.	The IDP shall be a “tool-kit” specification
2.	The IDP shall evolve in phases, each phase introducing new Tools keeping compatibility with the Tools of preceding phases
3.	The IDP shall be open to support all legitimate needs by · Value-Chain Users · Associations of People with Special Needs
4.	The IDP shall support Rights inheritance, i.e. that the set of Rights acquired by a given Value-Chain User is subject to the set of Rights that was available to the Value-Chain User granting the Rights
5.	The IDP shall support the ability of a given Value-Chain User to mask the Value-Chain Users supplying Services to it in support of the Services that it provides to its clients
6.	Licensing of technologies required to implement IDP tools shall be RAND and preferably royalty-free
7.	The IDP shall be designed in such a way that its use shall have a minimal impact on Users, ideally that its use should be transparent
8.	The IDP Tools must satisfy the relevant requirements expressed in this document
9.	All Entities must be capable of being uniquely and unambiguously Identified
10.	Information about Devices and Domains shall be restricted to the minimum required for these to operate in the DMP Environment
11.	The IDP shall specify technologies that are native to it (e.g. the Rights Expression Language) and supported by implementations claiming conformance with IDP. DMP recognises that there may be implementations that replace the native IDP technologies with others that have the same functionality. However, no support for conformance testing to such implementations will be provided by DMP.

1.4 Primitive Functions

The following table provides the current list of Primitive Functions grouped in categories. For each Primitive Function a cross in any of the last two right columns indicates whether or not it is currently specified and if so in which version of the Interoperable DRM Platform (AD #3). An X in both columns means that technology is provided by IDP-2 that adds to the technology already provided by IDP-1.

Table 1 – Primitive Functions

Category	Primitive Function	IDP#1	IDP#2	V.2.1	V.3.0
Represent
	Represent Identifier of Content	X
	Represent Identifier of Device	X
	Represent Identifier of User		X
	Represent Identifier of Domain	X
	Represent Identifier of DRM Tool		X
	Represent Identifier of Footprint
	Represent Identifier of Class of Users
	Represent Identifier of Territory
	Represent Identifier of Jurisdiction
	Represent Content	X	X
	Represent Resource		X
	Represent Metadata		X
	Represent DRM information		X
	Represent DRM Tool Body		X
	Represent DRM Tool		X
	Represent Rights Expression	X	X
	Represent Rights Data			X
	Represent Key Body		X
	Represent Key	X	X
	Represent Device Information		X		X
	Represent Domain Information		X
	Represent Use Data	X
	Represent Value Chain
	Represent Resource Format
	Represent Binarised XML	X
Identify
	Identify Content			X
	Identify IP Class			X
	Identify Metadata
	Identify Device	X
	Identify Domain		X
	Identify Role
	Identify User
Recognize
	Recognize Items			X
	Recognize Roles			X
Revoke
	Revoke Content
	Revoke Content Element
	Revoke Device
	Revoke Domain
	Revoke User
Authenticate
	Authenticate Content			X
	Authenticate Device	X
	Authenticate DRM Tool		X
	Authenticate User
Verify
	Verify Content
	Verify Device
Negotiate
	Negotiate Licence
	Negotiate Use Data
	Negotiate Licence and Use Data
Report
	Report Use Data				X
Deliver
	Store				X
	Copy
	Move
	Backup
	Export
	Access	X	X
	Restore
	Import
	Update
	Inter-Device communication				X
Manage
	Manage Domain	X	X
	Manage DRM Tool		X
Package
	Package as File	X
	Package as Broadcast		X
	Package as Streaming		X
Process
	Encrypt/Decrypt	X
Transact
Test Conformance
	Test Conformance of Rights Expressions
	Test Conformance of Enforcing Rights Expressions
	Test Conformance of Tamper resistance
Certify
	Certify Content
	Certify Device
	Certify User

1.5 Functional requirements

1.5.1 Represent

1.5.1.1 Represent Identifier of Content

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of Content so that it can be Processed by a Device
Objective	To enable accurate Governance of a Content Item
Requirements	1. Ability to provide unique and unambiguous identification of a Content Item 2. Ability to support versioning 3. Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete 4. Ability to Identify Content by different Users to enable tracing the origin of Content when Licensed to other Users 5. Ability to Identify a Content Item for Use only within a specific Device or a Domain (e.g. a Broadcast Footprint, a company, a home)
Benefits	1. Flexible distribution schemes where different Content Elements may be supplied by different Providers 2. A given Content Element may be referenced in multiple parts of a Content Item 3. Multiple Content Items can refer to the same Content Element 4. Fine granularity of Rights Expressions.

1.5.1.2 Represent Identifier of Device

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of a Device employed in a particular instance of Use so that it can be Processed by a Device
Objective	To enable various Device-related Functions such as · To support the association of a piece of Governed Content with a Device · To support Trust management
Requirements	· Ability to work in conjunction with existing industry schemes to administer customer/device-specific uses · Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete · Ability to obtain Device capability information by reading the Device Identifier · Ability to support requirements for Domain Management
Benefits	· Allows reliable administration of Device-based Uses · Compatible with replacement strategies in cases where a Device is destroyed or otherwise replaced, or else used only for a period of time after which a different Device will be used.

1.5.1.3 Represent Identifier of User

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of a User in a particular instance of Use so that it can be Processed by a Device
Objective	To enable various User-related Functions such as License Content to an Identified User
Requirements	· Ability to support User Authentication · Ability to support Identification of any Value-Chain User · Ability to accommodate a variety of models for human interaction with Devices e.g.: o Allow a single User to use multiple Devices, o Allow multiple Users to share a single Device, o Allow the use of a confidential identity (e.g. prepaid card) · Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete · Ability to access information related to the User that may be legally required for the provision of Content
Benefits	Depending on a given device's design, allows one User to employ multiple devices or allows multiple Users to use a single device

1.5.1.4 Represent Identifier of Domain

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of Domain so that it can be Processed by a Device
Objective	To enable Value-Chain Users to License Content to Identified groupings of Users and/or Devices
Requirements	· Ability to support the following types of Domains o Device-based o User-based o Location-based (e.g. DHCP) o Mixed Device, User and Location-based o Context-based § By reference to a legally established class of special users (e.g. students, people with special needs) · Ability to support a hierarchy of Domains
Benefits	Enable more Uses of Content by Identifying groupings of Users and/or Devices instead of just individual Users or Devices

1.5.1.5 Represent Identifier of DRM Tool

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of executable code or hardware device that implements one or more DRM Functions on a Device so that it can be Processed by a Device
Objective	To facilitate Authentication of DRM Tools
Requirements	Ability to Identify individual DRM Tools Ability to Identify groups of DRM Tools as an Entity (Tool Group) Ability to Identify complete DRM Systems (Tool Packs)
Benefits	· To obtain and classify DRM Tools · To Authenticate DRM Tools

1.5.1.6 Represent Identifier of Footprint

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of a primary broadcast distribution area so that it can be Processed by a Device
Objective	To enable Devices to Use Content intended for a particular Footprint
Requirements	Unique and unambiguous identification of a particular Footprint
Benefits	Enable Usage of Content within a particular Footprint

1.5.1.7 Represent Identifier of Class of Users

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of a particular class of Users so that it can be Processed by a Device
Objective	To enable Devices to Use Content intended for a particular class of Users
Requirements	Unique and unambiguous identification of a particular class of Users
Benefits	Enable Usage of Content within a particular class of Users

1.5.1.8 Represent Identifier of Territory

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of a particular geographical area so that it can be Processed by a Device
Objective	To enable Devices to Use Content intended for a particular Territory
Requirements	Unique and unambiguous identification of a particular Territory
Benefits	Enable Usage of Content within a particular Territory

1.5.1.9 Represent Identifier of Jurisdiction

	Detailed description of Requirements
Definition	The syntax of the information used to describe the identity of a particular Jurisdiction so that it can be Processed by a Device
Objective	To enable Devices to Use Content intended for a particular Jurisdiction
Requirements	Unique and unambiguous identification of a particular Jurisdiction
Benefits	Enable Usage of Content within a particular Jurisdiction

1.5.1.10 Represent Content

	Detailed description of Requirements
Definition	The syntax of the information used to describe the organisation and association of Content and Content Elements so that it can be Processed by a Device
Objective	To enable a predictable processing of Content and Content Elements according to the purposes of the Content Item design, i.e. to Represent the Governed Use of Work, Manifestation, Instance, Production, DRM Tool etc.
Requirements	· Ability to provide persistent association of Identifiers to Content and Content Elements · Ability to include Clear-text and Encrypted Identifiers, Content and Content Elements in a Content Item · Ability to apply Licenses to different Content Elements in a Content Item · Ability to Use individual Content Elements in a Content Item · Ability to associate to a Content Item Content Elements Stored at locations remote from each other · Ability to support temporary and permanent unavailability of Content Elements · Ability to Represent Content in a Delivery-System agnostic format · Ability to convey information related to § Key management § Encryption methods § Watermarking § Etc. · Ability of a Content Item to contain another Content Item
Benefits	· Standard format to securely communicate Resources and Governance information for Use · Multiple Uses of the same Resources (e.g. possibility to create multiple play lists) · Different Licenses for the same Content and/or Content Elements · Easy navigation · Easy repurposing

1.5.1.11 Represent Resource

	Detailed description of Requirements
Definition	The syntax of the information used to describe the format of a Resource so that it can be Processed by a Device
Objective	To enable a Device to interpret the Representation so that the Resource can be Used
Requirements	· To be as simple as possible · To be as expressive as required
Benefits	Use of Resources by Devices

1.5.1.12 Represent Metadata

	Detailed description of Requirements
Definition	The syntax of the information used to describe features and attributes associated with Content and Content Elements or Devices so that it can be Processed by a Device
Objective	· Facilitate interaction between Users for a plurality of purposes, e.g. o Classification o Description o Search and retrieval o Presentation o Etc. · Enable best Use of Content on Devices
Requirements	· Ability to support existing Metadata standards · Ability to signal the standard in use · Ability to employ a minimal Metadata standard set for End Users · Ability to describe Device features and capabilities
Benefits	Allow for an effective interchange of Content between Users and optimal Use of Content and Devices

1.5.1.13 Represent DRM Information

	Detailed description of Requirements
Definition	The syntax of the information used to describe Governance of Content so that it can be Processed by a Device
Objective	To enable a Device to interpret the information so that Content can be Used as determined by its Governance
Requirements	Ability to represent · DRM Tools required to Access Content · Initialisation and configuration data for DRM Tools · Decryption Keys · Information related to DRM Tool Management · Placeholders for Licenses
Benefits	Enable Content Governance by Devices

1.5.1.14 Represent DRM Tool Body

	Detailed description of Requirements
Definition	The syntax of the specific information used to describe DRM Tool embodiments used so that they can be Processed by a Device
Objective	To enable a Device to execute DRM Functions specific of a given Content Item
Requirements	· Ability to Represent a single Tool Body · Ability to Represent a Tool Pack Body
Benefits	Extend the number and scope of DRM Functions that a Device can execute

1.5.1.15 Represent DRM Tool

	Detailed description of Requirements
Definition	The syntax of the specific information used to describe the environment in which DRM Tools will operate so that they can be Processed by a Device
Objective	To provide the Device with the means to perform the required DRM functionality
Requirements	The Representation shall include: · Tool ID · DRM Processor type, including o Vendor o Model o Serial number · Target OS including o Vendor o Model o Serial number o Version o Virtual machine · CPU o Vendor o Model o Speed · Memory o Vendor o Model o Speed o Size · Auxiliary hardware o Smart card o Hard Key · Network · Downloading · RPC mechanism · Firmware · Tool API configuration o Instantiation API ID o Messaging API ID · Target HW · Format e.g. zip · Tool source · Authentication parameters · Update schedule info · Tool Validation info · License info · Others
Benefits	Upgradeable Device capable of executing multiple DRM functionalities

1.5.1.16 Represent Rights Expression

	Detailed description of Requirements
Definition	The syntax of the information used to describe Permissions and Conditions so that it can be Processed by a Device
Objective	To allow conditional Use of Content, based on the Conditions being satisfied or fulfilled
Requirements	· Ability to interpret a Rights Expression o Without a return channel o With low payload o On a wide array of Device sophistication · Ability to unambiguously Identify o The User granting the Permission o The Device, User or Domain obtaining the Permission o The Content and Content Elements to which the Rights Expression refers · Ability to utilise (Rights data dictionary) o A User selectable Rights data dictionary o A minimal default Rights data dictionary · Ability to Represent (Permission sets) o Different subsets of Permissions o New Permissions when the need occurs · Ability to Represent (specific Permissions to Content) o Conditional expiry (e.g. Content may no longer be Used if Stored for longer than a determined period without Use) o One Rights Expression to many Content Elements o Many Rights Expressions each referring to a different Content Element § In particular a Content Item can have no Rights Expression (i.e. a Device can Use the Content without limits) o Content Uses e.g. § Period of time (e.g. play as long as the play time is greater than specified time and less than a specified time) and based on time/date § Count based (play up to a specified number of times) § User based § Device based § Domain based § Location based o Rights Expressions with Context Use limitations, e.g. age of End-User · Ability to support Delivery by: o Streaming o Broadcast o File download o Physical media · Ability to support (Conditions) o Territories o Jurisdictions o Footprints o Domains o Devices o Users o IP Entities · Ability to support (Functions) o Not to Encrypt clear-text Resources o Quote o Time-shifted Use o Annotation o Trick modes o Move/Copy § Between Devices § Within Domain § Within Footprint o Export to a movable media · Ability to support (Content types) o Reference to different IP Entities o Addition of Metadata o Use of the following types of Resources: audio, video, images, text and executables and groups/bundles thereof o Access of Content based on Rating (e.g. suitability for age) o Rights to segments of Content o Many Rights Expressions each referring to particular Content Elements of a Content Item · Ability to support (Rights of Users) o Ability to represent the sets of Rights pertaining to all Users e.g. Authors, Performers, Producers, Aggregators, Distributors, etc. o The Right of a User to License another User o Restriction to a class of Users o Multiple Licensors · Ability to support dynamic creation of Rights Expressions as a result of interaction between Users · Ability to support Creative Commons licenses
Benefits	Potentially allow the full range of human contractual agreements to be embodied in the digital domain, especially including automatic processing of agreements that are stated in rigorous forms

1.5.1.17 Represent Rights Data

	Detailed description of Requirements
Definition	The semantics of the data used in Permission and Conditions so that they can be interpreted by a Device in a predictable way
Objective	To enable a device to perform the Functions in an agreed and predictable way
Requirements	· The RRD will maintain a basic core set of terms for o IP Entities o Actions o Rights o Roles · The RRD will support a number of extensions created as the need arises · The RRD extension will be consistent with the core · To support the following IP Entities o Work o Adaptation o Manifestation o Instance o Work Instance o Adaptation Instance o Work Manifestation Copy o Work Instance Copy o Adaptation Manifestation Copy o Adaptation Instance Copy o Product · To support the following Actions o Create Work o Make Manifestation o Make Work Manifestation o Make Adaptation Manifestation o Make Instance o Make Work Instance o Make Adaptation Instance o Make Copy o Make Adaptation Instance Copy o Make Adaptation Manifestation Copy o Make Work Instance Copy o Make Work Manifestation Copy o Play o Copy · To support a subset (to be defined) of the following REL Rights: o Adapt o Delete o Delist o Diminish o Embed o Enhance o Enlarge o Enlist o Execute o Export o GovernedAdapt o GovernedCopy o GovernedMove o Install o Modify o Move o Play o Print o Reduce o Uninstall · To support the following Roles o Creator o Adaptor o Instantiator o Producer o Distrubutor o End User · RRD shall support the execution of Functions, some of which may be derived from the terms in the list above or be included as new terms o Adapt (Resource) § Conversion of compression method § Video resolution § Sampling frequency o Backup o Copy o Edit o Encrypt o Export o Import o Move o Quote o Restore o Space-shifted Use o Store o Synchronise o Time-shifted Use o Transfer to an external rendering device o Etc. · It must be machine readable · It must convey a strict correspondence between machine and human based interpretation and understanding · It must be represent a wide array of Users through adoption of one or more Roles · It must describe a complete array of Actions that Users can perform on or with IP Entities. · It must be capable of discerning between Roles on the basis of different combinations of Actions and IP Entity relationships · It must be capable of associating Rights with Actions and Roles. · It must be capable of describing the transfer of Rights throughout the Value Chain · It must be able to associate which IP Entities are required by Actions and which if any are produced by Actions.
Benefits	· Users have assurance that Devices behave predictably. · Essential input for conformance testing.

1.5.1.18 Represent Key

	Detailed description of Requirements
Definition	The syntax of the information used to describe Keys and associated parameters so that it can be Processed by a Device
Objective	To provide a Device with the necessary information to utilize a Key
Requirements	· Ability to represent o Time dependent/independent Keys o Association of Keys to particular time segment of a Resource o Key type and related data (e.g. Authentication, Certificates, etc.) o Set of Key types
Benefits	The ability to use multiple Keys and Key Management schemes

1.5.1.19 Represent Device Information

	Detailed description of Requirements
Definition	The syntax of the information used to describe the capabilities of a Device to perform Functions so that it can be Processed by a Device
Objective	To describe the capability of a Device
Requirements	· To identify Device capabilities, e.g. o Capability to Process (e.g. Render) certain Resource Types o Capability to determine the applicability of certain Rights Expressions o etc.
Benefits	The ability to Access Content that is suitable for the Device

1.5.1.20 Represent Domain Information

	Detailed description of Requirements
Definition	The syntax of the information used to describe the attributes of a Domain so that it can be Processed by a Device
Objective	To describe the minimum set of attributes of a Domain that is required to License Content for that Domain
Requirements	· The Representation shall include o Information about when the Domain was created o Domain Identifier o Domain Public and Private Keys o Domain Administrator’s name and password o List of Devices/Users in the Domain o Maximum number of Devices/Users o List of Revoked Devices/Users o Expiration date of Domain · The Representation may optionally include o Type of Devices o Maximum frequency of Devices/Users leaving and joining
Benefits	· For the Content Provider the ability to determine proper Licensing of its Content · For the End-User the ability to obtain Content for Use within his Domain

1.5.1.21 Represent Use Data

	Detailed description of Requirements
Definition	The syntax of the information used to describe the elements making up one or more instance of Use of Content, Device or User so that it can be Processed by a Device
Objective	To enable processing of Use Data in a predictable fashion
Requirements	· Ability to Identify Use Data · Ability to support protection of Use Data · Ability to convert Use Data to a human readable form · Ability to not Identify User or Device associated with Use Data · Ability to Represent a wide range of Content Uses e.g. time of Use, combinations of Content Items, Domains, Superdistribution Uses
Benefits	Provide a machine-processable record of Uses

1.5.1.22 Represent Value Chains

	Detailed description of Requirements
Definition	The syntax of the information used to describe Value Chains
Objective	To digitally represent Value Chains
Requirements	· Ability to represent the actions of the Users · Ability to represent the relationships of the Users
Benefits	To enable the unambiguous replication of Value Chains

1.5.1.23 Represent Resource Format

	Detailed description of Requirements
Definition	The syntax of the information used to describe the format of Resources so that it can be Processed by a Device
Objective	To provide the means to Access Content containing suitable Resources for the Device
Requirements	· The ability to express relevant parameters in a Resource format o Compression algorithm used o Video resolution o Bitrate used for encoding o Audio sampling frequency o Number of channels o Etc.
Benefits	To facilitate Access to Content To be able to Access Content that is suitable for the Device

1.5.1.24 Represent Binarised XML

	Detailed description of Requirements
Definition	The efficient Representation of XML data
Objective	To save memory, transmission and processing capabilities when handling XML documents
Requirements	· To reduce the amount of information required to express an XML structure to a minimum · To allow for a lossless conversion between an XML structure its binary representation and the reconverted XML structure · To make processing of a binarised XML structure at least as easy to process as the original XML structure
Benefits	Better use of computing and transmission resources

1.5.2 Identify

1.5.2.1 Identify Content

	Detailed description of Requirements
Definition	The Function resulting from a request by a User and the consequent Assignment of an Identifier to Content Entities
Objective	To associate data, e.g. a number, to Entities in a unique and unambiguous fashion
Requirements	To Assign Identifiers according to the rules laid down by the Registration Authority as implemented by the Registration Agency so that there exists a unique, unambiguous, persistent and trusted correspondence between the Identifier and the Entity it Identifies · The Registration Agency shall provide unique Identifiers · The Registration Agency shall Assign the Identifiers unambiguously · The Registration Agency shall be able to Authenticate a Content Item without the need to Access the entire Content Item
Benefits	Form trusted relationships (i.e. Authenticate) by providing Users with the ability to Identify Content Entities

1.5.2.2 Identify IP Class

	Detailed description of Requirements
Definition	The Function by which a User Assigns an IP Class to a Content Item
Objective	To enable Recognition of the Content Item
Requirements	· There must be a determined set of IP Classes
Benefits	There are more possibilities to Use Content Items

1.5.2.3 Identify Metadata

	Detailed description of Requirements
Definition	The Function performed by a User when describing Entities within a DCI
Objective	To facilitate search for and Use of Content Entities
Requirements	· Ability to support the need of different Users to Assign Metadata that have mandatory descriptive fields, e.g.: o Author o Title o Genre of Authorship o Date of Creation of Work o … · Ability to facilitate cataloguing of Content for distribution to professional Users
Benefits	Secondary means to identify Entities

1.5.2.4 Identify Device

	Detailed description of Requirements
Definition	The Function resulting from a request by a User and the consequent Assignment of an Identifier to Devices
Objective	To enable Device Authentication
Requirements	To Assign Identifiers according to the rules laid down by the Registration Authority as implemented by the Registration Agency so that there exists a unique, unambiguous, persistent and trusted correspondence between the Identifier and the Device it Identifies · The Registration Agency shall provide unique Identifiers · The Registration Agency shall Assign the Identifiers unambiguously
Benefits	Form trusted relationships (i.e. Authenticate) by providing Users with the ability to Identify Devices

1.5.2.5 Identify Domain

	Detailed description of Requirements
Definition	The Function resulting from a request by a User and the consequent Assignment of an Identifier to Domain
Objective	To enable Identification of a Domain so that Content can be Licensed to it
Requirements	· The Registration Agency shall provide unique Identifiers, at least for the Domain life cycle · The Registration Agency shall Assign the Identifiers unambiguously
Benefits	Content can be Licensed to Domains

1.5.2.6 Identify Role

	Detailed description of Requirements
Definition	The Function by which a User is Assigned a Role
Objective	To enable Recognition of a Role
Requirements	· There must be a determined set of Roles
Benefits	It is possible to simplify licensing

1.5.2.7 Identify User

(Currently outside of DMP)

	Detailed description of Requirements
Definition
Objective
Requirements	·
Benefits

1.5.3 Recognize

1.5.3.1 Recognize Items

	Detailed description of Requirements
Definition	The Function that matches a given Content Item with corresponding IP Entities in the RRD
Objective	To classify Content Items with the IP that they represent
Requirements	· The ability to interface with the RRD
Benefits	Users have the means to recognize the full set of Conditions for any Role required to interact with a given Content Item

1.5.3.2 Recognize Roles

	Detailed description of Requirements
Definition	The Function that matches the Role Assigned to a User with a corresponding Role in the RRD
Objective	To classify a User’s Role with a given Content Item in terms of the RRD
Requirements	· The ability to interface with the RRD
Benefits	Users have the means to recognize the full set of Conditions for any Role required to interact with a given Content Item

1.5.4 Revoke

1.5.4.1 Revoke Content

	Detailed description of Requirements
Definition	The Function by which a User ceases to recognise a Content Item
Objective	To prevent the further Use of a Content Item
Requirements	· Content must be Identified
Benefits	To discontinue Use of a Content Item, e.g. when the Content Item has been found unsuitable for distribution

1.5.4.2 Revoke Content Element

	Detailed description of Requirements
Definition	The Function by which a User ceases to recognise a Content Element
Objective	To prevent the further Use of a Content Element
Requirements	· Content Element must be Identified
Benefits	To discontinue Use of a Content Element, e.g. when the Content Element is faulty

1.5.4.3 Revoke Device

	Detailed description of Requirements
Definition	The Function by which a User ceases to recognise a device as a Device
Objective	To prevent the further Use of the Device
Requirements	· Device must be Identified
Benefits	To discontinue Use of a Device, e.g. when the Device has been compromised

1.5.4.4 Revoke Domain

	Detailed description of Requirements
Definition	The Function by which a Domain Manager ceases to recognise a Domain
Objective	To prevent the further operation of the Domain
Requirements	· Domain must be Identified · Devices or Users belonging to the Domain must be Identified
Benefits	To discontinue operation of a Domain, e.g. the Devices have been compromised

1.5.4.5 Revoke User

	Detailed description of Requirements
Definition	The Function by which a User ceases to recognise a device as a User
Objective	To prevent the further Use of Devices or Content by a User
Requirements	· User must be Identified
Benefits	To discontinue Use of Devices by a User, e.g. when the device representing the User has been compromised

1.5.5 Authenticate

1.5.5.1 Authenticate Content

	Detailed description of Requirements
Definition	The Function of proving the identity of a Content Item to a Device
Objective	To make sure that a Device Accesses the intended Content Item
Requirements	· Content must be Identified · Content must be Signed or Hashed · Ability to compare a given Content Item with the Registered Content Item · Ability to compare the hash of a given Content Item with the Registered hash and ID of the Content Item
Benefits	To enable a Device to Use the intended Content

1.5.5.2 Authenticate Device

	Detailed description of Requirements
Definition	The Function of proving the identity of a Device to another Device a User or Domain. E.g. · A LPD Authenticates a DMD
Objective	To make sure that Content is Used by the intended Device
Requirements	· Device must be Identified · Ability to support different levels of Authentication
Benefits	To enable Content Uses on identified Devices

1.5.5.3 Authenticate DRM Tool

	Detailed description of Requirements
Definition	The Function of proving the identity of a DRM Tool to a Device
Objective	To make sure that the Content is processed by the intended DRM Tool
Requirements	· DRM Tool must be Identified
Benefits	Correct handling of Content Management and Protection

1.5.5.4 Authenticate User

	Detailed description of Requirements
Definition	The Function of proving the identity of a User to a Device another User or Domain
Objective	To make sure that the User is the intended User
Requirements	· Shall support multiple protocols for the authentication of Users · Outside of DMP scope
Benefits	To enable Content Uses by identified Users

1.5.6 Verify

1.5.6.1 Verify Content

	Detailed description of Requirements
Definition	The procedure to detect corruption or loss of part of the Content
Objective	Delivery of the correct Content
Requirements	· Ability to detect that there is corruption or loss of part of the Content
Benefits	To assure Content Integrity and support Trust Management in the case of DRM Tools

1.5.6.2 Verify Device

	Detailed description of Requirements
Definition	The procedure to detect corruption of part of the software of a Device
Objective	To support Trust Management with a Device that may be remote from a User
Requirements	· Ability to detect whether there is corruption of the Device software
Benefits	The ability to support Trust Management with a Device that may be remote from a User

1.5.7 Negotiate

1.5.7.1 Negotiate Licence

	Detailed description of Requirements
Definition	The procedure by which an agreement is reached between User A and User B whereby User A grants a Licence to User B and User B transfers a Value Expression to User A
Objective	To determine the terms and conditions of the Licence and corresponding compensation
Requirements	· User B can express agreement or disagreements with proposed License terms · The procedure shall support changes to any parameter of the License (e.g. Principal, types of Use such Play, Copy) · The procedure shall support automatic negotiation of license terms · At every step a human readable license must be provided · The procedure shall enable the setting of certain parameters as non subject of negotiation, e.g. setting “no copy” or “time-shifted Use” as a mandatory feature of the License · The procedure shall allow the determination of the degree of confidentiality (no eavesdrop) of the protocol · The procedure shall not require revealing the real identities until the protocol has been successfully concluded
Benefits	To allow Users to achieve the best match between demand and offer

1.5.7.2 Negotiate Use Data

	Detailed description of Requirements
Definition	The procedure by which an agreement is reached between User A and User B whereby User B grants to User A the right to use the User and/or Use Date of User B and User A transfers a Value Expression to User B
Objective	To let two Users determine how the information acquired during interaction with Content can be further utilised
Requirements	· User A can express agreement or disagreements with proposed License terms · The procedure shall support changes to any parameter of the License (e.g. Principal, types of Use) · The procedure shall support automatic negotiation of license terms · At every step a human readable license must be provided · The procedure shall enable the setting of certain parameters as non subject of negotiation · The procedure shall allow the determination of the degree of confidentiality (no eavesdrop) of the protocol · The procedure shall not require revealing the real identities until the protocol has been successfully concluded
Benefits	Allows User confidence that their privacy will be protected, simultaneously allowing Providers to gain knowledge from User and Use Data to the extent this is agreed.

1.5.7.3 Negotiate Licence and Use Data

	Detailed description of Requirements
Definition	The procedure by which an agreement is reached between User A and User B whereby User A grants to User B a Licence to Use Content and User B grants to User A a Licence to Use his User and Use Data
Objective	To let two Users determine how a Content Item can be used and User and Use Data can be used
Requirements	· Users can express agreement or disagreements with proposed License terms · The procedure shall support changes to any parameter of the License (e.g. Principal, types of Use) · The procedure shall support automatic negotiation of license terms · At every step a human readable license must be provided · The procedure shall enable the setting of certain parameters as non subject of negotiation · The procedure shall allow the determination of the degree of confidentiality (no eavesdrop) of the protocol · The procedure shall not require revealing the real identities until the protocol has been successfully concluded
Benefits	To allow Users to achieve the best match between demand and offer

1.5.8 Report

1.5.8.1 Report Use Data

	Detailed description of Requirements
Definition	The Function of generating a message containing Use Data triggered by the execution of another Function as programmed by a User
Objective	To provide information of Content Use
Requirements	· The User inserting a programmed event report (ER) should be able to specify o the conditions under which an event should trigger sending Use Data o what Use Data is to be reported o to whom the Use Data is to be reported · The delivery of the ER should be secure · No ER shall be generated without the User's consent · For any Content Item the User shall be informed if the Device generates an ER · A Device may be instructed to automatically accept or refuse DCIs containing an ER-R based on the nature of the ER to be generated · The User or Device that will generate the ER should be able not to use the Content that will trigger the reporting
Benefits	To enable a variety of business models, e.g. advertising with click counting

1.5.9 Deliver

1.5.9.1 Render

	Detailed description of Requirements
Definition	The Function of generating a human-perceivable signal from a Resource
Objective	To enable human perception of Content
Requirements	· A protocol to Deliver Content to a Device for Rendering
Benefits	To allow the Delivery of a Resource to the intended Rendering Device for human enjoyment in a way that was intended by the Rights Holder

1.5.9.2 Store

	Detailed description of Requirements
Definition	The Function by which Device A Delivers Content to Device B for the purpose of retaining it in Device B for possible Use at a different point in time
Objective	Allow a Device to retain Content and/or Resources for future Use
Requirements	· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices
Benefits	The User can Use a Content for a longer period of time as per License

1.5.9.3 Copy

	Detailed description of Requirements
Definition	The Function by which Device A Stores Content in Device B, preserving the original Content in Device A
Objective	· To enable more use of the same Content Item · To Copy or Move as per Rights Expressions. · To accomplish the transfer of a piece of Governed Content between Devices
Requirements	· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices
Benefits	Allow controlled Copy of Content

1.5.9.4 Move

	Detailed description of Requirements
Definition	The Function by which Device A Stores Content in Device B deleting the original Content in Device A
Objective	· To enable more use of the same Content Item · To Move as per Rights Expressions. · To accomplish the transfer of a piece of Governed Content between Devices
Requirements	· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices
Benefits	Allow controlled Move of Content

1.5.9.5 Backup

	Detailed description of Requirements
Definition	The Function by which a Device can Copy a Content Item (in case the Rights Expression is a Stateless Rights Expression) to and from a Device where the Content Item is not for Use, e.g. for the purpose of later Restoring the Content Item.
Objective	To be able to backup/restore Content to and from an external device
Requirements	Backup requires that the Backup does not result in a second usable copy.
Benefits	· To be able to make room for Governed Content in a Device without losing permanently the Governed Content that is removed from the Device. · Not to lose the Content in case of Device failure.

1.5.9.6 Export

	Detailed description of Requirements
Definition	The Function by which a Device makes available a Content Item for use by a non-DMP DRM system.
Objective	To enable use of a Content Item outside of an Environment.
Requirements	· A protocol to communicate with a non-DMP DRM system. This includes, as a minimum, a means to identify non-DMP DRM systems · In the event the other DRM system is not capable of accepting the encryption used the protocol should be capable of Decrypting and Exporting cleartext Resources, Metadata and Licenses so that it may be re-encrypted as required by the target DRM system. · A Secure Authenticated Channel (SAC)
Benefits	A Rights Holder has the ability to extend the range of use of their Content to other governed environments.

1.5.9.7 Access

	Detailed description of Requirements
Definition	The Function by which Device A obtains Content from Device B so that Device A can execute Functions
Objective	To enable a Device to process Content
Requirements	· Access Content via file download, broadcast and streaming
Benefits	Access to Content via an array of delivery mechanisms

1.5.9.8 Restore

	Detailed description of Requirements
Definition	The Function by which a Device can Copy a Content Item (in case the Rights Expression is a Stateless Rights Expression) to and from a Device where the Content Item is not for Use, e.g. for the purpose of later Restoring the Content Item.
Objective	To be able to backup/restore Content to and from an external device
Requirements	Backup requires that the Backup does not result in a second usable copy.
Benefits	· To be able to make room for Governed Content in a Device without losing permanently the Governed Content that is removed from the Device. · Not to lose the Content in case of Device failure.

1.5.9.9 Import

	Detailed description of Requirements
Definition	The Function by which a Device accesses a piece of content governed by a non-DMP DRM system.
Objective	To enable Use of a piece of governed content by a Device.
Requirements	· A protocol to communicate with a non-DMP DRM system. This includes, as a minimum, a means to identify non-DMP DRM systems · The protocol should be capable of obtaining Clear-text Resources, Metadata and Licenses so that these may be re-encrypted as required by the Environment. · A Secure Authenticated Channel (SAC)
Benefits	Enables Environments to be populated with governed content from sources outside of DMP.

1.5.9.10 Update

	Detailed description of Requirements
Definition	The means by which a Content Item may replaced by a new Content Item
Objective	Allow for Content to be Governed dynamically
Requirements	· Associate Content with License · Associate Content with DRM Tool
Benefits	· Enhanced flexibility in implementing Content Delivery and Use

1.5.9.11 Inter-Device communication

	Detailed description of Requirements
Definition	The means by which a DRM Processor and a Resource Processor exchange data in a Device
Objective	To support standardisation of Device components
Requirements	· Interface between DRM Processor and Resource Processor · Protocol between DRM Processor and Resource Processor
Benefits	To enable componentisation of Device

1.5.10 Manage

1.5.10.1 Manage Domain

	Detailed description of Requirements
Definition	Procedures to manage a set of Devices such that only those Devices can Use the Content Licensed to the Domain
Objective	To enable groups of Devices and/or Users e.g. belonging to a family to Use the same Content on any of the Devices in the group
Requirements	· Users with an authorised entitlement (Administrator) shall be able to fully control Domain membership and Content distribution. · Setting up a Domain, including the ability to distribute Licences that can only be used by Devices in the Domain · Joining a Domain · Authorising entry to a Domain · Leaving a Domain · Directing to leave a Domain, including the ability to exclude a Device so that it cannot process Licences associated with the Domain after the time of exclusion · Users without an authorised entitlement shall not be able to obtain confidential information related to the Domain · A Domain shall be configurable to permit a variety of distribution options between Devices belonging to the Domain, e.g. superdistribution of Content to Devices belonging to a sub-Domain within the Domain (e.g., specialized interest groups)
Benefits	Enables content distribution to be both very wide and very specific, supporting many possible business models.

1.5.10.2 Manage DRM Tool

	Detailed description of Requirements
Definition	Procedures to manage the communication of DRM Tools between themselves and a DRM Processor (parties) to enable a Device to Process Governed Content
Objective	To enable Use of a local or external DRM Tool by a Device
Requirements	It shall be possible for a DRM Tool to require: · To be informed of all the other DRM Tools operating at any time · To be notified when a new DRM Tool is instantiated · To be informed that a particular event occurs · The instantiation of another DRM Tool · The termination of another DRM Tool · The communication of the results of a DRM Tool · The exchange of a License or any part of it between two parties · The exchange of a Decryption Key along with associated information (i.e. timing) about its use between two parties · The mutual authentication with a party · The display of information to a User and the request for a User input
Benefits	To allow enhanced flexibility in the adoption of DRM technologies in Content Delivery and Use

1.5.11 Package

1.5.11.1 Package as File

	Detailed description of Requirements
Definition	The Function of processing Content for the purpose of delivering it between Devices as File
Objective	To ensure proper delivery of Content as File
Requirements	· Minimum overhead compared to Content · The Content should be efficiently retrievable
Benefits	Ability to Deliver Content between Devices

1.5.11.2 Package as Broadcast

	Detailed description of Requirements
Definition	The Function of processing Content for the purpose of delivering it between Devices as Broadcast
Objective	To ensure proper delivery of Content as Broadcast
Requirements	· Minimum overhead compared to Content · The Content should be efficiently retrievable · Transport of Content should be efficient and timely (e.g. an End-User should not have to wait for a long time before Using Content)
Benefits	Ability to Deliver Content between Devices

1.5.11.3 Package as Streaming

	Detailed description of Requirements
Definition	The Function of processing Content for the purpose of delivering it between Devices as Stream
Objective	To ensure proper delivery of Content as Stream
Requirements	· Minimum overhead compared to Content · The Content should be efficiently retrievable · Transport of Content should be efficient and timely (e.g. an End-User should not have to wait for a long time before Using Content)
Benefits	Ability to Deliver Content between Devices

1.5.12 Process

1.5.12.1 Encrypt/Decrypt

	Detailed description of Requirements
Definition	Methods used to hide portions or totality of Content Elements
Objective	To prevent a User from Using Content, Resources or Fragments of Resources
Requirements	· Suitably flexible for a wide variety of Content · Efficiently implementable on a wide range of Devices · Based on Encryption Algorithms that are: o publicly disclosed o subject to constant scrutiny and evaluation by the worldwide cryptographic community o supporting stream and bulk ciphers o considered as secure o in broad use · The appropriate consideration of export restrictions. · Encryption methods that allow decryption by Devices with different processing capabilities · Support o Facilitate efficient prefetch and decryption of child resources. o Efficient random access to content blocks for all linear content types
Benefits	To protect Content and Rights Expressions from being read by unintended Users

1.5.13 Transact

	Detailed description of Requirements
Definition	Providing User, Device, Governed Content or Service information to a payment system external to an Environment
Objective	To enable flexible payment systems such as subscription, pre-payment or transaction-based payment by a single Device, a Domain or a User.
Requirements	· The ability to support multiple payment methods and mechanisms
Benefits	Automated payment

1.5.14 Test Conformance

1.5.14.1 Test Conformance of Rights Expressions

	Detailed description of Requirements
Definition	Checking that a Rights Expression is interpreted and provides the output as intended by the originator of the Rights Expression
Objective	To test conformance of the engine interpreting the Rights Expressions
Requirements	Device conformance shall be assessed and regulated according to industrial compliance regime
Benefits	It is essential for a Rights Holder that a Device will correctly interpret Rights Expressions.

1.5.14.2 Test Conformance of Enforcing Rights Expressions

	Detailed description of Requirements
Definition	Checking that the Functions corresponding to the output are executed as intended
Objective	To test conformance of the engine executing the Rights Expressions
Requirements	Device conformance shall be assessed and regulated according to industrial compliance regime
Benefits	It is essential for a Rights Holder that a Device will correctly execute the interpreted Rights Expressions.

1.5.14.3 Test Conformance of Tamper resistance

	Detailed description of Requirements
Definition	Defining the levels of tamper resistance and the methods to be used when an implementation is put under test for tamper resistance to determine such levels
Objective	To test the robustness of a Device to attacks
Requirements
Benefits	It is essential for a Rights Holder that a Device is implemented in a way that makes it difficult for an attacker to tamper with it.

1.5.15 Certify

1.5.15.1 Certify Content

	Detailed description of Requirements
Definition	The issuance of a statement that a given Content Item is conformant to the DMP specifications (either through Certified Content Creation Device or Authority and corresponding Agency)
Objective	To provide the means to assure when required that a Content Item is indeed Content
Requirements	· Content conformance testing tools · Procedures to Certify Content
Benefits	To guarantee system integrity

1.5.15.2 Certify Device

	Detailed description of Requirements
Definition	The issuance of a statement by an authority that the claim by a device to be a Device is guaranteed
Objective	To make sure that Governed Content is Used by a Device
Requirements	· Device conformance testing tools · Procedures to Certify Devices
Benefits	To provide a guarantee that a Content Item is Used by a Device

1.5.15.3 Certify User

(Currently outside of DMP)

	Detailed description of Requirements
Definition	The issuance of a statement by an authority that the claim by a device (e.g. smart-card) to represent User is guaranteed
Objective	To make sure that Governed Content is Used by a User
Requirements	· Procedures to Certify Users
Benefits	To provide a guarantee that a Content Item is Used by a User

2 Architecture

2.1 Introduction

To facilitate or enable use of content by end-users, there is often the need for a string of intermediaries whose job is to make sure that content, once created, is packaged and delivered to end-users for consumption. Because intermediaries typically exchange and add value in a chain they, including creators and end-users, are also called value-chain users or, simply, users. Particularly with the use of digital technologies value-chain users tend to operate in a network and the name value-network is also used to indicate such a “non-sequential” relationship between intermediaries. In this document, however, the still more common word “value-chain” will be used.

This document contains a high-level description of the operation of a generic media value-chain based on the assumption that those who hold rights associated with content moving along the value-chain wish to retain control of the use of that content. This type of content is called “governed” content.

The description can be considered as an architecture that is shared by value-chains handling governed content. The architecture has been designed to be capable of supporting value-chains that are by and large digital extensions of today’s analogue value-chains, even though digital value-chains can be vastly different from today’s media value-chains whose origins are rooted in the prehistory of analogue media. DMP may reconsider this architecture if and when new intrinsically digital value-chains will emerge that cannot be supported by the current architecture or its extensions.

Please note the following general remarks:

1. In this document words beginning with a capital letter have the meaning defined in Approved Document No. 6 – Terminology;

2. The DMP architecture provides a broad view that serves to illustrate how Governed Content carrying Intellectual Property (IP) is generated, passed on through the Value-Chain and eventually consumed;

3. The term User or, when stressing the importance of his role in a Value-Chain is required, Value-Chain User, will be employed to indicate a Creator, an Intermediary or an End-User;

4. Approved Document No. 3 – Interoperable DRM Platform provides elementary technologies (“Tools”) in the form of an Interoperable DRM Platform (IDP) that can be employed to set up Value-Chains that handle Governed Content in an Interoperable way;

5. DMP specifications only address interoperability of the so-called DRM-layer, i.e. issues related to media coding and below (e.g. transport layer) are not addressed.

6. DMP is continually extending the scope of the architecture and adding new Tools to the IDP toolkit.

This Approved Document No. 2 provides:

1. A walkthrough exercising the main elements of Value-Chains enabled by the Tools specified in Approved Documents No. 3 and the steps required to set up Value-Chains, including the principles of operation of Authorities and Agencies in charge of Certification and Registration specified in Approved Document No. 5;

2. A series of models:

a. Creation Model identifying the major entities for which IP is attributed and describing their relationship to the digital objects involved in Content Creation;

b. Distribution Model identifying and describing the role of the principal Value-Chain Users engaged in distribution;

c. Delivery Model describing the two basic ways – File and Stream – in which Content can be Delivered between Devices;

d. DRM Tool Model describing the general operation of DRM Tools in Devices;

e. Device Model identifying and describing the principal Devices employed by Value-Chain Users;

f. Domain Model describing the operation of Domains of Devices and Users;

g. Import/Export Model describing how governed content can be converted to Governed Content and vice versa;

h. Data Model identifying and describing the different types of Data specified by DMP.

3. A summary description of the Tools specified by IDP-3.0.

Reading the Foreword of this Approved Document is a prerequisite for a proper understanding of this and other Approved Documents. It is also highly recommended that this document be read before delving in Approved Document No. 3 – Interoperable DRM Platform (IDP) [3].

2.2 An End-to-End Value-Chain

A Value-Chain is a group of interacting Users, connecting (and including) Creators to End-Users with the purpose of Delivering Content to End-Users. As indicated in the Figure below the main components are

1. Creation (including Adaptation)

2. Instantiation

3. Production

4. Content Provisioning

5. Service Provisioning

6. Consumption

Figure 1 – Value Chain

Note that dotted arrows mean that the output of a User can be Used by the same type of User to make more Resources Representing any of Work, Adaptation, Manifestation, Instance.

2.2.1 A walkthrough

A Creator makes a Work that may be performed (“Instantiated”) by a performer and Used by a Producer to make a product – typically a combination of Resources – to be distributed by Content and Service Providers.

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. For the purpose of Using Content on Devices, Content has to be digitally Represented. DMP calls such digitally Represented Content, DMP Content Information (DCI).

As was already the practice in the analogue world, Content Items require Identification. Creators, Instantiators and Producers typically have the objects that represent their intellectual and/or commercial property (IP Entities) uniquely Identified. With Identification appropriate Metadata are also typically generated.

Approved Document No. 5 specifies how this task is performed by a number of organisations (Registration 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 Identify Content Items

A User wishing to express conditions to Use a Content Item can associate a License to it Granting Permissions under specified Conditions. The party Granting Permissions is referred to as Licensor and the party receiving them is referred to as Licensee.

Approved Document No. 3 supports the case in which the Licensee is

1. A Device

2. A User (i.e. a device representing the user)

3. A Domain (i.e. groups of Devices and Users).

A User who does not wish to express Conditions to Use a Content Item can do so by Releasing it without a License. The Content Item, however, is still Governed because it is Identified.

To enable a Device to interpret Permissions without human intervention, DMP uses a machine readable language called Rights Expressions Language (REL). REL can be applied to Content that represents different categories of Intellectual Property (IP Entities). DMP uses a Creation Model to describe IP Entity relationships and dependencies. These are captured in a standard machine-readable ontology called Represent Rights Data (RRD) which also defines a set of Roles and Functions.

A Rights Holder can prepare generic Licenses for certain Roles, Functions and Content Items. These are converted to specific Licenses made available to Users who declare their Roles, Functions and Content Items.

By interacting with a Content Item using a Device a User typically generates data called Use Data, i.e. Data related to the Use that the User has made of a Content Item and Resources therein. This Use Data may have value in and of itself and the User generating the Use Data may decide to License other Value-Chain Users to Use such Use Data. In some instances the economic value of Content is “higher” than that of Use Data, but in other instances the opposite may be the case.

A Rights Holder may decide to add technology in the DCI distributed that will trigger sending back to one or more Rights Holders information about Events related to the use of a given DCI. This is called Event Reporting.

To support different business models Approved Document No. 3 allows a License to be:

· Bundled within the Governed Content (i.e. it is part of the DCI)

· Not Bundled within the Governed Content (i.e. the DCI references an external License).

Approved Document No. 3 allows other Content Elements in the DCI (e.g. Resources) to 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. To this end Approved Document No. 3 provides various means to convey Keys and related DRM information.

Approved Document No. 3 provides a basic selection of Encryption Tools that can be employed in restricted-capability Devices such as Portable Audio and Video (PAV) Devices (i.e. Devices without direct access to network). However, to support a broader range of applications such as those enabled by Stationary Audio and Video (SAV) Devices (i.e. Devices with network or broadcast access), Approved Document No. 3 also provides the means to Represent in a DCI blocks of executable code (called DRM Tools or DRM Tool Packs) 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 handle relationships between Devices, e.g. for the purpose of Access a Content Item or a Licence from a Device, it is necessary to utilise Protocols . In order to Deliver Content between Device Entities it is necessary to Package a DCI (in binary form) and its referenced Resources. Approved Document No. 3 supports 2 forms of Delivery:

1. As File. This is called DMP Content File (DCF);

2. As Stream. This is called 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.

2.2.2 Setting up Value-Chains

A designer of a Value-Chain or individual Users may decide set up a Value-Chain that offers Content or Services to other Value-Chain Users. AD3 provides Tools to optimise the effort to achieve this result while maximising flexibility of the resultant Value Chains.

In general Users require Devices to perform the Functions proper of their Role in a Value-Chain. To entrust Content to a Device, however, a Rights Holder must have assurance that the Device will execute Functions according to Approved Document No. 3. This is achieved by having the Device Certified.

Approved Document No. 5 specifies how this task 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. This three-layer arrangement is similar to the one used for Content Registration.

Content Registration Agencies have also the task to Authenticate, i.e. to confirm the identity of a Content Item. A Device wishing to obtain Authentication of a Content Item can either contact the relevant Content Registration Agency by reading the syntax of the Identifier or the Content Registration Authority. The Authority will then direct the Device to the relevant Agency.

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 special Devices called Device Identification Devices. Approved Document No. 5 specifies how this task is performed by a number of organisations (Device Registration Agencies) that are appointed and overseen by a single root authority (Device Registration Authority). DMP appoints the Device Registration Authority after approving the Authority’s Registration policies. The same three-layer arrangement used for Certification is also used for Identification.

Other Entities requiring Certification and Identification are: Domain Management Devices (Devices employed to manage Domains), DRM Tools and Users. Note that in the current phase of development Users play a role only to the extent they are represented by devices, e.g. smart cards and that Certification of such devices is out of DMP scope.

In summary:

1. DMP Certification Authorities and Agencies are required for the following Entities:

a. Devices, e.g. Creation Devices, Consumption Devices and Domain Management Devices

b. DRM Tools.

2. DMP Registration Authorities and Agencies are required for the following Entities:

a. Content – License and DRM Tool

b. Devices, e.g. Creation Devices, Consumption Devices and Domain Management Devices.

Note that only once a Device or a DRM Tool has been Certified will it be eligible to be Identified.

In general interacting Devices require Authentication to achieve Trust. Approved Document No. 3 provides Protocols that can be employed to achieve this.

2.2.3 Navigating the Value-Chain

The figure below places the Devices mentioned above in a generic Value-Chain and identifies their principal relationships. Note that in DMP a Device is either a combination of hardware and software – or just an instance of software – that allows a User to execute Functions.

Figure 3 – Some typical Devices in a Value-Chain

In the figure

1. Devices with a yellow colour provide Identifiers to Devices or Content

2. Device with a blue colour is used to make Content

3. Devices with a green colour provide the respective Content Elements

4. Device with an orange colour verifies Roles

5. Devices with a red colour are End-User Devices

6. Device with a violet colour manages Domains

7. Device with a purple colour is a non-DMP device.

The numbers indicate the different Protocol types required for Devices to communicate.

The figure above will be used to describe a full walkthrough.

1. Content Creation Device obtains Identifier from Identification Devices for

a. Resources

b. License

c. DRM Tool

d. Content

2. Content Creation Device makes Content by combining:

a. Resources

b. License

c. DRM Tool

d. Identifiers

3. Content is Delivered to Content Provider Device

4. In case License and DRM Tool are referenced (not Bundled within the Content)

a. License is Delivered to License Provider Device

b. DRM Tool is Delivered to DRM Tool Provider Device

5. An End-User Device (SAV) Accesses

a. Content from Content Provider Device

b. License from License Provider Device if Content does not have a Bundled License

c. DRM Tools from the DRM Tool Provider Device if

i. End-User Device does not already hold the required DRM Tool

ii. DRM Tools are not Bundled within the Content

6. End-User Device (SAV) performs the following according to License Permissions

a. Packages Content as File (DCF)

b. Adapts Resources creating DCI and DCF

c. Moves/Copies DCF to another SAV or End-User Device (PAV) via PXD.

7. PXD performs the following

a. Accesses Content with Bundled Licence (as DCF) from Content Provider Device

b. If Content does not have a Bundled Licence

i. Accesses Licence from Licence Provider Device

ii. Makes DCI

iii. Makes DCF

c. Moves/Copy DCF to PAV

2.3 The DMP Models

2.3.1 Creation Model

Value-Chains begin with Content Items that represent IP Entities. To ensure that management of Rights associated to IP are consistent, Value Chains must be able to generate copies and variations of Content without breaching the sets of Rights at every point in the Value-Chain. If such an integral treatment of Rights is not achievable in a consistent and reliable fashion, then there is little hope that Rights Holders will entrust Content representing their IP to a Value-Chain. Therefore the DMP has designs its Interoperable DRM Platform so that it can clearly identify the source of all IP and provide the means to represent all Rights associated with IP generated throughout the Value Chain.

Interoperability is key to this endeavour because it enables different IP-based business models of varying scope and depth to run their full course while at the same time providing the means to determine that the Rights expressed within them are adequately supported. Furthermore, interoperability removes the possibility that some Users in the Value Chain be capable of effecting arbitrary control over other Users by virtue of restrictions inherent in the design of technology.

The purpose of the Creation Model is to provide a generic architecture for "Creation" of Content. The model should be able to represent any case where the objects representing IP are Delivered to a Device, Stored or Rendered. For IP to be identified and managed, it is required that it be embodied in human perceivable objects to be communicated, identified and associated with an actual human source. However, the ‘objects’ referred to as ‘having’ IP in this Creation Model are really independent of physical/digital objects in that their existence depends on the mind of their Creators in the first instance although only when they are ‘fixed’ in a physical form, perceivable by other human beings, can the IP be identified and communicated.

Thus, the following objects referred to as IP Entities are defined formally in the DMP Terminology and are pivotal to the DMP vision of how IP is represented by Resources.

Work

It is the first IP Entity to which IP is attributed to in the Creation Model is Work and refers to the fruit of an effort of an individual or group of individuals that constitutes the logical construct that persists independently of the innumerable possible physical representations of that construct. A Work on the one hand can be very specific by being clearly identifiable through a large number of differing Manifestations all of which are perceived as being of the Work yet it is also intangible in that proof of its existence requires physically perceivable materials that are not of the Work.

Adaptation

An Adaptation of a Work is considered a new Work but is of dependent origination in that its existence depends on the existence of another independent Work. The law consistently requires that the Author of an original Work give his consent to the creation and distribution of the new Adaptation of the Work, possibly determining any set of restrictions both moral and economic. Also, the Author of an Adaptation must refer back to the root original Work. Thus, an original Work can spawn any number of Adaptations and Manifestations while an Adaptation can only spawn a singular Manifestation. Note that these requirements are only relevant for Works that are not in public domain.

Manifestation

A Manifestation is an object or event which is an expression of a Work, e.g. the original manuscript of a musical Work. It is clear that in order to establish the authorship of a Work, at least a first initial object – either digital or otherwise – must be produced and unequivocally attributed to the Author of the Work. Such objects are referred to as Manifestations. Although at least one Manifestation must be attributed to the Author of the Work, the Manifestations of Adaptations of a Work are also considered to be Manifestations of the Work. Thus, a given Work may have Manifestations attributable to other Authors.

Instance

An 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. Instances are not necessarily uniquely of a particular Manifestation of a Work. The IP associated with Instances is so inextricably dependent on both the Manifestation and the Work that it is of, that it is classified separately as “Neighbouring” or “Performing” Rights. An Instance when it is fixated to a physical support constitutes the first copy, also referred to as “master”, used to make further copies, e.g. for commercial purposes.

Expression

An expression is the result of a process that an individual undertakes when generating a tangible Manifestation of a Work or that an Instantiator, e.g. a Performer, undertakes when interpreting a particular Manifestation to generate an Instance.

DMP does not currently define the term expression because the Creation Model is presently only concerned with classification of Content as it pertains to associating IP with digital Manifestations and Instances of Works and any attribution of IP for an expression is considered to be un-severable and correspond faithfully to the attribution given for the Manifestation and/or Instance in which they are contained. That is to say, that the owner of any IP attributable to an expression is necessarily the same person or persons to which the Manifestation and/or Instance is attributable.

Thus, in the Creation Model any object either analogue or digital that either embodies or represents IP – for the purpose of attributing IP Rights – can be classified necessarily under one of the categories as listed below in Table 1.

Table 1 – IP Objects and Rights

*IP Entity*	*IP type*	*Associated Rights types*
Work	Independent origination	Creator
Adaptation	Dependent origination	Creator
Manifestation	Dependent origination (Any Manifestation depends on a Work)	Creator
Instance	Unique dependent stylistic reproduction	Neighbouring or performing rights

Thus, the scope of IP associated with the different IP Entities can be summarized as in Table 2 below. Authorship of a Work (independent origination) has dominion only over all its Manifestations and all Instances, copies, reproductions and communications thereof. Authorship of an Adaptation has dominion only over all its Manifestations, Instances, copies, reproductions and communications thereof. Realization of an Instance has dominion only over all copies and reproductions thereof.

Table 2 – IP Entity Scope

		*Entities*
		*Work*	*Adaptation*	*Manifestation*	*Instance*
*IP Type*	Work	x	x	x	x
	Adaptation		x	x	x
	Manifestation			x	x
	Instance				x

The figure below illustrates the dependencies between IP Entities.

Figure 4 – IP Entity dependencies

2.3.2 Represent Rights Data (RRD)

The Creation Model illustrates the process by which IP Entities are generated in terms of natural dependencies derived from the notion of an identifiable first origin of any idea. Thus, the Creation Model defines the relationship between the origin of IP Entities (ultimately residing in the mind of creators) and subsequent dependent IP Entities, Actions, and Roles. The Ontology is able to represent these concepts and their relationships.

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

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

2.3.2.1 DRM as the link between IP and REL

The IP Entities like Work, Adaptation, Manifestation or Instance are linked independently of whether their relationships are represented digitally or otherwise. In the case where objects are represented digitally, Rights over Resources must be made subordinate to the Rights over the IP Entity or Entities being represented. Thus, actions to be taken on digital files Representing different IP Entities must be associated with the hierarchy expressed by the RRD.

Since the ability to perform Functions on media files are agnostic to what those files Represent, only a DRM system can determine what IP is being Represented and how to associate that particular Representation with the set of actions or Functions available. To achieve this, the Metadata used to describe generically the object Represented by a DCI as well as the Resources within it, must be available and coincide with the terms defined in the RRD. Also, Users of Resources may be associated with generic Roles such as Adaptor, Instantiator, End-User etc. when being assigned rights in fully automated IP licensing processes.

Thus, combining both sets of actions plus Roles will allow for the determination of generic default conditions required to invoke different IDP Functions and combinations thereof. For example, a User obtains a Work-Manifestation Item and chooses the standard Role Adaptor. This then could automatically give rise to a standard set of conditions to be fulfilled such as “To Register DCI Adaptation of “Great Blue Work” approval certification XYZ is required.”

2.3.2.2 RRD Foundation

The RRD includes all the IP Entities of the Creation Model and adds corresponding Roles and Actions.

2.3.2.2.1 IP Entities

There are several levels of representation in digital media. The most common is the representation inherent in common digital files know as Resources i.e. MP3, MP2-4 files etc., that refers to the representation of any entity or event (performance, writing, acting etc.) for the purpose of conveying said event or entity directly to the human senses i.e. sight, hearing etc. through a rendering device.

Resources can be further Represented by using DCIs that provide a standard format for securely communicating all the information pertinent to the Use of a Resource such as its location, required tools to render Resources, Rights Expressions, Metadata etc., so that Resources are never isolated from the means to Use, govern and protect them.

However, DCIs need not be used only to represent Resources but rather can represent other types of entities particularly IP Entities (with or without a Resource). Thus, we may produce equally unique Representations of IP Entities for the purpose of IP management.

The DMP Creation Model extended beyond the IP Entities is sketched in Figure 5 below.

Figure 5 – Extended DMP Creation Model

In Figure 5 and between the creation of the Work and the making of Instances, derivation of IP Entities occurs at two fundamental levels denoted by the verbs: Depend and Use. Use always implies the existence of at least one copy therefore allowing further commercial copies for which rights granting is required. Depend implies a more un-severable relationship that may not necessarily refer to a physically perceivable object; for example, the Work here meant to refer to the logical construct and/or idea expressed in the Work’s physical Manifestations, exists necessarily prior to being so expressed. Therefore, we say that the Manifestation Depends on the Work rather than say that it Uses the Work.

Beginning with the last event of a chain of events, the chaining of Depend, Use and Produce defines generically what the object is (Work, Manifestation, Instance and Copy). Note that although the IP Rights considered in the Creation Model can be invoked as per different jurisdictions, the Produce-Use-Depend chains are expected to remain the same in most if not all cases.

At the end of the Creation Model the final products are copies of the IP Entities that can be communicated. These are as follows:

· Work-Instance-Copy

· Adaptation-Instance-Copy

· Work-Manifestation-Copy

· Adaptation-Manifestation-Copy

These copies constitute the basis IP Representation further down the distribution chain and are what are used in Products.

2.3.2.2.2 RRD Functions

RRD Functions are divided into two types:

· RRD Functions agnostic to whether or not the relevant IP Entities are represented digitally:

o Create Adaptations: The Function by which an Adaptation is created.

o First Fixation: The Function of making an Instance.

o Synchronization: The Function of concurrently performing/displaying two distinct Works or Adaptation Instances each for a different sense e.g. text and audio or video and song.

o Mechanical Reproduction: The Function of making physical copies of a Product

o Public Communication: The Function of publicly displaying/performing, e.g. live performance, radio, television, internet streaming, multicast of Instances and Manifestations, and download.

o Distribution: the Function of selling, renting and lending of copies.

o Private Copy: The Function of Storing Content and hold it private for non commercial purposes.

· RRD Functions taken on digital files that in their essential nature are agnostic to what the digital objects may represent such as the RRD Functions represented in REL or a DMP Value Chain Functions.

2.3.2.2.3 Roles

Roles are defined by groupings of RRD Functions realized on objects and therefore the definition of an RRD Function implies the corresponding Role to realize the RRD Function. Six different Roles can be listed: Creator, Adaptor, Instantiator, Producer, Distributor and End-User.

2.3.2.3 RRD Model as an Ontology

The IP objects can be formalized as an ontology. A digital representation of the DMP Creation Model serves to support the development of applications based on the Creation Model. Since the Creation Model is neutral i.e. represents all Users/Roles, IP Entities and their natural dependencies, it can be used as a common foundation for ascribing rights as defined by any jurisdiction that recognizes the ownership by individuals of original ideas. Thus, such an Ontology constitutes a powerful common core in support of interoperability between Digital Rights Management systems, a central goal of the DMP’s Interoperable DRM Platform.

The RRD is expressed in OWL (Web Ontology Language). A brief summary of the precedents that have led to the tools being used to formalize the RRD follows.

The key concepts that underlie OWL are classes and their relations expressed as properties. Thus, the concepts represented in the DMP Creation Model and their relations are mapped to OWL classes and properties. The official W3C reference of OWL can be found at [46].

“Approved Document No. 3 – Interoperable DRM Platform”, describes in detail how the model here described has been transposed into the OWL Ontology representation.

2.3.3 Distribution Model

In the general DMP 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 6 – Conceptual diagram of DMP Distribution Model

A specific Value-Chain need not involve all types of Users indicated in the Figure above, e.g.

1. The Service Provider may Deliver Content to End-Users with License and DRM Tools Bundled within it. In this case the Service Provider makes and Registers a new Content Item out of Content, License and DRM Tools received from other Users. This is represented in the top line of the figure.

2. The Service Provider may not be required as the End-User individually Accesses Content, License and DRM Tools. This is represented by removing the first line of the figure

3. The DRM Tool Provider may not be required, e.g. when Governed Content is Delivered without the use of DRM Tools. This is represented by removing the bottom line in the figure.

Note that the Service Provider makes and Registers a new Content Item out of Content, License and DRM Tools that he receives from other Users.

2.3.4 Delivery Model

For the purpose of this specification all types of Data to be Delivered between Device Entities can be Represented as Content Elements, in particular Content, Licenses, DRM Tools and DRM Information. These Content Elements can be variously combined between themselves and other Content Elements.

DCI is a Representation of Content that, along with the relevant Content Elements, can be Processed by a Device. However, DCI is not suitable for Delivering Content between Devices. The Package Function enables Delivery of a Content Item over a variety of specific Delivery mechanisms. Approved Document No. 3 supports Delivery as a File (DCF), on an MPEG-2 Transport Stream (DCB) and on a Real-Time Protocol transport (DCS).

The Package Function includes

· Insert DCI in the selected transport mechanism

· Extract DCI from the selected transport mechanism

2.3.5 DRM Tool Model

The following figure describes the DRM Tool Model.

Figure 7 – Handling of DRM Tools in a Device

Packaged Content is Delivered to a Device because the Device has Accessed it or another Device has Delivered it. The Parser extracts the DCI from the Packaged Content. In general the DCI Parser extracts the following from the DCI:

1. Resources

2. Metadata

3. DRM Information

4. DRM Tools or Tool Packs

5. Licenses

6. Keys.

Resources and Metadata are passed to the appropriate decoding pipelines while DRM Information, DRM Tools or Tool Packs, Licenses and Keys are passed on to the DRM Processor, a module within a Device that executes DRM-related Functions in a Trusted fashion.

The Device may already have all required DRM Tools e.g. because they are:

1. Embedded in the Device

2. Stored after having been previously Accessed

3. Bundled within the Content Item currently Accessed.

If none of the above holds, then the DRM Processor will Access the missing DRM Tools from the DRM Tool Provider Device. Once Used, all DRM Tools are kept in the Secure Storage of the Device.

The DRM Processor controls the critical points internal to a Device. As an example, in the Figure above there are 7 such “control points” (indicated as black nodes). The DRM Processor, using the DRM Information, instantiates the required DRM Tools as plug-in modules (called DRM Tool Bodies), and instructs them to operate on the specific control points along the Resource decoding pipelines.

As described above, DRM Tools represent one or more DRM Functions such as Authenticate, Decrypt, detect watermark signal or extract watermark payload, etc. The DRM Processor handles instantiation, initialisation, Authentication, and supervision of DRM Tools Bodies. However, DRM Tools can also be aggregated into a DRM Tool Group. In this case a DRM Tool Agent performs the same tasks above for the DRM Tools in a DRM Tool Group. The combination of a DRM Tool Agent and its DRM Tool Group is called DRM Tool Pack (see figure below).

Figure 8 – Tool Pack Interoperability

Note that a mandatory requirement for a DRM Processor is that it can interface with DRM Tool Agents and DRM Tools.

By using a DRM Tool Pack, sensitive information about the way a Resource is Governed can be placed in the DRM Tool Agent instead of placing it in the DCI. However, in those cases where a simple DRM Tool configuration is required, e.g. one DRM Tool performing AES Decryption on a Governed video stream, a single DRM Tool configuration may be a simpler option.

Figure 9 and Figure 10 below graphically compare the “stand alone” DRM Tools and. the DRM Tool Pack.


Figure 9 –“Stand alone” DRM Tools	Figure 10 – DRM Tool Pack

The following is an example of a complete walkthrough of the DRM Tool Model when a DRM Tool Pack is employed:

1. DRM Tool Provider

a. Obtains DRM Tool Pack ID from DRM Tool Identification Device

b. Includes DRM Tool Pack ID in Tool Pack Information with other related Metadata

c. Makes DRM Tool Pack by combining DRM Tool Pack Information, DRM Tool Agent, DRM Tool Group and Signature

d. Stores DRM Tool Pack in DRM Tool Provider Device

2. User Requests Service

3. Service Provider

a. Authenticates User

b. Sends Tool Pack ID and DRM Tool Provider Device’s URL to SAV

4. SAV requests Tool Pack with Tool Pack ID to DRM Tool Provider Device

5. DRM Tool Provider Device Delivers Tool Pack

6. DRM Processor

a. Accesses Tool Pack Information

b. Searches for requested DRM Tool Pack from Secure Storage

c. Executes DRM Tool Agent

d. Sends available Control Points to DRM Tool Agent

7. If User selects more than one Service simultaneously, DRM Processor executes all Tool Agents for each service

8. DRM Tool Agent instantiates DRM Tools, initializes DRM Tools, and connects each DRM Tool to proper Control Point

9. If there is a missing DRM Tool in the DRM Tool Group, DRM Tool Agent requests missing DRM Tool to DRM Processor

10. DRM Processor

a. Searches for missing DRM Tool in the Secure Storage

b. Gives the reference of the DRM Tool to Tool Agent

11. DRM Tool Pack Data contains information to initialize DRM Tools in DRM Tool Group, e.g. Key information for Decryption Tool or seed number for watermarking Tool

12. DRM Processor Accesses DRM Tool Pack Data and sends it to DRM Tool Agent, the only one capable of Parsing DRM Tool Pack Data

13. DRM Tool Agent uses DRM Tool Pack Data to initialise the appropriate DRM Tools in the DRM Tool Group

14. DRM Processor starts Resource decoding

15. DRM Tools perform DRM Functions on Resources

To Update a DRM Tool Pack/Tool in SAV the DRM Tool Provider Device performs the following:

1. DRM Tool Provider Device inserts a DRM Tool/Tool Pack Update message in the DCI

2. DRM Processor

a. Receives Update message

b. Recognises which DRM Tool Pack/Tool should be Updated

c. If DRM Tool Body is contained in the DCI then DRM Processor replaces the Tool Body

d. Else DRM Processor Access DRM Tool Body from DRM Tool Provider

e. Updates proper DRM Tool Pack/Tool according to the Update message

2.3.6 Device Model

It is convenient to introduce specific Device types that are needed to set up typical Value-Chains:

Table 3 – IDP-2 Device types

#	Device Name	Acronym
1.	Device Identification Device	DID
2.	Content Creation Device	CCD
3.	Content Identification Device	CID
4.	Content Provider Device	CPD
5.	License Provider Device	LPD
6.	Role Verification Device	RVD
7.	DRM Tool Provider Device	DPD
8.	Domain Management Device	DMD
9.	Domain Identification Device	DoID
10.	Content Consumption Device	SAV
11.	PAV eXternal Device	PXD
12.	Content Consumption Device	PAV

These are briefly described below

2.3.6.1 Device Identification Device

Approved Document No. 3 supports two kinds of Device Identification:

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 [34], generated by a Device Identification Device, is utilised as Device Identifier.

2.3.6.2 Content Creation Device

In a typical CCD walkthrough a Creator activates an application showing a GUI displaying a series of steps that the Creator is invited to follow. Therefore a Creator:

1. Selects the DCI from a number of available DCI templates

2. Gets Resources with corresponding Identifiers, e.g. from outside the CCD

3. Encrypts Resources (optional)

4. Fills the Metadata template for each Resource

5. Obtains Metadata Identifiers (optional)

6. Makes a License, e.g. by selecting one from a number of available License templates

7. Obtains a License Identifier from a License Identification Device

8. Adds License or License information within the DCI

9. Obtains Content Identifier from a Content Identification Device

10. Creates a DCF

11. Stores the DCF on a Content Provider Device.

2.3.6.3 Content Identification Device

The current phase of DMP specifications does not provide a Protocol for a Content Creation Device to obtain a Content Identifier.

2.3.6.4 Content Provider Device

A Content Creation Device Delivers Content to a Content Provider Device. A Content Consumption Device (SAV or PXD) Accesses Content from a Content Provider Device employing Access Protocols specified by Approved Document No. 3.

2.3.6.5 License Provider Device

In case Licenses are not Bundled within the Content, Licenses are Stored on a License Provider Device and may be Accessed by a Content Consumption Device employing Access Protocols specified by Approved Document No. 3.

In case Content is Licensed to a Domain, the License Provider Device requests appropriate information from the Domain Management Device (see below).

2.3.6.6 Role Verification Device

This Device responds to queries made by other Devices to verify the appropriate relationships between Roles, RRD Functions and IP Entities. For instance a Creator by querying the RVD can know all RRD Functions he can execute.

2.3.6.7 DRM Tool Provider Device

In case DRM Tools are not Bundled within the Content, DRM Tools are Stored on a DRM Tool Provider Device and may be Accessed by a Content Consumption Device employing Access Protocols specified by Approved Document No. 3.

2.3.6.8 PAV eXternal Device

PAV Devices do not have network or broadcast connections to Access Content or License. However, they can be connected to a PAV eXternal Device (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 11 – A PAV and its PXD

Two cases can be considered

1. In the simplest case the PXD Accesses a Content Item in the form of a DCF with a License Bundled within it. Content can then be Copied/Moved to the PAV Device, without further action by the PXD, using a Protocol that is not specified by DMP.

2. If the PXD obtains a Content Item in the form of a DCF without a Bundled License, the following steps are performed:

End-User connects his PXD to a Delivery System, e.g. Memory module, the Internet or a Broadcast channel;
End-User activates a browser;
End-User selects a Service;
End-User select a Content Item (without a License Bundled within it);
End-User Stores the selected Content in the PXD;
End-User plugs his PAV in the PXD;
End-User Accesses the License from License Service Provider;
PXD Bundles the License within the Content;
PXD makes a DCF;
DCF is Copied/Moved to PAV as in case 1.

2.3.6.9 Content Consumption Device (PAV)

To Store Content on a PAV Device the following steps are performed:

1. End-User plugs his PAV to the PXD;

2. End-User activates an application on the PXD that connects the PXD to the PAV;

3. The application displays a list of the DCFs on the PXD that are available for Use on the PAV;

4. End-User selects the DCFs to his liking;

5. End-User activates Move/Copy of those DCFs from PXD to PAV.

To Use Content on the PAV Device the following steps are performed:

1. End-User activates GUI

2. GUI

a. Reads the files Stored in PAV

b. Make a list using information from Metadata in each DCF

3. End-User selects DCF

4. PAV

a. Parses DCF to obtain DCI

b. Parse DCI to obtain

i. License

ii. Metadata

iii. Resource

c. Parses License to obtain DRM Information

5. GUI displays the list of Functions that can be executed and Metadata

6. User selects the Function

7. PAV

a. Decrypts Resource

b. Decodes Resource

c. Renders Resources.

2.3.6.10 Content Consumption Device (SAV)

Once a SAV has Accessed the Content, and the necessary License and DRM Tools using the Access Protocols specified in Approved Document No. 3, it can Use the Content, e.g. Play, Store or Adapt it in the SAV or Move/Copy the Content or its Adaptation to another SAV or PAV as per License terms.

These are Functions a SAV Device performs on a Content Item, in addition to the steps listed in the walkthrough of the DRM Tool Model:

1. Decrypt Resources

2. Decode (decompress) Resources

3. Deliver decompressed Resources for Rendering

4. Create DCF with Bundled License

5. Store DCF

6. Move or Copy the DCF to another SAV or a PAV

7. Adapt Content

8. Encrypt Resources.

The figure below is a conceptual model of a SAV

Figure 12 – Conceptual model of a SAV

In many instances a SAV interacts with other Devices through Interfaces defined as in the figure above. In other instances it may be useful to define interfaces between processing elements such as the DRM Processor and the Resource Processor of Fig. 13.

Figure 13 – DRM Processor and Resource Processor in a SAV

A separation between the Resource Processor and the DRM Processor increases flexibility as the vendor of the Resource Processor does not need to be concerned with the various types of DRM Processors. Likewise, the vendor of the DRM Processor does not have to be concerned with the properties of each Resource Processor. As a result, this architecture reduces the cost of integrating the DRM and Resource Processors. To achieve this, a standard Interface between both Processors and an appropriate Protocol is essential.

2.3.6.11 Domain Identification Device

See Domain Model below.

2.3.6.12 Domain Management Device

See Domain Model below.

2.3.6.13 Secure implementation of Devices

Device Certification Agencies have the task of checking the implementation of a Device and Certify that it can be Trusted up to a certain level. While a pure software implementation satisfies the DMP definition of Device, it is clear that, to operate, a complete Device must be complemented by a hardware component.

The Trusted Computing Group (TCG) has issued specification of a trusted computing platform consisting of two stacks, one is the software stack which is called “Trusted Software Stack (TSS)” and the other one is the hardware stack called “Trusted Platform Module (TPM)”. The TCG model is compatible with the DMP model in that both the TSS and the TSS can be “Devices”.

In the following some information on the TCG model is provided to clarify the role of the DMP reference software (Chillout).

The TPM provides four main functionalities implemented as hardware stack:

1. System integrity evaluation: a TPM can find that the BIOS, the OS or the software is falsified by storing the hash of these software stacks when they are correct;

2. Platform certification: a TPM can generate a secret key and store it securely in order to ensure that the correct TPM is used;

3. Secure storage: to store encryption keys, which is super-ciphered by TPM secret key;

4. Crypt-coprocessor: this contains RSA engine, Random Number Generator, Hash and so on..

TPM functionalities can be used through TSS software stacks, the APIs of which are also defined by TCG.

Devices can store any number of encryption Keys in the secure storage of the TPM. When a Device wishes to store a Keys, an application can use the TPM secret Key in order to encrypt them.

Figure 14 – Secure key storage

The hashes of the BIOS, OS and software stacks are registered in the PCR (Platform Configuration Register). So if a Device needs to Verify the TPM it requests the value of the PCR and compares it with the value of the PCR stored at the time it was shipped. If the received value of the PCR is equivalent to the stored value of the PCR, Verification succeeds.

Figure 15 – TPM Verification

In order to use the TCP, Devices should only use the TSS API when they wish to use TPM functions.

The Chillout Reference Implementation is a Java based software. A TSS Java wrapper is available as Open Source software. The trusted computing architecture is shown in Fig.15.

Figure 16 – Java based trusted computing

If the DMP Reference Software (Chillout) will adopt trusted computing technology, most of the existing software stacks are still useful. However, when Chillout stacks uses TPM functions, Chillout stacks should provide the functionality to use the TSS API.

2.3.7 Domain Model

Domains are groups of Devices or Users sharing some common properties. 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 Devices (SAV), belonging to two different End-Users;

2. One Device (PAV) belonging to another End-User connected to the network via a PXD;

3. One Device (SAV) belonging to another End-User and remotely connected to the other Devices in the Domain via the Internet.

Figure 17 – An example of Domain

In general 5 Device types are required to manage a Domain:

1. Domain Management Devices (DMD), to manage the life cycle of Domains and the list of Devices and Users belonging to the Domains;

2. Domain Identification Devices (DoID), to Assign Globally Unique Identifiers (GUID) to DMDs on behalf of Domain Registration Agencies;

3. End User Devices (EUD), e.g. SAV or PXD;

4. Users, bearing in mind that Users are represented by e.g. a device (smart card etc.) or an identity on a Device (UN/PW etc.);

5. License Provider Devices (LPD) to provide Licenses including for Use of Content in a Domain.

The combined operation of these Devices can be shown by a simple walkthrough in the figure below:

Figure 18 – The relationship of the 5 Device types in Manage Domain

1. A User (Domain Administrator) requests DMD to create a Domain

2. DMD

a. Creates Domain

b. Obtains Domain ID from Domain Identification Device;

c. Creates Domain Information containing Device/User list, maximum number of Devices/Users etc.;

d. Creates Domain Context for Device/User containing Domain ID, DMD ID, Domain Private Key, expiration etc.;

e. Delivers AccessID and AccessPassword to Domain Administrator;

f. Delivers Domain Context for Device/User to Device/User;

3. Device/User requests License to License Provider Device giving Domain ID;

4. License Provider Device sends Domain ID to DMD;

5. DMD Delivers Domain Public Key to LPD;

6. License Provider Device makes and Delivers License to Device/User.

Note: A Domain Management Device can manage one or several Domains. Ownership of a DMD can be implemented using a variety of mechanisms, e.g. End-User based or Service Provider based.

2.3.8 Import/Export Model

The DMP specifications enable Users to set up Value Chains and perform Functions in an Interoperable fashion. There may be, however, cases in which a Device needs to access governed content from a value-chain. An example, explicitly considered by Approved Document No. 3, is when a SAV accesses governed content broadcasted with a license expressed using the RMPI Rights Expression Language [35].

In this case 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.

Approved Document No. 3 specifies the Tools to convert a license expressed using RMPI to a License.

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

2.3.9 Data Model

Approved Document No. 3 specifies the Representation of the following data types:

Table 4 – IDP-2 Data types

Content	A DMP-defined structure of Content Elements, i.e. Resource, Metadata, Content, License, DRM Information, DRM Tool and Use Data
Identifier	The unique signifier Assigned by Identification
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
Metadata	Data that describe Content and Content Elements
DRM Information	Data that describe Governance of Content
DRM Tool	An algorithm which implements one or more DRM Functions
DRM Tool Body	An executable computer code that implements a DRM Tool
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
Key	Data used by a cryptographic method to make Clear-text Data Encrypted or, conversely, Encrypted Data Clear-text
DRM Message	A message exchanged between DRM Tool Bodies, DRM Processor and Devices
Device Information	Data characterising a Device, e.g. CPU, OS etc.
Domain Information	Data characterising a Domain that is Stored in a Domain Management Device, e.g. the list of Devices, Users, Domain Key etc.
Use Data	Data documenting the Functions performed by a Device Entity on a Content Item and the associated context
DCI Signature	Data Encrypted with a Private Key and appended to a DCI for the purpose of guaranteeing the Integrity of the DCI
DCI Hash	A number generated by applying a mathematical formula to a DCI

The following table describes which Content Elements can be contained in another Content Element

Table 5 – IDP-2 Content Elements

Content Elements	Content Elements contained
Content	· Identifier · Resources · Metadata · DRM Information · DRM Tool · DRM Tool Body · License · Key · DRM Message · Authentication Message · Device Information · Domain Information · Use Data · DCI Signature · DCI Hash
Identifier
Resources	· Identifier · Metadata · DRM Information
Metadata	· DRM Information
DRM Information	· DRM Tool · License · Key
DRM Tool	· DRM Tool Body · Device Information · DRM Message
DRM Tool Body
License	· Key
Key
DRM Message	· Key · Authentication Message
Device Information
Domain Information	· Key
Use Data
DCI Signature	· Key
DCI Hash

2.4 Platform Tools

This section provides a high-level description of the three types of Tools specified by Approved Document No. 3: Represent, Protocols and Package.

2.4.1 Represent

2.4.1.1 Content

The digital Representation of Content is called DMP Content Information (DCI). The DCI is an XML structure specifying Content Identifiers, DMP-specific information, DRM information and Licenses with Content and Content Elements. See figure below for a graphical representation of a particular DCI.

Figure 19 – An example of DMP Content Information (DCI)

Approved Document No. 3 adopts a subset of the MPEG-21 Digital Item Declaration for the DCI [21].

2.4.1.2 Identifier

To be Used in Value-Chains, Content Items should be unambiguously Identified for a given lifetime and within pre-assigned boundaries. Allocation of Identifier achieves this goal if the following aspects are guaranteed:

1. Persistence, i.e. the Identifier should be used as a reference to the Content Item even beyond the lifetime of the Content Item it Identifies

2. Uniqueness, i.e. the Identifier should be used across Users or globally.

Every Content Item expressed by a DCI contains a unique Identifier Assigned by a special type of User (Registration Agency). Approved Document No. 3 provides ways to Identify a Resource by means of its original Identifier inside the DCI (e.g. ISWC, ISRC) or other Metadata.

Approved Document No. 3 bases its Data Identification on the principles of MPEG-21 Digital Item Identification [22].

2.4.1.3 Resources

Resources can be typical media resources, but also DRM Tools, i.e. the executable code that is needed by a Device to Process protected Resources. As Creation and Identification of Resources are outside of the current scope of Approved Document No. 3, no Tools to Represent and Identify Resources are provided.

2.4.1.4 Metadata

Approved Document No. 3 adopts a subset of TV Anytime Metadata [35] as the default Metadata specification for Media Resources. Note that AD 3 supports the use of other metadata schemes.

2.4.1.5 DRM Information

DRM Information is the set of data resulting from implementing the rules to manage and protect any part of a DCI. It may include any information in the DCI, e.g.:

· Content Governance Information, including the signalling of the DRM Tools required to Access Content

· Decryption Keys

· Licenses

· Data for DRM Tools’ initialisation and configuration

· Appropriate Metadata

· Etc.

2.4.1.6 DRM Tool

DMP calls an executable computer code that implements a DRM Function a “DRM Tool Body”. This may be resident in a Device or contained or referenced in a DCI.

2.4.1.7 License

Approved Document No. 3 can support a wide range of business models ranging from the simple and straightforward usage models currently familiar to End-Users to innovative and possibly even speculative business models. Therefore the expression of Rights that may be required between any Users in a Value Chain and the nature and complexity of the Rights expressed may be dependent upon the role of the Users involved in this exchange.

In a Governed Content Item, the relevant Governance information is expressed within the DCI or referenced using Permissions expressed in REL statements. In order to be able to Access Governed and protected Resources, the User is required to have obtained the necessary Keys and Certificates as stipulated by the License. If the Keys are not Bundled within the DCI, they can be obtained as stipulated by the License Provider.

DMP employs two Profiles of the MPEG-21 Rights Expression Language (REL). The first (core profile) can be used in reduced-capability Devices such as PAVs. IDP-2 extends the MPEG-21 REL Dissemination and Capture (DAC) Profile [25], in order to support DMP Domain requirements.

The one-to-one association of Licenses to Content Items may entail significant logistic problems. Therefore IDP-2 also provides Tools to support alternative License distribution scenarios:

Table 6 – License Distribution Scenarios

License to	Description	Issues
1 Device	A Content Item is Licensed for Use on one specific Device.	Device requires a unique ID or certificate. Content must be re-Licensed for each new Device.
N Devices	A Content Item is Licensed for Use on multiple Devices.	Same as single Device. Reduced need to re-License Content as it can be Used on more than one Device.
Domain	A Content Item is Licensed to a Domain, i.e. Content can be Used on any Device within that Domain.	Content does not need to be re-Licensed, rather a Device needs to join the Domain. IDP-2 provides specifications for Tools to join and leave a Domain.

2.4.1.8 Key

A Key is Data used by a cryptographic method to make Clear-text Data Encrypted or, conversely, Encrypted Data Clear-text. It can be resident in a secure storage of a Device or be carried by a DCI.

2.4.1.9 Use Data

Currently DMP defines Use Data for the purpose of Domain Management.

2.4.2 Protocols

2.4.2.1 Identify

The following Entities require Identification:

1. Content

2. DRM Tool

3. Device

4. User

5. Domain

2.4.2.1.1 Identify Content

Currently Approved Document No. 3 only specifies the Representation of Content Identification, not the Protocol to request Content Identification.

2.4.2.1.2 Identify DRM Tool

Currently Approved Document No. 3 only specifies the Representation of DRM Tool Identification, not the Protocol to request DRM Tool Identification.

2.4.2.1.3 Identify Device

Device Identification is used for following purposes:

Authentication	The Licence Provider needs to verify that the target Device can properly Use Governed Content, i.e. the Licence Provider needs the Device Identifier to enable Authentication
Authorisation	The Device Identifier is important information for a User with appropriate authority to allow or disallow specific Devices to Render Governed content
Domain Management	The Device Identifier is used to Identify Devices belonging to a specific Domain in which various Devices can be Registered and managed
Audit	The Device Identifier is used to Identify participant Devices on Use of Governed Content if the audit record needs to be kept
License Backup/Restore	Use of Governed Content is controlled by the License that specifies allowed Device(s). The Device Identifier is used to Identify dedicated Device on Backup or Restoration of the License

Approved Document No. 3 provides Protocols supporting two kinds of Device Identification:

1. “Device info-based identification” in which a Device Identification Device generates the Device Identifier using some vendor specific information;

2. “Certificate-based identification” in which a Certificate is utilised for Device Identifier.

2.4.2.1.4 Identify User

User Identification is outside the scope of DMP.

2.4.2.1.5 Identify Domain

Domain Identification is performed by a Domain Identification Device. Currently Approved Document No. 3 does not specify the Protocol for a Domain Management Device to request Domain Identification.

2.4.2.2 Authenticate

The following Entities: Devices, Users and DRM Tools need to establish Trust between themselves before they may perform DRM-related Functions.

2.4.2.2.1 Authenticate Device

Approved Document No. 3 specifies a Protocol to Authenticate Devices having unique Certificates.

2.4.2.2.2 Authenticate User

User Authentication is outside the scope of DMP.

2.4.2.2.3 Authenticate DRM Tool

These Protocols are currently part of Manage DRM Tool Protocols.

2.4.2.3 Negotiate

This includes the following Protocols:

1. Protocol to Negotiate Licence to Use a Content Item

2. Protocol to Negotiate Licence to Use a Use Data Item

3. Protocol to jointly Negotiate Licence to Use a Content Item against a Licence to Use a Use Data Item

These Protocols are currently unspecified.

2.4.2.4 Deliver

The following Protocols are required by the IDP to Deliver Content. Those marked in normal are provided by Approved Document No. 3, Those marked in italic will be provided by future versions.

Table 7 – Definitions of types of Delivery

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
Move	The Function consisting of the following actions 1. Copy of Content from a source Device to a destination Device 2. Deletion of said Content in the source Device
Copy	The Function that 1. Duplicates Content 2. Delivers the duplicate to another Device
Export	The Function of making available a Content Item to a non-DMP DRM system
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 the duplicate(s) to another location that is not a Device
Access	The Function executed by a Device when making Content available to so that the Device can execute Functions on it
Import	The Function of Accessing a governed content item from a non-DMP DRM system
Restore	The Function of Moving Content and the associated Stateless Rights Expression, if any, to the Device from which Backup had been performed

2.4.2.4.1 Access

Approved Document No. 3provides the following Access Protocols:

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

Additionally the following Local Access Protocols are defined

1. Local License Access Protocol

2. Local DRM Tool Body Access Protocol

2.4.2.5 Manage DRM Tool

To facilitate the cooperation of multiple DRM Tools to perform DRM-related Functions on Governed Resources, Approved Document No. 3 provides a message-based architecture. Such messages are XML structures allowing the exchange of information between various components of a Device, e.g. the DRM Processor and a DRM Tool, or between two DRM Tools.

The following is a non-exhaustive list of Functions enabled by the messages defined in DMP Manage DRM Tool namespace:

· A DRM Tool may require to be informed of all the other DRM Tools operating at any time

· A DRM Tool may require to be notified when a new DRM Tool is instantiated

· A DRM Tool may require the instantiation of another DRM Tool

· A DRM Tool may require the termination of another DRM Tool

· A License or any part of it may be exchanged between two parties

· A Decryption Key, along with the timing information about its use, may be exchanged between two parties

· The results of a watermarking operation may be communicated

· Two DRM Tools may mutually authenticate

2.4.2.6 Manage Domain

Approved Document #3 provides a set of protocols that can be used to manage a Domain. See Domain Model.

2.4.3 Package Content

For the purpose of Delivery, Content typically needs to be Packaged. Currently Approved Document #3 provides Tools to Package Content for File (DCF), Broadcast (DCB) and Stream (DCS).

2.4.3.1 DMP Content File

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 [28]. 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 20 – Conceptual diagram of DMP Content Format (DCF)

2.4.3.2 DMP Content Stream

A number of transport mechanisms may be employed to transmit digitally Represented Content (DCI) between Devices. Currently those of highest relevance are 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 packet-based transmission protocols, Content must be packetised and then transmitted incrementally to the receiving Device. As Content is a combination of Content Elements, transmitting Content in a streaming fashion implies packetisation of its Content Elements.

Approved Document No. 3 specifies the means to incrementally transmit a DCI (including 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) [30]. The DIS standard specifies a Bitstream Binding Language (BBL) using which it is possible to describe 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.

Figure 21: Streaming a DCI using Digital Item Streaming

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

DIS can also be used to Package binary objects over a streaming protocol. BBL uses BS Schema from MPEG-21 Digital Item Adaptation (DIA) [27] to specify the structure of binary resources which are to be streamed using BBL. This enables fragments of a binary resource to be specified using XPath [44] references.

2.4.3.2.1 Broadcast

1. The figure below shows an example DCI related to TV program P1.

Figure 22 – Conceptual diagram of DMP Content Broadcast (DCB)

In this example Program P1 is composed of:

1. Metadata of the TV program P1 (green box)

2. Metadata of the video stream (DMP Infored box)

3. Pointer to the video stream in the MPEG-2 Transport Stream

4. Metadata of the associated audio stream (DMP Infolight blue box)

5. Pointer to the audio stream in the MPEG-2 Transport Stream

6. Metadata of the audio-visual stream (DMP Info)

7. License of the audio-visual stream

8. Metadata of the DRM Tools (DRM Info)

9. The actual DRM Tools carried as Resources in the DCI.

P1 is Governed as a whole, therefore only one single license and a single DRM Information element are needed. An alternative DRM configuration not contemplated in this figure but still possible using IDP-2 Tools shows Resources Governed individually by an appropriate License and each characterised by appropriate DRM Information.

Approved Document No. 3 provides Tools to carry DCB on MPEG-2 Transport Stream.

2.4.3.2.2 Stream

In the figure below the DCI of Content streamed comprises

1. Metadata of the streaming Content as a whole

2. Metadata of the video stream (DMP Info)

3. Pointer to the video stream in the RTP Stream

4. Metadata of the associated audio stream (DMP Info)

5. Pointer to the audio stream in the RTP Stream

6. Descriptor of streaming text

7. Pointer to the streaming text in the RTP Stream

8. License of the Governed video stream

9. Metadata of the DRM Tools (DRM Information) Governing the video Resource

10. The actual DRM Tools for the Video Resource carried as Resources in the DCI.

Figure 23 – Conceptual diagram of DMP Content Streaming (DCS)

Approved Document No. 3 provides Tools to carry DCS on RTP.

3 Interoperable DRM Platform

3.1 Introduction

This Approved Document No. 3 – Interoperable DRM Platform (IDP), provides specifications of basic standard technologies – called Tools – that are required to build Value-Chains. Examples of Value-Chains can be found in Approved Document No. 4 – Use Cases and Value-Chains – where it is shown how a selected number of Use Cases can be implemented employing Tools specified in this Approved Document No. 3. Of course other Value-Chains of interest to Users can be implemented employing IDP Tools.

For ease of treatment Tools are grouped in categories. In this Phase 3.0 of IDP (IDP-3.0) the following categories of Tools are specified:

1. Represent

o Content

o Metadata

o DCI Signature

o DCI Hash

o Identifier

o Resources

o DRM Information

o DRM Tool

o DRM Tool Body

o License

o Key

o DRM Messages

o Authentication Messages

o Device Information

o Domain

o Domain Protocols

o Use Data

o Access Protocols

o Binary XML

2. Protocols

o Identify

§ Device

§ User

o Authenticate

§ Device

§ User

o Manage

§ Domain

§ DRM Tool

o Access

§ Content

§ License

§ DRM Tool Body

§ Key

3. Package

o Content as File

o Content as Stream

In this Approved Document “chapters” will deal with categories and “sections” with “Tools”.

Whenever possible DMP Approved Documents do not specify new technologies, but adopt existing technologies. Therefore a number of Tools specified in this Approved Document contain references, restrictions, extensions or adaptations of technologies already standardised by other bodies. There are, however, also cases of technologies that are originally specified in this Approved Document.

Proper understanding of this Approved Document is facilitated by a careful reading of the Foreword to the Approved Document No. 3, of Approved Document No. 2 – Architecture and of Approved Document No. 6 – Terminology. Introductory information on some referenced standards, recommendations and specifications is provided in Annex A. However, proper understanding requires working knowledge of such referenced documents.

3.2 Represent

In this specification, the term Represent is used to describe the function of expressing information in a form that can be processed by a machine. This information relates to DMP Content Elements by conveying parameters and values between machines associated with the Content Elements.

This chapter specifies how to Represent various DMP Content Elements, some of their components and other Data that can be exchanged between Users. These are listed in the following table.

Table 8 – Data Represented in this specification

Content	The overall structure of Content Elements and their components.
Metadata	Metadata Representation within Content and a DMP Format
DCI Signature	Description of the digital Signature of the DCI and representation within Content
DCI Hash	Description of the Hash of the DCI and representation within Content
Identifier	Description of Identifier format and representation within Content
Resource	Description of Resource Elements as an element within Content
DRM Information	The grouping together of information associated with the Governance of Content
DRM Tool	Software modules performing one or more DRM Functions such as Authentication, Decryption, watermarking, etc.
DRM Tool Body	Data associated with specific instantiation of DRM Tools
License	The representation of the DMP License
Key	The representation of the Key data
DRM Messages	Messages exchanged between DRM Tools or between a DRM Tool and a DRM Processor.
Authentication Messages	Messages exchanged between two entities to mutually Authenticate
Device Information	The parameters required to describe the Device characteristics
Domain	Information relating to the management of Domains
Domain Protocols	Information exchanged between Devices while performing Domain-related Protocols
Use Data	The Use data Representation
Access Protocols	Information exchanged between Devices while performing Access-related Protocols
Binary XML	A format for Representing Binarised XML

The Representation of the Content and Content Elements is made up of XML schema, defined using the W3C XML schema language as specified in [44].

This Represent Section specifies a number of XML Schema, some of which are devised by the DMP and some of which are profiles of existing specifications or are adopted directly from existing specifications.

The table below summarises the namespace URIs of the schemas developed by the DMP. The column on the left indicates in which phase of IDP the schema has been developed. The column on the right indicates the namespace prefix used within this specification.

Table 9 – URIs of DMP-defined schemas.

Namespace URI	Namespace prefix
urn:dmp:idp:mediastreaming:accessprotocol:extensions:2007	dmp-msapx
urn:dmp:idp:Represent:ContentIdentifierProtocol:2007	dmprcip
urn:dmp:idp:Represent:DeviceIdentifierProtocol:2007	dmprdip
urn:dmp:idp:Represent:License:2007	dmprl
urn:dmp:idp:Represent:StoreContentProtocol:2007	dmprscp
urn:dmp:idp:Represent:StoreLicenseProtocol:2007	dmprslp

The following table summarises the namespace URIs of those schemas referenced by this specification.

Table 10 – URIs of referenced schemas

Namespace URI	Namespace prefix
urn:mpeg:mpeg21:2007:01-BBL-NS	bbl
urn:mpeg:mpeg21:2003:01-DIA-NS	dia
urn:mpeg:mpeg21:2006:07-DIDL-NS	didl-msaf
urn:mpeg:maf:schema:mediastreaming:DIDLextensions	didl-msx
urn:mpeg:mpeg21:2002:02-DIDMODEL-NS	didmodel
urn:mpeg:mpeg21:2002:01-DII-NS	dii-msaf
urn:mpeg:mpeg21:2005:01-ERL-NS	erl
urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS	ipmpdidl-msaf
urn:mpeg:mpeg21:2004:01-IPMPINFO-NS	ipmpinfo-msaf
urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007	ipmpinfo-msx
urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007	ipmpmsg
urn:mpeg:mpeg4:IPMPSchema:2002	mpeg4ipmp
urn:mpeg:mpeg7:schema:2001	mpeg7smp
urn:mpeg:mpeg7:smp:schema:2001	mpeg7smp
urn:mpeg:maf:schema:mediastreaming:accessprotocol:2007	msap
urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007	msbp
urn:mpeg:maf:schema:mediastreaming:domain:2007	msd
urn:mpeg:maf:schema:mediastreaming:domainprotocol:2007	msdp
urn:mpeg:mpeg21:2005:01-REL-M1X-NS (*)	rel-m1x-msaf
urn:mpeg:mpeg21:2006:01-REL-M2X-NS	rel-m2x
urn:mpeg:mpeg21:2006:01-REL-M3X-NS	rel-m3x
urn:mpeg:mpeg21:2003:01-REL-MX-NS (*)	rel-mx-msaf
urn:mpeg:mpeg21:2003:01-REL-R-NS (*)	rel-r-msaf
urn:mpeg:mpeg21:2003:01-REL-SX-NS (*)	rel-sx-msaf
urn:tva:metadata:2002	tva
urn:mpeg:maf:Profile:mediastreaming:tva:2007	tva-msaf
urn:mpeg:mpeg21:2003:01-DIA-NS	ued
http://www.w3.org/2000/09/xmldsig#	dsig
http://www.w3.org/2001/04/xmlenc#	xenc

(*) These namespaces refer to the REL schemas with validation rules defined in [25] joined with those defined in [26].

3.2.1 Represent Content

Represent Content defines the basic structure for any information related to Content, which may contain, in turn, a number of other Represent technologies. The Figure in Approved Document #2 Architecture provides an example of the hierarchy of the “Represent” technologies, when these are employed to Represent Content.

The actual hierarchy may differ depending on the structure of each Content Item, e.g. the order in which the various “Represent” technologies are employed. Also the Representation of different Content Elements may:

1. recur more than once in a Content Item

2. not recur at all

3. appear in different places depending on the hierarchy

See, for example the block “Represent Key” which appears nested in two different Represent blocks.

DMP defines Content as a structured combination of Content Elements. The Representation of these elements is specified in the remaining parts of the Represent chapter. When represented together these elements are ordered within a larger framework specified here as Represent Content.

DMP refers to the Content Representation Tool as “DMP Content Information” (DCI).

Specifically, this section provides the means to:

· convey Identifiers of Content and Content Elements

· associate DMP-specific information and Metadata with Content and Content Elements

· associate DRM Information with Content and Content Elements including

o DRM Tools,

o Licenses

o Device Information

o Keys

· associate digital signatures with the DCI

· associate hash values with the DCI

Note that the Represent Content Tool defined here enables the organisation of the Content Elements that together make up the Content and is independent from the Packaging used for Content Delivery, i.e. file, broadcast or network transport.

The DCI is an XML structure, based on the MPEG-21 Digital Item Declaration Language (DIDL) [21], in particular by the DIDL profile and extensions defined by the Media Streaming Application Format standard (MSAF) [31]. Annex A provides introductory information on the Digital Item Declaration Language.

In its entirety, the DMP Content Information (DCI) consists of both the Representation of the various DMP ‘Tools’ and the DCI framework for assembling these Represented Elements as Content. The following sub sections describe the locations of Content Elements Represented by this specification within the DCI XML structure. The description of the Representation of these Content Elements follows later in the subsequent parts of this section.

3.2.1.1 The DCI Structure

The top level element in a DCI is always a didl-msaf:DIDL element, except in those cases where a DCI is nested within another DCI, in which case the top-level element of the nested component is a didl-msaf:Item element. The didl-msaf:DIDL element is specified in the figure below:

</sequence>

</complexType>

Figure 24 The didl-msaf:DIDL element

A didl-msaf:DIDL element may contain any number of didl-msaf:DIDLInfo elements and one didmodel:Item. The DIDL element can have an arbitrary number of attributes from a namespace other than the target namespace or from a null namespace.

The didl-msaf:DIDLInfo element is specified in the figure below below:

</sequence>

</complexType>

Figure 25 The didl-msaf:DIDLInfo element

The DIDLInfo element may contain a Digital Signature associated with the DCI or parts thereof.

A didl-msaf:Item is specified below:

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 26 The didl-msaf:Item element

A didl-msaf:Item element may contain one or more didl-msaf:Descriptor elements, and zero or more choices between a didl-msaf:Item and a didl-msaf:Component element. A top-level didl-msaf:Item element Represents the Content Item. A didl-msaf:Item element child of another didl-msaf:Item element Represents a Content Element, eg a Resource or another Content Item.

A didl-msaf:Descriptor is specified below:

</sequence>

</extension>

</complexContent>

</complexType>

Figure 27 The didl-msaf:Descriptor element

A didl-msaf:Descriptor element is a container for a didl-msaf:Statement element.

A didl-msaf:Statement is specified below:

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 28 The didl-msaf:Statement element

A didl-msaf:Statement element can contain any of the following:

dii-msaf:Identifier, the container for the Identifier of a Content Item or a Content Element. See Section 3.2.5 – Represent Identifier.
dii-msaf:RelatedIdentifier, the container for the Related Identifier Identifier of a Content Item or a Content Element. See Section 3.2.5 – Represent Identifier.
didl-msx:Metadata, a top level container for Metadata and other information. See Section 3.2.2 – Represent Metadata.
ipmpinfo-msaf:IPMPGeneralInfoDescriptor, the container for general DRM Information related to the Content Item and all its Content Elements. See Section 3.2.7.3 – Represent General DRM Information.
ContentElementSignature: A container for the digital Signature or Hash value of the Resource (e.g. audio-visual resource, executable file, etc...) Represented by the Item containing the didl-msaf:Statement

For each didl-msaf:Statement element it is possible to specify a mimeType attribute specifying the mimeType of the content of the Statement, and a URI for the schema in use within the Statement.

A didl-msaf:Component is specified below:

</sequence>

</extension>

</complexContent>

</complexType>

Figure 29 The didl-msaf:Component element

The didl-msaf:Component element is a container for one or more didmodel:Resource elements. See 3.2.6 – Represent Resource for more information.

3.2.1.2 Location of Identifiers

This sub section describes the location of the Content Identifier in the DCI. Other aspects of Content Identification, namely Represent Identifier (syntax) and Protocol to Assign Identifier to Content are specified in Sections 3.2.5 and 3.3.1, respectively.

3.2.1.2.1 Location of Identifier for Content Item

The Identifier for a Content Item is located within the DCI according to MPEG-21 Digital Item Identification [22] as shown in the example below.

<didl-msaf:DIDL>

<didl-msaf:Item>

<didl-msaf:Descriptor>

<didl-msaf:Statement mimeType="text/plain">

<dii-msaf:Identifier> </dii-msaf:Identifier>

</didl-msaf:Statement>

</didl-msaf:Descriptor>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 30 Location of Identifier for a Content Item

3.2.1.2.2 Location of Identifiers for Content Elements

Identifiers for Content Elements are located within the DCI according to MPEG-21 Digital Item Identification [22] whose schema is defined in C.6, as shown in the example below.

<didl-msaf:DIDL>

<didl-msaf:Item>

<didl-msaf:Item id = book1>

<didl-msaf:Descriptor>

<didl-msaf:Statement mimeType="text/plain">

<dii-msaf:Identifier>  </dii-msaf:Identifier>

</didl-msaf:Statement>

</didl-msaf:Descriptor>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 31 Location of Identifier for a Content Element

3.2.1.3 Location of Metadata

The location of metadata within the didl-msaf structure is shown below for both the case in which data is related to all the Content Elements within the DCI and the case in which data is related to a specific Content Element within the DCI.

Metadata can be represented in a DMP-native way as specified in Section 3.2.2

3.2.1.3.1 Location of Metadata for a Content Item

The Metadata is located within the DCI under the didl-msaf:Metadata element.

The didl-msaf:Metadata element residing at the top level in the DCI is meant to convey Metadata about the whole Content Item, (ie all elements represented within the DCI).

The figure below below shows where the didl-msaf:Metadata element is located in the DCI for this case.

<didl-msaf:DIDL>

<didl-msaf:Item>

<didl-msaf:Descriptor>

<didl-msaf:Statement mimeType="text/plain">

<dii-msaf:Identifier>dmpID:012345</dii-msaf:Identifier>

</didl-msaf:Statement>

</didl-msaf:Descriptor>

<didl-msaf:Descriptor>

<didl-msaf:Statement mimeType="text/xml">

<didl-msx:Metadata>

</didl-msx:Metadata>

</didl-msaf:Statement>

<didl-msaf:Descriptor>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 32: Location of Metadata related to the Content Item

3.2.1.3.2 Location of Metadata for a Content Element

The Figure below shows where the didl-msx:Metadata element for a specific Content Element is located within the DCI in this case.

<didl-msaf:DIDL>

<didl-msaf:Item>

<didl-msaf:Item id="Resource1">

</didl-msaf:Descriptor>

<didl-msaf:Statement mimeType ="text/xml">

<dii-msaf:Identifier>ISWC: 01234567890</dii-msaf:Identifier>

</didStatement>

</didl-msaf:Descriptor>

<didl-msaf:Descriptor>

<didl-msaf:Statement mimeType="text/xml">

<didl-msx:Metadata>

</didl-msx:Metadata>

</didl-msaf:Statement>

</didl-msaf:Descriptor>

<didl-msaf:Component>

<didl-msaf:Resource ref="funky1.mp3" mimeType="audio/mpeg"/>

</didl-msaf:Component>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 33: Location of Metadata related to a Content Element

3.2.1.4 Location of DCI signatures

DCI signatures can be inserted in a didl-msaf:DIDLInfo element contained in a didl-msaf:DIDL element, as represented in the example below.

<didl-msaf:DIDL>

<didl-msaf:DIDLInfo>

<didl-msaf:DISignature>

<dsig:SignedInfo>

<dsig:CanonicalizationMethod Algorithm=""/>

<dsig:SignatureMethod Algorithm=""/>

<dsig:Reference>

<dsig:DigestMethod Algorithm=""/>

<dsig:DigestValue>888880AB</dsig:DigestValue>

</dsig:Reference>

</dsig:SignedInfo>

<dsig:SignatureValue>098765CC</dsig:SignatureValue>

</didl-msaf:DISignature>

</didl-msaf:DIDLInfo>

<didl-msaf:Item id="A1">

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 34: Location of DCI Signatures in the DCI

3.2.1.5 Location of Resources in the DCI

A Content Item may contain or reference any number of Resources.

A DCI Representing a Content Item which contains a number n of Resources, e.g. an MP3 file and an MPEG-1 video file, is characterised by n didl-msaf:Item elements as child elements of the top level didl-msaf:Item. Each inner Item contains a didl-msaf:Resource element Representing the Resource within a didl-msaf:Component element, as shown in the example below.

<didl-msaf:DIDL>

<didl-msaf:Item id="A1">

<didl-msaf:Item id="B1">

<didl-msaf:Component>

<didl-msaf:Resource mimeType="audio/mp3"/>

</didl-msaf:Component>

</didl-msaf:Item>

<didl-msaf:Item id="B2">

<didl-msaf:Component>

<didl-msaf:Resource mimeType="video/mpg"/>

</didl-msaf:Component>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 35: Location of Resources in the DCI

A DRM Tool Body, i.e. a special code to execute DRM functions, is considered a Resource. However, this Approved Document No. 3 has a dedicated section for Representation of DRM Tool Body which includes the description of the DRM Tool to enable exchange between Devices. The DRM Tools are located separately within the Content as described in Section 3.2.1.7

3.2.1.6 Location of Governed Content Elements

In cases where Content Elements are Governed Content Elements, the DCI elements that denote the locations of the Content Elements within the DCI are substituted for corresponding elements taken from the MPEG-21 IPMP Components, specifically those defined in the ipmpdidl-msaf namespace.

The following elements: ipmpdidl-msaf:Item and ipmpdidl-msaf:Statement can be used in lieu of the elements with the same name defined in the didl-msaf namespace to indicate that the Content Element they Represent is Governed. Therefore the rule specifying the location of an IPMP DIDL element is the same that specifies the position of the element with the same name in the didl-msaf namespace defined in [21] and described in Section 3.2.1.1 – The DCI Structure.

In addition to the element substitution defined, Governed Resources have an extra DCI child element within their respective didl-msaf:Resource; namely the ipmpdidl-msaf:ProtectedAsset child element described in Represent DRM Information section 3.2.7 and shown in Figure 58: The ipmpdidl-msaf:ProtectedAsset element

Metadata can also be Governed. This is described in Section 3.2.7.1 - Represent Governed Elements.

3.2.1.7 Location of DRM Information including DRM Tools

The DCI is able to convey within its structure a number of Content Elements that carry information relating to Governed Content Elements that may be required for correct operation of the IDP. These include Licences and DRM Tools that may be associated with the Use of specific Content Elements. Such items are represented in the DCI by the MSAF profile of the MPEG-21 IPMP information descriptor <ipmpinfo-msx:IPMPInfoDescriptor> as descibed in Section 3.2.7.2

The ipmpinfo-msaf:IPMPInfoDescriptor element is located as a child element of an ipmpdidl-msaf:Info element which, in turn, may be contained in one of the following:

· ipmpdidl-msaf:Item

· ipmpdidl-msaf:Statement

· didl-msx:Metadata

· ipmpdidl-msaf:ProtectedAsset.

The Figure below shows the case where the IPMPInfoDescriptor conveys DRM Information for a Resource.

<didl-msaf:DIDL>

<didl-msaf:Item>

<didl-msaf:Item id="Resource1">

<didl-msaf:Component>

<didl-msaf:Resource mimeType="application/ipmp">

<ipmpdidl-msaf:ProtectedAsset mimeType="video/mpeg">

<ipmpdidl-msaf:Info>

<ipmpinfo-msaf:IPMPInfoDescriptor>...<ipmpinfo-msaf:IPMPInfoDescriptor>

</ipmpdidl-msaf:Info>

<ipmpdidl-msaf:Contents> </ipmpdidl-msaf:Contents>

</ipmpdidl-msaf:ProtectedAsset>

</didl-msaf:Resource>

</didl-msaf:Component>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 36: Example location of an IPMPInfoDescriptor within the DCI

Note: Where a ipmpinfo-msaf:IPMPInfoDescriptor element appears as a child of a didl-msaf:Resource contained in the top didl-msaf:Item (the one referring to the Content Item as a whole), all the Resources part of that Content Item are Governed in the same way as specified in that ipmpinfo-msaf:IPMPInfoDescriptor, hence there is no need to replicate IPMPInfoDescriptors for all Resources, if these are Governed by the same rules.

3.2.1.8 Location of General DRM Information including DRM ToolList

The DCI uses the IPMPGeneralInfoDescriptor to convey lists of all the DRM Tools required to Access all the Governed Content Elements. See Section 3.2.7.3 for a description of the Representation of these components.

The ipmpinfo-msaf:IPMPGeneralInfoDescriptor element is located in a didl-msaf:Statement element which is child of a didl-msaf:Descriptor element describing the top-level didl-msaf:Item in a DCI (the one referring to the Content Item as a whole), as shown in the figure below.

<didl-msaf:DIDL>

<didl-msaf:Item>

<didl-msaf:Descriptor>

<didl-msaf:Statement>

<ipmpinfo-msaf:IPMPGeneralInfoDescriptor>  </ipmpinfo-msaf:IPMPGeneralInfoDescriptor>

</didl-msaf:Statement>

</didl-msaf:Descriptor>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 37 Location of ipmpinfo-msaf:IPMPGeneralInfoDescriptor

3.2.1.9 Location of Licenses

Depending on the scope of a License, this shall be signalled in different positions within the DCI. Licenses are required to;

1. Grant the Right to Use Content

2. Govern the Use of DRM Tools

3. Attribute properties to its Principal

For the first and second case, the location of Licenses is specified in this sub-section, while when the scope of a License is to attribute a property to its Principal, as in the case of a License attributing a User or a Device the property of belonging to a Domain, Licenses are obtained as specified in Section 3.3.3 – Protocols to Manage Domain.

A License (or a reference to a License or a License Service) whose scope refers to the first two cases is signalled by employing the ipmpinfo-msaf:RightsDescriptor element, shown in the Figure below:

</choice>

</sequence>

</complexType>

Figure 38: The ipmpinfo-msaf:RightsDescriptor element

An ipmpinfo-msaf:RightsDescriptor may contain a number of Licenses of type ipmpinfo-msaf:License, which is described below. In addition, the License Provider Device URL from where the License can be retrieved, of type “xsd:anyURI”, can be specified in element ipmpinfo-msaf:LicenseReference.

The ipmpinfo-msaf:RightsDescriptor is one of the nested child elements associated with Governed Content Elements hierarchy described in 3.2.7.1 – Represent Governed Elements, and is a child of the IPMPInfoDescriptor outlined in Section 3.2.7 – Represent DRM Information, located as DRM Information as described in Section 3.2.1.7.

The element ipmpinfo-msaf:License is shown in the Figure below:

</sequence>

</complexType>

Figure 39: The ipmpinfo-msaf:License element

The ipmpinfo-msaf:License element contains an rel-r-msaf:license., as defined in rel-r-msaf Schema [C.22].

In cases where Content is Packaged in a File, Licenses may alternatively be contained in the License_Container Box, as specified in Section 3.4.1.2.9 - License_Container Box.

The following sub-sections examine the cases 1 and 2 above in detail.

3.2.1.9.1 Licenses Granting the Right to Use Content

As specified in Section 3.2.7 – Represent DRM Information, DMP support the Governance of several types of Content Element: didl-msaf:Item, didl-msaf:Statement, didl-msaf:Resource, didl-msx:Metadata. If any of these Content Elements are Governed, their Use may be regulated by a License. The presence of a License in these cases is signalled by the ipmpinfo-msaf:RightsDescriptor in an ipmpinfo-msaf:IPMPInfoDescriptor element contained in an ipmpdidl-msaf:Info element child of any Governed Element.

The example below shows the location of a License governing the Use of a Governed Content Element

<didl-msaf:DIDL>

<didl-msaf:Item id="A1">

<didl-msaf:Item id="B1">

<didl-msaf:Component>

<didl-msaf:Resource mimeType="application/mp21-ipmp">

<ipmpdidl-msaf:ProtectedAsset mimeType="video/MP2P">

<ipmpdidl-msaf:Identifier>urn:mpegRA:mpeg21:dii:isan:006A-B</ipmpdidl-msaf:Identifier>

<ipmpdidl-msaf:Info>

<ipmpinfo-msaf:ipmpinfo-msafDescriptor>

<ipmpinfo-msaf:RightsDescriptor>

<ipmpinfo-msaf:License>

<r:license licenseId="012345">

....

</r:license>

</ipmpinfo-msaf:License>

</ipmpinfo-msaf:RightsDescriptor>

</ipmpinfo-msaf:ipmpinfo-msafDescriptor>

</ipmpdidl-msaf:Info>

<ipmpdidl-msaf:Contents ref="myserver.com/coolmovie"/>

</ipmpdidl-msaf:ProtectedAsset>

</didl-msaf:Resource>

</didl-msaf:Component>

</didl-msaf:Item>

</didl-msaf:DIDL>

Figure 40: An Example of License Governing a Content Element

3.2.1.9.2 Licenses Governing the Use of DRM Tools

In those cases where the Use of a DRM Tool is subject to a License, as for instance “DRM Tool T can only work on Devices certified by Agency A”, the License is conveyed by the ipmpinfo-msaf:RightsDescriptor element child of an ipmpinfo-msaf:Tool element.

The following example shows a DRM Tool whose Use is subject to a License that can be obtained from a given License Service.

<didl-msaf:Resource mimeType="application/mp21-ipmp">

<ipmpdidl-msaf:ProtectedAsset mimeType="video/MP2P">

<ipmpdidl-msaf:Identifier>urn:mpegRA:mpeg21:dii:isan:006A-15FAB</ipmpdidl-msaf:Identifier>

<ipmpdidl-msaf:Info>

<ipmpinfo-msaf:IPMPInfoDescriptor>

<ipmpinfo-msaf:Tool>

<ipmpinfo-msaf:RightsDescriptor>

<ipmpinfo-msaf:LicenseReference>

http://www.DRMTools.org/LicenseService

</ipmpinfo-msaf:LicenseReference>

</ipmpinfo-msaf:RightsDescriptor>

</ipmpinfo-msaf:Tool>

</ipmpinfo-msaf:IPMPInfoDescriptor>

</ipmpdidl-msaf:Info>

<ipmpdidl-msaf:Contents ref="myserver.com/mynewmovie"/>

</ipmpdidl-msaf:ProtectedAsset>

</didl-msaf:Resource>

Figure 41: An example of DRM Tool in which Use is subject to a License

3.2.1.10 Location of Key Information

There are two types of Keys identified in this specification: time-dependent and time-independent.

3.2.1.10.1 Time-independent Keys

A non-exhaustive list of locations where such a type of Key is delivered is given below:

in the dsig:Signature element, to specify the Key needed to validate the digital Signature, as specified in [43]
in a License, to identify a Principal, or to convey a Resource Decryption Key, as specified in Section 1 – Represent License.
in a ipmpmsg:KeyData element, for DRM Tool initialisation purposes, as specified in section 3.2.13.3 – Represent DRM Messages.

3.2.1.10.2 Time-dependent Keys

Time-dependent Keys are Represented as specified in Section 3.2.12.2 – Represent Time-dependent Keys and are located within a ipmpmsg:KeyData element for updating the Decryption Key for a DRM Tool used to Decrypt Resources.

3.2.1.11 Location of DRM Tool Body

A DRM Tool Body, the executable instructions implementing a DRM Function, may be conveyed in the DCI enclosed in ipmpinfo-msaf:Binary elements, as shown in the Figure below

<ipmpinfo-msaf:Tool>

<ipmpinfo-msaf:ToolBaseDescription>

<ipmpinfo-msaf:IPMPToolID>urn:Manufacturer:ToolPack:ToolID:ABCDEF9</ipmpinfo-msaf:IPMPToolID>

<ipmpinfo-msaf:ConfigurationSettings>

<ipmpinfo-msaf:Configuration>

<ipmpinfo-msx:ToolBody>

</ipmpinfo-msx:ToolBody>

</ipmpinfo-msaf:Configuration>

</ipmpinfo-msaf:ConfigurationSettings>

</ipmpinfo-msaf:ToolBaseDescription>

</ipmpinfo-msaf:Tool>

Figure 42: An example showing the location of DRM Tool Body

For more information on DRM Tool Bodies, see Section 3.2.9 – Represent DRM Tool Body.

3.2.1.12 Location of Device Information

In order to select an appropriate DRM Tool with matching hardware and software characteristics, Device Information, a set of data describing hardware and software characteristics of a Device, is required. The ipmpinfo-msx:DeviceInformation element may be located in ipmpinfo-msx:Tool or ipmpinfo-msx:ToolPack elements within a ipmpinfo-msx:ToolBody element.

<ipmpinfo-msx:ToolBody>

<ipmpinfo-msx:ToolPack>

<ipmpinfo-msx:DeviceInformation>

<!--See 3.2.14 – Represent Device Information -- >

</ipmpinfo-msx:DeviceInformation>

</ipmpinfo-msx:ToolPack>

</ipmpinfo-msx:ToolBody>

Figure 43: An example showing the location of Device Information

For more information on Device Information, see 3.2.15 – Represent Device Information.

3.2.2 Represent Metadata

The IDP-3.0 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 [36], defined in the tva-msaf namespace and given in Annex C.25. 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 MSAF profile mentioned above are defined as optional (minOccurs=0) in the TV-Anytime specification, and so instance documents conforming to this profile are compatible with the larger TV-Anytime specification.

Metadata is included under the didl-msx:Metadata element defined in the DMP Represent Content namespace and described below:

Metadata:

The didl-msx:Metadata element allows the inclusion of either Governed Metadata or Metadata in clear format. In the first case, Governed Metadata is conveyed as specified in 3.2.7.1 – Represent Governed Elements, while in the second case, Metadata is conveyed in the didl-msx:StructuredData element. A Metadata Identifier can be conveyed by means of the optional attribute "id". Furthermore, a Digital Signature of the whole didl-msx:Metadada element may be conveyed in the dsig:Signature element. The didl-msx:Metadata is shown in the Figure below:

</choice>

</sequence>

</complexType>

Figure 44: The didl-msx:Metadata element

StructuredData:

This element can contain data from any namespace.

The native type of Metadata supported in IDP-3.0 is of type tva-msaf:TVAMain, which is denoted by the attribute 'ref ' value of "urn:dmp:idp2:Represent:Metadata:2006:02". If this attribute is omitted, Metadata contained in tva-msaf:StructuredData is of type tva-msaf. Alternatively, any other Metadata schema can be employed. In this case the attribute 'ref' shall specify the URI of the Metadata namespace employed.

</sequence>

</complexType>

Figure 45: The didl-msx:StructuredData

3.2.2.1 The DMP Profile of TV-Anytime Metadata

The MSAF profile of TV-Anytime Metadata is built upon a modification of the TVA Main type to include only the Copyright, Classification and ProgramDescription elements. The syntax of ipmpmsg:TVAMain element is specified in the Figure below, while for the semantics refer to [35]:

</sequence>

</complexType>

Figure 46: The tva-msaf:TVAMain element

The ProgramDescription element defined in [35] has been reduced to include only the ProgramInformation, GroupInformationTable and CreditsInformationTable elements. The tva-msaf:DMP ProgramDescriptionType is related to the TV-Anytime elements as follows;

</sequence>

</complexType>

Figure 47: The tva-msaf:TVAMain element

Note: Since the elements omitted from the TV-Anytime Specification are all defined as optional, an instance document complying with the DMP profile of the TV-Metadata will also be compliant with a TV-Anytime phase 1 implementations.

3.2.3 Represent DCI Signature

The DCI may be signed by Users who took part in its creation or modification.

A signature is contained in the DISignature element child of a didl-msaf:DIDLInfo element.

3.2.4 Represent DCI Hash

In order to allow for the authentication of the DCI integrity without relying on a signature and 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 for reference along with the associated algorithm.

Hash values can be contained in a DISignature element, as specified in [42].

3.2.5 Represent Identifier

3.2.5.1 Represent Content and Content Elements Identifier

Identifiers for Content or Content Elements (e.g. a Resource) are expressed according to a DMP profile of MPEG-21 Digital Item Identification (DII) [22], as shown in the schema fragment figure below.

</extension>

</simpleContent>

</complexType>

</element>

Figure 48: Identifier and Related Identifier

The dii-msaf:Identifier element contains the Uniform Resource Identifier (URI) of the Content or Content Element, 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).

3.2.5.2 Format of Content Identifiers

The Content Identifier satisfies the characteristics of the URN (Uniform Resource Names) scheme defined in RFC 1737 [37]. Therefore Identifiers that conform to URN schemes can be used to Identify Content. Currently, there are several registered URN schemes such as International Standard Book Number (ISBN) and International Standard Serial Number (ISSN), each of them serving a specific purpose and having a unique namespace under Internet Assigned Numbers Authority (IANA).

The syntax of Content Identifier should be conformant to the URN syntax described in RFC 2141 [39] as follows:

urn:{a urn namespace for dmp}:{a subordinate namespace}:{subordinate-specific Content Identifier}

urn:{a urn namespace for 3rd party}:{namespace-specific Content Identifier}

Figure 49: Content Identifier Syntax

3.2.5.3 Represent License Identifier

As shown in the Figure below, any rel-msaf:License is characterised by a licenseId attribute specifying the Identifier for the License.

<xsd:complexType name="License">

<xsd:choice>

<xsd:sequence>

<xsd:choice minOccurs="0" maxOccurs="unbounded">

<xsd:element ref="r:grant"/>

</xsd:choice>

<xsd:element ref="r:issuer" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:choice>

<xsd:attribute name="licenseId" type="xsd:anyURI" use="optional"/>

<xsd:anyAttribute namespace="##other" processContents="lax"/>

</xsd:complexType>

Figure 50: The rel-msaf:License element

3.2.5.4 Represent Metadata Identifier

Metadata related to a Content Item or to a Content Element shall be inserted in a didl-msx:Metadata element, as specified in Section 3.2.2 – Represent Metadata. Metadata can be identified by means of an attribute to the didl-msx:Metadata element, named didl-msx:id, as shown in the Figure below:

Figure 51: The container for Metadata Identifier

3.2.5.5 Represent DRM Tool Identifier

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.

Figure 52: Tool Identifier Representation

3.2.5.6 Represent Device Identifier

The Device Identifier is Represented by means of the dmprdip:DeviceIdentifier element. The Represent Device Identifier Protocol namespace, dmprdip, defines an abstract base type element from which the rest of the elements are derived. This is the following:

Figure 53: The dmprdip:IdentifierBaseType complex type

A Device Identifier is Represented by the dmprdip:DeviceIdentifier element, as described in the Figure below:

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

Figure 54: The dmprdip:DeviceIdentifier element

The dmprdip:IDType complex type in the Figure above contains the Identifier of the Device, which can be either of type anyURI and conveyed by the id element, or an X.509 certificate, in which case it shall be expressed according to the dsig:X509Data element and conformant to RFC 2459 [41].

3.2.5.7 Represent User Identifier

IDP-3.0 does not provide Tools to Identify Users. However, several IDP-3.0 Use Cases require User Identification. This can be achieved with a variety of technologies such as:

· Certificates

· Globally unique Identifiers

· Devices (Smart cards, USB devices etc.)

3.2.5.8 Represent Domain Identifier

Every Domain of Devices or Users is characterised by Domain Identifier, which is defined in the msd namespace and shown in the Figure below:

</sequence>

</extension>

</complexContent>

</complexType>

</choice>

</sequence>

</complexType>

Figure 55: The msd:DomainID element

For more information on the msd:DomainID element, refer to Section 3.2.16 – Represent Domain.

3.2.6 Represent Resource

A Resource such as an audio track, a video clip, executable code, etc. is Represented in the DCI by the element didl-msaf:Resource, as shown in the box below.

</sequence>

</extension>

</complexContent>

</complexType>

Figure 56: The Resource element

The data type of the Resource represented by the didl-msaf:Resource element is identified by the mimeType attribute, as defined in IETF RFC 2045 [38]. A Resource is either defined in a didl-msaf: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 in the didl-msaf xml document. Lastly, the contentEncoding attribute, if present, specifies the content-encoding(s) as defined in IETF RFC 2616 [40] indicating what additional content-encodings have been applied to the Resource.

3.2.7 Represent DRM Information

DRM Information is the class of information contained in the DCI that relate 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, possibly including decryption Keys and information related to DRM Tool management

3. Placeholders for Licenses when these are Bundled within the DCI (see sub section 3.2.1.9).

DRM Information is expressed in XML and is based on the MPEG-21 IPMP Components [31] profile defined in the MSAF standard, included in Annexes C.8, C.9 and C.10.

The process of indicating that a Content Item or some of its Content Elements are Governed is done using one of the three MPEG-21 IPMP Components technologies described below, depending on the Content Item.

The Digital Media Project

Table of Contents

1 Value Chain Functions and Requirements