The Digital Media Project  






Approved Document No. 1, Draft 2.0 – Technical Specification for Interoperable DRM Platform, Phase I


0321/Adastral Park





Approved Document No. 1, Draft 2.0


Technical Specification for Interoperable DRM Platform, Phase I









Use of the technologies described in this specification may infringe patents, copyrights or intellectual property rights of DMP Members or non-members.

This DMP Technical Specification is subject to change without notice.

Neither DMP nor any of its Members accept any responsibility whatsoever arising out of or in connection with the use of this Technical Specification and the information contained herein for damages or liability, direct or consequential.

Draft 2.0 of this Technical Specification supersedes all previous versions 

Copyright © 2005 – The Digital Media Project








Important notice.

This document has been produced by Ad Hoc Group 04. It builds on the results of General Assembly 05 and technical work up to this period is captured in this working draft. As there have been many contributions to this process based on the development of the DMP ‘Primitive Functions’ this document is not yet in a final specification format. It is however the very first working draft of the technical approach and will be further developed both within the sections and as a complete document in the interim period leading up to GA06.


Comments on this draft are sought from interested parties. Comments should be directed to the DMP Secretariat.


Editor’s notes in [] throughout and are used as an aid to specification development.


[Stuff to do:

Work out consistent section structure (what are section headings? Function or tool or ?), such as Intro, Optional Diagram(s), Requirement(s) Mapping, Rationale, Specification(s), and Optional Example(s).  It is ok to have working notes in the document, especially where we know we are missing details or need more input.]

