Download 4 Requirements

Per realizzare la proposta
Peer-to-Peer iDRM
Requirements
DATE
ABSTRACT
2007-09-25
Document analysing the requirements of the interoperable DRM system in a Peerto-Peer infrastructure
AUTHOR (COMPANY) Walter Allasia (EURIX), Filippo Chiariglione (CEDEO.net), Leonardo Chiariglione
(CEDEO.net), Angelo Difino (CEDEO.net), Francesco Gallo (EURIX), Marco
Milanesio (University of Torino), Giancarlo Ruffo (University of Torino), Rossano
Schifanella (University of Torino)
VERSION
1.0
KEYWORDS
interoperable Digital Rights Management System, Peer-to-Peer Systems
RELATED ITEMS
dmpf.org – dmin.it
DOCUMENT HISTORY
2007-09-25
2007-09-21
2007-09-14
2007-09-11
2007-09-05
version 1.0 – submitted to DMIN.it forum
version 0.3 – submitted to DMIN.it forum
version 0.2 – submitted to DMIN.it forum
version 0.1 Modified during the iDRM-P2P meeting at University of Turin
First Draft
Page 1 of 26
Il presente documento è stato redatto da Digital Media in Italia (dmin.it), un gruppo
interdisciplinare, aperto e senza scopo di lucro che ha l’obiettivo di definire e proporre aree di
intervento che consentano all’Italia di acquisire un ruolo primario nello sfruttamento del fenomeno
globale “digital media”.
I professionisti che partecipano a dmin.it mettono a disposizione le proprie competenze, visioni ed
esperienze a titolo personale, pertanto quanto riportato nel documento non impegna in alcun modo
le aziende e le organizzazioni all’interno delle quali i singoli professionisti operano.
L’uso delle tecnologie descritte in questa specifica tecnica può infrangere brevetti, copyright o in
generale proprietà intellettuale di terze parti. In nessuna circostanza dmin.it può essere reso
responsabile di identificare tali diritti.
dmin.it non può può essere reso responsabile di qualunque fatto originato da o collegato con l’uso
di questa specifica tecnica.
Digital Media in Italia: http://www.dmin.it
Rilasciato con licenza Creative Commons Attribuzione - Non commerciale 2.5
1
15 dicembre 2007Index
Table of Contents
1 Index ...................................................................................................................................................3
2 Introduction ........................................................................................................................................4
3 Use cases ............................................................................................................................................7
3.1 Distribution of Content Items in a Peer-to-Peer network ............................................................7
Page 2 of 26
3.2 FairP2PMarketPlace ....................................................................................................................8
4 Requirements ....................................................................................................................................11
4.1 System overview .......................................................................................................................11
4.1.1 Expected operational environment system constraints and performances .........................11
4.1.2 High level diagrams of the system showing the external interfaces and data flows ..........12
4.2 Peer-to-Peer Network Infrastructure Requirements ..................................................................12
4.3 Peer-to-Peer Device Requirements ...........................................................................................14
4.3.1 User-Device requirements .................................................................................................14
4.4 Peer-to-Peer Content Requirements ..........................................................................................15
5 Bibliography .....................................................................................................................................17
6 Acronyms .........................................................................................................................................20
7 Glossary ...........................................................................................................................................21
Page 3 of 26
2
Introduction
In this paper we analyse the requirements that a Peer-to-Peer infrastructure has to satisfy in order to
be able to support an interoperable Digital Rights Management System.
The aim of the authors is to point out the required basic features , taking into account the
specifications and the guidelines provided by the Digital Media Project (DMP) [1] as well as the
DMIN.IT initiative [2].
Furthermore we want to provide a solution enabling the scientific research, built on innovative
technologies and oriented to research domain in the fields of peered infrastructures,
multimedia/semantic/social metadata management as well as new business models and value added
services.
In order to figure out what should be our solution, we first provide a simple overview of Peer-toPeer Systems. First of all, we can classify Peer-to-Peer Systems into two main categories: structured
and unstructured [3]. Figure 2.1 [3] shows this classification with some network example.
These systems were originally conceived as unstructured around the year 2000, when the bandwidth
became wide enough to enable other models than client-server.
Figure 2.1 Overview and classification of Peer-to-Peer Systems [3]
These unstructured Peer-to-Peer Systems can be divided into two main generations. The first
generation was implemented in two different ways, one very close to the client-server model with a
central manager (superpeer), and one to the opposite side, with a pure de-centralized system, where
the location of a specific item is unknown and has to be discovered dynamically. Examples of
centralized systems were Napster [4] and BitTorrent [5], while examples of the de-centralized ones
were gnutella0.4 [6] and Freenet [7]. All these systems have revealed points of failure and are no
more used in the current research environment. After a few years, the second generation of Peer-toPeer Systems appeared with the aim to improve the first generation, combining the powerful
features of the centralized and de-centralized systems and being accordingly called “Hybrid”.
Gnutella0.6, JXTA [8] and probably (but no one actually has accessed the source code) the widely
used Skype [9] are examples of second generation Peer-to-Peer Systems.
Second generation Peer-to-Peer Systems have a significant scalability limit: the number of hops
necessary to reach a resource. In a centralized system we have one hop with a single point of failure
and especially a non scalable system due to the central server itself. In a fully de-centralized system
we have a number of hops given by 2N, where N is the number of involved peers [10].
Research has progressed in a new direction to solve these problems: structured Peer-to-Peer Systems
can limit the hops for searching an item to the maximum number of log2N [11] or less [12].
However, this can be achieved only if we provide some kind of routing table for queries to every
peer and also give some kind of self awareness of the network. The hashing algorithms as well as
the simple hash table have played a major role in helping the researches solving this issue. The third
generation of Peer-to-Peer System is actually built on top of Distributed Hash Tables (DHT) [13],
that represent the current research area. Nowadays we have several DHT implementation, such as
Chord [11], CAN (Content Addressable Network) [14], Pastry [12], etc. and research is currently
analysing how to deal with huge amount of multimedia items in DHT-based Systems in a scalable
and efficient way. Since DHT has opened a new world for experimentation, a very powerful
approach is the one that is applying a metric space to DHT, i.e. by providing Metric Content
Addressable Networks (MCAN) [15] as well as GHT* [16], Metric -Chord (M-Chord) [17], etc.
In order to have a better comprehension of a DHT and understand how to fit this into the iDRM
System, Figure 2.2 [10] shows a typical DHT ring, usually composed of about 128 (or 160) bit of
addressing space [18].
Figure 2.2 A linear address space partitioned among 8 peers [10]
In our context we have to hash our metadata (key) and store the couple (key,value) into the DHT
address space whatever a Content Provider Device want to publish some content.
Actually, the logical ring is different from the physical network, as shown in Figure 2.3 [10].
Figure 2.3 The logical and physical layer of a DHT address space [10]
We have to point out that the Network Infrastructure describe in the following is mainly responsible
for providing Contents in a distributed environment and for indexing and searching metadata in a
suitable topology. We do not intend to provide a network enforcing content protection and
government, since these issues are already addressed at the application layer.
The use cases that the solution has to deal with are described in Section 3, while in Section 4 we
describe the requirements that an interoperable Digital Rights Management System as well as a
Peer-to-Peer System have to satisfy.
3
Use cases
For the proposed solution we consider the following use cases: the distribution of Content Items in a
Peer-to-peer network, named in the following Controlled Peer-to-Peer Distribution use case and the
development of a business model which benefit from a high level of cooperation among peers
named in the following FairP2PMarketPlace use case.
In the use cases presented in this document, the following types of users are considered:

