Open Digital Rights Language (ODRL) Version 2 Requirements

ODRL Initiative Working Draft: 13th Februar 2005

This version:
http://odrl.net/2.0/WD-v2req-20050213.html
Latest version:
http://odrl.net/2.0/v2req.html
Previous version:
http://odrl.net/2.0/WD-v2req-20041124.html
Editors:
Susanne Guth ODRL Initiative - susanneodrl.net
Renato Iannella ODRL Initiative - renatoodrl.net

Abstract

This document describes the requirements for the ODRL Version 2.0 specification

Status of this document

This section describes the status of this document at the time of its publication. This is a public Working Draft of the ODRL Version 2.0 Requirements document. It has been produced by the ODRL Version 2.0 Working Group. This is a ODRL Initiative Working Draft for review by ODRL Initiative members and other interested parties. Comments on this document should be sent to editors and discussion of this document takes place on the public ODRL Version 2.0 mailing list odrl-version2@odrl.net archived at http://lists.odrl.net/pipermail/odrl-version2/).

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than "work in progress".

Publication as a Working Draft does not imply endorsement by the ODRL Initiative.

Table of contents

1 Goals
2 Requirements
3 Acknowledgements
4 References

Goals

ODRL Version 2.0 has the following goals:

Requirements

1. Improving the ODRL data model

During two years of experience with the current ODRL Version 1.1 data model the following items were collected as additional required features of the data model.

   The issues list 1 discuss a new data model in general.

1.1 Provide improved next rights (downstream rights).

It is intended to support the application of next rights to an implementable number of levels. The value chain of electronic goods and services has several participants: For example, content creators, content distributors, and content consumers. ODRL should enable content creators to specify usage rights and conditions for a reasonable number of lower levels, i.e. the content distributors, the consumers, etc.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.2. Support the transfer of rights for content that is aggregated/dis-aggregated.

While being passed along the value chain, electronic goods and services are sometimes aggregated or dis-aggregated. In education for example, lecture notes, slides, exercises, and exams are bundled to a teaching package for an entire course. ODRL should support the representation of a package containing various assets, and at the same time maintaining and/or identifying the rights of a single part of an asset, e.g. for a set of slides.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.3. Support handling of status information for state-based rights constraints.

The ODRL community asked for a language feature in ODRL that expresses and handles status information for state-based rights constraints. For example, a ring tone is purchased with a stated-based rights constraint, e.g. the ring tone may be used up to 100 times. If the customer has played the ring tone already 10 times, this is a status information that some DRM applications might need in the ODRL expression. Therefore, ODRL requires the additional expressiveness to describe the respective status information.

   The issues list and the following threads in the version-2-interest-list discuss this requirement: [A]

1.4. Support contract negotiation.

Support flexible negotiations with mechanisms to select/choose different options in offers and agreements and the semantics of such selections.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.5. Provide additional contract parties or third parties.

The distinction between rightsholder and consumer is not sufficient in some cases. For example, if a consumer buys a license but is not the person that consumes the resulting access rights, a third contract party, such as a beneficiary or end user, is required. ODRL requires to express the status of the rights expression, respectively its current position in the contract life cycle. For rights expressions that represent tickets, ODRL also needs anonymous parties, so that the anonymous spending of tickets is possible (e.g. as an admission ticket to a concert). To read more details about this requirement, please refer to [GS04].

Additionally, ODRL should allow for generic rights expressions (and not specifying specific parties or assets), that can be externally linked. For example, a set of rights has been defined that may apply to a large, undefined number of assets, it may be more efficient to refer from the asset to this rights set than the other way around. Thus, it is not necessary to have a separate rights expression for each resource. Such "set of rights" are similar to the Creative Commons licenses.

   The issues list and the following threads in the version-2-interest-list discuss this requirement: [A], [B]

1.6. Provide fair use mechanisms.

Provide mechanisms to express "fair use" exceptions of copyrights laws, which is an implemented concept e.g. in the U.S. and Australian laws, for example.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.7. Provide a "NOT" expression.

The current basic concept in ODRL is that rights that are not explicitly granted by an expression are not allowed. In contrast to this, the ODRL community asks for a language concept that is able to express the following: "Everything is allowed, except for XXX". Therefore, provide mechanisms that state what you are NOT allowed to do.

   The issues list and the following threads in the version-2-interest-list discuss this requirement: [A],

1.8. Support rights and duties for all contract parties.

Provide language elements that can explicitly express right and duties of all contract parties. For example, expressing rights and duties for the rightsholder, e.g. that they must assure the delivery of a resource within the next 4 weeks. To see more details about this requirement, please refer to [GS04].

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.9. Provide an aligned constraint data model.