[Acronyms placed in document or referenced, also defined terms (the first letter uppercase terms, such as “Content”.]

[Needs careful integration with Use Case docs – relating to PAV and requirements driven]




Table of Contents


1      Foreword. PAGEREF _Toc96353835 \h 5

1.1       The Digital Media Project PAGEREF _Toc96353836 \h 5

1.2       DMP Membership. PAGEREF _Toc96353837 \h 5

1.3       DMP Approved Documents. PAGEREF _Toc96353838 \h 5

1.4       Intellectual Property Rights. PAGEREF _Toc96353839 \h 5

1.5       Media and Digital Technologies. PAGEREF _Toc96353840 \h 6

1.6       DRM and the Interoperable DRM Platform.. PAGEREF _Toc96353841 \h 6

1.7       The Toolkit Approach to IDP. PAGEREF _Toc96353842 \h 6

1.8       DRM goes beyond technology. PAGEREF _Toc96353843 \h 7

2      Introduction to this Specification. PAGEREF _Toc96353844 \h 9

3      Identify. PAGEREF _Toc96353845 \h 12

3.1       Identify Content PAGEREF _Toc96353846 \h 12

3.1.1        Overview.. PAGEREF _Toc96353847 \h 12

3.1.2        Characteristics of Content Identifier PAGEREF _Toc96353848 \h 12

3.1.3        The Assignment of Content Identifier PAGEREF _Toc96353849 \h 12

3.1.4        The Syntax. PAGEREF _Toc96353850 \h 12

3.1.5        Examples. PAGEREF _Toc96353851 \h 13

3.2       Identify License. PAGEREF _Toc96353852 \h 13

3.3       Identify Device. PAGEREF _Toc96353853 \h 14

3.3.1        Overview [of Device Identification] PAGEREF _Toc96353854 \h 14

3.3.2        Assumption [about the DMP Environment] PAGEREF _Toc96353855 \h 14

3.3.3        Authenticity of device identifier PAGEREF _Toc96353856 \h 14

3.3.4        Intents [Example uses of this technology in this role] PAGEREF _Toc96353857 \h 14

3.3.5        Function of Device Identification. PAGEREF _Toc96353858 \h 15

3.3.6        Device Info-Based Identification. PAGEREF _Toc96353859 \h 15

3.3.7        Certificate-Based Identification. PAGEREF _Toc96353861 \h 17

3.3.8        Example of Identify Device. PAGEREF _Toc96353862 \h 18

3.4       Identify Domain. PAGEREF _Toc96353863 \h 19

3.4.1        Overview [of Identify Domain] PAGEREF _Toc96353864 \h 19

3.4.2        [Overview of] Identify Domain Manager PAGEREF _Toc96353865 \h 19

3.4.3        Identify Domain Specification. PAGEREF _Toc96353866 \h 19

3.4.4        Identify Device in the Domain. PAGEREF _Toc96353867 \h 20

3.4.5        Identify User in the Domain. PAGEREF _Toc96353868 \h 20

4      Represent PAGEREF _Toc96353869 \h 21

4.1       Represent Content PAGEREF _Toc96353870 \h 21

4.1.1        Introduction. PAGEREF _Toc96353871 \h 21

4.1.2        Identifying DMP Content PAGEREF _Toc96353872 \h 22

4.1.3        Identifying DMP Content Data Elements. PAGEREF _Toc96353873 \h 22

4.1.4        DMP Information. PAGEREF _Toc96353874 \h 23

4.1.5        Signalling DMP information related to the whole DMP Content PAGEREF _Toc96353875 \h 24

4.1.6        Signalling DMP information related to an resource within DMP Content PAGEREF _Toc96353876 \h 25

4.1.7        Governed DMP Content PAGEREF _Toc96353877 \h 25

4.2       Package Content: [ DMP Content Format (DCF)] PAGEREF _Toc96353878 \h 31

4.2.1        Introduction. PAGEREF _Toc96353879 \h 32

4.2.2        ISO Base Media File Format Boxes used in the DCF. PAGEREF _Toc96353880 \h 33

4.3       Represent Rights Expressions. PAGEREF _Toc96353881 \h 35

4.3.1        Introduction. PAGEREF _Toc96353882 \h 35

4.3.2        Scope. PAGEREF _Toc96353883 \h 36

4.3.3        Rights Set to be expressed within this Technical Specification. PAGEREF _Toc96353884 \h 36

4.3.4        Expression of Rights (Rights Information or Expression Language) PAGEREF _Toc96353885 \h 36

4.3.5        REL profile schema for the PAV domain. PAGEREF _Toc96353886 \h 36

4.3.6        License Examples [Using Simple REL] PAGEREF _Toc96353887 \h 39     Play With Conditions (without decryption keys) PAGEREF _Toc96353888 \h 39     Play With Condition (with decryption keys) PAGEREF _Toc96353889 \h 39

4.4       TV-Anytime RMPI PAGEREF _Toc96353890 \h 40

5      Authenticate. PAGEREF _Toc96353891 \h 42

5.1       Authenticate Device. PAGEREF _Toc96353892 \h 42

6      Manage. PAGEREF _Toc96353893 \h 43

6.1       Manage Domain. PAGEREF _Toc96353894 \h 43

6.1.1        Overview.. PAGEREF _Toc96353895 \h 43     Domain Manager ID.. PAGEREF _Toc96353896 \h 44     Domain Management Information. PAGEREF _Toc96353897 \h 44     Domain Context for Device. PAGEREF _Toc96353898 \h 45     Domain Context for DCF. PAGEREF _Toc96353899 \h 45

6.1.2        Protocol between domain manager and Device. PAGEREF _Toc96353900 \h 46     Creating a domain. PAGEREF _Toc96353901 \h 46     Adding a Device. PAGEREF _Toc96353902 \h 46     Leaving Domain. PAGEREF _Toc96353903 \h 47     Renewing a Domain. PAGEREF _Toc96353904 \h 47

6.1.3        Protocol between domain manager and entities that authorize DCF. PAGEREF _Toc96353905 \h 48     Acquire Domain context PAGEREF _Toc96353906 \h 48

6.1.4        Max number of Devices per Domain. PAGEREF _Toc96353907 \h 48

6.1.5        Maximum frequency of update. PAGEREF _Toc96353908 \h 48

6.1.6        Simultaneous usage detection. PAGEREF _Toc96353909 \h 48     Overview.. PAGEREF _Toc96353910 \h 49     Sub-Domain. PAGEREF _Toc96353911 \h 49     Play Log. PAGEREF _Toc96353912 \h 50     Integrate the Play Log. PAGEREF _Toc96353913 \h 50     Illegitimate Simultaneous Use. PAGEREF _Toc96353914 \h 51     Notification to Domain Manager PAGEREF _Toc96353915 \h 52

6.2       Manage Key. PAGEREF _Toc96353916 \h 53

6.2.1        Signaling Key Types in DCF. PAGEREF _Toc96353917 \h 53     The ds:KeyInfo element PAGEREF _Toc96353918 \h 53     The xenc:KeySize element PAGEREF _Toc96353919 \h 55

6.2.2        Key Exchange Protocol PAGEREF _Toc96353920 \h 55     Overview.. PAGEREF _Toc96353921 \h 55

7      Access. PAGEREF _Toc96353922 \h 57

7.1       Access License. PAGEREF _Toc96353923 \h 57

7.1.1        Introduction. PAGEREF _Toc96353924 \h 57

7.1.2        Local License Access Protocol PAGEREF _Toc96353925 \h 57

7.1.3        Remote License Access Protocol PAGEREF _Toc96353926 \h 57

7.2       Requirements. PAGEREF _Toc96353927 \h 58

7.3       RLAP Description. PAGEREF _Toc96353928 \h 58

8      Process. PAGEREF _Toc96353929 \h 62

8.1       Encrypt PAGEREF _Toc96353930 \h 62

9      References. PAGEREF _Toc96353931 \h 63

10        Acronyms –TBD.. PAGEREF _Toc96353932 \h 64



1          Foreword

1.1        The Digital Media Project

The Digital Media Project (DMP) is a non-profit Association registered in Geneva. Its mission is “to promote continuing successful development, deployment and use of Digital Media that respect the rights of creators and rights holders to exploit their works, the wish of end users to fully enjoy the benefits of Digital Media and the interests of various value-chain players to provide products and services, according to the principles laid down in the Digital Media Manifesto”. 

1.2        DMP Membership

Membership in DMP is open to any corporation and individual firm, partnership, governmental body or international organisation. DMP does not restrict Membership on the basis of race, colour, sex, religion or national origin. By joining DMP each Member agrees—both individually and collectively—to adhere to open competition in the development of digital audio-visual technologies, products or services.

DMP Members are not restricted in any way from designing, developing, marketing or procuring digital audio-visual technology, hardware, software, systems or services. Members are not bound to implement or use specific digital audio-visual standards, recommendations and DMP specifications by virtue of their participation in DMP.

1.3        DMP Approved Documents

The goals of DMP are realised by developing Technical Specifications and Recommended Practices enabling businesses that support new or improved end-user experiences, and Recommended Actions to appropriate entities to act on removal of barriers holding up exploitation of Digital Media. Technical Specifications, Recommended Practices and Recommended Actions are collectively called "DMP Approved Documents".

DMP contributes the results of its activities to appropriate formal standards bodies and other appropriate entities whenever this is instrumental to achieve the general DMP goals.

DMP Approved Documents are developed by participating DMP members on the basis of submissions from both members and non-members and/or in response to Calls for Proposals.

DMP Approved Documents are publicly available documents whose copyright is retained by DMP. Electronic copies of DMP Approved Documents can be obtained from the DMP web site ( or from the DMP Secretariat (

1.4        Intellectual Property Rights

DMP develops Approved Documents with the intention of making them available in a form such that users of the Approved Documents can implement them either freely, or on a royalty-free basis or on fair and reasonable terms and non discriminatory (RAND) conditions following the IEC/ISO/ITU policy on IPR in international standards. When issuing Calls for Proposals DMP explicitly advises Respondents to the Calls of this policy.

In case an external standard or specification is referenced in a DMP Approved Document, DMP assumes that the same IPR policy or a comparable one has been adopted by the entity that produced the standard or specification.

However, it must be noted that DMP is not in a position to make any expressed or implied guarantee that licensing of any of the technologies relevant to any or all of its Approved Documents can indeed by obtained freely or on a royalty-free basis or at RAND terms.

1.5        Media and Digital Technologies

Media contents have always played and important role in all societies and manifold technologies have been invented and deployed to provide means to store and distribute media contents. The complexity of technologies and the stimulus to provide ever-enhanced end-user experiences have created very complex media content value-chains populated by an increasing number of interacting intermediaries providing increasingly sophisticated services to the two extremes of the value-chains – creators and end users – and to other intermediaries. In DMP all players in the value chain – Creators, Intermediaries and End-Users – are generically called Value-Chain Users. Terms beginning with a capital letter are defined in the DMP Terminology

Technologies have been designed with two main purposes in mind: the first to provide or augment the end-user experience, and to augment the capability to distribute media content. The latest round of technologies are digital. They have augmented the end-user experience, e.g. by providing very high quality audio and video that does not deteriorate with different generations of copies and have dramatically increased the distribution potential of media content by combining with the development of digital networks.

The result today is that the traditional means to manage the value of media content along the value-chain is fast losing its meaning. This is the source of various difficulties and is the major cause of the poor exploitation of the potential of digital media technologies. Digital Rights Management (DRM) has been advocated by many as the set of technologies that can overcome these difficulties.

The Digital Media Project agrees that DRM has the potential to combine the benefit of digital technologies with the need for a virtuous circle that motivates creators to continue creating because means to be remunerated are provided by DRM technologies. However, DMP sees serious problems in the introduction of DRM technologies that are not interoperable.

1.6        DRM and the Interoperable DRM Platform

A DRM system can be described as a particular form of communication system designed to provide controlled communication between two or more entities. As such the implementation of a DRM system may requires a broad range of communication technologies. Unless these are designed in such a way as to enable communication between two different implementations, DRM becomes an obstacle to communication between Value-Chain Users. This has particularly serious consequences in the case of the End-User because then the lack of interoperability may seriously impede the take off of services based on Governed Content.

Standards can bring benefits to the very special type of communication systems called DRM. However, the application of standards obeys to different rules because DRM is tightly connected to business practices enabled by the introduction of digital technologies. As these are currently forcing changes of the way Value-Chain Users conduct their business, it is hard to define what kind of standards are required now as the only thing that is know id that the current shape of business is changing. At the same time it is also even more difficult to forecast what kind of standards will be needed in the future because it is unknown.

A way out is found by noting that Value-Chain Users do business between them by performing Functions. Typically these Functions are a combination of smaller Functions called “Primitive Functions”. While Functions are changing because of the evolution of media business in the Value-Chain, Primitive Functions are in general rather stable.

Therefore DRM standardisation can be achieved by standardising Primitive Functions.

1.7        The Toolkit Approach to IDP

The immediate consequence of the conclusion above is that it is very difficult to define a “DRM standard” that provides interoperability between different Users in arbitrary Value-Chains or across different Value-Chains. What can be done is to define a Value-Chain serving a specific goal and standardise the required DRM technologies. While this may provide a solution for the contingent needs of today, it flies in the face of advancing convergence.

DMP instead provides a DRM standard based on the following approach:


1.      DMP defines a set of basic DRM technologies called “tools” – those that are needed to implement “Primitive Functions”. The document specifying the tools is called Interoperable DRM Platform (IDP) and constitutes Approved Document No. 1. Those who wish to establish a Value-Chain serving a particular purpose can draw tools from the IDP toolkit. As these are standard they can be acquired from an ecosystem of competing suppliers.


2.      To aid in this process DMP also develops a number of Use Cases that are believed to have a special value. IDP Use Cases are contained in Approved Document No. 2. Use Cases may address a portion or even an entire Value-Chain.


3.      To achieve its goal of enabling the creation of multiple interoperable Value-Chains, DMP has identified the need for Registration Authorities. The rules of operation of such Registration Authorities are given in Approved Document No. 3.


4.      DMP has recognised that there are basic assumptions underlying the establishment of IDP-enabled Value-Chains. These are contained in Approved Document No. 4.


5.      DMP supports the development of a reference software implementation of its specifications. Approved Document No. 5 contains such reference software. To the extent possible DMP provides the reference software as Open Source with a license aligned to established practices.


6.      Value-Chains are the result of business agreements by Value-Chain Users that are supported by a set of technologies. As the IDP tools can be acquired from multiple sources, each party in the agreement must have the means to ascertain that the other parties employ conforming products. Approved Document No. 6 contains Recommended Practices for End-to-End Conformance so that Value-Chain Users can reference it in their business agreements.

1.8        DRM goes beyond technology

In spite of the value DMP recognizes to Interoperable DRM as the main digital media-enabling technology, DMP has noted that DRM has the potential to substantially alter the balance that has been in existence in the analogue world between different Users of Content, in particular when one of them is the End-User. If not appropriately remedied, this imbalance may lead to a significant reduction of the scope of Traditional Rights and Usages (TRU) of Users. A possible outcome is the outright rejection of the new technology on the part of some Users, in particular End-Users.

It should be noted that DMP is not claiming that an established TRU necessarily implies a right of a User to a particular Use of digital media but simply that, if Users have found a particular Use advantageous in the analogue domain they are probably interested to continue exercising that Use in the digital domain as well. Leveraging on this interest may provide opportunities for new “Digital Media Business Models” that are attractive to Users but are respectful of the rights of those who have created Works and invested in making Content.

Therefore DMP expects that, to make DRM-enabled digital media successful, individual jurisdictions will determine which TRUs shall mandatorily be supported by the Interoperable DRM Platforms operating under their jurisdiction and which TRUs can be left to private negotiations between Users. This is a challenging task because it requires blending legal and social knowledge with in-depth knowledge of the highly sophisticated and unusual DRM technologies.

Acknowledging this hurdle DMP will develop and publish Approved Document No. 7 “Recommended Action on Traditional Rights and Usages”.

Such a document has the purpose of facilitating the deployment and adoption of Interoperable DRM technologies based on DMP Specifications by providing a neutral description of the potential problems arising in their use and designing scenarios enabled by specific technical and legal choices.


2          Introduction to this Specification


In the analogue domain the establishment of media value chains has typically been a complex undertaking because the technologies underpinning them are often unwieldy. Even so the number of media value chains has been large and, were it not for the appearance of digital technologies, diverse content media value chains satisfying different business needs would keep on appearing. In the digital domain it can be expected that digital media value chains can be created with much greater ease once interoperable DRM technologies will become the norm.

However, the business needs are so diverse that if one were to specify interoperable DRM technologies that are functional to each and every type of value chain one would end up with a very significant amount of work with the shortcoming that interoperability between different value chains would probably be low.

Considering the above the Digital Media Project has taken the approach of identifying “functions” – that DMP has called “Primitive Functions” – that are executed by value-chain users when doing business between them using DRM technologies that are at a sufficiently low level to be re-used at different points of a value chain and in different value chains.

DMP has called the ensemble of all such standardised DRM technologies “Interoperable DRM Platform (IDP)”. The IDP provides three major advantages:


1.      Ideally any value chain can be implemented using a combination of standard technologies – that DMP calls “Tools” – drawn from the IDP

2.      The standardised DRM technologies have reduced in cost because of the larger use of these key elements and the existence of a multitude of suppliers

3.      An enhanced degree of interoperability is achieved between different value chains.


DMP develops the IDP specification in phases. It concentrates on use cases believed to be of high practical interest, identifies the necessary Primitive Functions, develops the corresponding requirements and issues Calls for Proposals for technologies that are needed to implement the Primitive Functions required by the target use cases. In a following phase DMP will issue a Call for Proposals for additional technologies needed to support new Primitive Functions or additional functionalities of existing Primitive Functions.

So far DMP has identified a large number of Primitive Functions and has grouped them in different categories as represented in the table below:







Identify Data


Identify License


Identify User


Identify Device


Identify Use Context


Identify Domain


Identify Resource Format


Identify Device Capability


Identify Tool




Assign Identifier


Assign Descriptor




Revoke Domain




Represent Content


Represent Rights Expression


Represent Use Data


Represent Metadata




Authenticate User


Authenticate Device


Authenticate Domain


Authenticate Tools




Verify Data Integrity


Verify Device Integrity




Certify Work


Certify User


Certify Author


Certify Device




Manage Key


Manage Domain


Manage Device Capability


Manage Use Data Confidentiality































Test Conformance





Test Conformance of Rights Expressions


Test Conformance of Enforcing Rights Expressions


Test Conformance of Tamper resistance


This Interoperable DRM Platform, Phase I (IDP-1) specification contains specification of a reduced number of DRM technologies supporting Primitive Functions needed in Portable Audio and Video (PAV) Devices. A PAV is a Device capable of playing Governed Content obtained through a networked device. However, IDP-1 can also be used to support other use cases as shown in Approved Document No. 2 Interoperable DRM Platform Use Cases.

DMP is already extending the IDP-1 specification. The Interoperable DRM Platform, Phase II (IDP-2) will contain specification of DRM technologies that are required to support Primitive Functions needed for Stationary Audio and Video (SAV) Devices. A SAV is a Device capable of playing Governed Content obtained directly from a network. A SAV can typically also Store Governed Content, Copy or Move it to another SAV or to a PAV possibly after Adapting it, or Export/Import Governed Content to/from a non DMP DRM System.



3          Identify


This chapter collects the specification of the “Identify” category of Primitive Functions, i.e., currently, Identify Content, Identify License, Identify Device and Identify Domain.

[Reference use cases with this primitive function?  ]

[Awaiting first pass peer review]

3.1        Identify Content


[For clarification in update: what’s the relationship between Identify Data and Identify Content. The scope of IC? How is it changed from ID to IC? Reflect it to IDP-2 requirement.]


3.1.1        Overview

This section addresses the scope, syntax and method of Content Identification. Allocating a Globally unique and Persistent IDentifier (GPID) to a piece of Content is the unambiguous method for identifying Content. The GPID has two aspects, its lifetime and the valid boundary of its uniqueness. Persistence should be guaranteed for a long time so that the GPID may be used as a reference to a Content beyond the lifetime of the Content it identifies. The uniqueness should be guaranteed across Value Chain Players (VCPs), or globally, so that a GPID can play an important role in connecting Content throughout VCPs. Content Identifier is a sort of GPID.

3.1.2        Characteristics of Content Identifier

Content Identifier should satisfy the characteristics defined in RFC 1737 [14] published by IETF, which is known as URN (Uniform Resource Names) scheme. Currently, there are several registered URN schemes such as ISBN and ISSN, each of them serving a specific purpose and having a unique namespace under IANA (Internet Assigned Numbers Authority). Therefore identifiers that conform to URN schemes are eligible for Content Identifiers and can be used to identify Contents.

3.1.3        The Assignment of Content Identifier

There are two ways to assign Content Identifier. One is to assign IDs under existing URN namespaces and the other is to assign ones under the URN namespace managed by DMP Naming Authority. In the case of utilizing DMP Naming Authority, subordinate namespaces are allocated to registration agencies and assignment of Content Identifier is delegated to them. DMP Naming Authority and registration agencies control resolution. The Authority maintains the list of subordinate namespaces. Each registration agency maintains GPIDs registered with the registration agency.

3.1.4        The Syntax

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


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


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


The Content Identifier is placed as specified in 4.1.2

3.1.5        Examples

The DMP Naming Authority uses the namespace of DMPI and the DMPI scheme defines its syntax abiding the URN syntax with a specific purpose of identifying Content. In order to package content following the DMP specification, the ContentPro company asks a registration agency of its choice to assign the string 123456abc to a given piece of Content. The registration agency, which was given the subordinate namespace I100 by the Naming Authority, will use the following identifier for content registration: urn:uci:I100-123456abc. The syntax of Content Identifier is based on DMPI syntax. In order to enable support for the ISBN naming scheme (ISBN no. 12345689), the registration authority establishes a link between the content identifier mentioned above, and the ISBN number. Then, the identifier urn:dmpi:isbn-12345689 can be used.


3.2        Identify License

[General comment: We need to include an overall introduction to Licensing that would refer to all different sections involving license and not only Identify license, this may also be true of other categories of the document]

[This does not converge on a technology for ‘separate’ model. See Approved Doc No 4 and ensure all Ids are accommodated in this spec]


License identification may serve different ends such as:


  1. Identification of Rights transaction e.g. proprietary database.
  2. Identification of generic terms and conditions e.g. open license lookup.


License Identification for the restricted application of Portable Audio Visual device will imply the following.


[Defining these terms are out of scope of this document level.]

Licensor: The one that Grants the Rights

Licensee: The one that obtains the Rights from the Grantor

Rights: The list of actions permitted by virtue of the Rights Granted

Conditions: The conditions that must be met in order for the Principal to obtain and/or exercise the Rights

Object: The asset, item or thing to which the Rights apply.


Two models are proposed and supported by the General Architecture in dmp304. [Work in progress, see Approved doc 4]


The first recognizes that since all DCFs are identified uniquely and unambiguously via Content Identification and if all except the Authors level DCFs (see Fig. 1 [ Approved Document No 4 IDP Architecture]) are created based on previously existing DCFs, then by virtue of the Rights Expressions within the DCI of the first that must contain the license for the creation of the second. This model implies that each DCF is uniquely identified, encrypted and uniquely assigned to a particular User or perhaps User Domain. Identification of license in this model is integrated in the DCF and Content Identification suffices.


The second model (Fig. 2 in Approved Document No 4 IDP Architecture) proposes licenses as being delivered independently of DCFs whereby many copies of a DCF may circulate freely all with the same DCF ID and identical encryption. All are subject to obtaining a license that may be negotiated independently in terms of specific User identification, terms and conditions. Here licenses are identified and related to the Grantor.


Within the DCF format and for the purposes of License Authority identification, there must exist a hook for linking the DCF to the Licensor.

3.3        Identify Device

[Pending peer review on this section.]

3.3.1        Overview [of Device Identification]

Device identification is a system to identify PAV devices, in which device identifier’s format, generation scheme, generation protocol and exchange protocol are included. Device identifier is mainly used for device authentication. And it is also important information for DRM controller to allow or disallow the specific devices to render governed contents.


There can be two kinds of device identification. One is the ‘device info-based identification’ whose identifier is uniquely generated based on the device information by the server called ‘Device Identification Server’. And another one is the ‘certificate-based identification’ in which X.509 certificate is utilized for device identifier.

3.3.2        Assumption [about the DMP Environment]

This specification explains only identifier format, generation scheme, generation protocol and exchange protocol of device identification. A Device Identifier is stored on the Device after it is generated from Device Identification Server. And only Devices containing Device Identifiers are delivered to Users. So it does not address following topics. [Re-look at this sentence.]

3.3.3        Authenticity of device identifier

[Is this in scope for this document?  Perhaps in architecture or use case?]

Device identification does not care whether a device is real owner of the device identifier or not. Device identification does not care whether a device is hacked and its device identifier is forged or not, either. It is assumed that this verification work is to be done by the device authentication. It is desirable that generic tamper resistance issues including tampering of device identifier are addressed in detail in authentication or its related section.

3.3.4        Intents [Example uses of this technology in this role]

[Perhaps intents should be placed somewhere else, such as use case or architecture]

Device identification is used for following intents [described in the following sections]       Device Authentication

Rights issuer needs to verify target device to allow rendering of governed contents. So most of all, it is necessary for DRM rights issuer to get device identifier from identification process for following device authentication process.       Authorization

Device identifier is important information for DRM controller to allow or disallow the specific devices to render governed contents.       Domain Administration

Device identifier is used to identify member devices of specific domain in which various devices can be registered and managed.       Audit

Device identifier is used to identify participant devices on use or move of governed contents if the audit record needs to be written.       License Backup and Restore

Use of governed content is controlled by the license that specifies allowed device(s). Device identifier is used to identify dedicated device on backup or restoration of the license.

3.3.5        Function of Device Identification

Device identification is classified by two approaches according to the structure of device identifier. The first one is the ‘device info-based identification’. And the second one is the ‘certificate-based identification’.

3.3.6        Device Info-Based Identification

[Number of nested header levels needs reducing here as it makes things less clear]       ID Generation Scheme

Device info-based identification is an identification system in which ‘Device Identification Server’, generates device identifier using some vendor specific information such as vendor ID, model ID or product serial number. Device Identification Server issues and manages device identifiers for all DMP applied devices. The number of Device Identification Server can be multiple by countries or regions       Identifier format

Device identifier of the device info-based identification is composed of header part and identifier part that comprises 14 bytes. Figure 1 shows the structure of the device identifier.


 Figure  SEQ Figure 1: Identifier format of device info based identification



ID Type (1 byte): device identifier type (0x00 ~ 0xFF). 0x1 (indicates device info-based identification)


Issuer ID (2 bytes): Device Identification Server ID (0x0000 ~ 0xFFFF). It is generated and managed by DMP LA(License Authority), and all Device Identification Servers get this ID from DMP LA.


Version (1 byte): identifier format version (0x00 ~ 0xFF). It is managed by DMP LA.

Vendor ID (4 bytes): device vendor ID (0x00000000 ~ 0xFFFFFFFF). It is uniquely generated and managed by Device Identification Server.


Model ID (2 bytes): product model ID (0x0000 ~ 0xFFFF). It is uniquely generated and managed by product vendor.


Product Serial # (4 bytes): product serial number (0x00000000 ~ 0xFFFFFFFF). It is generated by device vendor and is registered to Device Identification Server. If device does not have the product serial number, Device Identification Server generates it.       Protocol [ Heading redundant?]       ID Generation Protocol

Figure 2 shows how to generate device identifier on device info-based identification system.


Identifier request: Requestor of device identifier sends vendor ID, model ID and product serial number of new device to Device Identification Server. If there is no specific product serial number on the device, the requestor may not send product serial number. It means that Device Identification Server is required to generate product serial number for the requested device.


Identifier Issuing: Verifying the uniqueness of product serial number, Device Identification Server generates new 14 bytes device identifier based on the device information from requestor. Newly created product serial number may be inserted if requested data does not contain it.





Figure  2: ID generation protocol of device info-based identification       ID Exchange Protocol


Figure 3 shows how to exchange a device identifier between two devices.




Figure  3: ID Exchange protocol of device info-based identification


Initialization: caller device confirms that callee device is ready to communicate each other through simple ping process


Identifier request: caller device requests device identifier of callee device


Response: callee device sends its device identifier to caller device.


Exception handling: If there is no response from peer device within certain time, exception handler is involved.

3.3.7        Certificate-Based Identification

[The following describes the components relating to the certificate based identification]       ID Generation Scheme

Certificate-based identification is another identification system in which the Device Identification Server generates X.509 certificate and this certificate must be stored on the device.

X.509 certificate is a container or transmission media of device identifier. And DN(Distinguished Name) value in the certificate is used for practical device identifier.


Under the certificate-based identification system, Device Identification Server is a kind of DCA(Device Certificate Authority) which has to get key pair for digital signature from Root CA. So DMP LA needs to take a role of Root CA.       Identifier Format

Device identifier on certificate-based identification system has variable length like Figure 4.



[Figure 4] Identifier format of certificate-based identification


Figure  4: Add title


ID Type (1 byte): device identifier type (0x00 ~ 0xFF). 0x02(indicates certificate-based identifier)


Length (2 bytes): certificate length (0x0000 ~ 0xFFFF).


Reserved (1 byte): Not used.


X.509 Certificate (n bytes): X.509 data. DN in the certificate is used for unique device identifier.       Protocol [As before – redundant nesting]       ID Generation Protocol

Under the certificate-base identification system, since DN field of X.509 certificate is used for device identifier, generation process of the device identifier must be replaced with the certificate generation process.       ID Exchange Protocol

The exchange process of device identifier under certificate-based identification system is almost same as device info-base identification system except one that it can check the validity of device identifier in X.509 certificate during RESPONSE phase by verifying the digital signature.

3.3.8        Example of Identify Device

[Consider placing examples somewhere else, and also look at the content licensed to device vs. content licensed to domain]

The following example describes how identifiers can be used when a user consumes a content item using a player, which stores the identifier within itself. Refer to the above protocols for use cases about requesting, issuing, and storing of identifiers.       Example 1: Device with Device Info-Based Identifier


- Mike has a DMP-compliant mp3 player MPXXX from AVendor. (that is, Vendor-ID and Model-ID of the mp3 player are AVendor and MPXXX , respectively).


- Mike pays for the famous content, music1 and gets the license with the restriction of [CAN BE PLAYED ONLY IN Mike’s MPXXX MP3 PLAYER FROM AVendor].


- When Mike tries to play music1,

a. DRM-controller parses the license and reads the restriction described in the license.

b. DRM-controller reads Device Identifier from the mp3 player.

c. DRM-controller retrieves Vendor-ID and Model-ID from Device Identifier.

d. DRM-controller confirms that the restriction is satisfied.


- Mike enjoys music1.       Example 2: Device with Certificate-Based Identifier


- Mike has a DMP-compliant mp3 player MPXXX from AVendor. (that is, Vendor-ID and Model-ID of the mp3 player are AVendor and MPXXX , respectively).


- Mike pays for the famous content, music1 and gets the license with the restriction of [CAN BE PLAYED ONLY IN Mike’s MPXXX MP3 PLAYER FROM AVendor].


- When Mike tries to play music1,

a. DRM-controller parses the license and reads the restriction described in the license.

b. DRM-controller reads device certificate from the mp3 player.

c. DRM-controller reads DN from Device Certificate.

d. DRM-controller retrieves Vendor-ID and Model-ID from DN.

e. DRM-controller confirms that the restriction is satisfied.


- Mike enjoys music1.

3.4        Identify Domain

[The primitive function of Identifying a Domain as an entity is specified here]

3.4.1        Overview [of Identify Domain]

To guarantee the global uniqueness of Domains, DMP will appoint a Domain Authority. The Authority will operate according to DMP-specified guidelines and appoint agencies to act as Domain Managers. And then Domain Manager ID is assigned to the agency. Domain Managers will assign Domain ID to guarantee locally uniqueness. Domain Manager ID and Domain ID are used to identify Domain. There is also an idea of Sub-Domain. Sub-Domain is a sub group of a Domain. This is used to control usages inside a Domain separately.

3.4.2        [Overview of] Identify Domain Manager

The agency assigned by DMP is given a Domain Manager ID to identify itself. URN scheme will be used for Domain Manager ID.  DMP will appoint a Domain Authority. The Authority will operate according to DMP-specified guidelines and appoint agencies to act as Domain Managers. Domain Managers will assign Domain Identifiers.

3.4.3        Identify Domain Specification

When a Device requests a new Domain for itself to Domain Manager, Domain Manager creates a new Domain with a new Domain ID. Identification of Domain relays on account ID and password which have been exchange between Device and Domain Manager when the Device requested a new Domain. For the second Device to the Domain, the same set of account ID and password are sent from Device to Domain Manager to identify the Domain, so that the second Device can be added to the Domain. More detail about the Domain identification protocol is described at Section 6.1 Manage Domain. The format of Domain Manager ID is shown below.


<element name="Domain ID" type="base64Binary "/>


3.4.4        Identify Device in the Domain

Domain Manager maintains a device list of all Domain. Every time a new Device joins the Domain, Device Manager adds Device ID of the Device to corresponding Device list. Refer to section 3.3 Identify Device.

3.4.5        Identify User in the Domain

When more than two users are in the Domain, Domain Manager creates Sub-Domain in order to keep track of their usage.  Sub-Domain is a sub group of a Domain and represents a user in the Domain. Once Sub-Domain is created, Sub-Domain ID is set to DCF as a part of Domain license. Multiple Sub-Domains may be given to a DCF, when the DCF is shared by multiple users. But the number of Sub-Domain to be given must be limited. It is unique only inside a Domain. Refer to Section 6.1 Manage Domain. The format of Sub-Domain ID is shown below.


<element name="Sub-Domain ID" type="base64Binary"/>



4          Represent

[Need some intro, check consistency of references.

This chapter collects the specification of the “Represent” category of Primitive Functions, i.e. (currently) Represent Content and Represent Rights Expression.

4.1        Represent Content

[This section specifies technologies to implement the primitive function to represent or describe the content within DMP file format such as DCF, like an index.  Insert picture to show context of it behaving like an index.]


[FC: New proposed text below]


According to DMP terminology, “Content” is defined as “A structured combination of Resource Types and Metadata”. This section specifies the set of technologies used to represent Resource Types and Metadata when combined together in an instance of Content. Particularly, this section provides means to:


Note that Represent Content is uncorrelated from the container in which Content is packaged/delivered, which can be a file, a transport mechanism, etc. 


The structured information for Represent Content described in this section is named DMP Content Information (DCI).


4.1.1        Introduction

The DMP Content Information is an XML structure used to Represent Content according to a DMP-defined subset of ISO/IEC 21000-2 (Digital Item Declaration, DID), ISO/IEC 21000-3 (Digital Item Identification, DII), ISO/IEC 21000-4 (IPMP Components), and extended by the DMP namespace to express DMP-specific information. ISO/IEC 21000-2 describes a set of abstract terms and concepts to form a useful model for defining Digital Items [3]. DCI extends DID by defining the <dmp:DMPInformation> element containing DMP-specific information and Metadata associated to Content and Content Data Elements, as shown in Figure 5 below. Moreover, the presence of Governed resources within DMP Content is signalled according to [5].


Figure 5: Simplified graphical representation of a DCI

4.1.2        Identifying DMP Content

DMP Content Identifier, as defined in 3.1, is expressed accordingly with MPEG-21 Digital Item Identification [4] specification, and is located within the DCI as shown in Figure below.




     <did:Item> <!--This item refers to the whole DMP Content-->


            <did:Statement mimeType="text/plain">


                <!--The DMP identifier for this content-->                           






4.1.3        Identifying DMP Content Data Elements

Identifiers for Content Data Elements are expressed accordingly with MPEG-21 Digital Item Identification [4] specification, and are located within the DCI as shown in Figure below.




     <did:Item> <!--This item refers to the whole DMP Content-->

         <did:Item> <!--This item refers to a Content Data Element-->


               <did:Statement mimeType="text/plain">


                   <!--The DMP identifier for this Content Data Element-->                          







4.1.4        DMP Information

·        The basic element of the DMP namespace is <DMP:DMPInformation> which is defined below. [At this high level, this is just a placeholder for more information.]

·        [The captions of all these figures need to be fixed!]


<xsd:element name="DMPInformation"> <!--Needs integration with metadata-->



         <xsd:element ref="dmp:ContentInfo"/>

         <xsd:element ref="dmp:Preview" minOccurs="0"/>

         <xsd:element ref="dmp:Data" minOccurs="0"/>




Figure 6: DMPInformation       ContentInfo

(Needs thorough discussion about DMP METADATA)

This element contains metadata related to a DMP file or a resource (depending on the position it is encountered). More sub-items have to be defined (TV-Anytime metadata, DivX metadata, etc…)


<xsd:element name="ContentInfo"> <!--Needs integration with metadata-->



         <xsd:element ref="dmp:Item_ID"/>

         <xsd:element ref="MediaFormatType" type="mpeg7:DType"/>

         <xsd:element ref="Title" type="mpeg7:TitleType" minOccurs="0"/>

         <xsd:element ref="Author" type="mpeg7:???" minOccurs="0"/>

         <xsd:element ref="Duration" type="???" minOccurs="0"/>

         <xsd:element ref="Year" type="mpeg7:???" minOccurs="0"/>




Figure  7: ContentInfo       Preview:

Specifies links to resources that a PAV may show to the user as a preview of the file. As for any <DID:resource>, a license may or may not be required. The linking happens through the use of the <DMP:Item_ID> element.


<xsd:element name="Preview">



                                    <xsd:element ref="dmp:Item_ID"/>




Figure  8: Preview       Data:

This element can contain data from any namespace. A conformant PAV doesn’t need to be able to interpret content extracted from this field.


<xsd:element name="Data">

   <xsd:complexType mixed="true">


         <xsd:any namespace="##any" processContents="lax" minOccurs="0"/>




Figure  9: Data


4.1.5        Signalling DMP information related to the whole DMP Content

The DMPInformation element residing at the top level in the DCI is meant to convey information about the whole DMP Content. Figure 10 below shows where DMPInformation is located in the DCI in this case.




     <did:Item> <!--This item refers to the whole DMP Content-->


            <did:Statement mimeType="text/plain">


                <!--The DMP identifier for this content-->                           




            <did:Statement mimeType="text/xml">


               <!--...conveying General DMP Information for the whole DMP Content-->







Figure  10:  DMPInformation about the whole DMP Content


4.1.6        Signalling DMP information related to an resource within DMP Content

The DMPInformation element residing in a sub-item of the DCI is meant to convey information about the resource which this item is associated. Figure 11below shows where DMPInformation is located in the DCI in this case.




      <did:Item> <!--the one representing the whole DMP Content-->

         <did:Item id="Resource1"> <!--the one representing a resource part of the DMP Content-->


               <did:Statement mimeType="text/xml">


                     <!--...conveying DMP Information for a resource part of the DMP Content-->





               <did:Resource ref="funky1.mp3" mimeType="audio/mpeg"/>






Figure  11: DMPInformation about a resource within the DMP Content

4.1.7        Governed DMP Content

If one or more resources part of the DMP Contentis governed, its governance is expressed in the DCI according to a DMP profile of the MPEG-21 IPMP Components [1] Standard, which defines:


1)      A language named IPMP Digital Item Declaration Language (IPMP DIDL), which provides for a protected Representation of the DID Model, allowing DID hierarchy which is encrypted, digitally signed or otherwise governed to be included in a DID document in a schematically valid manner.


2)      The IPMPInfoDescriptor schema, defining structures for expressing governance information related to a single resource within the Content, including all required tools, mechanisms and licenses.


3)      The IPMPGeneralInfoDescriptor schema, defining structures for expressing general governance information related to the whole Content, including all required tools, mechanisms and licenses.       IPMP DIDL

According to the IPMP DIDL, for each entity in the DID Model, an IPMP DIDL element is provided as a protected Representation of that entity. DIDL and IPMP DIDL element are equally interchangeable within a Digital Item; an IPMP DIDL element replaces a DIDL element whenever that element requires protection. For instance, as ISO/IEC 21000-2 DID defines the element <didl:Item>, ISO/IEC 21000-4 defines the equivalent <ipmpdidl:Item> and so on for every element in DIDL.


Each of the IPMP DIDL elements contains identical structure.


(i)                  a maximum of one ipmpdidl:Identifier element, into which an appropriate identifier for the protected Representation may be placed

(ii)                one ipmpdidl:Info element, into which information about the governance is placed

(iii)               one ipmpdidl:Contents element, into which the governed contents is placed




Figure 12 below is an example of a resource (an mp3 file) whose governance is expressed according to the IPMP DIDL model. In this case, the resource conveyed in element <ipmpdidl:Contents> (although a reference to it is given rather that its inclusion inline) is supposed to be obfuscated or protected in some form, and the necessary information for gaining access to it in clear form is specified in element <ipmp:IPMPInfoDescriptor> child of <ipmpdidl:Info>.




   <!--Asset protected, referenced externally-->

    <did:Resource mimeType="application/ipmp">

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



        <ipmpdidl:Contents ref="funky1.mp3" mimeType="audio/mpeg"/>




Figure  12: IPMP information for a governed resource


[Pending section 3 further pass 1 peer review]       The IPMPInfoDescriptor

The root element for IPMP Information Descriptor schema is “IPMPInfoDescriptor”, which may contain information related to the IPMP Tools that protect the associated Contents, to the licenses that govern them, and an associated digital signature, which is specified in the three elements below:


·        ipmp:Tool - IPMP tools are modules that perform (one or more) IPMP functions such as authentication, decryption, watermarking, etc. They can be single modules or even a complete DRM system. This element specifies the IPMP tool information required to protect the Digital Item or its parts such as a Tool descriptor and Tool configuration settings.


·        ipmp:RightsDescriptor – This element contains information about the license that governs the IPMPInfoDescriptor element. The license can be contained within this element, or a reference to it (or to a license service) is provided instead. If the license is encrypted, an IPMPInfoDescriptor containing information about how to access it is provided as a direct child of ipmp:RightsDescriptor.



·        dsig:Signature - The dsig:Signature element contains the signature for the IPMPInfoDescriptor element.


Figure 13 below, a restriction of the IPMPInfoDescriptor schema from [5], defines how this element is composed. Note: for enhance its readability, the schema below is not strictly following W3C rules; for the proper schema please refer to the accompanying documentation [To be produced].


<element name="IPMPInfoDescriptor"/>



                        <element ref="ipmp:Tool" minOccurs="0" maxOccurs="unbounded"/>

                        <element ref="ipmp:RightsDescriptor" minOccurs="0" maxOccurs="unbounded"/>

                        <element ref="dsig:Signature" minOccurs="0"/>




<element name="Tool"/>



                        <element ref="ipmp:ToolBaseDescription" minOccurs="1"/>

                        <element ref="ipmp:InitializationSettings" minOccurs="0"/>




<element name="ToolBaseDescription"/>



                        <element ref="ipmp:IPMPToolID" minOccurs="1"/>




<element name="IPMPToolID" type="anyURI"/>


<element name="InitializationSettings"/>



                        <element ref="ipmp:InitializationData"/>




<element name="InitializationData" type="ipmp:InitializationDataType"/>



                        <element ref="KeyInfo" minOccurs="0"/>

                        <element ref="KeySize" minOccurs="0"/>




<element name="RightsDescriptor"/>



                        <element ref="ipmp:License"/>

                        <element ref="ipmp:LicenseReference"/>

                        <element ref="ipmp:LicenseService"/>




<element name="License"/>



                        <any namespace="##any" processContents="lax" minOccurs="0"/>




<element name="LicenseService"/>



                        <any namespace="##any" processContents="lax" minOccurs="0"/>




<element name="LicenseReference"/>



                        <extension base="anyURI"/>





Figure  13: The DMP profile of IPMPInfoDescriptor       Example: How to signal a resource encrypted by AES in cbc mode with a 128 bit key


If the AES in cbc mode is registered to the chosen MPEG-21 Registration Authority with an ID of ABC002:56:79 the following schema shows how to signal it using ipmp:Tool.









                                    <xenc:KeySize> 128 </xenc:KeySize>




Figure  14: Add title       Location for IPMPInfoDescriptor elements in the DCI


IPMPInfoDescriptor elements conveying IPMP Information about a governed resource part of the DMP Content are located within the DCI as shown in Figure 15 below. Note that if one or more IPMPInfoDescriptor elements appear in the DCI, an IPMPGeneralInfoDescriptor element as defined in 5 shall be used to signal general IPMP information.




      <did:Item> <!--the one representing the whole DCF-->

         <did:Item id="Resource1"> <!--the one representing a resource part of the DCF-->


               <did:Resource mimeType="application/ipmp">

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





                     <ipmpdidl:Contents ref=""/>








Figure  15: Location of an IPMPInfoDescriptor within the DCIThe IPMPGeneralInfoDescriptor       The IPMPGeneralInfoDescriptor

The IPMPGeneralInfoDescriptor schema is used to convey general information relating to a complete DCF, and its use is mandatory whenever one or more IPMPInfoDescriptor elements appear in the DCI. In other words, a DCI containing one or more governed resources shall use one ad only one IPMPGeneralInfoDescriptor to convey general governance information. This element may contain the following elements:


·        The ipmp:ToolList element, the list of all the IPMP Tools required to unprotect all the governed objects part of the file. As DMP defines a limited number of protection algorithms (see 6.2 and 8.1), the list will be populated by a finite set of elements. Moreover, ipmp:Tool elements within ipmp:ToolList just contain the ipmp:IPMPToolID element and no further information, which will be signalled in the appropriate IPMPInfoDescriptor associated to the governed resource.


·        The (optional) IPMP:LicenseCollection element, which contains a collection of references to licenses for all governed parts of theDMP Content. This element is used with the purpose of giving the “big picture” on the governed parts of the file in one point. IPMP:LicenseCollection replaces element dmp:repository in dmp0264


·        The (optional) dsig:Signature element, which contains the signature for the present ipmp:IPMPGeneralInfoDescriptor.


Figure 16 below, a restriction of the IPMPGeneralInfoDescriptor schema from [1], defines this element and its child elements. Note: for enhance its readability, the schema below is not strictly following W3C rules; for the proper schema please refer to the accompanying documentation [To be produced].


<element name="IPMPGeneralInfoDescriptor"/>

<complexType >


                        <element ref="ipmp:ToolList" minOccurs="0"/>

                        <element ref="ipmp:LicenseCollection" minOccurs="0"/>

                        <element ref="dsig:Signature" minOccurs="0"/>

                        <!--Signature for the IPMPGeneralInfoDescriptor element and children -->




<element name="ToolList"/>



                        <element ref="ipmp:ToolDescription" maxOccurs="unbounded"/>




<element name="ToolDescription"/>



                        <element ref="ipmp:IPMPToolID"/>




<element name="LicenseCollection"/>



                        <element ref="ipmp:RightsDescriptor" maxOccurs="unbounded"/>



Figure  16: The DMP profile of IPMPGeneralInfoDescrioptor       Location for the IPMPGeneralInfoDescriptor element in the DCI

IPMPGeneralInfoDescriptor elements conveying IPMP Information about the whole DMP Content are located within the DCI as shown in the example schema below, which also contain other elements introduced o far in this section.




     <did:Item> <!--This item refers to the whole DMP Content-->


            <did:Statement mimeType="text/plain">


                <!--The DMP identifier for this content-->                           




            <did:Statement mimeType="text/xml">


               <!--...conveying General DMP Information for the DMP Content-->




         <did:Item id="Resource1"> <!--the one representing a resource part of the DMP Content-->


               <did:Resource mimeType="application/ipmp">

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





                     <ipmpdidl:Contents ref=""/>






      <did:Descriptor> <!--MPEG-21 IPMP stuff-->



            <!--Conveying General IPMP Information for the DMP Content-->









Figure  17 Location of IPMPGeneralInfoDescriptor, IPMPInfoDescriptor and DMPInformation [Styles issue]


4.2        Package Content: [ DMP Content Format (DCF)]

 [Comment: This format structure can be integrated with the other formats known as “represent”. May need review. Still unsure about the position of this.]


This section specifies how to package content into the DMP Content Format (DCF).

4.2.1        Introduction

DMP Content is packaged in files whose format is specified by a DMP profile of the MPEG-21 File Format specification [1], which contains the DCI with some or all of its ancillary resources, potentially in a single package. MPEG-21 File Format is based on the ISO Base Media File Format [2], which defines how to contain timed media information for a presentation in a flexible, extensible format that facilitates interchange, management, editing, and presentation of the media. This presentation may be ‘local’ to the system containing the presentation, or may be via a network or other stream delivery mechanism.


The file structure is object-oriented; a file can be decomposed into constituent objects very simply, and the structure of the objects inferred directly from their type. Moreover, the file format is designed to be independent of any particular network protocol while enabling efficient support for them in general.


[A representation of the DCF and its relation to the resources is shown here] [This would be ideal in AD #4]


[Picture reviewed in GA05 has now been drawn and is shown here. Still pending further peer review.]



 [moved to the DCI section]



In [2], files are formed as a series of objects, called boxes. All data is contained in boxes; there is no other data within the file. A basic box has two mandatory fields: length and type. The type identifier is used to dynamically bind a box to a statically defined type, while the size is an offset from the beginning to the end of the box. A Box type identifier is a Unique Identifier Number, which is represented by a code expressed using four bytes (4 Character Code, 4CC), each representing a human-readable character. The ISO base format uses a language called Syntax Description Language (SDL) for defining data structures, which has similarities with some programming languages and supports object orientation.


Table 1 is a subset of the table described in [1], section 3.1. The entry in the table represents a DMP-defined box, and has the purpose of containing the hash of the file, in order to protect it for integrity. The first two columns represent the 4CC identifying the box type; this information is displayed on two columns in order to show the nesting level of the boxes. The fourth column represents the section in [2] where such box is defined.








in [2]






file type and compatibility





free space










handler, declares the metadata (handler) type





binary XML container





XML container





item location





media data container





hashing value of the file

Table 1: Logical box structure diagram

4.2.2        ISO Base Media File Format Boxes used in the DCF


This section specifies syntax and semantics of the ISO Base Media File Format box elements adopted by the DMP to Package Content in the DMP File Format (DCF).       File Type Box (‘ftyp’)

aligned(8) class FileTypeBox
   extends Box(‘ftyp’) {
   unsigned int(32)  major_brand;
   unsigned int(32)  minor_version;
   unsigned int(32) compatible_brands[];  // to end of the box

·        major_brand = represents the brand identifier; for a DMP file it should be ‘dmpf’

·        minor_version = is an integer representing an informative version of the brand, and has to be set to ‘0x00000000’ for objects conforming to this specification

·        compatible brands: is a list of brands to which the content of this box is compatible, and follows syntax and semantics as defined in [2]

NOTE: DMP compliant files must have exactly one DMP File Type Box at the top level of the file.       Free Box (‘free’)

This optional box may contain any kind of data and follows the syntax and semantics as defined in [2]. A compliant PAV may ignore how to interpret the content of this box.       Meta Box (‘meta’)


aligned(8) class MetaBox (handler_type)
   extends FullBox(‘meta’, version = 0, 0) {
   HandlerBox(handler_type)   theHandler;
   PrimaryItemBox       primary_resource;      
   DataInformationBox   file_locations;        
   ItemLocationBox      item_locations;        
   ItemProtectionBox    protections;           
   ItemInfoBox          item_infos;            
   IPMPControlBox       IPMP_control;          
   Box   other_boxes[];                        

·        handler_type (hdlr) = ‘dmpf’


NOTE: For DMP-compliant files, only the field “other_boxes[]” is mandatory, and it will contain XML Boxes as specified below. A DMP-compliant device may ignore any content present in any other box defined in class MetaBox.       XML Boxes (‘bxml’)


aligned(8) class BinaryXMLBox
      extends FullBox(‘bxml’, version = 0, 0) {
   unsigned int(8) data[];    // to end of box

aligned(8) class XMLBox
      extends FullBox(‘xml ’, version = 0, 0) {
   string xml;

·        Binary XML Box is mandatory for DMP content. XML Box is optional

·        Both contain the DMP-defined DIDL Schema (Chapter 4 of this document).       Item Location Box


aligned(8) class ItemLocationBox extends FullBox(‘iloc’, version = 0, 0) {
   unsigned int(4)   offset_size;
   unsigned int(4)   length_size;
   unsigned int(4)   base_offset_size;
   unsigned int(4)   reserved;
   unsigned int(16)  item_count;
   for (i=0; i<item_count; i++) {
      unsigned int(16)  item_ID;
      unsigned int(16)  data_reference_index;
      unsigned int(base_offset_size*8)    base_offset;
      unsigned int(16)     extent_count;
      for (j=0; j<extent_count; j++) {
         unsigned int(offset_size*8)      extent_offset;
         unsigned int(length_size*8)      extent_length;



offset_size is taken from the set {0, 4, 8} and indicates the length in bytes of the offset field.


length_size is taken from the set {0, 4, 8} and indicates the length in bytes of the length field.


base_offset_size is taken from the set {0, 4, 8} and indicates the length in bytes of the base_offset field.


item_count counts the number of resources in the following array.


item_ID is an arbitrary integer ‘name’ for this resource which can be used to refer to it (e.g. in a URL).


data-reference-index is either zero (‘this file’) or a 1-based index into the data references in the data information box.


base_offset provides a base value for offset calculations within the referenced data. If base_offset_size is 0, base_offset takes the value 0, i.e. it is unused.


extent_count provides the count of the number of extents into which the resource is fragmented;  it must have the value 1 or greater.


extent_offset provides the absolute offset in bytes from the beginning of the containing file, of this item. If offset_size is 0, offset takes the value 0


extent_length provides the absolute length in bytes of this metadata item. If length_size is 0, length takes the value 0. If the value is 0, then length of the item is the length of the entire referenced file.       Media Data Box (‘mdat’)

This box contains the Media Data of the resources, and follows the syntax and semantics as defined in [2]       Hash Box (‘hash’)

This box contains the hash of the DMP file, which must be calculated from the beginning to the end of the last container, including the binarised DMP-defined DIDL Schema.


Building the DCF

[How to "build" the file, in the sense of how to multiplex resources in a seek- and reading-efficient way of the file by a device. Second picture inserted here as placeholder. Awaiting full peer review Picture needs redrawing with smaller font!]

[shouldn’t we have the picture related to DCI only first and then add the DCF box around it?]       Graphical Example representation of the DCF

The Figure below is a simplified graphical representation showing the use of some ISO Base Media File Format Boxes introduced in this section.

Figure 18: DCF Schematic


4.3        Represent Rights Expressions

4.3.1        Introduction

An interoperable DRM Platform needs to support a wide range of business models ranging from innovative and speculative to the simple and straight forward usage models currently familiar to the End User.  On a general level the expression of rights may be required between a number of Value Chain Players and the nature and complexity of the rights expressed may be dependent upon the nature of the value chain players involved in this exchange.


This technical specification is focussed on the rights expressed to the End User that can be interpreted on a Portable Audio Video device. However the DMP recognises that the PAV Use case only represents the most limited end device and that in due course the solutions described here will be extended to convey more complex scenarios to more complex user devices.

4.3.2        Scope

The scope of this section is the expressions of rights associated with Content that in turn map onto specific end device behaviour consistent with the semantics of the rights expressions. It does not extend to the expression of commercial offers or of details of financial transactions between the service provider and the End User.

4.3.3        Rights Set to be expressed within this Technical Specification

As this specification is targeted at the simple Use Case of the hand held portable device (PAV), this section summarises the basic operations that can be performed upon the governed content and that need to be expressed in some form by the chosen implementation of the rights expression.


Basic rights associated with this simple End-User Device are


  1. Play/Render
  2. Move – give to another User
  3. Copy/share to another User.
  4. Export from DMP Environment. [note: May be out of scope, - within scope, of IDP. Probably out of scope of IDP-1]


The following are condition uses of the above expressions.


  1. Play/render for n times [Use Case driven]
  2. Play/render within a time window [Use case driven]
  3. Move/share only to DMP domains associated with a geographical region [may not apply if super distribution not enabled]
  4. Backup [note: Is this appropriate for the PAV]

4.3.4        Expression of Rights (Rights Information or Expression Language)

This section describes a simplified profile of MPEG REL and a configuration of the TV-Anytime RMPI_MB that can be used to express the simple rights above.       Simplified DMP Profile of MPEG REL

This section specifies a significantly small subset of the MPEG-21 REL as the language for use within Licenses. The DMP profile of the REL has therefore to be slim enough to support the generation of licenses for content targeted to PAVs, but without losing the characteristic of being powerful and extensible, for future uses on IDP/IED.


This subset of MPEG-21 Part 5 “Rights Expression Language” based on OMA DRM REL Version 1.0 as a basic profile for the PAV Use Case. The following sub section contains the XML Schema of the proposed REL profile, followed by some simple examples of REL licenses according to this profile.

4.3.5        REL profile schema for the PAV domain

[Work in progress…  Approach needs extending for the complete PAV scenarios.]

The Schema below defines a simple MPEG-21 REL profile [16] compatible with OMA DRM REL Version 1.0. Peer review after further work]


The REL profile proposed, in outline, defines a license element, which can grant a certain number of rights on a resource. These are: [Not necessarily applicable.]


1.      play

2.      execute

3.      print


Rights can be exercised under certain conditions:


1.      a limited number of times

2.      a period of time between two dates

3.      a duration


Furthermore, in case the resource is encrypted, the license can convey the decryption key needed along with rights expressions.


This schema will be easily extensible in the future for covering more DMP scenarios.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:dmp="" xmlns:xsd="" elementFormDefault="qualified" attributeFormDefault="unqualified">

            <xsd:import namespace="" schemaLocation="xrml2sx.xsd"/>

            <xsd:import namespace="" schemaLocation="xrml2core.xsd"/>

            <xsd:element name="r:license">



                                                <xsd:element ref="r:grant" maxOccurs=”unbounded”/>


                                    <xsd:attribute ref="sx:ProfileCompliance"  use="required"/>


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



                                                <xsd:choice minOccurs="0">

                                                            <xsd:element name="mx:play"/>

                                                            <xsd:element name="mx:execute"/>

                                                            <xsd:element name="mx:print"/>


                                                <xsd:element ref="r:KeyHolder" minOccurs="0"/>

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

                                                <xsd:element ref="r:allConditions" minOccurs="0"/>




            <xsd:element name="KeyHolder">



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




            <xsd:element name="info">



                                                <xsd:element ref="dsig:KeyName" type="xsd:string"/>




            <xsd:element name="r:digitalResource">



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




            <xsd:element name="r:nonSecureIndirect">


                                    <xsd:attribute name="URI" type="xsd:string"/>



            <xsd:element name="r:AllConditions">



                                                <xsd:element ref="sx:exerciseLimit" minOccurs="0"/>

                                                <xsd:element ref="r:validityInterval" minOccurs="0"/>

                                                <xsd:element ref=" sx:validityIntervalFloating" minOccurs="0"/>




            <xsd:element name="sx:exerciseLinit">



                                                <xsd:element name="sx:count" type="xsd:string"/>




            <xsd:element name="r:validityInterval">



                                                <xsd:element name="r:notBefore" type="xsd:string" minOccurs="0"/>

                                                <xsd:element name="r:notAfter" type="xsd:string" minOccurs="0"/>




            <xsd:element name=" validityIntervalFloating">



                                                <xsd:element name="sx:duration" type="xsd:string"/>




Schema. 1.                        </xsd:schema>The MPEG-21 REL profile compatible with OMA ODRL 1.0

4.3.6        License Examples [Using Simple REL]       Play With Conditions (without decryption keys)






xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" sx:profileCompliance=”oma-drel-1.0”>


      <mx:play />


         <r:nonSecureIndirect URI=""/>










License granting one preview of the resource       Play With Condition (with decryption keys)





xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" sx:profileCompliance=”oma-drel-1.0”>





            <dsig:KeyName >Kug8YWrtMGnnTw678</dsig:KeyName>



      <mx:play />


         <r:nonSecureIndirect URI='' />










License granting one preview of an encrypted resource

4.4        TV-Anytime RMPI

[This needs clarification in line with the PAV Use case. Required in IDP-2 (SAV) not IDP-1 but we should probably keep it for GA06…]

[Work in progress…]

This section is written with reference to ETSI TS 102 822-5 Part 5 ‘Rights Management and Protection Information for Broadcast Applications’


This section determines the combination of fields to be used to convey the simple rights set outlined in the earlier section. The unpopulated fields may not exist in this simple profile. Device needs to ignore fields that are not included in the specification. The defaults arise from the limited functionality of the device.


The TV-Anytime RMPI specification allows the assertion of the following rights (where the semantics of these rights are specified in the TVA specification ref [])


  1. Play
  2. Analogue Export: e.g. Sending the content over S-Video to a VCR or TV.
  3. Digital Export (Standard definition): An example of a Digital Export SD would be sending the content over a legacy digital output to a display or recorder with a standard definition digital input.
  4. Digital Export (High Definition):
  5. Extend Rights: Allows new rights to be applied to content.


The TV-Anytime specification allows the granting of some of these rights to be conditional upon properties of the domain/device or other environmental variables:







Additional constraints expressible by TV-Anytime that may not be applicable to the simple PAV use case to express the minimum rights set are:










5          Authenticate

[Authenticate is a group of primitive functions to recognize and enable trust between entities.]

5.1        Authenticate Device

 [Work in progress…  This is possibly covered in other sections.  Why are we authenticating a device for what purpose?  Relevant document is DMP275]


This section will provide means to authenticate devices for the three classes of device identification.

1.      Devices without a hardware supported unique ID.

2.      Devices that are uniquely identified by vendor ID, product ID, serial number etc.

3.      Devices having certificates.


6          Manage

[Manage is a category of primitive functions to communicate parameters associated with system functions.  Check the terminology; this might fit into other sections perhaps.]


[Considerations for Content to Device Management and General Section]


Content is governed by licenses.  One requirement (ref #?) to enable widespread digital distribution of content is to specify how a device will programmatically resolve and enforce content licenses.  A common content license restricts how content can be distributed, hence copied and accessed.


There are several approaches to solving the requirement for the common license scenario:





Content Licensed to Single Device

A piece of content is licensed to work on one specific device.

Device requires a unique id or certificate.  Content must be re-licensed for each new device.

Content Licensed to Multiple Devices

A piece of content is licensed to work on multiple devices.

Same as single device.  The need to re-license can be reduced, since content will work on more than one device.

Content Licensed to Domain

A piece of content is licensed to a domain.  A domain is a level of indirection to a device.  Licensed content will work on any device that has the proper domain.  Content does not need to be re-licensed, rather a device need to join the domain.

The rules of joining and leaving the domain need to be specified.


6.1        Manage Domain

[Check structure, do not need as many overviews throughout document]

[Peer review pass 1 pending for the rest of the section.]

6.1.1        Overview

This section specifies the domain management protocols supported in Phase I of the DMP Interoperable DRM Platform specification. For when Content is licensed for the Domain these protocols define the operations that can be performed on Domains.


A Domain Manager controls membership of a domain. Domain Manager sets meta data about a Domain to a Device as a Domain Context, when the Device joins the Domain. Domain Manager also sets a Domain Context to a DCF when DCF is created with Domain license. This DCF will be able to be played on the Device with the same Domain Context. The Domain Manager controls Domain usage with Domain Context.       Domain Manager ID 

An unique Identifier which identifies the Domain Manager that hosts the domain information particular to the Domain ID. Refer to section 3.4 Identify Domain.       Domain Management Information

Domain Manager maintains Domain Management Information of all Domains that the Domain Manager created. Each Domain Management Information contains the following items.


1.      Domain ID  An unique Identifier created by Domain Manager which identifies a particular Domain. It’s locally unique inside Domain Manager. This is consistent throughout the Domain life time.


2.      Access ID  A pair of an access code and a password is create corresponding to Domain ID. This is used for Device or VCP to access their Domain. This may be updated when needed.


3.      Domain key  Domain Manager creates this key for encryption purpose relating to the Domain.


4.      Device ID list  A list of identifications that indicate Devices allowed to join the Domain. Refer to section 3.3 for Device ID.


5.      Expiration  Expiration period of the Domain given to a Device of the Domain.


6.      Maximum number of Device This is a number of Devices allowed to join the Domain.


7.      Maximum frequency of update Device is not allowed to leave and join the Domain exceeding this frequency.


8.      Revocation list  A list of Device ID which has been revoked.


<dmp:element name="Domain manage Info">


<dmp:element name="Domain ID" type="base64Binary "/>

<dmp:element name="Access ID" type="base64Binary "/>

<dmp:element ref="Domain key"/>

<dmp:element ref="Device ID list"/>

<dmp:element name="Maximum Number of Device" type="integer"/>

<dmp:element name="Maximum Frequency of update" type="integer"/>

<dmp:element ref="Revocation list"/>




<dmp:element name="Device ID list">


<dmp:sequence minOccurs="0" maxOccurs="unbounded">

<dmp:element ref="Device ID"/>

<dmp:element name="Expiration" type="dateTime"/>






<dmp:element name="Revocation list">


<dmp:sequence minOccurs="0" maxOccurs="unbounded">

<dmp:element ref="Device ID"/>



<dmp:/element>       Domain Context for Device

Domain Context is a set of information resident in devices that can use the DCF with the same Domain Context. Domain Context for Device has Domain Manager ID, Domain ID, Domain key and Expiration.


<dmp:element name="Domain Context for Device">


<dmp:element name="Domain Manager ID" type="base64Binary "/>

<dmp:element name="Domain ID" type="base64Binary "/>

<dmp:element ref="Domain key"/>

<dmp:element name="Expiration" type="dateTime"/>


<dmp:/element>       Domain Context for DCF

Domain Context is a set of information resident in a license that associates a linked DCF. Domain Context for DCF has Domain Manager ID, Domain ID, Domain key, Expiration and Sub-Domain ID list.


<dmp:element name="Domain Context for DCF">


<dmp:element name="Domain Manager ID" type="base64Binary "/>

<dmp:element name="Domain ID" type="base64Binary "/>

<dmp:element ref="Domain key"/>

<dmp:element ref="Sub-Domain ID list of this DCF"/>




<dmp:element name="Sub-Domain ID list of this DCF">


<dmp:element name="Number of rights" type="integer”>

<dmp:sequence minOccurs="0" maxOccurs="unbounded">

<dmp:element name="Sub-Domain ID" type="base64Binary"/>




6.1.2        Protocol between domain manager and Device

We need to clarify the two cases – one where the device is connected, the other where the device remains disconnected & the protocol uses the User as a proxy for these operations.       Creating a domain

A Device must have an User Identification and a Device Identification to join a Domain.

Successful execution of the Join Domain protocol establishes a Domain Context in the Device.



It is left to the discretion of the Domain Manager to react accordingly if a Device joins multiple Domains. The case where the device cannot be uniquely identified the Device generates a random challenge which the domain manager packages into the domain joining message. Domain Manager and device share a common key. The common key is used to transmit the random challenge in order to authorize the other device.  And the common key is also used to transmit the Domain Context. Successful execution of the Creating a domain generates of a set of Domain Information in Domain Manager and sets a new Domain Context in the Device.       Adding a Device

The User may add Devices to the Domain unless the number of Devices exceeds Maximum number of Device defined by Domain Manager. Almost same protocol with Creating a domain is used. The only difference is that account ID and password need to be sent to the Domain Manager at the authentication to get the same Domain ID. Successful execution of the Adding device protocol adds a new Device ID to Device ID list of the Domain Manager and adds a new Domain Context in the Device.       Leaving Domain

User may request Domain Manager to get user’s Device out of the Domain. With user’s request the Domain Manager excludes the requested Device out of the Domain. The protocol is same with Adding a device. Successful execution of the Leaving domain protocol erases a Domain Context in the Device. Domain Manager may also exclude any Device from the Domain without User’s request. In this case, Domain Context in the Device remains. Only Device ID list managed by Domain Manager changes.       Renewing a Domain

For when there is a device malfunction the domain can be renewed. Exceptional case in the disconnected case – would not normally need to do this. After expiration of a Domain Context, the User may request to renew the Domain Context to Domain Manager. Response message from Domain Manager may include new Expiration period of the Domain if Domain Manager gives permission to the Device to extend the Domain. If the Domain has been revoked, the response doesn’t include valid expiration.

[Ed – error in above diagram. Response (expiration) should be ‘Domain Context’.]

6.1.3        Protocol between domain manager and entities that authorize DCF

VCP that authorize Domain-bound content need to communicate with Domain Manager.       Acquire Domain context

When VCP authorizes a Domain-bound content, the VCP requests Domain Manager to send Domain Context of the Domain. Successful execution of the Create Domain-bound content protocol allows the VCP to use the Domain Context as apart of right expression of the Domain-bound content.

[Ed – diagram above needs editing to show ‘Request Domain Context’ phase].

6.1.4        Max number of Devices per Domain

This is a number of Devices allowed to join the Domain.

6.1.5        Maximum frequency of update

Device is not allowed to leave and join the Domain exceeding this frequency.

6.1.6        Simultaneous usage detection

[Need to be use cases somewhere and reference to here.]


Use case:

You want to limit content further than the domain allowed with simultaneous limit rules. For example notify a domain manger when a given a simultaneous use limitation violation where it is possible for user to break simultaneous use limitation.


Simultaneous playback license explained: A group of songs (S1, S2, …, S10) are licensed together to be limited to 1 simultaneous play for any of the songs in the group on a set of devices V1, V2, and V3.  If S1 is playing on a device V1, you should not play any other song from the song group S1 through S10 on the other devices V2 or V3.  Continuing the example, if you are allowed 2 simultaneous plays for the group, you could play S1 on V1 and S2 on V2, but should not play song group S1 through S10 on V3.  Also a piece of content can belong to more than one group.  For example group 1 consists of songs S1, S2, and S3.  .  Also we have group 2 with songs S10, S11, S5.  S3 is allowed to belong to two both groups.  In fact it can belong to more than one.  For example content is licensed as group 1 and group 2 which allows1 simultaneous play each on devices V1, V2, and V3.  Then S3 would be allowed to play on V1 and V2 at the same time.  Likewise S1 will only be allowed to play on V1 or V2, but not both.       Overview

The basic idea of this scheme is on the assumption that Devices in the same domain must be used by limited number of users. If more than expected number of Devices in the same Domain have been used at the same time, it’s to be informed to Domain Manager in order to help the Domain Manager to judge whether to continue to accept the Devices as a member of the Domain.

These implies intermittent connections to the domain manager and other devices, and also a trusted clock.       Sub-Domain

Sub-Domain is identified with Sub-Domain ID which is written in the right object of Content. Sub-Domain represents who mainly uses the Content with the Sub-Domain. A group of Content with the same Sub-Domain ID makes up a Content group of the Sub-Domain. The number of Content to be played at a time in the Content group of the Sub-Domain is limited to the number of Sub-Domain ID of each Content. Content may be given multiple Sub-Domains. In the example described below, Content 1, 2, 3, 4, 5 and 6 belong to Sub-Domain A and Content 4, 5, 6, 7 and 8 belong to Sub-Domain B. Content 4, 5 and 6 may behave as Sub-Domain A or Sub-Domain B. If 4, 5 and 6 behave as Sub-Domain A, one out of 1, 2, 3, 4, 5 and 6, and one out of 7 and 8 are allowed to be played at the same time. If 4, 5 and 6 behave as Sub-Domain B, one out of 1, 2 and 3, and one out of 4, 5, 6, 7 and 8 are allowed to be played at the same time. Each one of 4, 5 and 6 may choose its Sub-Domain independently. This is suitable when more than two users share Devices in their family. Each user requests Content as its Sub-Domain representing his/her ownership. But the number of Sub-Domain to be issued must be limited. Because issuing more Sub-Domains than the number of family members could weaken the capability to detect illegitimate usage.       Play Log

Device must record Play Log of Content on the Device. Every time the Device plays a Content, a new record is added to the Play Log on the Device. Each record must have Device ID, Start time, End time, Notification Flag and Sub-Domain ID. It represents that a Device with “Device ID” played a Content with “Number of Right” and “Sub-Domain” in the time frame of “Start Time” and “End Time”. Notification Flag is set to False when the record is created. Play Log format is described below.


<dmp:complexType name="Play Log">

<dmp:element name="Domain ID" type="base64Binary"/>

<dmp:element ref="Record"/>



<dmp:element name="Record">


<dmp:sequence minOccurs="0" maxOccurs="unbounded">

<dmp:element name="Device ID" type="base64Binary"/>

<dmp:element name="Start Time" type="dateTime"/>

<dmp:element name="End Time" type="dateTime"/>

<dmp:element name="Number of Rights" type="integer"/>

<dmp:element ref=" Sub-Domain ID list of this DCF"/>

<dmp:element name=”Notification Flag” type="boolean"/>





Device ID       

The identifier of the Device that used the Content.

Start Time      

The absolute time when the Content started being played.

End Time       

The absolute time when the Content finished being played.

Number of Rights 

The number of Devices allowed to use the Content of the same Domain simultaneously. It’s equivalent to the number of Sub-Domain. It’s written in the Rights objects of the Content. If it’s not written, it’s considered as 1.

Sub-Domain ID

The Identifier of a sub domain of a Domain. It’s written in the Rights objects of the Content.

Notification Flag

A flag indicating whether this record has been notified to Domain Manager or not.


If the Device leaves its Domain, the Device must hold the Play Log of the Domain in case of rejoining the same Domain.       Integrate the Play Log


When Devices belonging to the same Domain have a connection, each Device copies its Play Log and adds it to the Play Log of the other Device. If this operation causes duplicated record in the Play Log, the duplication will be deleted from the Play Log. If two records have the same information except Notification Flag elemet, the record with FALSE of Notification Flag will be overwritten by the record with TRUE of Notification Flag.


Eventually all of them integrate the Play Log of themselves.  Play Log integration protocol is shown below. If the connection is one way, only a half of the protocol is used to send Play Log from one to the other.       Illegitimate Simultaneous Use

If Play Log has any over wrapped record in time, it’s considered that the Devices indicated by Device ID in the over wrapped record had an illegitimate simultaneous use. All Devices that played any Content of the same Domain and of the same Sub-Domain at a moment are considered as having conducted Illegitimate Simultaneous Domain Use. If the Content is given more than two Sub-Domain ID, it can be whichever Sub-Domain it desires to avoid Illegitimate Simultaneous Domain Use. [Diagram below needs editing to capture changes made to text above and delete Illegitimate Simultaneous Media Use]       Notification to Domain Manager

If Illegitimate Simultaneous Use is detected in the Play Log on a Device, the Device should notify to Domain Manager when a connection is established to Domain Manager. After receiving Illegitimate Simultaneous Use Notice, the Domain Manager uses it as a criteria to decide whether or how to renew the Domain of the Device.  If the Domain Manager judges that the Device that misused the Domain should be revoked, Device ID of the Device is added to Revocation List managed by Domain Manager.


Once Illegitimate Simultaneous Use Notice is sent to Domain Manager, Notification Flag element of the record in the play log is set to “True” by the Device, so that Illegitimate Simultaneous Use Notice won’t be issued again when all record involved in the simultaneous usage have True of Notification Flag.


It is highly recommended that Domain Context is given a limited expiration so that the Device needs to renew the Domain connecting to Domain Manager at reasonable period of time. It’s a good chance to send Illegitimate Simultaneous Use Notice to Domain Manager right before renewing Domain. If the Device is in the Revocation List, the Renewing Domain must fail.

Illegitimate Simultaneous Use notice protocol is described below.

[Ed – diagram above needs editing. Reponse (expiration should read OK)]


Illegitimate Simultaneous Use notice format is described below.


<dmp:complexType name="Illegitimate Simultaneous Use Notice">

<dmp:sequence minOccurs="1" maxOccurs="unbounded">

<dmp:element name="Domain ID" type="base64Binary"/>

<dmp:element ref="Illegitimate Devices"/>

<dmp:element ref="Over wrap Time"/> 




<dmp:element name="Illegitimate Devices">


<dmp:sequence maxOccurs="unbounded">

<dmp:element name="Device ID" type="base64Binary"/>





<dmp:element name="Over wrap Time"/>


<dmp:element name="Start Time" type="dateTime"/>

<dmp:element name="End Time" type="dateTime"/>



6.2        Manage Key

[This section is describing the interoperable aspects of Key management]

6.2.1        Signaling Key Types in DCF

For definition of KeyInfo and related fields to this section see below       The ds:KeyInfo element

The element KeyInfo is specified in XMLDSIG ( ) in order to enable the recipient(s) to obtain the key needed to validate digital signatures. KeyInfo may contain keys, names, certificates and other public key management information, such as in-band key distribution or key agreement data. The XMLDSIG specification defines a few simple types but applications may extend those types or all together replace them with their own key identification and exchange semantics using the XML namespace facility. However, questions of trust of such key information (e.g., its authenticity or strength) are out of scope of the XMLDSIG specification and left to the application.

The KeyInfo element is specified as follows:


<element name="KeyInfo" type="ds:KeyInfoType"/>

<complexType name="KeyInfoType" mixed="true">

            <choice maxOccurs="unbounded">

<element ref="ds:KeyName"/>

<element ref="ds:MgmtData"/>

<any processContents="lax" namespace="##other"/>

<!-- (1,1) elements from (0,unbounded) namespaces -->


<attribute name="Id" type="ID" use="optional"/>




The KeyName element contains a string value (in which white space is significant) which may be used by the signer to communicate a key identifier to the recipient. Typically, KeyName contains an identifier related to the key pair used to sign the message, but it may contain other protocol-related information that indirectly identifies a key pair. (Common uses of KeyName include simple string names for keys, a key index, a distinguished name (DN), an email address, etc.)

Schema Definition:

<element name="KeyName" type="string"/>




 <!ELEMENT KeyName (#PCDATA) >


The MgmtData element within KeyInfo is a string value used to convey in-band key distribution or agreement data. For example, DH key exchange, RSA key encryption, etc. It provides a syntactic hook where in-band key distribution or agreement data can be placed.


Schema Definition:

   <element name="MgmtData" type="string"/>




   <!ELEMENT MgmtData (#PCDATA)>       The xenc:KeySize element

This is simple element defined in the XENC namespace ( ) use to carry the integer size of a cryptographic key. The schema for the KeySize parameter is as follows:


<element name “KeySize” minOccurs='0' type=”xenc:KeySizeType”/>


<simpleType name=”KeySizeType”>

<restriction base="integer"/>





[Add more details about why there are different levels of keys.]

Content data (audio or video) is broken into frames.  Each frame is encrypted as a unit.  A frame key protects a range of frames.  Each frame then has information about which frame key was used to protect it.  [continue].  Frame keys are protected by the content key.

6.2.2        Key Exchange Protocol

[Use SSL3/TLS1, which includes certificates plus Diffie-Hellman.  Do we need to include specifics about Diffie-Hellman details and cert details in this section or just reference.  Numbering need to be fixed.]       Overview

The CEK (Content Encryption Key) must be encrypted for secure transfer against eavesdrops or attacks. For the risk of security, transferring CEK in clear text format is not recommended. There are two ways considerable.


-         Certificate based CEK Exchange using PKI

-         Shared Key mechanism such as Diffie-Hellman algorithm Assumption


Key exchange protocol is only limited to the key generation and exchange to ensure the security of CEK exchange. The device authentication, to check if the devices or software are trustworthy with each other, must be processed prior to CEK exchange. The device authentication is not covered in this section.

The format for transferring key information is based on W3C XML ENC or XML DISG. It does not need to specify the technical guidelines. Certificate based CEK Exchange [Too many headings!!] Key Exchange Scheme

The Certificate based CEK Exchange utilize asymmetric key algorithm to transfer CEK in safe and the CEK is encrypted with the public key of receiver’s device or software.

The receiver’s device or software utilizes its own private key to decrypt CEK. Key Exchange Protocol [Do we need yet another level?]



Sender encrypts the CEK with the receiver’s public key and transfers to receiver. Receiver decrypts with its own private key. Shared Key Exchange Key Exchange Scheme [Redundant header]


Diffiie-Hellman algorithm supports the way for secure key information exchange. Shared Key Exchange utilizes Diffie-Hellman algorithm to generate shared key by key agreement in between devices or software. Key Exchange Protocol



Diffie-Hellman shared key is created when the device authentication is initialized. High bit length must be used for Diffie-Hellman parameter (p, g)’s long term security. Devices generate private key (x1 and x2) and the corresponding public key (y1, y2).The private key, x1 and x2, is a random number generated in every key exchange process. And it must be high bit length to ensure its long term security.


7          Access

[This is a category of primitive functions to request and retrieve entities.]

[Look at references]

[Integrate comments.]

[Work in progress…]

7.1       Access License

7.1.1        Introduction

The License Access Protocol (LAP) will be used for access licenses, expressed on a given Rights Expression Language, to an authenticated DMP device and to an authenticated DMP user.

There may be two different scenarios in which LAP can be used. The first is when the license is directly bundled inside the content and the second should be used when the license is not with the content.

7.1.2        Local License Access Protocol

The Local License Access Protocol (LLAP) should be used in the case that the license is directly bundled with the content.

7.1.3        Remote License Access Protocol

The Remote License Access Protocol (RLAP) should be used in the case that the license is not bundled with the content. This means that the license may be obtained by a different channel from the one used to obtain the content. The RLAP is a transactional protocol that is supported over an existing network protocol (TCP/IP or HTTP in the case of Internet/WWW access). In terms of security, the RLAP uses two security layers:

·        Application-Level: this corresponds to the messages described in the RLAP in this document.

·        Network-Level: this is represented by a security underlying protocol that is the SSL/TLS protocol.


Figure 19 - Security Layers


This RLAP is built on top of the following premises:

·        The first one is related to the fact that the User has acquired the rights on a previous step to use a specific content;

·        The user has offered some financial compensation for the content, or content usage;

·        There is an entity responsible for producing the licenses and managing licenses, and at the same time to produce licenses;

·        That the user has a DMP device that is capable of interpret the licenses and enforce the rights on the DMP content;

·        Last, that the device can connect to the network to obtain a license from the License User.

7.2        Requirements

[Need to determine place for these.  Look at terms definition, such as “credentials”.]

This part of the document describes some of the most relevant requirements which are specific of the license download process:

-         The license download protocol should be independent of the Rights Expression Language that is used to express the license;

-         License download should be secure, specially if the content decryption keys are within the license;

-         Only identified and authenticated devices shall be able to download licenses from License issuer;

-         Licenses should be protected against eavesdropping attacks (licenses should be read only by the legitimate owners and not by third parties);

-         Licenses should be signed and authenticated by the license issuer (tamper resistance);

-         The license download protocol needs to know the device and users credentials[cjcs1]  [cjcs2] and content credentials, in order to retrieve the appropriate license;

-         The license download protocol should contain the necessary mechanisms to verify that the license was in fact received by the user.

7.3        RLAP Description

[Pending peer review for pass 1.]

At the application level RLAP is based on the exchange of messages between two basic components: the DMP device and the License Manager. To support this protocol, it may be necessary that a certain number of third-party authorities exist in order to validate some of the credentials exchanged between the two intervenient.

The RLAP involves the following steps:

1.      The DMP device, checks that the content is protected and that a license is necessary to access to the content;

2.      The DMP device extracts the content identification from the content;

3.      The DMP device asks for the User credentials[cjcs3] ;

4.      DMP device checks its own credentials;

5.      DMP device generates a message that contains the following elements:

a.       The content identifier;

b.      The User credentials;

c.       The DMP device credentials;

d.      A unique transaction identifier generated by the DMP device, that will be used to validate the messages;

6.      This message is signed using the DMP device credentials.

7.      DMP device sends the message to the License Manager;

8.      The License Manager receives the message and:

a.       Checks the digital signature;

b.      Checks both the User and DMP device credentials;

c.       Reads the content identifier.

9.      The License Manager, checks if there is a license on the system for that specific content identification and for that user. Two different situations may occur:

a.       Either the license is in the system, and the License Manager returns it to the DMP device, in the following format components:

                                                               i.      The License Manager credentials;

                                                             ii.      The license signed by the License Manager (the content keys are ciphered with the user public key);

                                                            iii.      The same unique transaction identifier that was sent by the DMP device on the first message.

b.      Or the license doesn’t exist, or the User or DMP device credentials are invalid. In this case the message has the following components:

                                                               i.      The License Manager credentials;

                                                             ii.      An error message signed by the License Manager;

                                                            iii.      The same unique transaction identifier that was sent by the DMP device on the first message.

10.  The DMP device receives the message from the License Manager and checks the message contents, extracting the license and the content keys.

11.  Finally the DMP device sends a confirmation message to the License Manager signalling that the license was receive with success.

The following schema displays the messages exchanged between the DMP device and the License Manager:

Figure 20 - RLAP message sequence



Content Unique Identifier which is a unique identifier assigned to content.


User credential is a set of information that allows the unique identification of a User. This is traditionally a piece of information that is digitally signed by a credential issuance agency.


Device credential is a set of information that allows the unique identification of a Device. This is traditionally a piece of information that is digitally signed by a credential issuance agency.


Transaction identifier is a unique number generated randomly by the DMP device.


This is the license request message. This  message is represented by the set composed by the Cid, the UCred, the DCred and the Tid, digitally signed by the DMP device: SignKprivDevice{Cid + UCred + DCred + Tid}.


This represents the key that will be used to access and render the content. It can be more than one key.


This represents license information expressed in an appropriate Right Expression Language.


This represents the License Manager credentials. This is traditionally a piece of information that is digitally signed by a credential issuance agency.


This message corresponds to the answer returned from the License Manager if the presented credentials are correct and if the requested license exists of the system. This message is expressed with the following: LMCred + SignKprivLM{LICData(KpubU[Ckey])} + Tid


This represents the status error and message to be returned to the DMP device in case something fails.


This message represents the error message if something fails on the protocol. It is composed by the following: SignKprivLM{Status} + Tid


This is a message used to signal the LM that the license was received by the device. This message has the following format: SignKprivDevice{“ACK” +  Tid}



8          Process

See chapter 2 for a long list of Primitive Functions belonging to the Process category]



8.1        Encrypt

[The only ‘process’?]

[Needs completing]


This specification supports the following algorithms for content encryption:



9          References


  1. ISO/IEC 21000-2, Information Technology — Multimedia Framework (MPEG-21) — Part 9: File Format


  1. ISO/IEC 14496-12, Information technology – Coding of moving pictures and audio: ISO base media File format (technically identical to ISO/IEC 15444-12)


  1. ISO/IEC 21000-2, Information Technology — Multimedia Framework (MPEG-21) — Part 2: Digital Item Declaration


  1. ISO/IEC 21000-3, Information Technology — Multimedia Framework (MPEG-21) — Part 3: Digital Item Identification


  1. ISO/IEC 21000-4, Information Technology — Multimedia Framework (MPEG-21) — Part 4: IPMP Components


  1. “XML-Encryption Syntax and Processing” - W3C Recommendation 10 December 2002.


  1. “XML-Signature Syntax and Processing” - W3C Recommendation 12 February 2002.


  1. DMP Approved Document No. 1 Interoperable DRM Platform


  1. DMP Approved Document No. 2 IDP Use Cases.


  1. DMP Approved Document No. 3 Registration Authorities


  1. DMP Approved Document No. 4 IDP Architecture.


  1. DMP Approved Document No. 6 Terminology.


  1. ETSI TS 102 822-5 v1.1.1 Broadcast and On-line Services: Search, select and rightful use of content on personal storage systems (“TV-Anytime phase 1”); Part 5:Rights Management and Protection Information for Broadcast Applications


  1. IETF RFC 1737, K. Sollins and L. Masinter, Functional Requirements for Uniform Resource Names, December 1994.


  1. IETF RFC 2141 R. Moats, URN Syntax, May 1997.


  1. J. Delgado, J. Prados, E. Rodríguez, “Interoperability between MPEG-21 REL and OMA DRM: A Profile?” ISO/IEC JTC1/SC29/WG11 MPEG2005/M11580. Jan 2004.






10     Acronyms –TBD..


See AD #6 for the DMP terminology reference (do not repeat here).

 [cjcs1]This is created from the fact that it is possible that different users share the same device to use content.

 [cjcs2]This credentials may include as well some type of Federated Identity, such as Liberty Alliance

 [cjcs3]By credentials I mean that it could be something that may range from a single login and password, to a digitally signed certificate or a smartcard.