Creator: the entity responsible for
o creating a resource (a short movie, a song, etc.)
o specifying the metadata, the rights information (the modalities according to which
other users will be able to use the resource) and if necessary the protection



information for the resource. Hereinafter, the structured bundle of this information is
called the DMP Content Information (DCI).
o wrapping the resource and the DCI in a file, hereinafter the DMP Content File (DCF)
o ingesting the content item in the P2P network as a DCF
Distributor: the entity owning the right to distribute a typically protected content item to
other users or devices, according to the terms and conditions expressed in the license
bundled to it.
End-User: the entity owning the rights to use (e.g. play) a content item according to the
terms and the conditions expressed in the license bundled to it. The end-User may have the
capability to acquire the rights over a certain governed resource by performing some actions
(e.g. make a transaction).
A number of Service Providers, entities that may add value to content by providing services
such as indexing, ranking, etc.
Any User part of the P2P network may play any of the roles presented above.
3.1 Distribution of Content Items in a Peer-to-Peer network
This use case is based on the Use Case and Value Chain No 6 - Controlled Peer-to -Peer
Distribution reported in [19].
We imagine a P2P network whose members can have access to two kinds of Content Items:
(a) Governed by means of a License only, without enforcement (called Open Release by the Digital
Media Project)
(b) Governed by means of a License and Protected by means of DRM Tools
We can focus on a particular situation where these Content Items are mainly music files.
In case (a) we can imagine that the members of the P2P network can create and share their user
generated music to be released as unProtected Items, e.g. with a License allowing for the free
distribution within the P2P network, subject to Creative Commons-like licensing terms.
The members of the network are provided with a program to create and share their own Content
Items. The Content Item is a DCI containing the License, the Metadata and the Resources (or a
reference to them) and is stored in the shared directory of the member of the network as a DCF. The
member associates a License to a new Content Item using a small number of standard templates,
before ingesting the created DCF in the P2P network. The Metadata associated to the Content are
used for indexing it in the P2P network. The other members can search for this Content using the
associated Metadata and consume it according to the License. They could also browse the shared
directory of the member who created the Content to possibly search for similar or related music
files.
In case (b) the network can also host Content Items which are Governed by a commercial License
and are possibly Protected by DRM Tools. We imagine that the members of the network, when
searching for their favorite music, can find the Contents produced by a record company. The
company has joined the network to promote and sell their repertoire or these Content Items. If a
member of the network buys the Content Item, he may store it in the shared directory of his PC. The
members of the network can search for these Items in the network or can discover them "by chance"
when browsing the shared directory of the other members. Content Items produced by the record
company are Encrypted and can be consumed by the other members of the network only after they
have obtained a License. A few of these Items could possibly be unEncrypted because the record
company wants to use them for promotion. The members of the network are provided with a
program which is able to perform the following actions: searching Items, browsing the shared
directory of a given member, identifying the License associated to each Item to be agreed before
consumption, enabling the decryption of the Resource (if necessary) after obtaining the required key
and playing the Content according to the License. It should be noted that the program provided to
the members for this use case can be used also for the situation described in use case (a).
It should be noted that in this use case the members of the network only host Content Items provided
by a record company with a commercial License. In the following section we imagine a use case
where the peer are actively involved in the process of distributing such Content Items by defining a
business model based on a high collaboration among peers.
3.2 FairP2PMarketPlace
This use case models a scenario in which peers trade digital items over a Peer-to-Peer infrastructure
implementing a profit-sharing, fair and high-collaborative platform [20]. With respect to the Use
Case and Value Chain No 6 - Controlled Peer-to-Peer Distribution described in [19], this scenario
differs from the following aspects:
 Distribution model: each peer (authorized to deliver the item) actively participates in the
