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.
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.
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.
Other issues considered out of scope include: transport of materials, physical format, patron registration, copyright law, and issues surrounding item sales.
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.
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.
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.
 A unique ID per copy within an agency can be assigned
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.
 Playback can be restricted to authorized users only
Description: One of the basic functions of the DRM system. Stated for completeness.
 Time-out of keys - limited time authorization - by duration and/or date
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.
 Expiration of individual books
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.
 User authorization certificate (or equivalent) is tamper-resistant
Description: Authorization certificates will be constructed in such a way as to be extremely difficult to alter without destroying their functionality.
 Support secure method of distribution of non-redistributable user authorization certificate
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.
 Supports multiple authorizations per player
Description: Players can be multiply authorized. This allows for content from multiple agencies to be played.
 Can include authorization certificate along with content
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.
 Playback of a set of books can be restricted to a specific set of users (set = one or more)
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.
 Playback of a set of books can be restricted to a specific set of machines (set = one or more)
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.
 Minimize impact of certificate distribution on distributor
Description: Authorizations should be simple to create and distribute accurately and quickly and with a minimum of human intervention if so desired.
 Supports national and international interlibrary loan
Description: No part of the DRM system should preclude interlibrary loan.
 No authorization is necessary to play an unprotected content type even if it coexists with a protected content type
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.
 Authorizations cannot be created or transferred by end users alone
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.
 Provides a mechanism which allows the legitimate transfer of a book from one user to another
Description: A DTB can be transferred from one user to another within the bounds of its authorization.
 Supports ability to authorize a book for the entire universe of players
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.
 Authorizations may differentiate among types of playback systems (e.g. class, model, version, manufacturer)
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.
 User must be able to reproduce authorization certificate
Description: Necessary so authorization certificates can be backed up and restored without the intervention of the authorizing entity.
 Books can be authorized for multiple devices
Description: Useful for authorizing books to a patron who wishes to play them on multiple playback systems. May be redundant to .
 Certificates must be removable by the user
Description: User must be able to remove all authorizations from a player. Useful when selling a purchased player or submitting one for service.
 Support variable complexity keys and codes
Description: This requirement refers to the keys used with authorizations, not the encryption schemes used for protecting the content itself.
 Supports the ability to produce an authorization that can only be processed for a limited time
Description: Similar to , but refers to the time range during which an authorization can be applied rather than the time during which the content can be used.
Two requirements have been identified for this category, which covers compatibility with older players.
 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.
 Protected books must fail gracefully when played in a legacy player
Description: Allows older players (those which are not aware of this specification) to fail gracefully when presented with a book the DRM system protects.
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.
 Single cipher possible for all types of content
Description: The sets of ciphers chosen for each content type should have at least one common member.
 Fast enough for encryption on demand
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.
 Scalable encryption methods
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.
 Not all content types must be protected
Description: It must be possible to leave some DTB content (chosen by content type) unprotected.
 Strong encryption for text
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.
 Encryption algorithms must be industry standard
 Different ciphers may be used on various content types
Description: It is not required to encrypt all of a DTB’s content with the same cipher.
 Must allow for protection of partial content segments including non-markup only
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.
 Each internal content type can be protected
 Encryption algorithms must not preclude use of open-source components elsewhere in the system
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.
 Must allow efficient random access to content blocks for all linear content types
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.
 Must not require player to extract content from aggregated files
Description: Chosen encryption schemes must not rely on any combination of a DTB’s component files being zipped, tarred, or otherwise combined together.
 Includes a limited number of available ciphers per content type
Description: The number of available ciphers per content type will be chosen to allow flexibility without placing an undue burden on device manufacturers.
 Facilitate efficient prefetch and decryption of child resources
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.
Identification requirements pertain to the ability to trace content from the producer to the patron while maintaining the privacy rights of the patron.
 Allows implementation of watermarking of any content
Description: The DRM system should not preclude successful, stable watermarking or fingerprinting of any content.
 Supports traceability by distributor to individual level
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.
 Supports identification of own materials by originating distributor
Description: A distributor must be able to identify any circulated DTB as one they have distributed.
 Privacy of individual readers can be protected
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.
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.
 Cannot allow the production of a complete unprotected copy of the content
 Must not allow application to expose XML markup
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 , , and .
 Each protected component file must remain independently protected outside of a conforming application
Description: Players extracting content from a DTB must not create any accessible files that are unprotected, even temporarily.
 Must allow rendering compatible with existing assistive technologies (screen readers, refreshable braille displays)