ODRL version 1.1. distinguishes between constraints, requirements, and conditions which can be assigned to ODRL permissions. Each of these clauses defines a certain side-condition for a respective permission. We believe that it would be more reasonable to distinguish between ODRL conditions/constraints on the one hand and ODRL requirements (which in essence define duties) on the other. ODRL conditions and ODRL constraints directly relate to a permission (e.g. do not play after 12/31/05; or play at most five times) whereas requirements are more of a precondition that has to be fulfilled before a right may actually be assigned to the corresponding beneficiary. ODRL requirements are classical duties, whereas ODRL conditions and ODRL constraints should be seen as constraints on permissions.

A corresponding data model would comply with the typical constraint data model of the access control community and ease the implementation and processing of expressions. To read more details about this requirement, please refer to [GS04].

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.10. Expressing constraints on requirements.

A common type of expression used in contracts is the following: "the payment has to be made within four weeks after receipt of the shipment." With respect to ODRL 1.1 this expression is a requirement (the payment) that is narrowed by a constraint (within four weeks). To read more details about this requirement, please refer to [GS04].

Allowing constraints for duties or requirements needs clear semantics how the constraints are solved. For example, if a permission is granted only iff all requirements are fulfilled, but e.g. the payment requirement has a later time for payment allowed, should the permission be granted or not?

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.11. Revision of the Offer/Agreement model.

There maybe cases where the current Offer/Agreement model is not relevant, other document types, such as tickets (vouchers), or just no specific document type is required. There is also the possibility of supporting a "Request for Rights" which is from a Consumer to a Rights Holder.

   The issues list and the following threads in the version-2-interest-list discuss this requirement: [A],

1.12. Expressing Exclusive Permissions.

There maybe cases where a Permission is required to be "Exclusive", e.g. make the Permission is granted exclusively to a party or web site. At the moment a Permission can be stated to be "Exclusive" with the use of an attribute. The ODRL specification has to be revised, whether Exclusive Permissions can be sufficiently expressed.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.13. Expressing Permissions/Constraints for each member of a group.

There are cases where a permission shall be granted for each member of a certain group, e.g. each member of a school class shall get the permission to access certain class material. A "forEachMember" Constraint would generally allow group members to be assigned individual rights and constraints (using URI and id/idref). Alternatively, the same concept could be expressed by a "Member" Constraint that is further specified, e.g. any Member, one Member, all members, etc.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.14. Revision of the Condition Model

The current Condition model is under-utilised. It needs to be reviewed with the new V2 data model.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.15. Revision of the Revoke Model

The current Revoke model is under-utilised. It needs to be reviewed with the new Version 2 data model to determine if it is still required. Revoking licenses may only make sense in specific implementations of trust models. If it remains in the Version 2 data model, typical use cases have to be provided.

   The issues list and the following threads in the version-2-interest-list discuss this requirement: [A],

1.16. Revision of the Security Model

The current Security Model is very explicit. It needs to be reviewed to determine if it is best to be more open with the details being provided in community Profiles (e.g. OMA Mobile DRM [OMA04]).

   The issues list and the following threads in the version-2-interest-list discuss this requirement: [A],

1.17. Revision of the Containers Model

The current Containers model needs to be reviewed to see if it is adequate and/or can be improved.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.18. Revision of the Sequence Model

The current Sequence model needs to be reviewed to see if it is adequate and/or can be improved.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.19. Revision of the Linking Model

The current Linking model needs to be reviewed to see if it is adequate and/or can be improved.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.20. Revision of the Inheritance Model

The inheritance model is used in the OMA DRM specification. It would be useful to review its use to ascertain if any improvements/refinements are necessary.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.21. Revision of the WEMI Model

ODRL supports the Work/Expression/Manifestation/Item model to describe layers of content (from the Library community). It would be useful to review this to ascertain if any improvements/refinements are necessary. It maybe better, for example, to incorporate this with Inheritance and/or Linking between assets.

1.22. Providing a "dynamic" time constraint.

A permission can be granted for a certain "static" moment, e.g. a fixed date. The permission could also be granted for a "dynamic" moment, for example the first time the user executes a permission. For example, a user can play a certain songs as often as he wants, but only up to five days after he played it for the first time.

   The issues list and the following threads in the version-2-interest-list discuss this requirement:

1.23. Allowing a wild card as constraint value.

Sometimes a wild card is required within constraints rather than a fixed value. In most cases one would like to restrict, e.g. the number of usages, to a fixed number to express something like "the number of usage may not exceed 5". There may be cases where you would like to express "the number of usages may not exceed 'the currently allowed maximum''.

1.24. Handling privacy issues with regard to transaction business and personal data in rights expressions.

Party elements in contracts reveal information about the purchasing patterns of parties, as well as personal information. ODRL Version 2 should address these privacy issues and give recommendations for their handling.

1.25. Expressing Quality of Service (QOS) dependent permissions and constraints.

Service Level Agreements (SLA) grant different services levels or permissions depending on environmental conditions. ODRL Version 2 should support expressing SLAs.