distribution process sharing his own physical resources (e.g., bandwidth, CPU cycles,
storage space, etc…). Therefore, the content distribution can be performed by a parallel
multi-source download scheme to allow peers serving each other.
 Business and revenue model: in a standard music store like the iTunes market place, a big
reseller sells the content to a wide population of users that pay for the service (the item itself
and the distribution of it). In this case, the customer does not gain the right to redistribute the
content. She can only consume it according to the license conditions. The Peer-to-Peer
scenario introduces new aspects that the business and the revenue models have to deal with.
Together with the typical merchants, e.g. a record company, the scenario is populated by a
set of peers that contribute to the system: they buy, sell and distribute the content in a
collaborative manner. Moreover, each peer can play different roles at the same time. This use
case tries to introduce new economic models that enable profit-sharing and fairness amongst
peers.
Starting from the definition of the types of users introduced above, we identify the following actors:




A Content Item f.
A License related to f, packaged in a DCI file and signed by a LPD.
The Creator of a Content Item f, that deposits all the information about f. It can be the
author of f, or who owns the copyright of f (e.g., a record company).
The Distribution Right is issued/delegated by the Creator when she authorizes a peer to
further distribute a given content.


The Distributor is a regular peer that has gained the distribution right for a given f. Usually,
a peer is authorized to distribute f immediately after he received it.
The End-User is a peer that buys and downloads an object f directly from the Creator or via
an authorized Distributor.
Usually, in an economic transaction, fairness means that all the participants have to be remunerated
for the performed actions. As previously described, in a Peer-to-Peer system the users share not only
digital contents, but also hardware resources like computational power or bandwidth. The system
intends to remunerate a peer both for the original content she shared as well as for the physical
resources provided.
Accordingly, the main idea is that when a peer downloads a Content Item, then it should pay both
the creator and the distributor.
We can assume that each Content Item f has two costs:
 an ownership cost Ca( f )
 a distribution cost Cd( f )
