Copyright IPR Systems 2002. This document is available under the W3C Document License. See the W3C Intellectual Rights Notices and Disclaimers for additional information.
The Open Digital Rights Language (ODRL) is a proposed language for the Digital Rights Management (DRM) community for the standardisation of expressing rights information over content. The ODRL is intended to provide flexible and interoperable mechanisms to support transparent and innovative use of digital resources in publishing, distributing and consuming of electronic publications, digital images, audio and movies, learning objects, computer software and other creations in digital form. The ODRL has no license requirements and is available in the spirit of "open source" software.
This document is a submission to the World Wide Web Consortium from IPR Systems Pty Ltd (see Submission Request, W3C Staff Comment). For a full list of all acknowledged Submissions, please see Acknowledged Submissions to W3C.
This document is a NOTE made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. W3C has had no editorial control over the preparation of this Note. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.
A list of all W3C technical reports can be found at http://www.w3.org/TR/.
Please send feedback to <feedback@odrl.net> and general comments to <info@odrl.net>. Interested parties wishing to support the ODRL Initiative, please send email to <support@odrl.net>.
Further information on ODRL can be found at <http://odrl.net>
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.
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.
DRM systemts must also address and be consistent with the non-technical issues, including legal, business and social aspects of rights management. A recent W3C DRM Workshop [W3C-DRM] produced a number of position papers highlighting these important issues.
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:
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.
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:
The formal Expression Language and Data Dictionary elements are defined in:
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.
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.
The model, as shown in Figure 1, consists of the following three core entities:
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 a Uniform Resource Identifier [URI]. The URI is a unique identification system and may also include a resolution mechanism to the actual entity. Both of these entities contain a mechanism to refer to their unique identifiers, as well as a Context description.
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:
The security-based entities (Signature and Encryption) are further explained in the following section:
Additional features of the ODRL expression language are explained in the following sections:
The ODRL Foundation Model can be expressed using an XML binding. An example is shown in Example 1.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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.
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:
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:
A Permission must be associated with one or more Assets via an Offer or Agreement. This association can be explict (ie Permission is a child element of Offer or Agreement) or implict via a reference from an Offer/Agreement). A Permission can be associated with zero or more Constraints, Conditions, and Requirements.
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.
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.
<permission> <display/> <print> <constraint> ... </constraint> </print> <annotate/> </permission> |
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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.
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:
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. As an example of this, consider the <unit> constraint and it's meanings when used with the <count> and <range> constraints:
Additionally all Constraint elements may have a Context element (to support the use of uid) and a "type" attribute (to refer to additional information).
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.
For Permissions with multiple constraints, all constraints must be honoured with no conflicts arising. An error must be generated if the latter is true.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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:
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.
Some constraints are based on entities that could contain a number of sub-entities (ie members).
For example, a Group constraint would normally refer to a collection of individuals. Under normal conditions, a Print permission with a Count constraint of "1" that appeared with a Group constraint would indicate that the asset can only be printed once. However, we may wish the Count constraint of "1" to apply to each member of the Group constraint, thus enabling each individual to print the asset once.
In cases where the constraint needs to apply at the level of each member of another constraint then we can support this feature with a "forEachMember" mechanism. This mechanism enables any member-based constraint to be identified and the referring constraint will apply to each member of that constraint.
ODRL defines a URI to represent these semantics:
This URI value is used in the "type" attribute of the constraint element. The constraint elements refer to each other using id/idref (see Section 2.14).
Consider Example 4B where an asset has been acquired for teaching a class (eg JAVA101). The teacher has purchased the rights to an asset and the first constraint (with id of "Student01") enables any member of the identified group to display the asset. The print permission also has a constraint of "1" but this constraint refers to the first constraint (using idref) and has the "forEachMember" type attribute. This means that each member of the Group can print the asset once (and not that the asset can be printed once in total).
<display> <constraint id="student01"> <group> <context> <uid>ldap://dir.uni.au/class=JAVA101;o=A-UNI;c=AU</uid> </context> </group> </constraint> </display> <print> <constraint idref="student01" type="http://odrl.net/1.1/#forEachMember"> <count>1</count> </constraint> </print> |
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.
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:
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.
Additionally all Requirement elements may have a Context element.
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.
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.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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.
The Condition entity reuses two existing entities:
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.
Additionally all Condition elements may have a Context element.
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.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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.
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:
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).
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports expressing additional information about entities and related entities. The ODRL Context Model is shown in Figure 7.
The Context entity is an aggregation of ten other entities and includes:
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 (using the xml "lang" attribute).
The reference to identifiers (in the uid element) and vocabulary values (in the role element) should be conformant URIs. For identifiers, this requires the value to be one of the URI family (eg URL, URNs etc). For vocabulary values, this requires the scheme to be registered with an appropriate namespace. This mechanisms provides the most flexibility for additional URIs and vocabulary schemes to be utilised in ODRL. However, for backward compatibility, the <uid> element may also contain string datatypes.
Multiple uid elements can also be used in the context. For example, an Asset may contain many parts and each can be referenced via a uid element enabling the collection to be viewed as a whole Asset.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports expressing offers made from Rights Holders for specific rights over their assets. The ODRL Offer Model is shown in Figure 9.
The Offer entity is an aggregation of four other entities and includes:
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.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports expressing agreements made between parties for specific rights over assets. The ODRL Agreement Model is shown in Figure 9.
The Agreement entity is an aggregation of four other entities and includes:
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.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
ODRL supports revoking offers, agreements, and other rights expressions. The ODRL Revoke Model is shown in Figure 10.
The Revoke entity is an aggregation of one other entity:
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:
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.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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.
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.
To support information about the encryption of assets, ODRL defines a new entity called "Digest" that is a child 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:
The Asset entity contains a single "Key Info" entity that can either contain:
The Encrypted Key entity contains the following child entities:
A ODRL Encryption Profile is limited to the following required constraints:
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.
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:
The Signature entity also includes:
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:
A ODRL Digital Signature Profile signature is a valid signature (as defined in [XML-SIG]) limited to the following required constraints:
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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.
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:
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.
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).
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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:
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. Note: the order is dictated by this number attribute, not the physical order of the expressions.
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.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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. During this merge process, care must be taken that no conflicts arise inthe resultant rights expression.
The inherit element has an "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 also has a "default" attribute for parent assets, that, if true, will not allow child assets to override its rights. The default is false.
Both "override" and "default" cannot be true at the same time.
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.
Complete and formal syntactical examples are given in Section 4 "ODRL XML Syntax".
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:
The data dictionary elements are defined below in the following sections:
The Elements are defined in Table 1: Permission Elements.
The Elements are defined in Table 2: Constraint Elements.
