Open Digital Rights Language (ODRL)

Version: 1.0

Date: 2001-11-21

URI:

Editor: Renato Iannella

Copyright IPR Systems Pty Ltd 2001

Status

ODRL Version 1.0 will be submitted to the ISO/IEC MPEG standards body in response to its Call for Proposals for a Rights Data Dictionary and Rights Expression Language for the MPEG-21 Multimedia Framework.

ODRL has no license requirements and is available in the spirit of "open source" software.

Feedback and Comments

Please send feedback to <> and general comments to <>. Interested parties wishing to support the ODRL Initiative, please send email to <>.

1 Overview

Digital Rights Management (DRM) involves the description, layering, analysis, valuation, trading and monitoring of the rights over an enterprise's tangible and intangible assets. DRM covers the digital management of rights - be they rights in a physical manifestation of a work (eg a book), or be they rights in a digital manifestation of a work (eg an ebook). Current methods of managing, trading and protecting such assets are inefficient, proprietary, or else often require the information to be wrapped or embedded in a physical format.

A key feature of digitally managing rights will be the substantial increase in re-use of digital material on the Internet as well as the increased efficiency for physical material. The pervasive Internet is changing the nature of distribution of digital media from a passive one way flow (from Publisher to the End User) to a much more interactive cycle where creations are re-used, combined and extended ad infinitum. At all stages, the rights need to be managed and honoured with trusted services.

Current DRM technologies include languages for describing the terms and conditions, tracking asset usages by enforcing controlled environments or encoded asset manifestations, and closed architectures for the overall management of rights.

The Open Digital Rights Language (ODRL) provides the semantics for DRM expressions in open and trusted environments whilst being agnostic to mechanisms to achieve the secure architectures.

1.1 The Bigger Picture

It is envisaged that ODRL will "plug into" an open framework that enables peer-to-peer interoperability for DRM services. However, ODRL can also be used as an mechanism to express rights statements on its own and to plug into existing DRM architectures and frameworks.

DRM has traditionally been flavoured with security and encryption as a means to solve these issues, that is, Digital Rights Enforcement. This is the first-generation of DRM and represents a substantial narrowing of its real and broader capabilities. Second-generation DRM systems will provide these additional functions and support end-to-end supply chain services.

DRM systems should be based on and designed around open functional architectures and a robust and extensible information model. See [IANNELLA] for an overview of DRM Architectures and [ERICKSON] for DRM-enabled digital object models. The layers and relationships of rights can also quickly become very complex [HIGGS] and DRM systems must be designed to cater for this intricacy.

1.2 Scope

ODRL complements existing analogue rights management standards by providing digital equivalents, and supports an expandible range of new services that can be afforded by the digital nature of the assets in the Web environment. In the physical environment, ODRL can also be used to enable machine-based processing for rights management.

ODRL is a standard language and vocabulary for the expression of terms and conditions over assets. ODRL covers a core set of semantics for these purposes including the rights holders and the expression of permissible usages for asset manifestations. Rights can be specified for a specific asset manifestation (ie format) or could be applied to a range of manifestations of the asset.

ODRL is focused on the semantics of expressing rights languages and definitions of elements in the data dictionary. ODRL can be used within trusted or untrusted systems for both digital and physical assets. However, ODRL does not determine the capabilities nor requirements of any trusted services (eg for content protection, digital/physical delivery, and payment negotiation) that utilises its language. Clearly, however, ODRL will benefit transactions over digital assets as these can be captured and managed as a single rights transaction. In the physical world, ODRL expressions would need an accompanying system with the distribution of the physical asset.

ODRL defines a core set of semantics. Additional semantics can be layered on top of ODRL for third-party value added services with additional data dictionaries.

ODRL does not enforce or mandate any policies for DRM, but provides the mechanisms to express such policies. Communities or organisations, that establish such policies based on ODRL, do so based on their specific business or public access requirements.

ODRL depends on the use of unique identification of assets and parties. Common identification is a very difficult problem to have agreement across sectors and is why identification mechanisms and policies are outside the scope of ODRL. Sector-specific versions of ODRL may address the need to infer information about asset and party identifiers.

The ODRL model is based on an analysis and survey of sector specific requirements (including models and semantics), and as such, aims to be compatible with a broad community base. ODRL intends to meet the common requirements for many sectors and has been influenced by the ongoing work and specifications/models of the following groups:

The Project [INDECS]
Electronic Book Exchange Working Group [EBX]
International Federation of Library Associations [IFLA]
DOI Foundation [DOI]
ONIX International [ONIX]
Moving Pictures Expert Group [MPEG]
IMS Global Learning Consortium [IMS]
Dublin Core Metadata Initiative [DCMI]
Propagate Project [PROPAGATE]
OpenEBook Forum [OEBF]
Publishers Requirements for Metadata [PRISM]
Association of American Publishers [AAP]
Digital Imaging [DIG35]

ODRL proposes to be compatible with the above groups by defining an independent and extensible set of semantics. ODRL does not depend on any media types as it is aimed for cross-sector interoperability.

1.3 Specification Overview

This document, along with its normative references, includes all the specification necessary for the implementation of interoperable ODRL applications.

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 [RFC2119] which defines the significance of each particular requirement.

Examples used in this document are for demonstration purposes only.

The ODRL specification contains the following main sections:

Section 2 describes the model for the ODRL expression language.
Section 3 describes the semantics of the ODRL data dictionary elements.
Section 4 describes the XML syntax used to encode the ODRL expressions and elements.
Section 5 describes how additional ODRL data dictionaries can be defined.

The formal Expression Language and Data Dictionary elements are defined in:

2 ODRL Expression Language

The models for the ODRL language and data dictionary contain the structure and core semantics for the expressions. These models provide the overall framework for the expressions into which elements (from DRM data dictionaries) can be applied.

Note: The figures in this section cover both the Expression Language entities (shown as shadowed rectangles with "EX" in the top left corner) and the Data Dictionary elements (shown as rectangles with "DD" in the top left corner). Other namespaces ("DS" for XML Digital Signatures) are also shown.

2.1 ODRL Foundation Model

ODRL is based on an extensible model for rights expressions which involves a number of core entities and their relationships. This ODRL Foundation Model is shown in Figure 1.

Figure 1. ODRL Foundation Model

The model, as shown in Figure 1, consists of the following three core entities:

Assets
Rights
Parties

The Assets include any physical or digital content. The Assets must be uniquely identified and may consist of many subparts and be in many different formats. Assets can also be non-tangible expressions of works and/or manifested in particular renditions. Assets may also be encrypted to enable secure distribution of content.

The Rights include Permissions which can then contain Constraints, Requirements, and Conditions. Permissions are the actual usages or activities allowed over the Assets (eg Play a video Asset). Constraints are limits to these Permissions (eg Play the video for a maximum of 5 times). Requirements are the obligations needed to exercise the Permission (eg Pay $5 each time you Play the video). Conditions specify exceptions that, if become true, expire the Permissions and renegotiation may be required (eg If Credit Card expires then all Permissions are withdrawn to Play the video).

The Parties include end users and Rights Holders. Parties can be humans, organisations, and defined roles. End users are usually the asset consumers. Rights Holders are usually parties that have played some role in the creation, production, distribution of the Asset and can assert some form of ownership over the Asset and/or its Permissions. Rights Holders may also receive royalties.

With these three core entities, the foundation model can then express Offers and Agreements. Offers are proposals from Rights Holders for specific Rights over their Assets. Agreements are when Parties enter into contracts or deals with specific Offers. The model can also then express revoking of any Offers or Agreements.

The representation of Offers and Agreements is important core aspect of ODRL. This makes clear what the purpose of the rights expressions is achieving. Many different Offers can be created to meet various business models for assets. Offers can be linked, creating a hierarchy of options for end users. Agreements are the transformation of an Offer into a license for rights over an asset by parties. Also, there is no requirement that Offers be made prior to Agreements. After human interactions, Agreements can be created to express the accepted terms and conditions.

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. For example, the Context of an Agreement may specify the date of the transaction, the Context of a Party may specify their role. Although not mandatory, the use of Context to assign unique identifiers to the entire rights expression is highly recommended.

The Context also plays a very important role in identifying the entity (using a unique number/code from a standard identification scheme). This ability to uniquely reference any entity can be utilised in providing linkages between entities. For example, an Agreement can be linked to the original Offer by the latter's unique id number.

The general description of the Party and Asset entities is outside the scope of ODRL. What is in scope is that these entities must be referenced by using unique identification mechanisms (such as [URI], [DOI], [ISBN] etc). Both of these entities contain a mechanism to refer to their unique identifiers, as well as a Context.

The Asset entity (sometimes referred to as a Work, Content, Creation, or Intellectual Property), is viewed as a whole entity. If the Rights are assigned at the Asset's subpart level, then such parts would require to also be uniquely identifiable. However, ODRL can specify constraints on subparts of the asset. Additionally, Assets can be identified as to their layer of intellectual property as defined by the IFLA model [IFLA]. These include Work, Expression, Manifestation, and Item. This features also allows rights to be expressed over non-tangible assets and individual instances.

These core Entities together allow for a wide and flexible range of ODRL expressions to be declared. Additionally, the expressions can be digitally signed.

