DPRL Manual

The Digital Property Rights Language

Manual and Tutorial - XML Edition

Version 2.00 — November 13, 1998

LIMITED DISTRIBUTION - REVIEW PURPOSES ONLY

The material contained in this document is provided for review purposes only. Receipt of this document does not constitute a license, actual or implied, to any intellectual property contained herein. All material contained in this document is the intellectual property of the Xerox Corporation.

1. INTRODUCTION *

1.1 Enabling Commerce in Digital Property *

1.2 Scope of this Document *

1.3 Basics of Digital Property Rights *

1.4 Interfaces to Digital Property Rights Specifications *

1.4.1 Rights Editor Interfaces *

1.4.2 Trusted System Interfaces *

1.5 Design Goals for the Digital Property Rights Language *

2. LANGUAGE SPECIFICATIONS *

2.1 Specifying a Work *

2.2 Digital Property Rights *

2.2.1 Transport Rights *

2.2.2 Render Rights *

2.2.3 Derivative Work Rights *

2.2.4 File Management Rights *

2.2.5 Configuration Rights *

2.3 Specifying Times *

2.3.1 Specifying Moments in Time *

2.3.2 Specifying Units of Time *

2.3.3 Specifying When Rights Can Be Exercised *

2.4 Specifying Fees and Incentives *

2.4.1 Currencies and Accounts *

2.4.2 Digital Tickets *

2.4.3 Per Use and Metered Fees *

2.4.4 Best-Price Fees *

2.4.5 Markup Fees *

2.5. Specifying Access Controls *

2.5.1 Digital Licenses (Certificates) *

2.5.2 Security Classes *

2.6 Specifying Watermark Information *

2.6.1 Watermark Strings, Tokens, and Objects *

2.6.2 Examples of Watermark Specifications *

2.7 Bundle Secifications *

2.7.1 Specifying Time Limits Inside Bundles *

2.7.2 Specifying Fees Inside Bundles *

2.7.3 Specifying Access Inside Bundles *

2.7.4 Specifying Watermark Information Inside Bundles *

APPENDIX A. LEXICAL CONVENTIONS *

Keywords *

Constants *

Identifiers *

Currency Codes *

APPENDIX B. GRAMMAR FOR THE DIGITAL PROPERTY LANGUAGE *

APPENDIX C. QUESTIONS AND ANSWERS *

General Questions About Digital Property Rights *

Questions About Work Specifications *

Questions About Transport Rights *

Questions About Render Rights *

Questions About Derivative Work Rights *

Questions About File Management Rights *

Questions About Time Specifications *

Questions About Fee Specifications *

Questions About Security and Authorization *

INDEX *

1. INTRODUCTION

The Digital Property Rights Language Manual is a work in progress specifying a language for describing rights, conditions, and fees for using digital works. The Digital Property Rights Language (DPRL) is intended to support commerce in digital works, that is, publishing and selling electronic books, digital movies, digital music, interactive games, computer software and other creations distributed in digital form. It is also intended to support specification of access and use controls for secure digital documents in cases where financial exchange is not part of the terms of use.

This manual is being circulated for review among publishers, platform vendors, authors, librarians, and others interested in the issues involving rights and fees for digital works. Our purpose in circulating the manual is to solicit feedback and suggestions that can guide us in developing the language and establishing appropriate standards. The use of a standard language for usage rights on digital property ensures that trusted systems can exchange digital works and interoperate. The trusted systems are for authoring, playing, and selling digital works. They include personal systems, on-line storefront systems, library systems, and others.

The digital property rights language describes distinct categories of uses for digital works in terms of "rights," including rights to copy a digital work, or to print it out, or to loan it, or to use portions of it in derivative works. DPRL also describes conditions and fees (if any) relevant to such uses.

Before describing the language itself, this introduction first discusses the commercial context for DPRL. It discusses the intended audience for this manual and how usage rights would actually appear to creators, publishers, and consumers of digital works. Finally, it describes our design goals and assumptions for the language.

For variety in expression, we use the words digital property rights, digital rights, and usage rights synonymously. Similarly, we use the words digital property rights language, digital property language, digital rights language, and rights language synonymously. We also use the terms digital publications, digital documents, and digital works synonymously.

1.1 Enabling Commerce in Digital Property

Digital technology has shifted the balance of practice in the social contract between those who create and distribute works and those who use them. For many kinds of digital works, it is very easy to use and duplicate a work without having authorization or providing compensation. With electronic networks, it is easy to distribute unauthorized copies of a digital work to points around the world, without knowledge of the publisher or author.

For some publishers, the issue of unauthorized distribution represents too great a business risk and they do not publish in digital form. For others the revenue losses are affordable, but they lead to billing and distribution schemes that are cumbersome. For example, distributors of digital works typically bill all users the same amount regardless of the use to which the consumers will put the work. Some digital publishers rely on the honesty of users not to replicate a work or use it in unauthorized ways after an initial purchase. Ironically, some publishers figure that some "leakage" of works that need periodic upgrading (such as computer software) helps to increase their installed base. However, even for computer software, it is often reported that there are more unauthorized copies in use than authorized ones.

Consumers of digital works are also poorly served. It requires much more time, effort and money to be honest than to slip beyond the legal rights for use of a digital work. Consumers sometimes view the creators of a work as opponents, and try to "get away with" unpaid use because they have paid so much for other works. Given the lack of safeguards and reliable billing services, few publishers have been willing to distribute their works digitally over computer networks. Consequently, consumers miss out on the convenience of 24-hour software shopping and on-line delivery. Since there are no reliable and general means for determining how much software is used, users must usually pay the same for software regardless of how much use they make of it.

Various approaches have been proposed to create a commercially viable means of distribution. These approaches are based on concepts such as trusted systems, semi-trusted systems, digital envelopes, and secure containers. The most general approaches are based on two simple ideas: that digital works can be bought and sold among trusted systems and that works have attached usage rights that specify what can be done with them and what it costs to exercise the rights.

Different publishing and distribution systems require different kinds of subsystems and capabilities. The digital property language is primarily concerned with those systems that are directly involved in buying, selling, and using digital works. These systems would generally be implemented as trusted systems.

A trusted system is a system that can hold digital works and which can be trusted to honor the rights, conditions, and fees specified for a work. Trusted systems can take different forms, such as "trusted players" that play digital works, or "trusted readers" for reading digital works or "trusted servers" that may provide access to digital works on a network. Recognizing that different applications require different kinds of trusted systems and different levels of security, we use the terms trusted system and repository interchangeably to refer generically to systems relied on to keep documents secure and to honor usage rights.

Different implementations of trusted systems have different requirements for security and different approaches. In the most secure approaches, all of the hardware and software on the platform is certified to honor digital rights. Other approaches focus on the use of so-called secure envelopes or containers, emphasizing transmission and storage of information. All such approaches have some elements that are assumed to be trusted and which can be circumscribed by boundaries of trust. These boundaries may be the boundaries of program code assumed not to be altered, data files assumed not to be acessible, language interpreters (such as Java) assumed to follow certain rules, or physical hardware assumed not to be compromised. The security of a trusted system depends in large measure on its vulnerability across these boundaries. For the purposes of this document, we use the term "trusted system" in a generic sense to refer to all systems for security and commerce in digital works, regardless of the techniques used to create a basis for trust.

We use the term "semi-trusted system" to refer to a class of repositories that have two levels of storage - regular storage and trusted storage. Regular storage is file space accessible to untrusted programs. Generally, this is used to hold encrypted works. Trusted storage is special storage not readily accessible to untrusted programs. Trusted storage is for encryption keys, billing data, some non-transferable digital certificates, and digital tickets.

Beyond trusted systems are several other kinds of systems, made up of hardware, software, and communications elements. For example, trusted systems would confirm credit and exchange billing data with financial clearing houses. In contrast to "authoring systems," we use the term "digital publishing systems" to refer to systems that can import digital works in native formats, interact with a publisher or distributor to add usage right information, and export the digital works in encrypted forms or in digital containers. We use the term "network sales server" to refer to systems that offer documents for sale on-line, such as on the World Wide Web.

1.2 Scope of this Document

This document explains the basic concepts for managing digital works in trusted systems, describes the language syntax and semantics, and provides examples of typical specifications of usage rights. It does not provide specifications for security in trusted systems, propose specific applications, or describe the details of the accounting systems required.

One of the goals of our work in usage rights is to develop an approach and language that can be used throughout the publishing industries and in other industries as well. This paper does not address the agreements, coordination or institutional challenges involved in achieving that goal. See (Stefik, 1995) for a sketch of some of the institutional challenges.

1.3 Basics of Digital Property Rights

Digital property rights (or "usage rights" for short) are rights associated with digital works and their parts that describe how the works can be used. Here are some basic concepts:

• Rights are associated with parts of a digital work (and with folders).

• Every class of usage right has a corresponding transaction.

• The transaction defines what a repository does when the right is exercised.

• Rights are described in sentences of a machine-interpreted language having a grammar.

• The transactions for a given work are parameterized by the information in the usage rights sentences for the work.

• The rights on a work can be changed later, if the change is authorized by the rights owner.

1.4 Interfaces to Digital Property Rights Specifications

Specifications in the digital property language are established by creators of digital works and also by publishers and distributors. Specifications are used by consumers as they select and use digital works. However, creators, publishers, distributors, or consumers would seldom (if ever) look directly at specifications written in the language.

Thus, specifications in the usage rights language are intended to be readable by machines rather than directly readable by people. They are used by systems that store, play, transport, copy, and sell digital works. These repositories potentially include a range of devices with embedded computers, including personal computers, set top boxes, personal document readers, personal entertainment devices, on-line servers, and trusted printers.

In many cases, the rights associated changing rights with a digital work are established at the time that the work is published and remain the same over time. There are, however, several ways that rights may be changed over time, and these involve different interfaces.

• Republishing with new rights. In the simplest case, the publisher or rights holder may simply republish a work with new rights. At the time of publishing, the terms and conditions on new copies of the work are changed to be different from those on older copies of the work. One way to accomplish this is simply to reinvoke a rights editor on a copy of the work and then to begin distributing only the revised version. An important job of a rights editor is to check the credentials of the person seeking to change the rights, since only the rights owner is authorized to change the rights on a work.

• Embedding a work and adding new terms and fees. In this case, a work may be embedded in a larger work. Embedding is controlled by the Embed right discussed later in this document. Generally, embedding is done by a distributor, who adds value by repackaging the work. Embedding typically adds extra fees for exercising rights. Although this operation typically includes combining a work with additional content, it includes the case where the content itself is not changed.

• Upgrading rights. Some trusted systems will support the operation of changing the rights on a work already distributed. This process would be carried out on a trusted system which checks the authorization for the change during a transaction that changes the rights. The details of the transaction are beyond the scope of this document except to say that the operation is automatic and the transaction to change the keys must be digitally signed by the rights owner.

Programmers developing trusted applications that use the rights language would typically not work with the syntax directly. Instead, they would use the application programmer’s interface (API) to an object-oriented representation of the statements in the rights language. The application interface is described in other documents.

1.4.1 Rights Editor Interfaces

To specify rights a publisher of a digital work uses a graphical user interface (a "rights editor" program) in a digital authoring or publishing system. Such interfaces can take different forms. For example, one convenient form of a right editor interface is similar to a spreadsheet.

The interface enables a publisher to fill in information indicating what rights, fees, or licenses apply to the digital work at hand. For example, a publisher may simply select individual rights or a set of standard rights from a menu, modifying them slightly to indicate particular fees or distribution requirements. The publishing program then outputs a specification written in the digital property language and attaches that specification to the digital work.

1.4.2 Trusted System Interfaces

Trusted systems, such as trusted workstations, trusted music players, trusted video players, and other trusted devices need user interfaces appropriate to the device.

For example, to play a work of digital music or a video, a consumer would just press the play button of a trusted player in much the same way that one uses a play button on a conventional compact disk or video tape player. In many systems, pushing a button would automatically invoke all of the appropriate checking, authorization, and payment transactions that are required for playing the digital work. In some systems, a consumer could use a small display similar to a calculator display to select among different rights or billing options. Different devices would have different user interfaces, but interoperable devices would share a common digital property language — a lingua franca for systems dealing in permissions and fees.

In some cases, a digital work may be offered with hundreds of variations on the rights. For example, a publisher may offer variations on rights at different prices for different users. There may be regular consumer rates, corporate rates, special rates for academic institutions or libraries, special rates for members of the book of the month club, special rates for frequent fliers, special rates for recent purchasers of other works by the same publisher, and so on. There can be different rates for a permanent use, use over a ten year period, or use over a special two-day introductory period.

