DAISY Digital Rights Management System

Version 2 Requirements

1. Summary

A list of requirements for a system to protect DAISY and ANSI/NISO Z39.86 digital talking books is presented.  These have been gathered and compiled by the Working Group on Digital Rights Management of the DAISY Consortium.  The requirements aim to describe a system that fairly balances the rights of end users with the protection requirements of copyright holders, publishers, and local copyright law and is minimally invasive.

2. Introduction

The DAISY Consortium wishes to create a standard Digital Rights Management (DRM) scheme for use with Digital Talking Book (DTB) standards in order to satisfy copyright holders and publishers that their works are being protected and to comply with copyright law.

Most entities distributing books for the blind and print disabled using the existing DTB standards are required by law to apply some sort of protection, up to and including stringent encryption and watermarking systems.  In any case, the copyright holders and publishers whose works are being distributed wish to see those works protected in a way that prevents their dissemination to unauthorized users.

At the same time, end-users of those works expect reasonable rights to the use of those publications.

The ideal DRM system, then, is one that is entirely transparent up to the limits of an end-user’s usage rights and does not allow those limits to be exceeded in any way.  Where those limits lie is the subject of considerable debate.

It is important to note that the function of a DRM system is to enforce those limits, not to set them, and it is in this spirit that the Working Group has approached the subject.  That is, we wish to create a system that is effectively, flexibly, and transparently able to implement policy without imposing limitations of its own.  The Working Group is committed to remaining neutral on the issue of which rights should be limited and which extended to an end user, except where those limits might restrict the legitimate use of assistive technologies.

3. Context

Per requirements 35 and 36, the DRM system under development applies to DTBs complying with the DAISY 2.02 and the ANSI/NISO Z39.86 (DAISY 3.0) DTB specifications. 

4. Scope

Other issues considered out of scope include: transport of materials, physical format, patron registration, copyright law, and issues surrounding item sales.

5. Roles

For the convenience of the reader, each requirement has been assigned to one or more user roles: (C)opyright holder, (D)istributor, (M)anufacturer, or (E)nd user.  By examining the assignments in the complete list of requirements an interested reader can quickly determine which requirements are applicable to his or her area of interest.

6. Requirements, by area

Each requirement has been assigned, where possible, to one of nine categories.  These are described below.  Some requirements are not assigned to a category.  Rejected requirements have not been categorized.

6.1 Authorization

This category contains requirements of the DRM system to allow playback of a DTB under access conditions set by the distributor.  Controllable parameters include user, machine, and date/time.  Machine-level authorizations are further broken down by manufacturer, class of machine (hardware or software), model, and version number.  All authorizations are optional and not mutually exclusive.

Users must be able to back up and copy their authorizations and remove them from machines but not to create their own authorizations.  Authorization to play a given DTB can travel with or separate from that DTB.

[4] A unique ID per copy within an agency can be assigned

Roles: C

Description: For agencies that desire to do so, a unique ID can be generated and assigned to each digital copy of a DTB.  In this way both on-demand copies and those that circulate can be tracked to an individual location or user.  Supports the Identification requirements.

[5] Playback can be restricted to authorized users only

Roles: C

Description: One of the basic functions of the DRM system.  Stated for completeness.

[13] Time-out of keys - limited time authorization - by duration and/or date

Roles: D

Description: Authorizations to play a book can expire, based on the time and date and/or the amount of time elapsed since the authorization was applied.  This requirement implies the existence of a clock on the playback device.  It is likely that such authorizations will be expected to fail completely on playback devices with no clock.

[15] Expiration of individual books

Roles: D

Description: The ability to play a DTB can expire regardless of authorization.  This requirement implies the existence of a clock on the playback device.  It is likely that such DTBs will be expected to fail to play on playback devices with no clock.

[16] User authorization certificate (or equivalent) is tamper-resistant

Roles: D

Description: Authorization certificates will be constructed in such a way as to be extremely difficult to alter without destroying their functionality.

[50] Support secure method of distribution of non-redistributable user authorization certificate