The core entities (except for Asset and Party) are further explained in the following sections:

Permissions (see Section 2.2 "ODRL Permission Model")
Constraints (see Section 2.3 "ODRL Constraint Model")
Requirements (see Section 2.4 "ODRL Requirement Model")
Conditions (see Section 2.5 "ODRL Condition Model")
Rights Holders (see Section 2.6 "ODRL Rights Holder Model")
Contexts (see Section 2.7 "ODRL Context Model")
Offers (see Section 2.8 "ODRL Offer Model")
Agreements (see Section 2.9 "ODRL Agreement Model")
Revoking Rights (see Section 2.10 "ODRL Revoke Model")

The security-based entities (Signature and Encryption) are further explained in the following section:

Security (see Section 2.11 "ODRL Security Model")

Additional features of the ODRL expression language are explained in the following sections:

Containers of entities (see Section 2.12 "Expression Containers")
Sequence of entities (see Section 2.13 "Expression Sequence")
Linking between entities (see Section 2.14 "Expression Linking")
Inheritance between entities (see Section 2.15 "Expression Inheritance")

2.1.1 Foundation XML Example

The ODRL Foundation Model can be expressed using an XML binding. An example is shown in Example 1.

Example 1. Foundation Model XML Syntax
. ... ... ... ... ... ... ... ... ... ... ...

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.2 ODRL Permission Model

ODRL supports the expression of Permissions for both Offers and Agreements. This is the recognised set of activities allowed over the Asset. The ODRL Permission Model is shown in Figure 2.

Figure 2. ODRL Permission Model

The Permission entity consists of an aggregation of four abstract entities. The abstract entities (depicted as clouds in Figure 2) are solely used to group similar permissions, and include:

Usage - indicates a set of methods in which the Asset can be consumed (realised with: Display, Print, Play, Execute).
Reuse - indicates a set of operations in which the Asset (or portions of it) can be re-utilised (realised with: Modify, Excerpt, Annotate, Aggregate).
Transfer - indicates a set of procedures in which the rights over the Asset can be transferred (realised with: Sell, Lend, Give, Lease).
Asset Management - indicates a set of digital asset management operations (realised with: Move, Duplicate, Delete, Verify, Backup, Restore, Save, Install, Uninstall).