In many cases, an unmediated interface to so many variations will be overly complex for normal use. An alternative is for the system to present the set of credentials, memberships, and special offers available to the user via an interface agent that matches held certificates and tickets with the rights offers available on the digital work. Given a selection policy established by the user, the agent can filter the choices down to a small set or automatically select the lowest cost right meeting the user’s needs. For example, on a trusted music player, pressing the play button may be all that is required to select the least expensive alternative and play the work.

1.5 Design Goals for the Digital Property Rights Language

The design goals for DPRL are:

• To describe rights, fees, and conditions appropriate for the commerce models that are important to publishers and consumers in digital publishing.

• To provide standard terms for usage rights specifications that have useful, concise and easily understandable meanings.

• To provide operational definitions of specifications for vendors of trusted systems that distribute or render digital works, so that the compliance of systems can be tested and evaluated.

• To provide a basis of extensibility to new language features in a manner that does not unduly compromise the other goals.

Digital commerce in documents requires a wide range of specification abilities to handle the variety of publishing niches and payment schemes that will be desired. A digital property rights language should be expressive enough to handle a wide range of situations for commerce in documents. The rights specifications must be practical to interpret and enforce by computer systems. Furthermore, the meaning of rights expressed in the language must be clearly defined so that different systems will interpret the rights in the same way.

Broadly construed, DPRL is about "terms and conditions" of use. Terms and conditions ultimately refer to facts about the world and permissioned actions on digital works. Examples of facts are: the current date and time, whether the user is a member of the book of the month club, and the security class of the trusted system. DPRL requires well-defined and certified ways of determining such facts, such as trusted clocks and accessible, signed digital certificates attesting to various facts. Restated, the kinds of facts DPRL uses to determine whether a right can be exercised are always determinable in a reliable way by accessing digital certificates and controlled internal parameters of trusted systems.

Actions sanctioned by terms and conditions are always well-defined transactions corresponding to exercising specific digital rights. Thus, there are transactions defined for such actions as printing, copying, or making an encrypted backup copy. All of these actions are performed by trusted systems. There are no rights in DPRL for actions performed by people, such as "play for educational purposes," although this might alternatively be approximated as "play for a user possessing a specific, valid educator or student certificate."

Although the digital property rights language has already benefited from comments from publishers and other interested parties, the language is not frozen. Further changes will be made as we discover situations that we have not yet considered. Feedback and suggestions are solicited.

2. LANGUAGE SPECIFICATIONS

Usage rights specifications are represented using the element/attribute markup model of eXtensible MarkUp Language(XML) . Collectively, the markup tags indicate what rights are in effect on a digital work. Different parts of a work may have different rights specified. The rights specification is written in a Document Type Definition (DTD) file.

Terms in italics represent elements. An element may contain other elements, together with character data. Elements can also contain meta-data in the form of attribute list. A basic XML element declaration looks like this:

<!ELEMENT list (item)+>

This means that the element list contains one or more item elements. "+" denotes one or more. "*" denotes zero or more. A "?" indicates that a specification is optional. Vertical bars "|" are used to indicate alternative expressions. For example, the rule

<!ELEMENT b (a, (x| c)?)>

<!ELEMENT x (list))

<!ELEMENT a EMPTY>

<!ATTLIST a d CDATA #REQUIRED>

