The Open Digital Rights Language (ODRL 2.2), being a W3C Recommendation since 2018, is a popular candidate for a policy language applied in data spaces. However, ODRL does not yet have a formal semantics. In this paper, we address this issue by making the first steps towards a formal, declarative semantics for ODRL. We start by covering a subset of the language that includes only ODRL's main features (permissions, prohibitions, obligations, duties, refinements and constraints). This exercise naturally reveals "gray areas" in ODRL's informal semantics, as well as lack of expressiveness; both will be pointed out during the formalization.
The realization of open and distributed ecosystems in which organizations, individuals, and digital companions can exchange data or resources is becoming increasingly important, as shown by the studies of various W3C Community Groups and data space initiatives supported by the European Commission1. Prerequisites for the realization of such systems are: (i) the sovereignty of participants over their resources, i.e., the ability to define rules for accessing and using these resources; (ii) the possibility of having interactions based on agreements and policies; (iii) the ability to verify the compliance of interactions with respect to the agreements and policies stipulated and also with respect to legislation. Central to building such systems is a language for specifying policies that can express, at least, permissions, prohibitions, and obligations for the various actions that can be performed on digital resources.
The Open Digital Rights Language (ODRL) is a policy language that can be applied to a broad variety
of scenarios. Originally designed for Digital Rights Management (DRM) applications, ODRL is now
being used to express manifold contracts and policies, such as data licensing [
However, ODRL 2.2 [
The W3C ODRL Community Group is aware of the lack of a formal semantics for ODRL and has
published a draft report on ODRL semantics [
In this paper, we propose a declarative semantics for ODRL 2.2. We start by covering a subset of the language that includes only ODRL’s main features (permissions, prohibitions, obligations, duties, refinements and constraints). This exercise naturally reveals "gray areas" in ODRL’s informal semantics, as well as lack of expressiveness; both will be pointed out during the formalization. We are going to formalize ODRL’s semantics in a declarative, model-theoretic style, because such an approach is implementation-independent and – more importantly – independent from the computational tasks (that is, policy use), while procedural approaches are intrinsically tied to specific tasks. Declarative semantics can be used as a universal reference point to prove that all procedural solutions to any of the computational tasks conform to the same meaning of the policy. Thus, declarative semantics is the key to achieving the coherent behavior across all the diferent policy-related computational tasks that we are advocating. We are going to illustrate and justify our declarative semantics by means of standard examples that can be found in ODRL’s specification documents.
The paper is structured as follows. Section 2 presents some examples of ODRL policies. Section 3 defines a formal declarative semantics for ODRL’s main constructs, and points out several issues afecting the informal semantics. Section 4 illustrates the declarative semantics by formalizing the examples of Section 2. Section 5 illustrates how the declarative semantics provides correctness criteria for the implementation of policy-related computational tasks. Section 6 is devoted to conclusions.
In this section we illustrate several examples of ODRL policies. Let us start with the involved parties. Consider two people, Alice and Bob, and the organization ACME. Their URIs are /party#Alice, /party#Bob, and /party#ACME, respectively.
Now moving on to the digital resources, called assets in ODRL terminology.. ACME runs a web server at http://acme.example.org/. The web server hosts a document /doc.html and a music library at /music/. The music library contains individual songs, e.g., /music/1999.mp3. In addition, there is a photo album at /photoAlbum.
Finally, we represent the actions that parties can perform on assets. The actions we consider are listed in order of appearance and with the comments from the ODRL vocabulary2: • odrl:print, i.e., “To create a tangible and permanent rendition of an Asset.” • odrl:play, i.e., “To create a sequential and transient rendition of an Asset.” • odrl:compensate, i.e., “To compensate by transfer of some amount of value, if defined, for using or selling the Asset.” • odrl:archive, i.e., “To store the Asset (in a non-transient form).”
All of these actions are special cases of odrl:use, i.e., “actions that involve general usage by parties”. None of them is odrl:transfer, i.e., “actions that involve in the transfer of ownership to third parties”.
Suppose that ACME allows everyone to print /doc.html in 300 dpi, but only before the year 2018. In
ODRL terms, the policy specifies a permission rule for the class of printing actions, where the action
is refined with the constraint stating that the resolution should be less than or equal to 300 dpi. The
permission is further constrained, that is, the permission is only granted for actions exercised before
2018-01-01. Figure 1 shows the policy /policy/13-14#p (similar to Examples 13 and 14 in [
Action 1: Alice prints /doc.html with 300 dpi on 2017-12-31T14:35:27+01:00.
Next, consider a policy in which ACME allows Bob to play the target asset /music/1999.mp3, but
only in combination with a compensation of EUR 5.00. In ODRL terminology, the policy contains
a permission rule for the play action class with a duty of the compensate action class refined by a
constraint. Figure 2 shows the policy /policy/22#p (similar to Example 22 in [
The combination of the following two actions should comply with the policy: Action 2: Bob compensates EUR 5.00 at datetime 2024-12-31T14:33:42+01:00.
Action 3: Bob plays the song /music/1999.mp3 at datetime 2024-12-31T14:35:27+01:00.
Finally consider a policy in which ACME prohibits Bob from archiving the target asset /photoAlbum
before the year 2024. In ODRL terms, the policy consists of a prohibition rule with a constraint that the
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
</policy/22#p> a odrl:Policy ;
odrl:permission [
a odrl:Rule , odrl:Permission ;
odrl:assigner </party#ACME> ;
odrl:assignee </party#Bob> ;
odrl:target </music/1999.mp3> ;
odrl:action odrl:play ;
odrl:duty [
a odrl:Duty ;
odrl:action [
a odrl:Action ;
rdf:value odrl:compensate ;
odrl:refinement [
a odrl:Constraint ;
odrl:leftOperand odrl:payAmount ;
odrl:operator odrl:eq ;
odrl:rightOperand 5.00 ;
odrl:unit "Euro"
datetime has to be equal to the year 2024. See Figure 3 for the policy /policy/19#p (similar to the
example in Section 5.1 [
Accordingly, the following action does not comply with the policy:
Action 4: Bob archives /photoAlbum on 2023-06-18.
In order to propose the following formalization of the semantics of ODRL 2.2 we considered the
specification written in Natual Language available in the ODRL Information Model 2.2 [
We assume domains Δ1, . . . , Δ, each of which contains real-world entities of a particular class or data type used in the ODRL policy (like assets, parties, numbers, dates, etc.). Note that may be larger than the number of classes and data types mentioned in ODRL’s information model and core vocabulary, because an ODRL profile may add further entity types to the core ones. In the following, the domains of assets, actions, and parties will be denoted by Δas, Δac, and Δpa, respectively.
Note that both assets and parties may be either collections (i.e. sets) or individual objects. In order to simplify technical definitions in the rest of the paper, we introduce a function " set " that transforms all assets and parties into sets, for uniformity. Formally, set() = ︂{ {} if is a set otherwise.
For each domain Δ ̸= Δac, there exists a corresponding set of identifiers I that represent the elements of Δ according to the serialization(s) prescribed by ODRL’s (profile) specification. For example, if Δ is the set of all integers, then I is the set of expressions that represent integers, such as {"@value": "1200", "@type": "xsd:integer"}. Two or more expressions may denote the same element, like "2002-05-30T09:30:10Z" and "2002-05-30T08:30:10-01:00", which represent the same date and time using diferent time zones. We assume that the sets I are mutually disjoint. Moreover, let
I = ⋃︁ I and Δ = ⋃︁ Δ .
=1 =1
: I → Δ , The meaning of identifiers is specified by a
denotation function such that for each ∈ [1, ], and for all ∈ I, () ∈ Δ . For example, if
= ”http://acme.example.org/music/1999.mp3”, then () denotes the actual (physical) mp3 file located at .
The domain Δac of action instances is structured in a slightly diferent way. The action terms ("use", "transfer", "play", etc.) denote classes of action instances, that is, for each action term , () ⊆ Δac , and whenever ODRL’s core ontology or a profile ontology contain the expression odrl:includedIn , then () ⊆ (). For example (”odrl : print”) ⊆ (”odrl : use”).
Furthermore, two meta-functions party and obj associate each action instance ∈ Δac with the set of actors that exercise it, and the set of assets involved. Formally, for all ∈ Δac, party() ⊆ Δpa and obj() ⊆ 3.2. Constraint Operators eq gt gteq lt lteq neq ⋃︀ ︀( > )︀
=1 (op) = ⋃︀ ︀(
=1 ⋃︀ ︀(
=1 ⋃︀ ︀( ̸ = ≥ < )︀ ︀) ︀) =1 ≤ op isA hasPart isPartOf isAllOf isAnyOf isNoneOf (op) ∈ ∋ ∈ = ∈ / ∈ deliveryChannel industryContext paymentAmount assetPercentage purpose recipient resolution size version sets thereof. Let us denote with ≤ the ordering associated with Δ (if Δ is not ordered, then ≤ is < are derived from ≤ in the usual way. By analogy with identifiers, we denote the meaning of an >, ≥ , and For example, (eq) is the set of all pairs (, ) ∈ Δ × Δ such that = ; (gt) is the set of all pairs (, ) ∈ Δ × Δ such that, for some ∈ [1, ], > ; (isA) is the set of all pairs (, ) ∈ Δ × Δ such its meaning will be available.
□
The meaning of the logical operators or, xone, and is defined similarly, using the standard truth tables of boolean connectives. For example, (or) is the set of pairs {(, ), (, ), ( , )}. Remark 1. ODRL supports also a logical operator andSequence, which prescribes the evaluation of its arguments from left to right. Given that logical and is symmetric and that ODRL’s core constraints have no side efects, it is hard to find any diferences between and and andSequence. Currently there are no examples on the intended use of the latter, so its formalization is deferred until a clearer specification of ODRL’s constraints and refinements contain a left operand that expresses the properties of assets, parties, actions, and other ODRL entities, and possibly the properties of the environment. Table 2 lists some of the core left operands and their type; most of them specify properties of actions and assets.
Property values may change. A state associates properties with their values at a particular point in time and lists the events that occur at that time. Thus, states can be thought of as snapshots of the world. ODRL also supports left operands that depend on a history of states, such as "count"; these operands, which we call temporal left operands, will be discussed in a future paper.
Formally, let LOn = {ℓ1, . . . , ℓ} be the set of nontemporal left operands, let Δev be the domain of events (we assume that actions are events, that is, Δac ⊆ Δev), and let Δdt be the domain of date-and-time points. A state is a triple
= ⟨, , (· ) ⟩ where ∈ Δdt represents the current time, ⊆ Δev is the set of events that occur at that time, and (· ) is an interpretation function that maps each nontemporal left operand ℓ ∈ LOn on a function ℓ of the appropriate type (cf. Table 2). Thus, the function (· ) specifies the values of all nontemporal properties at time .
Constraints (and refinements) are expressions like " leftOperand:ℓ operator: rightOperand:", that we will abbreviate to ⟨ℓ, , ⟩. Here we focus on nontemporal constraints, that is, ℓ ∈ LOn.
We say that a domain element ∈ Δ satisfies a constraint ⟨ℓ, , ⟩ in a state – in symbols, , |= ⟨ℓ, , ⟩ – if
(ℓ (), ()) ∈ () .
Here ℓ () is the value of ’s property ℓ in , () is the value denoted by the right operand, and () is the meaning of .
Based on the above definition, the meaning of the logical constraints based on operators or, xone, and is defined in the obvious way.
• a type (such as "permission", "prohibition", "duty"); • an action class (such as "use", "transfer", "play", . . . ); • an optional "target" asset (for "object"), which is mandatory for permissions and prohibitions; • an optional "assignee" party (for "party"); • other optional properties such as "assigner", "duty", "remedy", and "consequence".
Before delving into the definition of compliance, we need to introduce the notion of rule activation: Definition 1. A rule is active on some action ∈ in some state if one of the following conditions holds: • has no constraints (then is trivially active); • if has a set of constraints ⟨ℓ, , , ⟩ ( = 1, . . . , ), then is active on if for all = 1, . . . , , , |= ⟨ℓ, , , ⟩, where = if ℓ, is an action property, and = () if ℓ, is an asset property.
In the rest of this subsection, we assume that the rule has no duties nor remedies. Duties and remedies will be dealt with in the following subsections.
Definition 2. (Compliance with permissions) We say that complies with a permission (in a state ) if all the following conditions hold: 1. is active on in ; 2. ∈ ( ) (the action belongs to the permitted class); 3. if ’s action specification contains refinements ⟨ℓ, , , ⟩ ( ∈ [1, ]), then for all such , , |= ⟨ℓ, , , ⟩ (the action satisfies the refinements); 4. if the target is a collection, then obj() ⊆ (); otherwise obj() = { ()} (all the assets involved in are covered by the target of ); 5. if the target has refinements ⟨ℓ, , , ⟩ ( ∈ [1, ]), then for all such , and for all ∈ obj(), , |= ⟨ℓ, , , ⟩ (all the assets involved in satisfy the refinements); 6. if an assignee (for "peer") is specified in the permission, then party() ⊆ set( ()) (the actors who exercise the action are among the authorized assignees); 7. if the assignee has refinements ⟨ℓ, , , ⟩ ( ∈ [1, ]), then for all such and for all ∈ party(), , |= ⟨ℓ, , , ⟩ (all the actors that exercise satisfy the refinements).
Definition 3. (Compliance with prohibitions) If is a prohibition, we say that complies with (in ) if at least one of the following conditions holds: 1. is not active on in ; 2. ∈/ ( ) (the action does not belong to the specified class); 3. ’s action specification contains a refinement ⟨ℓ, , ⟩ such that , ̸|= ⟨ℓ, , , ⟩ (the action does not satisfy some refinement); 4. for all ∈ obj(), either ∈/ set( ()), or there exists a target refinement ⟨ℓ, , ⟩ such that , ̸|= ⟨ℓ, , , ⟩ (none of the assets involved in the action is covered by ’s target specification); 5. specifies an assignee , and for all ∈ party(), either ∈/ set( ()), or there exists a target refinement ⟨ℓ, , ⟩ such that , ̸|= ⟨ℓ, , , ⟩ (none of the parties that exercise the action satisfy ’s assignee specification).
In other words, an action is prohibited by if matches ’s action specification, some of the assets involved in the action matches ’s asset specification, and some of the parties that exercise the action match ’s assignee specification.
A duty is a rule with an action class , an optional asset , an optional assignee , and an optional list of constraints 1, . . . , .
Definition 4. (Compliance with a duty) A state complies with (or, equivalently, fulfills ) a duty with the above structure if there exists an action ∈ , called fulfilling action for , such that all of the following conditions hold: 1. is active on in (the constraints of are satisfied); 2. ∈ ( ) (the action has the required type); 3. if ’s action specification contains refinements ⟨ℓ, , , ⟩ ( ∈ [1, ]), then for all such , , |= ⟨ℓ, , , ⟩ (the action satisfies the refinements); 4. if a target is specified in , then obj() equals the set of all assets ∈ Δas such that (i) ∈ set( ()) and (ii) if the target has refinements ⟨ℓ, , , ⟩ ( ∈ [1, ]), then for all such , , |= ⟨ℓ, , , ⟩ (the assets involved in are exactly those specified in with "target" and its refinements); 5. if an assignee is specified in , then party() equals the set of all parties ∈ Δpa such that (i) ∈ set( ()) and (ii) if the target has refinements ⟨ℓ, , , ⟩ ( ∈ [1, ]), then for all such , , |= ⟨ℓ, , , ⟩ (the parties that exercise are exactly those specified in with "assignee" and its refinements).
Remark 2. Diferent semantics for fulfillment are possible. In the above version, the action must be exercised jointly by all the specified assignees (as in: the contract shall be approved by all assignees). Alternatively, one might require that the action be exercised by any of the specified assignees (as in: the payment shall be made by any of the assignees), or that each assignee should independently fulfil the duty (e.g. all assignees shall register). Each of these three semantics is useful in diferent use cases. Unfortunately, ODRL does not specify which of the above semantics is the intended one, and it is not expressive enough to select the desired semantics, based on the use case. □
The duties of permission rules are obligations that must be fulfilled as a prerequisite before the permission is exercised. Thus, some notion of time shall be introduced in the semantics. Definition 5. A trace is a sequence of states = ⟨1, 2, . . . , ⟩ such that < +1 ( = 1, . . . , ), that is, timestamps are increasing.
Definition 6. (Compliance with a permission with duties) Given a trace = ⟨1, 2, . . . , ⟩, a state ( ∈ [1, ]) and and action ∈ , we say that complies (in and ) with a permission with duties 1, . . . , if the following two conditions hold: 1. complies with in as specified in the previous section for duty-less permissions; 2. for each duty ( ∈ [1, ]) there exists ∈ [1, ] such that fulfills .
Remark 3. Diferent notions of compliance with permissions with duties are possible. In the above version, a single duty fulfillment executed in one state sufices to permit any number of actions 1, . . . , exercised in states +1, +2, . . . , . This can be useful to say, for example, that after registering to a web site (once and for all), a user may access all the contents of the web site. In other use cases, one may need to say that each action execution requires a diferent fulfillment of the duty; this would be useful to specify pay-per-view policies. ODRL is not expressive enough to distinguish these two meanings – nor does it specify which of the two semantics should be adopted. □ Remark 4. The ODRL Information Model specification states that a duty is "an agreed Action that MUST be exercised (as a pre-condition to be granted the Permission)" and that "the duty property asserts a pre-condition between the Permission and the Duty". Accordingly, fulfillment has been formalized in Def. 6 by requiring that the duty is fulfilled before exercising the permitted action (cf. the condition ∈ [1, ]). However, this notion of fulfillment cannot model duties that occur in the future, as in the norm: "personal data can be collected but it must be deleted within one month". A possible alternative interpretation of the specification is that the assignee(s) must agree to fulfill the duty before exercising the permission (the duty may be fulfilled later); however, such agreement is not formalized in the specification, therefore also this alternative interpretation needs clarifications. □ Remark 5. Sections 2.6.3 and 2.6.4 of ODRL’s Information Model state that "A duty [an obligation, respectively] is fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised". The above definitions formalize this statement. There exists, however, another way of intending the role of constraints in duties; it could be stipulated that the duty is active – and its action shall be exercised – only if the constraints are satisfied (otherwise, the duty can essentially be ignored). Some of the examples in the ODRL Information Model are apparently using the latter meaning rather than the specified semantics (cf. Example 22). □
Prohibitions may have "remedies", which are duties that – if fulfilled after the prohibition has been infringed – restore the prohibition state to "not infringed". In formal terms: Definition 7. Given a trace = ⟨1, 2, . . . , ⟩, a state ( ∈ [1, ]) and and action ∈ , we say that complies (in and ) with a prohibition with remedies 1, . . . , if at least one of the following conditions hold: 1. complies with in as specified in the previous sections for remedy-less prohibitions; 2. for each remedy ( ∈ [1, ]) there exists ∈ [, ] such that fulfills .
Note that if the prohibition is infringed at and the remedies occurs later at some with ∈ [+1, ], then does not comply with in all the traces ⟨1, . . . , ⟩ with ∈ [, − 1], while does comply with in all the traces ⟨1, . . . , ⟩ such that ∈ [, ]. In this way the formal semantics models the scenarios where the prohibition is infringed for some time, until the remedy is fulfilled. Remark 6. In the full specification, a duty that occurs in an obligation or permission rule may have "consequences", that is, further duties that restore compliance if has not been fulfilled. The semantics of consequences can be modelled by analogy with the semantics of remedies. The definition is easy and left to the reader. □
An ODRL policy Π may contain one or more rules (permissions, prohibitions, and duties, possibly of diferent types) plus several properties for specifying namespaces and profiles, and a property "conflict" with possible values "perm" (permissions have precedence), "prohibit" (prohibitions have precedence), "invalid" (conflicts generate an error); the latter is the default value. 3 Remark 7. ODRL cannot express gap resolution strategies, where "gap" means that an action is neither permitted nor prohibited. There are at least two standard approaches to resolving policy gaps in data security: the open and the closed default policies, that permit and deny the action, respectively. In the absence of references to gap resolution in ODRL’s specification, here we will (temporarily) adopt the most conservative approach, namely, the closed default policy. The reader may easily verify that prohibitions still make sense when they partially overlap permissions, unless the conflict resolution strategy is "perm"; in that case, prohibitions are irrelevant and useless. We recommend to extend ODRL with a policy property that specifies the gap resolution strategy; it might be called "default", with values "permit", "prohibit" and "invalid". □ Definition 8. Consider a policy Π with permissions 1, . . . , , prohibitions 1, . . . , , obligations 1, . . . , , and conflict value (for "strategy"). For all traces = ⟨1, 2, . . . , ⟩, we say that: complies with Π if all of the following conditions hold: 1. for all obligations ( ∈ [1, ]) there exists a state in ( ∈ [1, ]) such that fulfills (i.e.
all obligations are fulfilled); in the following conditions, let denote a fulfilling action for ; 2. for all states in ( ∈ [1, ]) and all actions ∈ , at least one of the following two conditions holds: a) is either a fulfilling action for an obligation of Π, or a fulfilling action for the duty of some permission that is active on some action ′ ∈ ( ≤ ≤ ); b) there exists a permission such that complies (in and ) with , and either ="perm" or complies (in and ) with all the prohibitions 1, . . . , .
In other words, a trace complies with Π if all the obligations are fulfilled, and all actions are either required or permitted.4 Point 2b deals with the latter; the existence of an applicable permission is enough if ="perm" (because in this case the permission overrides any infringed prohibition), while for the other strategies , shall comply with all prohibitions. To understand point 2a, first note a crucial point: Remark 8. The fulfilling actions of obligations and duties may have to be authorized, too, but they may fall outside the scope of the policy Π, in general. For example, a content provider may state in Π that an mp3 can be played only after fulfilling the duty of paying 2 euros online, and this action is either permitted or denied by the policy Π′ of another company (the bank). This observation reveals a set of open issues: ODRL provides no means to define the scope of a policy (i.e. which actions must comply with which policy), nor whether there are actions that are not subject to any policy and may be freely exercised. Moreover there is no guideline about the interplay of diferent policies, of which the provider + bank example is just one particular instance; in more complex examples, Π and Π′ may "overlap" and conflicts may have to be solved. □ 3A policy may also contain properties that factorize the common features of its rules; however this is just an abbreviation and does not require additional semantic definitions. 4According to the closed policy, an action is permitted only if there is an explicit permission rule, cf. Remark 7.
In order to deal with the above lack of specifications, in this first proposal we provide a temporary solution by stipulating (through point 2a) that fulfilling actions are implicitly compliant with the policy that requests those actions. Thus, in the above example, the 2 euros payment complies with the policy Π of the content provider (which "requests" that action as a duty when the file is played), although it may infringe the policy Π′ of the bank. A cleaner solution needs a notion of policy scope.
In this section, the formalization presented in Section 3 is explained by using diferent examples of policy types and action instances presented in Section 2.
We start by explaining the evaluation of a first type of policy, that is, a policy containing a permission constrained by a constraint in which the class of actions governed is refined by another constraint, for example, the policy /policy/13-14#p in Figure 1. The rule 1 in the /policy/13-14#p is characterized by the following properties: • the type of the rule, = odrl:Permission; • the action class regulated by the rule, = odrl:print; • the target asset of the rule, = /doc.html.
Moreover, the rule 1 is restricted by a constraint ⟨ℓ, , ⟩ where ℓ=odrl:dateTime, =odrl:lt, and ="2018-01-01".
In order to evaluate the permission 1, we have to consider an action and a state. Following the formalization presented in Section 3.5, we start by evaluating the rule 1 on the action 1 (Action 1 in Section 2.1) and the state = ⟨, {1}, · ⟩ whose relevant properties are: • type of 1 = odrl:print, that is, 1 belongs to ("odrl:print") (which is the set of instances of odrl:print); • actors = party(1) = {/party#Alice}; • assets = obj(1) = {/doc.html}; • odrl:dateTime(1) = = 2017-12-31T14:35:27+01:00; • odrl:resolution(1) = 300.
First, it is necessary to check whether rule 1 is on action 1. This is done by evaluating whether the action 1 satisfies the constraint ⟨ℓ, , ⟩ of 1. Indeed, it holds that , 1 |= ⟨odrl:dateTime, odrl:lt, "2018-01-01"⟩ because the pair (odrl:dateTime(1)), ("2018-01-01")) evaluates to
(2017-12-31T14:35:27+01:00, 2018-01-01) ∈ (odrl:lt) .
Therefore, we can conclude that 1 is on action 1.
Subsequently, it is necessary to evaluate whether the action 1 complies with the permission 1 by checking all the following conditions: 1. 1 is active on 1 ∈ , as we have just shown; 2. 1 ∈ ( ), holds, because the type of 1 equals the permitted type (equivalently, 1 is an instance of odrl:print); 3. 1 satisfies the refinement: , 1 |= ⟨odrl:resolution, odrl:lteq, 300⟩, i.e. it holds that (odrl:resolution(1),300) = (300, 300) ∈ (odrl:lteq); 4. obj(1) = set( ()) = { ()}, i.e. {/doc.html} = {/doc.html}; 5. the other conditions need not be checked because the target has no refinements and the assignee is not specified.
Given that all these conditions are satisfied, we can conclude that 1 complies with the permission 1 in state (that is, 1 is permitted by 1). Since 1 is the unique action in and complies with the unique rule of policy /policy/13-14#p, which is a permission, the trace ⟨⟩ complies with /policy/13-14#p, according to Def. 8.
We continue by explaining the evaluation of a second type of policy, i.e. a policy containing a permission that is constrained by a duty, like /policy/22#p in Figure 2. The permission rule 1 in /policy/22#p is characterized by: • the type of the rule, 1 = odrl:Permission; • the action class regulated by the rule, 1 = odrl:play; • the target asset of the rule, 1 = /music/1999.mp3; • the assignee of the rule, 1 = /party#Bob.
The duty rule 1 in /policy/22#p is characterized by: • the type of the rule, 2 = odrl:Duty; • the action class regulated by the rule, 2 = odrl:compensate; Moreover, the action of 1 is subject to the refinement ⟨odrl:payAmount,odrl:eq,5.00⟩.
Consider Action 2 (formalized by an instance 2) in which Bob compensates 5.00 EUR and Action 3 (formalized by 3) in which Bob plays the mp3 (in Section 2.2). Following the formalization presented in Section 3.6, we shall evaluate the policy on a sequence of states ⟨1, 2⟩ where 1 complies with (i.e. fulfills) the duty 1, while in 2 the permission 1 to play the mp3 file is exercised. Accordingly, let us assume that in state 1 there is the action 2 ∈ 1 and 1 equals the time when 2 happens, i.e. 2017-12-31T14:35:27+01. The relevant properties of 2 are: • type = odrl:compensate; • actors = party(2) = {/party#Bob}; • odrl:dateTime1(2) = 1 = 2024-12-31T14:33:42+01:00; • odrl:payAmount1(2) = 5.00. 1 complies with (fulfills) the duty 1 because all the following conditions hold: 1. 1 is active because it has no constraints; 2. 2 ∈ ( 2), because the type of 2 equals the required type 2 = odrl:compensate; 3. 1’s action specification contains a refinement, and 2 satisfies the refinement because ⟨odrl:payAmount, odrl:eq, 5.00⟩; 4. the target and the assignee of 1 are not specified. , 2 |=
Let us now check whether the permission 1 applies to an action 3 ∈ 2, whose relevant properties are: • type = odrl:play; • actors = party(3) = {/party#Bob}; • assets = obj(3) = {/music/1999.mp3}; • odrl:dateTime2(3) = 2 = 2024-12-31T14:35:27+01:00.
It is straightforward to demonstrate that 3 complies with 1 in 2. This can be done by checking all the conditions for a duty-less permission as shown in the previous section. The second condition that must be checked for permissions with duties, is whether 2 is preceded by a state that fulfills the duty 1. As we have already pointed out, this second condition is satisfied with = 1. Now, if 2 and 3 are the only actions in ⟨1, 2⟩, then this trace complies with /policy/22#p because 2 is permitted by clause 2a in Def. 8 while 3 is permitted by clause 2b.
In this section we explain the evaluation of a third type of policy, i.e. a policy containing a prohibition constrained by a constraint, e.g. the policy /policy/19#p in Figure 3. The rule 1 in /policy/19#p is characterized by: • the type of the rule, = odrl:Prohibition; • the action class regulated by the rule, = odrl:archive; • the target asset of the rule, = /photoAlbum; • the assignee party of the rule, = /party#Bob.
Now we check whether the prohibition 1 forbids, in a state , a given action 4 ∈ , which corresponds to Action 4 (formalized by an instance 4) in Section 2.3. Following the formalization presented in Section 3.5, the relevant properties of 4 are: • type = odrl:archive; • actors = party(4) = {/party#Bob}; • assets = obj(4) = {/photoAlbum}; • odrl:dateTime(4) = 2023-06-18.
Moreover, the rule 1 is restricted by a constraint ⟨ℓ, , ⟩ where ℓ = odrl:dateTime, = odrl:lt, and = "2024-01-01".
First, it is necessary to check whether 1 is on 4 in . This amounts to checking whether 4 satisfies the constraint of 1. This evaluation is similar to the evaluation in Section 4.1 and we can conclude that 1 is on action 4.
Subsequently, it is necessary to evaluate if the action 4 complies with the prohibition 1 by checking whether at least one of the following conditions holds: 1. 1 is not active on 4 in ; as we pointed out, this condition does not hold; 2. 4 ̸∈ ( ); this does not hold either, because the type of 4 equals the prohibited type ; 3. some action refinement is violated; since there are no refinements, this condition does not hold; 4. it should be obj(4) ∩ set( ()) = ∅, since there are no target refinements; however the intersection equals {/photoAlbum}, therefore, this condition does not hold; 5. similarly, none of the assignees should match the assignee specification of 1; since party(4) = set( ()) = {/party#Bob}, this condition is not satisfied, either.
As none of the above conditions hold, we can say that 4 does not comply with the prohibition 1, that is, Bob’s action infringes the prohibition. Accordingly, the trace ⟨⟩ does not comply with /policy/19#p (cf. Def. 8).
Here we illustrate how declarative semantics can be used to assess the correctness of the algorithms designed for specific computational tasks, and guarantee their mutual interoperability. First we provide an abstract definition of the main classes of such algorithms. We define also what it means for these algorithms to be correct, based on the declarative semantics (i.e., the notion of compliance defined in the previous section).
Definition 9.
1. A monitoring mechanism MM is an algorithm that takes as input a trace (which models a system log) and a policy Π and returns a boolean value (compliant/non compliant); MM is correct if it returns true if and only if complies with Π; 2. an access control mechanism AC is an algorithm that takes a trace (which models the current situation), a policy Π, and a request of an action , represented as a state = ⟨, {}, (· )⟩,5 and returns a boolean value; AC is correct if it returns true if and only if the trace · (the concatenation of and ) complies with Π (that is, the execution of the action does not lead to a violation of Π); 3. a policy comparison mechanism PC is an algorithm that takes two policies Π1 and Π2 and returns a boolean value; PC is correct if it returns true if and only if all the traces that comply with Π1 comply also with Π2.6
As we claimed, it is now possible to guarantee that diferent algorithms behave in a coherent way, based on a single, unambiguous meaning of the policies involved. For example, it follows immediately from the above definitions that correct monitoring, access control and comparison mechanisms always return mutually compatible results: Proposition 1.
1. If a monitoring mechanism MM and an access control mechanism AC are correct, then for all traces and for all action requests ,
(, Π, ) = MM ( · , Π) (i.e. access control decisions are never invalidated during auditing); 2. if a monitoring mechanism MM and a policy comparison mechanism PC are correct, then for all traces and all policies Π1 and Π2, the following facts hold: a) for all traces , if (Π1, Π2) = and MM (, Π1) = , then MM (, Π2) = (when PC says that Π1 complies with Π2, if auditing is successful w.r.t. Π1, then it is successful also w.r.t. Π2); b) if (Π1, Π2) ̸= then there exists a trace such that MM (, Π1) = , and MM (, Π2) = (when PC says that Π1 does not comply with Π2, there exists indeed a trace such that auditing is successful only for Π1); 3. if an access control mechanism AC and a policy comparison mechanism PC are correct, then the following fact holds: for all traces and all action requests , if (Π1, Π2) = and (, Π1, ) = , then (, Π2, ) = (when PC says that Π1 complies with Π2, then access is granted by Π1 only if it is granted also by Π2).
Note that one correctness proof for each algorithm sufices to guarantee that its behavior is mutually compatible with that of all correct algorithms. Without a unique reference semantics, compatibility could only be guaranteed by proving a result similar to one of the above three propositions for each pair of algorithms.
We have provided a formalization of part of the ODRL 2.2 specification as provided by the ODRL
Information Model 2.2 [
Besides extending the coverage of the formalization, future work could: propose improvements of ODRL to overcome its current limitations; clarify the relationship between ODRL and existing W3C recommendations (such as XML Schema Part 2: Datatypes Second Edition [10] and RDF 1.1 Semantics [11]); further investigate policy scope, and how permissions and prohibitions are combined into policies; and extend the expressiveness of ODRL’s temporal constraints.
P. A. Bonatti acknowledges financial support from the PRIN 2022 project 2022LA8XBH-POLAR, and project SERICS (PE00000014) under the NRRP MUR program funded by the EU-NGEU. A. Harth acknowledges support from IGF project GRANERGIZE (FKZ 01IF23286N).
This work was conceived during the Dagstuhl Seminar 25051 “Trust and Accountability in Knowledge GraphBased AI for Self Determination”, which took place in January 2025.
During the preparation of the paper, the authors used DeepL for grammar and spelling check, paraphrase, and reword. The authors reviewed and edited the text and take full responsibility for the papers’s content. [10] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes Second Edition, Recommendation, W3C, 2004. https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Latest version available at https://www.w3. org/TR/xmlschema-2/. [11] P. Hayes, P. Patel-Schneider, RDF 1.1 Semantics, Recommendation, W3C, 2014. https://www.w3.org/TR/ 2014/REC-rdf11-mt-20140225/. Latest version available at https://www.w3.org/TR/rdf11-mt/.