ODRL V2.0 - Core Model

Draft Specification: 15 October 2010 ("Namur Edition")

This version:: http://odrl.net/2.0/DS-ODRL-Model-20101015.html
Latest version:: http://odrl.net/2.0/DS-ODRL-Model.html
Previous version:: http://odrl.net/2.0/DS-ODRL-Model-20090923.html
Editors:: Renato Iannella, Semantic Identity, risemanticidentity.com; Helge Hundacker, University of Koblenz, hundackeruni-koblenz.de; Daniel Paehler, University of Koblenz, tulkasuni-koblenz.de; Andreas Kasten, University of Koblenz, andreas.kastenuni-koblenz.de; Susanne Guth, Vodafone, susanne.guthvodafone.com

Abstract

This document describes the ODRL Version 2.0 Core Model Specification. The model incorporates new features and requirements for the ODRL policy expression language.

Status of this document

This is the fourth public Draft Specification of the ODRL V2.0 Core Model Specification document produced by the ODRL Version 2.0 Working Group.

The ODRL Initiative publishes a Draft Specification to indicate that the document is believed to be stable and to encourage implementation by the wider community. The ODRL Version 2.0 Working Group expects to advance this document to Specification once the Working Group has developed Working Drafts for the ODRL Version 2.0 Common Vocabulary and at least one Encoding and demonstrated at least two interoperable implementations.