Roles: D

Description: The system should support a method of transporting standalone authorization certificates (separate from the player itself or any content).  It should not be necessary for any certifying agency to physically possess a player in order to authorize it.  Certificates should be assignable to individual users or players to prevent reuse.

[51] Supports multiple authorizations per player

Roles: D

Description: Players can be multiply authorized.  This allows for content from multiple agencies to be played.

[52] Can include authorization certificate along with content

Roles: D

Description: Authorization certificates can optionally be included along with DTB content. This will facilitate authorization for those distributors who wish to individually produce and authorize their DTBs.

[54] Playback of a set of books can be restricted to a specific set of users (set = one or more)

Roles: D

Description: Distributors should be able to authorize books to patrons in sets rather than one at a time.  This enables one-to-many, many-to-one, and many-to-many authorizations.

[77] Playback of a set of books can be restricted to a specific set of machines (set = one or more)

Roles: DC

Description: Distributors should be able to authorize books to machines in sets rather than one at a time.  This enables one-to-many, many-to-one, and many-to-many authorizations.

[62] Minimize impact of certificate distribution on distributor

Roles: D

Description: Authorizations should be simple to create and distribute accurately and quickly and with a minimum of human intervention if so desired.

[23] Supports national and international interlibrary loan

Roles: D

Description: No part of the DRM system should preclude interlibrary loan.

[72] No authorization is necessary to play an unprotected content type even if it coexists with a protected content type

Roles: DCE

Description: DTBs can contain both protected and unprotected content types (e.g. the text content of a DTB is protected but the audio content is not).  The presence of the protected content does not imply required authorization to play the unprotected content.

[80] Authorizations cannot be created or transferred by end users alone

Roles: DCE

Description: Patrons must not be able to create valid authorizations, nor should they be able to alter certificates to apply to other users or machines.

[81] Provides a mechanism which allows the legitimate transfer of a book from one user to another

Roles: DCE

Description: A DTB can be transferred from one user to another within the bounds of its authorization.

[85] Supports ability to authorize a book for the entire universe of players

Roles: DCE

Description: It should be possible to create a DTB that is protected (that is, unplayable by nonconforming media players) but carries an authorization allowing it to be played on any conforming player.

[78] Authorizations may differentiate among types of playback systems (e.g. class, model, version, manufacturer)

Roles: DM

Description: Authorizations can be made specific to these levels of granularity.  Required in the event that some players do not fully conform to the DRM specification.

[53] User must be able to reproduce authorization certificate

Roles: E

Description: Necessary so authorization certificates can be backed up and restored without the intervention of the authorizing entity.

[55] Books can be authorized for multiple devices

Roles: E

Description: Useful for authorizing books to a patron who wishes to play them on multiple playback systems.  May be redundant to [77].

[70] Certificates must be removable by the user

Roles: E

Description: User must be able to remove all authorizations from a player.  Useful when selling a purchased player or submitting one for service.

[74] Support variable complexity keys and codes

Roles: E

Description: This requirement refers to the keys used with authorizations, not the encryption schemes used for protecting the content itself.

[86] Supports the ability to produce an authorization that can only be processed for a limited time

Roles:

Description: Similar to [13], but refers to the time range during which an authorization can be applied rather than the time during which the content can be used.

6.2 Backward compatibility

Two requirements have been identified for this category, which covers compatibility with older players.

[58] Must not render players incompatible with version 1 of PDTB spec

Roles: D, E

Description: The existing (Version 1) specification for IPP can still be implemented on any player that also implements this version. 

[69] Protected books must fail gracefully when played in a legacy player

Role: E

Description: Allows older players (those which are not aware of this specification) to fail gracefully when presented with a book the DRM system protects.

6.3 Encryption

Encryption will be a fundamental component of the protection scheme.  Requirements in this area address the flexibility and strength of the set of ciphers available in this protection scheme. 

