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.
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.
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.
Part 1: Primer
1 About XrML
2 XrML Concepts
3 Extensibility of the XrML Core
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
C Index of Types and Attributes
Content of this Specification
Scope of this Document
Dependencies on Other Specifications
Part III: Standard Extension Schema: Provides normative technical details regarding the XrML standard extension. This extension to the language defines types and elements common to many XrML usage scenarios but which do not form part of the language's core.
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.
This specification depends on the following other specifications:
T. Bray, D. Hollander, A. Layman, 14 January 1999.
For a list of other related specifications, see Appendix D, References.
The diagrams in this specification use the following conventions:
|A single mandatory element.|
|A single mandatory element with child elements.|
|A single mandatory element containing Parsed Character Data (#PC-Data). The content may be simple content or mixed complex content.|
|A single optional element.|
|A multiple optional element (in this case, zero to infinity) with child elements.|
|A placeholder for any element from any namespace.|
|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.|
Note: These diagrams were generated
using Altova XML Spy Integrated Development Environment. For more
information, see the Altova web site, http://www.xmlspy.com.
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.
The reality of the Internet and
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
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
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:
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
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.
XrML exploits the advantages provided by current XML technologies:
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.
XrML comprehends real-life system issues such as:
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
To enable content owners and
distributors to describe rights, fees and conditions appropriate to commerce
models they select.
To provide standard terms for
usage rights with useful, concise, easily understandable meanings.
To offer vendors sound operational definitions of trusted systems for compliance testing and evaluation.
To leverage existing standards or standard activities as much as possible, including W3C XML schema, XML Digital Signature, and XPath.
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.
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,
digitalWork is a resource
(also defined in the XrML Content Extension), and
validityInterval is a condition.
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.
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
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:
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
Principal, Right, Resource, and Conditiontypes will define useable principals, rights, resources, and conditions, respectively.
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:
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).
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.
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).
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).
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.
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.
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).
The XrML Core uses XML Schema technology to enable extensibility. For further details about these mechanisms, please refer to the XML Schema Primer.
Three XML Schema technologies are used commonly with XrML for extensibility:
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.
To use this type of extension, use the new element in the existing element's place.
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.
To use this type of extension, place the xsi:type attribute in your instance document on the element whose type you are changing.
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.
To use this type of extension, use the element in the position defined by the "any" element placeholder.
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.
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.|
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:
markup conformance: refers to the conformance of any XML expressions that use valid XrML expressions. The "use" includes using only XrML expressions as well as using XrML expressions together with XML expressions within other namespaces. The conformance is on the syntactic and semantic information that the XML expressions carry.
application conformance: refers to the conformance of any XML applications that are capable of processing XrML expressions. The conformance is on their functionality for performing syntactic validation and semantic interpretation of XrML expressions according to the XrML specification.
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.
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:
It implements and processes the mandatory elements and attributes as well as mandatory semantic requirements ("must" and "must not") set forth in this specification.
For any optional elements and attributes as well as optional semantic requirements ("should" and "may") it chooses to implement, it implements and processes them in the way prescribed.
At a minimum, it implements the mandatory elements and attributes in the XrML Core.
If it implements any XrML extension, it must implement all the mandatory elements and attributes in that extension.
It must parse and check an XrML document for well-formedness. If the application has validation functionality, it must also validate XrML documents against their referenced schemas and the semantic requirements specified in this XrML specification.
When it has interpretation functionality, it must interpret XrML in ways consistent with the semantic definitions and processing rules specified in the XrML specification. This covers processing rules for handling licensePartId and licensePartIdRef, pattern matching, using varName and varRef, generating and verifying license signatures, and authorization.
Go to Part II: XrML Core Schema