PDTB 2.0 Draft Specification

Important: this is an archived document. The current version is available from the Protected Digital Talking Book area.

DAISY Protected Digital Talking Book Specification

Version 2.0 (DRAFT)—9 April 2006

1 Abstract

This specification was created to support talking book programs in libraries and agencies which operate under legally-mandated requirements to protect intellectual property. While the specific provisions of these laws vary from country to country in their particulars, they generally allow libraries and agencies to publish copyrighted matter to their clients with print disabilities under special exemptions from customary commercial considerations. In return they require that these libraries and agencies publish to their clients utilizing “specialized formats” not generally available to the public. Some traditional examples of “specialized formats” include braille and multi-track cassette tape recordings.

The DAISY 2.02 and ANSI/NISO Z39.86 specifications define formats for digital talking books that are specially designed to meet the needs of persons with print disabilities. The first encryption specification designed to turn such a book into a Protected Digital Talking Book (PDTB) was not made available to the public. This subsequent specification (PDTB2) defines a means for further specializing these formats by describing various transformations which may be applied to DAISY and ANSI/NISO digital talking books. These transformations, based on standard information technology techniques, will prevent content from being displayed in reading systems or other user presentation technologies unless appropriately authorized by the issuing library, agency, or publisher. The specification is designed in such a way that a single reading system can be authorized to process books from multiple libraries, agencies, or publishers.

The PDTB2 specification has been designed to be flexible in order to meet different needs of different agencies in different countries. While there is a minimum set of requirements that all PDTBs must meet, it is expected that each library or agency may adopt or ignore the various optional components. Since it is expected that those libraries and agencies which do use the PDTB2 specification will still publish some content without protection, the PDTB2 specification is completely compatible with non-protected content. PDTB2-aware reading systems will still play non-protected digital talking books. Although non-PDTB2-aware reading systems will not be able to play a protected digital talking book, they will still play an appropriate and informative issuer-defined message.

This document specifies the technical means by which digital talking books can be issued in a protected format. It is intended as a specification for transforming existing unprotected digital talking books into a protected format using simple encryption means. In addition, it defines the mechanisms for expressing and validating user authorizations to such protected books.

1.1 Status of this document

This specification is a draft for public review and comment.

1.2 Table of Contents

1.3 Acknowledgements

The following individuals participated in the working group that created this specification: Ole Holst Andersen, Danish National Library for the Blind; Neil Bernstein, National Library Service for the Blind and Physically Handicapped, Library of Congress; Thomas Kjellberg Christensen, Danish National Library for the Blind; Keith Creasy, American Printing House for the Blind; Tom Diaz; Linus Ericson, Swedish Library of Talking Books and Braille; Blake Erickson, Telex; Marc-André Hébert, HumanWare; Mattias Karlsson, Dolphin Audio Publishing; George Kerscher, DAISY Consortium, Recording for the Blind & Dyslexic; Dominic Labbé, HumanWare; Dennis Leas, gh; Tom McLauglin, National Library Service for the Blind and Physically Handicapped, Library of Congress; Michael Moodie, National Library Service for the Blind and Physically Handicapped, Library of Congress; Tatsuo Nishizawa, Plextor; Diana Hiorth Persson, Dolphin Audio Publishing; James Pritchett, Recording for the Blind & Dyslexic; Dorothea Salo, Text Artisan Guild.

2 Introduction

2.1 Definitions and conventions

2.1.1 Normative vs. non-normative

All language in this specification is normative except for sections specifically designated as informative.

2.1.2 Fundamental definitions

Common understanding of certain terms is a prerequisite for the correct understanding of this specification. These terms are defined in the following list:

Authorization object
An authorization object is a data object that transmits the content decryption keys and rights expression for a single book to a reading system. The content decryption keys are secured within the authorization object by encrypting them with some key known to the reading system. The authorization encryption may use either a symmetric (single-key) or public key (dual-key) cipher. This authorization encryption key is identified by name in the authorization object, and is presumed to be stored somewhere in the reading system. If the reading system does not have the named key, it must acquire it, most likely via a key exchange object.
Collection
One or more PDTBs protected using the same key. A single authorization can grant access to all books in the collection. The contents of collections are entirely under the control of issuers. A single issuer may distribute authorizations for one or more collections
Digital Talking Book (DTB)
An unprotected multimedia accessible book as described by the DAISY 2 [DAISY202] or ANSI/NISO Z39.86 [NISO] specifications
Issuer
An entity that creates and authorizes the use of PDTBs. The issuer of a PDTB may or may not be the producer of the original DTB
Key exchange object
A key exchange object is a data object that transmits encryption key material from one entity to another, most likely from an issuer to a reading system. The key material is secured within the object by encrypting it with the public key of the entity on the receiving end. This assumes that the sender already has the receiver’s public key; if not, the sender must acquire it.
Producer
An entity that produces DTBs and/or PDTBs
Protected Digital Talking Book (PDTB)
A DTB that has been protected as described by this specification.
Protector
A program (or set of programs) that takes as input a DTB and that produces as output named AES keys, an encrypted DTB, authorization objects, and key exchange objects
Reading system
A combination of hardware and/or software that accepts PDTBs and directly or indirectly makes them available to users. A reading system may be implemented entirely on one device, or it may be split among several computers
Text/image content
The digital text documents (XHTML or DTBook) of a DTB and all images referenced by that digital text. Stylesheets and Document Type Definitions (DTDs) referenced by digital text documents are not considered part of the text/image content
User
A person who reads a DTB or PDTB using a reading system.
Vendor
A manufacturer of a reading system

In addition, the key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this specification are to be interpreted as described in IETF RFC 2119 [RFC2119].

2.1.3 Other definitions

Encryption key data, Decryption key data
Binary data used as input to an encryption or decryption algorithm.
Plaintext
Original, unencrypted data
Keyring
A secure storage mechanism for encryption keys.
SMIL files
Synchronized Multimedia Integration Language documents used to control the presentation of text and/or audio in a DTB

2.2 Relation to other specifications

2.2.1 ANSI/NISO Z39.86

This specification also defines the means for protecting digital talking books created per the ANSI/NISO standard [NISO]. This standard was written in reference to ANSI/NISO Z39.86-2002 and 2005; future revisions of this standard may require modifications to this protected digital talking book specification.

All files created especially for the protected ANSI/NISO digital talking book (Substitute NCX, text, audio, and SMIL) must conform to the same version of the ANSI/NISO Z39.86 specification as does the rest of the book content. Protector programs may but need not support both versions of ANSI/NISO Z39.86.

2.2.2 DAISY 2.0.2

This specification defines the means for protecting digital talking books, including those created per the DAISY 2.02 [DAISY202] specification.

All files created especially for the protected DAISY 2 digital talking book (substitute NCC, text, audio, and SMIL) must conform to the DAISY 2.02 specification.

2.2.3 ISO8601

Computer-readable dates and times in protected digital talking books must be expressed according to [ISO8601].

2.2.4 ODRL

The PDTB2 rights expression language is a subset, or profile, of the Open Digital Rights Language, version 1.1 [ODRL]. ODRL is a free and open XML-based standard with no licensing requirements. Version 1.1 has been published by the World Wide Web Consortium [W3C] as a W3C Note. ODRL is promoted by the ODRL Initiative, a cooperative project with more than a dozen participating organizations.

2.2.5 URI

All URIs called for by this specification must conform to [RFC3986].

2.2.6 W3C XML Schema

XML objects defined by this specification are expressed via [W3CXMLSchema].

2.2.7 XML-Signature Syntax and Processing

The key exchange object defined in this specification uses elements from [XMLSignature].

2.2.8 XML Encryption

The key exchange and authorization objects defined in this specification use elements from [XMLEncryption].

2.3 Intellectual property statement

In accordance with the requirement of a free and open specification, the working group creating this specification did avoid knowingly including, using, or depending on any proprietary technology in the design of additional parts of the system. In addition, the working group chose only component technologies that it believed to be royalty-free. These technologies include:

Please refer to the license terms at the sites listed under the References section at the end of the document for further details on the legal status of these components.

This specification does not recommend any particular implementations of these technologies. The choice of specific code libraries or other methods of implementation are left to the implementor. It is the implementor’s responsibility to ensure that any implementation follows the terms of the licences for any constituent code or technique.

3 Technical introduction

3.1 Simple overview

This section is informative.

Four entities are involved in transactions surrounding DAISY PDTBs:

  • Issuer
  • Reading system manufacturer
  • Reading system
  • User

At the highest and simplest level, the steps in a secured transmission of a DAISY PDTB are:

  • The issuer encrypts the content of the book.
  • The issuer stores the required content decryption keys in an authorization object.
  • The issuer sends the encrypted book and the authorization object to the user.
  • The user presents the book to the reading system.
  • The reading system retrieves the content decryption keys from the authorization object, if possible.
  • The reading system decrypts and renders the book content for the user.

3.2 Detailed data flow

This section is informative.

The data flow below details the key exchanges necessary for secure transmission of a DAISY PDTB. This is only one scenario; others are possible.

  • The issuer encrypts the content of the book.
  • The issuer stores the required content decryption keys in an authorization object secured with an asymmetric cipher.
  • The issuer sends the encrypted book and the authorization object to the user.
  • The user presents the book to the reading system.
  • The reading system sends its public key to the issuer.
  • The issuer stores the reading system identifier and key.
  • The issuer sends the authorization encryption key to the reading system via a key exchange object, secured using the reading system’s public key.
  • The reading system stores the authorization encryption key.
  • The reading system retrieves the content decryption keys from the authorization object using the authorization encryption key.
  • The reading system decrypts and renders the book content.

4 Packaging

4.1 ANSI/NISO Z39.86 DTBs

4.1.1 Package file

The package file for a protected book must not be encrypted.

Every protected book must have a “protected package file”, which is a modified version of the package file. This file is the authoritative, full package file for the protected book. It is slightly different from the normal Z39.86 package file (OPF file).

The file extension for protected book package file must be “.ppf” (“protected package file”).