It is envisioned that a small set of ciphers for each content type (text, audio, image) will be selected as a part of the design process.  Each set should contain ciphers of varying complexity and one common (across content types) cipher will be identified.  All should be usable with lightweight hardware players.

Other requirements relate to mixing encrypted and unencrypted segments and ensuring the efficiency of DTB playback by a player handling encrypted content.

[24] Single cipher possible for all types of content

Roles: D

Description: The sets of ciphers chosen for each content type should have at least one common member.

[26] Fast enough for encryption on demand

Roles: D

Description: Some distributors may choose to create a uniquely protected copy of a DTB each time it is circulated.  This requirement asks that the chosen encryption schemes not add undue delay to that process by requiring excessive time to apply.

[29] Scalable encryption methods

Roles: D

Description: Encryption methods should, where possible, be scalable by using, for example, variable-length keys or a varying number of iterations in a repeatable step.

[25] Not all content types must be protected

Roles: DC

Description: It must be possible to leave some DTB content (chosen by content type) unprotected.

[28] Strong encryption for text

Roles: DC

Description: As text is usually seen as the most valuable content type, the encryption methods chosen for it must be especially strong while meeting all other requirements.

[37] Encryption algorithms must be industry standard

Roles: DC

[48] Different ciphers may be used on various content types

Roles: DC

Description: It is not required to encrypt all of a DTB’s content with the same cipher.

[49] Must allow for protection of partial content segments including non-markup only

Roles: DC

Description: The distributor should be able to choose which segments, within a content type, are to be encrypted.  This allows, for example, leaving an abstract or opening chapter of a text unencrypted for a reader to gauge interest or for use by an automated cataloging system.

Also, some content types may best be protected through a technique of partial encryption.  For example, for ease of navigation it may be desirable to encrypt only the body text of a text content segment while leaving its markup in the clear.  Some audio encodings can be partially encrypted allowing for very efficient decryption while still rendering the audio unintelligible.

[60] Each internal content type can be protected

Roles: DC

[39] Encryption algorithms must not preclude use of open-source components elsewhere in the system

Roles: M

Description: Some open-source software cannot, under its license, be mixed with closed-source software in a single product.  An effort should be made to choose encryption systems that do not preclude the use of open-source software elsewhere in the DRM system.

[64] Must allow efficient random access to content blocks for all linear content types

Roles: M

Description: As quick navigation is seen as an important requirement in a playback device, the encryption systems should allow the efficient random access that such navigation requires.

[66] Must not require player to extract content from aggregated files

Roles: M

Description: Chosen encryption schemes must not rely on any combination of a DTB’s component files being zipped, tarred, or otherwise combined together.

[76] Includes a limited number of available ciphers per content type

Roles: M

Description: The number of available ciphers per content type will be chosen to allow flexibility without placing an undue burden on device manufacturers.

[63] Facilitate efficient prefetch and decryption of child resources

Roles: ME

Description: DTBs may contain mixed content types with interlinked content.  Rendering becomes inefficient when links are encrypted along with the content in which they are embedded.  An effort should be made to avoid this kind of inefficiency.

6.4 Identification

Identification requirements pertain to the ability to trace content from the producer to the patron while maintaining the privacy rights of the patron.

[3] Allows implementation of watermarking of any content

Roles: C

Description: The DRM system should not preclude successful, stable watermarking or fingerprinting of any content.

[31] Supports traceability by distributor to individual level

Roles: C

Description: Some distributors may wish to watermark or fingerprint content in order to identify to whom a found copy of a DTB was circulated.  The DRM system must support this ability.

[32] Supports identification of own materials by originating distributor

Roles: C

Description: A distributor must be able to identify any circulated DTB as one they have distributed.

[33] Privacy of individual readers can be protected

Roles: E

Description: A circulated copy of a DTB should not contain information, encrypted or clear, than can by itself identify to whom the book was circulated.  If such information is included it must require a lookup at the originating agency in order to definitively identify a patron.

6.5 Player behavior

