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

• TODO: what makes a test pass or fail in plain terms.

4. ODRL Evaluator

Mention different steps

Elaborate the need for the time thingy Refer to repo how much we support

5. User Interface

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

[ODRL3.0PROPOSAL]

8. Supporting Materials

• ODRL Compliance Report: https://w3id.org/force/compliance-report

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

• test suite: https://w3id.org/force/test-suite

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

• github repository for an ODRL Evaluator: https://w3id.org/force/evaluator

• ESWC 2025 paper: TODO:

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

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

• ODRL 3.0 Proposal specification: https://w3id.org/odrl3proposal

• demonstrator: https://w3id.org/force/ESWC2025-demo

  • source code: https://w3id.org/force/ESWC2025-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#> .