The Digital Media Project
INTEROPERABLE
DIGITAL RIGHTS MANAGEMENT
PLATFORM
Technical Specification, Phase II
9 February 2006
NOTICE
Use of the technologies described in this DMP Approved Document may infringe patents, copyrights or intellectual property rights of DMP Members or non-members. Under no circumstance shall DMP be held responsible for identifying any or all such rights.
Neither DMP nor any of its Members accept any responsibility whatsoever arising out of or in connection with the use of this DMP Approved Document and the information contained herein for damages or liability, direct or consequential.
This DMP Approved Document supersedes all previous versions and is subject to change without notice.
DMP is a non profit organisation registered in accordance to the laws of Switzerland.
Copyright © 2006 – 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 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 connected to business practices. As the introduction of digital technologies is currently forcing changes 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.
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.
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.
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).
|
# |
Value-Chain User |
Acr. |
Definition |
|
1. |
Creator |
CRE |
A User who creates a Work and generates its first Manifestation |
|
2. |
Performer |
PRF |
A User who interprets a Manifestation of a Work making an Instance |
|
3. |
Registration Authority |
RAU |
A User managing Identifier name spaces, and appointing and overseeing Registration Agencies |
|
4. |
Registration Agency |
RAG |
A User appointed by a Registration Authority to Assign Identifiers |
|
5. |
Collective Management Society |
CMS |
A User who provides collective representation to its members, e.g. Authors, Performers, Publishers etc. |
|
6. |
Producer |
PRD |
A User who produces Content |
|
7. |
Publisher |
PBL |
A User who selects Content and makes it available to other Users |
|
8. |
Syndicator |
SND |
A User who manages and places Content to Retailers using a variety of purchasing options |
|
9. |
Metadata Resolution provider |
MRP |
A User who resolves, i.e. maps between disparate sets of Metadata |
|
10. |
Repository |
RPS |
A User who offers Services to long-term Store, Identify, describe, locate, Access, manage, and Validate Content and its Metadata |
|
11. |
Monitoring Service provider |
MNP |
A User who processes Use Data to provide information |
|
12. |
Marketer |
MKT |
A User who provides promotional, sale enhancement, brand enhancement and merchandising Services |
|
13. |
Aggregator |
AGG |
A User who provides procuring, packaging, presenting, cataloguing, archiving and indexing Services typically to Retailers |
|
14. |
Retailer |
RTL |
A User who sells or Licenses Content to an End-user |
|
15. |
Technology provider |
TCP |
A User who provides technology to make Devices |
|
16. |
Technology licensing provider |
TLP |
A User who provides Device Manufacturers with a license to utilise patented technology to make Devices |
|
17. |
Device Manufacturer |
DVM |
A User who manufactures or assembles hardware and/or software components to make Devices |
|
18. |
Connectivity provider |
CNP |
A User who provides point-to-point or point-to-multipoint connectivity between Users |
|
19. |
Network Service provider |
NTP |
A User who provides Internet Protocol (or equivalent) services and typically various other services above it, e.g. quality of service |
|
20. |
Tool provider |
TOP |
A User who sells or Licenses Tools to Users |
|
21. |
Certificate Authority |
CRA |
A User who issues digital Certificates used to create digital Signatures and public-private Keys |
|
22. |
Certification Authority |
CAU |
A User appointing and overseeing Certification Agencies |
|
23. |
Certification Agency |
CAG |
A User appointed by a Certification Authority to Certify Devices or DRM Tools |
|
24. |
Clearing House |
CLH |
A User who collects Value Expressions from other Users to distribute to Right Holders for the purchase of Use Rights over a given instance of Content |
|
25. |
Payment Service provider |
PSP |
A User who provides the infrastructure for financial transactions |
|
26. |
End-User |
ENU |
The last User in a Value-Chain |
|
27. |
Reseller |
RSL | A User who possesses the Right to control the disposition and transfer of Content from End-users to different End-users |
|
28. |
Public Authority |
PBA |
A User who provides rules relating to the Use of Content and taxation on transactions related to Content. |
|
1. |
The IDP shall be a “tool-kit” specification |
|
2. |
The IDP shall evolve in phases, each phase introducing new Tools keeping compatibility with the Tools of preceding phases |
|
3. |
The IDP shall be open to support all legitimate needs by · Value-Chain Users · Associations of People with Special Needs |
|
4. |
The IDP shall support Rights inheritance, i.e. that the set of Rights acquired by a given Value-Chain User is subject to the set of Rights that was available to the Value-Chain User granting the Rights |
|
5. |
The IDP shall support the ability of a given Value-Chain User to mask the Value-Chain Users supplying Services to it in support of the Services that it provides to its clients |
|
6. |
Licensing of technologies required to implement IDP tools shall be RAND and preferably royalty-free |
|
7. |
The IDP shall be designed in such a way that its use shall have a minimal impact on Users, ideally that its use should be transparent |
|
8. |
The IDP Tools must satisfy the relevant requirements expressed in this document |
|
9. |
All Entities must be capable of being uniquely and unambiguously Identified |
|
10. |
Information about Devices and Domains shall be restricted to the minimum required for these to operate in the DMP Environment |
The following table provides the current list of Primitive Functions grouped in categories. For each Primitive Function a cross in any of the last two right columns indicates whether or not it is currently specified and if so in which version of the Interoperable DRM Platform (AD #3). An X in both columns means that technology is provided by IDP-2 that adds to the technology already provided by IDP-1.
Table 1 – Primitive Functions
|
Category |
Primitive Function |
IDP#1 |
IDP#2 |
|
Represent |
|
|
|
|
|
Represent Identifier of Content |
X |
|
|
|
Represent Identifier of Device |
X |
|
|
|
Represent Identifier of User |
|
X |
|
|
Represent Identifier of Domain |
X |
|
|
|
Represent Identifier of DRM Tool |
|
X |
|
|
Represent Identifier of Footprint |
|
|
|
|
Represent Identifier of Class of Users |
|
|
|
|
Represent Identifier of Territory |
|
|
|
|
Represent Identifier of Jurisdiction |
|
|
|
|
Represent Content |
X |
X |
|
|
Represent Resource |
|
X |
|
|
Represent Metadata |
|
X |
|
|
Represent DRM information |
|
X |
|
|
Represent DRM Tool Body |
|
X |
|
|
Represent DRM Tool |
|
X |
|
|
Represent Rights Expression |
X |
X |
|
|
Represent Rights Data |
|
|
|
|
Represent Key Body |
|
X |
|
|
Represent Key |
X |
X |
|
|
Represent Device Information |
|
X |
|
|
Represent Domain Information |
|
X |
|
|
Represent Use Data |
X |
|
|
|
Represent Resource Format |
|
|
|
|
Represent Binarised XML |
|
|
|
Assign |
|
|
|
|
|
Assign Identifier |
|
|
|
|
Assign Metadata |
|
|
|
Revoke |
|
|
|
|
|
Revoke Content |
|
|
|
|
Revoke Content Element |
|
|
|
|
Revoke Device |
|
|
|
|
Revoke Domain |
|
|
|
|
Revoke User |
|
|
|
Authenticate |
|
|
|
|
|
Authenticate Content |
|
|
|
|
Authenticate Device |
X |
|
|
|
Authenticate DRM Tool |
|
X |
|
|
Authenticate User |
|
|
|
Verify |
|
|
|
|
|
Verify Content |
|
|
|
|
Verify Device |
|
|
|
Deliver |
|
|
|
|
|
Store |
|
|
|
|
Copy |
|
|
|
|
Move |
|
|
|
|
Backup |
|
|
|
|
Export |
|
|
|
|
Access |
X |
X |
|
|
Restore |
|
|
|
|
Import |
|
|
|
|
Update |
|
|
|
Manage |
|
|
|
|
|
Manage Domain |
X |
X |
|
|
Manage DRM Tool |
|
X |
|
|
Manage Use Data Confidentiality |
|
|
|
Package |
|
|
|
|
|
Package as File |
X |
|
|
|
Package as Broadcast |
|
X |
|
|
Package as Streaming |
|
X |
|
Process |
|
|
|
|
|
Encrypt/Decrypt |
X |
|
|
Pay |
|
|
|
|
Test Conformance |
|
|
|
|
|
Test Conformance of Rights Expressions |
|
|
|
|
Test Conformance of Enforcing Rights Expressions |
|
|
|
|
Test Conformance of Tamper resistance |
|
|
|
Certify |
|
|
|
|
|
Certify Content |
|
|
|
|
Certify Device |
|
|
|
|
Certify User |
|
|
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of Content so that it can be Processed by a Device |
|
Objective |
To enable accurate Governance of a Content Item |
|
Requirements |
1. Ability to provide unique and unambiguous identification of a Content Item 2. Ability to support versioning 3. Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete 4. Ability to Identify Content by different Users to enable tracing the origin of Content when Licensed to other Users 5. Ability to Identify a Content Item for Use only within a specific Device or a Domain (e.g. a Broadcast Footprint, a company, a home) |
|
Benefits |
1. Flexible distribution schemes where different Content Elements may be supplied by different Providers 2. A given Content Element may be referenced in multiple parts of a Content Item 3. Multiple Content Items can refer to the same Content Element 4. Fine granularity of Rights Expressions. |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a Device employed in a particular instance of Use so that it can be Processed by a Device |
|
Objective |
To enable various Device-related Functions such as · To support the association of a piece of Governed Content with a Device · To support Trust management |
|
Requirements |
· Ability to work in conjunction with existing industry schemes to administer customer/device-specific uses · Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete · Ability to obtain Device capability information by reading the Device Identifier · Ability to support requirements for Domain Management |
|
Benefits |
· Allows reliable administration of Device-based Uses · Compatible with replacement strategies in cases where a Device is destroyed or otherwise replaced, or else used only for a period of time after which a different Device will be used. |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a User in a particular instance of Use so that it can be Processed by a Device |
|
Objective |
To enable various User-related Functions such as License Content to an Identified User |
|
Requirements |
· Ability to support User Authentication · Ability to support Identification of any Value-Chain User · Ability to accommodate a variety of models for human interaction with Devices e.g.: o Allow a single User to use multiple Devices, o Allow multiple Users to share a single Device, o Allow the use of a confidential identity (e.g. prepaid card) · Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete · Ability to access information related to the User that may be legally required for the provision of Content |
|
Benefits |
Depending on a given device's design, allows one User to employ multiple devices or allows multiple Users to use a single device |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of Domain so that it can be Processed by a Device |
|
Objective |
To enable Value-Chain Users to License Content to Identified groupings of Users and/or Devices |
|
Requirements |
· Ability to support the following types of Domains o Device-based o User-based o Location-based (e.g. DHCP) o Mixed Device, User and Location-based o Context-based § By reference to a legally established class of special users (e.g. students, people with special needs) · Ability to support a hierarchy of Domains |
|
Benefits |
Enable more Uses of Content by Identifying groupings of Users and/or Devices instead of just individual Users or Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of executable code or hardware device that implements one or more DRM Functions on a Device so that it can be Processed by a Device |
|
Objective |
To facilitate Authentication of DRM Tools |
|
Requirements |
Ability to Identify individual DRM Tools Ability to Identify groups of DRM Tools as an Entity (Tool Group) Ability to Identify complete DRM Systems (Tool Packs) |
|
Benefits |
· To obtain and classify DRM Tools · To Authenticate DRM Tools |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a primary broadcast distribution area so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular Footprint |
|
Requirements |
Unique and unambiguous identification of a particular Footprint |
|
Benefits |
Enable Usage of Content within a particular Footprint |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a particular class of Users so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular class of Users |
|
Requirements |
Unique and unambiguous identification of a particular class of Users |
|
Benefits |
Enable Usage of Content within a particular class of Users |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a particular geographical area so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular Territory |
|
Requirements |
Unique and unambiguous identification of a particular Territory |
|
Benefits |
Enable Usage of Content within a particular Territory |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a particular Jurisdiction so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular Jurisdiction |
|
Requirements |
Unique and unambiguous identification of a particular Jurisdiction |
|
Benefits |
Enable Usage of Content within a particular Jurisdiction |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the organisation and association of Content and Content Elements so that it can be Processed by a Device |
|
Objective |
To enable a predictable processing of Content and Content Elements according to the purposes of the Content Item design, i.e. to Represent the Governed Use of Work, Manifestation, Instance, Production, DRM Tool etc. |
|
Requirements |
· Ability to provide persistent association of Identifiers to Content and Content Elements · Ability to include Clear-text and Encrypted Identifiers, Content and Content Elements in a Content Item · Ability to apply Licenses to different Content Elements in a Content Item · Ability to Use individual Content Elements in a Content Item · Ability to associate to a Content Item Content Elements Stored at locations remote from each other · Ability to support temporary and permanent unavailability of Content Elements · Ability to Represent Content in a Delivery-System agnostic format · Ability to convey information related to § Key management § Encryption methods § Watermarking § Etc. |
|
Benefits |
· Standard format to securely communicate Resources and Governance information for Use · Multiple Uses of the same Resources (e.g. possibility to create multiple play lists) · Different Licenses for the same Content and/or Content Elements · Easy navigation · Easy repurposing |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the format of a Resource so that it can be Processed by a Device |
|
Objective |
To enable a Device to interpret the Representation so that the Resource can be Used |
|
Requirements |
· To be as simple as possible · To be as expressive as required |
|
Benefits |
Use of Resources by Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe features and attributes associated with Content and Content Elements or Devices so that it can be Processed by a Device |
|
Objective |
· Facilitate interaction between Users for a plurality of purposes, e.g. o Classification o Description o Search and retrieval o Presentation o Etc. · Enable best Use of Content on Devices |
|
Requirements |
· Ability to support existing Metadata standards · Ability to signal the standard in use · Ability to employ a minimal Metadata standard set for End Users · Ability to describe Device features and capabilities |
|
Benefits |
Allow for an effective interchange of Content between Users and optimal Use of Content and Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe Governance of Content so that it can be Processed by a Device |
|
Objective |
To enable a Device to interpret the information so that Content can be Used as determined by its Governance |
|
Requirements |
Ability to represent · DRM Tools required to Access Content · Initialisation and configuration data for DRM Tools · Decryption Keys · Information related to DRM Tool Management · Placeholders for Licenses |
|
Benefits |
Enable Content Governance by Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the specific information used to describe DRM Tool embodiments used so that they can be Processed by a Device |
|
Objective |
To enable a Device to execute DRM Functions specific of a given Content Item |
|
Requirements |
· Ability to Represent a single Tool Body · Ability to Represent a Tool Pack Body |
|
Benefits |
Extend the number and scope of DRM Functions that a Device can execute |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the specific information used to describe the environment in which DRM Tools will operate so that they can be Processed by a Device |
|
Objective |
To provide the Device with the means to perform the required DRM functionality |
|
Requirements |
The Representation shall include: · Tool ID · DRM Processor type, including o Vendor o Model o Serial number · Target OS including o Vendor o Model o Serial number o Version o Virtual machine · CPU o Vendor o Model o Speed · Memory o Vendor o Model o Speed o Size · Auxiliary hardware o Smart card o Hard Key · Network · Downloading · RPC mechanism · Firmware · Tool API configuration o Instantiation API ID o Messaging API ID · Target HW · Format e.g. zip · Tool source · Authentication parameters · Update schedule info · Tool Validation info · License info · Others |
|
Benefits |
Upgradeable Device capable of executing multiple DRM functionalities |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe Permissions and Conditions so that it can be Processed by a Device |
|
Objective |
To allow conditional Use of Content, based on the Conditions being satisfied or fulfilled |
|
Requirements |
· Ability to interpret a Rights Expression o Without a return channel o With low payload o On a wide array of Device sophistication · Ability to unambiguously Identify o The User granting the Permission o The Device, User or Domain obtaining the Permission o The Content and Content Elements to which the Rights Expression refers · Ability to utilise (Rights data dictionary) o A User selectable Rights data dictionary o A minimal default Rights data dictionary · Ability to Represent (Permission sets) o Different subsets of Permissions o New Permissions when the need occurs · Ability to Represent (specific Permissions to Content) o Conditional expiry (e.g. Content may no longer be Used if Stored for longer than a determined period without Use) o One Rights Expression to many Content Elements o Many Rights Expressions each referring to a different Content Element § In particular a Content Item can have no Rights Expression (i.e. a Device can Use the Content without limits) o Content Uses e.g. § Period of time (e.g. play as long as the play time is greater than specified time and less than a specified time) and based on time/date § Count based (play up to a specified number of times) § User based § Device based § Domain based § Location based o Rights Expressions with Context Use limitations, e.g. age of End-User · Ability to support Delivery by: o Streaming o Broadcast o File download o Physical media · Ability to support (Conditions) o Territories o Jurisdictions o Footprints o Domains o Devices o Users o IP Entities · Ability to support (Functions) o Not to Encrypt clear-text Resources o Quote o Time-shifted Use o Annotation o Trick modes o Move/Copy § Between Devices § Within Domain § Within Footprint o Export to a movable media · Ability to support (Content types) o Reference to different IP Entities o Addition of Metadata o Use of the following types of Resources: audio, video, images, text and executables and groups/bundles thereof o Access of Content based on Rating (e.g. suitability for age) o Rights to segments of Content o Many Rights Expressions each referring to particular Content Elements of a Content Item · Ability to support (Rights of Users) o Ability to represent the sets of Rights pertaining to all Users e.g. Authors, Performers, Producers, Aggregators, Distributors, etc. o The Right of a User to License another User o Restriction to a class of Users o Multiple Licensors · Ability to support dynamic creation of Rights Expressions as a result of interaction between Users |
|
Benefits |
Potentially allow the full range of human contractual agreements to be embodied in the digital domain, especially including automatic processing of agreements that are stated in rigorous forms |
|
|
Detailed description of Requirements |
|
Definition |
The semantics of the data used in Permission and Conditions so that they can be interpreted by a Device in a predictable way |
|
Objective |
To enable a device to perform the Functions in an agreed and predictable way |
|
Requirements |
· Provide the semantics for the following: o Adapt (Resource) § Conversion of compression method § Video resolution § Sampling frequency o Backup o Copy o Edit o Encrypt o Export o Import o Move o Quote o Restore o Space-shifted Use o Store o Synchronise o Time-shifted Use o Transfer to an external rendering device o Etc. |
|
Benefits |
· Users have assurance that Devices behave predictably. · Essential input for conformance testing. |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe Keys and associated parameters so that it can be Processed by a Device |
|
Objective |
To provide a Device with the necessary information to utilize a Key |
|
Requirements |
· Ability to represent o Time dependent/independent Keys o Association of Keys to particular time segment of a Resource o Key type and related data (e.g. Authentication, Certificates, etc.) o Set of Key types |
|
Benefits |
The ability to use multiple Keys and Key Management schemes |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the capabilities of a Device to perform Functions so that it can be Processed by a Device |
|
Objective |
To describe the capability of a Device |
|
Requirements |
· To identify Device capabilities, e.g. o Capability to Process (e.g. Render) certain Resource Types o Capability to determine the applicability of certain Rights Expressions o etc. |
|
Benefits |
The ability to Access Content that is suitable for the Device |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the attributes of a Domain so that it can be Processed by a Device |
|
Objective |
To describe the minimum set of attributes of a Domain that is required to License Content for that Domain |
|
Requirements |
· The Representation shall include o Information about when the Domain was created o Domain Identifier o Domain Public and Private Keys o Domain Administrator’s name and password o List of Devices/Users in the Domain o Maximum number of Devices/Users o List of Revoked Devices/Users o Expiration date of Domain · The Representation may optionally include o Type of Devices o Maximum frequency of Devices/Users leaving and joining |
|
Benefits |
· For the Content Provider the ability to determine proper Licensing of its Content · For the End-User the ability to obtain Content for Use within his Domain |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the elements making up one or more instance of Use of Content, Device or User so that it can be Processed by a Device |
|
Objective |
To enable processing of Use Data in a predictable fashion |
|
Requirements |
· Ability to Identify Use Data · Ability to support protection of Use Data · Ability to convert Use Data to a human readable form · Ability to not Identify User or Device associated with Use Data · Ability to Represent a wide range of Content Uses e.g. time of Use, combinations of Content Items, Domains, Superdistribution Uses |
|
Benefits |
Provide a machine-processable record of Uses |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the format of Resources so that it can be Processed by a Device |
|
Objective |
To provide the means to Access Content containing suitable Resources for the Device |
|
Requirements |
· The ability to express relevant parameters in a Resource format o Compression algorithm used o Video resolution o Bitrate used for encoding o Audio sampling frequency o Number of channels o Etc. |
|
Benefits |
To facilitate Access to Content To be able to Access Content that is suitable for the Device |
|
|
Detailed description of Requirements |
|
Definition |
The efficient Representation of XML data |
|
Objective |
To save memory, transmission and processing capabilities when handling XML documents |
|
Requirements |
· To reduce the amount of information required to express an XML structure to a minimum · To allow for a lossless conversion between an XML structure its binary representation and the reconverted XML structure · To make processing of a binarised XML structure at least as easy to process as the original XML structure |
|
Benefits |
Better use of computing and transmission resources |
|
|
Detailed description of Requirements |
|
Definition |
The Function performed by a User when Assigning an Identifier to Identifiable Entities, e.g. Content, Content Elements (License and DRM Tool), Device, Domain and User |
|
Objective |
To associate data, e.g. a number, to Entities in a unique and unambiguous fashion |
|
Requirements |
To Assign Identifiers according to the rules laid down by the Registration Authority as implemented by the Registration Agency so that there exists a unique, unambiguous, persistent and trusted correspondence between the Identifier and the Entity it Identifies |
|
Benefits |
Form trusted relationships (i.e. Authenticate) by providing Users with the ability to Identify Entities such as Content, Content Elements (License and DRM Tool), Device, Domain or User. |
|
|
Detailed description of Requirements |
|
Definition |
The Function performed by a User when describing Entities within a DCI |
|
Objective |
To facilitate search for and Use of Content Entities |
|
Requirements |
· Ability to support the need of different Users to Assign Metadata that have mandatory descriptive fields, e.g.: o Author o Title o Genre of Authorship o Date of Creation of Work o … · Ability to facilitate cataloguing of Content for distribution to professional Users |
|
Benefits |
Secondary means to identify Entities |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a Content Item |
|
Objective |
To prevent the further Use of a Content Item |
|
Requirements |
· Content must be Identified |
|
Benefits |
To discontinue Use of a Content Item, e.g. when the Content Item has been found unsuitable for distribution |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a Content Element |
|
Objective |
To prevent the further Use of a Content Element |
|
Requirements |
· Content Element must be Identified |
|
Benefits |
To discontinue Use of a Content Element, e.g. when the Content Element is faulty |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a device as a Device |
|
Objective |
To prevent the further Use of the Device |
|
Requirements |
· Device must be Identified |
|
Benefits |
To discontinue Use of a Device, e.g. when the Device has been compromised |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Domain Manager ceases to recognise a Domain |
|
Objective |
To prevent the further operation of the Domain |
|
Requirements |
· Domain must be Identified · Devices or Users belonging to the Domain must be Identified |
|
Benefits |
To discontinue operation of a Domain, e.g. the Devices have been compromised |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a device as a User |
|
Objective |
To prevent the further Use of Devices or Content by a User |
|
Requirements |
· User must be Identified |
|
Benefits |
To discontinue Use of Devices by a User, e.g. when the device representing the User has been compromised |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a Content Item to a Device |
|
Objective |
To make sure that a Device Accesses the intended Content Item |
|
Requirements |
· Content must be Identified · Content must be Signed or Hashed |
|
Benefits |
To enable a Device to Use the intended Content |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a Device to another Device a User or Domain. E.g. · A LPD Authenticates a DMD |
|
Objective |
To make sure that Content is Used by the intended Device |
|
Requirements |
· Device must be Identified · Ability to support different levels of Authentication |
|
Benefits |
To enable Content Uses on identified Devices |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a DRM Tool to a Device |
|
Objective |
To make sure that the Content is processed by the intended DRM Tool |
|
Requirements |
· DRM Tool must be Identified |
|
Benefits |
Correct handling of Content Management and Protection |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a User to a Device another User or Domain |
|
Objective |
To make sure that the User is the intended User |
|
Requirements |
· Shall support multiple protocols for the authentication of Users · Outside of DMP scope |
|
Benefits |
To enable Content Uses by identified Users |
|
|
Detailed description of Requirements |
|
Definition |
The procedure to detect corruption or loss of part of the Content |
|
Objective |
Delivery of the correct Content |
|
Requirements |
· Ability to detect that there is corruption or loss of part of the Content |
|
Benefits |
To assure Content Integrity and support Trust Management in the case of DRM Tools |
|
|
Detailed description of Requirements |
|
Definition |
The procedure to detect corruption of part of the software of a Device |
|
Objective |
To support Trust Management with a Device that may be remote from a User |
|
Requirements |
· Ability to detect whether there is corruption of the Device software |
|
Benefits |
The ability to support Trust Management with a Device that may be remote from a User |
|
|
Detailed description of Requirements |
|
Definition |
The Function of generating a human-perceivable signal from a Resource |
|
Objective |
To enable human perception of Content |
|
Requirements |
· A protocol to Deliver Content to a Device for Rendering |
|
Benefits |
To allow the Delivery of a Resource to the intended Rendering Device for human enjoyment in a way that was intended by the Rights Holder |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A Delivers Content to Device B for the purpose of retaining it in Device B for possible Use at a different point in time |
|
Objective |
Allow a Device to retain Content and/or Resources for future Use |
|
Requirements |
· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices |
|
Benefits |
The User can Use a Content for a longer period of time as per License |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A Stores Content in Device B, preserving the original Content in Device A |
|
Objective |
· To enable more use of the same Content Item · To Copy or Move as per Rights Expressions. · To accomplish the transfer of a piece of Governed Content between Devices |
|
Requirements |
· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices |
|
Benefits |
Allow controlled Copy of Content |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A Stores Content in Device B deleting the original Content in Device A |
|
Objective |
· To enable more use of the same Content Item · To Move as per Rights Expressions. · To accomplish the transfer of a piece of Governed Content between Devices |
|
Requirements |
· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices |
|
Benefits |
Allow controlled Move of Content |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device can Copy a Content Item (in case the Rights Expression is a Stateless Rights Expression) to and from a Device where the Content Item is not for Use, e.g. for the purpose of later Restoring the Content Item. |
|
Objective |
To be able to backup/restore Content to and from an external device |
|
Requirements |
Backup requires that the Backup does not result in a second usable copy. |
|
Benefits |
· To be able to make room for Governed Content in a Device without losing permanently the Governed Content that is removed from the Device. · Not to lose the Content in case of Device failure. |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device makes available a Content Item for use by a non-DMP DRM system. |
|
Objective |
To enable use of a Content Item outside of an Environment. |
|
Requirements |
· A protocol to communicate with a non-DMP DRM system. This includes, as a minimum, a means to identify non-DMP DRM systems · In the event the other DRM system is not capable of accepting the encryption used the protocol should be capable of Decrypting and Exporting cleartext Resources, Metadata and Licenses so that it may be re-encrypted as required by the target DRM system. · A Secure Authenticated Channel (SAC) |
|
Benefits |
A Rights Holder has the ability to extend the range of use of their Content to other governed environments. |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A obtains Content from Device B so that Device A can execute Functions |
|
Objective |
To enable a Device to process Content |
|
Requirements |
· Access Content via file download, broadcast and streaming |
|
Benefits |
Access to Content via an array of delivery mechanisms |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device can Copy a Content Item (in case the Rights Expression is a Stateless Rights Expression) to and from a Device where the Content Item is not for Use, e.g. for the purpose of later Restoring the Content Item. |
|
Objective |
To be able to backup/restore Content to and from an external device |
|
Requirements |
Backup requires that the Backup does not result in a second usable copy. |
|
Benefits |
· To be able to make room for Governed Content in a Device without losing permanently the Governed Content that is removed from the Device. · Not to lose the Content in case of Device failure. |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device accesses a piece of content governed by a non-DMP DRM system. |
|
Objective |
To enable Use of a piece of governed content by a Device. |
|
Requirements |
· A protocol to communicate with a non-DMP DRM system. This includes, as a minimum, a means to identify non-DMP DRM systems · The protocol should be capable of obtaining Clear-text Resources, Metadata and Licenses so that these may be re-encrypted as required by the Environment. · A Secure Authenticated Channel (SAC) |
|
Benefits |
Enables Environments to be populated with governed content from sources outside of DMP. |
|
|
Detailed description of Requirements |
|
Definition |
The means by which a Content Item may replaced by a new Content Item |
|
Objective |
Allow for Content to be Governed dynamically |
|
Requirements |
· Associate Content with License · Associate Content with DRM Tool |
|
Benefits |
· Enhanced flexibility in implementing Content Delivery and Use |
|
|
Detailed description of Requirements |
|
Definition |
Procedures to manage a set of Devices such that only those Devices can Use the Content Licensed to the Domain |
|
Objective |
To enable groups of Devices and/or Users e.g. belonging to a family to Use the same Content on any of the Devices in the group |
|
Requirements |
· Users with an authorised entitlement (Administrator) shall be able to fully control Domain membership and Content distribution. · Setting up a Domain, including the ability to distribute Rights Expressions that can only be used by Devices in the Domain · Joining a Domain · Authorising entry to a Domain · Leaving a Domain · Directing to leave a Domain, including the ability to exclude a Device so that it cannot process Rights Expressions associated with the Domain after the time of exclusion · Users without an authorised entitlement shall not be able to obtain confidential information related to the Domain · A Domain shall be configurable to permit a variety of distribution options between Devices belonging to the Domain, e.g. superdistribution of Content to Devices belonging to a sub-Domain within the Domain (e.g., specialized interest groups). |
|
Benefits |
Enables content distribution to be both very wide and very specific, supporting many possible business models. |
|
|
Detailed description of Requirements |
|
Definition |
Procedures to manage the communication of DRM Tools between themselves and a DRM Processor (parties) to enable a Device to Process Governed Content |
|
Objective |
To enable Use of a local or external DRM Tool by a Device |
|
Requirements |
It shall be possible for a DRM Tool to require: · To be informed of all the other DRM Tools operating at any time · To be notified when a new DRM Tool is instantiated · To be informed that a particular event occurs · The instantiation of another DRM Tool · The termination of another DRM Tool · The communication of the results of a DRM Tool · The exchange of a License or any part of it between two parties · The exchange of a Decryption Key along with associated information (i.e. timing) about its use between two parties · The mutual authentication with a party · The display of information to a User and the request for a User input |
|
Benefits |
To allow enhanced flexibility in the adoption of DRM technologies in Content Delivery and Use |
|
|
Detailed description of Requirements |
|
Definition |
The means to allow User A to negotiate the way User B will utilise acquired User and Use Data of User A |
|
Objective |
To let two Users determine how the information acquired during their interaction can be further utilised |
|
Requirements |
· Mechanism for protection of Use Data · Ability to decide the utilisation of Use Data |
|
Benefits |
Allows User confidence that their privacy will be protected, simultaneously allowing Providers to gain knowledge from User and Use Data to the extent this is agreed. |
|
|
Detailed description of Requirements |
|
Definition |
The Function of processing Content for the purpose of delivering it between Devices as File |
|
Objective |
To ensure proper delivery of Content as File |
|
Requirements |
· Minimum overhead compared to Content · The Content should be efficiently retrievable |
|
Benefits |
Ability to Deliver Content between Devices |
|
|
Detailed description of Requirements |
|
Definition |
The Function of processing Content for the purpose of delivering it between Devices as Broadcast |
|
Objective |
To ensure proper delivery of Content as Broadcast |
|
Requirements |
· Minimum overhead compared to Content · The Content should be efficiently retrievable · Transport of Content should be efficient and timely (e.g. an End-User should not have to wait for a long time before Using Content) |
|
Benefits |
Ability to Deliver Content between Devices |
|
|
Detailed description of Requirements |
|
Definition |
The Function of processing Content for the purpose of delivering it between Devices as Stream |
|
Objective |
To ensure proper delivery of Content as Stream |
|
Requirements |
· Minimum overhead compared to Content · The Content should be efficiently retrievable · Transport of Content should be efficient and timely (e.g. an End-User should not have to wait for a long time before Using Content) |
|
Benefits |
Ability to Deliver Content between Devices |
|
|
Detailed description of Requirements |
|
Definition |
Methods used to hide portions or totality of Content Elements |
|
Objective |
To prevent a User from Using Content, Resources or Fragments of Resources |
|
Requirements |
· Suitably flexible for a wide variety of Content · Efficiently implementable on a wide range of Devices · Based on Encryption Algorithms that are: o publicly disclosed o subject to constant scrutiny and evaluation by the worldwide cryptographic community o supporting stream and bulk ciphers o considered as secure o in broad use · The appropriate consideration of export restrictions. · Encryption methods that allow decryption by Devices with different processing capabilities · Support o Facilitate efficient prefetch and decryption of child resources. o Efficient random access to content blocks for all linear content types |
|
Benefits |
To protect Content and Rights Expressions from being read by unintended Users |
|
|
Detailed description of Requirements |
|
Definition |
Providing Use, User, Device and Governed Content information to a payment system external to an Environment |
|
Objective |
To enable flexible payment systems such as subscription, pre-payment or transaction-based payment by a single Device, a Domain or a User. |
|
Requirements |
· The ability to support multiple payment methods and mechanisms |
|
Benefits |
Automated payment |
|
|
Detailed description of Requirements |
|
Definition |
Checking that a Rights Expression is interpreted and provides the output as intended by the originator of the Rights Expression |
|
Objective |
To test conformance of the engine interpreting the Rights Expressions |
|
Requirements |
Device conformance shall be assessed and regulated according to industrial compliance regime |
|
Benefits |
It is essential for a Rights Holder that a Device will correctly interpret Rights Expressions. |
|
|
Detailed description of Requirements |
|
Definition |
Checking that the Functions corresponding to the output are executed as intended |
|
Objective |
To test conformance of the engine executing the Rights Expressions |
|
Requirements |
Device conformance shall be assessed and regulated according to industrial compliance regime |
|
Benefits |
It is essential for a Rights Holder that a Device will correctly execute the interpreted Rights Expressions. |
|
|
Detailed description of Requirements |
|
Definition |
Defining the levels of tamper resistance and the methods to be used when an implementation is put under test for tamper resistance to determine such levels |
|
Objective |
To test the robustness of a Device to attacks |
|
Requirements |
|
|
Benefits |
It is essential for a Rights Holder that a Device is implemented in a way that makes it difficult for an attacker to tamper with it. |
|
|