Description: Players should render DTB content in standard fashion such that assistive devices and software can be used without modification.
 Players must inform the user of authorization failures
Description: Given the requirement that the DRM system be as transparent as possible , 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.
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.
 Should support limited excerpting of content
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  and ).
 Distributor must be able to specify export limitations per book
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.
 Distributor must be able to specify export limitations by content type per book
Description: Similar to , but fine-tunes export limitations to be specified for each content type (text, audio, image) within a DTB.
Description: The DRM system should contain an education component. Patrons must understand what activities are allowed within a distribution system.
 Must allow user to make a copy of the protected DTB for personal use
Description: Users must be able to back up their DTBs.
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.
 All book types can be protected
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.
 Any valid DAISY 2.02 book can be protected including multivolume books
Description: Also see .
 Any valid Z39.86 book can be protected including multivolume books
Description: Also see .
 No implementation of DRM shall depend upon a particular interpretation of 2.02 or Z39.86 (e.g. ncx v. spine)
Description: The DRM system design shall depend only on the specifications and not interpretations or implementations of those specifications.
 Minimize impact of DRM system on DTB specs
Description: The DRM system design should not make requirements of future versions of the DTB specification.
This category covers limitations on the trust model used between players and trusted or untrusted programs and devices regarding the exposure of protected content.
 Must allow transfer of content to trusted devices
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.
 Must support limitation of transfer of content to untrusted devices (e.g. clipboard)
Description: See ,  and .
These are requirements that apply to the design specification itself rather than the DRM system it defines.
 Timeframe: Spec done end of 2005
Description: The Working Group has set December 2005 as a deadline for completion of the DRM system design specification.
 Spec is publishable as an open specification
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.
 Spec will be written such that a role player can easily identify and uniquely specify portions relevant to its implementation
Description: The final design specification will call out relevant portions by stakeholder role.
 Spec will identify required, optional, and dependent components for distributors and playback systems
 Spec will call out features that are potentially difficult to implement for lightweight players
Description: Such features are typically those that are resource-hungry or computationally expensive.
Many requirements do not fall cleanly into the categories above. Those are listed here.
 Must apply to any distribution means (CD, flash, download, streaming, etc.)
Description: The DRM system is independent of the physical medium on which a DTB is carried.
Description: The DRM system can be implemented on any computing platform with sufficient resources.
 All pieces of this specification must be at least RAND and preferably royalty-free
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.
 Minimize impact on end-user (transparency)
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.
 Shall not impair content rendering quality
Description: Playback audio and image quality shall not be diminished when protected.
 Should be implementable in an open-source playback system
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.
 Required features must be implementable for all current types of DTB reading systems
Description: No required features should call for capabilities or components unavailable on today’s commonly available hardware or software players.
 No general international export limitations on constituent technologies
Description: The DRM system should not include any technology that would render conforming players unavailable for transfer outside a country’s borders.
 Minimize impact on player performance (e.g. response time)
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.
 Spec can be easily extended with respect to technologies (e.g. new ciphers)
Description: The system is modularized so that new ciphers and watermarking/fingerprinting schemes can be substituted for or added to those initially chosen.
 Where possible should be built on existing, approved standards (e.g. W3C, ISO)
 All aspects of system support internationalization
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.
 Authorizations may not differentiate between standalone and reproducible playback systems
Reason for rejection: Conflicting. See 
 Can't "hide" text from other applications (e.g., screen-readers)
Reason for rejection: Redundant. See 
 Print to Braille should be unlimited
Reason for rejection: Too permissive. See 
 Implementable on lightweight players
Reason for rejection: Redundant. See 
 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.
 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.
 User authorization certificate must have cleartext user identification
Reason for rejection: Privacy concerns
 Required features be implementable for all libraries
Reason for rejection: Unnecessary
 Must be implementable in a short time frame
Reason for rejection: Redundant. See 
 Protocols established from publisher to distributor
Reason for rejection: Out of scope
 Must be able to protect formats other than DTB
Reason for rejection: System applies only to DTBs, including text-only type.
 External files/content may be encrypted
Reason for rejection: Out of scope
 Support serial copy management
Reason for rejection: Out of scope
 Content-level authorization
Reason for rejection: No strong user requirement
 Multiple levels of authorization
Reason for rejection: Would excessively complicate system
|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|
|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|
|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  including multivolume books||Spec integration||W||Y||W||W|
|36||Any valid Z39.86 book can be protected  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|
|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|