The Digital Media Project

INTEROPERABLE

DIGITAL RIGHTS MANAGEMENT

PLATFORM

Technical Specification, Phase II

9 February 2006

Foreword

The Digital Media Project

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

Membership in DMP is open to any corporation and individual firm, partnership, governmental body or international organisation. DMP does not restrict Membership on the basis of race, colour, sex, religion or national origin. By joining DMP each Member agrees, both individually and collectively, to adhere to open competition in the development of digital media technologies, products or services. DMP Members are not restricted in any way from designing, developing, marketing or procuring digital media technologies, hardware, software, systems or services. Members are not bound to implement or use specific digital media standards, recommendations and specifications by virtue of their participation in DMP.

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

DMP operates on the basis of open international collaboration of all interested parties: corporations and individual firms, partnerships, governmental bodies or international organisations, supporting the DMP mission and the means to achieve its goals. DMP ADs are developed according to the DMP Procedures of Work [11]. DMP seeks the involvement of creators and end users of Digital Media through appropriate mechanisms.

DMP ADs are publicly available documents whose copyright is retained by DMP. DMP contributes the results of its activities to appropriate formal standards bodies and other appropriate entities whenever this is instrumental to achieve the general DMP goals. Electronic copies of DMP ADs can be obtained free of charge from the DMP web site (http://www.dmpf.org/) or from the DMP Secretariat (secretariat@dmpf.org).

DMP has the intention to make ADs available in a form such that users can implement them either freely, or on a royalty-free basis or on fair and reasonable terms and non discriminatory (RAND) conditions following the IEC/ISO/ITU policy on IPR in international standards. When issuing Calls for Proposals DMP explicitly advises Respondents to the Calls of this policy. If DMP references an external standard or specification in a DMP AD, DMP expects that the same IPR policy, or a comparable one, has been adopted by the entity that produced the standard or specification.

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

Media and Digital Technologies

Media content has always played an important role in all societies and manifold technologies have been invented and deployed to provide means to store, distribute and consume it. The complexity of these technologies and the stimulus to provide ever-enhanced end-user experiences have created very complex media content value-chains populated by an increasing number of interacting intermediaries, each providing increasingly sophisticated services to the two extremes of the value-chains – creators and end users – as well as to the various intermediaries in between. Note that in DMP all players in the value chain – Creators, intermediaries and End-Users – are generically called Value-Chain Users or, simply, Users. Note that terms beginning with a capital letter are defined in the DMP Terminology [6].

Media value-chain technologies have been designed with two main purposes in mind: the first to provide or augment the end-user experience, and the second to provide or augment the capability to distribute media content. The latest round of technologies – the digital technologies – have augmented the end-user experience, e.g. by providing very high quality audio and video that does not deteriorate with time and use. Further digital networks have also dramatically increased the distribution potential of media content.

As a result the traditional means to manage the value of media content along the value-chain are rapidly losing their established meaning. This is the source of various difficulties and is the major cause of the poor exploitation of the potential of digital media technologies. Digital Rights Management (DRM) has been advocated by many as the set of technologies that can overcome these difficulties because Users are given the possibility to manage Content while it moves along the Value-Chain.

The Digital Media Project agrees that DRM has the potential to combine the benefit of digital technologies with the need for a virtuous circle that motivates Creators to continue creating because remuneration is facilitated by DRM technologies. However, DMP sees serious problems in the introduction of DRM technologies that are lacking Interoperability.

A DRM system can be described as a particular form of communication designed to provide controlled communication between two or more Users. Therefore the implementation of a DRM system may require a broad range of communication technologies. Unless these are designed in such a way as to enable communication of Content between two different implementations, DRM becomes an obstacle that prevent Users from having the seamless and rewarding communication that digital media technologies have enabled. This has particularly serious consequences in the case of the End-User because the lack of Interoperability detracts from the End-User experience and thus may seriously impede the take off of services designed to provide appropriate remuneration to relevant value-chain users.

Standards can bring benefits to the very special type of communication systems called DRM. However, the application of DRM standards obeys different rules because DRM is tightly con­nected to business practices. As the introduction of digital technologies is currently forcing chan­ges in the way value-chain users conduct their business, it is hard to define today what kinds of standards are required, much less to forecast what kinds of standard will be needed in the future.

DMP approaches the problem of DRM Interoperability by specifying technologies – that DMP calls Tools – required to implement what DMP calls “Primitive Functions”. These are “smaller” functions obtained when the functions value-chain users perform when they do business between themselves are broken down into more atomic elements. It is expected that, while functions may undergo substantial changes as a consequence of the evolution of the media business in the value-chain, Primitive Functions will generally remain more stable.

Therefore DMP is not developing a universal “DRM standard” capable of providing interoperability between every variety of different Users in arbitrary Value-Chains or across different Value-Chains. DMP provides specifications of Tools enabling Primitive Functions along with examples of how Value-Chains serving specific goals can be set up using the standard Tools. DMP specifications are developed in phases, so as to achieve gradual development of standards technologies.

The DMP approach to DRM standardisation is based on the following process

1.                    For each phase Use Cases deemed to be significant are identified and documented;

2.                    Primitive Functions required to implement the selected Use Cases are singled out;

3.                    Requirements for Primitive Functions are developed through inputs from relevant Users;

4.                    Tools serving the needs represented by the Use Cases are standardised;

5.                    Calls for Proposals for Tools with the identified requirements are issued;

6.                    The Tools are selected and documented through an open process. DMP favours Tools that have already been developed, standardised or adopted by other bodies, possibly adapting them to DMP needs;

7.                    Specifications of how Tools can be assembled to implement the selected Use Cases are developed;

8.                    In subsequent phases, Calls for Proposals for additional Tools needed to support new Primitive Functions or additional functionalities of existing Tools are issued.

DMP calls the ensemble of all standardised DRM Tools “Interoperable DRM Platform (IDP)”. The IDP provides several major advantages:

1.                    The specifications are industry agnostic, i.e. Users are free to build a great variety of Value-Chains that suit their business models by combining the Tools appropriate for them;

2.                    The capabilities of a Value-Chain or new Value-Chains can be extended by adding more Tools, possibly through additional standardisation;

3.                    The cost to access standardised Tools may be reduce because in general Tools have multiple usages and may be provided by multiple suppliers;

4.                    Full interoperability can be achieved within a Value-Chain;

5.                    An enhanced degree of interoperability can be achieved between different Value-Chains;

6.                    Innovation can be continuously fed in the system.

DRM requires more than technology

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

DMP is not claiming that an established TRU necessarily implies a right of a User to a particular Use of digital media but simply that, if Users have found a particular Use advantageous in the analogue domain, they are probably interested in continuing to exercise that Use in the digital domain as well. Leveraging upon this interest may provide multiple opportunities for new “Digital Media Business Models” that are attractive to Users but respectful of Rights Holders.

Therefore DMP intends to add technologies to its specifications to make the exercise of a broad range of TRUs technically possible. However, even a summary analysis shows that many TRUs have a legislative/regulatory impact that needs to be addressed by proper authorities. This can only be done within individual jurisdictions by determining which TRUs shall be mandated in Interoperable DRM Platforms operating under their jurisdiction and which TRUs can be left to private deals between Users. This is a challenging task because it requires blending knowledge encompassing the legal, social and economic fields with in-depth knowledge of the highly sophisticated and unusual DRM technologies.

The suite of DMP Approved Documents

DMP has produced the following ADs:

1.        Chapter 1 – Value Chain Functions and Requirements [1]: a collection of Primitive Functions derived from today’s media value-chains with corresponding Requirements.

2.        Chapter 2 - Architecture [2]: 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.

3.        Chapter 3 – Interoperable DRM Platform [3]: a collection of technical specifications of basic Tools that are needed to implement Primitive Functions.

4.        Chapter 4 – Use Cases and Value Chains [4]: 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.

5.        Chapter 5 – Certification and Registration Authorities [5]: 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.

6.        Chapter 6 – Terminology [6]: a set of terms and corresponding definitions that are used throughout DMP ADs providedto overcome the problem of DRM being a new field that impacts many existing fields with their own established and sometimes conflicting terminologies.

In addition DMP is currently developing the following ADs:

7.        Chapter 7 – Reference Software [7]: a software implementation of IDP Tools. DMP strives to provide the reference software as Open Source, with a license aligned to established practices. When this is not possible DMP provides the reference software with a “modify, use and distribute” license.

8.        Chapter 8 – End-to-End Conformance [8]: a set of Recommended Practices that Value-Chain Users can reference to ascertain that the Tools employed by other parties conform to DMP Technical Specifications and Technical References.

9.        Chapter 9 – Mapping of Traditional Rights and Usages to the Digital Space [9]: a set of example support of TRUs using DMP Tools possibly complemented by recommendations to appropriate authorities to enable the benefit of TRUs in a DMP-enabled world of digital media.

1          Value Chain Functions and Requirements

1.1        Introduction

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

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

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

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

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

2.        Derive Functions from the stated needs

3.        Develop requirements for implementing Functions

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

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

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

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

1.        Civil Rights Associations

2.        Association of People with Special Needs

3.        Collective Management Societies

4.        Device Manufacturers

5.        Individuals

6.        Producers

7.        Public Service Broadcasters

8.        Sheet Music Publishers

9.        Telecommunication operators.

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

This Chapter 1 contains

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

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

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

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

1.2        Value-Chain Users

1.3        General requirements

1.4        Primitive Functions

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

Table 1 – Primitive Functions

1.5        Functional requirements

1.5.1           Represent

1.5.1.1           Represent Identifier of Content

1.5.1.2           Represent Identifier of Device

1.5.1.3           Represent Identifier of User

1.5.1.4           Represent Identifier of Domain

1.5.1.5           Represent Identifier of DRM Tool

1.5.1.6           Represent Identifier of Footprint

1.5.1.7           Represent Identifier of Class of Users

1.5.1.8           Represent Identifier of Territory

1.5.1.9           Represent Identifier of Jurisdiction

1.5.1.10       Represent Content

1.5.1.11       Represent Resource

1.5.1.12       Represent Metadata

1.5.1.13       Represent DRM Information

1.5.1.14       Represent DRM Tool Body

1.5.1.15       Represent DRM Tool

1.5.1.16       Represent Rights Expression

1.5.1.17       Represent Rights Data

1.5.1.18       Represent Key

1.5.1.19       Represent Device Information

1.5.1.20       Represent Domain Information

1.5.1.21       Represent Use Data

1.5.1.22       Represent Resource Format

1.5.1.23       Represent Binarised XML

1.5.2           Assign

1.5.2.1           Assign Identifier

1.5.2.2           Assign Metadata

1.5.3           Revoke

1.5.3.1           Revoke Content

1.5.3.2           Revoke Content Element

1.5.3.3           Revoke Device

1.5.3.4           Revoke Domain

1.5.3.5           Revoke User

1.5.4           Authenticate

1.5.4.1           Authenticate Content

1.5.4.2           Authenticate Device

1.5.4.3           Authenticate DRM Tool

1.5.4.4           Authenticate User

1.5.5           Verify

1.5.5.1           Verify Content

1.5.5.2           Verify Device

1.5.6           Deliver

1.5.6.1           Render

1.5.6.2           Store

1.5.6.3           Copy

1.5.6.4           Move

1.5.6.5           Backup

1.5.6.6           Export

1.5.6.7           Access

1.5.6.8           Restore

1.5.6.9           Import

1.5.6.10       Update

1.5.7           Manage

1.5.7.1           Manage Domain

1.5.7.2           Manage DRM Tool

1.5.7.3           Manage Use Data Confidentiality

1.5.8           Package

1.5.8.1           Package as File

1.5.8.2           Package as Broadcast

1.5.8.3           Package as Streaming

1.5.9           Process

1.5.9.1           Encrypt/Decrypt

1.5.10       Pay

1.5.11       Test Conformance

1.5.11.1       Test Conformance of Rights Expressions

1.5.11.2       Test Conformance of Enforcing Rights Expressions

1.5.11.3       Test Conformance of Tamper resistance

1.5.12       Certify

1.5.12.1       Certify Content

1.5.12.2       Certify Device

1.5.12.3       Certify User

(Currently outside of DMP)

2          Architecture

2.1        Introduction

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

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

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

Please note the following general remarks:

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

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

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

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

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

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

This Chapter 2 provides:

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

2.        A series of models:

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

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

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

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

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

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

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

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

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

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

2.2        An End-to-End Value-Chain

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

1.        Creation (including Adaptation)

2.        Instantiation

3.        Production

4.        Content Provisioning

5.        Service Provisioning

6.        Consumption

Figure  1 – Value Chain

Note that dotted arrows mean that the output of a User can be Used by the same type of User to make Resources Representing the same type of IP Entity.

2.2.1           A walkthrough

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

For proper management in a Value-Chain it is useful to combine different types of Resources with different types of Metadata and possibly other information types. DMP calls this combination Content. For the purpose of Using Content on Devices, Content has to be digitally Represented. DMP calls such digitally Represented Content, DMP Content Information (DCI).

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

1.        A Device

2.        A User

3.        A Domain.

A User who does not wish to express Conditions to Use a Content Item can do so by Releasing it without a License.

4.        To enable a Device to interpret Permissions without human intervention, DMP uses a machine readable language called Rights Expressions Language (REL).

To support different business models Chapter 3 allows a License to be:

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

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

Chapter 3 allows other Content Elements in the DCI (e.g. Resources) to be in-line or referenced.

The Content Elements in Governed Content can either be in a form that allows immediate Processing, e.g. for Rendering by a Device (so-called Clear-text) or in a protected (i.e. Encrypted) form. To this end Chapter 3 provides various means to convey Keys and related DRM information.

Chapter 3 provides a basic selection of Encryption Tools that can be employed in restricted-capability Devices such as Portable Audio and Video (PAV) Devices (i.e. Devices without direct access to network). However, to support a broader range of applications such as those enabled by Stationary Audio and Video (SAV) Devices (i.e. Devices with network or broadcast access), Chapter 3 also provides the means to Represent in a DCI blocks of executable code (called DRM Tools or DRM Tool Packs) that are required to Process various types of Governed Content.

XML is the technology selected by DMP to Represent Content. XML is very powerful and flexible but Content Represented by means of XML can easily become bulky and unwieldy. Therefore DMP has selected an XML binarisation technology that not only reduces the size of a DCI but also allows simpler Processing in a Device without loss of information.

To Deliver Content between Device Entities it is necessary to Package a DCI (in binary form) and its referenced Resources. Chapter 3 supports 2 forms of Delivery:

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

2.        As Stream. This is called DMP Content Broadcast (DCB) in the case of an MPEG-2 Transport Stream, and DMP Content Streaming (DCS), in the case of Real Time Protocol on Internet Protocol.

2.2.2           Setting up Value-Chains

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

Chapter 5 specifies how this task is performed by a number of organisations (Certification Agencies) that are properly appointed and overseen by a single root authority (Certification Authority). DMP appoints the Certification Authority after approving the Authority’s Certification policies. The figure below depicts this three-layer arrangement.

Figure  2 – Authorities appoint Agencies that Certify Entities

In general interacting Devices require the establishment of a Trust relationship between them, e.g. when they Deliver Content between them. A precondition for this to be possible is that a Device be Identified. The task of Assigning Identifiers to Devices is performed by special Devices called Device Identification Devices. Chapter 5 specifies how this task is performed by a number of organisations (Registration Agencies) that are appointed and overseen by a single root authority (Registration Authority). DMP appoints the Registration Authority after approving the Authority’s Registration policies. The same three-layer arrangement used for Certification is also used for Identification.

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

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

In summary:

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

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

b.       DRM Tools.

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

a.        Content – License and DRM Tool

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

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

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

2.2.3           Navigating the Value-Chain

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

Figure  3 – Devices in a Value-Chain

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

1.        Content Creation Device obtains Identifier from Identification Devices for

a.        Resources (this is outside of DMP)

b.       License

c.        DRM Tool

d.       Content

2.        Content Creation Device makes Content by combining:

a.        Resources

b.       License

c.        DRM Tool

d.       Identifiers

3.        Content is Delivered to Content Provider Device

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

a.        License is Delivered to License Provider Device

b.       DRM Tool is Delivered to DRM Tool Provider Device

5.        An End-User Device (SAV) Accesses

a.        Content from Content Provider Device

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

c.        DRM Tools from the DRM Tool Provider Device if

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

                            ii.        DRM Tools are not Bundled within the Content

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

a.        Packages Content as File (DCF)

b.       Adapts Resources creating DCI and DCF

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

7.        PXD performs the following

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

b.       If Content does not have a Bundled Licence

                             i.        Accesses Licence from Licence Provider Device

                            ii.        Makes DCI

                          iii.        Makes DCF

c.        Moves/Copy DCF to PAV

2.3        The DMP Models

2.3.1           Creation Model

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

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

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

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

Work

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

Adaptation

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

Manifestation

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

Instance

An Instance is an object or event which is an example of an Identified Manifestation, e.g. a unique performance of a specific Manifestation of a musical Work. Instances are not necessarily uniquely of a particular Manifestation of a Work. The IP associated with Instances is so inextricably depend­ent on both the Manifestation and the Work that it is of, that it is classified separately as “Neigh­bouring” or “Performing” Rights. An Instance when it is fixated to a physical support constitutes the first copy, also referred to as “master”, used to make further copies, e.g. for commercial purposes.

Expression

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

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

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

Table  1 – IP Objects and Rights

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

Table  2 – IP Entity Scope

The figure below illustrates the dependencies between IP Entities.

Figure  4 – IP Entity dependencies

2.3.2           Distribution Model

In the general DMP Distribution Model the following Users operate:

1.        Content Providers providing Content to End-Users and Service Providers;

2.        License Providers providing Licenses to End-Users and Service Providers;

3.        DRM Tool Providers providing DRM Tools to End-Users and Service Providers;

4.        Service Providers providing Services to End-Users.

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

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

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

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

Figure  5  – Conceptual diagram of DMP Distribution Model

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

2.3.3           Delivery Model

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

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

The Package Function includes

·         Insert DCI in the selected transport mechanism

·         Extract DCI from the selected transport mechanism

2.3.4           DRM Tool Model

The following figure describes the DRM Tool Model.

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

1.        Resources

2.        Metadata

3.        DRM Information

4.        DRM Tools or Tool Packs

5.        Licenses

6.        Keys.

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

Figure  6 – Handling of DRM Tools in a Device

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

1.        Embedded in the Device

2.        Stored after having been previously Accessed

3.        Bundled within the Content Item currently Accessed.

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

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

Figure  7 – Tool Pack Interoperability

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

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

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

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

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

1.        DRM Tool Provider

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

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

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

d.       Stores DRM Tool Pack in DRM Tool Provider Device

2.        User Requests Service

3.        Service Provider

a.        Authenticates User

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

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

5.        DRM Tool Provider Device Delivers Tool Pack

6.        DRM Processor

a.        Accesses Tool Pack Information

b.       Searches for requested DRM Tool Pack from Secure Storage

c.        Executes DRM Tool Agent

d.       Sends available Control Points to DRM Tool Agent

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

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

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

10.     DRM Processor

a.        Searches for missing DRM Tool in the Secure Storage

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

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

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

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

14.     DRM Processor starts Resource decoding

15.     DRM Tools perform DRM Functions on Resources

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

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

2.        DRM Processor

a.        Receives Update message

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

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

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

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

2.3.5           Device Model

IDP-2 requires the following Device types:

Table  3 – IDP-2 Device types

These are briefly described below

2.3.5.1           Device Identification Device

Chapter 3 supports two kinds of Device Identification:

1.        “Device info-based identification” in which a Device Identification Device generates the Device Identifier using some vendor specific information such as vendor ID, model ID or product serial number;

2.        “Certificate-based identification” in which a X.509 certificate [30], generated by a Device Identification Device, is utilised as Device Identifier.

2.3.5.2           Content Creation Device

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

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

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

3.        Encrypts Resources (optional)

4.        Fills the Metadata template for each Resource

5.        Obtains Metadata Identifiers (optional)

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

7.        Obtains a License Identifier from a License Identification Device

8.        Adds License or License information within the DCI

9.        Obtains Content Identifier from a Content Identification Device

10.     Creates a DCF

11.     Stores the DCF on a Content Provider Device.

2.3.5.3           Content Identification Device

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

2.3.5.4           License Identification Device

This is functionally equivalent to Content Identification Device.

2.3.5.5           DRM Tool Identification Device

This is functionally equivalent to Content Identification Device.

2.3.5.6           Content Provider Device

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

2.3.5.7           License Provider Device

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

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

2.3.5.8           DRM Tool Provider Device

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

2.3.5.9           PAV eXternal Device

PAV Devices do not have network or broadcast connections to Access Content or License. However, they can be connected to a PAV eXternal Device (PXD) or a SAV, that in turn is connected to a network or broadcast channel. The following figure depicts the relationship between the four relevant Devices.

Figure  10  – A PAV and its PXD

Two cases can be considered

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

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

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

2.3.5.10       Content Consumption Device (PAV)

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

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

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

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

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

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

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

1.        End-User activates GUI

2.        GUI

a.        Reads the files Stored in PAV

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

3.        End-User selects DCF

4.        PAV

a.        Parses DCF to obtain DCI

b.       Parse DCI to obtain

                                 i.            License

                                ii.            Metadata

                              iii.            Resource

c.        Parses License to obtain DRM Information

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

6.        User selects the Function

7.        PAV

a.        Decrypts Resource

b.       Decodes Resource

c.        Renders Resources.

2.3.5.11       Content Consumption Device (SAV)

A conceptual model of a SAV is provided by the figure below

Figure  11 – Conceptual model of a SAV

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

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

1.        Decrypt Resources

2.        Decode (decompress) Resources

3.        Deliver decompressed Resources for Rendering

4.        Create DCF with Bundled License

5.        Store DCF

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

7.        Adapt Content

8.        Encrypt Resources.

2.3.5.12       Domain Identification Device

See Domain Model below.

2.3.5.13       Domain Management Device

See Domain Model below.

2.3.6           Domain Model

Domains are groups of Devices or Users sharing some common properties. Using Domains it becomes possible to implement more flexible Licensing modalities, e.g. to License a Content Item to all Devices or Users in a Domain. A Domain is managed by a special Device called Domain Management Device.

Figure  12 – An example of Domain

The figure above represents a possible Domain configuration with:

1.        Two Devices (SAV), belonging to two different End-Users;

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

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

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

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

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

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

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

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

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

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

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

2.        DMD

a.        Creates Domain

b.       Obtains Domain ID from Domain Identification Device;

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

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

e.        Delivers AccessID and AccessPassword to Domain Administrator;

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

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

4.        License Provider Device sends Domain ID to DMD;

5.        DMD Delivers Domain Public Key to LPD;

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

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

2.3.7           Import/Export Model

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

In this case a Device performs the following steps:

1.        accesses content

2.        translates license into a License

3.        makes DCF using the received Resources, Metadata and the License just made

4.        Stores DCF.

Chapter 3 specifies the Tools to convert a license expressed using RMPI to a License.

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

2.3.8           Data Model

Chapter 3 specifies the Representation of the following data types:

Table  4 – IDP-2 Data types

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

Table  5 – IDP-2 Content Elements