These are requirements imposed on conforming DTB players by the DRM system.  Because a player has the authority and ability to decrypt content it also has the responsibility to maintain protection of that content.  Such protection, however, cannot be allowed to preclude the use of assistive technologies.

[11] Cannot allow the production of a complete unprotected copy of the content

Roles: C

[42] Must not allow application to expose XML markup

Roles: C

Description: In no case should the XML markup underlying a DTB be exposed to the user in any way, even if protected by the export controls described in [44], [45], and [46].

[67] Each protected component file must remain independently protected outside of a conforming application

Roles: C

Description: Players extracting content from a DTB must not create any accessible files that are unprotected, even temporarily.

[40] Must allow rendering compatible with existing assistive technologies (screen readers, refreshable braille displays)

Roles: E

Description: Players should render DTB content in standard fashion such that assistive devices and software can be used without modification.

[57] Players must inform the user of authorization failures

Roles: E

Description: Given the requirement that the DRM system be as transparent as possible [8], normal operation will not require a patron to be concerned with the authorization process.  It is vital, then, that when a user is unable to access a DTB because of authorization failure the cause is clearly communicated to the user.

6.6 Rights

This section covers the usage rights of a patron and potential limitations of those rights needed to conform to copyright law.  Topics include excerpting, export, and user education.

[41] Should support limited excerpting of content

Roles: CE

Description: Although the very function of the DRM system is to limit a DTB’s use by unauthorized parties, the Working Group recognizes that some limited excerpting of a book should be allowed.  The DRM system must allow this, with limitations set by the distributor (see [45] and [46]).

[45] Distributor must be able to specify export limitations per book

Roles: DC

Description: A distributor can, when protecting a DTB, specify how much of the book (by percentage or other applicable units) can be exported in an unprotected fashion.

[46] Distributor must be able to specify export limitations by content type per book

Roles: DC

Description: Similar to [45], but fine-tunes export limitations to be specified for each content type (text, audio, image) within a DTB.

[18] Terms of use must be disclosed to user (education about rights, restrictions, penalties)

Roles: E

Description: The DRM system should contain an education component.  Patrons must understand what activities are allowed within a distribution system.

[56] Must allow user to make a copy of the protected DTB for personal use

Roles: E

Description: Users must be able to back up their DTBs.

6.7 Spec integration

The DRM system under discussion is required to work with DAISY 2.02 and ANSI/NISO Z39.86-format books.  The requirements in this area state the necessary extent of such compatibility.

[7] All book types can be protected

Roles: D

Description: “Book types” refers to the six types of DTB described in section 13, “Types of DTB” of the ANSI/NISO Z39.86-2002 specification.

[35] Any valid DAISY 2.02 book can be protected including multivolume books

Roles: D

Description: Also see [7].

[36] Any valid Z39.86 book can be protected including multivolume books

Roles: D

Description: Also see [7].

[87] No implementation of DRM shall depend upon a particular interpretation of 2.02 or Z39.86 (e.g. ncx v. spine)

Roles: DM

Description: The DRM system design shall depend only on the specifications and not interpretations or implementations of those specifications.

[88] Minimize impact of DRM system on DTB specs

Roles: DM

Description: The DRM system design should not make requirements of future versions of the DTB specification.

6.8 Trust model

This category covers limitations on the trust model used between players and trusted or untrusted programs and devices regarding the exposure of protected content.

[44] Must allow transfer of content to trusted devices

Roles: CE

Description: It is recognized that playback devices need to work with other devices and software in order for some patrons to access a DTB’s content.  For example, a blind reader may use a refreshable braille display or external text-to-speech processor to access textual content.  This requires the playback device to transfer content to those devices.

[47] Must support limitation of transfer of content to untrusted devices (e.g. clipboard)

Roles: CE

Description: See [44], [45] and [46].

6.9 Metarequirements

These are requirements that apply to the design specification itself rather than the DRM system it defines.

[1] Timeframe: Spec done end of 2005

Roles: D

Description: The Working Group has set December 2005 as a deadline for completion of the DRM system design specification.

[2] Spec is publishable as an open specification

