eXtensible rights Markup Language (XrML) 2.0 Specification
Part I: Primer

20 November 2001

Available formats: HTML and PDF. In case of a discrepancy, the HTML is considered definitive. 

NOTE: To enable interactive browsing of the XrML schemas and examples, the XrML Specification and its companion Example Use Cases document use an HTML version that leverages the XML access functionality provided by the W3C Xpath recommendation. For this reason, you need to view these HTML documents with a browser that supports that recommendation (for example, Internet Explorer Version 6.0). If your browser does not support this functionality, please view the PDF versions of those documents.

Copyright (C) 2001 ContentGuard Holdings, Inc. All rights reserved. "ContentGuard" is a registered trademark and “XrML”, “eXtensible rights Markup Language”, the XrML logo, and the ContentGuard logo are trademarks of ContentGuard Holdings, Inc. All other trademarks are properties of their respective owners.

XrML 2.0 Specification Terms of Use
 

READ THESE TERMS OF USE (“AGREEMENT”) CAREFULLY BEFORE USING THE XrML 2.0 SPECIFICATION (“SPECIFICATION”).  ATTEMPTING TO USE ANY PART OF THE SPECIFICATION WILL INDICATE THAT YOU HAVE READ, UNDERSTOOD, AND ACCEPTED THESE TERMS.  DO NOT PROCEED IN ANY SUCH MANNER UNLESS YOU ARE ABLE AND WILLING TO ENTER INTO AND COMPLY WITH THIS AGREEMENT. CONTENTGUARD STRONGLY RECOMMENDS THAT YOU KEEP A COPY OF THIS AGREEMENT IN A SAFE PLACE FOR FUTURE REFERENCE.  IF YOU DO NOT AGREE TO THESE TERMS, THEN DO NOT USE OR COPY THE SPECIFICATION AND IMMEDIATELY DESTROY ANY COPY OF THE SPECIFICATION YOU MAY HAVE OBTAINED,

  1. WARRANTY DISCLAIMER.  THE XrML SPECIFICATION IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED REGARDING OR RELATING TO THE SPECIFICATION INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

  2. LIMITATION OF LIABILITY.  CONTENTGUARD SHALL NOT BE LIABLE FOR ANY DAMAGES, DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES (INCLUDING, WITHOUT LIMITATION, LOST PROFITS BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR OTHER INFORMATION OR OTHER LOSS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THIS AGREEMENT, THE USE OR DISTRIBUTION OF THE SPECIFICATIONS OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. CONTENTGUARD SHALL NOT BE LIABLE FOR ANY CLAIM PERTAINING TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN THE SPECIFICATIONS. IN THIS PARAGRAPH "CONTENTGUARD" INCLUDES ITS SUBSIDIARIES, PARENTS, EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, SUBCONTRACTORS, SERVICE PROVIDERS AND SUPPLIERS.

  3. Rights.  No rights or licenses are granted expressly, by implication, estoppel or otherwise, to any patent rights, trademarks, trade secrets or other rights in any jurisdiction other than those expressly set forth in this Agreement.

  4. Miscellaneous Provisions.  In your use or distribution of the Specification you agree to comply strictly with all applicable import and export laws and regulations of the United States and other countries. The laws of the State of Maryland and the intellectual property laws of the United States shall govern this Agreement.

  5. Feedback.  If you wish to provide any feed back to ContentGuard concerning the Specification your feedback is subject to a supplemental agreement.  PLEASE DO NOT PROVIDE ANY FEEDBACK UNLESS AND UNTIL YOU READ AND AGREE TO THE SUPPLEMENTAL AGREEMENT.   

Supplemental Agreement On Providing Feedback to ContentGuard Concerning XrML 2.0

READ THE TERMS OF THIS SUPPLEMENTAL AGREEMENT (“AGREEMENT”) CAREFULLY BEFORE PROVIDING CONTENTGUARD WITH ANY INPUT, SUGGESTIONS, COMMENTS, SUGGESTED MODIFICATIONS, IDEAS OR OTHER FEEDBACK CONCERNING THE XrML 2.0 SPECIFICATION (“FEEDBACK”).  PROVIDING FEEDBACK WILL INDICATE THAT YOU HAVE READ, UNDERSTOOD, AND ACCEPTED THESE TERMS AND CONDITIONS.  DO NOT PROVIDE FEEDBACK UNLESS YOU ARE ABLE AND WILLING TO ENTER INTO AND COMPLY WITH THIS AGREEMENT. CONTENTGUARD STRONGLY RECOMMENDS THAT YOU COPY, PRINT OUT OR DOWNLOAD A COPY OF THIS AGREEMENT AND KEEP IT IN A SAFE PLACE FOR FUTURE REFERENCE. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, THEN PLEASE DO NOT PROVIDE ANY FEEDBACK.

 1. Right to Use Feedback by ContentGuard.  ContentGuard would like your Feedback concerning the Specification. You can contact ContentGuard with Feedback through the XrML.org website.  In the event that you provide Feedback in any way, you agree that ContentGuard shall have a non-exclusive, unlimited, sub-licensable, worldwide, perpetual, irrevocable, non-terminable, non-cancelable right to use, copy and exploit in any manner all such Feedback, including but not limited to, use by incorporation of Feedback into the Specification or computer programs and documentation for assignment, license, or other transfer to third parties and the right to use, in any manner and for any purpose, any information gained as a result of your Feedback.  

 2. Right to Provide Feedback.  You warrant that you have the right to provide the Feedback and, if you are providing the Feedback on behalf of an entity, you warrant that you have the right to provide it on behalf of the entity. 


Abstract

This specification defines the eXtensible rights Markup Language (XrML), a general-purpose language in XML used to describe the rights and conditions for using digital resources.  

Status of this Document

Feedback and suggestions are welcome. Public discussion on XrML and its applications takes place on the discussion forum at http://www.xrml.org/forum.asp. Please report errors and provide comments on this document to the current editor at http://www.xrml.org/xrml_comments.asp.

Quick Table of Contents

Part 1: Primer

1 About XrML

2 XrML Concepts

3 Extensibility of the XrML Core

4 Conformance

Part II: XrML Core Schema

5 Technical Reference

Part III: Standard Extension Schema

6 Standard Extensions

Part IV: Content Extension Schema

7 About the Content Extension

8 Content Extension Data Model

9 Content Extension Elements

Part V: Appendices

A XrML Schemas

B Glossary

C Index of Types and Attributes

D References

E Acknowledgements

Full Table of Contents for Part I: Primer

Preface

Content of this Specification

Scope of this Document

Dependencies on Other Specifications

Diagram Conventions

1 About XrML

1.1 The Need for a Language

1.2 Requirements for a  Language that Describes Rights and Conditions

1.3 Benefits of XrML

1.4 Design Goals and Principles

2 XrML Concepts

2.1 License

2.2 Grant

2.3 Principal

2.4 Right

2.5 Resource

2.6 Condition

3 Extensibility of the XrML Core

3.1 Common XML Schema Extensibility Mechanisms

3.1.1 XML Schema Element Substitution Groups

3.1.2 XML Schema Type Substitution

3.1.3 XML Schema "any" Element

3.1.4 Using the Three Extension Mechanisms

3.2 Documenting Schema Extensions

4 Conformance

4.1 Markup Conformance

4.2 Application Conformance

Preface

Content of this Specification

This specification defines the eXtensible rights Markup Language (XrML), a general-purpose language in XML used to describe the rights and conditions for using digital resources. It also provides mechanisms to ensure message integrity and entity authentication within XrML documents. The specification consists of the following parts:

Scope of this Document

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

One of the goals of this document is to develop an approach and language that can be used throughout industry to stipulate rights to use digital resources and the conditions under which those rights may be exercised. This document does not address the agreements, coordination or institutional challenges involved in achieving that goal.

Dependencies on Other Specifications

This specification depends on the following other specifications:

Extensible Markup Language (XML) 1.0 Specification
T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10 February 1998.
 http://www.w3.org/TR/REC-xml
Namespaces in XML

T. Bray, D. Hollander, A. Layman, 14 January 1999.

http://www.w3.org/TR/REC-xml-names

XML Schema
David C. Fallside, Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, Paul V. Biron, Ashok Malhotra, 02 May 2001
http://www.w3.org/XML/Schema

For a list of other related specifications, see  Appendix D, References.

Diagram Conventions

The diagrams in this specification use the following conventions:
el_single.gif A single mandatory  element. 
A single mandatory element with child elements.
el_pcdata.gif A single mandatory element containing Parsed Character Data (#PC-Data). The content may be simple content or mixed complex content.
el_optional.gif A single optional element. 
el_multiple.gif A multiple optional element (in this case, zero to infinity) with child elements.
el_any.jpg A placeholder for any element from any namespace.
el_pcdata.gif A complex type.
A sequence. Solid lines connect this symbol to required elements within the sequence. Dotted lines connect this symbol to optional elements in the sequence.
A choice.

Note: These diagrams were generated using Altova XML Spy Integrated Development Environment. For more information, see the Altova web site, http://www.xmlspy.com.

1 About XrML

This chapter provides an overview of XrML. It provides a basic definition of XrML, describes the need that XrML is meant to address, and explains design goals for the language.

1.1 The Need for a Language

The reality of the Internet and the need to control the use of digital content and digital services has fueled the development of technologies that attempt to manage, secure, control, and automate the flow of content and the access of services. Digital Rights Management (DRM) is the common term associated with such technologies. Other technologies such as Digital Asset Management, Content Management, and Trust Systems are also getting incorporated into the DRM workflow. The DRM space is becoming more important and, in many cases, required to enable certain business models.

If we consider the lifecycle or workflow for digital content and services, we see that exchange of rights information is required between the players or entities in the workflow or at each step of the lifecycle. For example, a content user needs to know what rights or permissions are associated with a piece of content.

We also realize that expressing rights can be simple or very complex. For example:

Rights expressions get more complex when we try to mimic the use and distribution of content in the physical world, for example, when specifying the rights that would govern lending of a digital book, or the rights that control the giving away of an article in an electronic magazine.

Therefore, a common language that can be shared among the participants in this digital workflow is required, not only from an obvious interoperability point of view, but more so to comprehend that rights will be manipulated and changed during the digital workflow and lifecycle. For example, the usage rights for a piece of content will change as it moves among the creator, aggregator, retailer, and user.

1.2 Requirements for a  Language that Describes Rights and Conditions

As DRM technologies are developed to support a wide variety of business model and content formats, the language supporting the DRM must have wide appeal. Namely, the language must be:

1.3 Benefits of XrML

XrML is a language to specify rights. Using XrML, anyone owning or distributing digital resources (content, services, software applications) can identify the parties allowed to use those resources, the rights available to those parties, and the terms and conditions under which those rights may be exercised.

XrML has its roots in Xerox PARC’s Digital Property Rights Language (DPRL), first introduced in 1996. DPRL became XrML when the meta-language (used to construct the language) changed from lisp to XML in 1999. Since then, ContentGuard and its partners have invested additional work to enrich the language.

XrML has thus become comprehensive by providing a framework to express rights at different stages of a workflow or lifecycle, generic by defining a large body of format and business neutral terms (about 100) and using these terms to specify rights to any digital content and any digital services, and precise through the development of a grammar and processing rules that allow unique interpretation of the language. XrML is by far the most advanced and mature rights language.

Additionally, XrML exploits the advantages provided by current XML technologies:

This means that XrML can leverage XML technologies and know-how to machine-process the language, to extend the language to support new business models, and to integrate the language with other technologies and systems.

Furthermore, XrML comprehends real-life system issues such as:

1.4 Design Goals and Principles

A principal design goal for XrML 2.0 is to accommodate and support extensibility and customizability without changes to XrML 2.0 itself. To achieve this goal, the XrML 2.0 design follows the principles listed below:

Other design goals for XrML include:

XrML 2.0 itself makes use of its extensibility mechanisms internally. It is split into several parts:

Others parties may define their own extensions using existing, standard XML Schema and XML Namespace mechanisms.

2     XrML Concepts

This chapter describes the key concepts and the data model used by XrML to define rights and conditions for principals to use digital resources.

XrML 2.0 core concepts include license, grant, principal, right, resource and condition. The XrML Core defines elements for the last four of these concepts in an abstract fashion. Extensions to the XrML Core could extend these elements to address specific business applications. 

A simple XrML license looks like the following, where the keyHolder is a principal, print is a right (defined in the XrML Content Extension), digitalWork is a resource (also defined in the XrML Content Extension), and validityInterval is a condition.

A particular key holder can print an ebook located at a given URL before Christmas of 2001.

2.1 License

A key top-level construct in XrML 2.0 is a license. Conceptually, a license is the container of grants. The basic structure of a license contains the following:

Those familiar with XrML 1.x, digital certificates, and other similar structures might notice the absence of the identification of the principal or principals to whom certain rights are conveyed (e.g., ISSUEDPRINCIPALS in XrML 1.x). This notion has been flattened and regularized within the structure and terms of each individual grant.

A license can be digitally signed by the principal who issues it, signifying that the issuer does indeed bestow the grants contained therein. Syntactically, multiple issuers may sign a given license. However, no additional semantic is associated with the joint signing; it is as if each had signed a copy of the license independently

License Model

2.2 Grant

A grant is the element within the license that bestows an authorization upon some principal. It conveys to a particular principal the sanction to exercise an identified right against an identified resource, possibly subject to first fulfilling some conditions. 

Structurally, a grant consists of the following:

Grant Model

The XrML 2.0 Core defines principals, rights, resources, and conditions as abstract concepts. It is expected that extensions to the Principal, Right, Resource, and Condition types will define useable principals, rights, resources, and conditions, respectively. 

2.3 Principal

A principal encapsulates the identification of principals to whom rights are granted. Each principal identifies exactly one party. In contrast, a set of principals, such as the universe of everyone, is not a principal.

A principal denotes the party that it identifies by information unique to that individual. Usefully, this is information that has some associated authentication mechanism by which the principal can prove its identity. The Principal type supports the following identification technologies:

Principal Model

Extensions to the XrML Core could use the Principal element in any context in which a party must be identified and authenticated. For example, the Principal element could be used to identify a resource (for example, to identify and authenticate a secure service to which rights are granted).  

2.4 Right

A right is the "verb" that a principal can be granted to exercise against some resource under some condition. Typically, a right specifies an action (or activity) or a class of actions that a principal may perform on or using the associated resource.

Right Model

The XrML 2.0 Core provides a right element to encapsulate information about rights and provides a set of commonly-used, specific rights, notably rights relating to other rights, such as issue, revoke, delegate, and obtain. Extensions to the XrML Core could define rights appropriate to using specific types of resources. For instance, the XrML content extension defines rights appropriate to using digital works (for instance, play and print rights).

2.5 Resource

A resource is the "object" to which a principal can be granted a right. A resource can be a digital work (such as an e-book, an audio or video file, or an image), a service (such as an email service, or B2B transaction service), or even a piece of information that can be owned by a principal (such as a name or an email address).

Resource Model

The XrML 2.0 Core provides mechanisms to encapsulate the information necessary to identify and use a particular resource or resources that match a certain pattern. The latter allows identification of a collection of resources with some common characteristics. Extensions to the XrML Core could define resources appropriate to specific business models.  

2.6 Condition

A condition specifies the terms, conditions, and obligations under which rights can be exercised. A simple condition is a time interval within which a right can be exercised. A slightly complicated condition is to require the existence of a valid, prerequisite right that has been issued to some principal. Using this mechanism, the eligibility to exercise one right can become dependent on the eligibility to exercise other rights. Moreover, a list of conditions can be put in conjunction to form a condition requiring that the conditions all be true simultaneously. 

Condition Model

The XrML 2.0 Core defines a condition element to encapsulate information about conditions and some very basic conditions. Extensions to the XrML Core could define conditions appropriate to specific distribution models. For instance, the XrML content extension defines conditions appropriate to using digital works (for instance, watermark, destination, and renderer).

3 Extensibility of the XrML Core

The XrML Core uses XML Schema technology to enable extensibility. For further details about these mechanisms, please refer to the XML Schema Primer.

3.1 Common XML Schema Extensibility Mechanisms

Three XML Schema technologies are used commonly with XrML for extensibility:

3.1.1 XML Schema Element Substitution Groups

To extend XrML using this mechanism, define a new element with a type derived from an existing element's type and set the "substitutionGroup" schema attribute of the new element to the name of the existing element. This type of extension is the most commonly used with XrML. It is the type of extension used by licensePart, principal, right, resource, condition, and xmlPatternAbstract.

Example: Creating a timeLimit condition

	

	

To use this type of extension, use the new element in the existing element's place.

3.1.2 XML Schema Type Substitution

To extend XrML using this mechanism, define a new type derived from an existing type.

Since this type of extension is similar to element substitution groups, many people choose to use element substitution groups instead.  Both can be used in most situations.  The primary difference is that with element substitution groups, the name of the element changes, whereas with type substitution, an xsi:type attribute is used instead.

Example: Adding locationOfIssue to IssuerDetails

To use this type of extension, place the xsi:type attribute in your instance document on the element whose type you are changing.

3.1.3 XML Schema "any" Element

The "any" element placeholder defines an extensibility point which may contain any XML element from any other namespace.  To extend XrML using this feature, define any element in any other namespace.

XrML allows this extensibility  mechanism at select points where the extension space can be large enough to account for a whole standard specification.  Examples of this are extra license information, methods of referring to a service, and mechanisms for revocation.

Example: Adding proprietary secret information to a license

To use this type of extension, use the element in the position defined by the "any" element placeholder.

3.1.4 Using the Three Extension Mechanisms

The following license gives an example of using these three extensions.  The example grants anyone the right to execute a certain game (located at http://www.xrml.org/games/2001/11/myext) for up to 10 minutes.  The details show that the license was signed in the United States.  The proprietary secret information might contain the key to unlock the game on some secure game demonstration system.

Example: Using the three extension mechanisms

3.2 Documenting Schema Extensions

When making extensions, it is important to clearly document the semantics of the new elements and types.  The following table lists things to consider when documenting common classes of extensions:

Class of Extension Documentation Considerations
principal Describe what procedure should be followed before making a claim that a certain principal can be described by an instance of that extension.
right Describe which sequences of events are consistent, and which are inconsistent, with the right described by an instance of that extension.
resource Describe which physical or logical items are described by instances of that extension.
condition Describe the set of contexts for which an instance of that extension is to be considered satisfied and the set of contexts for which an instance of that extension is to be considered breached.
xmlPatternAbstract Describe the set of XML trees that match the pattern and the set that do not.

 

4 Conformance

This chapter provides conformance requirements and guidelines for XrML. These conformance requirements and guidelines ensure consistency of format, organization, content, interpretation, and other aspects of an XrML expression or construct, so that certain levels of reuse and interoperability can be achieved among XrML applications. 

This chapter addresses conformance in terms of the following two aspects:

4.1 Markup Conformance

An XML expression is said to be XrML markup conforming if it contains elements in the XrML core and extension namespaces, and these elements together with their attributes meet all the mandatory syntactic and semantic requirements as prescribed in the normative parts of this XrML specification. An XrML markup conforming XML expression can be an XML expression starting with an XrML element or an XML expression that uses XrML elements together with elements in other XML namespaces. Since the XrML schemas are normative, XrML expressions must be valid against these schemas in the sense defined by XML Schema. Moreover, they must adhere to the semantic restrictions imposed for each XrML element and attribute used. For instance, a licensePart cannot have both the attributes licensePartId and licensePartIdRef, even though having both of them is syntactically valid. 

4.2 Application Conformance

An XrML application is any application or software/hardware module that can validate, interpret, or generate valid XrML expressions. An XrML application that processes XrML expressions might be an editor that creates or modifies XrML expressions, or an interpreter that verifies, against an XrML license expression, whether or not some principal has some right on some resource. 

An XrML application is said to be XrML application conforming if, when it claims to validate, interpret, and/or generate XrML, it validates the syntax of, interprets the semantics of, and/or generates well-formed XrML expressions according to the XrML specification. An XrML conforming application must meet the following criteria: 

Go to Part II: XrML Core Schema