2. Keeping ODRL simple.

A basic requirement is to keep ODRL simple. Its simpleness is the one of the key reasons that many initiatives use ODRL than other more complex rights expression languages.

3. Maintain backwards compatibility with ODRL Version 1.1.

As ODRL has already been accepted by standard organisations, such as the Open Mobile Alliance, further developments of the language require to be able to handle all language concepts of previous versions.

4. Provide formal semantics for ODRL data model.

Formal semantics are required for the unambiguous implementation and processing of ODRL rights expressions. However, some pioneer work has already been done in this field [HKS04, PW04].

   The following threads in the version-2-interest-list discuss this requirement: [A]

5. Support related metadata standards and vocabularies.

ODRL should explicitly support the use of right vocabularies from various sectors and communities. It should also support the reuse of other metadata vocabularies to supplement, e.g. the context element. For example, instead of using the context element to describe personal information, the vCard standard could be used.

6. Use the Unified Modeling Language (UML) for the notation of the data model.

All technical diagrams should be created with diagram types from the Unified Modeling Language.

7. Revision of the ODRL data dictionary

During two years of experience with the current ODRL Version 1.1 data dictionary the following items were collected for discussion.

7.1. Permissions to function calls.

The data dictionary requires the respective permissions and constraints that can be used to grant permission to a certain function of an application. Sometimes the permission <execute> is too broad, as an application can have a large number of different functions. Some rights holder might want to restrict the usage of an application to certain functions.

7.2. Updating the Context Elements.

New or updated context elements may be required to express additional entity attributes. For example, identifying assets not by their "uid" but by their "class", like all spreadsheet documents.

7.3. Permissions and constraints for "disaggregation".

The data dictionary requires the respective permissions and constraints for the "disaggregation" of an aggregated asset. For example, if a teacher specifies rights for a bundle of learning resources, s/he might want to allow its disaggregation with certain constraints.

7.4. Constraints for the Aggregation element.

The data dictionary requires additional constraints for the Aggregation permission. ODRL shall allow the specification of constraints that must be preserved and propagated under aggregation or embedding.

7.5. Contract Attributes.

ODRLv2 should support context elements for the different rights document types (RDT). For examples, the attribute "Contract Domain" is required for agreements.

7.6. Accumulated Usage Rights

ODRLv2 data dictionary should support comprehensive permission terms that bundle single permissions. Comprehensive permission terms could be "All permissions" or "All usage".

7.7. Permission to publicly perform/present.

ODRLv2 data dictionary should support a permission that grants "publicly present" or "publicly perform" (e.g. in the present the content of a book in eductional context.)

7.8. Export/Import Rights

ODRLv2 data dictionary should support a permission that grants the "export" and/or "import" of some resource from/into the current (DRM) system.

7.9. Steaming Rights

ODRLv2 data dictionary should support a permission that grants the "streaming" of content.

7.10. Encrypt/Decrypt Rights

ODRLv2 data dictionary should support a permission that grants resp. prohibits the "encryption" or "decryption" of content.

7.11. Encrypt/Decrypt Rights

ODRLv2 data dictionary should support a permission that grants resp. prohibits to "reformat" content, e.g. to reformat an MP3 file to a WAV file.

Change History

 Section  Description
 New  Added Section 7.5 - 7.7 based on comments made by Eetu Luoma to the discussion list.
 New  Added Sections 7.8, 1.23, 1.24, and 1.25.
 1.10  Paragraph has been added that addresses "relaxed" Duties.
 7.8 - 7.11  Paragraphs have been added/modified after the review of the DMP requirements list [DMP05].

Acknowledgements

The editors gratefully acknowledge feedback to this document from:

References

[ODRL02]  Open Digital Rights Language (ODRL), Version 1.1. Technical Specification, ODRL Initiative, http://www.w3.org/TR/odrl/, August 2002.
[GS04]  S. Guth, M. Strembeck: A Proposal for the Evolution of the ODRL Information Model. In Workshop-Proceedings of the International Workshop on the Open Digital Rights Language (ODRL), Vienna, Austria, April 2004.
[HKS04]  M. Holzer, S. Katzenbeisser, C. Schallhart: Towards Formal Semantics for ODRL. In Workshop-Proceedings of the International Workshop on the Open Digital Rights Language (ODRL), Vienna, Austria, April 2004.
[PW04]  R. Pucella, V.Weissman: A Formal Foundation for ODRL, in Workshop on Issues in the Theory of Security (WITS), Barcelona, Spain, April 2004.
[OMA04]  The Open Mobile Alliance (OMA) http://www.openmobilealliance.org/, Last visited in October 2004.
[DMP05]  The Digital Media Project (DMP) Interoperable DRM Platform (IDP) Functions and Requirements. Doc. No. 0328/GA05, January 2005.