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 (with all refinements satisfied) regulated
by an active permission, then the action is permitted.
if there is no active permission to do such an action (with all refinements satisfied) and the default
setting for the ODRL Evaluator is set to "everything is prohibited unless explicitly permitted" a
violation should be generated.
The ODRL Evaluator computes that a Permission is active if:
- all the existing Constraints of the Rule are satisfied and;
- all the existing Conditions (duties of the Rule) are fulfilled or inactive;
If one of those conditions is not met, the Permission is inactive.
In the following examples of permissions, as we will analyse one permission at a time, we will not deal with the generation of violations for permissions.
Evaluation of Constraints and Refinements
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.
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/13",
"permission": [{
"target": "http://example.com/document/1234",
"assigner": "http://example.com/party/16",
"action": "distribute",
"constraint": [{
"@id": "http://example.com/constraint/1",
"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 class of actions regulated by this Permission has type equal to distribute and
object equal to the target of the permission, i.e. document:1234.
- (E-13-1) If the requested or perfomed action belongs to the class of actions regulated by the Permission and the Permission is active then the action is permitted.
- (E-13-2) If the requested or perfomed action belongs to the class of actions regulated by the Permission, but the Permission is inactive, then, assuming that only this Permission is considered (this is because other permissions could regulate this action), the action is denied.
- If the requested or perfomed action does not belong to the class of actions regulated by the Permission then assuming that only this Permission is considered (this is because other permissions could regulate this action), the action is denied.
The table below shows the input (blue) and the output (red) of the ODRL Evaluator in different cases.
| Example | Policy | World | Requested/Performed Action | satisfaction state of constraint:1 |
activation state of the permission |
control state of the permission |
output |
|---|---|---|---|---|---|---|---|
| E13-1 | policy:13 (link) | We are in 2017 current time.year=2017(link) |
distribute
document:1234link |
satisfied | active | permit the action | (link 1) (link 2) |
| E13-2 | policy:13 (link) | We are in 2019 current time.year=2019(link) |
distributedocument:1234link |
not-satisfied | inactive | deny the action | (link 1) (link 2) |
Example of a permission whose permitted action is refined
Example description
The example below is similar to Example 14 in the ODRL Information Model 2.2.
It 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/14",
"permission": [{
"target": "http://example.com/document/1234",
"assigner": "http://example.com/party/616",
"action": [{
"rdf:value": { "@id": "odrl:print" },
"refinement": [{
"@id": "http://example.com/refinement/14"
"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 this Permission has type equal to print and
its object is equal to the target of the permission, i.e. document:1234.
Access control or monitoring scenario:
The Permission is always active because it has neither Constraints nor Conditions (Duties). Given a formal description a performed action.
- (E14-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 permission permits the action.
- (E14-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 permission does not permit the action.
| Example | Policy | Requested/Performed Action | satisfaction of refinement:14 |
activation state of the permission |
control state of the permission |
|---|---|---|---|---|---|
| E14-1 | policy:14 | print of document:1234 with resolution less than 1200 dpi was performed |
satisfied | active | permit the action |
| E14-2 | policy:14 | print of document:1234 with resolution more than 1200 dpi was performed |
not-satisfied | active | deny the action |
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.
- The initial state of a Condition (duty) is inactive.
- 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).
- If the Constraints of the Condition (duty) are all satisfied or there are no Constraints, then the duty is active.
- 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 | Policy | World | Requested/Performed Action | activation state of condition:1 |
deontic state of condition:1 |
activation state of the permission |
control state of the permission |
|---|---|---|---|---|---|---|---|
| E22-1 | policy:22 | compensate with payAmount = 5 euro and beneficiary = party:sony is not performed |
play and target = music:1999.mp3 and performer = party:billie |
active | not-set | inactive | deny the action |
| E22-2 | policy:22 | compensate and payAmount = 5 euro and beneficiary = party:sony is performed |
play and target = music:1999.mp3 and performer = party:billie |
active | fulfilled | active | permit the action |
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:
| Example | Policy | World | Requested/Performed Action | satisfaction of constraint:1 |
satisfaction of refinement:1 |
activation of condition:1 |
deontic state of condition:1 |
activation of the permission |
control state of the permission |
|---|---|---|---|---|---|---|---|---|---|
| E88-1 | policy:88 | It is not Sunday |
play and target = music:1999.mp3 and performer = party:billie |
not-satisfied | don't care | inactive | not-set | active | permit the action |
| E88-2 | policy:88 | It is Sundaycompensate with payAmount = 5 euro and beneficiary = party:sony is NOT performed. |
play and target = music:1999.mp3 and performer = party:billie |
satisfied | not-satisfied | active | not-set | inactive | deny the action |
| E88-3 | policy:88 | It is Sundaycompensate with payAmount = 5 euro and beneficiary = party:sony is performed. |
play and target = music:1999.mp3 and performer = party:billie |
satisfied | satisfied | active | fulfilled | active | permit the action |