Hence, the total cost of f is C( f ) = Ca( f )+Cd( f ), which is exactly the price that the user should pay
for gaining it. For example, a MP3 song s can have a cost of 1$, where Ca(s) = .99$ and Cd(s) =
.01$; a DIVX movie m, can costs 6$, where Ca(m) = 5.50$ and Cd(s) = .50$. Anyway, we will
assume that Ca( f ) and Cd( f ) are always deducible from the meta information contained in the DCI
segment. The costs for the distribution and the ownership of a given object are substantially
different. They depend on several criteria, most of them based on the market trends.
With respect to the distribution model, we have three scenarios:
(1) the distributor is the creator (or a delegate),
(2) there is only one distributor,
(3) there are multiple distributors, i.e., multi-source download.
Figure 3.1 summarizes the actors and the messages involved in the previous three scenarios.
Figure 3.1 - Actors and the messages involved in the FairP2PMarketPlace scenario
When the Creator of a resource creates a Content Item and, therefore, the License associated, he has
to define the revenue policies in order to set the ownership and distribution costs. There are many
feasible scenarios that strongly depend on the terms of the License. In the following, we describe
two possible schemes:
1. The Content Item f is unprotected and freely distributed for non-commercial purposes. In this
case, both the Ca(f) and Cd( f ) costs can be null.
2. The Content Item f is protected by a Commercial License. The Creator defines Ca(f) and
Cd(f) according to the pricing mechanism implemented in the market. When a Receiver buys
the item f, she has to pay Ca( f ) to the Creator and Cd( f ) to the peers that participate to the
distribution process. Afterwards, the Receiver acquires the Distribution Right and she
becomes a licensed distributor for f.
The dynamics described above is strongly related to the notion of incentives to cooperate and, in
particular, with the countermeasures adopted to fight the free-riding phenomenon. In fact, the
market tends to attain a scenario in which peers have not the tendency to deviate from a cooperative
behavior in which they trade digital contents and physical resources, because it represents the most
profitable strategy.
In order for a market to take place, we will assume the presence of mechanisms for accounting
services and resources consumption as well as functions for crediting and debiting users. We assume
the existence of a function pay(idX , idY , v) that invokes all the measures in order to securely provide
a payment of value v from user X to user Y. The use case is not related to a particular scheme,
anyway, the iPay [21] specification can provide all the necessary functionalities.
4
Requirements
4.1 System overview
The system has to fully support an interoperable Digital Right Management System. In this way we
have to take into account the guidelines and specifications provided by DMP [2, 19, 22-25].
Figure 4.1 shows the value chain in a interoperable DRM. There are for main boxes representing the
responsibilities as Distributed Services, Content Creation, Content Providing, Stationary
Audio/Video. In these boxes we can imaging the relative Devices running the roles written in the
ellipses. The Service Provider Devices are transversal to the others as they can be addressed in every
ring of the chain.
In our Peer-to-Peer infrastructure, the main difference with respect to the standard client-server
architecture, resides in the content provider as it is distributed and mirrored and can also provide a
partial content in the multi source download scenario.
Figure 4.1. Value Chain of iDRM.
4.1.1 Expected operational environment system constraints and performances
Concerning the environment, our aim is to address several and different Operating Systems and
Platforms. This is the same goal as Chillout [26]. Our implementation has to maintain the
multiplatform capability.
The hardware commonly available for a laptop must be sufficient for running the iDRM Peer-toPeer solution. We can figure out that the memory needed should not exceed one Gbyte and the
computing power needed should not require more than a simple CPU.
The bandwidth provided by an ADSL connectivity should be enough for running the solution, even
if the intrinsic asymmetric connection cannot give good performances in an infrastructure where
peers, by definition, are actually client and server at the same time, hence the communicate
symmetrically.
4.1.2 High level diagrams of the system showing the external interfaces and data flows
Figure 4.2 shows the main components identified for having an iDRM System.
Figure 4.2 Devices involved in the iDRM system
The yellow boxes provide transversal services to all the involved devices and they should be
centralized services. They are responsible for identifying devices, contents and domains. In the
following we do not take into account the last, as the domains in a Peer-to-Peer topology can be
figured out as Overlays and need a special analysis, which is beyond the scope of this paper.
The rose boxes are actually the end users and the only difference in our network topology is that
these SAV have to be able to access contents from several distributed providers. Anyway these
content providers, represented by the green coloured box in the middle, are essentially different
from the standard architecture. In a Peer-to-Peer environment the Content Provider has to deal with
the specific topology and in our DHT case it has to publish the hashed metadata of the Contents to
the network.
Also it has to provide the Access to the content to the other Content Providers by means of standard
protocols based on TCP/IP. In the following we summarise the requirements into 3 main categories:
network infrastructure, device and content.
4.2 Peer-to-Peer Network Infrastructure Requirements
In order to have a complete iDRM System on a Peer-to-Peer infrastructure, we have to find out the
most powerful Peer-to-Peer solution that should be able to realise the use cases discussed above, as
well as all the requirements and prerequisites coming from the interoperability of the DRM System.
Moreover, focusing the attention to the Peer-to-Peer network infrastructure, the chosen solution
must satisfy the following requirements:
Req. no. 1 It has to be immediately available
Req. no. 2 It has to be stable
Req. no. 3 It has to provided by some kind of Open Source license
Req. no. 4 It has to be easily integrable into the Chillout Platform [11]
Req. no. 5 It has to be a structured Peer-to-Peer System based on DHT (Distributed Hash Table)
topologies because:
5.1 it solves some limitations and constraints due to the unstructured Peer-to-Peer System of
second generation as scalability, performance, limited number of hop per search.
5.2 it has to enable the scientific experimentation of the solution, combined together with an
iDRM System, in order to involve researchers and universities.
5.3 it has to be open to new features/technologies as capable of taking into account
Social/Semantic/... Overlay Networks (SON) [27] and also value added services as
recommendation systems.
Req. no. 6 It has to support metadata queries on all the published contents available on the network
as well as on a specific peer. The queries should be as follows:
6.1 simple keyword queries
6.2 structured queries as hierarchy and range queries
6.3 queries for similarity searches on contents [28] as well as rights [29,30]
Req. no. 7 It has to support a schema for metadata management as follows:
7.1 describing the content itself (multimedia features) MPEG-7 [ 31]
7.2 describing social and semantic information MPEG-7
7.3 expressing the license MPEG-21 REL [32]
Req. no. 8 It has to enable peers to share and protect their own real identity.
Req. no. 9 It has to support the use of a virtual identity of the user.
Req. no. 10 It has to support the dynamic discovery of the distributed services available on the
network [32]
Req. no. 11 It has to be able to monitor the content transfer between peers.
Req. no. 12 It has to enable peers to load/store their contents with the following modalities:
contents loaded/stored onto the own shared directory
contents loaded/stored onto the shared directory of an agreeing peer
Req. no. 13 It has to support several and different business models
Req. no. 14 It has to support the multi-source transport/download from peers having the whole as
well as partial content as source.
4.3 Peer-to-Peer Device Requirements
In our environment a Peer-to-Peer Device could act as a CPD, a SAV or a CCD or a combination of
them: it is important to notice that all these logical components can be bundled into the same
software package and therefore can run on the same hardware device, hence on the same peer. A
peer running as simple SAV Device could actually apply for a “free ride” as it only consume
contents and resources, without supplying the network with it own resources (that's done by CPD).
As we are facing the distribution of Governed Contents we have to address this problem. In our
scenario, the free riding as we know it is not possible at all. The user can copy/share whatever he
wants and can provide files unprotected and not governed by any license, but the system will not
take into account these items and nobody will be able neither to look for nor to access them.
Wrapping up, a peer can act as SAV, consuming the items (perhaps paying for accessing them), as
well as CPD, providing contents and in the FairP2PMarketPlace scenario he should be able to have
revenues for this feature. Lastly a peer can act as CCD, creating the contents and publishing them on
the network infrastructure. We have to point out that the CCD has to be bundled with the CPD
because once the content is created it has to be published and made available by means of the
content provider. We are willing to disable the publication of a content item on a different peer than
the creator. In the future a different configuration could be possible, where a peer can actually run
only the Creation Device, but a more in-depth analysis should be done especially concerning the
security, bandwidth consumption, and fake uses.
The SAV device represents the End-User Device, able to apply for a search on the peered network
and consume the items found, according to their licence rights and constraints.
4.3.1 User-Device requirements
As stated above, in our scenario, the User-Device will embed the following functionalities:
1. Content Provider Device (CPD)
2. Content Creation Device (CCD)
3. Stationary Audio/Video Device (SAV)
Considering these 3 components (CPD, CCD, SAV) available on the User-Device acting as peer, we
can better define the responsibilities.
The CPD has to be able to:
1. Join the Peer-to-Peer network,
2. Apply for a put(key,value) into the network, indexing the contents in the chosen topology
3. Support the multi source download, by means of appropriated API
The SAV has to be able to:
1. Join the Peer-to-Peer network,
2. Apply for a get(key) on the network, searching for some content, where key should be a
keyword as well as a structured query
3. Use content according to its License
4. Access License from LPD (internal as well as external to the Peer-to-Peer network)
The CCD has to able to:
1. Join the Peer-to-Peer network
2. Ask for a License to the License Provider Device
3. Access the DRM Tool Provider Device
4. Create the DCI/DCF structure to be published on the network
5. Push the created content to the related Content Provider Device (running on the same peer)
4.4 Peer-to-Peer Content Requirements
Concerning the contents, our solution of iDRM on Peer-to-Peer System has to deal with Digital
Items, starting from audio and still images files, leaving the video as well as the streaming
capabilities for a further analysis. The metadata referring the digital contents has to be formatted as
MPEG-7 [28] and MPEG-21 [29]. The first will take into account metadata concerning the content
itself, multimedia features as well as semantic information. The latter has to represent the metadata
concerning the expression of the associated Rights.
Our solution has to manage governed content (with an associated License) that could be provided in
a clear representation or could be protected by means of DRM Tools
Each Content Item shall contain at least:
 Content Identifier
 Content Metadata
 License(s)
 Resources (inline or referenced)
and optionally:
 DRM Information
 DRM Tools
 Event Report Request
The structures of the mentioned DCI and DCF files are represented in figure 4.1. These files
represent our governed content (DCF). Even if a peer can share several items also unprotected as
well as ungoverned, the CPD will not provide them to the other peers and the related metadata will
not be indexed on the network. Hence we can assume that in our solution we only deal with
governed content. Other scenarios are also possible but are left for further analysis.
Taking into account only Governed Items means that our solution prevents unauthorized copies and,
even if a peer acting a Content Provider is able to store and share several items coming from
different peers, he can access only those he holds the rights for.
Figure 4.1 Structures of DCI and DCF files [4-8]
5
Bibliography
[1] Digital Media Project (DMP) - http://www.dmpf.org
[2] DMIN.it - Digital Media in Italia - http://dmin.it
[3] Jorg Eberspacher, Rudiger Schollmeier - First and Second Generation of Peer-to-Peer SystemIn Peer-to-Peer Systems and Applications, volume 3485 of Lecture Notes in Computer Science.
Springer-Verlag Berlin Heidelberg, 2005.
[4] Napster – http://free.napster.com/
[5] BitTorrent – http://www.bittorrent.com/
[6] gnutella - http://www.gnutella.com/
[7] Ian Clarke et al. Freenet: A Distributed Anonymous Information Storage and Retrieval System.
Edinburgh, University of Edinburgh-Division of Informatics, 1999.
[8] JXTA - Li Gong. JXTA: A Network Programming Environment. IEEE Internet Computing,
5(3):88–95, 2001. ISSN 1089-7801
[9] Skype – http://www.skype.com/
[10] Klaus Wehrle, Stefan Gotz, Simon Rieche - Distributed Hash Table - In Peer-to-Peer Systems
and Applications, volume 3485 of Lecture Notes in Computer Science. Springer-Verlag Berlin
Heidelberg, 2005.
[11] Ion Stoica, Robert Morris, David R. Karger, Frans M. Kaashoek, and Hari Balakrishnan.
Chord: A scalable peer-to-peer lookup service for internet applications. In Proceedings of the 2001
Conference on Applications, Technologies, Architectures, and Protocols for Computer
Communications (SIGCOMM 2001), San Diego, California, August 27-31, 2001, pages 149–160.
ACM Press, 2001.
[12] A. I. T. Rowstron and P. Druschel. Pastry: Scalable, decentralized object location, and routing
for large-scale peer- to-peer systems. In Middleware, pages 329–350, 2001. http://research.microsoft.com/~antr/Pastry/
[13] Klaus Wehrle, Stefan Gtz, and Simon Rieche. Distributed Hash Tables. In Peer-to-Peer
Systems and Applications, volume 3485 of Lecture Notes in Computer Science, chapter 7, pages
79–93. Springer-Verlag Berlin Heidelberg, 2005.
[14] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenker, “A Scalable Content-Addressable
Network”, Proceedings of ACM SIGCOMM 2001.
[15] Fabrizio Falchi, Claudio Gennaro, and Pavel Zezula. A content-addressable network for
similarity search in metric spaces. In Proceedings of the 3rd International Workshop on Databases,
Information Systems, and Peer-to-Peer Computing (DBISP2P 2005), Trondheim, Norway, August
28–29, 2005, pages 126–137, August 2005.
[16] S. Ratnasamy, B. Karp, L. Yin, F. Yu, D. Estrin, R. Govindan and S. Shenker - GHT: A
Geographic Hash-table for Data-centric Storage in Sensornets - In First ACM International
Workshop on Wireless Sensor Networks and Applications (WSNA), September 2002.
[17] David Novak and Pavel Zezula. M-Chord: A scalable distributed similarity search structure. In
Proceedings of First International Conference on Scalable Information Systems (INFOSCALE
2006), Hong Kong, May 30 – June 1, 2006, pages 1–10, New York, NY, USA, 2006. ACM Press.
[18] Stefan Gotz, Simon Rieche, Klaus Wehrle - Selected DHT Algorithms - In Peer-to-Peer
Systems and Applications, volume 3485 of Lecture Notes in Computer Science. Springer-Verlag
Berlin Heidelberg, 2005.
[19] Approved Document No. 4 – Use Cases and Value Chains: a collection of all Use Cases along
with normative specifications of examples of (portions of) Value-Chains implementing the Use
Cases using the Tools drawn from the IDP Toolkit.
[20] G.Ruffo, R.Schifanella “FairPeers: Efficient Profit Sharing in Fair Peer-to-Peer Market
Places”, in Aiko Pras, Jürgen Schönwälder, Burkhard Stiller Guest Editors, Journal of Network and
Systems Management (JNSM), special issue on Peer-to-Peer Technologies Service Management,
September 2007, Springer Press
[21] DMIN.it, iPay Sistema di registrazione e conversione punti per digital media
[22] Approved Document No. 1 – Value Chain Functions and Requirements: a collection of
Primitive Functions derived from today’s media value-chains with corresponding Requirements.
[23] Approved Document No. 2 - Architecture: a general architecture that describes some of the
digital extensions of today’s media value-chains and collects the basic assumptions and technologies
underlying the establishment of IDP-enabled Value-Chains.
[24] Approved Document No. 3 – Interoperable DRM Platform: a collection of technical
specifications of basic Tools that are needed to implement Primitive Functions.
[25] Approved Document No. 5 – Certification and Registration Authorities: a set of operational
rules for Certification Authorities established to Certify Devices and DRM Tools, and Registration
Authorities established to Assign Identifiers to Content, DRM Tools, Devices, Users and Domains.
[26] Chillout Software – http://chillout.dmpf.org
[27] A. Fast, D. Jensen, and B. N. Levine. Creating social networks to improve peer-to-peer
networking. In KDD, pages 568–573, 2005.
[28] Michal Batko. Distributed and Scalable Similarity Searching in Metric Spaces. In Current
Trends in Database Technology - EDBT 2004 Workshops, EDBT 2004 Workshops PhD, DataX,
PIM, P2P&DB, and ClustWeb, Heraklion, Crete, Greece, March 14-18, 2004, Revised Selected
Papers, volume 3268 of Lecture Notes in Computer Science, pages 44–53, 2004. ISBN 3-54023305-9.
[29] W. Allasia, F. Chiariglione, F. Falchi, F. Gallo, “An Innovative Approach for Indexing and
Searching Digital Rights”, Proceedings of AXMEDIS 2007 - 3rd International Conference on
Automated Production of Cross Media Content for Multi-channel Distribution.
[30] W. Allasia, F. Falchi, F. Gallo, N. Orio, “A Digital Rights Aware Similarity Measure for
Multimedia Documents”, Proceedings of MS 2007 – First ACM Workshop on the Many Faces of
Multimedia Semantics
[31] MPEG-7 - ISO/IEC. Information technology - Multimedia content description
interfaces., 2002. 15938.
[32] ISO/IEC 21000-1:2001 MPEG-21 Vision, Technologies and Strategy
[33] One Ring to Rule them All: Service Discovery and Binding in Structured Peer-to-Peer Overlay
Networks – M. Castro, AM. Kermarrec, A. Rowstron (Microsoft Research, Cambridge-UK), P.
Druschel (Rice University,Houston-USA)
6
Acronyms
Acronym
BBL
CCD
CID
CPD
DCB
DCF
DCI
DCS
DID
DIS
DoID
DMD
DPD
DRM
IDP
GUI
Meaning
Bitstream Binding Language
Content Creation Device
Content Identification Device
Content Provider Device
DMP Content Broadcast
DMP Content File
DMP Content Information
DMP Content Streaming
Device Identification Device
Digital Item Streaming
Domain Identification Device
Domain Management Device
DRM Tool Provider Device
Digital Rights Management
Interoperable DRM Platform
Graphical User Interface
IP
IP
LID
LLAP
LPD
OWL
PAV
PKI
PXD
RCAP
REL
RLAP
RMPI
RTP
SAC
SAV
TCG
TCP
TPD
TPM
TPM
TRU
TS
TSS
UDP
URI
XML
7
Intellectual Property
Internet Protocol
License Identification Device
Local License Access Protocol
License Provider Device
Ontology Web Language
Portable Audio and Video (Device)
Public Key Infrastructure
PAV eXternal Device
Remote Content Access Protocol
Rights Expression Language
Remote License Access Protocol
Rights Management and Protection Information
Real Time Protocol
Secure Authenticated Channel
Stationary Audio and Video (Device)
Trusted Computing Group
Trusted Computing Platform
DRM Tool Provider Device
Technical Protection Measure
Trusted Platform Module
Traditional Right and Usage
(MPEG-2) Transport Stream
Trusted Software Stack
User Datagram Protocol
Universal Resource Identifier
eXtensible Markup Language
Glossary
From [1][4-8]
Access (Content)
Bundle
Certificate
Certification
Certification Agency
Certification Authority
Condition
Content
The Function executed by a Device when making Content
available so that the Device can execute Functions on it
The Function of binding two sets of Data
A token attesting that an Entity has passed the tests of a
Certification Agency
The process whereby a Certification Agency issues a
Certificate
A User appointed by a Certification Authority to Certify
Entities
A User appointing and overseeing Certification Agencies
The terms and obligations under which Permissions in a
License can be exercised
A DMP-defined structure of Content Elements
Content Element
Content Entity
ContentGroup
Content Interoperability
Content Item
Content Provider
Control Point
Copy
Creator
Credentials
Data
Decrypt
Delete
Deliver
Delivery System
Device
Device Entity
Device Information
Device Interoperability
Distribution
Distributor
DMP Content Broadcast (DCB)
DMP Content Broadcast (DCS)
DMP Content File (DCF)
DMP Content Information (DCI)
DMP DRM System
Any of the following Data types: Resource, Metadata,
Content, License, DRM Information, DRM Tool, DRM Tool
Pack and Use Data
Any of the following Entities: Content and Content Elements
A group of Content Items for Management within Domains
The capability of a Content Item to be Used by a Device in the
way expected by the Device(s) from which the Content has
originated. DMP Governed Content is Interoperable with
DMP Devices
A particular instance of Content
A User who Delivers Content to another User
A point in a Device under the control of a DRM Tool, e.g. in a
Resource decoding pipeline
The Function by which Device A Stores Content in Device B,
preserving the original Content in Device A
A User who generates a Work and makes its first
Manifestation, also referred to as author
Information describing the security attributes of an Entity
Information converted to digital form
The Function of bringing previously unprocessable Data to a
processable form using a Key
The Function of erasing a Content Item Stored on a Device
The Function of transferring Content between any two or
more Devices using a transport mechanism (file download,
broadcast transport protocol or network streaming protocol)
A system designed to enable Delivery of Content between
Devices
A combination of hardware and software or just an instance of
software that allows a User to execute Functions
Any of the following Entities: Device, User and Domain
Data characterising a Device, e.g. CPU, OS etc.
The capability of a device to exchange data with other devices
across standard interfaces, using standard protocols, and to be
processed by the devices exchanging the data in a predictable
fashion. DMP Devices are Interoperable
The Function of selling, renting and lending
A User who distributes a Product
DMP Content Information Packaged for Delivery as
Broadcast
DMP Content Information Packaged for Delivery as
Streaming
DMP Content Information Packaged for Delivery as File
The digital Representation of Content
A DRM System that realizes Interoperability. A DMP DRM
system implementation allows Devices to Use Content from
another DMP DRM System implementation even though the
latter may use different technologies
DMP Information
Domain
Domain Context Information
Domain Information
Domain Management
DRM Function
DRM Information
DRM Message
DRM Processor
DRM system
DRM Tool
DRM Tool Agent
DRM Tool Body
DRM Tool Group
DRM Tool Pack
End-User
Entity
Environment
File
Footprint
Governed Content
Grant
Data used to describe Content and Content Elements not
related to Governance
A set of Devices sharing some common attributes, such as
personal or group ownership that is appropriate for various
business models
Data characterising a Domain that is Stored in a Device for the
purpose of Managing and Licensing Use of Content in
Domains
Data characterising a Domain that is Stored in a Domain
Management Device, e.g. the list of Devices, Users, Domain
Key etc.
The set of Functions that relate to the
1. creation, renewal and deletion of Domains
2. joining, renewing and leaving a Domain by Devices and
Users
3. Licensing of Content to Domains
Data that describe Governance of Content
A message exchanged between DRM Tool Bodies, DRM
Processor and Devices
A module within a Device Certified as being Trusted for
executing DRM Functions
A system of Information Technology components and services
which strives to distribute and control content and its rights.
This operates in an environment driven by law, policies and
business models.
An algorithm which implements one or more DRM Functions
Executable code that instantiates, initialises, Authenticates,
and supervises any operation performed between DRM Tools
within a DRM Tool Group
An executable computer code that implements a DRM Tool
A combination of DRM Tools
Executable code that comprises a DRM Tool Group and its
DRM Tool Agent
A User in a Value-Chain who ultimately consumes Content
Any of the following: Intellectual Property Entities, Content
Entities and Device Entities
A Device or set of interconnected Devices. An Environment
can interact with other Environments using Protocols and can
also interact with the outside of the Environment through
appropriate interfaces using protocols
Content Entity which is Stored on a Device
The geographic area, typically delimited by political
boundaries, intended to be covered by a broadcast signal
A Content Item that is at least Identified
The Function of a User asserting to another User the
Permission to Use a Content Item under specified Conditions
Identifier
Identify
Instance
Instantiator
Integrity
Intellectual Property (IP)
Interface
Intermediary
Interoperability
Key
Key Management
Licence
License
Licensee
Licensor
Metadata
Move
Package (Content)
Performer
Permission
Platform
Play
Policy
Primitive Function
Principal
The unique signifier Assigned by Identification
The Function of Assigning a unique signifier that establishes
the identity of Entities
An object or event which is an example of an Identified
Manifestation (e.g. a File)
A User who produces an Instance
The state of a Content Item or a Device when the information
contained has not been altered or corrupted
Any identifiable product of the mind attributable to any
person(s) or legal entitie(s) that can be represented or
communicated physically and protectable by copyright or
similar laws.
The Data interchange point between
1. Devices
2. Devices and devices
3. Devices and Users
4. Devices and Delivery Systems
Any Value-Chain User with the exclusion of Creator and EndUser
The ability of a User to technically execute Functions through
Interfaces and Protocols, based on open specifications, with
predictable results
Data used by a cryptographic method to make Clear-text Data
Encrypted or, conversely, Encrypted Data Clear-text
The set of processes employed to create, authenticate, issue,
distribute, store, recover, and revoke Keys
Data Representing the Permissions to a Content Entity under
given Conditions expressed by Rights Expressions that are
Granted by one User to another User
The Function by which a User Grants Permissions to Use a
Content Entity
The User to whom another User Grants Rights
The User who Grants Rights to another User
Data that describe Content and Content Elements
The Function by which Device A Stores Content in Device B
deleting the original Content in Device A
The Function of Processing Content for the purpose of
Delivering it between Devices
A type of Instantiator
The ability to execute Functions on a Content Item
The technology infrastructure that enables Users to Use
Content
The Function of Rendering a Resource
A principle accepted by a group of Users
A Function typically embedded in a Function or more than
one Function
The User to whom Permissions are Granted
Private Copy
Private Key
Process
Produce
Producer
Product
Protocol
Public Communication
Public Key
Publish
Publisher
Register
Registered Content
Registration Agency
Registration Authority
Release
Render
Represent
Resource
Resource Processor
Resource Type
Restore
Retailer
The Function of Storing Content and hold it private for non
commercial purposes
A Key used to Encrypt Data that only the corresponding
Public Key can Decrypt or Decrypt data Encrypted by the
corresponding Public Key
The Function of transforming Data executed by a Device
The Function of making Products
A User that makes Products
A Content Item that adds value to IP Entities by including
them with an appropriate Licence for the purpose of
Publishing
Data formats and rules Devices must follow to exchange
information with each other
The Function of publicly displaying/performing, e.g. live
performance, radio, television, internet streaming, multicast of
Instances and Manifestations, and download
A Key used to Encrypt Data that only the corresponding
Private Key can Decrypt or Decrypt data Encrypted by the
corresponding Private Key
The Function of making available a Product to other Users
A User who selects a Product and makes it available to other
Users
The Function of Assigning an Identifier to an Entity and
keeping a record of it
Content to which an Identifier has been Assigned by a
Registration Agency
A User appointed by a Registration Authority to Assign
Identifiers
A User managing Identifier name spaces, and appointing and
overseeing Registration Agencies
The Function of making a Content Item available to other
Users, e.g. at commercial terms
The Function of converting a Resource to a humanperceivable form
The Function of expressing information in a form that can be
processed by a Device
Data, whose Representation is not specified by DMP (e.g. an
MP3 file or an executable code), that can be Processed by a
Device
A module within a Device capable of processing Resources
A Resource such as video, audio, audio-visual, text, synthetic
audio, 2D/3D graphics etc.
The Function of Moving Content and the associated Stateless
Rights Expression, if any, to the Device from which Backup
had been performed
A User who sells or Licenses Content to an End-User
Revoke
Rewind
Right
Rights Data
Rights Expression
Rights Holder
Role
Schema
Secure Authenticated Channel
(SAC)
Service
Signature
Stateless Rights Expression
Store
Stream
Super Distribution
Synchronise
Syndicate
Technical Specification
Tool
The Function of recalling a Content Item or removing the
ability of a Device to Use Content
The Function of restarting the Rendering of a Resource
A consequence of ownership of Intellectual Property yielding
the ability of performing one or more Functions
Data that describes the semantics of actions that can be taken
on or with IP Entities
Data that can be Processed to obtain the list of Functions
Permitted on a Content Item and the Conditions under which
they can be performed
A User who has Rights to License Content
A defined set of actions and corresponding Conditions
attributed to and required of a User
A description of the structure and rules an XML document
must satisfy
A Delivery System that is secure and Encrypted
A set of Functions executed by a User on Content that is
valuable for another User or Users
Data Encrypted with a Private Key and appended to other
Data typically for the purpose of guaranteeing the Integrity of
the Data
A Rights Expression that does not include any Use counts or
overall Use duration etc.
The Function by which Device A Delivers Content to Device
B for the purpose of retaining it in Device B for Use at a
different point in time
The Function of Delivering Content to a Device where the
transferred Content is Processed for Rendering only and not
Stored
A mechanism that
1. Allows an End-User to Distribute Content to recipient
End-Users or Devices and
2. Enables the End-Users of the recipient Devices to obtain a
Licence for the said Content
The Function of concurrently performing/displaying two
distinct IP Entities each for a different human sense e.g. text
and audio or video and song
The Function of Licensing Works or Content for Publication
or Distribution by more than one Publisher or Distributor,
typically simultaneously
A type of Approved Document containing normative clauses.
Its use in Devices, Contents and Services may require
business agreements between relevant Users. Such business
agreements are outside of DMP
A technology capable of implementing a Function
Traditional Right and Usage
Trust
Trust Management
Use
Use Case
Use Context
Use Data
User
User Data
User Identity
Value-Chain
Value-Expression
Verify
A Right or exception or custom to use content in a given
manner within Jurisdiction
A state where Device Entities enable Users to execute
Functions on Governed Content
The set of mechanisms by which Trust can be established,
preserved and severed
The execution of a Function on a Content Item by a Device
A description of a specific case involving the establishment
and operation of a Value-Chain that can be implemented using
the Tools specified in Approved Documents
The association of a Content Item with other Content Items
and the circumstances of Use
Data documenting the Functions performed by a Device on a
Content Item and the associated context
Any person or legal entity in a Value-Chain connecting (and
including) Creator and End-User. For the purpose of the
current phase of Approved Documents a User is represented
by a device or by a User Identity on the Device (e.g.
username/password).
Data related to a User
Data that establish the distinct personality of a person or a
legal entity
A group of interacting Users, connecting (and including)
Creators to End-Users
The equating of any two groupings of Content Items and/or
Services
The Function of assessing
 The Integrity of a Content Item
 The Integrity of a Device
 The Role adopted by a User with respect to the IP
Entity represented by a Content Item