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.
This specification is approved by the DAISY Consortium.
Copyright laws vary from country to country and thus some organizations are required to adhere to copyright and content protection requirements that may be very different. In many countries there are no requirements to encrypt content distributed to blind and print disabled persons. However, there are situations where technological measures must be used to protect the content.
Only in countries where technological measures are required to protect intellectual property, the DAISY Consortium recommends the use of PDTB2, the Protected Digital Talking Book Specification. Although PDTB2 prevents unauthorized use of DTBs, it does not prevent exchange between cooperating and authorized libraries. The DAISY Consortium has developed this system which encrypts content to support libraries and agencies which operate under mandated requirements to use technological measures to protect intellectual property.
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.
All language in this specification is normative except for sections specifically designated as informative.
Common understanding of certain terms is a prerequisite for the correct understanding of this specification. These terms are defined in the following list:
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].
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.
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.
Computer-readable dates and times in protected digital talking books must be expressed according to [ISO8601].
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.
All URIs called for by this specification must conform to [RFC3986].
XML objects defined by this specification are expressed via [W3CXMLSchema].
The key exchange object defined in this specification uses elements from [XMLSignature].
The key exchange and authorization objects defined in this specification use elements from [XMLEncryption].
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.
This section is informative.
Four entities are involved in transactions surrounding DAISY PDTBs:
At the highest and simplest level, the steps in a secured transmission of a DAISY PDTB are:
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 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 original 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). This file is unencrypted.
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:
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.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.
The facade book must be a valid Z39.86 DTB. As such, it will have its own package file. This package file must:
Book metadata in the unprotected package file must be unchanged from the protected package file except for:
All of these must be changed if the content of the facade book does not match that of the protected book.
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). The reading system determines whether a given media type in a book is encrypted by checking the book's authorization object for the presence of a content encryption key for that media type.
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 section 4.3.
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). The reading system determines whether a given media type in a book is encrypted by checking the book's authorization object for the presence of a content encryption key for that media type.
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.
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].
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.
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:sourceDatencc:setInfoncc:sourcePublisherncc:sourceEditionncc:sourceRightsncc:sourceTitleAll 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-versionprod:pdtb2-authFileprod:pdtb2-authRequestURIprod:pdtb2-nccFileThe 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.
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.
<xe:EncryptedData> elementA 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> <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:
<CipherData><CipherValue> element holding the encrypted data <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> <element name='CipherValue' type='base64Binary'/>
Contains: The base64 encoded encrypted data
Syntax: <xe:CipherValue>...content...</xe:CipherData>
Attributes: None
Valid inside: <CipherData>
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:
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:
<ncx> element, effectively encrypting the entire NCX file<navLabel> elements in the NCX file. In this mode the labelling information in the NCX file is encrypted, but the navigational structure remains unencryptedThe SMIL files of a Z39.86 DTB may be encrypted in one of two ways:
<smil> element, effectively encrypting the entire SMIL file<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:
<dtbook> element, effectively encrypting the entire textual content filePDTB2 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 file of a DAISY 2.02 DTB may be encrypted in one of two ways:
<html> element, effectively encrypting the entire NCC file<a> elements in the NCC file. In this mode the text in the NCC file is encrypted, but the navigational structure remains unencryptedThe 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:
<html> element, effectively encrypting the entire textual content fileFor each <EncryptedData> element to be decrypted, the decryptor must:
<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. <EncryptedData> element. <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 replacementFor each element or element content to be encrypted as an <EncryptedData> element, the encryptor must:
<EncryptedData> element:
<EncryptedData> element as appropriate<CipherData> element and append a single <CipherValue> element whose content encrypted data obtained in 3. encoded using base64.<CipherData> element as a child of the <EncryptedData> element.<EncryptedData> element constructed in step 4.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. 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. Hardware reading systems should also store an instance key unique to each individual reading system.
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.
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.
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.
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.
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.
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:
This information should be made available to users before purchase of a reading system.
Issuers should inform users:
PDTBs should contain language free of encryption and available to the user informing users:
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.
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.
Reading system returns to normal operation, perhaps using keys from the authorization object as needed.
This example is informative, not normative.
Authorization from a library for playback of its collection on a specific model of DAISY reading system.
Bob receives a private key that will allow him to play books from the Zenith Library collection and adds it to his player's keyring:
Bob receives a CD containing a book from the Zenith Library collection and reads it.
The key exchange object must contain:
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 containerIssuer 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 identificationuid 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 keyKeyInfo 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 pairds: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 UAKissuerID 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.
The authorization object contains:
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 objectIssuer element, one Book element, one ODRL Rights element, and zero or more Keys elements.Issuer = Issuer identificationuid attribute that contains the unique identifier assigned to the entity (see section 7.8).Book = container for book identification datauid attribute that matches the uid of the DTB (dc:identifier item).Rights = ODRL rights expressionKeys = content key(s) secured using a single authorization key, plus encrypted rights informationContains 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.
ContentKey = a specific encrypted content key applied to a specific media typeContains 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 itContains 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:
Book refers to the protected DTB that the system is trying to decrypt/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./BookAuthorization/Keys/xe:EncryptedData. If this does not match the unencrypted form, notify the user and continue./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.The encryption of a key consists of two main tasks:
The following types of keys may require encryption for compliance with this specification:
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 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.
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:
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.
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.
This section is informative.
This specification chose a rights expression language able to express the following rights:
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).
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:
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.
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].
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.individual constraint on all permissions. The reading system does not possess a user key with that name. Thus, no permissions can be granted.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.revoke
clause. revoke is not supported, so the entire rights expression is invalid, because revoke is at the same level as permission.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.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.
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.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.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.
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.accept: User must agree to rights and conditions (specified by the document).
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.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.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-cnibversion: 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:
pdtb2:NumberOfCharactersThe examples in this section are informative, not normative.
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>
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>
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>
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.
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:
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.
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.
Key exchange is used by DAISY participants to "target" a particular population as the legitimate users of a protected digital talking book.
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.
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.
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.
Key pairs can be obtained and stored via key exchange objects (KXOs). KXOs are processed by reading systems, which should persistently store the keys on a "key ring." (See the reading system behavior section for more details on key storage.) KXOs exist entirely for the purpose of delivering keys from one entity to another.
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.
The examples in this section are informative, not normative.
Prepare for fulfillment requests by generating keys and encrypting the content:
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:
DAISY.us-acme.dt-fg991DAISY.us-acme.user-116400482DAISY.us-acme.dt-fg991.A public key presumably associated with
DAISY.us-acme.user-116400482.
DAISY.us-acme.dt-fg991text
and DAISY.us-acme.dt-fg991audioThe user presents the public key to the protector program inside a key exchange object. The protector program's procedure is as follows:
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.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.
<?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>
<?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>
<!-- 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>
<!-- 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>
STATUS: Version 2.0 Approved, Specification for DAISY Protected Digital Talking Book
Last update: 13 March 2007