<!ELEMENT c (#PCDATA)>

means that a element b is expanded into an "a" followed by an optional "x" or "c". The element x is expanded to another element "list". The element a does not contain any data between its start and end tags but has a mandatory character data attribute "d" that has to be specified. The element c contains Parsed Character Data (PCDATA) . The "#"words are XML keywords and should be used as is (case senstive).

If an element (as in "a") is specified to be EMPTY, it means that there will not be anything between its start and end tags. The usage of such tags within a XML document can be in either of the following two ways:

An element can also be defined as ANY, in which case, between the start and end tags of that element any other tag or data can be specified in the XML document.

Just as elements represent the document’s logical structure, entites represent its physical structure. A reference to a declared entity can be done in the DTD. For example

<!ENTITY % inline "#PCDATA | emphasis | link" >

<!ELEMENT para (%inline;)

is equivalent to <!ELEMENT para (#PCDATA | emphasis | link)>

White space in the language follows the XML specification. White space, such as spaces, tabs and blank lines, is used to set apart the markup for greater readability. However, "significant" white space within character data is preserved. In XML, all markup tags are case sensitive and the XML documents using this DTD should use the tags as defined. Thus a "Work" tag is different from "work" tag or "wORk" tag. The rights specification DTD defines all the tags by capitalizing the first letter for better readability.

The comments in a XML document begins with "" characters.

Design goals for the specification written in XML include

• Simple parsing. The XML is compatible with SGML and is easy to write programs which process XML documents.

• Extensive defaulting. Many parameters are optional. The mandatory parameters are specified and optional parameters have well-defined defaults.

• Extensibility. In the rights specification DTD, it is easy to add new features unambiguously without substantially modifying the language or rewriting old specifications.

The rights specified in an XML document should meet all the well-formedness and validity constraints specified in the DTD. An example of well-formed, valid XML is

<b>

<c>"This element is a PCDATA"</c>

</a>

</b>

The order in which the elements are specifed within another element is position-sensitve. (i.e within the element "b", element "c" cannot be specified before "a".

2.1 Specifying a Work

The highest level grouping in the digital property language is a work specification.

The language design goal for a work specification is to provide a place for the information relevant to a digital work. A composite work would have a separate work specification for each part of the overall work.

<!ELEMENT Work (RightsVersion,

WorkId?,

Description?,

Owner?,

Parts?,

Contents?,

Copies?,

Comment?,

(RightsGroup | ReferencedRightsGroup)+

<!ELEMENT RightsVersion EMPTY>

<!ATTLIST RightsVersion version-id CDATA #REQUIRED>

<!ELEMENT WorkId EMPTY >

<!ATTLIST WorkId work-id CDATA #REQUIRED>

<!ELEMENT Description (#PCDATA)>

<!ELEMENT Owner (Certificate)>

<!ELEMENT Parts (WorkId+)>

<!ELEMENT Contents EMPTY>

<!ATTLIST Contents from CDATA #REQUIRED

to CDATA #REQUIRED>

<!ELEMENT Copies EMPTY>

<!ATTLIST Copies copy-count CDATA #IMPLIED>

<!ELEMENT Comment (#PCDATA)>

A work specification includes the RightsVersion which is the version of the rights language used for the specification. This is intended to facilitate backward compatibility to works whose rights were written in an old version of the language.

A work specification also includes optional work identification (WorkId). This identifies a digital certificate signed by a well known registration authority and assigning a unique identification number to the digital work. Assumptions and methods for identifying and rating works are discussed elsewhere in this document.

The work-id is an identification tag which can be used to identify this work. It includes information for detecting locally if the work has been changed or tampered with. It also includes address information for locating a reference copy of the work.

A work specification also includes an optional text description of the work, which is intended to hold ISBN numbers for books, ISSN numbers (for periodicals), author addresses, and a variety of other information for identifying a work, but whose format is not necessarily fixed. The format and scope of the information in the text description is not specified, so that different organizations can put different information here. In general, the information in the text description is intended for human use. It is not used in the automatic rights processing of a repository.

The ability to change the rights on a work is not the same issue as adding further fees or restrictions when a work is included in a composite work. Rather, it is the right to change the terms and conditions within the work specification. A work specification includes an optional owner specification, which indicates who is authorized to change any part of the work-specification, including adding or deleting rights, changing conditions, or raising or lowering fees. The owner specification indicates what digital license is required to make the changes. If no owner specification is specified, then anyone can make changes to the rights on a digital work. This is the first example of a specification of a digital certificate. Digital certificates and their representation are described in more detail later in this manual.

For composite works, the optional parts specification specifies a list of works which are included as parts of this work. The right specifications given in the higher level work specification are for the work as a whole. (They do not override the rights on individual included works. See the appendix on transaction semantics.)

The contents specification gives the starting and stopping addresses to which the rights in the work specification apply. If no contents specification is given, the work is interpreted as covering the entire attached digital work. When works are nested, the addresses are taken as relative to the beginning (origin) of the larger containing work. The form of an address depends on the medium on which the work is stored.

An optional copies specification gives the number of copies of the digital work. This field is referenced in the operation of various rights. If no copies specification is given, the number of copies of the digital work is taken to be one. If there are two or more copies, then it is possible to transfer or loan a copy of the work while exercising other rights on remaining copies.

A work specification includes an optional comment. Comments in DPRL are intended for documentation, typically used by people creating and updating rights specifications. Comments are not interpreted for meaning by trusted systems. However, persistence of comments is important in order for comments to serve their purpose. Comments have fixed and specific locations in the syntax ("structured comments"). There can be atmost one comment in a work specification. Comments can also be used in other places in a specification, such as in rights groups, as described later.

Finally, a work specification includes a list of named groups of rights.

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

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

<Owner>

</Certificate>

</Owner>

<Parts>

</Parts>

<Comment>"Rights edited by Pete Jones, June 1996."</Comment>

<Comment>"This set of rights is used for standard retail editions."</Comment>

</Access>

</Account></BundleMonetary></BundleFee>

</Bundle>

<Play>

</MeteredFee></Monetary></Fee>

</Play>

<Print>

</Certificate>

</Printer>

<Watermark-Tokens all-rights="false" render-rights="true"/>

</Watermark>

</Print>

<Copy>

</Copy>

<Copy>

<User>

</Certificate>

</User>

</Access>

</Copy>

</Restore>

</RightsList>

</RightsGroup>

</Work>

This example of a work specification in the digital property language has one rights group. The work specification expresses conditions and fees for several rights: play, print, transfer, copy, delete, backup, and restore. The syntax, meaning and defaults of these various right specifications are explained later. The work includes two other parts, a photograph and a chart of breeds incorporated from other sources.

Usage rights specifications are organized in groups of rights. Various rights specify what usage rights are passed along when a work is copied, transferred, loaned, or used in derivative works. It is convenient to refer to groups of rights by name. Within a work specification, each rights group must have a unique name.

<!ELEMENT RightsGroup (Comment?, Bundle?, RightsList)>

<!ATTLIST RightsGroup group-name CDATA #REQUIRED>

<!ELEMENT ReferencedRightsGroup (Comment?, Bundle?, RightsList)>

<!ATTLIST ReferencedRightsGroup group-name CDATA #REQUIRED>

There are two kinds of rights groups: regular rights groups and reference rights groups. A regular rights group contains a group of rights applied to the current work. A reference rights group contains a group of rights that can be referred to by name in transport rights and applied to subsequent copies of the work.

A rights group can include an optional comment before the list of rights.

A rights group can include an optional bundle specification, which specifies time specifications, fee specifications, or access specifications that apply to all of the rights in the group. The precise meanings of time specifications, fee specifications, access specifications, and watermark specifications as they appear in bundle specifications are explained in later sections. A bundle specification can include an optional comment.

The rights for a digital work are explicitly listed. Any right not in the list is not granted. The name of the right identifies the kind of right. Kinds of rights fall into various classes as explained later.

There can be more than one instance of a particular kind of right for a given work. For example, there can be more than one instance of a Copy right, which grants permission to make new copies of a digital work. One instance of the Copy right may have a special rate for "book of the month club" members. Another instance of the Copy right may allow copies to made without charge if the consumer has an appropriate digital ticket.

<!ELEMENT RightsList ((Copy | Transfer | Loan |

Play | Print | Export |

Edit | Extract | Embed |

Install | Uninstall)+)>

Each right, identified by its name, has an optional comment, an optional time specification, an optional access specification, and an optional fee specification.

All the rights being granted for the work is specified in the list. The various kinds of rights covered by the usage rights system are described in the rest of this section. The time specification states the period of time over which the right is granted. The access specification states conditions on the exercise of a right, such as a requirement for various authorizations. The fee specification states fees associated with the exercise of a right. These specifications are described individually in the following sections of this manual.

The specifications for a given right are a combination of (1) the specifications explicitly within the right statement itself, and (2) specifications from an optional bundle specification in the rights group to which it belongs. If there is no time specification, then there is no time limit on the use of this right. If there is no access specification, then there is no access test (including security level) required. If there is no fee specification, then there is no fee required for use. A right specification can include an optional comment.

2.2 Digital Property Rights

Rights belong to one of several categories. The rights in DPRL describe uses that:

• Relate meaningfully to distinctions of use described in copyright law.

• Respect distinctions of use relevant to common licensing arrangements in commercial purposes of digital works.

• Are enforceable by practical trusted systems.

• Are exercised by carrying out a particular transaction on a repository.

Logically, rights can be categorized into Transport, Render, Deravative work, File management and rights for Configuration. Transport rights govern the movement of a work from one repository to another. Render rights govern the printing and display of a work, or more generally, the transmission of a work through a transducer to an external medium. (This includes the Export right, which can be used to make copies in the clear.) Derivative work rights govern the reuse of a work in creating new works. File management rights govern such things as making and restoring backup copies. Finally, configuration rights refer to the installation of software in repositories.

The next five sections pf this manual, describe each of the rights that fall under each catergory.

2.2.1 Transport Rights

Transport rights govern the creation and movement of persistent copies of a work under the control of trusted repositories. There are three distinct kinds of transport rights: copy, transfer, and loan. The interpretation of these rights are similar to familiar operations on physical works: copying an audio tape, transferring (or giving someone) a book, or loaning a compact disc.

The design goals of the transport rights are to provide for the following:

• To distinguish between rights for moving works among repositories and rights that increase the total number of copies of a digital work.

• To describe controlled loaning of works, both personal loans and also institutional or library loans.

• To support a range of distribution models, including both licensed distributor models and consumer-based distribution (also known as super distribution).

• To enable publishers to specify how the rights change on new copies of works.

• To control what rights move to the loaner copy when a copy of a work is loaned out and also what rights stay behind.

<!ELEMENT Copy (NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Transfer (NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Loan (RemainingRights?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

A Copy right is the right to make a new digital copy of a work. (Print rights, described later, govern the making of hard copies.) The Copy right is invoked whenever a new digital copy is made. Like all rights, the right to copy can be parameterized by time, access, fee, and control specifications. An optional next-copy-rights specification can be used to establish rights for the new copy that are distinct from the rights on the original.

A Transfer right is the right to transfer the digital work from one repository to another. A Transfer right does not increase the number of copies of a work because the transfer transaction between two trusted systems removes the digital work from the sending repository when the copy has been created and verified on the receiving repository.

A Loan right is the right to loan a copy of the work for a period of time. A Loan right creates a "loaner" copy of a work on a receiving repository. Typically, during the time that a work is loaned, the original copy of the work cannot be rendered. However, if there is more than one copy of the work on the original repository, then the original repository can still exercise all rights on copies that are not loaned out. As discussed below, exactly what rights are usable by either the loaning repository or at the loanee repository can be specified explicitly using the next-copy-rights and the remaining-rights specification.

Throughout the loan period, both repositories must keep track of the fact that the copy has been loaned and take this information into account in all relevant transactions. At the end of the loan period, the copy of the work on the receiving repository deactivates and the copy on the loaning repository reactivates.

<!ELEMENT NextCopyRights (RightsToAdd | RightsToDelete)>

<!ELEMENT RemainingRights EMPTY>

<!ATTLIST RemainingRights group-name CDATA #REQUIRED>

When a digital work is copied, transferred, or loaned, certain rights become available on the receiving repository. Exactly which rights are available is determined by an optional NextCopyRights specification. By default, the rights on the new repository are the same as the rights on the original repository. However, the list of rights can be modified by specifically adding or deleting groups of rights. The groups named can be either regular rights groups or reference rights groups.

The rights specification for the next copy can be described as a set of differences from the original specification. These differences may be rights to add to those of the original and rights to delete from those of the original. The set of rights provided in the RightsToAdd specification is added to those of the original work. The set of rights provided in the RightsToDelete specification is deleted from those of the original.

<!ELEMENT RightsToAdd EMPTY>

<!ATTLIST RightsToAdd group-name CDATA #REQUIRED>

<!ELEMENT RightsToDelete EMPTY>

<!ATTLIST RightsToDelete group-name CDATA #REQUIRED>

The optional remaining rights specification describes what rights to keep behind in the original loaned work. If this specification is not given, then no rights are retained when the last copy is loaned out.

Here is a simple example of a Loan usage right that specifies what rights to keep and which ones to give on the loaned copy. In this case, the loaner copy gets all of the rights except the book club rights, which are retained, by the original repository.

<Loan>

</Access>

</Loan>

Here is another example of a work specification. This work specification has two rights groups, one called "Distributor" and one called "Consumer."

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

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

<Owner>

</Certificate>

</Owner>

<Comment>"These rights limited to our licensed distributors."</Comment>

</Certificate></User>

</Access>

</Bundle>

<Copy>

</Ticket></Fee>

</Copy>

</RightsList>

</RightsGroup>

<Comment>"These rights exercised by any owner of our works."</Comment>

</Access>

</Account></BundleMonetary>

</BundleFee>

</Bundle>

</Account></Monetary></Fee>

</Copy>

<Play>

</MeteredFee></Monetary></Fee>

</Play>

<Delete><Comment>"This right is without restrictions."</Comment></Delete>

<Loan>

</Loan>

</RightsList>

</RightsGroup>

</Work>

The distributor rights include the right to copy a work without fee except that a particular digital ticket must be punched. The distributor rights also include a right to play the work without fee. Each of the rights in the "Distributor" rights group requires a Murphy’s distributor digital license to exercise.

There is also a "Consumer" rights group. This group includes rights to copy, play, delete, transfer, and loan. The copy right has a set fee to make a copy and the play right has a metered charge of five cents per hour. A loaner copy does not carry the distributor rights.

2.2.2 Render Rights

Render rights govern the creation of representations of a digital work outside of the control of trusted systems.

According to the dictionary, to render something is to represent it in a verbal form or in a drawing or a painting. In the context of usage rights, we use the word "render" to refer to processes that transform a digital copy of a work into a form where it can be seen or used outside of the repository. For example, a digital book or digital photograph may be displayed on a screen, a piece of music may be played through a loud speaker, a movie may be shown on a screen, or a page of a book may be printed on a printer.

When a digital work is rendered, information moves outside of the control of a trusted system. This presentation of the work as image or sound makes it possible for someone to see or hear the work. Necessarily, it also makes the work accessible for analog copying. Anything you can see you can photograph; anything you can hear you can record. Rendering does not imply permission to make other recordings of the work, such as with a film camera, video camera, or tape recorder, even though such copies will typically have lower quality than the digital original. The right to make such copies is governed by copyright law. Many techniques for rendering from digital originals also allow the inclusion of information in watermarks and fingerprints, making it possible to identify the work and also the person who played it. Although recordings of rendered works cannot be prevented, such non-digital copying of a work is governed by applicable copyright laws.

The design goals of the render rights are:

• To distinguish between rights for making ephemeral copies such as display images and rights for making long-lasting copies such as printouts.

• To provide a means of distinguishing different kinds of players and printers for digital works such as ones that add distinguishing codes. For example, a publisher may want to limit printing of a digital work to certain kinds of printers that are capable of embedding specific kinds of watermarks.

• To provide a controlled means for creating unencumbered digital copies outside of a trusted system.

• To provide a means for specifying information to be embedded in watermarks for works displayed or printed. Watermark data can be pre-specified by a publisher or distributor. It includes data that is not known until the time that a work is printed or displayed.

<!ELEMENT Play (Player?, Watermark?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Print (Printer?, Watermark?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Export (Repository?, Comment?, Time?, Access?, Fee?)>

There are three kinds of render rights: play, print, and export.

Play rights refer to ways of making a transient or ephemeral copy of a work available for use. For example, a page of a book may be displayed on a screen or music may be played out a speaker. The image on the screen or the sound coming out of the speaker is a transient copy. The Play right is also used to refer to invocation of a computer program, such as when someone plays a video game. The renderings produced when a Play right is exercised are ephemeral. Another way to understand a "Play" right is that playing requires active participation by a trusted player to render the work during the entire time that the work is perceivable.

Print rights refer to making more permanent rendered copies of a work outside of the control of a repository. In contrast to the Play right, once a work is printed, the printed copy can be viewed without requiring that the "printer" be used the entire time. The typical case is printing something on paper at a printer. The Print right also refers to making rendered copies on other external media, such as bitmap images on removable disks or audio on magnetic tapes. For example, a repository may provide rights to "print" encrypted backup copies of a digital work. Unauthorized use of such copies is inhibited because such copies of the work are generally encrypted.

An Export right makes a digital source copy outside of trusted system control. Typically, this would be a file in a format suitable for unencumbered viewing, printing, or editing. Thus, this right can be used to make a digital copy that is not encrypted or otherwise protected. An Export right might be exercised, for example, to release an older work after it has passed out of copyright.

Render rights can optionally specify the use of particular kinds of hardware for playing and printing. These specifications are intended to qualify the use of a work. Players and printers are parts of repositories, and are sometimes called trusted players and trusted printers. They are identified by non-transferable digital certificates. A given repository, such as a trusted printer, may have several different digital certificates corresponding to different output devices or kinds of printing services. For example, a digital movie player may specify a kind of player suitable for home use rather than theater use. The certificate for a particular player may be used to differentiate between high and low resolution renderings with appropriately different fees.

A printer specification may indicate a printer which marks the pages with a particular kind of identifying watermark. Specifications for embedding data in watermarks on trusted printers and trusted players are discussed in a later section.

Here is an example of a work specification. This specification is for a digital home movie. The work has two groups of rights called "theater" and "home-viewer". The theater rights allow playing the movie on a kind of public viewer by authorized distributors for a fee of $100. The home-viewer rights allow playing the movie on a home player for a rate of $5 per hour.

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

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

<Description>"Title: 'Zuke-Zack, the Moby Dog - The Movie' Script:'John Beagle'

Director: 'Peter Hound Jones' Producer: 'Martha Jones'

No Cruelty to Animals in this flick.

</Description>

<Owner>

</Certificate>

</Owner>

<Play>

</Certificate></Player>

</Certificate></User></Access>

<Fee>

</Account></Monetary></Fee>

</Play>

</RightsList>

</RightsGroup>

<Play>

</Certificate></Player>

<Fee>

</Monetary>

</Fee>

</Play>

</RightsList>

</RightsGroup>

</Work>

The following example is of a digital book. The exemplar digital book has no fee for playing, but does have a five dollar fee for making a digital copy. It also has two Print rights, both requiring a trusted printer. The first Print right can be exercised if the user has a particular prepaid ticket. The second print right has a flat fee of ten dollars. The example assumes that the digital book can transmitted to a user’s computer by exercising the Copy right, and that the user can play or print the work at his or her convenience using the Play and Print rights. Fees are logged from the user’s workstation whenever a right is exercised.

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

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

</Certificate></Owner>

</Access>

</BundleMonetary></BundleFee>

</Bundle>

<Print>

</Certificate></Printer>

</Ticket></Fee>

</Print>

<Print>

</Certificate></Printer>

</Print>

</RightsList>

</RightsGroup>

</Work>

Here is a different version of rights for the "Moby Dog Story" digital book. In this version, the publisher does not want digital delivery to be made directly to a consumer workstation. A practical consideration supporting this choice may be that the publisher wants to minimize the risk of unauthorized copying and requires a higher level of security than is provided by trusted systems on available workstations. Instead, the publisher wants the book to be sent directly from an on-line bookstore to a trusted printer. Printing must be prepaid via digital tickets. To enable digital distribution to authorized distributors but not directly to consumers, the publisher requires that both parties in a Copy right be have an authorizing digital license. In this example, a consumer can not play the work at a workstation. Instead, the consumer must print the work.

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

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

</Certificate></Owner>

</Access>

</BundleMonetary></BundleFee>

</Bundle>

<Copy>

</Certificate></Source>

</Certificate></Destination>

</Access>

</Copy>

<Print>

</Certificate></Printer>

</Ticket></Fee>

</Print>

</RightsList>

</RightsGroup>

</Work>

2.2.3 Derivative Work Rights

Derivative work rights govern the reuse of a digital work, in whole or part, to create a new composite work. The design goal for derivative work rights is not to cover all possible forms of reuse. Many kinds of reuse involve substantial negotiation about issues that are outside the scope of what a practical trusted system can mediate or check. Rather, the derivative use rights are intended to automate the simple case where the rights owner can pre-determine fees and repository-testable conditions on a work prior to distributing it digitally.

The design goals for the derivative work rights are:

• To make it possible for the rights owner to pre-arrange fees and conditions governing subsequent use of the material in derivative works.

• To make it possible for the rights owner to pre-determine whether communication for notification or authorization is required before a derivative work right can be exercised.

• To ensure that all information about authorship, identity, contents, and rights is controlled or preserved in the derivative work.

• To arrange that the collection of fees for use of derivative works is automatic and can depend on the number of copies of the derivative work that are actually made.

• To enable a rights owner to determine whether derivative works can incorporate selected portions of a work, or whether the original work must be incorporated in total.

• To provide a framework that can eventually enable a rights owner to determine what kinds of changes are permitted in the derivative work, if any.

<!ELEMENT Edit (Editor?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Extract (Editor?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Embed (Editor?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Editor (Certificate+)>

There are three kinds of derivative work rights: extract, edit, and embed.

The Extract right allows removing a portion of a digital work, creating a new work. A rights owner can divide a total digital work up into different sub-works, each with its own work specification. In this way, the rights owner can decide whether a work can be reused as a whole or in parts, and also can associate different rights and conditions with different parts of a digital work. Extract differs from Edit in that it does not grant the right to modify a work, except by removing parts of it.

The editor specification is intended to be used to test whether different editing systems qualify. From the perspective of DPRL, an editor is expected to be a trusted system with signed certificates attesting to its properties. A publisher can name the properties that an editing system must have before it can be used to edit the work. If the optional editor specification is not given, then any editor program can be used for the extraction process. Otherwise, an editing system with the specified certificates can be used.

Edit grants the right to modify a work. Edit is like Extract in that it creates a new work. It differs from Extract in that it is used to make changes to a work. A rights owner can control what kinds of changes can be made to a digital work by specifying a kind of editor. For example, a particular digital audio music editor may allow someone to change the pitch or key of a piece of music, but not add notes. If the optional editor specification is not given, then any editing program can be used. Otherwise, only the specified editing system can be used.

Embed grants the right to include a work as part of a composite work. Embed puts a copy of a digital work inside a composite work. If the optional editor specification is not given, then any editing system can be used. Otherwise, only the specified editor can be used.

By default, if the optional next copy rights are not specified, the fees and conditions for a work when it is reused are the same as the fees and conditions for the original work. A publisher can override this default by adding or deleting rights in an optional next-copy-rights specification.

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

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

</Certificate></Owner>

<Comment>"These rights apply to deravative works."</Comment>

<Copy>

</Access>

</Account>

</Monetary></Fee>

</Copy>

</RightsList>

</RightsGroup>

</Access></Bundle>

<Copy>

</Account>

</Monetary></Fee>

</Copy>

</Certificate>

</Editor>

</Extract>

<Embed>

</Certificate>

</Editor>

</NextCopyRights>

</Embed>

<Play>

<Fee>

</Account>

</Monetary>

</Fee>

</Play>

</RightsList>

</RightsGroup>

</Work>

Here is an example of how a work can be specified to provide for derivative use. In this example, the publisher has granted Extract and Embed rights requiring that a particular "editing" program be used. No changes can be made to the work. In addition to the original rights on the work, the embedded work has an additional copy right with a lower per use fee paid to a different account.

For some applications, it will be useful to have fairly elaborate controls on the changes that can be made to a derivative work. For example, a written work may require that certain sections always be extracted together. A musical work may allow changing the key and pitch but not the notes. The variety of possible kinds of controls is rich, not developed, and depends on the media and application. The digital property language is designed to allow application-specific kinds of restrictions as described in the following.

Each kind of editor can have its own terminology for kinds of change. For example, a digital music editor might have editing operations for pitch, key, instrumentation, and other things. Digital representations for works can be augmented to include annotations that point to regions of a work and specify in an application-specific way the kinds of changes that can be made. Such annotations would have no effect when a work is played, but would control editing operations when a derived work is edited.

In this way the rights specifications are divided between domain-independent considerations in the digital property language and the application-specific considerations in specific editors. The usage rights language allows a rights owner to specify general usage rights in the usual way, including the required use of a chosen editor (or family of editors) for editing the work. The rights owner then uses the specified editor to annotate the work to specify the kinds of changes that are allowed in domain specific terms. Later when a user wants to make a derived work by editing the work, he must use a compatible trusted editor which follows the domain-specific change annotations.

2.2.4 File Management Rights

File management rights govern access to directory and file information when two repositories are connected. File management rights control how directory information of one repository can be accessed from another. They also control the making and restoring of backup copies.

Some usage rights, such as Print or Copy, typically involve more than one repository. Other usage rights, such as Transfer and Loan, inherently involve more than one repository. To exercise rights that involve more than one repository, a user at one repository must be able to access digital works located on another.

The design goals for the file management rights are as follows:

• To provide a simple and consistent means to specify and control access to digital works across different repositories and different kinds of repositories.

• To provide a lightweight and convenient means for organizing collections of digital works on a repository.

• To integrate specifications for controlling how collections of works can be used with specifications about how individual works can be used.

• To provide facilities that manage the risk of system or media failure or distribution of rogue works.

<!ELEMENT Backup (BackupCopyRights, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Restore (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Verify (Verifier, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Folder (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Directory (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Delete (Comment?, Time?, Access?, Fee?)>

<!ELEMENT BackupCopyRights EMPTY>

<!ATTLIST BackupCopyRights group-name CDATA #REQUIRED>

<!ELEMENT Verifier(Certificate+)>

There are six kinds of file management rights: Folder, Directory, Delete, Verify, Backup, and Restore.

When a repository has many digital works, it is often convenient to organize them into named hierarchical sets called folders. This approach is basic to many popular file systems, such as Windows™, MacOS™, and UNIX™. In repositories built on conventional computer file systems, these hierarchical sets generally correspond to file system folders and directories. For consistency across brands of repositories, the same digital property language that applies to digital works is also used for folders.

Folder rights govern the creation and naming of subfolders, and the right to reconfigure the folders by moving files and folders among folders. These rights are exercised by commands at a repository user interface. The right to exercise all of these operations is governed by the single "folder" right. (Restated, there are no separate rights for moving or renaming files and folders. All of these repository actions are governed under folder rights.) Directory rights govern the delivery of information about what works are contained within folders.

Here is an example of a rights group for a personal folder on a repository. The rights on a folder augment the rights of the works in a folder. For example, if a work is moved into a folder on which there are no print rights, no work in the folder can be printed. In this example, the rights group named "PersonalFolder" simply adds the requirement that a particular authorizing license ("Stefik’s license") be in force before any of a set of rights can be exercised. Moving a work into this "personal" folder would prevent anyone, who is logged into the repository but who does not have the license, from accessing or using any work in the folder.

</Certificate></User></Access>

</Bundle>

</RightsList>

</RightsGroup>

A directory listing may be requested of any folder in a repository, allowing either the local or a remote repository to get information about the works, their parts, and other folders contained in it. The ability to get information about a folder, a work, or its parts may be withheld in such directory listings by simply requiring a license to exercise the right.

Delete rights govern the operation of deleting a copy of a digital work. The generally expected practice is to grant any copy owner the right to delete the work. The right to delete needs to be controlled in applications where many people can log into a repository and where deleting a file could be done accidentally or in malicious mischief. To prevent the unwanted and unauthorized deletion of digital works that are accessed remotely, it is typical for a Delete right to include various conditions, such as the requirement of a digital license to exercise the right.

An opposite problem from unauthorized deletion is the creation of "Trojan Horse" works which are copied for free but which require fees to delete them. To defend against such tricks, many repositories will generate warning and confirmation messages before accepting copies of works that lack delete rights or which assess charges or conditions to exercise this right.

Verify rights are used to authorize checking of the authenticity of a work. There are several different kinds of checking that can be performed. The simplest checks verify that the work is properly encrypted. Other checks involve the use of 1-way hash functions and other keys that can detect tampering with a work. Other checks can consider hot-lists of rogue works maintained by the trusted system. Reference copies of a work may be available on the network. Local copies can be carefully compared with reference copies to verify their authenticity.

Since a verifying system has access to the contents of a digital work, publishers can require that the system be certified. To protect against "rogue verifiers" that copy works under the guise of checking them or that damage works, publishers may specify that particular kinds of verifiers be used, such as certified verifiers on well known on-line servers.

</Certificate></Verifier></Verify>

Backup grants the right to make copies of a work for the purpose of guarding against the loss of the original due to accident or catastrophic media or equipment failure. The backup operation creates an encrypted copy of a digital work, which is in a form where it cannot be rendered without first exercising a restore operation. The optional BackupCopyRights is used to specify the rights on the encrypted backup copy. Typically, Transfer and Restore rights would be given on a backup copy. If no backup copy rights are given, the default right is to restore the copy. Backup copy rights are not the same as the rights that will be available when the backup copy is restored. The rights on the restored copy are the same as the rights on the original before the backup was made.

A restore operation converts an encrypted backup copy into a usable copy in a controlled manner. Restore rights typically elaborate various fees and conditions that balance the interests of the copy owner with the interests of the publisher.

</Access></Transfer>

</Ticket></Fee>

</Restore>

</Monetary></Fee>

</Restore>

</Certificate></User>

</Access>

</Restore>

</RightsList>

</ReferencedRightsGroup>

</Access></Play>

</Access></Transfer>

</RightsList>

</RightsGroup>

Here is an example of Backup and Restore rights. The reference rights group named "Safety-Net" includes a transfer right and three restore rights with different fees and conditions. All of the restore rights require that the repository have security class 3. One of the restore rights requires no monetary fee but uses a particular digital ticket. This approach could be used by a publisher who grants a limited number of free restorations controlled by a set of digital tickets. The second restore right costs a flat fee of $15. The third restore right is free, but requires a particular distributor’s license.

The second rights group called "regular" elaborates rights for normal use, including play, delete, transfer, and backup. The backup copy rights are those in the "SafetyNet" rights group. The next example expresses the same rights groups somewhat more simply by using Bundle specifications.

</Bundle>

</Access></Transfer>

</Ticket></Fee>

</Restore>

</Monetary></Fee>

</Restore>

</Certificate></User></Access>

</Restore>

</RightsList>

</ReferencedRightsGroup>

</Access></Bundle>

</RightsList>

</RightsGroup>

2.2.5 Configuration Rights

Configuration rights govern the adding and removing of system software from highly secure repositories. These rights are not relevant on platforms where the loading of software is not controllable.

The design goals for configuration rights are as follows:

• To provide a means to load software that insures that it is certified, has not been tampered with, and is compatible with the repository.

• To arrange that a user installing and uninstalling repository software in the field has security on the same order as when software is installed in a secure facility.

Because general purpose computers have other means for loading and deleting software, configuration rights are most relevant to dedicated, high security repositories. Typically, the control offered by configuration rights on secure repositories is most useful when adding software for a new player or editor.

<!ELEMENT Install (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Uninstall (Comment?, Time?, Access?, Fee?)>

There are two kinds of configuration rights: Install and Uninstall. As with all other rights, these rights also have an optional comment, time, access, fee specification. An Install operation makes software runnable on a repository. Just copying a program to a repository does not make it runnable. The installation operation checks that software is certified, that it has not been tampered with, and that it is compatible with the repository. If these conditions are satisfied, the install operation links the software into the secure software procedures of the repository.

The Uninstall operation removes software from the running system. Uninstall does not delete the file corresponding to the program. It merely disables it from running, restoring it to the state before it was installed.

2.3 Specifying Times

Usage rights are usually granted for a specified period of time. The time period over which a right is granted is indicated by a time specification. To honor time specifications, a trusted system must have accurate and tamper-proof clocks.

The language design goals of the time specifications are:

• To express time limits that govern when rights become available and when they cease to be available.

• To express the categories of time blocks that are useful for governing commercial use of digital works.

• To describe contiguous periods of time, periods of time that do not start until a work is first used, and accumulative amounts of time that need not be contiguous.

• To provide unambiguous specifications suitable for international commerce and commerce across time zones.

Time specifications use representations of moments in time and units of time. The next two sections describe representations for moments and time units. We then discuss time specifications for usage rights that use these representations to indicate when the rights are valid.

2.3.1 Specifying Moments in Time

Moment specifications indicate a particular moment in time. All specifications of a particular moment in time must specify the date and optionally the time. Any of the paramters are not filled then 00 is implied.

<!ENTITY % moment "yyyy CDATA #IMPLIED

mm CDATA #IMPLIED

dd CDATA #IMPLIED

hrs CDATA #IMPLIED

min CDATA #IMPLIED

sec CDATA #IMPLIED">

Time constants (hrs, min, sec) represent specific times-of-day on the 24-hour clock in Universal Time, or UT (equivalent to Greenwich Mean Time, or GMT). The "hrs" represents the hour and therefore must be between 0 and 23, inclusive. The "min" represents the minute and must be between 0 and 59, and the "sec" represents the second, and therefore must be between 0 and 59, inclusive. The time "24:00:00", in some contexts defined to be equivalent to the time "00:00:00", is not allowed.

Time of Day Meaning

hrs=17 min=30 sec=01 Five-thirty p.m. and one second. (GMT)

hrs=00 min=00 sec=00 Twelve o’clock Am. (GMT)

(midnight, the first second of the day)

hrs=12 min=00 sec=00 Twelve o’clock p.m. (noon, GMT)

Date constants (yyyy, mm, dd) represent a specific day on the calendar. "yyyy" represents the year and must be between 0 and 9999, inclusive. Note that one-, two-, and three-digit integers represent years through 999 AD. Specifically, two-digit integers do not, as in common usage, represent years in the current centennial. "mm" represents the month and therefore must be between 1 and 12, inclusive. "dd" represents the day and therefore must be between 1 and either 28, 29, 30, or 31, inclusive, according to the calendar. Here are some examples of date constants.

Date Constant Meaning

yyyy=1996 mm=5 dd=15 May 15, 1996

yyyy=0999 mm=12 dd=31 December 31, 999

yyyy=2000 mm=01 dd=03 January 3, 2000

Since repositories need to have synchronized clocks for their transactions, which may take place across time zones, it is convenient to use Universal Time as a standard. Conversion to local date and time is performed by the user interface of the trusted system.

2.3.2 Specifying Units of Time

Time specifications indicate a period of time by specifying a number of calendar units, a number of time units, or both. Calendar units are specified in calendar years, months, and days. Time units are specified in hours, minutes, and seconds.

Calendar units are idiosyncratic as units of measure because they do not have uniform sizes. Thus, years have different numbers of days in them depending on leap years. Similarly, different months have different numbers of days in the Julian calendar. Nonetheless, these "units" are convenient in specifications because so many people use calendars.

<!ENTITY % interval "years CDATA #IMPLIED

months CDATA #IMPLIED

days CDATA #IMPLIED

hours CDATA #IMPLIED

minutes CDATA #IMPLIED

seconds CDATA #IMPLIED">

Calendar units(years, months, days) have the same syntactic structure as date constants. The number of years can be between 0 and 9999, referring to a number of calendar years. The number of months can be between 0 and 9999, refering to a number of calendar months. The number of days can be between 0 and 9999. Here are some examples of calendar units.

Calendar Units Meaning

months=3 days=4 Three months and four days.

days=40 Fourty days.

days=7 Seven days

years=1 One calendar year.

In particular, a specification 00/03/00 for three months is not the same as 00/00/90 for ninety days, although they are close. The actual number of days in three calendar months depends on the months when the specification applies.

Time units(hours, minutes, seconds) have the same syntactic structure as time constants. The number of seconds can be an integer between 0 and 9999. The number of minutes can be an integer between 0 and 9999. The number of hours can be an integer between 0 and 9999.

Time Units Meaning

hours=2 minutes=30 Two hours and thirty minutes.

minutes=67 Sixty seven minutes.

minutes=5 seconds=30 Five and a half minutes.

2.3.3 Specifying When Rights Can Be Exercised

We are now ready to consider time specifications for rights. All time specifications refer to a time interval over which the rights are enabled. In addition, there is an optional expiration date, after which the right cannot be exercised even if the interval is not exhausted. If no time specification is given, the right is assumed to be always valid.

<!ELEMENT Time ((From | Interval | Metered)?, Until)>

<!ELEMENT From EMPTY>

<!ATTLIST From %moment;>

<!ELEMENT Interval EMPTY>

<!ATTLIST Interval %interval;>

<!ELEMENT Metered EMPTY>

<!ATTLIST Metered %interval;>

<!ELEMENT Until EMPTY>

<!ATTLIST Until %moment;>

There are three kinds of intervals in time specifications: fixed intervals, sliding intervals, and metered intervals.

In their most complete form, fixed intervals start at a fixed time and ends at a fixed time. In variations, a fixed interval specification can specify only a starting time or only an ending time. Here are some examples of fixed interval specifications.

• <Time><Until yyyy="1995"/></Time>

• <Time><Until yyyy="1994" mm="12" dd="31" hrs="23" min="59" sec="59"/></Time>

Can be used until midnight New Year’s Eve in 1994.

• <Time>

</Time>

Can be used only on Valentine’s Day in 1997.

Sliding intervals specify a consecutive period of time. The period starts when the right is first exercised. To accurately account for sliding intervals, a trusted system must keep track of the time that use started. Here are some examples of sliding interval specifications.

• <Time><Interval hours="12"/><Until yyyy="1996"/></Time>

Can be used for any twelve consecutive hours any time up to January 1, 1996.

• <Time><Interval hours="2"/><Until yyyy="1996" mm="05" dd="01" hrs="8"/></Time>

Can be used for two consecutive hours any time up to 8:00 am May 1, 1996.

Metered intervals represent accumulative periods of time. A user can start and stop using exercising a right as often as he wants. The metering clock runs whenever the right is being exercised, and stops when the user stops using it. The right can be exercised as long as the total time has not been used. To accurately account for metered time, a repository must keep an incremental log of the amount of time used so far.

• <Time>

</Time>

Can be used for two hours of metered time spread out in any way up to 8:00 am on May 1, 1996. The work cannot be used after May 1, 1996 even if the metered time has not yet exhausted the two hours.

• <Time>

</Time>

Can be used for two months spread out in any way until September 1, 1998.

Note that a metered time interval specification is not the same thing as a metered fee specification. A metered time interval indicates the time that a right is valid. It can be used even on rights for which there is no fee. A metered fee specification is a way of indicating how to charge to exercise a right in using a work. Metered fee specifications could be used even on works where the right to use the work does not expire at all.

2.4 Specifying Fees and Incentives

Usage rights can have associated fees which are paid to specific accounts. To honor these fees, trusted systems need to communicate regularly with financial clearing houses. They also need to have reliable and tamper-proof means of recording and reporting billing data. Different repositories have different approaches, depending on the application and the required levels of security and accountability. Some systems accumulate billing logs locally and report them to financial clearing houses on a scheduled basis. Less secure systems must connect with an on-line financial clearinghouse each time that a transaction is made, and before a transaction can be completed.

The language design goals for fee specifications are:

• To express the kinds of charges to exercise a right that are commercially useful for all kinds of digital works.

• To express variations on per-use fees and metered-use fees, including payments per time unit, minimum and maximum fees over a period, and fixed fees for unlimited use in a fixed time period.

• To accommodate approaches based on both credit accounts and debit accounts.

• To support transactions on trusted systems where the consumer is not on-line.

• To express fees in most national currencies and also in publisher-supplied non-currency units (digital tickets).

• To express payments from a consumer to a publisher as well as incentives from a publisher to a consumer.

• To express predetermined and scheduled changes in price.

• To express bundled prices for using combinations of rights.

A fee specification describes the financial transaction required to exercise a right. It can include a ticket specification or a monetary specification. If a ticket specification is given, then the transaction requires that a particular kind of digital ticket be processed ("punched") by a digital ticket agent accessible to the repository. The simplest digital tickets are used just once and are punched by a standard digital ticket agent when they are used. More complex tickets have more internal structure, representing expiration dates, numbers of times that they can be punched, and may require a specialized ticket agent. If a monetary specification is given, then the user will be billed.

<!ELEMENT Fee (Ticket | Monetary)>

<!ELEMENT Ticket (Authority, Type)>

Each right of a digital work can have different fee specifications. In the following example, the "Play Options" rights group gives three different fee schemes for playing the work. One has a ticket, one charges a dollar per play, and one is fifty cents an hour. Some usage rights in the "Regular" rights group, such as transfer, delete, and backup require no fees at all.

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

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

"Title: 'The Moby Dog Story' Author:'John Beagle'

</Description>

<Owner>

</Certificate>

</Owner>

</Ticket></Fee></Play>

<Play>

<Time>

</Time>

</Monetary></Fee>

</Play>

<Play>

</Monetary></Fee>

</Play>

</RightsList>

</RightsGroup>

</Access>

</Transfer>

<Copy>

</Monetary></Fee>

</Copy>

</Access>

</Monetary></Fee>

</Restore>

</RightsList>

</RightsGroup>

</Work>

More details on ways to specify different kinds of fees are described in the following sections.

2.4.1 Currencies and Accounts

Charges may be expressed in any currency known to the repository. As with paper currency, digital bills are subject to the principles and dynamics of currency exchange when accounts are reconciled with financial clearing houses. Restated, the transactions are recorded in a particular currency. Subsequent fluctuations in the value of the currency may occur. If the currency is not explicitly specified, then "US dollar" is assumed. A table of ISO currency codes is given in Appendix A.

<!ELEMENT Currency EMPTY>

<!ATTLIST Currency iso-currency-code CDATA #REQUIRED>

<!ELEMENT Account ((AccountTo, House?) | (AccountFrom, House?))>

<!ELEMENT AccountTo EMPTY>

<!ATTLIST AccountTo account-id CDATA #REQUIRED>

<!ELEMENT AccountFrom EMPTY>

<!ATTLIST AccountFrom account-id CDATA #REQUIRED>

<!ELEMENT House EMPTY>

<!ATTLIST House clearing-house-id CDATA #REQUIRED>

Usage rights fees and incentives may be handled by a wide variety of financial systems and institutions including banks, credit institutions, and electronic commerce organizations.

The account specification typically indicates the account to be paid. Fees are paid by the user/copy-owner to the revenue-owner and indicated by the element AccountTo in the account specification. Incentives are paid by the revenue-owner to user/copy-owner and are indicated by the element AccountFrom in the account specification.

An account-id is an account number together with an institution code that identifies a specific account at a specific bank or other financial institution from which fees will be collected, or to which incentives will be paid.

The account specification takes an optional clearinghouse specification that names a financial clearing house. In closed systems where the financial clearing house is known by default, the specification is unnecessary. In open systems where multiple clearinghouses are possible and account numbers are not unique, the specification names the clearinghouse to be used.

In the following examples, exercising the first right causes the user to be billed fifty cents. Exercising the second one causes the user to be credited fifty cents. The right itself includes information known to the publisher. It does not, for example, name the user’s account. The user’s account information must be held elsewhere in the system.

<Play>

</Monetary></Fee>

</Play>

<Play>

</Monetary></Fee>

</Play>

<Play>

</Account>

</Monetary></Fee>

</Play>

2.4.2 Digital Tickets

Digital tickets are used for pre-paid uses. Loosely speaking, they are a kind of private currency. They are not legal tender, but they can often be purchased for money. They can be exchanged for particular services. Like movie tickets, digital tickets are punched when they are used. On a trusted system, a digital ticket is punched by a local digital ticket agent. A ticket is a digital certificate that is altered ("punched") after use making it unusable for any future transactions.

The design goals for digital tickets are:

• Digital tickets are special digital works issued by publishers.

• A ticket publisher can predetermine the conditions under which tickets can be created, transferred across repositories, or used in rights.

• Independent of the time specifications on rights that use them, tickets can expire even if they have not been used.

• Both unused and punched tickets are secure against forgery and tampering.

• Tickets are processed by a generic ticket agent that is part of a repository.

• Tickets can specify additional required processing by local or remote ticket agents.

• Metered tickets can be used to prepay usage over a period of time.

• Metered tickets can be shared across multiple rights, so that the rights share a single clock.

Digital tickets are implemented as encrypted computer files kept in trusted storage. Repositories treat digital tickets much like digital works, in that digital tickets have rights attached to them and these rights are used to govern copying, transferring, and other uses. A digital ticket is punched when a digital ticket agent "plays" the ticket. In the typical and simplest case, playing a digital ticket involves recording its use in the billing data and marking it as punched.

More sophisticated kind of digital tickets are possible. For example, some digital tickets can be "metered tickets" which keep track of the amount of time over which they are used. In this case, each time that the ticket is used, the digital ticket agent records on the ticket the time that passes when a right is being exercised. The ticket is exhausted when the time runs out. More than one right can be associated with a given metered ticket. In this case, the multiple rights share a clock. Metered tickets are also useful when the time that rights will be used is paid ahead of time, instead of being logged while the right is exercised. The internal state of tickets, including metering information, is part of the ticket creation process and not part of the language for describing rights that use such tickets. See the section on tickets and digital certificates.

If a ticket has Copy and Transfer rights, copies can be made (possibly for a fee) for another user. If a ticket has been used before it is copied, it must be refreshed before it is copied.

Digital tickets are accessible only to the certified accounting routines of the trusted system. Because they are tokens for payment, tickets must be kept in trusted storage on trusted and semi-trusted systems. For certain low-security repositories, tickets can be accessed from remote repositories of adequate security. Software-only trusted systems can still use digital tickets, but their security is necessarily less.

<Play>

</Ticket></Fee>

</Play>

<Play>

</Account>

</Monetary></Fee>

</Play>

In this example, there are two play rights. The first one just requires a ticket. The second example requires no ticket, but costs a dollar per hour.

2.4.3 Per Use and Metered Fees

Regular fee specifications are the basic forms of monetary arrangements. For each fee, specifications can include a fee type, optional minimum and maximum price specifications over the life of this copy of the work, and the account to be charged (or credited to the user as an incentive).

<!ELEMENT Monetary ((PerUse | MeteredFee | BestPriceUnder | CallForPrice | Markup),

Min?,

Max?,

Account)>

<!ELEMENT PerUse (Currency?)>

<!ATTLIST PerUse value CDATA #REQUIRED>

<!ELEMENT MeteredFee (Rate, Per, By?)>

<!ELEMENT Rate (Currency?)>

<!ATTLIST Rate value CDATA #REQUIRED>

<!ELEMENT Per EMPTY>

<!ATTLIST Per %interval;>

<!ELEMENT By EMPTY>

<!ATTLIST By %interval;>

<!ELEMENT BestPriceUnder (Currency?)>

<!ATTLIST BestPriceUnder value CDATA #REQUIRED>

<!ELEMENT CallForPrice EMPTY>

<!ATTLIST CallForPrice dealer-id CDATA #REQUIRED>

<!ELEMENT Min (Rate, Per)>

<!ELEMENT Max (Rate, Per)>

The optional minimum price specification indicates the minimum price to be paid per time unit if the right is exercised at all. The optional maximum price specification refers to the maximum price to be paid per time unit if the right is exercised at all. When both a maximum and minimum price specification are given, the maximum price specification dominates.

A Per-Use fee is a simple fee charged every time that a right is exercised. Here are some examples of per-use fees.

<Play>

</Account>

</Monetary></Fee>

</Play>

<Play>

</Account>

</Monetary></Fee>

</Play>

In this example, the user has three different per use options for playing the digital work. To exercise the first right, the cost is simply fifty cents per use. To exercise the second right, the user pays $15 the first time he plays the work and all subsequent plays are free. This is arranged in the language by specifying a $15.00 per use fee together with a lifetime maximum fee of $15. This kind of billing arrangement can be used with consumer-based distribution schemes based on pay-for-play rather than pay-for-copy.

MeteredFee specify a fee charged by the hour, or more generally, a fee charged per given units of time in use. Metered fees only make sense for uses whose value depends on time. Thus, the MeteredFee specification is only valid in conjunction with the Play right.

The Per portion of the specification indicates the units of time over which the rate is charged. The optional By field indicates the resolution at which billing is computed, that is, whether it is computed to the nearest day, minute, or second. If the By element is not given, it is assumed to be the same as the Per field.

For example, a per year charge is figured over a calendar year, starting at the time the work is used. For example, suppose that a user is using a work charged at $365 per year. He starts on December 31, 1996 and ends on January 1, 1997. Assume that the duration of use is approximately one day and that the By field is one day or less. With these assumptions, the fee for use would be about one dollar. If the By: field is set to a year, then the fee would be about $365, although the user would not be charged more for exercising the right further during 1997.

<Play>

</Monetary></Fee>

</Play>

<Play>

</MeteredFee>

</Monetary></Fee>

</Play>

Here are two examples of metering both with a rate of fifty cents per hour. Suppose that someone plays a work for 70 minutes. In the first example, the user is charged $1. The metering counts how many of the intervals ("two 1-hour ticks") are started. As soon as the user plays the work past the first hour, he is charged for two hours. In the second example, the By field is specified to be one second. In this case, the user is only charged for the portion of the second hour that he uses computed to the nearest second. Rounding up to the nearest second, he would be charged about $.59 for using the work for 70 minutes.

The following example combines a metered rate with a minimum fee. To exercise the right, the user is charged a dollar per hour with a minimum fee of $2 per day but a maximum of $15 per year.

<Play>

</Account>

</Monetary></Fee>

</Play>

Another useful billing variation is to have a fixed fee for unlimited use of a work over a fixed period of time. Restated, the user should be able to exercise the right as many times as desired during a fixed period for an overall fixed fee. This arrangement can be specified by a combination of time specifications and fee specifications. The example shows two ways to grant the right to play a work as often as desired during any contiguous month any time up to 2010. The Interval time specification says that the month starts when the work is first played. The MeteredFee specification and PerUse specifications establish the rate. In both examples, the Max specification assures that the user will not be charged more than $10 during the month for exercising the right.

<Play>

</Monetary></Fee>

</Play>

<Play>

</Monetary></Fee>

</Play>

2.4.4 Best-Price Fees

Best-Price is a fee that can be dynamic and is determined when the account is settled. It is used to accommodate special deals, rebates, and pricing that depends on information that is not available to the trusted repository at the time the usage right is exercised, but without communicating with a dealer before the purchase is authorized. A Best-Price specification limits the risk to the user by naming a maximum amount that the exercising of the right will cost. This is the amount that is tentatively charged to the account. However, when the transaction is ultimately reconciled, any excess amount charged will be returned to the user/copy-owner in a separate transaction. In the example, the is charged $5 to play the work, but will get a rebate if the price has gone down.

<Play>

</Monetary></Fee>

</Play>

Call-For-Price is similar to Best-Price in that it is intended to accommodate cases where prices are dynamic. However, unlike Best-Price, communication with a dealer to determine the price is required before the purchase is authorized; the transaction cannot be completed if the trusted repository is unable to communicate with the dealer.

<Play>

</Monetary></Fee>

</Play>

2.4.5 Markup Fees

Markup fees are fees that are computed as a percentage of other fees. For example, a distributor may want to add a flat ten percent overhead for selling copies of a digital work, or a government may want to tax sales of a digital works.

<!ELEMENT Markup EMPTY>

<!ATTLIST Markup percentage CDATA #REQUIRED>

Markup fees are specified in conjunction with composite works. In the following example, the Royal Tax Collector of Oz has created a work specification, which can be added to the specifications of all digital works sold in Oz. This specification adds a one percent tax every time a copy right is exercised in the embedded digital work. It does not tax the exercising of any other right.

<Work>

<Description>"Oz Export Control"</Description>

</Certificate></Owner>

<Copy>

<Fee>

</Account>

</Fee>

</Copy>

</RightsList>

</RightsGroup>

</Work>

The minimum fee specification within the Markup specification assures that a minimum tax of five cents will be collected to make copies even if the work has no publisher-set fee for copying.

2.5. Specifying Access Controls

Although one of the main advantages of digital works is the potential for broad and inexpensive distribution, it is sometimes important to limit the distribution of particular digital works. For example, a company using digital documents to coordinate distributed work teams may want to limit distribution to certain employees in order to protect corporate or trade secrets. A publisher of an electronic journal may want to assure that copies of a work are only available to subscribers or subscribing institutions. A public school may want to limit access by students to documents that are age appropriate or which reflect certain community values. In these examples, limiting distribution is different from making sure that people have paid for works that they use. Access specifications for authorization enable non-monetary criteria to govern the exercise of usage rights.

In addition to the requirement to authorize distribution of works to particular sets of people, there is a requirement to limit distribution of works to particular repositories. Repositories will be created by different vendors for different purposes and will have different kinds of security arrangements. Creators of digital works need to be able to specify the required levels of security. When two repositories establish a communications link, part of the process is to mutually determine levels of security.

The approach for both authorization and security is the controlled distribution of digital certificates or digital licenses. A digital license is analogous to a driver’s license in that the right to drive a car is supposed to be governed by whether a person is qualified. The operational test that a person has passed a driver’s test is possession of a license. The operational test that a repository or owner is qualified is roughly possession of a license, where the license is held in secure storage. A preferred variation on simple "possession of the license" is to have a challenge/response protocol in which the user’s system proves that it is the bonafide holder of the license, based on the use of their private key. (The particulars of the protocol are outside the scope of this document.) Digital licenses are themselves digital works, have provisions for detecting tampering, and may be held in trusted storage on repositories.

The digital property language addresses security concerns by recognizing that different digital platforms can have different levels of security. When two repositories communicate, the first step of their registration process includes a challenge/response protocol during which they determine each other’s level of security. The level of security of a repository is established by a certification process, which assigns a repository a non-transferable digital certificate indicating its security level.

The design goals for authorization specifications in the digital property language are:

• It should be possible to specify different authorization requirements for different rights on a work.

• Digital licenses should be issuable potentially by any registered organization. It should be possible to determine the issuer from the license itself.

• Digital licenses for repository operators should be issuable to persons and should become visible to transactions when the authorized person logs onto the repository.

• Digital licenses for repositories should be issuable to repositories by certifying organizations. These licenses are accessible when anyone uses the repository.

• Digital licenses should have expiration dates.

• Distribution of digital licenses should be reliably controllable. A license issuer can predetermine the conditions under which licenses can be created or transferred across repositories.

• For transactions involving two repositories, it should be possible to specify different authorization requirements for each repository.

• It should be possible to specify authorizations which require communication or computation in order to complete a transaction.

In the digital property language, requirements for authorization are indicated by Access: specifications. The particular design goals for security class specifications are given later.

<!ELEMENT Access (Security*, User?, Source?, Destination?)>

<!ELEMENT User (Any | Certificate+)>

<!ELEMENT Any (Certificate+)>

<!ELEMENT Source (Any | Certificate+)>

<!ELEMENT Destination (Any | Certificate+)>

<!ELEMENT Certificate (Authority, PropertyPair*)>

<!ELEMENT PropertyPair EMPTY>

<!ATTLIST PropertyPair name CDATA #REQUIRED

value CDATA #REQUIRED>

Access specifications include security class specifications, user authorization specifications, source authorization specifications, and destination authorization specifications.

2.5.1 Digital Licenses (Certificates)

We use the terms authorizations, certificates, and digital licenses interchangably to refer to digital objects, signed by a known digital authority, that attest that certain persons or repositories have certain properties. For example, an identity certificate issued to a person might contain certain identifying address, employment, age, club membership, or citizenship information, as well as a public key issued to the person. A certificate issued to a repository might contain information about its serial number, its country of registration, it security classification, its registered owner.

User authorization specifications refer to authorizations associated with a person requesting a transaction on a repository. A repository must be able access separate sets of authorizations associated with each person who uses it. In some systems, this separation of authorizations would be accomplished by having the authorizations kept on a repository card that a user plugs into the file repository in order to use it. In other implementations, the certificates for different people may be kept on the repository but require that the user be logged in before they be activated. In general, authorizations become available when the associated person logs in and satisfies a proof of identity protocol, presuming that they have not expired.

Source specifications list certificates that must be on the same repository as the digital work. These certificates become accessible whenever anyone logs onto the repository. Destination specifications list certificates on the other repository in a transaction, such as the repository intended to receive a digital work.

When a digital license is used, it is "played" by the generic digital license server which is part of the software of a repository. The digital license server is a certified program, whose validity can be assured by various means. A license itself may specify that a special purpose license server may be needed, either on the repository or accessed remotely.

<Play>

</Monetary></Fee>

</Play>

<Play>

</Certificate></User></Access>

</Play>

<Play>

</Certificate></Source></Access>

</Play>

In the example, the digital work has three Play rights. To exercise the first Play right requires no particular authorization, but has a per use fee of fifteen dollars. To exercise the second Play right requires no fee, but requires the user to have a license issued by Jones Publishers as a movie distributor. To exercise the third right requires no fee but requires a site license on the repository.

The next three examples show source and destination specifications. Destination specifications are relevant in transaction involving two repositories, such as a Transfer transaction that moves a digital work from a source repository to a destination repository. A destination specification describes certificates that must be displayed by the destination repository. A source specification describes certificates that must be displayed by the source repository.

<Print>

</Certificate></Destination></Access>

</Print>

<Copy>

</Certificate></Source>

</Certificate></Destination>

</Access>

</Copy>

An authorization specification can include more than one certificate. The Copy right in this example can be exercised by a user that has either a distributor license or a customer-class-1 license issued by Jones publishers.

<Copy>

</Certificate>

</Certificate>

</Any></User></Access>

</Copy>

2.5.2 Security Classes

By using certificates to indicate specific system properties, it is possible to be arbitrarily precise in characterizing requirements on a transaction for a trusted system. Any particular fact to be tested can be represented in terms of a valid digital certificate that must be presented by a system.

A disadvantage of specifications that can only test for the presence or absence of particular digital certificates is that there is no easy way to specify that a publisher wants a system that is "at least this secure". From a practical perspective, there may be many ways to make a system secure enough for a publisher, and the number of ways to achieve security changes over time. New kinds of systems suitable for holding a work can appear after a digital work is published. This creates a need for a way to specify security such that given two specifications, A and B, it is possible to ask and answer the question "Does specification A describe a requirement that is at least as secure as specification B?" Facilitating such statements and comparisons is the purpose of the security classes part of the digital property rights language.

The design goals for security class specifications in the digital property language are:

• It should be possible to specify different security class requirements for different rights.

• Given two security class specifications, it should be possible to determine their ranking in a partial ordering. Restated, it should be possible to determine whether specificaton A is at least as secure as specification B.

• The criteria for describing security provisions should admit the use of multiple dimensions, such as phycal security, communications security, defenses against viruses, method for identity testing, and so on.

• It should be possible to add new dimensions for security over time, that is, the language of dimensions should be extensible.

• Claims that a system has particular features used in determining security should be backed by digital certificates.

The basic idea of security class specifications is a kiwiet diagram. In this diagram, there is a central point and multiple axes, each of which is a numeric scale representing some dimension. A security specification is esssentially a vector, giving a numeric value for a subset of the axes. Preferably, it gives a numeric value for all of the axes, but in the case that some axis is not mentioned, a value of zero for that axis is assumed. The higher the number on an axis, the greater the security claimed. The accompanying diagram gives an example with four different specifications overlayed on the figure, each portrayed in a different color. One specification A, is strictly greater than another B, if the position specified on each axis for A is greater than the specification on the corresponding axis for B. Graphically, one specification exceeds or meets another if it entirely encloses it in the diagram, that is, specification A exceeds specification B if the polygon for A creates an outer boundary that completely contains the polygon for B.

In the accompanying figure, the three polygons A, B, and C correspond to three specifications. Specification A is greater than specification B because it exceeds it on all axes. Specification A is not greater than specification C, because C is greater than A on the biometrics axis. Similarly, C is not greater than A, because A is greater than C on the physical security axis.

<!ELEMENT Security EMPTY>

<!ATTLIST Security name CDATA #REQUIRED

value CDATA #REQUIRED>

Here is an example of a security class specification. It gives the required levels for four security dimensions. Values required for other dimensions default to zero.

</Access></Play>

2.6 Specifying Watermark Information

The term watermark historically refers to a translucent design impressed on paper during manufacture which is visible when the paper is held to the light. Because watermarks are impressed using combinations of water, heat, and pressure, they are not easy to add or alter outside of the paper factory. Watermarks are used in making letterheads and are intended to show that a document is official.

The term watermark is now used to cover a wide range of technologies for marking rendered works, including text, digital pictures, and digital audio. Some watermarks are noticeable to people and some are hidden. In some kinds of watermarks, the embedded information is human readable, but in other kinds the information can only be read by computers.

The term fingerprint is sometimes used in contrast with watermarks, to refer to marks that carry information about the end user or rendering event rather than the document or publisher. These marks are called "fingerprints" because they can be used to trace the source of a copy back to a person or computer that rendered the original. In contrast, the term watermark is often used to refer to marks that carry information to identify the work or publisher.

The same technologies and kinds of marks, e.g. glyph boxes, can be used to carry both kinds of information. In practice, it is not only possible but often desirable and convenient to combine both kinds of information — for watermarks and fingerprints — in a single mark. For simplicity in this document, we use the term watermark generally to refer to any marking technique for embedding information, whether it is about the digital work itself or the rendering event.

Different kinds of watermarks have different capacities for embedding data. For example, glyph boxes can be added to a printout of a document. They are capable of robustly encoding about 300 bytes per square inch on 300 dpi laser printers. With data compression, more information can be encoded in the same space.

Different kinds of watermarks are suitable for different kinds of works and media. For example, different techniques are used for watermarking music, movies, books, and high resolution photographs. For example, watermarks for music can embed data in the digital signal that are inaudible to the human ear when the music is played. The digital representations for different kinds of work -- e.g. for music, video, and text -- are varied and constantly evolving.

The following are design goals for watermark capabilities in DPRL:

• Publishers can specify that watermarks embed information known when a work is published (e.g. title and author) as well as information known only when a work is rendered (e.g. user name or printer name).

• The specification of what information is to be embedded in a watermark is specified in DPRL statements.

• Media-dependent specifications of a watermark, such as the shape and location of a glyph box or the parameters of an acoustic watermark, are not expressed in DPRL. These are expressed within the digital contents of a work or are implied by the type of rendering device. (This separation of responsibility for representation is intended to allow digital content representations and DPRL to evolve independently.)

• The specification of what information is to be embedded in a watermark is separate from the specification of the type of watermark.

• The type of watermark used is implied by the type of the printer or player.

Using DPRL, a publisher requests what information is to be expressed in a watermark. Since watermarks may have a limited capacity to embed information, it is possible for a publisher to request more information to be included in a watermark than can fit. The standard policy for rendering devices is to truncate the information expressed in the watermark when the capacity limit is reached. This means that the publisher can choose to express the most important information first. To the extent possible, one function of a Rights Editor is to inform a publisher of cases where information will be truncated.

In the case where more than one watermark appears in a work (or on a page in the case of trusted printing), then the information expressed in each watermark begins at the beginning. In a multimedia work the same information may be encoded by completely different techniques in pictures, music, and linked text as the work is played or printed. In this example, DPRL expresses the information to be encoded and the players and printers embed it in different digital representations and renderings.

2.6.1 Watermark Strings, Tokens, and Objects

The following table gives the syntax for watermark specification in DPRL.

<!ELEMENT Watermark ((Watermark-Str |Watermark-Tokens | Watermark-Object)*)>

<!ELEMENT Watermark-Str EMPTY>

<!ATTLIST Watermark-Str string CDATA #REQUIRED>

<!ELEMENT Watermark-Tokens EMPTY>

<!ATTLIST Watermark-Tokens all-rights (true|false) "false"

render-rights (true|false) "false"

user-name (true|false) "false"

user-id (true|false) "false"

user-location (true|false) "false"

institution-name (true|false) "false"

institution-id (true|false) "false"

institution-location (true|false) "false"

render-name (true|false) "false"

render-id (true|false) "false"

render-location (true|false) "false"

render-time (true|false) "false"

copy-number (true|false) "false">

<!ELEMENT Watermark-Object (WorkId)>

Thus, a watermark specification is a list of sources of information. The elements of the list can be strings of text known at the time the work is published (Watermark-Str), they can be lists of tokens signifying "fingerprint" informtion known at the time a work is rendered (Watermark-Token), or they can be digital objects whose bits are to be encoded (Watermark-Object). The objects are assumed to present in the contents of the digital work being rendered, specified by WorkIds in the DPRL specification.

The watermark tokens when specified will take a value "true". The meanings for the various watermark tokens ("fingerprint information")are given in the following:

all-rights Listing of all rights associated with the work, expressed in DPRL.

render-rights Listing of all render rights associated with the work, expressed in DPRL.

user-name The user’s name.

user-id The user’s id, associated with his identity certificate.

user-location The user’s location, associated with his identity certificate.

institution-name The institution’s name that owns the rendering service or rendering device.

institution-id The institutions’s id, associated with its identity certificate.

institution-location The institution’s location, associated with its identity certificate.

render-name The name of the rendering device (e.g. the printer name) that rendered the copy.

render-id The rendering device’s id, associated with its identity certificate.

render-location The rendering device’s location, associated with its identity certificate.

render-time The time and date that the work was rendered.

copy-number The number of copies of the work.

2.6.2 Examples of Watermark Specifications

In the first example, there are two rendering rights on the work, a Play right and a Print right. Only the Print right specifies watermarking. The print right specifies a particular kind of trusted printer, so the type of watermarking is determined by the type of trusted printer.

The information to be saved in the watermark includes an initial string in which the title, author, and a copyright notice are given. The next part of the information for the watermark includes the user’s id, the location of his institution, the name and location of the printer, and the time that the work was printed.

<Work>

</Certificate></Owner>

</Account>

</BundleFee>

</Access>

</Bundle>

<Print>

</Certificate></Printer>

<Watermark-Str string="Title: 'Zeke Zack - The Moby Dog Story'

<Watermark-Tokens user-id="true" institution-location="true"

render-name="true" render-location="true"

render-time="true"/>

</Watermark>

</Print>

</RightsList>

</RightsGroup>

</Work>

The following is a second example of a watermark specification. For simplicity, it shows only the Print right. In this example, there are two strings and one set of tokens containing watermark information.

<Print>

</Certificate></Printer>

<Watermark-Str string="Title: 'Zeke Zack - The Moby Dog Story'

<Watermark-Tokens user-id="true" institution-location="true"

render-name="true" render-location="true"

render-time="true"/>

<Watermark-Str string="Support Independent Authors!

Do not Photocopy this document!"/>

</Watermark>

</Print>

The next example is for a Play right. In this case, an acoustic watermark is used. This example differs from the previous one in that the watermark tokens include the DPRL text for the render rights. Furthermore, a watermark-object is included which means that the bits of that object representation are sent to the watermarking system. One possible effect of this on an acoustic watermark, depending on the technology, is to make the "Moby Dog Jingle" play at a very low volume at some point in the music.

<Play>

</Certificate></Player>

<Watermark-Str string="Title: Moby Dog Howling Song

<Watermark-Tokens user-id="true" institution-location="true" render-rights="true"/>

<Watermark-Object>

</Watermark-Object>

</Watermark>

</Play>

2.7 Bundle Secifications

In DPRL, each right can fully and separately specify the time limits, fees, access conditions, and watermark information particular for that right. This provides flexibility, but it also can lead to redundancy in the specification for those cases where many rights share the same sub-specifications. To simplify the expression of rights for those cases where rights share common terms and conditions, DPRL provides bundle specifications. There can be at most one bundle specification in a rights group. For clarity, it is preferred that bundle specifications precede individual right specifications in a rights group. Programs that generate DPRL should follow this convention. The syntax for a bundle specification is as follows:

<!ELEMENT Bundle (Comment?, Time?, Access?, BundleFee?, Watermark?)>

<!ELEMENT BundleFee (Ticket | BundleMonetary)>

<!ELEMENT BundleMonetary ((PerUse | MeteredFee | BestPriceUnder | CallForPrice | Markup)?,

Min?,

Max?,

Account)>

2.7.1 Specifying Time Limits Inside Bundles

DPRL makes it possible to give separate and distinct time specifications for every right associated with a work. However, in many cases, the time specifications are the same for all of the rights in a rights group. To avoid repeating the specification for every right, a time specification can be expressed once within a bundle specification. In this case, the meaning of the time specification is the same as it were repeated for every right in the right group.

The following example is perhaps typical of the way that time limits can be expressed within bundle specifications. It enables the bearer to exercise any of the rights for two hours any time up to May 1, 1998, assuming that the trusted system has a high enough security class.

<Comment> "Trial rights. Anyone can use the work for two hours"</Comment>

<Time>

</Time>

</Access>

</Bundle>

</RightsList>

</RightsGroup>

When a time specification is given in a bundle and a further time specification is given for some right in the rights group, the specification given for the individual right dominates. In that case, the time-specification given in the bundle is specialized by the time-specification in the right.

The next example shows how a time specification can be given in a bundle, and specialized in a right. In this case, an expiration period is given in the bundle causing all rights to expire in 1998. Furthermore, the Play right specializes this specification by indicating that the work can be played for up to two hours in this period.

<Comment>" Expires 1998."</Comment>

</Access>

</Bundle>

<Play>

</Play>

</RightsList>

</RightsGroup>

2.7.2 Specifying Fees Inside Bundles

DPRL makes it possible to specify a separate fee for each individual right associated with a digital work. Sometimes it is convenient to express fee information for an entire set of rights bundle specification. In the most typical usage, fee specifications inside bundles are used to indicate parts of a fee specification that are common to all of the rights in the rights group. In the following example, the account number for all payments is given in the bundle-spec.

<Comment>"All Royalties go to Jones"</Comment>

</Account>

</BundleMonetary></BundleFee></Bundle>

</Monetary></Fee></Print>

</Monetary></Fee></Play>

</RightsList>

</RightsGroup>

In the next example, a metered ticket is used to give a two hour maximum usage across all kinds of players.

</Ticket></BundleFee>

</Bundle>

</Certificate></Player></Play>

</Certificate></Player></Play>

</RightsList>

</RightsGroup>

Tickets can be used across different kinds of rights. Suppose for example that a publisher has an every day price with separate fees to print or to view a document. In every day prices, it costs four dollars to print a document and ten cents an hour to view it. However, they want to offer a special rate for prepaid customers where the four dollars gives the right to print it once and also the right to view it for several hours for free.

This combination is accomplished by having two rights groups. The first rights group ("Every Day Prices") establishes the pay as you go regular rates, and the second rights group ("PrintNView Deal") ties printing and playing to the use of a prepaid digital ticket delivered with the digital work which costs four dollars and which authorizes printing once and unlimited viewing.

</Access>

</Account></BundleMonetary></BundleFee>

</Bundle>

<Play>

</MeteredFee></Monetary></Fee>

</Play>

<Print>

</Certificate></Printer>

</Print>

</RightsList>

</RightsGroup>

</Access>

</Ticket></BundleFee>

</Bundle>

</Certificate></Printer></Print>

</RightsList>

</RightsGroup>

2.7.3 Specifying Access Inside Bundles

DPRL makes it possible to give separate and distinct access specifications for every right associated with a work. In many cases, the access specifications are the same for all rights in a rights group, or they may have many elements in common. To simplify specifications for these common cases, an access specification can be included within a bundle specification. In this case, the meaning is the same as if the same time specification were repeated for every right in the right group.

When an access specification is given in a bundle specification and also another access specification is given for some right in the rights group, the specification given for the individual right dominates.

In that case, the time-specification given in the bundle is ignored for that right in the interpretation process. In the following example, all of the rights require security class 3 or greater.

</Access></Bundle>

</RightsList>

</RightsGroup>

2.7.4 Specifying Watermark Information Inside Bundles

DPRL makes it possible to give separate and distinct specifications for watermark information for every Print or Play right in a digital work. In many cases, the watermark information is the same for all Print and Play rights in a group. To simplify specifications for these common cases, a watermark specification can be included within a bundle specification. In this case, the meaning is the same as if the same watermark specification were repeated for every Print and Play right in the right group.

<Work>

</Certificate></Owner>

</Access>

</Account></BundleMonetary></BundleFee>

<Watermark-Tokens user-id="true" institution-location="true"

render-name="true" render-location="true"

render-time="true"/>

</Watermark>

</Bundle>

<Copy>

</Copy>

<Print>

</Certificate></Printer>

</Ticket></Fee>

</Print>

<Print>

</Certificate></Printer>

</Print>

</RightsList>

</RightsGroup>

</Work>

In this example, the rights group contains a bundle with fee, access, and watermark specifications. Watermark specifications apply to all render right statements in the rights group. In the example, they apply to the Play right and to both Print rights.

When a watermark specification is given for a printer or player that does not support watermarks, it is ignored. In this example, if the player does not embed watermarks, the specification will be effective only for the two rights involving trusted printers.

APPENDIX A. LEXICAL CONVENTIONS

This section explains conventions for describing elements of the digital property language.

Blanks, horizontal and vertical tabs, new lines, form feeds, and comments are referred to as "white space" and serve to separate tokens. White space or punctuation is required to separate adjacent identifiers, keywords and constants. The following characters are used as punctuation:

< > " "

No distinction is made between left and right double quotes. There are three kinds of tokens: keywords, constants and identifiers.

Keywords

The following are keywords in the digital property language. This list does not include the names of foreign currencies or watermark tokens, which are listed separately. It also does not include property names that may become standardized for certain classes of digital certificates. The XML keywords are also not mentioned in this

Access

Account

AccountFrom

AccountTo

Any

Authority

Backup

BackupCopyRights

BestPriceUnder

Bundle

BundleFee

BundleMonetary

CallForPrice

Certificate

Comment

Contents

Copies

Copy

Currency

Delete

Description

Destination

Directory

Edit

Editor

Embed

Export

Extract

Fee

Folder

From

House

Install

Interval

Loan

Markup

Max

Metered

MeteredFee

Min

Monetary

NextCopyRights

Owner

Parts

Per

PerUse

Play

Player

Printer

PropertyPair

Rate

ReferencedRightsGroup

RemainingRights

Repository

Restore

RightsGroup

RightsList

RightsToAdd

RightsToDelete

RightsVersion

Security

Source

Ticket

Time

Transfer

Type

Uninstall

Until

User

Verifier

Verify

Watermark

Watermark-Object

Watermark-Str

Watermark-Tokens

Work

WorkId

Constants

In XML literal, string, integer, floating constants are all considered to be character data(CDATA). It is upto the parser to check for the validity of the data.

Character data is any string of characters which does not contain the start delimiter "<" enclosed within double quotes("). A character is an atomic unit of text as specified by ISO/IEC10646. Legal characters are tab, carriage return, line feed, and the leagal graphic characters of Unicode and ISO/IEC 10646.

Identifiers

Identifiers are the attributes values in elements. All characters are significant, and upper- and lower-case characters are distinct. The following are the name of identifiers in the digital property language.

account-id

all-rights

authority-id

clearing-house-id

copy-count

copy-number

days

dealer-id

from

group-name

hours

hrs

institution-id

institution-location

institution-name

interval

iso-currency-code

min

minutes

moment

months

name

percentage

render-id

render-location

render-name

render-rights

render-time

sec

seconds

string

ticket-id

user-id

user-location

user-name

value

work-id

years

yyyy

Explained below is the meaning of some of the key identifiers of DPRL.

An account-id is an identifier for a specific account at a specific bank or other financial institution from which fees will be collected, or to which incentives will be paid.

An authority-id is an identifier for an organization that issues digital certificates.

A clearing-house-id is an identifier for a financial clearing house, such as a bank or credit card consortium.

A ticket-id is an identifier of a digital certificate that is used to grant permission for a one-time transaction on a particular work.

A work-id is an identifier of a digital work.

These identifiers are always contained in digital certificates, signed by an issuer. Conventions and procedures for establishing meaning for these id’s is beyond the scope of this manual.

Currency Codes

For compatibility with other standards, DPRL uses the ISO 4217 three-character currency code. In most cases, the ISO 4217 currency code is composed of the country’s two-character ISO 3166 country code plus a one-character currency designator. More details are given on the ISO On-line home page.

ADP Andorran Peseta KRW (South) Korean Won

AED United Arab Emirates Dirham KWD Kuwaiti Dinar

AFA Afghanistan Afghani KYD Cayman Islands Dollar

ALL Albanian Lek LAK Lao Kip

ANG Netherlands Antillian Guilder LBP Lebanese Pound

AOK Angolan Kwanza LKR Sri Lanka Rupee

ARA Argentinian Austral LRD Liberian Dollar

ATS Austrian Schilling LSL Lesotho Loti

AUD Australian Dollar LUF Luxembourg Franc

AWG Aruban Florin LYD Libyan Dinar

BBD Barbados Dollar MAD Moroccan Dirham

BDT Bangladeshi Taka MGF Malagasy Franc

BEF Belgian Franc MNT Mongolian Tugrik

BGL Bulgarian Lev MOP Macau Pataca

BHD Bahraini Dinar MRO Mauritanian Ouguiya

BIF Burundi Franc MTL Maltese Lira

BMD Bermudian Dollar MUR Mauritius Rupee

BND Brunei Dollar MVR Maldive Rufiyaa

BOB Bolivian Boliviano MWK Malawi Kwacha

BRC Brazilian Cruzeiro MXP Mexican Peso

BSD Bahamian Dollar MYR Malaysian Ringgit

BTN Bhutan Ngultrum MZM Mozambique Metical

BUK Burma Kyat NGN Nigerian Naira

BWP Botswanian Pula NIC Nicaraguan Cordoba

BZD Belize Dollar NLG Dutch Guilder

CAD Canadian Dollar NOK Norwegian Kroner

CHF Swiss Franc NPR Nepalese Rupee

CLF Chilean Unidades de Fomento NZD New Zealand Dollar

CLP Chilean Peso OMR Omani Rial

CNY Yuan (Chinese) Renminbi PAB Panamanian Balboa

COP Colombian Peso PEI Peruvian Inti

CRC Costa Rican Colon PGK Papua New Guinea Kina

CSK Czech Koruna PHP Philippine Peso

CUP Cuban Peso PKR Pakistan Rupee

CVE Cape Verde Escudo PLZ Polish Zloty

CYP Cyprus Pound PTE Portuguese Escudo

DDM East German Mark (DDR) PYG Paraguay Guarani

DEM Deutsche Mark QAR Qatari Rial

DJF Djibouti Franc ROL Romanian Leu

DKK Danish Krone RWF Rwanda Franc

DOP Dominican Peso SAR Saudi Arabian Riyal

Algerian Dinar SBD Solomon Islands Dollar

ECS Ecuador Sucre SCR Seychelles Rupee

EGP Egyptian Pound SDP Sudanese Pound

ESP Spanish Peseta SEK Swedish Krona

ETB Ethiopian Birr SGD Singapore Dollar

FIM Finnish Markka SHP St. Helena Pound

FJD Fiji Dollar SLL Sierra Leone Leone

FKP Falkland Islands Pound SOS Somali Schilling

FRF French Franc SRG Suriname Guilder

GBP British Pound STD Sao Tome and Principe Dobra

GHC Ghanaian Cedi SUR USSR Rouble

GIP Gibraltar Pound SVC El Salvador Colon

GMD Gambian Dalasi SYP Syrian Potmd

GNF Guinea Franc SZL Swaziland Lilangeni

GRD Greek Drachma THB Thai Bhat

GTQ Guatemalan Quetzal TND Tunisian Dinar

GWP Guinea-Bissau Peso TOP Tongan Pa'anga

GYD Guyanan Dollar TPE East Timor Escudo

HKD Hong Kong Dollar TRL Turkish Lira

HNL Honduran Lempira TTD Trinidad and Tobago Dollar

HTG Haitian Gourde TWD Taiwan Dollar

HUF Hungarian Forint TZS Tanzanian Schilling

IDR Indonesian Rupiah UGS Uganda Shilling

IEP Irish Punt USD US Dollar

ILS Israeli Shekel UYP Uruguayan Peso

INR Indian Rupee VEB Venezualan Bolivar

IQD Iraqi Dinar VND Vietnamese Dong

IRR Iranian Rial VUV Vanuatu Vatu

ISK Iceland Krona WST Samoan Tala

ITL Italian Lira YDD Democratic Yemeni Dinar

JMD Jamaican Dollar YER Yemeni Rial

JOD Jordanian Dinar YUD New Yugoslavia Dinar

JPY Japanese Yen ZAR South African Rand

KES Kenyan Schilling ZMK Zambian Kwacha

KHR Kampuchean (Cambodian) Riel ZRZ Zaire Zaire

KMF Comoros Franc ZWD Zimbabwe Dollar

KPW North Korean Won

APPENDIX B. GRAMMAR FOR THE DIGITAL PROPERTY LANGUAGE

This section collects together the complete DTD for the digital property language.

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

<!ELEMENT Work (RightsVersion,

WorkId?,

Description?,

Owner?,

Parts?,

Contents?,

Copies?,

Comment?,

(RightsGroup | ReferencedRightsGroup)+

<!ELEMENT RightsVersion EMPTY>

<!ATTLIST RightsVersion version-id CDATA #REQUIRED>

<!ELEMENT WorkId EMPTY>

<!ATTLIST WorkId work-id CDATA #REQUIRED>

<!ELEMENT Description (#PCDATA)>

<!ELEMENT Owner (Certificate)>

<!ELEMENT Parts (WorkId+)>

<!ELEMENT Contents EMPTY>

<!ATTLIST Contents from CDATA #REQUIRED

to CDATA #REQUIRED>

<!ELEMENT Copies EMPTY>

<!ATTLIST Copies copy-count CDATA #IMPLIED>

<!ELEMENT Comment (#PCDATA)>

<!ELEMENT RightsGroup (Comment?, Bundle?, RightsList)>

<!ATTLIST RightsGroup group-name CDATA #REQUIRED>

<!ELEMENT ReferencedRightsGroup (Comment?, Bundle?, RightsList)>

<!ATTLIST ReferencedRightsGroup group-name CDATA #REQUIRED>

<!ELEMENT Bundle (Comment?, Time?, Access?, BundleFee?, Watermark?)>

<!ELEMENT RightsList ( (Copy | Transfer | Loan |

Play | Print | Export |

Edit | Extract | Embed |

Install | Uninstall)+