This document specifies the expected behaviour of an ODRL Evaluator, a piece of software that performs computations based on a set of policies, a request and a certain state of the world.

Introduction

The Open Digital Rights Language (ODRL) is a policy expression language that can be used to represent permitted, prohibited, and obligated actions over a certain asset.

The ODRL Information Model formally defines the core abstract concepts of the model and their properties by means of an OWL 2 Ontology (available at https://www.w3.org/ns/odrl/2/), which is described in the ODRL Vocabulary & Expression specification. This document does not contradict these documents, and its interpretation is subordinate to theirs.

The ODRL ontology can be used as a data model to represent machine-readable Policies and associate them with digital or analog assets. By using a machine-readable language to represent policies, ODRL implementations can provide useful functionalities such as those of a policy search engine, a policy compatibility checker, an access control system, a monitoring system, or a policy planning system, among others.

• which Permissions, Prohibitions, and/or Obligations (collectively named Rules) are active in a given instant of time. A Rule is said to be active if it is in effect;
• which Prohibitions and Obligations have been violated or fulfilled.

When the ODRL Evaluator evaluates Permissions, it is expected to work in at least one of these two scenarios:

1. Access control scenario: the ODRL Evaluator determines the access by users or software agents to digital resources considering a set of policies, the state of the world, and the description of the action that a user requests to perform on certain digital resources. It may be useful to distinguish between requested and attempted action. When an agent attempts to perform an action, e.g. an agent double-clicks on a picture, if the action is not permitted the attempt is recorded and if it is the case sanctioned. In the case of a request, only the answer is generated: either the action is permitted or the action is denied.
2. Policy monitoring scenario (also known as compliance checking or usage control): given a set of policies and the description of the state of the world that includes the actions actually performed, the ODRL Evaluator has to determine whether obligations or prohibitions have been fulfilled or violated by the performance of certain actions, and which permissions are active.

ODRL Evaluator

The ODRL Evaluator uses as input:

1. a Policy;
2. a formal description of the State of the World;
3. a formal description of an Evaluation Request that contains at least a description of an action (e.g. the type of the action, the actor who is located in a given place, the target, and an instant of time);

1. an Evaluation Report;

State of the World

The ODRL Evaluator requires a formal representation of the state of the world. The state of the world specifies knowledge representing real-world information that aids the evaluation of ODRL Policies. For example, a certain state of the world may include the current date and time, the location of agents, or the history of performed actions.

This document aims to provide a formal representation for the state of the world concepts that are necessary to evaluate ODRL policies, without forcing the usage of existing vocabularies, e.g., country codes can be modelled using the ISO 3166 and UN M49 standards. Furthermore, the formal representation of this information will be specified as RDF triples. The existence of these triples does not entail their represented world is a reality: the factuality of the class instances is not entailed, and hypothetical computations are possible. The implementor of the ODRL Evaluator may want to describe the factuality of relevant class instances. RDF triples to represent the state of the world may be generated as observations from the world generated by third parties or by the ODRL Evaluator itself.

• SotW: A set of knowledge representing real-world information aiding the evaluation of ODRL Policies
• currentTime: Denotes the current time of the state of the world
• location: Denotes the location where the policy is being evaluated
• assetCollection: Denotes an asset that is part of an asset collection
• partyCollection: Denotes a party that is part of a party collection
• report: Denotes existing reports from previously performed ODRL evaluations, i.e., to get history of attempted and performed actions
• count: Denotes the amount of times a rule has been exercised
• event: Denotes information about an event that has occurred, e.g., when it has occurred
• accumulatedTime: Denotes an accumulated amount of time a rule has been exercised
• recipient: Denotes information about a recipient of a rule that has been exercised

Evaluation Request

An evaluator requires an Evaluation Request as input. The Evaluation Request, which is represented in RDF, is formally defined by the class odrl-fs:EvaluationRequest and MUST contain the following properties:

• odrl:action: The action to be evaluated (e.g., use, read, modify).
• odrl:assignee: The party (e.g., person or organization) requesting/requested the action.
• odrl:target: The asset (e.g., file, document, data) on which the action is to be/was performed.
• dcterms:issued: The time of the request.

Additional contextual information can also be included in the Evaluation Request, e.g., a purpose for exercising the requested action.

To ensure consistency, it is recommended that requests conform to the defined SHACL shapes.

For formal validation and integration, the odrl-fs:EvaluationRequest class is defined in an OWL ontology, with corresponding SHACL shapes specifying structural constraints and a JSON-LD context to ensure semantic consistency across RDF representations. These resources can be found at the following locations:

• OWL Ontology
• SHACL Shapes
• JSON-LD Context

Semantics of Policies

There are three ODRL Policy subclasses (Agreement, Offer, Set), plus four non-normative ODRL Policy subclasses (Assertion, Privacy, Request, Ticket). Direct instances of the odrl:Policy class must be understood as policy odrl:Set policies. This subsection describes how are these policies to be understood in relation to semantics.

• A odrl:Set policy must be considered by an ODRL Evaluator. The odrl:Set is not necessarily linked to odrl:Offer nor odrl:Agreement.
  
• An odrl:Offer policy must not be considered by an ODRL Evaluator. It is created by an odrl:Assigner as a mere proposition.
• An odrl:Agreement policy must be considered by an ODRL Evaluator as any other odrl:Set policy. It represents the accord between (at least) one odrl:Assigner and a odrl:Assignee. An instance of odrl:Agreement may have a way for the odrl:Assigner to trace to its related odrl:Offer.

Before providing the semantics of an ODRL Policy that may contain one or more Rules, we have to provide the semantics of the different types of ODRL Rules: Permission, Prohibition, and Obligation.

Semantics of Permissions

In ODRL 2.2 a Permission can be limited by duties, like making a payment, we call these Conditions. It can also be limited by Constraints (in time, in space, etc.). In addition, the definition of the permitted action, the asset, and the party collection can be refined with Refinements. The evaluation of these Conditions (duties) and Constraints determine whether the Permission is active (i.e., it permits the performance of an action that belongs to the class of action regulated by the permission and that satisfies all the refinements) or not. Permissions can be evaluated in two different scenarios: access control or monitoring.

In the access control scenario: when an action is requested, the activation of permissions is computed. If there is an active permission that permits such an action with all refinements satisdied, then action is permitted. If there is not an active permission that permits such an action with all refinements satisdied, then action is denied.

In the monitoring scenario: when an action is performed, it is represented in the state of the world. When the performace of the action has to be evaluated with respect to the permissions. If the performed action belongs to class of actions regulated by the active permission and all the refinements satisfied then the action is permitted by the permission. If the performed action does not belong to class of actions regulated the permission or the permission is inactive then the action is not permitted by the permission.

The ODRL Evaluator computes that a Permission is active iif:

1. All the existing Constraints of the Rule are satisfied AND;
2. All the existing Conditions (duties) of the Rule are fulfilled or inactive;

If one of those conditions is not met, the Permission is inactive.
The ODRL Evaluator computes that the action represented in the Evaluation Request is permitted by a Permission in the given State of the World iff:

1. The Permission is active AND
2. The action is the Evaluation Request belong to the permitted class of actions with the correct target and assigee (when they are specified) AND
3. All the refinements (related to action, target, and assignee) are satisfied.

Please note that in the following examples namespaces are used, so that http://example.com/constraint/ is simplified by "constraint:", http://example.com/policy/ is simplified by "policy:", etc.

Notation used in the example tables: blue colour for the input and red colour for the output of the ODRL Evaluator

Evaluation of Constraints

Example description

A permission may have its action limited (in time, in space, etc.) without any Condition (Duty) or Refinement. This is the situation of the following case (similar to Example 13 in the ODRL Information Model 2.2). The permission below allows the target asset document:1234 to be distributed, it includes the constraint that the permission may only be exercised until 2018-01-01. The permission is granted by the organization party:16.

{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Set",
"uid": "http://example.com/policy/A1",
"permission": [{
   "@id": "http://example.com/rule/A1",
   "target": "http://example.com/document/1234",
   "assigner": "http://example.com/party/16",
   "action": "distribute",
   "constraint": [{
       "@id": "http://example.com/constraint/A1",
       "leftOperand": "dateTime",
       "operator": "lt",
       "rightOperand":  { "@value": "2018-01-01", "@type": "xsd:date" }
   }]
}]
}
            

Expected behaviour of the Evaluator

The ODRL Evaluator has to calculate first the activation state of the permission. The constraint must be evaluated on the state of the world, which must include a representation of the current time. As long as the current time is before the first day of 2018, the Permission is active. When the first day of 2018 is passed, the Permission is inactive. The action class regulated by the permission is distribute, the target is document:1234, and the assignee is not specified.

Explanation:

• (A1-1) If the action to be evaluated belongs to the class of actions regulated by the Permission and the Permission is active then the action is permitted by the permission.
• (A1-2) If the action to be evaluated belongs to the class of actions regulated by the Permission, but the Permission is inactive, then the action is permitted by the permission.

Evaluation of Refinements

Example description

The example below (which is similar to Example 14 in the ODRL Information Model 2.2) allows the target asset document:1234 to be printed and also include a refinement indicating that the resolution of the printing action must be less than or equal to 1200 dpi. The permission is granted by the organization party:616.

{
"@context": "http://www.w3.org/ns/odrl.jsonld",
"@type": "Set",
"uid": "http://example.com/policy/B1",
"permission": [{
    "@id": "http://example.com/rule/B1",
    "target": "http://example.com/document/1234",
    "assigner": "http://example.com/party/616",
    "action": [{
       	"rdf:value": { "@id": "odrl:print" },
        "refinement": [{
            "@id": "http://example.com/refinement/B1"
            "leftOperand": "resolution",
            "operator": "lteq",
            "rightOperand": { "@value": "1200", "@type": "xsd:integer" },
            "unit": "http://dbpedia.org/resource/Dots_per_inch"
        }]
    }]
}]
}     

Expected behaviour of the Evaluator
The class of actions regulated by the Permission is print, the target is document:1234, and the assignee is not specified.

Explanation: the Permission is always active because it has neither Constraints nor Conditions (Duties).

• (B1-1) If the requested or performed action belongs to the class of actions regulated by the Permission and the action satisfies the Refinement, then the action is permitted by the permission.
• (B1-2) If the requested or performed actions belongs to the class of actions regulated by the Permission but it does not satisfy the Refinement, then the action is NOT permitted by the permission.

Evaluation of Conditions (Duties)

When a Permission contains Conditions (duties), they have to be evaluated first.

A Condition (duty) is fulfilled if all its constraints are satisfied and if its action, with all refinements satisfied, has been performed.

1. The initial state of a Condition (duty) is inactive.
2. If at least one of the Constraints of the Condition (duty) is not satisfied, then the duty is inactive. (For example, the duty to pay a ticket to get an active permission to enter in a museum may be active only on Sundays and inactive the other days).
3. If the Constraints of the Condition (duty) are all satisfied or there are no Constraints, then the duty is active.
4. If the Condition (duty) is active and an action that belongs to the class of actions regulated by the Condition with all refinements satisfied is performed, then Condition (duty) is fulfilled.

The life cycle of a Condition (duty) is depicted in the figure below:

Once the Condition (duty) has been evaluated, the Permission can be evaluated.
If the Condition is active but it is not fullfilled then the Permission is inactive.
If the Condition is fulfilled then the Permission is active.

Example of a conditioned permission

Example description

The example below (similar to Example 22 in the ODRL Information Model 2.2) is a Permission that is constrained by a Condition (Duty). The Condition does not have Constraints, but its action has a refinement. This permission is granted by party:sony for party:billie to play the target asset music:1999. The permission includes the Condition to perform the compensate action that has a refinement of payAmount of euro 5.00. The semantics of Permission requires that the compensate action (included in the duty) must be performed before the play action in order to get an active permission to perform the play action.

        {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Agreement",
        "uid": "http://example.com/policy/22",
        "permission": [{
            "assigner": "http://example.com/party/sony",
            "assignee": "http://example.com/party/billie",
            "target": "http://example.com/music/1999.mp3",
            "action": "play",
            "duty": [{
               "@id" : "http://example.com/condition/1",
               "action": [{
                  "rdf:value": { "@id": "odrl:compensate" },
                  "refinement": [{
                     "@id" : "http://example.com/refinement/1",
                     "leftOperand": "payAmount",
                     "operator": "eq",
                     "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
                     "unit": "http://dbpedia.org/resource/Euro"
                  }]
                }]
            }]
        }]
        }  
        

Expected behaviour of the Evaluator

The class of actions regulated by this Permission has type equal to play, object equal to the target of the permission, i.e. music:1999.mp3, and performer equal to the assignee of the permission, i.e. party:billie.

The condition (duty) have to be evaluated first. condition:1 does not have Constraints, so it is never inactive. It starts to be active and it is fulfilled when in the state of the world there is a representation of a performed action that matches with the the class of actions described in the condition:1.

The class of actions regulated by condition:1 has type equal to compensate, its payAmount is equal to 5 euro, and (given that the odrl:compensatedParty of the odrl:compensate action is not specified) its beneficiary is the assigner of the permission party:sony. It is not required that the agent who performs the compensate action is party:billie because, for example, a company can pay for its employees (feature for an ODRL profile: it would be useful for actions of compensation or payment to contain a reference to a policy or a rule and to the party for whom they are performed).

Access control or monitorin scenario:

Given a formal description of the requested or performed action, if such an action belongs to the class of actions regulated by the Permission and the Permission is active, then the action is permitted, otherwise it is denied.

Example of a permission whose condition has constraints

Example description

This policy contains a Permission constrained by a Condition (duty) (like in policy:22) with the difference that such Condition has constraints, it is only activated on Sundays.

        {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Agreement",
        "uid": "http://example.com/policy/88",
        "permission": [{
            "assigner": "http://example.com/party/sony",
            "assignee": "http://example.com/party/billie",
            "target": "http://example.com/music/1999.mp3",
            "action": "play",
            "duty": [{
                "@id" : "http://example.com/condition/1",
                "action": [{
                    "@id" : "http://example.com/action/payment",
                    "rdf:value": { "@id": "odrl:compensate" },
                    "refinement": [{
                        "@id" : "http://example.com/refinement/1",
                        "leftOperand": "payAmount",
                        "operator": "eq",
                        "rightOperand": { "@value": "5.00", "@type": "xsd:decimal" },
                        "unit": "http://dbpedia.org/resource/Euro"
                    }]
                }],
                "constraint": [{
                    "@id" : "http://example.com/constraint/1",
                    "leftOperand": "ex:dayOfWeek",
                    "operator": "eq",
                    "rightOperand": { "@value": "Sunday", "@type": "xsd:string" }
                }]
            }]
        }]
        }  
        

Expected behaviour of the Evaluator

The class of actions regulated by this Permission has type equal to play, object equal to the target of the permission, i.e. music:1999.mp3, and performer equal to the assignee of the permission, i.e. party:billie.

The class of actions regulated by condition:1 has type equal to compensate, its payAmount is equal to 5 euro, and (given that the odrl:compensatedParty of the odrl:compensate action is not specified) its beneficiary is the assigner of the permission party:sony.

condition:1 has to be evaluated first. Given that condition:1 has constraints it starts to be inactive and it becomes active when its Constraints are all satisfied (the state of the world satisfies its Constraints, i.e. the current date is a Sunday. For expressing this constraint an external vocabulary with the leftOperand ex:dayOfWeek is used). An active Constraint, it is also fulfilled when in the state of the world there is a representation of an performed action that matches with the class of actions described in the Constraint.

The permission can be evaluated as follows:
If the Condition is inactive (its Constraint is not satisfied), the Permission is active.
If the Condition is active but it is not fullfilled, the Permission is inactive.
If the Condition is fulfilled the Permission is active.

Access control or monitoring scenario:

Semantics of Prohibitions

• not-set when the regulated action with all refinements satisfied has not been performed;
• violated when the regulated action with all refinements satisfied has been performed;

Evaluation of a prohibition with constraints

Example description

This is example is similar to Example 19 in the Information Model, with the differences that it has not a related permission and it has a Constraint. In this case, there is a prohibition that is constrained by a constraint. The policy below is a formal Agreement between two parties (the assigner and the assignee) that the action of archiving the specified digital asset is prohibited. The prohibition is specifically active before the first day of 2025.

        {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Agreement",
        "uid": "http://example.com/policy/55",
        "prohibition": [{
            "@id" : "http://example.com/prohibition/1",
            "target": "http://example.com/photoAlbum:55",
            "action": "archive",
            "assigner": "http://example.com/MyPix:55",
            "assignee": "http://example.com/assignee:55",
            "constraint": [{
               "@id" : "http://example.com/constraint/1",
               "leftOperand": "dateTime",
               "operator": "lt",
                "rightOperand":  { "@value": "2025-01-01", "@type": "xsd:date" }
           }]
        }]
        }
        

Expected behaviour of the Evaluator

The prohibition has an activation state and a deontic state that have to be calculated.

In this example, the Constraint must be evaluated on the state of the world. As long as the current time is before the first day of 2025 the Prohibition is active. After that date the Prohibition is inactive. When the prohibition is active, a violation occurs if the prohibited action is performed.

Sematics of Obligations

• fulfilled when the regulated action with all refinements satisfied is performed;
• violated when the regulated action with all refinements satisfied can no longer be performed;
• not-set when the regulated action with all refinements satisfied can be performed but has not been so far.

Evaluation of an obligation without constraints

Example description

This example of derived from Example 20 in the Information Model. It describes an obligation that is not constrained by a Constraint. The policy below is a formal Agreement between two parties (the assigner and the assignee) that the action to compensate the assigner for a payment amount of EU500.00 is obliged.

        {
        "@context": "http://www.w3.org/ns/odrl.jsonld",
        "@type": "Agreement",
        "uid": "http://example.com/policy/42",
        "obligation": [{
          "@id" : "http://example.com/obligation/1",
          "assigner": "http://example.com/party/43",
          "assignee": "http://example.com/party/44",
          "action": [{
              "rdf:value": {
                "@id": "odrl:compensate"
              },
              "refinement": [
                {
                  "leftOperand": "payAmount",
                  "operator": "eq",
                  "rightOperand": { "@value": "500.00", "@type": "xsd:decimal" },
                  "unit": "http://dbpedia.org/resource/Euro"
                }]
            }]
        }]
        }
        

Expected behaviour of the Evaluator

The Evaluator must determine the activation state and the deontic state of the obligation. The Obligation is always active. If the obliged action is performed then the obligation is fulfilled.

References