Note: The listed elements above (eg Display, Print etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.

Additionally, the Permissions support:

an "Exclusivity" attribute that indicates if the granted permission is confined to nominated Parties (as per an Agreement).
The Context entity for the purposes of assigned unique identifiers to specific sets or groups of Permissions.

A Permission must be associated with one or more Assets via an Offer or Agreement. A Permission can be associated with zero or more Constraints, Conditions, and Requirements.

Important Note:

A Permission that is not specified in any Rights Expressions is not granted. That is, no assumptions should be made with regard to Permissions if they are not explicitly mentioned in the ODRL expression.

2.2.1 Permission XML Example

The ODRL Permission Model can be expressed using an XML binding. An example is shown in Example 2 in which permissions for display, print (with a constraint), and annotate have been granted.

Example 2. Permission Model XML Syntax
...

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.3 ODRL Constraint Model

ODRL supports the expression of Rights Constraints. This is the recognised set of restrictions on the Permissions over the Asset. The ODRL Constraint Model is shown in Figure 3.

Figure 3. ODRL Constraint Model

The Constraints entity consists of an aggregation of several abstract entities. The abstract entities (depicted as clouds in Figure 3) are solely used to group similar constraints, and include:

User - indicates a set of constraints which limits usage to identified user(s) (realised with: Individual, Group).
Device - indicates a set of constraints which limits usage to physical devices or systems (realised with: CPU, Network, Screen, Storage, Memory, Printer, Software, Hardware).
Bounds - indicates a set of constraints which limits usage to a fixed number or extent/coverage (realised with: Count, Range, Spatial).
Temporal - indicates a set of constraints which limits usage to temporal boundaries (realised with: Date Time, Accumulated, Interval).
Aspect - indicates a set of constraints which limits usage to distinct features or expressions of the asset (realised with: Quality, Format, Unit, Watermark).
Target - indicates a set of constraints which limits usage to where and how the asset is used (realised with: Purpose, Industry, ReContext).
Rights - indicates a set of constraints which only applies to asset with a Transfer Permissions and enables the specification (and constraints) on downstream permissions (realised with: Transfer Permission).

Note: The listed elements above (eg Individual, Group etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.

A Constraint is associated with one Permission. If a Constraint appears at the same level as a number of Permissions, then the Constraint applies to all of the Permissions. Constraints can also have zero or more other Constraints. In this case, the child constraint applies to the parent constraint.

For Permissions with multiple constraints, all constraints must be honoured with no conflicts arising. An error must be generated if the latter is true.

Additionally all Constraint elements may have a Context element (to support the use of uid) and a "type" attribute (to refer to additional information).

Important Note:

Any Constraint that is expressed but cannot be performed by the consuming system, must not be granted. That is, if a system does not understand how to guarantee that a specified constraint be honoured it must not grant the permission at all.

2.3.1 Constraint XML Example

The ODRL Constraint Model can be expressed using an XML binding. An example is shown in Example 3 in which the display permission is constrained to a particular CPU. The print permission is limited to printing up to five times. The play permission is limited to a recurring period of seven days which itself can only occur up to ten times.

Example 3. Constraint Model XML Syntax
1 5 P7D 10

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.3.2 Transfer Permission Constraint Example

The Transfer Permission constraint is used to enable the downstream distribution of rights over assets. It applies only to assets that have one of the Transfer Permission applied as this ensures that the authorised party can transfer rights to other users. (This is sometimes called "narrow" rights.)

The Transfer Permission constraint may contain a list of other Permissions that either must be or may be passed along when the asset is transferred. If a Permission is not listed, then those permissions may not be passed along when the asset is transferred. In other words, the default is that no Permissions may be passed along when the asset is transferred.

When a Permission is passed along, the party that transfers the asset may or may not be allowed to alter the Permissions (typically by narrowing it). The Transfer Permission entity supports the following "downstream" attribute values to indicate this:

equal
less
notgreater (less than or equal to)

If the downstream attribute is "equal", the Permissions must be passed along without change when the asset is transferred. This is the default situation.

If the downstream attribute is "less", a smaller subset of Permissions must be passed along when the asset is transferred.

If the downstream attribute is "notgreater", the Permissions may be narrowed when the asset is transferred, but it must not be expanded.

The following Example 4 shows how the Transfer Permission constraint (applied to the Sell transfer permission) contains two options. The first option contains two other permissions (print, display) and the downstream attribute is set to "equal". The means that when the asset is sold to other users, the seller (authorised under the agreement) must provide these Permissions. The second option also contains two other permissions (aggregate, annotate) and the downstream attribute is set to "notgreater". The means that when the asset is sold to other users, the seller may provide these two Permissions, one of them, or none of them.

Example 4. Constraint Model - Transfer Permission - XML Syntax

2.4 ODRL Requirement Model

ODRL supports the expression of Rights Requirements. This is the recognised set of preconditions that must be met in order to obtain the related permissons. The ODRL Requirements Model is shown in Figure 4.

Figure 4. ODRL Requirement Model

The Requirement entity consists of three abstract entities. The abstract entities (depicted as a cloud in Figure 4) are solely used to group similar requirements, and includes:

Fee - indicates a set of requirements for payments for usage (realised with: PrePay, PostPay, PerUse).
Interactions - indicates a set of requirements on user interactions (realised with: Accept, Register).
Usage - indicates a set of requirements on the use of the asset (realised with: Attribution, Tracked).

Note: The listed elements above (eg PrePay etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.

A Requirement can be associated with one or many Permissions. If a Requirement appears at the same level as a number of Permissions, then the Requirement applies once to all of the Permissions. For Permissions with multiple Requirements, all Requirements must be honoured and no conflicts should arise. An error must be generated if the latter is true.

The ODRL Data Dictionary also defines the common reusable Payment entity, A payment may consist of the fixed amount to pay, the currency of the amount, the taxation due (as a percentage) and a taxation code.

Important Note:

Any Requirement that is expressed but cannot be performed by the consuming system, must not be granted. That is, if a system does not understand how to guarantee that a specified Requirement has been met, then it must not grant the permission at all. Users of the system must be informed of the situation.

2.4.1 Requirement XML Example

The ODRL Requirement Model can be expressed using an XML binding. An example is shown in Example 5 in which the play permission requires a $AUD20 fee (plus 10% tax) to be paid per use.

Example 5. Requirement Model XML Syntax
20.00 10.0

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.5 ODRL Condition Model

ODRL supports the expression of Rights Conditions. These are exceptions that are conditional events that, if become true (or occur), render the Permissions as no longer valid. The ODRL Condition Model is shown in Figure 5.

Figure 5. ODRL Condition Model

The Condition entity reuses two existing entities:

Permission - indicates the set of permissions that will trigger the event
Constraint - indicates a set of constraints. that will trigger the event

Note: The elements above are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.

If a Condition becomes true (ie the specified event occurs), then the system must cease granting the Permission to the user. The system may inform the user of the situation and offer information about renegotiating a new agreement.

A Condition can be associated with one or many Permissions. If a Condition appears at the same level as a number of Permissions, then the Condition applies once to all of the Permissions. For Permissions with multiple Conditions, all Conditions must be honoured and no conflicts should arise. An error must be generated if the latter is true.

Important Note:

Any Condition that is expressed but cannot be met or understood by the consuming system, must not grant the related Permissions. That is, if a system does not understand how to guarantee that a specified Condition has been met, then it must not grant the Permissions at all.

It is also important to note that Conditions and Constraints/Permissions behave in a similar ways but with opposite effect. A right can be expression with a Permission (what you are allowed to do) and a Constraint (limiting your permission). However, a Condition expresses the same semantics but as exceptions. If those conditions are met, the right is extinguished.

2.5.1 Condition XML Example

The ODRL Condition Model can be expressed using an XML binding. An example is shown in Example 6 in which there are two permissions; sell and play. The play permission has a constraint on a particular type of software meaning that the play permission must be expired if and when that software is used to play the video. Additionally, there is a constraint that applies to all of the permissions (both play and sell). This constraint is on the spatial area (Australia) meaning that the permissions must be expired if and when the permissions are carried out in Australia.

Example 6. Condition Model XML Syntax
... AU

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.6 ODRL Rights Holder Model

ODRL supports the identification of Rights Holders. The Rights Holder is a recognised Party and any set of entitlements that they are due for the use of their Asset. The ODRL Rights Holder Model is shown in Figure 6.

Figure 6. ODRL Rights Holder Model

The Rights Holder entity consists of one abstract entity: The abstract entity (depicted as a cloud in Figure 6) is solely used to group similar Rights Holder royalty entitlements, and include:

Percentage - indicates a payment due to the indicated party for each transaction over the asset as a percentage of the value of the net transaction.
Fixed Amount - indicates a payment due to the indicated party for each transaction over the asset as a fixed value of the net transaction.

Note: The listed elements above (eg Percentage etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.

A Rights Holder can contain one or more Parties, and can be associated with one or many Assets. Parties can also be nested to indicate dependencies. For example; to support Rights Holder Sonya receiving 10% of Rights Holder Fiona's royalty (who may receive a fixed amount).

2.6.1 Rights Holder XML Example

The ODRL RightsHolder Model can be expressed using XML. An example is shown in Example 7 in which two identified parties share royalties with 90% to one and 10% to the other for each net transaction over their asset.

Example 7. RightsHolder Model XML Syntax
... 90 ... 10

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.7 ODRL Context Model

ODRL supports expressing additional information about entities and related entities. The ODRL Context Model is shown in Figure 7.

Figure 7. ODRL Context Model

The Context entity is an aggregation of ten other entities and includes:

UID - a unique identification number for the entity.
Name - a name used to describe the entity.
Role - the role played by the entity.
Remark - comments related to the entity.
Version - indicates the version of the entity.
Date - indicates the date the entity occurred or is valid for.
Event - indicates the type of event
Physical Location - indicates the physical location of the event/entity.
Digital Location - indicates the digital location of the event/entity.
External Reference - a link (URI) to an additional information about the entity.
Transaction - information about the purchased transaction related to the entity.
Service - a link (URI) to the service providing the entity.

Note: The listed elements above (eg UID etc) are defined in full in Section 3 "ODRL Data Dictionary Semantics" and form the basis of the ODRL Data Dictionary.

The Context is used for a number of different purposes and can be associated with any entity. When declaring Assets, it is used to indicate the unique identifier for the asset. When declaring Parties, it is used to indicate the unique identifier for the party, what role they may have played, and their name. The whole rights expression (eg Offer) can also have a Context to indicate the unique identifier for the expression as well as when it was created. The Agreement entity can also have a Context to provide information about the transaction.

The text-based Content entities (ie Name and Remark) may also indicate the human language of the text value.

2.7.1 Context XML Example

The ODRL Context Model can be expressed using an XML binding. An example is shown in Example 8 in which the context for a party is described.

Example 8. Context Model XML Syntax
c=EX;o=Federal Library;ou=Registry; cn=Maria K Brown Maria Brown AO1 http://www.maria-k-brown.com/vcard.xml

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.8 ODRL Offer Model

ODRL supports expressing offers made from Rights Holders for specific rights over their assets. The ODRL Offer Model is shown in Figure 9.

Figure 8. ODRL Offer Model

The Offer entity is an aggregation of four other entities and includes:

Asset - information about the asset
Rights Holder - information about the parties making the offer.
Permission - information (or a link) to the usage permissions being offered.
Context - details about the offer such as the date, time, location, identifier etc.

The Offer entity allows for detailed expressions of particular Rights Holders who have negotiated and agreed to offer particular permissions over their assets. Although not mandatory, the use of Context to assign unique identifiers to Offers is highly recommended. An Offer must include at least one Asset and Permission. If Rights Holder is not specified, then the system must support obtaining this information from other sources.

2.8.1 Offer XML Example

The ODRL Offer Model can be expressed using an XML binding. An example is shown in Example 10 in which an offer, with context, is described for a set of permissions over an asset with two rights holders.

Example 9. Offer Model XML Syntax
http://www.example.com/offer/3893823823472384888373 2001-10-10 http://www.example.com/e-book-store ... ... ...

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.9 ODRL Agreement Model

ODRL supports expressing agreements made between parties for specific rights over assets. The ODRL Agreement Model is shown in Figure 9.

Figure 9. ODRL Agreement Model

The Agreement entity is an aggregation of four other entities and includes:

Asset - information about the asset
Party - information about the parties to the agreement.
Permission - information (or a link) to the usage permissions being agreed to.
Context - details about the agreement such as the date, time, location, identifier etc.

The Agreement entity allows for detailed expressions of particular parties who have negotiated and agreed to a set of particular permissions over some assets. Although not mandatory, the use of Context to assign unique identifiers to Agreements is highly recommended. An Agreement must include at least one Asset and Permission. If Party is not specified, then the system must support obtaining this information from other sources.

2.9.1 Agreement XML Example

The ODRL Agreement Model can be expressed using an XML binding. An example is shown in Example 10 in which an agreement, with context, is described between a party and a set of permissions over an asset.

Example 10. Agreement Model XML Syntax
10.999/license/20010701/8736282828AAS 2001-07-01T10:31:30 Sydney, Australia Transacted by Example.Com ... ... ...

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.10 ODRL Revoke Model

ODRL supports revoking offers, agreements, and other rights expressions. The ODRL Revoke Model is shown in Figure 10.

Figure 10. ODRL Revoke Model

The Revoke entity is an aggregation of one other entity:

Context - identifier of the expression

The Revoke entity allows for the specification, via the unique identifier (uid) in Context, of the rights expression that is being revoked. The identifier (and identifier scheme) must be known to the consuming system.

Since the unique identifier (uid) in Context can be applied to any of the following:

the entire rights expression
Offers
Agreements
Permissions

then any (or all) of the above can be revoked.

Multiple expressions can be revoked at one time with multiple contexts in a Revoke statement.

2.10.1 Revoke XML Example

The ODRL Revoke Model can be expressed using an XML binding. An example is shown in Example 11 in which the prior agreement expressed in Example 10 (above) is being revoked. The Agreement identifier is used by the uid element.

Example 11. Revoke Model XML Syntax
10.999/license/20010701/8736282828AAS 2001-10-30 Error in Original Agreement

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.11 ODRL Security Model

ODRL supports both secure rights expressions with digital signatures and specifying the encryption of assets. The security model uses a profile of the W3C XML Signature [XML-SIG] and W3C XML Encryption [XML-ENC] specifications to support enveloped signing of the entire rights expression (when using an XML binding) and including encryption information about assets. The ODRL security profile uses a subset of the elements used in these two specifications to ensure interoperability.

2.11.1 Encryption

The ODRL Encryption Model is shown in Figure 11 and consists of additional ODRL entities (entities marked with "EX") and entities taken from the Digital Signature (entities marked with "DS") and Encryption (entities marked with "EC") specifications.

Figure 11. ODRL Encryption Model

To support information about the encryption of assets, ODRL defines two new entities called called "Digest" and "Content Encryption Key" (referred to as "cek") that are children of the ODRL Asset entity.

The Digest entity is designed to protect the integrity of the binding with the associated content and contains the following child entities:

DigestMethod - indicates the algorithm used to calculate the digest value. The "SHA-1" algorithm must be supported.
DigestValue - the value of the calculated digest.

The "cek" entity contains either a single "Plain Text Key" or multiple "Encrypted Key" as child entities. The PlainTextKey also has an "Key Name" attribute to support being referred to.

The Encrypted Key entity contains the following child entities:

EncryptionMethod - indicates the encryption algorithm used. The "RSA" algorithm must be supported.
Cipher Data - contains the raw encrypted data in the CipherValue child entity.
Key Info - See section Section 2.11.3 "Digital Signature" for details on this entity.

2.11.2 XML Encryption Profile

A ODRL Encryption Profile is limited to the following required constraints:

The permissible EncryptionMethod is RSA:
http://www.w3.org/2001/04/xmlenc#rsa-1_5
The permissible KeyInfo is X509Data:
http://www.w3.org/2000/09/xmldsig#X509Data

2.11.3 Digital Signature

The ODRL Digital Signature Model is shown in Figure 12 and consists of entities taken from the Digital Signature (entities marked with "DS") and Encryption (entities marked with "EC") specification.

Figure 12. ODRL Digital Signature Model

To support the digital signing of the rights expression, ODRL utilises entities from the XML Signature specification. The ODRL expression and Signature are "enveloped" within the "rights" entity. The Signature entity is used to refer to the rights expression via its "id" attribute.

The Signature entity includes the "SignedInfo" entity containing the following three entities:

CanonicalizationMethod - specifies the algorithm for canonicalization to be applied to the SignedInfo element prior to performing signature calculations. The "C14N" algorithm must be supported
SignatureMethod - indicates the method used to generate the signature. The "RSA" method must be supported
Reference - a link to the rights expression (via reference to its "id"). The Reference entity also contains a Transform entity to indicate any transformations required ("Enveloped Signature" and "C14N" are required to be supported in that order). The Reference entity also contains the DigestMethod and DigestValue entities (as described above in Section 2.11.1 "Encryption").

The Signature entity also includes:

SignatureValue - the base64 encoded signature value.
KeyInfo - this entity contains three other child entities; "X509Data", "SPKI Data" and "Key Name".

The "Key Name" entity contains a string value which may be used by the signer to communicate a key identifier to the recipient.

The "SPKI Data" entity contains information related to Simple Public Key Infrastructure (SPKI) public key pairs, certificates and other SPKI data and includes the "SPKI S-Exp" entity which is the base64 encoding of an SPKI canonical S-expression.

The "X509 Data" entity includes the following:

X509 Certificate - contains a base64-encoded binary Distinguished Encoding Rules (DER) X509 V.3 certificate
X509 SKI - contains the base64-encoded plain (non-DER-encoded) value of a X509 V.3 Subject Key Identifier (SKI) extension
X509 CRL - contains a base64-encoded Certificate Revocation List (CRL)

2.11.4 XML Digital Signature Profile

A ODRL Digital Signature Profile signature is a valid signature (as defined in [XML-SIG]) limited to the following required constraints:

The permissible CanonicalizationMethod is Canonical XML:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
The permissible SignatureMethod is RSA.
http://www.w3.org/2000/09/xmldsig#rsa-sha1
The permissible DigestMethod is SHA-1
http://www.w3.org/2000/09/xmldsig#sha1
The permissible Transform is Enveloped Signature and Canonical XML:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.w3.org/2000/09/xmldsig#enveloped-signature
The permissible KeyInfo is X509Data and SPKIData
http://www.w3.org/2000/09/xmldsig#X509Data
http://www.w3.org/2000/09/xmldsig#SPKIData

2.11.5 Security XML Example

The ODRL Security Model can be expressed using XML. Example 12 shows the asset element now including the encryption element with appropriate digest and content encryption key (cek) values.

Example 13 shows a rights expression that has been digitally signed. The rights expression element has been allocated the "id" of "MyRightsData". (Note: this "id" attribute is not the same as the "uid" element used in the "context" element, although they both could have the same value.) The id is used by the "Reference" element inside the Signature element. The "transforms" element also indicates the algorithms required to process the signed XML expression.

Both Example 12 and Example 13 need to include a mixture of XML namespaces (to support ODRL, XML Signature, and XML Encryption) and these are clearly indicated with the namespaces prefixes.

Example 12. Security Model XML Syntax - Encryption
xmlns:o-ex="https://odrl.net/1.0/ODRL-EX" xmlns:o-dd="https://odrl.net/1.0/ODRL-DD" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" > http://example.com/offers/3838383838.odrl MRV Profile 2.8.99 http://example.com/1793874932.mov ---base64 encoded hash value--- enc:Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> --- base64 encoded subject key id --- ---base64 enc encrypted CEK---

Example 12. Security Model XML Syntax - Encryption


                                                 xmlns:o-ex="https://odrl.net/1.0/ODRL-EX"
                                                    xmlns:o-dd="https://odrl.net/1.0/ODRL-DD"
                                                    xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
                                                      xmlns:enc="http://www.w3.org/2001/04/xmlenc#" >
                  
                           http://example.com/offers/3838383838.odrl 
                           MRV Profile 2.8.99 
                  
                 
                        
                 
                            
                                    
                                           http://example.com/1793874932.mov 
                                   
                 
                                        
                                           
                                               ---base64 encoded hash value--- 
                                        
                 
                                  
                                              
                                                       
                                                                              enc:Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
                                                        
                                                           
                                                                    --- base64 encoded subject key id --- 
                                                          
                                                  
                                                   
                                                                 ---base64 enc encrypted CEK---

Example 13. Security Model XML Syntax - Digital Signature
xmlns:o-ex="https://odrl.net/1.0/ODRL-EX" xmlns:o-dd="https://odrl.net/1.0/ODRL-DD" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" > http://example.com/license/1191918237827.odrl ... ... ... ds:Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> ds:Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> ds:Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> ---base64 encoded hash value--- ---base64 encoded signature value--- ---base64 encoded signer certificate---

Example 13. Security Model XML Syntax - Digital Signature


                                                     xmlns:o-ex="https://odrl.net/1.0/ODRL-EX"
                                                    xmlns:o-dd="https://odrl.net/1.0/ODRL-DD"
                                                    xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
                                                      xmlns:enc="http://www.w3.org/2001/04/xmlenc#" >
                 
                  
                           http://example.com/license/1191918237827.odrl 
                       
                 
                        
                                 ... 
                             ... 
                           ... 
                    
                 
                       
                 
                          
                                 
                                                                        ds:Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                                 
                                       
                                         
                                                 
                                                              ds:Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                                                   
                                                              ds:Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                                         
                                                
                                               ---base64 encoded hash value--- 
                                        
                         
                 
                                 ---base64 encoded signature value--- 
                 
                             
                                    
                                            ---base64 encoded signer certificate---

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.11.6 Encrypting ODRL Elements

In some circumstances, it may be necessary to only encrypt parts of ODRL expressions. For example, to make the rights holders royalty payments information confidential. The Security models described above can also support this requirements.

The encryption of specific ODRL elements can take place exactly as specified in Section 4 "Processing Rules" from [XML-ENC]. (The introductory examples in Section 2 of [XML-ENC] also provide a good overview.) The plain text ODRL elements to be protected will be replaced with the resulting encrypted XML structures. Sharing of the key used to protect these elements is out of the scope of ODRL and must be handled by the parties involved.

2.12 Expression Containers

The ODRL expression language also supports a number of mechanisms for grouping entities into containers. The groupings in the containers imply explicit semantics and must be supported.

There are three types of containers defined:

And - the entities all must be supported/recognised
Exclusive Or - only one of the entities must be supported/recognised
Inclusive Or - one or more of the entities must be supported/recognised

A new structure, called "container" is utilised to aggregate other entities to enforce the above semantics. The container structure has an attribute called "type" (with fixed values of "and", "ex-or", "in-or") to indicate the container type. The default container type is "and". Additionally, when no container structure is used, the default of "and" is implied.

The container semantics only applies to the immediate children of the container.

Typically the container structure is used to aggregate permissions, constraints, conditions, and requirements but can be used on other entities.

2.12.1 Container XML Example

The ODRL Container structure can be expressed using XML. An example is shown in Example 14 in which the play permission is constrained to either (or both) the CPU or Storage device and the requirement is to either pay up front ($AUD200) or per use ($AUD1.50).

Example 14. Container XML Syntax
200.00 1.50

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.13 Expression Sequence

The ODRL expression language also supports a number of mechanisms for specifying the sequence of entities for both total and partial ordering. A sequence of the entities implies the order in which the entities must be addressed/supported.

There are two types of sequence orders defined:

total - the order is absolute
partial - the order is optional

A new structure, called "sequence" is utilised to aggregate other entities to enforce the above semantics. The sequence structure has an attribute called "order" (with fixed values of "total", "partial") to indicate the sequence order. The default sequence order is "total". Additionally, when no sequence structure is used, then no assumptions on the order should be made.

Within the sequence structure, the order is specified with "seq-item" elements, each with an attribute indicating the order number. The attribute (called "number") is an integer equal to or greater than one.

The sequence semantics only applies to the immediate children of the sequence.

Typically the sequence structure is used to order permissions, constraints, conditions, and requirements but can be used on other entities.

2.13.1 Sequence XML Example

The ODRL Sequence structure can be expressed using XML. An example is shown in Example 15 in which the requirement for the play permission is to undertake the absolute order of (1) register you details with the service provider, and then (2) pay the fee specified.

Example 15. Sequence XML Syntax
http://example.com/registerhere 100.00

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.14 Expression Linking

The ODRL expression language also supports the ability to explicitly link expression fragments. The links between the expression fragments imply explicit semantics and must be supported. The linking allows for ODRL expressions to be constructed by reusing existing expressions and allowing explicit links between fragments. Each ODRL fragment can be uniquely identified with the "id" attribute and referred to with the "idref" attribute.

In the usual case, entities appearing in ODRL rights expressions (offers or agreements) are assumed to be related. That is, a Permission entity that appears with an Asset entity are assumed to be related (ie this expresses the Asset's permissions). When explicit linking is used, then the link relationships take precedence. The examples in the next section show how these cases can be expressed.

2.14.1 Link XML Example

The ODRL Link structure can be expressed using XML. An example is shown in Example 16 in which the sell permission only applies to ASSET-01 and the lend permission applies to both ASSET-01 and ASSET-02.

Example 16. Link XML Syntax
... ...

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

2.15 Expression Inheritance

The ODRL expression language also supports the ability to specify the inheritance of expressions between assets. That is, to allow parent/child relationships to be defined.

The child asset element can include the "inherit" element which will indicate from which other parent asset(s) to inherit the rights from. All the parent asset rights will be merged with the child asset rights.

The inherit element may have an optional "override" attribute for child assets, that, if true, will not inherit the parent asset rights, but will define its own rights. The default is false.

The inherit element may have an optional "default" attribute for parent assets, that, if true, will not allow child assets to override its rights. The default is false.

2.15.1 Inheritance XML Example

The ODRL Inheritance structure can be expressed using XML. An example is shown in Example 17 in which the first rights expression specifies the play Permission for the identified asset. The second rights expression, for an asset related to the first, specifies that the rights should be inherited from the identified asset.

The expression also indicates not to override the inherited rights (the default), hence, the complete rights for the second asset includes the play and give Permissions. If the second expression did indicate to override the inherited rights, then the only Permissons for the second asset would be give.

Example 17. Inheritance XML Syntax
urn:example:asset:007 urn:example:asset:007-Part1 urn:example:asset:007

Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".

3 ODRL Data Dictionary Semantics

This section details the semantics of all the ODRL data dictionary elements that is used within the ODRL expression language. The ODRL data dictionary elements form the basis of the language and can be extended (see Section 5 "ODRL Extensibility") by additional elements. Each element in the data dictionary is defined using the following attributes defined by ISO-11179:

Name - The label assigned to the data element
Identifier - The unique identifier assigned to the data element (that is used for the syntactical encoding of the element)
Definition - A statement that clearly represents the concept and essential nature of the data element
Comment - A remark concerning the application of the data element

The data dictionary elements are defined below in the following sections:

3.1 Permissions Elements

The Elements are defined in Table 1: Permission Elements.

Table 1. Permission Elements
Name	Identifier	Definition	Comment
Usage Permissons (pertaining to the end use of an asset)
Display	display	The act of rendering the asset onto a visual device.
Print	print	The act of rendering the asset onto paper or hard copy form.
Play	play	The act of rendering the asset into audio/video form.
Execute	execute	The act of running machine executable code on computer hardware.
Transfer Permissions (pertaining to the downstream transfer rights of an asset)
Sell	sell	The act of allowing the asset to be sold (ownership transfer) in exchange of value.
Lend	lend	The act of allowing the asset to be made available for temporary use then returned (without exchange of value). During this period, the asset is only available to the lendee.	Temporal constraints are required for downstream use.
Give	give	The act of allowing the asset to be given away (ownership transfer) in perpetuity without exchange of value.
Lease	lease	The act of allowing the asset to be made available for a fixed period of time then returned (for exchange of value). During this period, the asset is only available to the lessee.	Temporal constraints are required for downstream use.
Asset Management Permissions (pertaining to the digital management of an asset)
Move	move	The act of allowing a digital asset to move between data storage devices.	Specification of constraints on the data storage devices may be allowed.
Duplicate	duplicate	The act of making an exact copy of a digital asset between data storage devices.	Specification of constraints on the data storage devices may be allowed.
Delete		The act of deleting a copy of an asset.
Verify		The act of allowing authorization to check the authenticity of an asset.
Backup		The act of making copies of an asset for the purpose of guarding against the loss of the original due to accident or catastrophic media or equipment failure.
Restore		The act of allowing the conversion of a backup copy into a usable copy in a controlled manner.
Save		The act of saving a copy (including any changes) of an asset to permanent storage.
Install		The act of allowing for the operation of loading, verification and certification of an asset into a data storage device.
Uninstall		The act of allowing for the removal from or disabling of an asset in a data storage device.
Reuse Permissions (pertaining to the re-utilisation of an asset creating a new asset)
Modify	modify	The act of changing parts of the asset creating a new asset.
Excerpt	excerpt	The act of extracting (replicating) unchanged parts (or all) of the asset for reuse into another asset.
Annotate	annotate	The act of adding notations/commentaries to the asset creating a new asset.
Aggregate	aggregate	The act of using an asset (or parts of it) as part of a composite work or collection.

3.2 Constraint Elements

The Elements are defined in Table 2: Constraint Elements.

Table 2. Constraint Elements
Name	Identifier	Definition	Comment
User Constraints (Any human or organisation)
Individual	individual	An identifiable party acting as an individual.	Use Context to identify the individual.
Group	group	A number of identifiable parties acting as a collection of individuals.	Use Context to identify the group
Device Constraints (Any electronic or digital equipment or system)
CPU	cpu	An identifiable computing system with a central processing unit (CPU).	Use Context to identify the device.
Network	network	An identifiable data network.	Use Context to identify the device. Use Range to indicate the IP Address restriction.
Screen	screen	An identifiable display output screen device.	For example, a screen reader or braille device. Use Context to identify the device.
Storage	storage	An identifiable storage media device.	For example, a hard disk or removable cartridge. Use Context to identify the device.
Memory	memory	An identifiable memory device.	For example, the clipboard. Use Context to identify the device.
Printer	printer	An identifiable hard copy printer.	Use Context to identify the device.
Software	software	An identifiable software application that must be present.	Use Context to identify the device.
Hardware	hardware	An identifiable generic hardware device.	Use Context to identify the device.
Bound Constraints (The limits/extent within which any entity can function)
Count	count	A numeric count indicating the number of times the corresponding entity may be exercised. Contains the following sub entities: start - the beginning of the count (inclusive) end - the end of the count (inclusive) fixed - an exact singular count	Positive decimals must be supported. If there is no "start" or "end" value, then the count is open-ended. Note, "start" must always be less than or equal to "end" and one must always be present if there is no "Fixed". "Fixed" can only appear by itself For example, the Print usage may be constraint with a count of 1 to 10 meaning that the asset can be printed once or up to 10 times.
Range	range	A numeric range indicating the min/max values of the corresponding entity that the constraint applies to. Contains the following sub entities: min - the beginning of the range (inclusive) max - the end of the range (inclusive) The numeric values must use the ordinal position when referring to external objects.	Positive and negative decimals must be supported. If there is no "min" or "max" value, then the range is open-ended. Note: "min" must always be less than or equal to "max" and one must always be present. For example, this is used to specify that only pages numbered 1 to 10 may be printed (using the "pages" subunit entity).
Spatial	spatial	Specification of a geographic area	Use Context to identify the spatial area with codes specified from a controlled vocabulary (eg [ISO3166] for country codes).
Temporal Constraints (The time limits within which any entity can function)
Date Time	datetime	A date and/or time-based range. Contains the following sub entities: start - the beginning of the range (inclusive) end - the end of the range (inclusive) fixed - an exact point in date/time	Date and Time value must conform to [ISO8601]. If there is no "start" and/or "end" value, then the range is open-ended. Note: "start" must always be less than or equal to "end" and one must always be present if there is no "fixed" value. "Fixed" can only appear by itself.
Accumulated	accumulated	The maximum period of metered usage time.	Period value must conform to [ISO8601]. For example "P30H" indicates a 30 hour period.
Interval	interval	Recurring period of time in which the rights can be exercised.	Date and Time value must conform to [ISO8601]. For example "P7D" indicates a 7 day period.
Aspect Constraints (Any distinct feature of the Asset)
Quality	quality	Specification of constraints on the quality aspects of the asset. Contains the following attribute: type - the classification of the quality type	The values for the type attribute must be from a well known vocabulary and the source clearly identified. For example, the resolution of an image or number of colours.
Format	format	Specification of constraints on the format(s) of the asset. Contains the following attribute: type - the classification of the format type	The values for the type attribute must be from a well known vocabulary and the source clearly identified. For example, values can taken from the Internet Media Type [IMT] list.
Unit	unit	Specification of constraints on the whole asset or sub-parts of the asset. Contains the following attribute: type - the classification of the sub-unit part type	The values for the type attribute must be from a well known vocabulary and the source clearly identified.
Water Mark	watermark	Specification of watermarking requirements for the asset.	Use Context to identify the watermark information.
Target Constraints (How and where limits over the Asset)
Purpose	purpose	Specification of a specific purpose to which the usage is constrained.	Use Context to identify the purpose from a known vocabulary
Industry	industry	Specification of a specific industry group to which the usage is constrained	Use Context to identify the industry from a known vocabulary
ReContext	recontext	Specification if the asset may or may not be re-contextualised.	Boolean value.
Rights Constraints (Constraints over Rights Permissions)
Transfer Permission	transferPerm	Specification of constraints over Transfer Permissions for the downstream transfer of assets. Contains the following attribute: downstream - the allowable narrowing of the specified Permissions (equal, less, notgreater)	See example in Section 2.3.2 "Transfer Permission Constraint Example".

3.3 Requirement Elements

The Elements are defined in Table 3: Requirement Elements.

Table 3. Requirement Elements
Name	Identifier	Definition	Comment
Common Entities
Payment	payment	The amount of the payment. Contains the following sub-entities and attributes: amount and currency taxpercent and code	The amount must be a positive decimal to two decimal places. The mandatory currency must use [ISO4217] codes. The taxpercent must be a positive decimal between 0 and 100 (inclusive). The optional code can be any standard tax identifier.
Payment Requirements (Obligations in the form of financial payments)
Pre Pay	prepay	The amount due prior to the granting/use of the rights.	Use Payment entity. Temporal constraints may also be used.
Post Pay	postpay	The amount due after the use of the rights.	Use Payment entity. Temporal constraints may also be used.
Per Use	peruse	The amount due for each use of the granted rights.	Use Payment entity.
Interactions Requirements (Obligations in the form of user actions)
Accept	accept	User must view and agree to textual information.
Register	register	User must register their details with a service provider.
Usage Requirements (Obligations in the form of usage conditions)
Attribution	attribution	The use of the asset must always include attribution of the asset owners.
Tracked	tracked	The User will be tracked for their use of the asset.	User must be aware of Privacy policy of the service provider.

3.4 Rights Holder Elements

The Elements are defined in Table 4: Rights Holder Elements.

Table 4. Rights Holder Elements
Name	Identifier	Definition	Comment
Royalty (Financial payments to Rights Holders)
Percentage	percentage	The percentage of the net transaction amount due to the rights holder.	The value must be a positive decimal between 0 and 100 (inclusive). The total of all rights holders must not exceed 100.
Fixed Amount	fixedamount	The fixed amount due to the rights holder for each net transaction amount.	Use Payment entity.

3.5 Context Elements

The Elements are defined in Table 5: Context Elements.

Table 5. Context Elements
Name	Identifier	Definition	Comment
UID	uid	The unique identifier for the entity. Contains the following attribute: idscheme - indicates the scheme used for the identifier. IMPORTANT NOTE: The default (and assumed) idscheme for the UID element is "URI".	Valid idschemes include: URI DOI X500 ISAN ISBN ISRC ISSN ISTC ISWC ISO3166 FPI GUID mpg_ID IDDN UUID References to the above schemes can be found in Section 6 "References".
Name	name	The general name given to the entity.
Role	role	The role played by the identified entity. Contains the following attribute: idscheme - indicates the scheme used for the identifier.	The role values may be selected from existing vocabulary schemes, including MARC ONIX MPEG7
Remark	remark	General comments or description about the entity
Date	date	The date/time related to the entity	See DateTime entity for complete semantics.
Physical Location	pLocation	The physical place where the entity occurred or is located.
Digital Location	dLocation	The digital location where the entity is located.	Use Context to indicate digital identifiers.
External Reference	reference	A link to additional information about the entity.	The link must be a URI and resolve to (at least) well formed XML.
Service	service	A link to the service providing the entity	The link must be a URI
Version	version	The version of the entity
Transaction	transaction	Information about the purchased transaction related to the entity
Event	event	The type of event related to the entity

4 ODRL XML Syntax

ODRL is expressed in schema-valid XML syntax. This syntax is formally specified by the XML Schemas defined in Appendix A and Appendix B. These are the normative references for the ODRL expression language and data dictionary (respectively).

Note: If the human language needs to be specified for any elements containing string values, then the use of the standard "xml:lang" attribute is recommended including the XML namespace.

4.1 ODRL XML Schemas

ODRL utilises two XML Schemas. One schema defines the Expression Language elements and constructs (see Appendix A), the other defines the Data Dictionary elements (see Appendix B). Both must be used to support valid ODRL expressions. Further, the Data Dictionary schema is dependent on the Expression Language schema as the former defines elements that are constrained by the expression language model.

4.2 ODRL XML Namespaces

ODRL supports XML Namespaces to indicate the scope and identity of its elements and other content description elements.

The XML Namespace URI for the ODRL Expression Language version 1.0 is:

https://odrl.net/1.0/ODRL-EX

The XML Namespace URI for the ODRL Data Dictionary version 1.0 is:

https://odrl.net/1.0/ODRL-DD

NOTE: These URIs should be considered experimental until the ODRL specification is formalised by an appropriate body and new XML Namespaces and URIs are assigned.

4.3 ODRL Linking

ODRL uses XML Schema ID and IDREF to refer from XML fragments to other fragments as described in Section 2.14 "Expression Linking". This is used to express the relationship between the core ODRL entities such as Asset, Permission, Offer and Agreement. Such elements can be identified with the "id" attribute then referred to via "idref" attribute.

It is important to recognise that as the ODRL expressions become more complicated, the need to partition and express linkages becomes paramount in order to have manageable and reusable rights expressions. The linking mechanism allows for quite complex expressions to be generated whilst preserving the interpretability of the overall rights language.

4.4 ODRL XML Examples

The XML syntax will be explained via a serious of scenarios covering different content sectors (ebooks, video, education).

4.4.1 Ebook Scenario #1

Corky Rossi (an author) and Addison Rossi (an illustrator) publish their ebook via "EBooksRUS Publishers". They wish to offer consumers to purchase (a requirement to pay $AUD20.00 plus 10% tax) the ebook which is restricted to a single CPU only and they are allowed to print a maximum of 2 copies. They will also allow the first 5 pages (Units) of the ebook to be viewed online for free (no requirement). Note the use of the NumberOfPages entity from the ONIX namespace to indicate the unit type.

The revenue split is 60% to the Author, 10% to the Illustrator and 30% to the Publisher. Their identities are shown from an X.500 repository and their roles indicated using the ONIX and MARC terms.

The XML encoding of this scenario in ODRL is shown below:


                     xmlns:o-dd="https://odrl.net/1.0/ODRL-DD"
                      xmlns:onix="http://www.editeur.org/onix/ReferenceNames"
                       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xsi:schemaLocation="https://odrl.net/1.0/ODRL-DD https://odrl.net/1.0/ODRL-DD-10.xsd
                                 https://odrl.net/1.0/ODRL-EX  https://odrl.net/1.0/ODRL-EX-10.xsd">
           
               
           
              
                      
                            10.999999/ebook/rossi-000001
                             Why Cats Sleep and We Don't
                          
           
           
             
                         
                            
                                         
                               
                        
                   
                              
                                          2 
                               
                        
                     
                                
                                     
                                            20.00
                                              10.00
                                          
                           
                    
               
           
                
                         
                            
                                         
                                              
                                                         
                                                              1
                                                              5
                                                      
                                             
                                        
                              
                        
           
           
                
                      
                            c=AU;o=Rights Dir;cn=Corky Rossi
                                A01
                   
                   
                               60
                       
              
             
                      
                            c=AU;o=Rights Dir;cn=Addison Rossi
                              A12
                   
                   
                               10
                       
              
             
                      
                            c=AU;o=Rights Dir;cn=EBooksRUS
                                  pbl
                   
                   
                               30

4.4.2 Ebook Scenario #2

Following from Ebook Scenario #1 (above), a consumer (Mary Smith) decides to purchase the ebook under the conditions outlined. The ODRL expression below shows the Agreement generated. The Agreement has a context (with identifier and date). The Permission now shows the details of the constraint that is specific to the consumer. (In this case, the CPU identifier is saved with the license.)

The XML encoding of this scenario in ODRL is shown below:


                     xmlns:o-dd="https://odrl.net/1.0/ODRL-DD" 
                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xsi:schemaLocation="https://odrl.net/1.0/ODRL-DD https://odrl.net/1.0/ODRL-DD-10.xsd
                                 https://odrl.net/1.0/ODRL-EX  https://odrl.net/1.0/ODRL-EX-10.xsd">
           
               
           
                          
                            10.999999/license/1234567890-ABCDEF
                              Sydney, Australia
                                  Transacted by Example.Com
                        
           
                   
                              
                                    10.999999/ebook/rossi-000001
                             
                   
           
                     
                                 
                                    
                                                 
                                                        
                                                            
                                                                                         WebBuy:CPD-ID:ER-393939-DSS-787878
                                                     
                                           
                                       
                                
                           
                                      
                                                  2 
                                       
                                
                             
                                        
                                             
                                                    20.00
                                                      10.00
                                                  
                                   
                            
                       
           
                        
                              
                                    10.999999/users/msmth-0001111
                                    Mary Smith

4.4.3 Ebook Scenario #3

The ebook for an "Electronic Book Exchange" voucher is entitled "XML: A Manager's Guide". The rights owner is Addison-Wesley.

There is an agreement with the Distributor of this book (a company called "XYZ"). They have rights to Sell up to 5000 copies of the book.

Another licensed end user for this book is "John Doe". All his permissions start from the beginning of 2001 and finish at the end of 2004. He has rights to view the book for a total of 30 days. He can print up to 5 copies on a "trusted printer". He can print up to 5 pages between page 1 and 100 every week - up to a total of 100 pages - on any printer. He can also extract 5000 bytes every week up to a total of 1,000,000 bytes onto the Clipboard (memory). He has the right to Give the book away after one year of the permissions starting.

Note the use of the NumberOfPages and NumbeOfBytes entities from the ONIX and EBX namespaces. Note the use of id and idref for indicating the relationships between the agreements/rightsholder and the asset.

The XML encoding of this scenario in ODRL is shown below:


                    xmlns:o-dd="https://odrl.net/1.0/ODRL-DD"
                      xmlns:onix="http://www.editeur.org/onix/ReferenceNames"
                       xmlns:ebx="http://www.ebxwg.org/ebook/vocab/"
                         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xsi:schemaLocation="https://odrl.net/1.0/ODRL-DD https://odrl.net/1.0/ODRL-DD-10.xsd
                                 https://odrl.net/1.0/ODRL-EX  https://odrl.net/1.0/ODRL-EX-10.xsd">
           
               
                    10.999999/voucher/2001/1234567890
                         2001-05-01 
                     issued 
           
           
           
                     
                            872-2345-981
                            XML: A Manager's Guide
                       
           
           
             
                      
                            http://publishers.net/registry/AWL
                               Addison-Wesley
                               http://www.addison-wesley.com
                      
                   
              
           
             
                          
                         
                              
                                    http://distributors.net/registry/xyz
                                     XYZ Company
                                          dst
                           
                   
                     
                                 
                                       
                                                  5000 
                                    
                                
                      
                
           
                 
                          
                         
                              
                                    http://people.net/registry/john-doe-9999
                                         John Doe
                             
                   
                     
                                 
                                         
                                           2001-01-01
                                                 2004-12-31
                                     
                                  
                                
                                    
                                                 P30D
                                   
                                
                           
                                      
                                                
                                                          5 
                                                       
                                                            
                                                                    Trust:Print:4747474742222
                                                               
                                                   
                                           
                                                
                                                         
                                                              
                                                                          100 
                                                             
                                                        
                                                      
                                           
                                                
                                                         
                                                              
                                                                         
                                                                              1 100
                                                                         
                                                                      5 
                                                               
                                                        
                                                      P7D
                                                          
                                           
                                        
                                 
                             
                                    
                                                 
                                                     
                                                                 
                                                                       
                                                                                 
                                                                                       
                                                                                                
                                                                                                       1000000
                                                                                               
                                                                                      
                                                                                          
                                                                                                P7D
                                                                                                  
                                                                                                       5000
                                                                                                  
                                                                                      
                                                                                 
                                                                          
                                                                
                                                      
                                                
                                    
                                
                           
                                       
                                                 
                                                   2002-01-01
                                                 
                                          
                                
                      
           
                
          
          Notes: In dealing with the  element, it's important to understand the separate meanings of the  and  elements and their relation to the unit element:
          
            
              
                A count that is outside a unit element means the number of times the right can be exercised (eg, a count of 5 inside a print element means "print 5 times").
              
              
                A count that is inside a unit element means the number of units (eg a count of 5 inside a NumberOfPages type unit element that is itself inside a print element means "print 5 pages").
              
              
                A range that is outside a unit element meanings depends on the containing element.
              
              
                A range that is inside a unit element means the minimum or maximum ordinal position of the units (eg a range with min of 1, max of 100, inside a unit element that is itself inside a print element means "print pages numbered (positioned) between 1 and 100").

4.4.4 Video Scenario #1

A video has three rights holders. Massimo Canale receives 75% of the transactions and Simona Canale receives the other 25%. Additionally, Maria Canale receives 10% of Simona's share. (Note the nesting of the last two parties.)

The video is offered at two different levels of quality (30 and 90dpi) and each has a different per use fee.

Note the use of the "resolution" entity from the MPEG7 namespace to indicate the Quality aspect of the asset. Note also that the whole expression has a context with a unique identifier (this is used in the next example).

The XML encoding of this scenario in ODRL is shown below:


                    xmlns:o-dd="https://odrl.net/1.0/ODRL-DD"
                      xmlns:mpeg7="http://www.mpeg7.org/2001/MPEG-7_Schema"
                         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xsi:schemaLocation="https://odrl.net/1.0/ODRL-DD https://odrl.net/1.0/ODRL-DD-10.xsd
                                 https://odrl.net/1.0/ODRL-EX  https://odrl.net/1.0/ODRL-EX-10.xsd">
           
               
                    10.9999999/voucher/383838383
                      The Voucher for XML: The Movie 
                     
                                  
                                    http://example.com/odrl/383838383.xml
                            
                   
                 
           
           
           
                      
                              
                                    10.9999999/video/383838383
                                       XML: The Movie
                               
                   
           
                     
                              
                                    c=IT;o=Registry;cn=Massimo Canale
                               
                           
                                       75
                               
                      
                     
                              
                                    c=IT;o=Registry;cn=Simona Canale
                                
                           
                                       25
                               
                              
                                      
                                            c=IT;o=Registry;cn=Maria Canale
                                         
                                   
                                               10
                                       
                              
                     
           
                     
                                 
                                       
                                                 
                                                     
                                                                 
                                                                      30
                                                             
                                                     
                                                
                                   
                                        
                                                
                                                     
                                                            1000
                                                       
                                           
                                    
                               
                              
                                       
                                                 
                                                     
                                                                 
                                                                       90
                                                            
                                                     
                                                
                                   
                                        
                                                
                                                     
                                                            5000

4.4.5 Super Distribution Example #1

A company offers the free distribution (ie the give permission) for the video asset (from 4.4.4 Video Scenario #1) to a particular individual (J J Jones) for a period ending at 31 December 2001. They do this by allowing the rights expression (itself an asset) to be given away.

Note that the video is not the asset in this case, but the rights expression is treated as an asset.

The XML encoding of this scenario in ODRL is shown below:


                        xmlns:o-dd="https://odrl.net/1.0/ODRL-DD"
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xsi:schemaLocation="https://odrl.net/1.0/ODRL-DD https://odrl.net/1.0/ODRL-DD-10.xsd
                                 https://odrl.net/1.0/ODRL-EX  https://odrl.net/1.0/ODRL-EX-10.xsd">
           
               
           
                          
                              
                                    10.9999999/voucher/383838383
                                      The Voucher for XML: The Movie 
                             
                   
           
                     
                              
                                    c=US;o=Example;cn=J J Jones
                             
                   
             
                        
                                 
                                       
                                                 
                                                    2001-12-31

4.4.6 Education Scenario #1

An online lecture (software application) is offered (execute) for a per-use fee of $AUD2.00 which must be constrained to a certain network. Additionally, for a fee of $AUD1000.00 the lecture can be lent to (up to) 100 individuals.

The rights holder receives 50% of the execute fee and 25% of the lend fee. (Note the linking between the party entity and the permission entities.)

The XML encoding of this scenario in ODRL is shown below:


                       xmlns:o-dd="https://odrl.net/1.0/ODRL-DD"
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                         xsi:schemaLocation="https://odrl.net/1.0/ODRL-DD https://odrl.net/1.0/ODRL-DD-10.xsd
                                 https://odrl.net/1.0/ODRL-EX  https://odrl.net/1.0/ODRL-EX-10.xsd">
           
               
           
                      
                              
                                    10.9999999/learnobject/uni/aa/7373722
                                    XML: The Lecture
                             
                   
             
                        
                              
                                    c=AU;o=UniA;cn=Prof Bean
                                
                           
                                       
                                                50       
                                                
                                    
                                         
                                                25       
                                                
                                    
                                 
                      
             
                        
                                
                                    
                                                 
                                   
                                        
                                                
                                                     
                                                            2.00
                                                       
                                           
                                    
                               
                   
           
                        
                                
                                       
                                                 
                                                         
                                                                 
                                                                      1
                                                                          100
                                                            
                                                     
                                                
                                        
                                        
                                                
                                                     
                                                            1000.00

4.5 XML Minimisation

This specification uses XML for its syntactical representations. However, there are cases where a more compact binary representation is required to reduce the transmission size of XML documents and allowing more effective use of XML data on narrowband communication channels.

It is proposed that such a representation can be achieved by utilising the WAP Binary XML Content Format [WBXML].

5 ODRL Extensibility

ODRL defines both the core structure of the expression language and a set of core elements as part of the ODRL data dictionary. Additional data dictionaries can be defined and used within the ODRL framework To define a new data dictionary, a new XML Schema must be created that imports the ODRL expression language schema.

The expression language schema defines elements that are utilised as the "place holder" for data dictionary elements. For example, the ODRL Expression Language schema defines:

which allows permission elements to be defined in the ODRL Data Dictionary schema, such as:

The Data Dictionary schema utilises the "substitutionGroup" mechanism from XML Schema to ensure that only the appropriate elements can be used in the correct position in the ODRL Expression Language.

There are six substitution elements that can be used for additional data dictionaries:

permissionElement
requirementElement
constraintElement
conditionElement
contextElement
rightsholderElement

When defining additional data dictionary elements, ensure that they are defined using one (and only one) of these substitution groups. The additional data dictionary elements may also define extensions, such as attributes or other complex data structures.

5.1 Example

Lets assume that the Mobile sector wishes to use ODRL but needs to extend the data dictionary to provide two new Permissions (Ring, Send) and one new Requirement (sms-accept). The first step is to define their new XML Schema for this data dictionary as shown in Example 18 and assign an appropriate XML Namespace.

Example 18. Mobile Data Dictionary XML Schema
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" xmlns:o-ex="https://odrl.net/1.0/ODRL-EX" elementFormDefault="qualified" attributeFormDefault="qualified"> schemaLocation="https://odrl.net/1.0/ODRL-EX-10.xsd"/>

Example 18. Mobile Data Dictionary XML Schema


                             xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
                           xmlns:o-ex="https://odrl.net/1.0/ODRL-EX"
                          elementFormDefault="qualified" attributeFormDefault="qualified">
               
                     
                                    schemaLocation="https://odrl.net/1.0/ODRL-EX-10.xsd"/>

The next step is to use the Mobile Data Dictionary as you would normally for ODRL expressions. Consider the Offer shown in Example 19. In this case the offer over the specified asset is to "give" it away and to allow the "ring" permission with a constraint of 200 times. There is also a Requirement to pay an amount and to accept SMS messages (sms-accept).

Example 19. Mobile Example
xmlns:o-dd="https://odrl.net/1.0/ODRL-DD" xmlns:mm="http://example.net/MOBILE-DD"> 10.999999/ringtone/1234567WWW 200 5.00

Example 19. Mobile Example


                          xmlns:o-dd="https://odrl.net/1.0/ODRL-DD" 
                         xmlns:mm="http://example.net/MOBILE-DD">
               
               
               
                          
                                  
                                         10.999999/ringtone/1234567WWW 
                                      
                       
               
                         
                                     
                                  
                                             
                                                       200  
                                       
                                    
                                    
                                            
                                                 
                                                        5.00

6 References

Technical Standards:

[AAP] Digital Rights Management for Ebooks: Publisher Requirements, Version 1.0, Association of American Publishers, 2000.

[DCMI] Dublin Core Metadata Initiative

[DIG35] DIG35 Specification - Metadata for Digital Images - Version 1.0, August 30, 2000

[DOI] Digital Object Identifier

[EBX] Electronic Book Exchange

[FPI] Information Technology SGML Support Facilities Registration Procedures for Public Text Owner Identifiers, ISO/IEC 9070, Second Edition, International Organization for Standardization, April, 1991.

[GUID] Globally Unique Identifier

[IDDN] International Identifier of Digital Works

[IFLA] Functional Requirements for Bibliographic Records

[IMS] IMS Global Learning Consortium

[IMT] Internet Media Types

[INDECS] Interoperability of Data in Ecommerce Systems

[ISAN] International Standard Audiovisual Number

[ISBN] International Standard Book Number

[ISRC] International Standard Recording Code

[ISSN] International Standard Serial Number

[ISTC] International Standard Textual Work Code

[ISWC] International Standard Musical Work Code (ISO/15707)

[ISO3166] Country Names and Code Elements

[ISO4217] Currency Names

[ISO8601] ISO (International Organization for Standardization). Representations of dates and times

[MARC] MARC Code List for Relators

[MPEG] Moving Picture Experts Group

[mpg_ID] MPEG Content Related ID Registration in System Level for MPEG RDD Requirement. M7671, Pattaya, December 2001.

[MPEG7] MPEG7 Roles List

[OEBF] OpenEBook Forum

[ONIX] ONIX International

[PRISM] Publishing Requirements for Industry Standard Metadata, 2001

[PROPAGATE] Propagate Project

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels

[URI] Uniform Resource Identifiers (URI): Generic Syntax

[UUID] Universal Unique Identifier

[VCARD] vCard MIME Directory Profile

[WBXML] WAP Binary XML Content Format, W3C NOTE 24 June 1999

[X500] Technical Overview of Directory Services Using the X.500 Protocol, 1992

[XML] Extensible Markup Language 1.0

[XML-ENC] XML Encryption Syntax and Processing, W3C Working Draft 18 October 2001

[XML NAMESPACE] Namespaces in XML

[XML SCHEMA] XML Schema Part 1: Structures, Part 2: Datatypes

[XML-SIG] XML-Signature Syntax and Processing, W3C Proposed Recommendation, 20 August 2001

Papers:

[ERICKSON] A Digital Object Approach to Interoperable Rights Management, John S Erickson, D-Lib Magazine, June 2001, Volume 7 Number 6

[HIGGS] Rights Management: Managing the Layers of Rights and Roles in the Knowledge Based Economy, Peter Higgs, 2000, IPR Systems Report.

[IANNELLA] Digital Rights Management (DRM) Architectures, Renato Iannella, D-Lib Magazine, June 2001, Volume 7 Number 6

7 Acknowledgements

The editors wish to acknowledge the following organisations as formal supporters of the ODRL Initiative:

IPR Systems
Simpsons Solicitors
OzAuthors
Pipers
ARPA
Vienna University
Information Management Australia

The editors wish to specially acknowledge the contributions to this document from Nokia:

Julian Durand
Honglang Zhang
Leon Hurst
Markku Kontio
Oliver Bremer

The editors wish to acknowledge the support from the following organisations:

IBM
Adobe
Panasonic
MarkAny

The editors gratefully acknowledge feedback to this document from:

Peter Higgs, IPR Systems
David Parrott, Reuters
Robert Bolick, McGraw-Hill
Judie Mulholland, Florida State University
Susanne Guth, Vienna University
Sheng Mei Shen, Panasonic
Andy Powell, UKOLN
Craig A Schultz, Accessticket
Joseph Reagle Jr, W3C
Bob Mathews, Adobe
Rick Jelliffe, Topologi
Jason Boyer, Adobe

Appendix A: ODRL Expression Language XML Schema (Normative)

The XML Namespace URI for the ODRL Expression Language version 1.0 is:

https://odrl.net/1.0/ODRL-EX

The actual location of the XML Schema is:

https://odrl.net/1.0/ODRL-EX-10.xsd

The XML Schema is documented at:

https://odrl.net/1.0/ODRL-EX-10-DOC/index.html


               xmlns:o-ex="https://odrl.net/1.0/ODRL-EX" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
            xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
               xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
               elementFormDefault="qualified" attributeFormDefault="qualified" version="1.0">
         
               
               schemaLocation=" http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/xmldsig-core-schema.xsd"/>
           
                schemaLocation="http://www.w3.org/TR/2001/WD-xmlenc-core-20011018/xenc-schema.xsd"/>

Appendix B: ODRL Data Dictionary XML Schema (Normative)

The XML Namespace URI for the ODRL Data Dictionary version 1.0 is:

https://odrl.net/1.0/ODRL-DD

The actual location of the XML Schema is:

https://odrl.net/1.0/ODRL-DD-10.xsd

The XML Schema is documented at:

https://odrl.net/1.0/ODRL-DD-1.0-DOC/index.html


                      xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:o-dd="https://odrl.net/1.0/ODRL-DD" 
                    xmlns:o-ex="https://odrl.net/1.0/ODRL-EX"
                    elementFormDefault="qualified" attributeFormDefault="qualified" version="1.0">
         
               
                                                                                      schemaLocation="https://odrl.net/1.0/ODRL-EX-10.xsd"/>

Appendix C: Document Change History (Informative)

Major changes from Version 0.9 to 1.0 of the ODRL Expression Language include:

Added explicit support for the construct to complement the existing construct (see Section 2.8 "ODRL Offer Model")
Added new section on Security (see Section 2.11 "ODRL Security Model") to include support for Digital Signatures and Encryption
Added new section on Sequence of entities (see Section 2.13 "Expression Sequence")
Added new section on Inheritance of entities (see Section 2.15 "Expression Inheritance")
Added Section 4.5 "XML Minimisation"
Added Section 2.5 "ODRL Condition Model"
Added Section 2.10 "ODRL Revoke Model"
Removed "narrow" attribute from Permission entity. Now described as a constraint in Section 2.3.2 "Transfer Permission Constraint Example".
Removed the incomplete "Transporting ODRL Expressions" section as this out of scope for ODRL
Modified RightsHolder model to have Party as the parent of rightsholder children
Updated Section 5 "ODRL Extensibility"

Major changes from Version 0.9 to 1.0 of the ODRL Data Dictionary include:

Added "version" to Context
Added "transaction" to Context
Added "service" to Context
Default scheme for UID element is "URI"
Added explicit sub elements to Date Time: (removed attributes)
Added explicit sub elements to Count: (removed attributes)
Added explicit sub elements to Range: (removed attributes)
Split "dateEvent" from Context into "Date" and "Event" elements
Added new "Asset Management" Permissions: Move, Duplicate, Delete, Verify, Backup, Restore, Install, Uninstall, Save
Added new "Interactions" Requirements: Accept, Register
Added new "Usage" Requirements: Attribution, Tracked
Added "hardware" permission to Constraints
Renamed the "copy" permission to "excert"
Added "aggregate" permission
New idschemes added to : mpg_ID, ISAN, ISRC, ISSN, ISWC, IDDN, UUID
Renamed "Location" (in Context) to "Physical Location
Added "Digital Location" to Context
Removed the Spatial constraint entity ("country") and created a new "spatial" element to be under the "Bounds" constraint entity.
Added "purpose" and "industry" constraints.