Framework for ODRL Rule Compliance through Evaluation (FORCE)

Note: Key publications that contributed to this work: Slabbinck et al., 2025, 'Interoperable Interpretation and Evaluation of ODRL Policies'.

1. Introd­uction

The Open Digital Rights Language (ODRL) is a W3C Recommendation that provides a standardized, machine-readable way to express permissions, prohibitions, and obligations over content and services. In addition, these permissive, prohibitive and obligatory rules can be limited by constraints, such as temporal or spatial restrictions, and duties, such as making a payment or a deleting an asset after using it, may be imposed on permissions. This standard is composed of two W3C Recommendation: an information model [ODRL-model] and a vocabulary [odrl-vocab].

The ODRL Information Model specifies a semantic model for permission, prohibition, and obligation statements. This information model covers core concepts, such as assets, i.e., the resource or service over which the rule applies, parties, i.e., the senders or recipients of rules, and actions, i.e., the actual operations that are being permitted, denied or made mandatory. As such, ODRL supports the expression of statements like "Party X may use Asset Y under condition Z and must do action W".

Furthermore, the ODRL Vocabulary provides a well-defined RDF vocabulary that describes the terms used in ODRL policies. For instance, odrl:use and odrl:distribute are defined as ODRL actions, and odrl:spatial and odrl:purpose as ODRL left operands, used to model constraints. There is also the possibility to extend this vocabulary through the usage of profiles [odrl-profile-bp], which allow the definition of additional terms, e.g., custom actions or left operands, for particular domains, e.g., healthcare or education.

As an example, the following ODRL policy specifies a patient’s permission for its health data to be read by a physician for primary care:

<https://example.com/health-primarycare> a odrl:Set ;
    odrl:uid <https://example.com/health-primarycare> ;
    dcterms:description "Patient allows its health data to be read by a physician for primary care."@en ;
    odrl:permission [
        odrl:action odrl:read ;
        odrl:target <https://example.com/patient/health-data> ;
        odrl:assigner <https://example.com/patient> ;
        odrl:assignee <https://example.com/physician> ;
        odrl:constraint [
            odrl:leftOperand odrl:purpose ;
            odrl:operator odrl:eq ;
            odrl:rightOperand sector-health:PrimaryCareManagement ] ] .

Furthermore, as previously discussed, the ODRL recommendations define how to represent policies using the information model and the vocabulary, however the expected behavior of software that performs computations based on these policies is not standardized. Hence, this might lead to differences in the interpretation and evaluation of these policies and its accompanying rules. To tackle this issue, the ODRL CG is currently developing a formal semantics for ODRL 2.2 [odrl-formal-semantics]. This specification defines the expected behavior of an piece of software, i.e., an ODRL Evaluator, that takes an input an ODRL policy, an evaluation request and a description of the state of the world, and outputs a compliance report which contains, e.g., information regarding active or inactive permissions or about the deontic state of prohibitions and obligations.

Inspired by the work of the ODRL CG on this Formal Semantics specification, Slabbinck et al. described in 'Interoperable Interpretation and Evaluation of ODRL Policies' the development of the following contributions:

• an ODRL Compliance Report Model,

• an ODRL Test Suite, and

• and ODRL Evaluator.

Based on this work, FORCE provides

• a guide on the several specifications, e.g., the ODRL Compliance Report Model or the ODRL 3.0 proposal, and pieces of software, e.g., the ODRL Test Suite or the ODRL Evaluator, we are building to work with the current ODRL standard and to test new features for a possible future version of the standard, and

• a Web application that acts as a playground to test these specifications and software libraries.

1.1. Terminology

The following terms are used to describe concepts in this specification.

ODRL Compliance Report Model

A vocabulary that is used to elaborate the result of an evaluation of an ODRL Policy, (optionally) ODRL Request and the State of the World. It elaborates not only whether a rule from a policy is active, but also why.

ODRL Evaluator

A system that determines whether the Rules of an ODRL Policy expression have meet their intended action performance.

ODRL Test Suite

Software that can execute, validate and measure the compliance of an ODRL evaluator over a set of test cases.

State of the World

Knowledge representing real-world information aiding the evaluation of ODRL Policies.

2. ODRL Compliance Report Model

The ODRL Compliance Report Model [compliance-report] defines a model and a vocabulary that can be used to compute the output of an evaluation of a ODRL Policy, a ODRL Request, and the state of the world. It elaborates not only whether a rule from a policy is active, but also why, by taking into consideration the ODRL Formal Semantics specification [odrl-formal-semantics].

To compute the compliance report, the following parameters are considered:

• Satisfaction state: whether a certain premise is satisfied or not, e.g., the requested asset matches the target of the policy rule.

• Activation state: a rule is active if, and only if, all premises of a rule are satisfied.

• Attempted state: if the assignee made a request to perform a certain action over a certain target asset, then the rule was attempted.