The protected package file must follow the Z39.86 specification for package files with the following modifications:

  • Package file metadata (under “x-metadata”)
    • Add item pdtb2:specVersion with value “2005-1”
  • Package manifest
    • All files in protected book and in the compatibility “facade” (see below) are listed
    • New media types for files added to support protection
      • Authorization file = application/x-pdtbauth+xml
    • New media types for encrypted files
      • Encrypted NCX = application/x-pdtbncx+xml
      • Encrypted SMIL = application/x-pdtbsmil+xml
      • Encrypted audio:
        • AAC = application/x-pdtbmpeg4-generic
        • MP3 = application/x-pdtbmpeg
        • WAV = application/x-pdtbwav
      • Encrypted text content = application/x-pdtbook+xml
      • Encrypted image:
        • JPEG = application/x-pdtbjpeg
        • PNG = application/x-pdtbpng
        • SVG = application/x-pdtbsvg
    • File extensions for encrypted files are unchanged.
    • Protected (encrypted) NCX must have the id attribute value “ncx” (as required by the Z39.86-2005 specification). To follow XML rules, the id attribute for the unprotected NCX must change to a different, unique string where it appears in the PNCX manifest.
  • Package spine
    • The protected package spine lists protected (encrypted) SMIL files

4.1.2 Compatibility (“facade”) book

In order to maintain backwards compatibility, each PDTB must also contain a valid, unprotected Z39.86 book. This book must present whatever content is appropriate for an unauthorized user. It functions as a fallback when a protected book is presented either to a reading system that is unaware of the DAISY PDTB2 specification, or to a reading system without the appropriate keys to decrypt the content. The nature of the unprotected content is entirely determined by the producer.

4.1.2.1 Facade package file

The facade book must be a valid Z39.86 DTB. As such, it will have its own package file. This package file must:

  • have the file extension .opf
  • include pdtb2:specVersion metadata item (= “2005-1”)
  • include pdtb2:package metadata item (gives name of .ppf file)
  • include pdtb2:authorization metadata item (gives name of authorization file)
  • Book metadata in the unprotected package file must be unchanged from the protected package file (including the value “ncx” for the id attribute value) except for:
    • dtb:multimediaType
    • dtb:multimediaContent
    • dtb:narrator
    • dtb:totalTime
    • dtb:audioFormat

    All of these must be changed if the content of the facade book does not match that of the protected book.

  • The manifest must include only the files needed for the compatibility facade; it must not list encrypted files.
  • The spine must list only facade (unencrypted) SMIL.
4.1.2.2 DistInfo

For multiple books on one piece of media, no changes are needed; the distInfo element must point to the .opf files (facade packages) of the various books.

For a single book that spans multiple pieces of media, the distMap must list both protected and facade SMIL files, and the fileSet element, if present, must list all files for both protected and facade books.

4.1.3 NCX file

The NCX file for the protected book may or may not be encrypted. If encrypted, it must use the Advanced Encryption Standard (AES) and follow the procedures identified in section 4.3.

Some, all, or none of the audio files and image files used for labels within the NCX may be encrypted. In the case where some audio/image files are encrypted but others are not, there must be a way of identifying which files are which. A type attribute is added by this specification to both the audio and img elements of the NCX for this purpose. The value of this attribute must be the MIME media type for the file referenced by the src attribute of the same element. In cases where all audio and/or image files are encrypted or all are not encrypted, this attribute is optional. In mixed encrypted/unencrypted books, the type attribute is optional for audio/img elements referencing encrypted content, but is mandatory for those referencing unencrypted content (i.e., in mixed protected/unprotected content books, media files are assumed to be encrypted by default). Should the type attribute be missing, the authorization object may be consulted to determine which files are encrypted.

4.1.4 SMIL files

The SMIL files for the protected book may or may not be encrypted. If encrypted, they must use the Advanced Encryption Standard (AES) and follow the procedures identified in [XML content protection].

Some, all, or none of the audio files and image files referenced within a SMIL file may be encrypted. In the case where some audio/image files are encrypted but others are not, there must be a way of identifying which files are which. The type attribute for both the audio and img elements of the SMIL files serves this purpose. The value of this attribute must be the MIME media type for the file referenced by the src attribute of the same element. In cases where all audio and/or image files are encrypted or all are not encrypted, this attribute is optional. In mixed encrypted/unencrypted books, the type attribute is optional for audio/img elements referencing encrypted content, but is mandatory for those referencing unencrypted content (i.e., in mixed protected/unprotected content books, media files are assumed to be encrypted by default). Should the type attribute be missing, the authorization object may be consulted to determine which files are encrypted.

4.1.5 Audio and image files

The audio and image files of the protected book may or may not be encrypted. If encrypted, they must use AES. Any file that is encrypted must be encrypted as a whole, not in part.

4.1.6 Text content files

Some, all, or none of the text content files for a protected book may be encrypted. If encrypted, they should use the Advanced Encryption Standard (AES) and follow the procedures identified in [XML content protection].

4.2 DAISY 2.02 DTBs

In order to maintain backwards compatibility, each PDTB must also contain a valid, unprotected DAISY 2.02 book (“facade book”). This book must present whatever content is appropriate for an unauthorized user. It will function as a fallback when a protected book is presented either to a reading system that is unaware of the DAISY PDTB2 specification, or to a reading system without the appropriate keys to decrypt the content. The nature of the content is entirely determined by the producer.

The facade book must be a valid DAISY 2.02 DTB. As such, it will have its own NCC. The head of this NCC must contain the complete, unaltered Dublin Core (“dc:”) metadata from the original DTB NCC. In addition, it must contain in an unaltered form any of the following DAISY (“ncc:”) metadata items that appear in the original DTB:

  • ncc:sourceDate
  • ncc:setInfo
  • ncc:sourcePublisher
  • ncc:sourceEdition
  • ncc:sourceRights
  • ncc:sourceTitle

All other DAISY metadata items in the facade NCC must follow the DAISY 2.02 specification in reference to the facade DTB itself and not to the original DTB. A producer may preserve these original DTB metadata items by using the same metadata names with the prod:pdtb2- prefix (e.g., prod:pdtb2-totalTime).

In addition, the facade NCC must include the following special metadata items:

prod:pdtb2-version
The version number of the PDTB2 specification. For PDTBs prepared under this version of the specification, this metadata item must have a value of “2005-1”
prod:pdtb2-authFile
The URI of the authorization file
prod:pdtb2-authRequestURI
The URI to request authorization
prod:pdtb2-nccFile
The name of the encrypted original NCC

The content of the body of the facade DTB is not mandated; it can be structured in whatever way the producer finds appropriate.

In a DTB spanning multiple pieces of media, each piece of media must have its own facade NCC.

4.3 XML content protection

Protection of XML content must be done according to the “XML Encryption Syntax and Processing” W3C Recommendation [XE].

More specifically, PDTBs compliant to this specification use the <EncryptedData> element specified in [XE] for encrypting elements or element content of the XML documents needing protection.

An element of a XML document is encrypted by replacing it with an <EncryptedData> element containing the encrypted element. Information about the key and algorithm needed to decrypt the element can be found in the authorization obejct as described in section 5.3. The content of an element may be encrypted in much the same way, except that only the content of the element is replaced by an <EncryptedData> element.

4.3.1 The <xe:EncryptedData> element

A brief description of the <EncryptedData> element and its descendants follows. In the syntax for each element the xe: prefix is used for the http://www.w3.org/2001/04/xmlenc# namespace defined in [XE]. Note that the schema definition differs from that in [XE]; this specification does not employ the full syntax but is valid under [XE].

<EncryptedData>
Description: Holds the encrypted data and replaces the encrypted element or text nodes in the encrypted XML documents
Namespace: http://www.w3.org/2001/04/xmlenc#
Schema definition:

    <element name='EncryptedData' type='xe:EncryptedDataType'/>
    <complexType name='EncryptedDataType'>
        <complexContent>
            <extension base='xe:EncryptedType'/>
        </complexContent>
    </complexType>
    <complexType name='EncryptedType' abstract='true'>
        <sequence>
            <element ref='xe:CipherData'/>
        </sequence>
        <attribute name='Id' type='ID' use='optional'/>
        <attribute name='Type' type='xe:TypeAttrType' use='required'/>
    </complexType>
    <simpleType name='TypeAttrType'>
        <restriction base='anyURI'>
            <enumeration value='http://www.w3.org/2001/04/xmlenc#Content'/>
            <enumeration value='http://www.w3.org/2001/04/xmlenc#Element'/>
        </restriction>
    </simpleType>

Contains: Exactly one <xe:CipherData> element
Syntax: <xe:EncryptedData ...attributes...>...content...</xe:EncryptedData>
Attributes:

  • Id (ID, optional)
  • Type (anyURI, required). Must have one of the values ‘http://www.w3.org/2001/04/xmlenc#Content’ (if the encrypted data represents the contents of the enclosing element) or ‘http://www.w3.org/2001/04/xmlenc#Element’ (if the encrypted data represents an entire element).
<CipherData>
Description: Container for the <CipherValue> element holding the encrypted data
Namespace: http://www.w3.org/2001/04/xmlenc#
Schema definition:

    <element name='CipherData' type='xe:CipherDataType'/>
    <complexType name='CipherDataType'>
         <sequence>
             <element ref='xe:CipherValue'/>
         </sequence>
    </complexType>

Contains: Exactly one <xe:CipherValue> element
Syntax: <xe:CipherData>...content...</xe:CipherData>
Attributes: None
Valid inside: <EncryptedData>

<CipherValue>
Description: Holds the encrypted data encoded as a base64 string
Namespace: http://www.w3.org/2001/04/xmlenc#
Schema definition:

    <element name='CipherValue' type='base64Binary'/>

Contains: The base64 encoded encrypted data
Syntax: <xe:CipherValue>...content...</xe:CipherData>
Attributes: None
Valid inside: <CipherData>

4.3.2 Encryption of Z39.86 XML documents

PDTB2 supports encryption of DTBs conforming to the Z39.86 standards (i.e. the two standards Z39.86-2002 and Z39.86-2005). In Z39.86 DTBs the following XML documents can be encrypted:

  • The NCX document
  • The SMIL documents
  • The DTBOOK textual content documents

Note that all other XML documents of Z39.86 DTBs are not encrypted using the XML content encryption described here. If SVG image files are encrypted, they must be block-encrypted like binary image files, rather than XML-encrypted like XML text-content files.

The NCX file of a Z39.86 DTB may be encrypted in one of two ways:

  • Encrypting the root <ncx> element, effectively encrypting the entire NCX file
  • Encrypting the content of all <navLabel> elements in the NCX file. In this mode the labelling information in the NCX file is encrypted, but the navigational structure remains unencrypted

The SMIL files of a Z39.86 DTB may be encrypted in one of two ways:

  • Encrypting the root <smil> element, effectively encrypting the entire SMIL file
  • Encrypting the media elements of the SMIL file (In Z39.86-2002 and Z39.86-2005 DTBs the media elements are the <text>, <audio> and <image> elements)

Note that encrypting the root <smil> element of very large SMIL documents may result in performance degradation on playback systems with limited resources. When encrypting DTBs with very large SMIL documents, the publisher should split these SMIL files into several smaller SMIL files prior to encryption to avoid performance degradation.