Roles: DCEM

Description: The Working Group intends to eschew “security by obscurity” and will publish the DRM system design specification openly, implying that the system’s security is not inherent in its design or implementation but rather lies in the ciphers and watermarking systems it uses and in the secrecy of the keys chosen during use.

[84] Spec will be written such that a role player can easily identify and uniquely specify portions relevant to its implementation

Roles: DM

Description: The final design specification will call out relevant portions by stakeholder role.

[82] Spec will identify required, optional, and dependent components for distributors and playback systems

Roles: M

[89] Spec will call out features that are potentially difficult to implement for lightweight players

Roles: M

Description: Such features are typically those that are resource-hungry or computationally expensive.

6.10 Uncategorized

Many requirements do not fall cleanly into the categories above.  Those are listed here.

[6] Must apply to any distribution means (CD, flash, download, streaming, etc.)

Roles: D

Description: The DRM system is independent of the physical medium on which a DTB is carried.

[22] Platform-independent

Roles: DEM

Description: The DRM system can be implemented on any computing platform with sufficient resources.

[38] All pieces of this specification must be at least RAND and preferably royalty-free

Roles: DM

Description: All intellectual property used by the DRM system should be licensable free or at a reasonable cost so as not to place undue cost burdens on distributors. RAND stands for “reasonable and non-discriminatory” and refers to licensing terms.

[8] Minimize impact on end-user (transparency)

Roles: E

Description: This requirement states a basic goal of the DRM system: The end-user should experience the use of a protected DTB in a way identical to that of an unprotected one.  This goal is impossible to meet completely but every effort should be made to meet it as closely as possible.

[30] Shall not impair content rendering quality

Roles: E

Description: Playback audio and image quality shall not be diminished when protected.

[59] Should be implementable in an open-source playback system

Roles: EM

Description: The DRM system should be designed so that it can be used with an open-source playback system.  This requirement is problematic given the relative ease with which such a player could be modified to circumvent the DRM system’s protection.

[19] Required features must be implementable for all current types of DTB reading systems

Roles: M

Description: No required features should call for capabilities or components unavailable on today’s commonly available hardware or software players.

[75] No general international export limitations on constituent technologies

Roles: M

Description: The DRM system should not include any technology that would render conforming players unavailable for transfer outside a country’s borders.

[68] Minimize impact on player performance (e.g. response time)

Roles: ME

Description: There should be minimal performance change (ideally, none) when playing protected content (compared to unprotected content).  Seek and search operations do not take longer.  Load times are not increased.

[83] Spec can be easily extended with respect to technologies (e.g. new ciphers)

Roles:

Description: The system is modularized so that new ciphers and watermarking/fingerprinting schemes can be substituted for or added to those initially chosen.

[90] Where possible should be built on existing, approved standards (e.g. W3C, ISO)

Roles:

[91] All aspects of system support internationalization

Roles:

6.11 Rejected requirements

Requirements that have been rejected by the Working Group are documented here along with the reason for their rejection.  Some requirements are held to be out of scope, while others are deemed as inappropriate, overly difficult, or redundant.

[79] Authorizations may not differentiate between standalone and reproducible playback systems

Roles: DM

Reason for rejection: Conflicting.  See [78]

[9] Can't "hide" text from other applications (e.g., screen-readers)

Roles: E

Reason for rejection: Redundant.  See [40]

[10] Print to Braille should be unlimited

Roles: E

Reason for rejection: Too permissive. See [44]

[27] Implementable on lightweight players

Roles: M

Reason for rejection: Redundant.  See [19]

[12] PIN -- equivalent: an authorization code that doesn't necessarily have to be entered manually (e.g., a second CD, via Internet, etc.).  Entered either once only (at key transaction) or for every book.  PIN entry for every book is, essentially, a password for the reading system (identify self as valid user of system before book can be played)

Reason for rejection: Redundant.  Authorization system is proposed in multiple requirements.

[14] Permanent licenses can be implemented through multiple library cards per library (one for loaning books, one for licensed)