• Performance state: whether the action of the rule was performed, unperformed, or it has an unknown state, i.e., there is no information to know if it was already performed or not, but it still can be.

• Deontic state: whether a given action that is allowed is already executed, should have been executed and it was not, or there is not enough information to make the decision.

Below is an overview of the ODRL Compliance Report Model.

As an example, if there is a policy that states that ALICE may READ resource X before 2024-02-12T11:20:10.999Z:

<urn:uuid:32127a3f-5296-4cc6-b9d6-ef6c647a721d> a odrl:Set ;
  odrl:uid <urn:uuid:32127a3f-5296-4cc6-b9d6-ef6c647a721d> ;
  dcterms:description "ALICE may READ resource X before 2024-02-12T11:20:10.999Z." ;
  dcterms:source <https://github.com/SolidLabResearch/ODRL-Test-Suite/> ;
  odrl:permission <urn:uuid:d6ab4a38-68fb-418e-8af5-e77649a2187a> .

<urn:uuid:d6ab4a38-68fb-418e-8af5-e77649a2187a> a odrl:Permission ;
  odrl:assignee ex:alice ;
  odrl:action odrl:read ;
  odrl:target ex:x ;
  odrl:constraint <urn:uuid:constraint:86526f9b-57c2-4c94-b079-9762fec562f1> .

<urn:uuid:constraint:86526f9b-57c2-4c94-b079-9762fec562f1> odrl:leftOperand odrl:dateTime ;
  odrl:operator odrl:lt ;
  odrl:rightOperand "2024-02-12T11:20:10.999Z"^^xsd:dateTime .

and ALICE requests to READ resource X:

<urn:uuid:1bafee59-006c-46a3-810c-5d176b4be364> a odrl:Request ;
  odrl:uid <urn:uuid:1bafee59-006c-46a3-810c-5d176b4be364> ;
  dcterms:description "Requesting Party ALICE requests to READ resource X." ;
  odrl:permission <urn:uuid:186be541-5857-4ce3-9f03-1a274f16bf59> .

<urn:uuid:186be541-5857-4ce3-9f03-1a274f16bf59> a odrl:Permission ;
  odrl:assignee ex:alice ;
  odrl:action odrl:read ;
  odrl:target ex:x .

at the current time that is recorded in the state of the world as:

@prefix temp: <http://example.com/request/> .

<urn:uuid:192620fa-06d9-447b-adbd-bd1ece4f9b12> a ex:Sotw ;
  ex:includes temp:currentTime .

temp:currentTime dcterms:issued "2017-02-12T11:20:10.999Z"^^xsd:dateTime .

then ALICE is ALLOWED to READ resource X because the target resource, action, party, and temporal constraint (current time is before 2024-02-12T11:20:10.999Z) premises are satisfied and as such the permission in the policy is active:

<urn:uuid:352c5b8a-3249-4a6a-add7-bc3ab1cc41e3> a report:PolicyReport ;
  dcterms:created "2017-02-12T11:20:10.999Z"^^xsd:dateTime ;
  report:policy <urn:uuid:32127a3f-5296-4cc6-b9d6-ef6c647a721d> ;
  report:policyRequest <urn:uuid:1bafee59-006c-46a3-810c-5d176b4be364> ;
  report:ruleReport <urn:uuid:485a907c-c90b-4b8e-8df6-161829751c99> .

<urn:uuid:485a907c-c90b-4b8e-8df6-161829751c99> a report:PermissionReport ;
  report:attemptState report:Attempted ;
  report:rule <urn:uuid:d6ab4a38-68fb-418e-8af5-e77649a2187a> ;
  report:ruleRequest <urn:uuid:186be541-5857-4ce3-9f03-1a274f16bf59> ;
  report:premiseReport <urn:uuid:42391701-9c0b-43de-92f7-5e8d9ee8b425>,
    <urn:uuid:17d7a919-77a8-447a-9a9f-714795af9663>,
    <urn:uuid:980cd0b6-7839-4428-937d-f110c3bed77c>,
    <urn:uuid:5662701d-37da-41e4-9b7c-cf464d88a6dc> ;
  report:activationState report:Active .

<urn:uuid:17d7a919-77a8-447a-9a9f-714795af9663> a report:TargetReport ;
  report:satisfactionState report:Satisfied .

<urn:uuid:980cd0b6-7839-4428-937d-f110c3bed77c> a report:PartyReport ;
  report:satisfactionState report:Satisfied .

<urn:uuid:5662701d-37da-41e4-9b7c-cf464d88a6dc> a report:ActionReport ;
  report:satisfactionState report:Satisfied .