The textual content files of a Z39.86 DTB may be encrypted in one of three ways:

  • Encrypting the root <dtbook> element, effectively encrypting the entire textual content file
  • Encrypting all text nodes
  • Encrypting an arbitrary subset of the nodes of the textual content file.
4.3.3 Encryption of DAISY 2.02 XML documents

PDTB2 supports encryption of DTBs conforming to the DAISY 2.02 standard. In DAISY 2.02 DTBs the following XML documents may be encrypted:

  • The NCC document
  • The SMIL documents
  • The XHTML textual content documents

The NCC file of a DAISY 2.02 DTB may be encrypted in one of two ways:

  • Encrypting the root <html> element, effectively encrypting the entire NCC file
  • Encrypting the content of all <a> elements in the NCC file. In this mode the text in the NCC file is encrypted, but the navigational structure remains unencrypted

The rules for encrypting Z39.86 SMIL Documents (see section 4.3.2) must also be followed for DAISY 2.02 SMIL Documents .

The textual content files of a DAISY 2.02 DTB may be encrypted in one of three ways:

  • Encrypting the root <html> element, effectively encrypting the entire textual content file
  • Encrypting all text nodes
  • Encrypting an arbitrary subset of the nodes of the textual content file.
4.3.4 Processing

For each <EncryptedData> element to be decrypted, the decryptor must:

  1. Retrieve the content encryption key from the authentication object as described in section 5.3.
  2. Decrypt the data contained in the <CipherData> element: First, retrieve the encrypted octet sequence by base64 decoding the text value of the <CipherValue> element. Then decrypt the octet sequence using the algorithm and key retrieved in step 1.
  3. The cleartext sequence obtained in step 2. is now interpreted as UTF-8 encoded character data representing the serialized XML element or element content, as specified by the Type attribute of the <EncryptedData> element.
  4. The <EncryptedData> element must now be replaced by the element or element content obtained in step 3. Note that if the containing XML document is not UFT-8 encoded, the element needs to be re-encoded prior to replacement

For each element or element content to be encrypted as an <EncryptedData> element, the encryptor must:

  1. Select the key to be used in encrypting the data. Make sure this key is added to the Authentication Object as described in section 5.3.
  2. Obtain the cleartext octets by serializing the data in UTF-8 as specified in [XML]. The XML data must be provided in Unicode Normalization Forms, see [UNINORM].
  3. Encrypt the cleartext octets obtained in 2. using the algorithm and key selected in steps 1.
  4. Build the <EncryptedData> element:
    • Set the Type attribute of the <EncryptedData> element as appropriate
    • Construct a <CipherData> element and append a single <CipherValue> element whose content encrypted data obtained in 3. encoded using base64.
    • Append the constructed <CipherData> element as a child of the <EncryptedData> element.
  5. Finally replace the element or element content with the <EncryptedData> element constructed in step 4.

5 Reading system behavior

5.1 Keys

All reading systems must be able to store and use RSA public/private key pairs to decrypt and use key exchange objects and authorization objects in conformance with section 8.2.4 and section 8.2.5. Each key pair must be associated with a key identifier.

All reading systems must store at a minimum two RSA key pairs corresponding to the manufacturer and the model of the reading system.

Software reading systems must also store a key pair that corresponds to the instance of the reading system, a key pair that is unique for each machine on which the reading system is installed.

All reading systems must be able to store one or more key pairs that belong to the individual or individuals authorized to play protected content on the reading system. Hardware reading systems should also store an instance key unique to each individual reading system.

Reading systems must take diligent measures to protect all private keys in order to prevent those keys from being copied or used to access content outside the context of the reading system’s normal use. The “instance” key generated for a specific instance of a software reading system should be designed and used in such a way that it cannot be used on an instance of the reading system that resides on a different machine from the one on which it was created.

5.2 Key exchange object

When presented with a key exchange object, a reading system must determine the key identifier and compare it to keys already stored on the reading system. If the required key is not stored, the reading system should first attempt to retrieve the necessary key online. If this is not possible or fails, the reading system should notify the user and must fail to decode or use the key exchange object.

If the reading system has a key identified in the key exchange object, it must be able to use that key to decode and use an authorization object associated with specific content. The reading system should store the key obtained from the key exchange object for subsequent use. Non-networked reading systems need not store the public key portion of the key pair, since they have no further use for it.

If a reading system is unable to store a key due to insufficient memory, the reading system should notify the user. The reading system should also provide a method to remove keys from the system to make room for new keys, and to allow the reading system to be transferred to another user.

If a key already exists in the reading system’s internal memory with an ID that matches one being installed from a key exchange object, the reading system must overwrite the existing key with the one being installed.

5.3 Authorization objects

When presented with an authorization object, a reading system must determine the key identifier and compare it to keys stored on the reading system. If the required key is not stored, the reading system should look for a key exchange object on the medium with the book. If no stored key or key exchange object can be located, the reading system should notify the user, play the facade book, and must fail to decode or use the authorization object.

If the reading system has a key identified in the authorization object, it must be able to use that key to decode and use AES keys associated with specific content in conformance with section 5.7.

Reading systems must decode rights expressed using ODRL to determine what rights are granted and what restrictions may be placed on the use of the authorization object or the associated content as described in section 7.6. If limitations are placed on the rights to use the object or the content, the reading system must comply with all expressed limitations. The reading system must only allow access to the object and the content based on expressed rights.

5.4 PDTB content

Producers may use AES to encrypt PDTB content and must use the PDTB2 ODRL profile to express rights and limitations on the access to or use of the content. Reading systems must be able to decrypt content using AES and must comply with the rights and limitations expressed in the rights-expression section of the authorization object.

5.5 User education

This section of the standard is intended to ensure that users of content understand their scope of action with regard to protected content, do not unexpectedly lose access to protected content, and are not surprised by restrictions on content access.

Reading-system manufacturers should inform users:

  • whether their reading system plays PDTBs that conform to this standard
  • any limitations on their reading system’s support of this standard that could affect which content a user decides to acquire
  • that their reading system plays both protected and unprotected content
  • of the existence of keys linked to the model and individual serial number of the reading system
  • that protected content purchased for one reading system or reading-system model may not be transferable to other reading systems
  • of the procedure for transferring legitimately-purchased content to a new reading system, or rescuing it from a malfunctioning reading system.
  • what will be done with any personal data acquired by the manufacturer in the context of registering a device with the manufacturer in the context of selling or providing the reading system to a user

This information should be made available to users before purchase of a reading system.

Issuers should inform users:

  • that the content they are receiving is protected
  • of the rights and limitations associated with use of the content
  • of any consequences (e.g. loss of access, criminal prosecution) associated with misuse of the content, including attempts to use the content past time limits
  • of the procedure for replacing legitimately-acquired content in case of device malfunction or loss, new device purchase, or other event that results in loss of access to legitimately-acquired content. If no such procedure is available, or the vendor controls content replacement, this also should be communicated to users.
  • what will be done with any personal data acquired by the issuer in the context of requesting or delivering protected content
  • of any changes to previously existing agreements between issuer and user

PDTBs should contain language free of encryption and available to the user informing users:

  • that the PDTB2 is protected
  • whether its protection is keyed to the user, the device, or the device model
  • of the rights and limitations associated with use of the PDTB
  • of any consequences (e.g. loss of access) associated with misuse of the PDTB, including attempts to use the content past time limits

All communications aimed at users should use the simplest and clearest language possible, and be available in a format fully accessible to the user, preferably the same format as the content itself.

5.6 Decision chart

This section is informative.

Note: Each sub-heading represents a point in the process that can be jumped to by the reading system depending on the outcome of the current operation.

  • Presentation
    1. The reading system is presented with a media unit or URI.
    2. The reading system checks for package, NCC/NCX, or distInfo file for the book. If one is found, go to “Open book;” if not, continue.
    3. Look for key exchange object. If found, go to “Process key exchange object;” if not, go to “Fail/Exit.”
  • Open book
    1. Open package or NCC/NCX file and check DAISY version. If this version is supported by the reading system, continue; if not, go to “Play facade book.”
    2. Check version of PDTB. If this version is supported by the reading system, continue; if not, go to “Play facade book.”
    3. Test for protected book by looking for “pdtb2” meta items. If these are found, continue; if not, go to “Play facade book.”
    4. Get the authorization object’s URI from the metadata. If the authorization object is found, go to “Process authorization object,” if not, go to “Play facade book.”
  • Process authorization object
    1. Load the authorization object and check for EncryptedKey section. If it is found, continue; if not, go to “Process rights.”
    2. Locate the named key needed to decrypt the encrypted section of the authorization object. If this key is found then decrypt the keys and rights section and go to “Process Rights.” If not, then continue.
    3. Attempt to locate a Key Exchange Object. If found, go to “Process Key Exchange Object.” If not, go to “Play Facade Book.”
  • Process key exchange object
    1. Load key exchange object and locate the “EncryptedKey” section for which this reading system has the key named in “KeyInfo”. If found, continue; if not, check the medium containing the book for it. If still not found, notify the user and go to “Fail/Exit.”
    2. Use the key found in KeyInfo to decrypt the CarriedKey, and store this key in reading-system memory. If a key with that name already exists, overwrite it. If reading-system resources are exhausted, notify the user and go to “Fail/Exit.”
    3. Go to “Resume normal reading-system operation.”
  • Process rights
    1. Read rights expression.
    2. Compare clear-text rights with decrypted rights to determine if the clear-text rights have been altered. If they do not match, then notify the user and continue.
    3. Set necessary parameters such as limitations on printing, excerpting, etc.
    4. If conditions are met, go to “Play protected book;” if not, notify the user and go to “Play facade book.”
  • Play protected book
    1. Locate the protected NCX by looking in the package file for the protected book, or load the NCC/NCX for the protected book.
    2. Play the content normally using keys from the authorization object as needed.
    3. Resume normal reading-system operation.
  • Play facade book
    1. Attempt to play facade book’s contents. If this fails, go to “Fail/Exit.”
  • Fail/Exit
    1. Notify user with reading-system failure notification.
    2. Fall back to normal reading-system operation.
  • Resume normal reading-system operationReading system returns to normal operation, perhaps using keys from the authorization object as needed.

5.7 Example

This example is informative, not normative.