Reason for rejection: Does not apply.  Requirement carried over from Version 1.

[17] User authorization certificate must have cleartext user identification

Reason for rejection: Privacy concerns

[20] Required features be implementable for all libraries

Reason for rejection: Unnecessary

[21] Must be implementable in a short time frame

Reason for rejection: Redundant.  See [1]

[34] Protocols established from publisher to distributor

Reason for rejection: Out of scope

[43] Must be able to protect formats other than DTB

Reason for rejection: System applies only to DTBs, including text-only type.

[61] External files/content may be encrypted

Reason for rejection: Out of scope

[65] Support serial copy management

Reason for rejection: Out of scope

[71] Content-level authorization

Reason for rejection: No strong user requirement

[73] Multiple levels of authorization

Reason for rejection: Would excessively complicate system

Complete list of requirements in numerical order and keyed by role

  Requirement Category Roles*
C D M E
1 Timeframe: Spec done end of 2005 Meta W Y W W
2 Spec is publishable as an open specification Meta R Y G B
3 Allows implementation of watermarking of any content Identification R W W W
4 Unique ID per copy within an agency can be assigned Authorization R W W W
5 Playback can be restricted to authorized users only Authorization R W W W
6 Must apply to any distribution means (CD, download, streaming, etc.) Uncategorized W Y W W
7 All book types can be protected Spec integration W Y W W
8 Minimize impact on end-user (transparency) Uncategorized W W W B
9 Can't "hide" text from other applications (e.g., screen-readers) Rejected W W W B
10 Print to Braille should be unlimited Rejected W W W B
11 Can't allow the production of a complete unprotected copy of the content Player behavior R W W W
12 PIN -- equivalent: an authorization code that doesn't necessarily have to be entered manually (e.g., a second CD, via Internet, etc.).  Entered either once only (at key transaction) or for every book.  PIN entry for every book is, essentially, a password for the reading system (identify self as valid user of system before book can be played) Rejected        
13 Limited time authorizations by duration and/or date Authorization W Y W W
14 Permanent licenses can be implemented through multiple library cards per library (one for loaning books, one for licensed) Rejected        
15 Expiration of individual books Authorization W Y W W
16 User authorization certificate (or equivalent) is tamper-resistant Authorization W Y W W
17 User authorization certificate must have cleartext user identification Rejected W W W W
18 Terms of use must be disclosed to user (education about rights, restrictions, penalties) Rights W W W B
19 Required features must be implementable for all current types of DTB reading systems Uncategorized W W G W
20 Required features be implementable for all libraries Rejected W W W W
21 Must be implementable in a short time frame Rejected W W W W
22 Platform-independent Uncategorized W Y G B
23 Supports national and international interlibrary loan Authorization W Y W W
24 Single cipher possible for all types of content Encryption W Y W W
25 Not all content types must be protected Encryption R Y W W
26 Fast enough for encryption on demand Encryption W Y W W
27 Implementable on lightweight players Rejected W W G W
28 Strong encryption for text Encryption R Y W W
29 Scalable encryption methods Encryption W Y W W
30 Shall not impair content rendering quality Uncategorized W W W B
31 Supports traceability by distributor to individual level Identification R W W W
32 Supports identification of own materials by originating distributor Identification R W W W
33 Privacy of individual readers can be protected Identification W W W B
34 Protocols established from publisher to distributor Rejected W W W W
35 Any valid DAISY 2.02 book can be protected [7] including multivolume books Spec integration W Y W W
36 Any valid Z39.86 book can be protected [7] including multivolume books Spec integration W Y W W
37 Encryption algorithms must be industry standard Encryption R Y W W
38 All pieces of this specification must be at least RAND and preferably royalty-free Uncategorized W Y G W
39 Encryption algorithms must not preclude use of open-source components elsewhere in the system Encryption W W G W
40 Must allow rendering compatible with existing assistive technologies (screen readers, refreshable braille displays) Player behavior W W W B
41 Should support limited excerpting of content Rights R W W B
42 Must not allow application to expose XML markup Player behavior R W W W
43 Must be able to protect formats other than DTB Rejected W W W W
44 Must allow transfer of content to trusted devices Trust model R W W B
45 Distributor must be able to specify export limitations per book Rights R Y W W
46 Distributor must be able to specify export limitations by content type per book Rights R Y W W
47 Must support limitation of transfer of content to untrusted devices (e.g. clipboard) Trust model R W W B
48 Different ciphers may be used on various content types Encryption R Y W W
49 Must allow for protection of partial content segments including non-markup only Encryption R Y W W
50 Supports a secure method of distribution of non-redistributable user authorization certificate Authorization W Y W W
51 Supports multiple authorizations per player Authorization W Y W W
52 Can include authorization certificate along with content Authorization W Y W W
53 User must be able to reproduce authorization certificate Authorization W W W B
54 Playback of a set of books can be restricted to a specific set of users (set = one or more) Authorization W Y W W
55 Books can be authorized for multiple devices Authorization W W W B
56 Must allow user to make a copy of the protected DTB for personal use Rights W W W B
57 Players must inform the user of authorization failures Player behavior W W W B
58 Must not render players incompatible with version 1 of PDTB spec Back compatibility W Y W B
59 Should be implementable in an open-source playback system Uncategorized W W G B
60 Each internal content type can be protected Encryption R Y W W
61 External files/content may be encrypted Rejected W W W W
62 Minimizes the impact of certificate distribution on distributor Authorization W Y W W
63 Facilitate efficient prefetch and decryption of child resources Encryption W W G B
64 Must allow efficient random access to content blocks for all linear content types Encryption W W G W
65 Support serial copy management Rejected W W W W
66 Must not require player to extract content from aggregated files Encryption W W G W
67 Each protected component file must remain independently protected outside of a conforming application Player behavior R W W W
68 Minimize impact on player performance (e.g. response time) Uncategorized W W G B
69 Protected books must fail gracefully when played in a legacy player Back compatibility W W W B
70 Certificates must be removable by the user Authorization W W W B
71 Content-level authorization Rejected W W W W
72 No authorization is necessary to play unprotected content even if mixed with protected content Authorization R Y W B
73 Multiple levels of authorization Rejected W W W W
74 Supports variable complexity keys and codes Authorization W W W B
75 No general international export limitations on constituent technologies Uncategorized W W G W
76 Includes a limited number of available ciphers per content type Encryption W W G W
77 Playback of a set of books can be restricted to a specific set of machines (set = one or more) Authorization R Y W W
78 Authorizations may differentiate among types of playback systems (e.g. class, model, version, manufacturer) Authorization W Y G W
79 Authorizations may not differentiate between standalone and reproducible playback systems Rejected W Y G W
80 Authorizations cannot be created or transferred by end users alone Authorization R Y W B
81 Provides a mechanism which allows the legitimate transfer of a book from one user to another Authorization R Y W B
82 Spec will identify required, optional, and dependent components for distributors and playback systems Meta W W   W
83 Spec can be easily extended with respect to technologies (e.g. new ciphers) Uncategorized W W W W
84 Spec will be written such that a role player can easily identify and uniquely specify portions relevant to its implementation Meta W Y G W
85 Supports ability to authorize a book for the entire universe of players Authorization R Y W B
86 Supports the ability to produce an authorization that can only be processed for a limited time Authorization W W W W
87 No implementation of DRM shall depend upon a particular interpretation of 2.02 or Zed (e.g. ncx v. spine) Spec integration W Y G W
88 Minimize impact of DRM system on DTB specs Spec integration W Y G W
89 Spec will call out features that are potentially difficult to implement for lightweight players Meta W W   W
90 Where possible should be built on existing, approved standards (e.g. W3C, ISO) Uncategorized W W W W
91 All aspects of system support internationalization Uncategorized W W W W
*Roles: (C)opyright holder, (D)istributor, (M)anufacturer, (E)nd user