<urn:uuid:42391701-9c0b-43de-92f7-5e8d9ee8b425> a report:ConstraintReport ;
  report:constraint <urn:uuid:constraint:86526f9b-57c2-4c94-b079-9762fec562f1> ;
  report:constraintLeftOperand "2017-02-12T11:20:10.999Z"^^xsd:dateTime ;
  report:constraintOperator odrl:lt ;
  report:constraintRightOperand "2024-02-12T11:20:10.999Z"^^xsd:dateTime ;
  report:satisfactionState report:Satisfied .

3. ODRL Test Suite

The ODRL Test Suite [odrl-test-suite] ensures that different ODRL Evaluators can compared against eachother regarding functionality. If they pass the test cases in the same manner, they can then be used interchangable.

The flow of the ODRL Test Suite is the following: For each test case, evaluate the policy using the specificed state of the world and request. Then compare the evaluated policy report against the test case policy report.

The comparison is executed using following metrics:

• Both policy reports must have the same amount of rule reports,

• Each rule report must point to the designated requested permission and policy rule.

• The rule reports must have the same state (Activation, Attempted, Performance and Deontic)

• All premises must have the same satisfaction state.

3.1. Contributing

Contributing to the test suite can be done by following the guide in the wiki. It describes how a test case has to be designed, what are the pitfalls and provides some tooling on how to create test-cases for the ODRL Test Suite.

4. ODRL Evaluator

The ODRL Evaluator [odrl-evaluator] is an open-source software component that evaluates ODRL policies that result in Compliance Reports.

The current architecture consists of two main components: the validation component and the evaluation component. The validation component performs a series of sanity checks to ensure that only valid input is passed to the evaluation component for policy evaluation.

The ODRL Evaluator is fully stateless. If state is required for policy evaluation, then it MUST be present in the State of the World One example of such a required fact is the current time, which MUST always be included. This is achieved by presenting at least following triple: temp:currentTime dcterms:issued "2017-02-12T11:20:10.999Z"^^xsd:dateTime . Further details are elaborated in the Compliance Report section.

5. User Interface

The core features of the demonstrator are the following:

• An intuitive user interface such that users can edit ODRL Policies, requests and the State of the World, which can then be immediately evaluated by an ODRL Evaluator.

• A comprehensive, human-readable explanation of the resulting output, aiding the understanding of the ODRL Compliance Report Model.

• A selection of scenarios (ODRL Policies, requests and SotWs) to facilitate exploring ODRL Policies and evaluations.

There are two variants of the FORCE demonstrator:

• FORCE demonstrator (default): https://w3id.org/force/demo

• FORCE demonstrator (with ODRL 3.0 proposals): https://w3id.org/force/demo/odrl3proposal

6. State of the World for ODRL Evaluator

See the State of the World for ODRL Evaluator specification [SotW4ODRL] for further details.

7. ODRL 3.0

The ODRL 3.0 specification tries to address several limitations with the following structure:

1. Use Cases: A collection of use cases which require a major change to the ODRL Model in order for them to be resolved

2. Requirements: The common requirements extracted from the use cases that needs to be resolved such that the use cases can be implemented

3. ODRL 3.0 Proposals: An example of how the requirements can be met through changes to the ODRL 2.2 Information Model [ODRL-model] and hints on how it could be implement.

8. Supporting Materials

• ODRL Compliance Report Model ([compliance-report]): https://w3id.org/force/compliance-report

  • github repository: https://w3id.org/force/compliance-report/repo

• ODRL Test Suite ([odrl-test-suite]): https://w3id.org/force/test-suite

  • github repository: https://w3id.org/force/test-suite/repo

• github repository for an ODRL Evaluator ([odrl-evaluator]): https://w3id.org/force/evaluator

• Key publications that contributed to this work:

  • Slabbinck et al., 2025, 'Interoperable Interpretation and Evaluation of ODRL Policies'.

• State of the World for ODRL specification ([SotW4ODRL]): https://w3id.org/force/sotw

• ODRL Policy Instantiation specification ([ODRL-Instantiation]): https://w3id.org/force/policy-instantiation

• ODRL 3.0 Proposal specification ([ODRL3.0PROPOSAL]): https://w3id.org/force/odrl3proposal

• Web demonstrator: https://w3id.org/force/demo

  • source code: https://w3id.org/force/demo/repo

9. Namespaces

Commonly used namespace prefixes used in this specification:

@prefix dcterms:       <http://purl.org/dc/terms/> .
@prefix ex:            <http://example.org/> .
@prefix odrl:          <http://www.w3.org/ns/odrl/2/> .
@prefix odrl3proposal: <https://w3id.org/force/odrl3proposal#> .
@prefix report:        <https://w3id.org/force/compliance-report#> .
@prefix rdf:           <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sector-health: <https://w3id.org/dpv/sector/health#> .
@prefix skos:          <http://www.w3.org/2004/02/skos/core#> .
@prefix xsd:           <http://www.w3.org/2001/XMLSchema#> .