Process for playback of content authorized for a specific model of DAISY reading system:

  • The user receives a CD from an issuer that contains a key exchange object that is keyed to work only on a specific model of hardware-based reading system, the “Acme DAISY Player.”
  • The user places the medium onto the Acme DAISY Player, which begins to read the contents of the medium. The reading system finds the key exchange objects on the medium and begins to look for one that it can use by matching the key required to read the key exchange object with keys that are installed in the reading system. If it fails to find a match, the reading system plays a message from the provider of the key exchange object and aborts the installation.
  • In this case, the reading system finds a key exchange object encrypted with the “Acme DAISY Player” public key and matches it with a private key that is stored in its memory.
  • The reading system uses its private key to decrypt the collection key from the issuer and stores this key in its memory for later use.
  • Later, a medium containing a book from the issuer is received by the user and it is placed in the reading system.
  • The reading system reads the package file (.opf) of the book and determines that it is protected under this specification. It also locates the file that contains the authorization object required to decrypt and play the content.
  • The reading system reads information from the authorization object and discovers that it has been encrypted with the collection key that was received from the issuer.
  • The reading system looks up the issuer’s key in its table of keys and uses this key to decrypt the authorization object and obtains the keys needed to decrypt the books content.
  • The reading system reads the Right Expression section of the authorization object to discover any limitations or restrictions placed on the use of this book’s content and what rights to the content are expressly granted.
  • The reading system begins to decrypt and play the book.

<!–

5.7.2 Example 2

Process for playback of content authorized for a specific instance of a software reading system:

  • A user installs a software-based reading system on a personal computer. When installed the reading system creates an instance key that is unique to this installation and to the specific machine on which it is being installed. This key, along with the make and model keys, is stored by the reading system.
  • The user goes to the issuer’s Web site and downloads a protected issue of a magazine. It is stored on the computer’s hard drive.
  • The user opens the reading system and then attempts to open the protected magazine. The reading system reads the package file, determines that it is protected under this specification, and locates the authorization object that was downloaded with the magazine.
  • The reading system reads the authorization object, and determines that it does not have the required key to decrypt and play the book’s content. It then reads the URI of the server where the key is available and begins a SOAP transaction with the server.
  • The server requests the public key for this instance of the reading system, and the reading system sends the key.
  • The server uses the instance key to encrypt a key exchange object and sends this object to the reading system. The reading system receives the key exchange object, and installs the key required to use the authorization object.
  • The reading system uses the key it has received to decrypt the authorization object.
  • The reading system reads the rights expression section of the authorization object and determines that all the requirements for using the content are met.
  • The reading system obtains the keys required to decrypt the magazine’s content from the authorization object, decrypts them, and begins to play the content, using the keys as needed.

–>

6 Authentication and key exchange

6.1 Key exchange object model

The key exchange object must contain:

  • Identification of the key issuer
  • One or more keys or key pairs, secured using one or more trusted public keys and/or
  • One or more public keys

It uses elements from the [XMLSignature] and [XMLEncryption] vocabularies. Its file extension must be “kxo.”

The normative description of the syntax for this object is the XML schema instance KeyExchObj.xsd. An example document is given in section 9.3. What follows is a normative prose description of the object semantics.

KeyExchange = document container
Contains one Issuer element and one or more Keys or ds:KeyInfo elements. The Keys elements are used to transmit keys in secured fashion. The ds:KeyInfo elements are used to transmit public keys following the [XMLSignature] specification.
Issuer = Issuer identification
Contains the issuer name. Includes a uid attribute that contains the unique identifier assigned to the entity by the DAISY Consortium (see section 7.8).
Keys = Set of keys secured using same encryption key
Contains a KeyInfo element (from [XMLSignature]) and one or more KeyPair or UAK elements. The KeyInfo element identifies the key used to secure all the other keys contained in this Keys element. The KeyPair elements contain public-private key pairs (see below). The UAK elements contain DAISY PDTB version 1 UAKs (see below).
KeyPair = A container for a secured public-private key pair
Contains one ds:KeyInfo element for the public key (not secured) and one EncryptedKey element (from [XMLEncryption]) for the private key.
UAK = A container for a base64-encoded PDTB v1 UAK
Contains the base64-encoded binary data of an encrypted PDTB version 1 UAK. This element has required issuerID and collectionID attributes that give the Issuer and Collection IDs of the UAK as a convenience to reading systems. The UAK element is provided as a mechanism for securely transmitting PDTB1 UAKs to reading systems that support both PDTB standards. Support for this is not required in any reading system, but is recommended for those that support both PDTB standards, since this can simplify the process of migrating from version 1 to version 2.

All keys must be given unique names by the issuer. See section 7.8 for details. Key names are given in the ds:KeyName child of the appropriate ds:KeyInfo element.

6.2 Authorization object model

The authorization object contains:

  • Identification of the entity issuing the authorization
  • Identification of the book with which it is associated
  • Rights data
  • The content encryption key(s) for the book, secured using one or more authorization key(s)

It uses elements from the [XMLSignature], [XMLEncryption], and [ODRL] vocabularies.

The normative description of the syntax for this object is the XML schema instance AuthObj.xsd. A non-normative example document is given in BookAuthorization.xml. What follows is a normative prose description of the object’s syntax and semantics.

BookAuthorization = container for authorization object
Contains one Issuer element, one Book element, one ODRL Rights element, and zero or more Keys elements.
Issuer = Issuer identification
Content is the issuer name. Includes a uid attribute that contains the unique identifier assigned to the entity (see section 7.8).
Book = container for book identification data
Includes a uid attribute that matches the uid of the DTB (dc:identifier item).
Rights = ODRL rights expression
See rights expression section for details.

Keys = content key(s) secured using a single authorization key, plus encrypted rights information
Contains a single KeyInfo element (from [XMLSignature]) to identify the key required to process this authorization, followed by one or more ContentKey elements to present the secured content keys. Content keys are AES keys. Also included is a single EncryptedRights element, giving an encrypted version of the rights expression (see below).

The KeyInfo element can also contain an optional child element KeyRequestURI. The content of this element is a URI. The media-type attribute on this element indicates the nature of the URI target. A value of “application/x-pdtbkxo+xml” indicates that the URI points to a PDTB2 key exchange object; a value of “application/soap+xml” indicates that the URI points to a server that can accept key requests using the SOAP protocol as described in this specification.

ContentKey = a specific encrypted content key applied to a specific media type
Contains an EncryptedKey element (from [XMLEncryption]) containing a content key secured using the key given in the KeyInfo element of the Keys element. The media attribute on ContentKey indicates which DTB media type(s) are encrypted using this key. Accepted values are “text”, “audio”, “image”, and “all”.

The EncryptedKey element must include the following children: EncryptionMethod, CipherData, and CarriedKeyName. These are defined in [XMLEncryption].

EncryptedRights = container for the encrypted rights expression and the key used to encrypt it
Contains a single EncryptedKey element and a single EncryptedData element (from [XMLEncryption]). The EncryptedData element contains the encrypted version of the Rights element of this authorization object. The EncryptedKey element holds the key used to perform this encryption, and is secured using the key given in the KeyInfo element of the Keys element.

A reading system might process an authorization object in this fashion:

  1. Confirm that Book refers to the protected DTB that the system is trying to decrypt
  2. Look up the decryption keys referenced by the /BookAuthorization/Keys/ds:KeyInfo element. Process using the first Keys element that identifies a key that the reading system has on its keyring. If no keys are available to the reading system, it should take steps to acquire one (possibly via the KeyRequestURI), or fail.
  3. Once the correct decryption key has been identified and/or acquired, use it to decrypt the rights expression in /BookAuthorization/Keys/xe:EncryptedData. If this does not match the unencrypted form, notify the user and continue.
  4. Again, once the correct decryption key has been identified and/or acquired, use it to decrypt each of the content keys located in the /BookAuthorization/Keys/ContentKey elements. Associate the media and xe:CarriedKeyName with each of these content keys, since they will be needed to determine which key to use when decrypting content.
  5. Store any rights information that might be necessary when determining playback behaviors.
  6. Decrypt and play the DTB.

6.3 Encrypting keys

The encryption of a key consists of two main tasks:

  1. obtaining an octet representation of the key, and
  2. encrypting the octet representation of the key using the selected key encryption key and algorithm.
6.3.1 Octet representation of Keys

The following types of keys may require encryption for compliance with this specification:

  • Symmetric 128 bit keys of the AES algorithm
  • RSA private keys

The following two subsections describe how to obtain octet representations of these two types of keys.

Given a key K, the octet representation of key K is denoted OCR(K).

The symmetric algorithm used in PDTB2 is AES. The keys of this algorithm consist of a sequence of octets 128 bits long (i.e. 16 octets). When an octet representation of symmetric keys is necessary, the octets of the keys must be used directly.

A RSA private key consists of 7 non-negative integers:

  • the modulus (modulus or n)
  • the public exponent (publicExponent or e)
  • the private exponent (privateExponent or d)
  • the first prime factor of the modulus (prime1 or p)
  • the second prime factor of the modulus (prime2 or q)
  • the exponent of the first prime (exponent1 or dP)
  • the exponent of the second prime (exponent2 or dQ)
  • the Chinese Remainder Theorem coefficient (coefficient or qInv)

The octet representation of a RSA private key is made using ASN.1 with DER encoding as defined in [X.680] and [X.690] respectively. The ASN.1 syntax is:

RSAPrivateKey ::= SEQUENCE {
  version Version,
  modulus INTEGER,         -- n
  publicExponent INTEGER,  -- e
  privateExponent INTEGER, -- d
  prime1 INTEGER,          -- p
  prime2 INTEGER,          -- q
  exponent1 INTEGER,       -- d mod (p-1)
  exponent2 INTEGER,       -- d mod (q-1)
  coefficient INTEGER      -- (inverse of q) mod p }

Version ::= INTEGER