Comments on this document should be sent to editors. Discussion of this document takes place on the public working group mailing list odrl-version2@odrl.net (archived at http://odrl.net/pipermail/odrl-version2_odrl.net/) and in the public ODRL Initiative Wiki.

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 Draft Specification does not imply endorsement by the ODRL Initiative.

This document uses the following visual indicators for substantial differences from the previous version:

Green background - Previous content has been updated
Yellow background - New content has been added
Pink background and strikeout - Previous content has been deleted

1. Overview
2. ODRL Core Model
3. Expression Semantics
3. Scenarios (Informative)
4. Profiles (Informative)
5. Experimental Features (Informative)
Acknowledgements
References

1. Overview

The ODRL policy expression language has benefited from a robust underlying information model that has captured its semantics and provided extensibility paths for various communities. ODRL Version 2.0 is a major update for ODRL and will supersede Version 1.1.[ODRL11]

The ODRL Core Model is designed to be independent from implementation mechanisms and is focussed on the optimal model and semantics to represent policy-based information.

The following documents are planned for ODRL Version 2.0:

ODRL V2.0 - Requirements [ODRL-REQ]. The Requirements document represents requirements for the language that have been gathered since ODRL Version 1.1 has been released. Not all requirements are aimed to be met.
ODRL V2.0 - Core Model (this document)
ODRL V2.0 - Common Vocabulary. This document will specify the potential terms (vocabulary) used by the Core Model for policy expression needs across communities. (This was called the "data dictionary" previously.)
ODRL V2.0 - Core Model - XML Encoding. The XML Encoding document will specify the serialisation of the Core Model in XML, including the normative XML Schema for the new Model and examples.
ODRL V2.0 - Core Model - RDF/XML Encoding. The RDF/XML Encoding document will specify the serialisation of the Core Model in RDF/XML.

The new model is based on additional semantics and requirements gathered from the DRM community, the latest research on security, access control, obligation management as well as the past experiences in implementations and research of ODRL. The requirements for Version 2.0 are documented [ODRL-REQ] and will be directly referenced in this document to ensure that they have been adequately addressed (where applicable).

The model shall be formally specified using UML notation [UML] [ODRL-REQ#6] and shall utilise the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in accordance to [RFC2119].

To make keywords easily distinguishable, this document uses syntax highlighting based on the following rules:

Core Model entities (classes in the UML diagram) begin with a capital letter and are formatted in bold fonts, e.g. Party, Asset or Role.
The entities' attributes begin with a lower-case letter and are formatted in bold fonts, e.g. uid, type or function. Attribute names comprising several words are written in "camelCase", i.e. each new word begins with a capital letter, e.g. inheritFrom or rightOperand.
The concrete values that the attributes can take begin with lower-case letters and formatted in typewriter font, e.g. invalid, assigner or true. CamelCase is also used for values, where necessary.

2. ODRL Core Model

Figure 2.1 below shows the complete version 2.0 ODRL Core Model. Policy is the central entity that holds an ODRL policy together. In its encoded form, e.g. in an XML document, it makes the policy addressable from the outside word via its uid attribute. Policy can refer to Permissions and Prohibitions.

A Permission allows a particular Action to be executed on a certain Asset, e.g. "play the audio file abc.mp3". A Constraint like "at most 10 times" might be added to specify the Permission more precisely. The Party that grants this Permission is linked to it with the Role assigner, the Party that is granted the Permission is linked to it with the Role assignee, e.g. "assigner VirtualMusicShop grants the Permission to assignee Alice". Additionally, a Permission may be linked to Duty entities.

Similar to Permissions, a Duty states that a certain Action must be executed by the Party with the Role assignee for the Permission to be valid, e.g. "Alice must pay 5 EUR in order to get the Permission to play abc.mp3".

The Prohibition entity is used in the same way as Permission, with the two differences that it does not refer to Duties and (obviously) that it forbids the Action, e.g. "Alice is forbidden to use abc.mp3 commercially".

ODRL Core Model Version 2.0

Figure 2.1 - ODRL Core Model Version 2.0

The following sections describes each entity of the Core Model in greater detail.

2.1 Policy

The Policy entity is the top-level entity and contains the following attributes:

uid: the unique identification of the Policy entity (REQUIRED)
type: indicates the semantics of the Policy entity (REQUIRED). These are further described in the ODRL profiles.
conflict: indicates the precedence between Permissions and Prohibitions (OPTIONAL)
undefined: indicates how to handle undefined Actions (OPTIONAL)
inheritAllowed: indicates if the Policy entity can be inherited (OPTIONAL)
inheritFrom: the identifier from which this Policy inherits from it's parent Policy (OPTIONAL)
inheritRelation: the identifier for the relationship type of this inheritance structure (OPTIONAL)

The uid attribute MUST be a unique identifier.

The range of values for the Policy entity's type attribute will be described in the Common Vocabulary document or in community profiles. This value may also impose further constraints on the expression language constructs, such as Offer and Agreement.

The conflict attribute is used to resolve conflicts arising from the merging of policies, specifically when there are conflicting Actions in the Permissions and Prohibitions. If present, the conflict attribute MUST take one of the following values:

perm: the Permissions will always takes precedence
prohibit: the Prohibitions will always takes precedence
invalid: the policy is not valid

If the conflict attribute is not explicitly set, its default value will be used instead. The default value of the conflict attribute is invalid.

The undefined attribute is used to indicate how to support Actions that are not part of any known profile in the policy expression system. If present, the undefined attribute MUST take one of the following values:

support: the Action is to be supported as part of the policy - and the policy remains valid
ignore: the Action is to be ignored and not part of the policy - and the policy remains valid
invalid: the Action is unknown - and the policy is invalid

In the support case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MUST be made aware of the unknown Action. This may be via a user interface that displays the unknown Action for human readability.

In the ignore case, even though the Action is unknown, the policy still is valid and the consuming parties or system of the policy MAY be made aware of the unknown Action.

In the invalid case with the unknown Action, the policy is invalid and the consuming parties or system of the policy MUST be made aware of this.

If the undefined attribute is not explicitly set, its default value will be used instead. The default value of the undefined attribute is invalid.

Other attributes may be added to the Policy entity to support additional functions and requirements. Typically, these will be from different community vocabulaires. For example, to indicate the issued date or valid dates of the Policy entity, use of the Dublin Core Metadata Terms would be recommended.

2.1.1 Inheritance

The inheritAllowed attribute in the Policy entity is used to indicate if the Policy expression can be used in any inheritance relationship [ODRL-REQ#1.20]. If present, the value of the inheritAllowed attribute MUST take one of the following values:

true: the Policy expression can be used for inheritance
false: the Policy expression can not be used for inheritance

If the inheritAllowed attribute is not explicitly set, its default value will be used instead. The default value of the inherit attribute is true.

Only if the inheritAllowed attribute has the value true can the inheritFrom and inheritRelation attributes be specified.

The inheritFrom attribute in the (child) Policy will uniquely identify (via a UID) the (parent) Policy from which the inheritance will be performed.

The inheritRelation attribute in the (child) Policy will uniquely identify (via a UID) the type of inheritance from the (parent) Policy. For example, this may indicate the business scenario, such as subscription or other inheritance structures such as expression, manifestation. Such terms may be defined in the Common Vocabulary or community Profiles.

The following restrictions apply when using inheritance:

Single inheritance is only supported. (One Parent Asset to one or more Child Assets. No Child Asset can inherit from two or more Parent Assets.)
Inheritance can be to any depth. (Many levels of Children Assets.)
Inheritance cannot be circular.
The Child Asset will always override the Parent Asset. i.e.: If the same Action appears in the Parent, then it is replaced by the Child version, otherwise the Parent Actions are added to the Child's Actions.
No state information is transferred from the policy in the Parent Asset to the Child Asset

2.2 Asset

The Asset entity is primarily aimed at identifying the content that is the subject of ODRL policy, e.g. a media file. Furthermore, it can be used to represent other assets that are needed to express Duties. The Asset entity is referred to by the Permission and/or Prohibition entities, and also by the Duty entity.

The Asset entity contains the following attributes:

uid: the unique identification of the Asset (REQUIRED)
inheritFrom: the unique identification of the Asset whose policy will be inherited (OPTIONAL)

Since ODRL policies could deal with any kind of asset, the ODRL Core Model does not provide additional metadata to describe Asset entities of particular media types. It is recommended to use already existing metadata standards, such as Dublin Core Metadata Terms that are appropriate to the Asset type or purpose.

2.3 Party

The Party entity is aimed at identifying a person, group of people, or organisation. The Party MUST identify a (legal) entity that can participate in policy transactions [ODRL-REQ#1.5].

The Party entity contains the following attribute:

uid: the unique identification of the party (REQUIRED)

The Role entity is used to associate the Party entity with the relevant Permission, Prohibition, and Duty entities.

The ODRL Core Model does not provide additional metadata for the Party element. It is recommended to use already existing metadata standards, such as IETF vCard that are appropriate to the Party type or purpose.

The Party entity undertakes the same three roles with both the Permission and Prohibition entities:

A Party entity can transfer Permissions and Prohibitions by being the Assigner (supplier) of such.
A Party entity can receive Permissions and Prohibitions by being the Assignee (consumer) of such. Note, the Assignee can also represent a group of people and/or legal entities, but only one member of the group receives the set of Permissions.
A Party entity can receive Permissions and Prohibitions by being the Assignees (consumers) of such. In this case, the Party entity MUST identify a group of people and/or legal entities. Each member of the group receives the same set of Permissions and Prohibitions [ODRL-REQ#1.13].

The Party entity undertakes three roles with the Duty entity:

A Party entity can be responsible for undertaking a Duty by being the Assignee (debtor) of such.
A Party entity can be entitled to receive the outcomes of a Duty by being the Assigner (creditor) of such. Note, the Assigner can also represent a group of people and/or legal entities, but only one member of the group is the beneficiary of the Duty.
A Party entity can be entitled to receive the outcomes of a Duty by being the Assignees (creditors) of such. In this case, the Party entity MUST identify a group of people and/or legal entities. Each member of the group is the beneficiary of the Duty.

Finally, the Party entity undertakes an additional role with the Asset entity:

A Party entity can be related to an Asset by being the Rightsholder (owner) of such. This role allows expressing that someone simply "owns" an Asset.

2.4 Role

The Role entity is an association class and can be used to link to a Party from either Permission, Duty or Prohibition, indicating which role the Party takes with respect to the entity that links to it.

The Role entity contains the following attributes:

function: the functional role the Party takes (REQUIRED)
scope: defines how the role shall be interpreted under different contexts. (OPTIONAL)

The function attribute MUST take one of the following values:

assigner: indicates that the Party has assigned the associated Permission, Duty, or Prohibition. In other words, the Party grants a Permission or requires a Duty to be performed or states a Prohibition.
assignee: indicates that the Party has been assigned the associated entity, i.e. they are granted a Permission or required to perform a Duty or have to adhere to a Prohibition.

Other values for the function attribute may be defined in the Common Vocabulary and community Profiles.

The scope attribute MAY be used to indicate the context under which to interpret the Party entity. If present, the scope attribute MAY take one of the following values:

individual: indicates that the Party entity is a single individual. The linked Permission, Duty or Prohibition is applicable for that individual only.
group: indicates that the Party entity represents a group. The group consisting of many individual members. The linked Permission, Duty or Prohibition is applicable for each member of that group. For example, a (constrained) Permission to play a movie 5 times is valid for each Party member or the Duty to pay 3 EUR has to be fulfilled by each Party member.

Other values for the scope attribute may be defined in the Common Vocabulary and community Profiles.

2.5 Permission

The Permission entity indicates the Actions that the assignee is permitted to perform on the associated Asset. In other words, what the assigner (supplier) has granted to the assignee (consumer). Any ODRL policy expression MUST contain at least one Permission. If several Permission entities are referred to by a Policy, all of them are valid.

The Permission entity has the following relations:

Party: linked to via Role (see Section 2.4). At least one Party (the assigner) MUST be referred to (REQUIRED)
Action: the Permission entity MUST refer to exactly one Action that indicates the granted operation on the linked Asset (REQUIRED)
Asset: the Permission entity MUST refer to exactly one Asset on which the linked Action may be performed (REQUIRED)
Constraints: the Permission MAY refer to one or more Constraints which affect the validity of the Permission, e.g. if the Action play is only permitted for a certain period of time (OPTIONAL)
Duty: the Permission MAY refer to one or more Duty entities that indicate a requirement that must be fulfilled in return for receiving the Permission (OPTIONAL)

2.6 Duty

The Duty entity indicates a requirement that must be fulfilled in return for being entitled to the referring Permission entity [ODRL-REQ#1.8]. While implying different semantics, the Duty entity is similar to Permission. If a Permission refers to several Duty entities, all of them have to be fulfilled for the Permission to become valid. If several Permission entities refers to one Duty, then the Duty only has to be fulfilled once for all the Permission entities to become valid.

The Duty entity contains the following attributes:

uid: a unique identification for this Duty. (REQUIRED)
relax: indicates if the Duty may be fulfilled at any time (OPTIONAL)

If set, the relax attribute MUST take one of the following values:

true: this means that the Duty may be fulfilled at any time, including after the containing Permission has been utilised by the Party with the Role assignee
false: the Duty must be fulfilled before the Permission can be exercised

If not explicitly set, relax takes the default value false. Note that the Duty has to be fulfilled eventually, regardless of the value of relax.

The Duty entity has the following relations:

Action: indicates the operation (e.g. pay) that must be performed (REQUIRED). Note: It is assumed that the assigned Party has the appropriate permissions to perform this action.
Party: a Duty MAY refer to Party entities with different Roles (see Section 2.4). If no explicit Party is linked to as assignee or assigner, the Parties with the respective Roles are taken from the referring Permission. (OPTIONAL)
Asset: a Duty MAY refer to at most one Asset which is related to fulfilling the Duty. For example, a pay Action must be linked to an Asset that indicates the amount to pay. The mechanisms to perform this linking/packaging are defined by community Profiles. (OPTIONAL)
Constraint: a Duty MAY link to one or more Constraints [ODRL-REQ#1.10] (OPTIONAL)

2.7 Prohibition

The Prohibition entity indicates the Actions that the assignee is prohibited to perform on the linked Asset [ODRL-REQ#1.7]. Prohibitions are issued by the supplier of the Asset - the Party with the Role assigner. If several Prohibition entities are referred to by a Policy, all of them are valid.

The Prohibition entity has the following relations:

Party: linked to via Role (see Section 2.4). At least one Party (the assigner) MUST be referred to (REQUIRED)
Action: the Prohibition MUST refer to exactly one Action, for example copy (REQUIRED)
Asset: the Prohibition entity MUST refer to exactly one Asset on which the Action is prohibited (REQUIRED)
Constraint: one or more Constraints MAY optionally constrain a Prohibition (OPTIONAL)

2.8 Action

The Action entity (when related to a Permission entity) indicates the operations (e.g. play, copy, etc.) that the assignee (i.e. the consumer) is permitted to perform on the Asset linked to by Permission. When related to a Prohibition, the Action entity indicates the operations that the assignee (again the consumer) is prohibited to perform on the Asset linked to by Prohibition. Analogously, when related to a Duty, it indicates an operation that has to be performed.

Action contains the following attribute:

name: indicates the Action entity term (REQUIRED)

As its value, the name attribute SHOULD take one of a set of Action names which are formally defined in profiles. The ODRL Common Vocabulary defines a standard set of potential terms that may be used. Communities will develop new (or extend existing) profiles to capture additional/refined semantics.

2.9 Constraint

The Constraint entity indicates limits and restrictions to the Permission, the Prohibition and the Duty entity [ODRL-REQ#1.9]. Constraints express mathematical terms with two operands and one operator. For example, the "number of usages" (name) must be "smaller than" (operator) the "number 10" (rightOperand). If several Constraints are linked to by the same entity, all of them are valid.

The Constraint entity contains the following attributes:

name: a name that identifies the the left operand of the operation (REQUIRED)
operator: an operator function (REQUIRED)
rightOperand: the right operand of the operation (REQUIRED)
status: the current value of the left operand (OPTIONAL)

The name identifies the left operand of the mathematical operation for the Constraint such as "Number of Usages" and "Expiration Date" etc. The operator identifies the comparative operation such as "greater than" or "equal to". The rightOperand identifies the value that is being compared. When processing policy expressions, these Constraint names SHALL be directly linked to a procedure that can determine the outcome of the operations, such as the number of already performed usages and the current date. The name and operator would be defined in the Common Vocabulary or community profiles.

The status provides the current value of the Constraint variable (i.e. current value of name) [ODRL-REQ#1.3]. This is useful in cases where the current status of Constraints needs to be captured and expressed in the ODRL Core Model.

3. Expression Semantics

A number of normative rights expressions features supported by the ODRL Core Model are discussed in this section.

3.1 Next Rights

The NextRights association allows for the specification of downstream (or transfer) rights to subsequent Assignee/s. The NextRights is expressed as a direct relationship between the pertinent Action and a Rights expression (that is the set of rights that the Assignee/s must only use for downstream assignment). The NextRights rights expression may not contain an Asset entity. In this case the Asset is assumed to be the same as in the current (upstream) rights expression. When an Asset entity is included in the NextRights expression, then it is assumed that this Asset is a subset (or strongly related) to the upstream Asset. For example, the upstream Asset maybe a collection of five tracks on a music Album, and the downstream Asset is one specific track. For a Next Rights example please refer to Section 4 Scenarios.

3. Scenarios (Informative)

This section shows a number of policy expression scenarios. In these examples, the different policy expression types that are used are for illustrative purposes only and are not part of this normative specification. Also, the specific Action and Constraint names (etc.) used in these examples are for illustrative purposes only. Please note that formal policy expression types and other entities will be defined in the ODRL Common Vocabulary specification, or in community profiles.

3.1 Set

The following shows an instance of a Set Policy. The Set shows a policy expression, stating that the Asset urn:asset:9898 is target of the Permissions publish and the Prohibition to modify. No parties or other elements are involved. This Set could be used, for example, as a template or an instant license.

instance set

Figure 3.1 - An instance of a Set Policy

3.2 Offer

The following shows the instance of an Offer Policy. The Offer contains the music file urn:music:4545 that is offered by the Party urn:sony:10 with the Permissions to play and copy the file. The Permission copy is only granted once. The two Permissions are offered for a payment of AUD$0.50.

instance Offer

Figure 3.2 - An instance of an Offer Policy

3.3 Agreement

The following shows the instance of an Agreement Policy. The Agreement contains all entities shown in the Offer scenario above. A new Party element urn:billie:888 has been added. This Party accepted the previous Offer and thus is now the buyer of the Permissions play and copy, i.e. is related as assignee of the Permissions and Duty elements.

instance Agreement

Figure 3.3 - An instance of an Agreement Policy

3.4 Request

The following shows the instance of a Request Policy. The Party urn:guest:0589 Requests the Permission to display the Asset urn:news:0099.

instance Request

Figure 3.4 - An instance of a Request Policy

3.5 Ticket

The following shows the instance of a Ticket Policy. The Ticket expresses the play Permission for the Asset urn:game:4589. The Ticket is valid until the end of the year 2010. Any valid holder of this ticket may exercise this Permission.

instance Ticket

Figure 3.5 - An instance of a Ticket Policy

3.6 Offer and Next Policy

The following shows the instance of an Offer Policy with NextPolicy. The party urn:sony:99 assigns the Permission distribute directly to the potential buyer of the permission who will pay $EU1,000. The distribute Permission is also constrained to the country Italy. The potential assignee may then distribute the Asset according to the NextPolicy linked directly from this Duty. In this case, the linked Asset may only be displayed to downstream consumers.

instance next rights

Figure 3.6 - An instance of an Offer and Next Policy Policy

3.7 Extended Relation

The following shows the instance of an Offer with a Permission Extended Relation. The Offer includes two Permissions copy and print that are tied together by a logical XOR operator, i.e. either the Permission print or the Permission copy may be performed but not both. The print Permission may only performed 5 times. Note that each of the Permissions may have their individual constraints, target, etc.

instance container

Figure 3.7 - An instance of an Extended Relation

3.7 Privacy

The following shows the instance of an Privacy Policy. The Asset is Personal Data and the Assignee is allowed to distribute the Asset only for the purpose of contacting the subject of the Personal Data. The purpose value is taken from the P3P privacy purpose vocabulary. Additionally, the assignee must delete the Asset after a 30 day period (retention policy).

instance Privacy

Figure 3.7 - An instance of an Privacy Policy

3.8 Permission and Prohibition

The following shows the instance of an Agreement Policy with both a Permission and a Prohibition. The party urn:sony:10 assigns the Permission play to the Party billie:888 at the same time they are prohibited from utilising the Asset as a ringtone. Additionally, in case of any conflict, the conflict attribute is set to perm indicating that the Permissions will take precedence.

instance perm prohibit

Figure 3.8 - An instance of an Permission and Prohibition Policy

3.9 Inheritance

The following shows the instance of an Child Agreement urn:policy:9999 inheriting from a Parent Agreement urn:policy:5531 Policy. The inheritFrom attribute of the Policy of the Child Agreement has the same identifier as the Policy in the Parent Agreement. In this inheritance example, the Parent Agreement allows the Billie Party to print the parent Asset and the Child Agreement allows the Class:IT01 Party (a group of people) to print the child Asset and for the Billie Party to print the parent Asset. That is, the Child Agreement includes all the entities of the Parent Agreement.

instance inherit

Figure 3.9 - An instance of an Inheritance Policy

3.10 Social Network

The following shows the instance of an agreement Policy for a Social Network scenario. The Asset are photos posted to a Social Networks site and the assigner is the owner of the photos. The assignee is a group and represents the football network members on the social network, who are each allowed to display the photos.

instance social network

Figure 3.10 - An instance of an Social Network Policy

4. Profiles (Informative)

The ODRL Core Model represents a broad need for policy expressibility. As a result, different communities will require less or more elements from the Core Model. Community profiles of the ODRL model are expected to be developed that adequately document these changes in respect to the Core Model. Some requirements of this process include:

Document any additions to the Core Model
Document any aspects of the Core Model that will have different default values
Document which aspects of the Core Model are not being used (deprecated)
Declare your communities namespace (see Encoding specifications)
Share the Community profile with the ODRL Initiative for feedback and comments

5. Experimental Features (Informative)

This section contains advanced ODRL features. Although not part of the normative specification, they provide an opportunity for communities to experiment with and provide feedback on experiences that may be included in future ODRL versions.

5.1 Extended Relations

Extended Relations may tie Permission, Prohibition, Duty, and Constraint entities together with an AND, OR or XOR relationship. Only entities of the same type can be linked with this model. For example, a Permission and Prohibition cannot be linked together within this model. The Extended Relations model supports the following attribute:

operation: MAY be set with one of the mathematical values AND, OR and XOR. (OR is the default if not specified.)

The following table outlines the semantics of Extended Relations with respect to each of the main entity types.

	`Permission`	`Prohibition`	`Duty`	`Constraint`
`OR`	The related party MAY perform any (at least) one of the `Action`s	The related party MAY NOT perform at least one of the `Action`s	The related party MUST perform at least one of the `Action`s	The related `Permission`/`Prohibition`/`Duty` is restricted by at least one of the `Constraint`s
`AND`	The related party MUST perform all of the `Action`s	The related party MAY NOT perform all of the `Action`s	The related party MUST perform all of the `Action`s	The related `Permission`/`Prohibition`/`Duty` is restricted by all of the `Constraint`s
`XOR`	The related party MAY perform only one of the `Action`s	The related party MAY NOT perform only one of the `Action`s	The related party MUST perform only one of the `Action`s	The related `Permission`/`Prohibition`/`Duty` is restricted by only one of the `Constraint`s.

Note that Extended Relations are not needed to assign two or more Permissions to a Party entity. In this case simply use as many Assignee relations between Party and Permission as needed.

5.2 Consequences and Remedies for Duties

When assigning a Duty the policy assumes that the assignee will either perform the Duty (and then get access to the Asset) or not perform the Duty (and hence, not get access to the Asset). There is one exception in that Duty entity may contain the relax boolean that indicates the duty may be fulfilled at anytime, including after the Permission has been utilised by the assignee.

However, there is no concept of compensation for not performing the Duty. That is some type of consequence of not performing the Duty or a remedy if something went wrong. One possible solution would be to allow there to be Duty for Duties, making it clear the consequence of not performing that Duty within the specified terms.

Acknowledgements

The editors gratefully acknowledge feedback and contributions to this document from:

Vicky Weissman, Mark Strembeck, Alapan Arnab, Steven Rowat, Eetu Luoma, Jaime Delgado, Ruediger Grimm, Stuart Myles, Francis Cave, Rigo Wenning, Hassan Abdel-Rahman, Jonas Zitz
Members of the Version 2.0 Working Group

References

[ISO4217]	ISO 4217 currency and funds name and code elements. Specification, International Organization for Standardization (ISO), 07 July 2008. http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/currency_codes/currency_codes_list-1.htm
[ODRL11]	R. Iannella (ed). Open Digital Rights Language (ODRL), Version 1.1. Technical Specification, ODRL Initiative, 8 August 2002. http://odrl.net/1.1/ODRL-11.pdf
[ODRL-REQ]	S. Guth & R. Iannella (eds). Open Digital Rights Language (ODRL) Version 2.0 Requirements (Working Draft), ODRL Initiative, http://odrl.net/2.0/v2req.html, 24 November 2004.
[RFC2119]	Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. The Internet Society, March 1997. http://tools.ietf.org/html/rfc2119
[UML]	Unified Modeling Language (UML), Object Management Group, 2003. http://www.omg.org/technology/documents/formal/uml.htm