Framework for ODRL Rule Compliance through Evaluation (FORCE)

Living Document,

This version:
https://w3id.org/force
Previous Versions:
Issue Tracking:
GitHub
Editors:
(Ghent University - imec)
(Ghent University - imec)
License:
CC-BY-SA-4.0

Abstract

The Framework for ODRL Rule Compliance through Evaluation (FORCE) is designed to assist in ODRL policy development and enhance comprehension of ODRL evaluation outputs. Furthermore, it enables experimentation and prototyping of ODRL 3.0 proposals.

TODO: mention all publications that contributed to this work so far.

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:

Based on this work, FORCE provides

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:

Below is an overview of the ODRL Compliance Report Model.

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

ODRL Test Suite
TODO: write full text

4. ODRL Evaluator

ODRL Evaluator architecture
TODO: write full text

Mention different steps

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

5. User Interface

https://w3id.org/force/demo

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

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#> .

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

References

Normative References

[COMPLIANCE-REPORT]
Wout Slabbinck; Beatriz Esteves. ODRL Compliance Report Model. URL: https://w3id.org/force/compliance-report
[ODRL-FORMAL-SEMANTICS]
Nicoletta Fornara; et al. ODRL Formal Semantics. URL: https://w3c.github.io/odrl/formal-semantics/
[ODRL-Instantiation]
Ruben Dedecker; Beatriz Esteves. ODRL Policy Agreement Instantiation. URL: https://w3id.org/force/policy-instantiation
[ODRL-model]
Renato Iannella; Serena Villata. ODRL Information Model 2.2. URL: https://w3c.github.io/poe/model/
[ODRL-PROFILE-BP]
Michael Steidl. ODRL V2.2 Profile Best Practices. URL: https://w3c.github.io/odrl/profile-bp/
[ODRL-VOCAB]
Renato Iannella; et al. ODRL Vocabulary & Expression 2.2. URL: https://w3c.github.io/poe/vocab/
[ODRL3.0PROPOSAL]
Beatriz Esteves; et al. Open Digital Rights Language (ODRL) 3.0 Proposal. URL: https://w3id.org/force/odrl3proposal
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SotW4ODRL]
Beatriz Esteves; Wout Slabbinck. State of the World for ODRL Evaluator. URL: https://w3id.org/force/sotw