Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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