as specified in [PKCS #1 v2.0]. Remark that version is always 0.

6.3.2 Encryption of octet representations

The second task in encrypting a key is encrypting the octet representation as defined in section section 6.3.1 using a chosen algorithm and key. Keys must be encrypted using the RSA algorithm with a public key (n, e) as follows:

  1. Obtain the octet representation OCR(K) of key K as described in the section 6.3.1.
  2. Let k be the length in bytes of the modulus of key (n, e). Divide OCR(K) into octet sequences K1, …, Km, m>=1 each of length at most k-11 octets.
  3. Encrypt each octet sequence Ki, i=1, …, m using the RSAES-PKCS1-V1_5-ENCRYPT function found in [PKCS #1 v2.0] Section 7.2.1 Encryption Operation obtaining m cipher octet sequences RSAES-PKCS1-V_15-ENCRYPT((n, e), Ki), i=1, …, m.
  4. The cipher text representation of key K is now obtained as a concatenation of the m cipher text octet sequences:
    PKCS1-V1_5-ENCRYPT((n, e), K1) … PKCS1-V1_5-ENCRYPT((n, e), Km)

6.4 Interlibrary loan

This specification permits but does not require that libraries create or participate in interlibrary loan systems for PDTBs.

Defining precisely how such loans take place is out-of-scope for this specification. Several methods are possible. The borrowing library must in some fashion authenticate the user to the lending library. The lending library then creates an authorization object keyed to that user and passes it and the PDTB to the borrowing library, which presents both to its user. In an online context, user authentication may be done by having libraries securely exchange their public keys. Exchange of physical media with appropriate authorization objects is also feasible.

A borrowing library must not alter rights expressions attached to a PDTB by a lending library, even if the borrowing library’s standard user privileges are more lenient. Lending libraries should make plaintext rights-expression language available to borrowing libraries and to users who request and receive content via interlibrary loan.

7 Rights expression

7.1 Purpose

This section is informative.

A rights expression language expresses in a standard and computer-readable format the terms and conditions under which a piece of digital content may be used. It is not meant as a substitute for copyright language, but rather to specify which activities a reading system may allow the user to undertake with respect to digital content. These activities include (in addition to reading): excerpting, printing, selling, changing the order or speed of rendering, and others.

Rights expression occasionally overlaps with other restrictions contained in this specification. As a general rule, a rights expression grants the permission to use a document but it is the possession of decryption keys that gives one the ability to use it. Additionally, the permissions and restrictions present in a rights expression are enforced by the reading system.

If improperly implemented, these two (permission and ability) may be in conflict. For example, a document is packaged with a rights expression stating that a given party has permission to play a document. However, that party has not been previously given the decryption keys necessary to play the document, nor are the keys packaged with the document. Thus, the party has permission to play the document but not the ability.

As illustrated here, when the rights expression for a document conflicts with other mechanisms (most notably encryption), those other mechanisms take precedence. In the example above, the reading system is simply incapable of playing the document despite explicitly stated permission to do so because it does not possess the necessary keys.

This may also result in implicit restrictions on document use. That is, a reading system may be restricted from playing a document because it does not have the keys it needs, but that restriction is not stated explicitly in the rights expression. All direct and indirect users of this specification should remember that the rights expression may state only those rights and restrictions that are above and beyond the ability to process the authorization and the document itself.

7.2 Requirements for rights expression

This section is informative.

This specification chose a rights expression language able to express the following rights:

  • Control the rights to play the audio portion of a DTB
  • Control the rights to render the text portion of a DTB
  • Control the rights to render the image portion of a DTB
  • Ability to specify these rights separately or together
  • Time-limit (absolute, accumulated, or interval) any of the above
  • Specify the number of characters of text or seconds of audio that can be excerpted
  • Restrict the above rights based on name, organization, reading system, or version
  • Require the user to accept terms and conditions before using a DTB

A metarequirement of the implementation is the ability for a user to see an unambiguous statement of rights and restrictions (beyond those needed to process the authorization itself, such as possession of the necessary decryption keys).

7.3 Out-of-scope requirements

This section is informative.

The following requirements are outside the scope of rights expression in this specification and, where applicable, are met through other means:

  • Grant or restrict the ability to back up a DTB. There is no restriction on copying DTBs with their authorization information intact. Reading systems shall not save unprotected copies of DTBs except in compliance with the excerpting rules specified in the rights expression.
  • Financial transactions (e.g. purchase of a DTB). ODRL contains facilities for handling payments of fees and royalties. These will not be used in this profile.
  • Transfer (among users). ODRL contains facilities for control of the transfer of an asset among users, either for loan, sale, or grant. These will not be used in this profile.
  • Digital signature and encryption. ODRL includes provisions for the use of digital signature and XML encryption. As these are needed elsewhere in this specification, they will be handled outside of rights expression.
  • Revocation of previously granted rights.

7.4 Rights expression security

If the rights expression is not secured, rights can be changed by the end user. A plaintext rights expression must be included in all authorization objects (see section 6.2) so that the user can ascertain rights with respect to the content. An identical, encrypted copy of the rights expression must also be included within the authorization object if any of the content to which it refers is encrypted. The encrypted rights expression must be encrypted in the same manner (and using the same key) as other encrypted elements within the authorization object. Reading systems should compare the two copies and warn the user if there is a mismatch. Reading systems must honor the rights expressed in the encrypted copy only. If no encrypted copy is included (because no content is encrypted), then the reading system must use the unencrypted rights expression.

7.5 ODRL summary

This section is informative.

ODRL is divided into two parts. The expression language itself includes the core entities of the language—those that form the structure of a rights expression. The data dictionary contains the specific actions and rights that are hung on the expression language’s framework.

For example, permission is an expression language element. Child elements would specify the types of permissions, such as play, excerpt, or save as in the following ODRL fragment, which gives the user unconstrained permission to play the asset:

<permission>
 <play/>
<permission>

Named permissions are then, in turn, constrained with constraint elements, such as datetime (when a permission is valid), individual (for whom it is valid) or count (how many times it can be used). The following fragment says the asset can be played ten times:

<permission>
 
<play>
   <constraint>
      <count>10</count>
   </constraint>
 
</play>
</permission>

The condition element also affects a named permission by specifying an event that, if it becomes true, permanently renders the associated permission invalid. Conditions are not used in the DAISY PDTB2 profile.

A requirement element is associated with a named permission and specifies the set of preconditions that must be met in order to obtain the permission. Only one requirement, accept, is used in this profile. Use of the accept requirement means that the user must accept certain terms and conditions before the associated permission is granted.

Most elements may or must have an associated context in order to specify information about the parent element. These contexts usually include an identifier that must be matched in the reading system (such as a version number).

Note that in this profile, permission elements are always contained within an agreement that specifies the asset to which the permissions apply. For example:

  <agreement>
    <asset>
       <context>
         <uid>DAISY.us-nls.db58935</uid>
       </context>
    </asset>
    <permission>
      <play/>
    </permission>
 </agreement>

The agreement must be contained in a rights element, the root element for all ODRL rights expressions.

Complete information about the construction of valid rights expressions is found at [ODRL].

7.6 Rules for interpretation of rights expressions by reading systems

  1. Constraints that are expressed but cannot be honored must result in a denial of permissions.
    1. Example: The rights expression contains separate play permissions for audio and text. It contains a datetime constraint on the audio permission only, but the reading system does not have a real-time clock. Thus, the datetime constraint cannot be honored, so the audio play permission is denied. The text play permission can still be granted as it is not bound by the datetime constraint in this case.
    2. Example: The rights expression contains an individual constraint on all permissions. The reading system does not possess a user key with that name. Thus, no permissions can be granted.
  2. Unrecognized elements must also result in a denial of permissions for the individual permission under which they are expressed.
  3. Unsupported elements of ODRL (that is, elements that are valid ODRL but not a part of the PDTB2 subset) must be treated as unrecognized elements.
    1. Example: A rights expression contains a play permission with a payment requirement. payment is not supported, so the play permission must be denied. Other permissions at the same level as play are unaffected.
    2. Example: A rights expression contains a revoke clause. revoke is not supported, so the entire rights expression is invalid, because revoke is at the same level as permission.
  4. Rights expressions must always be honored if present, even if the content referred to is unencrypted. If the rights expression is deemed invalid, no use rights shall be granted.
  5. Per the section above, when a rights expression is in conflict with other security mechanisms specified in this document, those other mechanisms will by necessity take precedence.
    1. Example: The rights expression states that any subscriber to a service has play permission for a document but the reading system being used does not possess the private key used by subscribers to that service. The document cannot be played.

7.7 Definitions of supported ODRL elements

The DAISY PDTB2 profile for ODRL contains only the elements listed here. All other ODRL 1.1 elements are unsupported and must not be implemented by software or used in rights expressions accompanying digital talking books.

The published ODRL 1.1 XML schema is used unedited, but rights expressions that do not adhere to the specifications in this section will be considered invalid. For example, an <asset> element is not required by ODRL but is required by this specification, and hence must be present for the rights expression to be valid per this specification.

7.7.1 Expression language elements

  • rights: Root element for a rights expression. Required. Must contain one and only one agreement.
  • agreement: Contains the permissions granted by the producer. Required. Must contain an asset if any permissions are granted.
  • asset: Specifies the content to which this right expression applies. Required. Must contain a context element containing a uid element whose text is the uid of the DTB to which this rights expression applies. The uid must match the uid in the Book element found earlier in the authorization object.
  • permission: Permissions are the actual usages or activities allowed over the assets (e.g. play an audio asset). Required if any permissions are to be granted.
  • constraint: Constraints are limits to permissions (e.g. Play the audio for a maximum of 5 times). Optional.
  • requirement: Requirements are the obligations needed to exercise the permission. Optional. The only valid requirement element is accept (agree to terms and conditions).
  • context: Most entities in the model can support a specific context. A context, which is relative to the entity, can describe further information about that entity or the relationship between entities. Required per parent element.
  • party: Parties include end users and Rights Holders. Parties can be humans, organizations, and defined roles. End users are usually the asset consumers. Optional.
  • container: Used to logically combine permissions, constraints, conditions, and requirements. The type attribute may have a value of “and”, “ex-or”, or “in-or” for “logical and,” “exclusive-or,” or “inclusive-or,” respectively.

7.7.2 Data Dictionary elements

  1. Permission elements.All permission elements are optional and may be used unconstrained.
    • play: The act of rendering the asset into audio, text, and/or image (non-hardcopy) form. Strongly recommended for every rights expression.
    • print: The act of rendering the asset onto paper or hardcopy form. To limit the number of pages printed, the constraint and count elements may be used.
    • save: The act of saving a copy of an asset to permanent storage. Saved copy must be protected per this specification as least as strongly as the original.
    • excerpt: The act of extracting (replicating) unchanged parts (or all) of the asset for reuse into another asset.
  2. Constraint elements
    • individual: An identifiable party acting as an individual. True if reading system holds a private key with a matching name. Requires a name context element to specify the individual.
    • group: A number of identifiable parties acting as a collection of individuals. True if reading system holds a private key with a matching name. Requires a name oruid context element to specify the group.
    • hardware: An identifiable hardware device. True if reading system is a hardware reading system and holds a vendor or model private key with a matching name. Requires a name context element to specify the device name or a version context element to specify the hardware version.
    • software: An identifiable software application. True if reading system is a software reading system and holds a vendor or model private key with a matching name. Requires a name context element to specify the software name or a version context element to specify the software version..
    • range: A numeric range indicating the minimum/maximum values of the corresponding entity that the constraint applies to. Must contain one or both subelements min and max. Meaning depends on the constraining element (such as datetime, unit, or version).
    • datetime: A date and/or time-based range. Use [ISO8601]-compliant dates and times.
    • accumulated: The maximum period of metered usage time. Uses [ISO8601]-compliant time amounts.
    • interval: Recurring period of time in which the rights can be exercised. Uses [ISO8601]-compliant dates and times.
    • format: Used to specify a permission or constraint on only a single media type. Specified media type must be present in the DTB manifest.
    • unit: Specification of constraints on the whole asset or sub-parts of the asset.
      • Optional attribute: pdtb2:NumberOfCharacters. Used with a constrained print or excerpt permission.
    • count: A numeric count indicating the number of times the corresponding permission may be exercised. May be a child of a unit constraint.
  3. Requirement elements
    • accept: User must agree to rights and conditions (specified by the document).
      • Required attribute: uri. Value is a reference to a SMIL presentation of the terms and conditions. If supporting this element, the reading system shall implement a mechanism for a yes-or-no response from the user, where a “yes” response indicates acceptance of the terms. A “no” response indicated rejection of the terms and shall cause the reading system to fail to grant the associated permission.
  5. Context elements
    • uid: The unique identifier for the entity.
    • name: The general name given to the entity.
    • remark: General comments or description about the entity, contained as the element’s text.
    • date: The date/time related to the entity. Uses [ISO8601]-compliant dates and times.
    • service: A link to the service providing the entity.
    • version: The version of the entity.

7.8 Identifiers

Context elements requiring identifiers should draw those values from well-established vocabularies.

  • format: Media type used in DTB manifest. Should refer to the media type matching the resource under control.
  • uid: Existing DTB uid (dc:Identifier)
  • name: Fully qualified user, group, collection, or other identifier used as a private key name, e.g.. DAISY.us-rfbd.c0001.
  • date: Per ISO8601.
  • service: Fully qualified DAISY-issued service identifier, e.g. DAISY.us-nls or DAISY.ca-cnib
  • version: The version of the entity. This is determined by the entity’s manufacturer. Platform shall return a matching string.
  • remark: General comments or description about the entity, contained as the element’s text.
  • unit:
    • Number of characters: use pdtb2:NumberOfCharacters
    • Amount of time: per [ISO8601]

7.9 Examples

The examples in this section are informative, not normative.

7.9.1 Example 1

Unrestricted playback/view of specified DTB audio and text, with print permission restricted to 10,000 characters.

<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
xmlns:pdtb="http://www.daisy.org/PTDB/2005/RightsExpression">
  <o-ex:agreement>
    <o-ex:asset>
       <o-ex:context>
         <o-dd:uid>DAISY.us-nls.db58935</o-dd:uid>
       </o-ex:context>
    </o-ex:asset>
    <o-ex:permission>
       <o-dd:play/>
       <o-dd:display/>
       <o-dd:print>
         <o-ex:constraint>
           <o-dd:unit o-ex:type="pdtb2:NumberOfCharacters">
              <o-ex:constraint>
                <o-dd:count>10000</o-dd:count>
              </o-ex:constraint>
           </o-dd:unit>
         </o-ex:constraint>
       </o-dd:print>
    </o-ex:permission>
  </o-ex:agreement>
</o-ex:rights>

7.9.2 Example 2

Playback permission, plus limited excerpting permission (1 hour of audio), with acceptance of conditions required for either (because the requirement element is at the same level as the permissions).

<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
xmlns:pdtb="http://www.daisy.org/PDTB/2005/RightsExpression">
  <o-ex:agreement>
    <o-ex:asset>
       <o-ex:context>
         <o-dd:uid>DAISY.us-nls.db58935</o-dd:uid>
       </o-ex:context>
    </o-ex:asset>
    <o-ex:permission>
       <o-dd:play />
       <o-dd:excerpt>
         <o-ex:constraint>
            <o-dd:format>application/x-pdtbmpeg</o-dd:format>
           <o-ex:constraint>
              <o-dd:accumulated>P1H</o-dd:accumulated>
           </o-ex:constraint>
         </o-ex:constraint>
       </o-dd:excerpt>
       <o-ex:requirement>
         <o-dd:accept uri="file:///terms.smil" />
       </o-ex:requirement>
    </o-ex:permission>
  </o-ex:agreement>
</o-ex:rights>

7.9.3 Example 3

Date (not after 31 Dec 2006) and hardware version restricted playback. Must meet both constraints to playback audio. Note that reading systems with no real time clock will not allow any playback, as the date/time restriction cannot be honored.

<?xml version="1.0" encoding="UTF-8"?>
<o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX"
xmlns:o-dd="http://odrl.net/1.1/ODRL-DD"
xmlns:pdtb="http://www.daisy.org/PDTB/2005/RightsExpression">
  <o-ex:agreement>
    <o-ex:asset>
       <o-ex:context>
         <o-dd:uid>DAISY.us-nls.db58935</o-dd:uid>
       </o-ex:context>
    </o-ex:asset>
    <o-ex:permission>
      <o-dd:play/>
       <o-ex:container o-ex:type="and">
         <o-ex:constraint>
           <o-dd:datetime>
              <o-dd:end>2006-12-31T23:59:59</o-dd:end>
           </o-dd:datetime>
         </o-ex:constraint>
         <o-ex:constraint>
           <o-dd:hardware>
              <o-ex:context>
                <o-dd:version>01.03.0112</o-dd:version>
              </o-ex:context>
           </o-dd:hardware>
         </o-ex:constraint>
       </o-ex:container>
    </o-ex:permission>
  </o-ex:agreement>
</o-ex:rights>

8 The DAISY public key infrastructure

8.1 Introduction

This section is informative.

Public key pairs are pairs of numbers issued to people. A person picks one of these numbers randomly and keeps it secret. That key is called the private key. The other number need not be kept secret; it can be published in the newspaper, in Internet and other network directories, and on paper. It is called the public key for that person.

The DAISY organization will issue key pairs to a large number of entities, people and automatons, in order to allow both encryption and signing applications among them. The sets of keys deployed by such an organization as DAISY, along with the rules and policies for using them, constitute a public key infrastructure.

Future versions of this specification are expected to include an infrastructure for online key exchange via certificates and online transactions.

8.2 Key pairs

The two numbers in a key pair are mathematically related such that a message encrypted with one number can be decrypted by the other number, and by no other number. This makes possible two important operations:

  1. A person named Alice can encrypt a message to Bob by finding Bob’s public key in a public place and using it to encrypt the message. Bob—because only Bob has the private key for Bob—is the only person who can decrypt and read the message.
  2. A person named Alice can sign a message by computing a hash of the message, encrypting it with her private key, and sending the result (a digital signature) to Bob, along with the original text of the message. Bob can verify the signature in the following manner: Compute the same hash of the message, decrypt the signature with Alice’s public key, and see whether the computed hash equals the decrypted result. If they are equal, two things are proven:
    1. The text of the message from Alice—the unencrypted text—was not altered in transit, because otherwise the hash values would not be equal. This is called the function or property of authentication.
    2. Alice is the source of the message, because only she possesses the private key corresponding to the public key that Bob used to decrypt the signature. This is the property of nonrepudiation. As is desirable with a pen-and-ink signature, Alice cannot claim later that she did not sign the message. Alice definitely signed it unless she has been careless with her private key.

Persons are used for clarity in the above description, but key pairs are commonly assigned to computers and computer programs as well, so “Bob” could be a server operated by an issuer and “Alice” could be a reading system.

8.2.1 Encryption applications: key exchange

Public key encryption algorithms are computationally expensive, and they are rarely used directly to encrypt messages. Instead, a random number is generated and used as a symmetric key; in the DAISY PDTB2 system, this is a 128-bit number, and the symmetric algorithm used is the standard AES. The term symmetric means that the same key is used both for encryption and for decryption. The RSA operation, in contrast, is asymmetric, because two different numbers are used.

In effect, to encrypt a message to Bob, Alice encrypts it with a random 128-bit AES key, sends Bob the encrypted message, and also sends Bob the AES key, which is itself encrypted with Bob’s public key. So long as Bob has not been careless with his own private key, he, and only he, can decrypt the AES key and thus decrypt the message.

This use of public keys to encrypt symmetric keys is a common technique called key exchange. The “message” of interest in DAISY applications is the encrypted contents of a digital talking book. Any or all parts of the book (images, text, and audio) may be encrypted or may be left in the clear.

8.2.2 Target populations

Key exchange is used by DAISY participants to “target” a particular population as the legitimate users of a protected digital talking book.

8.2.2.1 Users entitled to a collection (collection key)

These users have obtained a collection key from a particular issuer. Issuers often choose to give their users access to a large set, or collection, of books. The issuer may do this by using the same key for all titles in the collection and can then provide the collection key to users via the key exchange technique.

8.2.2.2 Users owning particular reading systems (vendor, model, and instance keys)

Books can be targeted for all users who own a reading system made by a particular vendor. Reading systems must have key pairs representing their vendor preinstalled at the time of manufacture.

Books can be targeted for all users who own a specific reading system model. Reading systems must have key pairs representing their model preinstalled at the time of manufacture. The precise definition of model is up to the vendor, but it is taken by issuers and other entities to mean a set of machines that have very similar features, including security properties, so that for digital rights management purposes all members can be considered equivalent.

Books can be targeted at a specific instance of a reading system. Software reading systems should generate a unique key pair, specific to the installation of the reading system, at install-and-setup time. Via key exchange, the public key for this instance can be used to produce digital talking books that are usable only on that specific installation of the software reading system. This “ties” the PDTB to that particular installation; the user who wants to listen to the PDTB on a different system needs to get a different key.

8.2.2.3 Patrons of a specific issuer (user keys)

Issuers may, as they do now, assign a number to a user and may then issue a key pair associated with that number. By key exchange, this user can be provided the key to a single digital talking book or to a collection and can use that key on more than one reading system. (For contrast, see the discussion of reading system instance keys.)

Note that two issuers may honor credentials from each other’s users by securely exchanging their own public keys. Such an arrangement can facilitate interlibrary loans: as long as the user names have been properly formed, each library can securely exchange keys with its own users and with the users of the other library.

8.2.3 Transmission of keys

Keys and key pairs can be obtained and stored via two mechanisms: authorization objects and key exchange objects. Both objects are processed by reading systems, which can persistently store the keys on a “key ring.” (See the reading system behavior section for more details on key storage.)

8.2.4 Authorization objects

Authorization objects are made to accompany particular digital talking books. For instance, a common delivery method will be to make a CD containing one or more protected digital talking books, each one having a corresponding authorization object.

8.2.5 Key exchange objects

Key exchange objects exist entirely for the purpose of delivering keys from one entity to another.

8.3 Examples

The examples in this section are informative, not normative.

8.3.1 Protector program operating as a web server

Prepare for fulfillment requests by generating keys and encrypting the content:

  1. Generate a random 128-bit key to be used for each data type in the book.
  2. Encrypt DTB elements with AES and the above keys.
  3. Name the keys appropriately. For example, if this is at Acme Library and the book ID is DAISY.us-acme.dt-fg991, suitable key names would be:
    • DAISY.us-acme.dt-fg991text
    • DAISY.us-acme.dt-fg991audio
  4. The encrypted book and this key can now be stored persistently until time to fulfill a request on behalf of a particular user. Both the original book ID and the key name are unique indices. (A convenient way to store the key is to create an authorization object and encrypt the key under the protector program’s own private key.)

8.3.2 Fulfillment of a book request, using a protector program

There is a user, with the library-card number 116400482, who is an authorized Acme user. The user’s formal name is DAISY.us-acme.user-116400482. (Acme has chosen to prefix its library card numbers with “user-” for readability.)

Now a request is received to prepare the preceding book for this user. A protector program will be the primary tool here. The required input data are:

  1. The book ID DAISY.us-acme.dt-fg991
  2. The user’s name DAISY.us-acme.user-116400482
  3. Rights expression for DAISY.us-acme.dt-fg991.
  4. A public key presumably associated with DAISY.us-acme.user-116400482.
  5. The named keys such as DAISY.us-acme.dt-fg991text and DAISY.us-acme.dt-fg991audio

The user presents the public key to the protector program inside a key exchange object. The protector program’s procedure is as follows:

  1. Check the format and type of the public key for DAISY.us-acme.user-116400482. As long as it is a 1024-bit number, assume it is legitimate and fetch the keys DAISY.us-acme.dt-fg991text and DAISY.us-acme.dt-fg991audio.
  2. Encrypt DAISY.us-acme.dt-fg991text and DAISY.us-acme.dt-fg991audio with the public key.
  3. Create an authorization object and store the results of step 2 in the audio and text CipherValue elements, with the corresponding key names in the CarriedKeyName elements.

Caution: The protector program may be a server conducting Internet transactions with a remote client program. All a client program has to do is present properly formatted name and a properly formatted number (a public key), and the server will give it a PDTB targeted with the supplied public key. The server should at a minimum require a user to sign in with a password before it gives up any protected content.

9 Appendices

9.1 Authorization object schema

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	targetNamespace="http://www.daisy.org/DRM/2005/BookAuthorization"
	elementFormDefault="qualified"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xe="http://www.w3.org/2001/04/xmlenc#"
    xmlns:odrlx="http://odrl.net/1.1/ODRL-EX"
    xmlns:odrld="http://odrl.net/1.1/ODRL-DD"
    xmlns:dba="http://www.daisy.org/DRM/2005/BookAuthorization"
>
	<xs:annotation>
		<xs:documentation>
			DAISY DRM:  XML Schema for authorization object
			Version 1, rev 8 (31 Jan 2006)
		</xs:documentation>
	</xs:annotation>
	
	<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
			   schemaLocation="http://www.w3.org/TR/xmlenc-core/xenc-schema.xsd" />
    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
    		   schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"  />
	<xs:import namespace="http://odrl.net/1.1/ODRL-EX"
			   schemaLocation="http://odrl.net/1.1/ODRL-EX-11.xsd" />
	<xs:import namespace="http://odrl.net/1.1/ODRL-DD"
			   schemaLocation="http://odrl.net/1.1/ODRL-DD-11.xsd" />

	<xs:element name="BookAuthorization">
		<xs:annotation>
			<xs:documentation>
				BookAuthorization = container for authorization object
				BookAuthorization (Issuer, Book, odrlx:rights, Keys*)
			</xs:documentation>
		</xs:annotation>

		<xs:complexType>
			<xs:sequence>
				<xs:element name="Issuer" type="dba:IssuerType" />
				
				<xs:element name="Book" type="dba:BookType" />
				
				<xs:element ref="odrlx:rights" />
				
				<xs:element name="Keys" type="dba:KeysType" minOccurs="0" maxOccurs="unbounded" />
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	
	
	<xs:complexType name="IssuerType">
		<xs:annotation>
			<xs:documentation>
				Issuer = Issuer identification
				Issuer (#PCDATA)
			</xs:documentation>
		</xs:annotation>

		<xs:simpleContent>
			<xs:extension base="xs:string">
				<xs:attribute name="uid" type="dba:IdString" />
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>
	
	<xs:simpleType name="IdString">
		<xs:annotation>
			<xs:documentation>
				IdString = data type for issue IDs (e.g., DAISY.us-Acme)
				Name parts use all allowed XML name characters except period
			</xs:documentation>
		</xs:annotation>
		<xs:restriction base="xs:string">
			<xs:pattern value="([A-Za-z0-9-_:])+(\.([A-Za-z0-9-_:])+)*" />
		</xs:restriction>
	</xs:simpleType>

	<xs:complexType name="BookType" >
		<xs:annotation>
			<xs:documentation>
				Book = container for book identification data
				Book EMPTY
			</xs:documentation>
		</xs:annotation>

		<xs:attribute name="uid" type="xs:string" />
	</xs:complexType>

	<xs:complexType name="KeysType">
		<xs:annotation>
			<xs:documentation>
				Keys = content key(s) secured using a single authorization key; also encrypted rights expression
				Keys (ds:KeyInfo, ContentKey+, EncryptedRights) 
			</xs:documentation>
		</xs:annotation>
		<xs:sequence>
			<xs:element ref="ds:KeyInfo" />
			<xs:element name="ContentKey" type="dba:ContentKeyType" maxOccurs="unbounded" />
			<xs:element name="EncryptedRights" type="dba:EncryptedRightsType" />
		</xs:sequence>
	</xs:complexType>

	<xs:complexType name="ContentKeyType">
		<xs:annotation>
			<xs:documentation>
				ContentKey = a specific encrypted content key applied to a specific media type
				ContentKey (xe:EncryptedKey)
				ATTLIST = media (all|text|audio|image)
			</xs:documentation>
		</xs:annotation>
		
		<xs:sequence>
			<xs:element ref="xe:EncryptedKey" minOccurs="1" maxOccurs="1" />
		</xs:sequence>
		<xs:attribute name="media" use="required" >
			<xs:simpleType>
				<xs:restriction base="xs:string">
					<xs:enumeration value="all" />
					<xs:enumeration value="text" />					
					<xs:enumeration value="audio" />					
					<xs:enumeration value="image" />					
				</xs:restriction>
			</xs:simpleType>
		</xs:attribute>
	</xs:complexType>
	
	<xs:complexType name="EncryptedRightsType">
		<xs:annotation>
			<xs:documentation>
				EncryptedRights = container for the encrypted rights expression and the key used to encrypt it
				EncryptedRights (xe:EncryptedKey, xe:EncryptedData)
			</xs:documentation>
		</xs:annotation>

		<xs:sequence>
			<xs:element ref="xe:EncryptedKey" minOccurs="1" maxOccurs="1" />
			<xs:element ref="xe:EncryptedData" minOccurs="1" maxOccurs="1" />
		</xs:sequence>
	</xs:complexType>

	<xs:element name="KeyRequestURI" type="dba:KeyRequestURIType" />
	
	<xs:complexType name="KeyRequestURIType">
		<xs:annotation>
			<xs:documentation>
				KeyRequestURI = URI to which a request for the key can be sent (if necessary and possible)
			</xs:documentation>
		</xs:annotation>
		<xs:simpleContent>
			<xs:extension base="xs:anyURI">
				<xs:attribute name="media-type" use="required" >
					<xs:simpleType>
						<xs:restriction base="xs:string">
							<xs:enumeration value="application/x-pdtbkxo+xml" />
							<xs:enumeration value="application/soap+xml" />					
						</xs:restriction>
					</xs:simpleType>
				</xs:attribute>
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>

</xs:schema>

9.2 Key exchange object schema

<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	targetNamespace="http://www.daisy.org/DRM/2005/KeyExchange"
	elementFormDefault="qualified"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xe="http://www.w3.org/2001/04/xmlenc#"
    xmlns:dkx="http://www.daisy.org/DRM/2005/KeyExchange"
>
	<xs:annotation>
		<xs:documentation>
			DAISY DRM:  XML Schema for key exchange object
			Version 1, rev 7 (6 Apr 2006)
		</xs:documentation>
	</xs:annotation>
	
	<xs:import namespace="http://www.w3.org/2001/04/xmlenc#"
			   schemaLocation="http://www.w3.org/TR/xmlenc-core/xenc-schema.xsd" />
    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
    		   schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"  />

	<xs:element name="KeyExchange">
		<xs:annotation>
			<xs:documentation>
				KeyExchange = document container
				KeyExchange (Issuer, (ds:KeyInfo | Keys)+)
			</xs:documentation>
		</xs:annotation>

		<xs:complexType>
			<xs:sequence>
				<xs:element name="Issuer" type="dkx:IssuerType" />
				<xs:choice maxOccurs="unbounded">
					<xs:element ref="ds:KeyInfo" />
					<xs:element name="Keys" type="dkx:KeysType" />
				</xs:choice>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	
	
	<xs:complexType name="IssuerType">
		<xs:annotation>
			<xs:documentation>
				Issuer = Issuer identification
				Issuer (#PCDATA)
			</xs:documentation>
		</xs:annotation>

		<xs:simpleContent>
			<xs:extension base="xs:string">
				<xs:attribute name="uid" type="dkx:IdString" />
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>

	<xs:simpleType name="IdString">
		<xs:annotation>
			<xs:documentation>
				IdString = data type for issue IDs (e.g., DAISY.us-Acme)
				Name parts use all allowed XML name characters except period
			</xs:documentation>
		</xs:annotation>
		<xs:restriction base="xs:string">
			<xs:pattern value="([A-Za-z0-9-_:])+(\.([A-Za-z0-9-_:])+)*" />
		</xs:restriction>
	</xs:simpleType>

	<xs:complexType name="KeysType" >
		<xs:annotation>
			<xs:documentation>
				Keys = Set of keys secured using same encryption key
				Keys (ds:KeyInfo, (xe:EncryptedKey | KeyPair)+)
			</xs:documentation>
		</xs:annotation>

		<xs:sequence>
			<xs:element ref="ds:KeyInfo" />
			<xs:choice maxOccurs="unbounded">
				<xs:element name="KeyPair" type="dkx:KeyPairType"  />
				<xs:element name="UAK" type="dkx:UAKType"  />
			</xs:choice>
		</xs:sequence>
	</xs:complexType>

	<xs:complexType name="UAKType" >
		<xs:annotation>
			<xs:documentation>
				UAK = A container for a base64-encoded PDTB v1 UAK
				UAK (#PCDATA)
				Attributes:
					issuerID = Issuer ID string from UAK
					collectionID = Collection ID string from UAK
			</xs:documentation>
		</xs:annotation>
		
		<xs:simpleContent>
			<xs:extension base="xs:base64Binary">
				<xs:attribute name="issuerID"  type="xs:string"  use="required"/>
				<xs:attribute name="collectionID" type="xs:string" use="required" />
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>
	<xs:complexType name="KeyPairType" >
		<xs:annotation>
			<xs:documentation>
				KeyPair = A container for a secured public-private key pair
				(ds:KeyInfo, xe:EncryptedKey)
			</xs:documentation>
		</xs:annotation>

		<xs:sequence>
			<xs:element ref="ds:KeyInfo" />
			<xs:element ref="xe:EncryptedKey" />
		</xs:sequence>
	</xs:complexType>

</xs:schema>

9.3 Authorization object example

<!-- Book Authorization Object sample
-->
<!-- This sample shows a book authorized using a single book collection key
     In this version, the book collection key is a symmetrical one.
-->
<BookAuthorization xmlns="http://www.daisy.org/DRM/2005/BookAuthorization"
                   xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                   xmlns:xe="http://www.w3.org/2001/04/xmlenc#"
                   xmlns:odrlx="http://odrl.net/1.1/ODRL-EX"
                   xmlns:odrld="http://odrl.net/1.1/ODRL-DD"
                   xmlns:dba="http://www.daisy.org/DRM/2005/BookAuthorization">

<!-- Issuer = Issuer identification -->
	<Issuer uid="DAISY.us-acme">Acme Library for the Print-Disabled</Issuer>

<!-- Book = container for book identification data -->
	<Book uid="DAISY.us-acme.abcd-1234-2006" />

<!-- odrlx:rights = plaintext version of rights expression -->
	<odrlx:rights xmlns:ddrm="http://www.daisy.org/DRM/2005/RightsExpression">
	    <odrlx:agreement>
	        <odrlx:asset>
	            <odrlx:context>
	                <odrld:uid>DAISY.us-acme.abcd-1234-2006</odrld:uid>
	            </odrlx:context>
	        </odrlx:asset>
	        <odrlx:permission>
	            <odrld:play/>
	            <odrld:display/>
	            <odrld:print>
	                <odrlx:constraint>
	                    <odrld:unit odrlx:type="ddrm:NumberOfCharacters">
	                        <odrlx:constraint>
	                            <odrld:count>10000</odrld:count>
	                        </odrlx:constraint>
	                    </odrld:unit>
	                </odrlx:constraint>
	            </odrld:print>
	        </odrlx:permission>
	    </odrlx:agreement>
	</odrlx:rights>

<!-- Keys = content key(s) secured using a single authorization key; also encrypted rights expression -->
	<Keys>
	<!-- The key that unlocks this authorization -->
		<ds:KeyInfo>
			<ds:KeyName>DAISY.us-acme.c0001</ds:KeyName>
			<dba:KeyRequestURI media-type="application/soap+xml">http://drm.acme.org/keys</dba:KeyRequestURI>
		</ds:KeyInfo>

	<!-- The content keys, encrypted using our key -->
		<ContentKey media="text">
			<xe:EncryptedKey>
				<xe:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
				<xe:CipherData>
					<xe:CipherValue>0000</xe:CipherValue>
				</xe:CipherData>
				<xe:CarriedKeyName>DAISY.us-acme.abcd-1234-2006-text</xe:CarriedKeyName>
			</xe:EncryptedKey>
		</ContentKey>
		<ContentKey media="audio">
			<xe:EncryptedKey>
				<xe:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
				<xe:CipherData>
					<xe:CipherValue>0000</xe:CipherValue>
				</xe:CipherData>
				<xe:CarriedKeyName>DAISY.us-acme.abcd-1234-2006-audio</xe:CarriedKeyName>
			</xe:EncryptedKey>
		</ContentKey>
		
	<!-- The ODRL from above, encrypted using a key that has been encrypted using our authorization key -->
		<EncryptedRights>
			<xe:EncryptedKey>
				<xe:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
				<xe:CipherData>
					<xe:CipherValue>0000</xe:CipherValue>
				</xe:CipherData>
			</xe:EncryptedKey>

			<xe:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element">
				<xe:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
				<xe:CipherData>
					<xe:CipherValue>0000</xe:CipherValue>
				</xe:CipherData>
			</xe:EncryptedData>
		</EncryptedRights>
	</Keys>
</BookAuthorization>

9.4 Key exchange object example

<!-- Key Exchange Object sample
-->
<!-- This sample shows a symmetric key and a public/private key pair encrypted by the public keys for 
     three different reading system models.
-->
<KeyExchange xmlns="http://www.daisy.org/DRM/2005/KeyExchange"
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
          xmlns:xe="http://www.w3.org/2001/04/xmlenc#">

<!-- Issuer = Issuer identification -->
	<Issuer uid="DAISY.us-acme">Acme Library for the Print-Disabled</Issuer>

	<Keys>
	<!-- The ds:KeyInfo element names the key used to secure everything in this Keys container -->
		<ds:KeyInfo>
			<ds:KeyName>DAISY.it-italoCorp.italianPlayer</ds:KeyName>
		</ds:KeyInfo>

	<!-- The symmetric key is contained in an xe:EncryptedKey element -->
		<xe:EncryptedKey>
			<xe:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
		<!-- CipherData here is AES key, as described in Ole's "Encrypting Keys" document -->
			<xe:CipherData>
				<xe:CipherValue>0000</xe:CipherValue>
			</xe:CipherData>
			<xe:CarriedKeyName>DAISY.us-acme.c0001</xe:CarriedKeyName>
		</xe:EncryptedKey>

	<!-- KeyPair = A container for a secured public-private key pair -->
		<KeyPair>
		<!-- The ds:KeyInfo child is the public key (not secured) -->
			<ds:KeyInfo>
				<ds:KeyValue>
					<ds:RSAKeyValue>
						<ds:Modulus>0000</ds:Modulus>
						<ds:Exponent>0000</ds:Exponent>
					</ds:RSAKeyValue>
				</ds:KeyValue>
				<ds:KeyName>DAISY.us-acme.i9876</ds:KeyName>
			</ds:KeyInfo>
		<!-- The xe:EncryptedKey child contains the private key, encrypted by the key identified above -->
			<xe:EncryptedKey>
			<!-- The CipherData here is private key, as described in Ole's "EncryptingKeys" document -->
				<xe:CipherData>
					<xe:CipherValue>0000</xe:CipherValue>
				</xe:CipherData>
				<xe:CarriedKeyName>DAISY.us-acme.i9876</xe:CarriedKeyName>
			</xe:EncryptedKey>
		</KeyPair>
	</Keys>

<!-- Same keys secured for fi-finniCorp.finnishPlayer -->
	<Keys>
		<ds:KeyInfo>
			<ds:KeyName>DAISY.fi-finniCorp.finnishPlayer</ds:KeyName>
		</ds:KeyInfo>		
		<xe:EncryptedKey>
			<xe:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
			<xe:CipherData>
				<xe:CipherValue>0000</xe:CipherValue>
			</xe:CipherData>
			<xe:CarriedKeyName>DAISY.us-acme.c0001</xe:CarriedKeyName>
		</xe:EncryptedKey>

		<KeyPair>
			<ds:KeyInfo>
				<ds:KeyValue>
					<ds:RSAKeyValue>
						<ds:Modulus>0000</ds:Modulus>
						<ds:Exponent>0000</ds:Exponent>
					</ds:RSAKeyValue>
				</ds:KeyValue>
				<ds:KeyName>DAISY.us-acme.i9876</ds:KeyName>
			</ds:KeyInfo>
			<xe:EncryptedKey>
				<xe:CipherData>
					<xe:CipherValue>0000</xe:CipherValue>
				</xe:CipherData>
				<xe:CarriedKeyName>DAISY.us-acme.i9876</xe:CarriedKeyName>
			</xe:EncryptedKey>
		</KeyPair>
	</Keys>
	
<!-- Same keys secured for th-thaiCorp.thaiPlayer -->
	<Keys>
		<ds:KeyInfo>
			<ds:KeyName>DAISY.th-thaiCorp.thaiPlayer</ds:KeyName>
		</ds:KeyInfo>
			
		<xe:EncryptedKey>
			<xe:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
			<xe:CipherData>
				<xe:CipherValue>0000</xe:CipherValue>
			</xe:CipherData>
			<xe:CarriedKeyName>DAISY.us-acme.c0001</xe:CarriedKeyName>
		</xe:EncryptedKey>

		<KeyPair>
			<ds:KeyInfo>
				<ds:KeyValue>
					<ds:RSAKeyValue>
						<ds:Modulus>0000</ds:Modulus>
						<ds:Exponent>0000</ds:Exponent>
					</ds:RSAKeyValue>
				</ds:KeyValue>
				<ds:KeyName>DAISY.us-acme.i9876</ds:KeyName>
			</ds:KeyInfo>
			<xe:EncryptedKey>
				<xe:CipherData>
					<xe:CipherValue>0000</xe:CipherValue>
				</xe:CipherData>
				<xe:CarriedKeyName>DAISY.us-acme.i9876</xe:CarriedKeyName>
			</xe:EncryptedKey>
		</KeyPair>
	</Keys>

</KeyExchange>


<!-- Key Exchange Object sample #2
-->
<!-- This sample shows how to send just a public key; in this case the public key of the library
-->
<KeyExchange xmlns="http://www.daisy.org/DRM/2005/KeyExchange"
          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
          xmlns:xe="http://www.w3.org/2001/04/xmlenc#">

<!-- Issuer = Issuer identification -->
	<Issuer uid="DAISY.us-acme">Acme Library for the Print-Disabled</Issuer>

<!-- ds:KeyInfo contains the actual public key data -->
	<ds:KeyInfo>
		<ds:KeyValue>
			<ds:RSAKeyValue>
				<ds:Modulus>0000</ds:Modulus>
				<ds:Exponent>0000</ds:Exponent>
			</ds:RSAKeyValue>
		</ds:KeyValue>
		<ds:KeyName>DAISY.us-acme</ds:KeyName>
	</ds:KeyInfo>

</KeyExchange>

9.5 References