# Usage Control Specification, Enforcement, and Robustness: A Survey

Ines Akaichi  0000-0002-6020-5572<EMAIL_ADDRESS>and  Sabrina Kirrane
0000-0002-6955-7718<EMAIL_ADDRESS>Institute for Information Systems
& New Media, Vienna University of Economics and BusinessViennaAustria

###### Abstract.

The management of data and digital assets poses various challenges, including
the need to adhere to legal requirements with respect to personal data
protection and copyright. Usage control technologies could be used by software
platform providers to manage data and digital assets responsibly and to
provide more control to data and digital asset owners. In order to better
understand the potential of various usage control proposals, we collate and
categorize usage control requirements, compare the predominant usage control
frameworks based on said requirements, and identify existing challenges and
opportunities that could be used to guide future research directions.

Usage Control, Policy Languages, Enforcement Frameworks, Robustness

This work is funded by the European Union Horizon 2020 research and innovation
programme under the Marie Skłodowska-Curie grant agreement No 860801. Sabrina
Kirrane is funded by the FWF Austrian Science Fund and the Internet Foundation
Austria under the FWF Elise Richter and netidee SCIENCE programmes as project
number V 759-N

††ccs: Security and privacy Information accountability and usage control††ccs:
Social and professional topics Computing / technology policy††ccs: Social and
professional topics Intellectual property††ccs: Social and professional topics
Privacy policies

##  1\. Introduction

Modern decentralized systems, such as the _Internet of Things (IoT)_ and
_virtual data spaces_ , face a variety of challenges from a data and digital
asset management perspective. According to Zrenner et al. (2019), data owners
are reluctant to share their data with decentralized systems, as often they
have no control over how their data are used. Since the _General Data
Protection Regulation_ (GDPR) (Commission, 2018) entered into force, in 2018,
the need to provide more control and transparency to data subjects with
respect to how personal data are _collected_ , _stored_ , and _processed_ is
mandated in Europe, and also outside of the European Union if the data relates
to European citizens. More broadly, the importance of digital asset management
is underlined by the _new copyright legislation_ (Commission, 2021), which
came into effect in 2021, with the aim to protect creativity in the digital
age.

When it comes to digital asset management, Pretschner (2009) and Park and
Sandhu (2004) highlight that the sharing of data in decentralized environments
goes beyond traditional access control, as existing solutions do not provide
control over data usage once access to the data has been granted. Technologies
that aim to address this challenge, which are usually classified as usage
control (Pretschner et al., 2006), aim to ensure that data consumers handle
data according to usage rules stipulated by data owners. More broadly, usage
control is an umbrella term for data management software that caters for data
protection, copyright, and/or various legislative and institutional policies
(Pretschner, 2009).

The term _usage control_ was first introduced by Park and Sandhu (2004) whose
research focuses on supporting the continuous monitoring of digital asset
usage in dynamic distributed environments. Over the years, researchers have
proposed various usage control conceptual models (cf., (Cao et al., 2020; Park
and Sandhu, 2004; Neisse et al., 2015)) and policy languages (cf., (Hilty et
al., 2007b; Kirrane et al., 2018; Colombo et al., 2010)). Other works focus on
enforcing the respective policies, via proactive mechanisms that aim to
prevent policy violations (cf., (Jung et al., 2014; Lazouski et al., 2012b;
Kumari et al., 2011)) and reactive mechanisms that detect security breaches
and policy violations (cf., (Basin et al., 2011; Pretschner et al., 2007;
Etalle and Winsborough, 2007)). Additionally, there are a handful of surveys
that aim to better understand the state of the art with respect to usage
control. For instance, Pretschner et al. (2008) survey existing usage control
mechanisms with a specific focus on _digital rights management_ (DRM)
technologies. Another survey conducted by Lazouski et al. (2010) focuses
specifically on the usage control (UCON) model proposed by Park and Sandhu
(2004), with the authors reviewing the various implementations and extensions.
In turn, Nyre (2011) analyzes the strengths and weaknesses of existing usage
control solutions, with a particular focus on enforcement mechanisms.

Considering the potential of usage control as a tool for ensuring compliance
with respect to data protection, copyright, as well as institutional policies,
there is need for a more holistic overview of existing works and their support
for a broad set of usage control requirements. Towards this end, in this
paper, we perform a comprehensive analysis of existing usage control
frameworks based on a variety of usage control requirements gleaned from the
literature. Our primary contributions are summarized as follows:  (i) we
present and align various usage control concept definitions found in the
literature;  (ii) we propose a comprehensive taxonomy of usage control
requirements that are commonly used to guide the development of usage control
solutions;  (iii) we conduct a qualitative comparison of the predominant usage
control proposals found in the literature based on the aforementioned taxonomy
(iv) we draw on the comparison in order to outline various challenges and
opportunities for the usage control domain in general and decentralized
systems in particular.

The remainder of this paper is structured as follows: In Section 2, we present
our motivating use case scenario and introduce several important usage control
concepts. In Section 3, we discuss the methodology underpinning our literature
review and requirements taxonomy generation process. In Section 4, we describe
the proposed taxonomy of usage control requirements. In Section 5, we compare
and contrast the predominant usage control frameworks found in the literature.
In Section 6, we discuss open challenges and opportunities for the usage
control domain. Finally, we conclude by summarizing the paper in Section 7.

##  2\. Motivational Scenario

We start by describing a practical usage control scenario that can be used to
guide our analysis. Following on from this, we provide the necessary
background in terms of usage control concept definitions.

###  2.1. Use Case

Our usage control scenario is inspired from the _internet of things_ (IoT)
domain. Figure 1 illustrates a smart city scenario, where residents make use
of multiple smart objects, such as smart homes, cars, parking lots, watches,
etc. Smart objects contribute, among other things, to simplifying every day
activities. These objects produce different types of data that are captured by
sensors or actuators. In such a scenario, data can relate to the smart
objects, such as power consumption, battery status, etc., or the users
themselves, such as Global Positioning System (GPS) location or any other type
of private information that relates specifically to the user. Different
stakeholders, such as institutions that manage the supply of water or energy,
are interested in the data produced by these smart objects in order to derive
insights on consumption that can be used to optimize their service offerings.
Such information could also be used by marketing companies in order to devise
new or adjust existing marketing strategies. Thus, the manufacturers of these
objects may host or use data sharing platforms whereby data resulting from the
use of smart objects are shared with both their customers and various third
parties. Such platforms could offer the following sharing possibilities to
subscribers:  (i) an option to download data relating to smart objects or
their users;  (ii) the ability to access ad-hoc analysis and statistics about
specific smart objects  (iii) the possibility to perform on-the-fly analysis
based on statistical or machine learning models.  The decentralized nature of
this data sharing scenario and the nature of the data imply usage concerns
that involve personal data (e.g., control the usage of location information)
and regulations (e.g., delete all personal data after a certain time, as
mandated by the GDPR), among others.

Figure 1. Descriptive Usage Control Scenario

###  2.2. Usage Control: What and How?

The goal of this section is to establish a common understanding in terms of
the various concepts that are collectively used to specify usage control
policies (what?) and to describe how usage control policies can be enforced
(how?).

####  2.2.1. What?

Pretschner et al. (2006) refer to an entity that provides a resource (e.g.,
data) together with a policy that describes its access and usage restrictions
as a _data provider_. Whereas, an entity that receives a copy of a resource
and the respective policy is called a _data consumer_. Park and Sandhu (2004)
refer to both the data consumer and the data provider as _subjects_. The
resources that are governed by the policy are referred to as _data_ by
Pretschner et al. (2006) and _objects_ by Park and Sandhu (2004). Usage
control policies express restrictions in the form of rules that govern the use
of resources, in particular the _actions_ or _operations_ on the data that can
be performed by data consumers (e.g., accessing, processing, downloading).
Park and Sandhu (2004) refer to such actions as _rights_.

Furthermore, Bettini et al. (2003) and Pretschner et al. (2006) define usage
control rules in terms of two basic classes: _provisions_ and _obligations_.
Provisions refer to specific activities that need to be performed before an
access decision is taken (i.e., before access to data is provided), while
obligations refer to activities that need to be performed in the future (i.e.,
after access to data has been granted). The problem with this definition is
that it does not capture the generality of usage rules in terms of what should
or should not (i.e., positive and negative obligations) and what can or can
not (i.e., permissions and prohibitions) be done with the data (Clemente et
al., 2005). This definition focuses only on the specific activities that must
be performed by users before and after access to the data is provided. Park
and Sandhu (2004), in turn, define usage control policies in terms of decision
factors that determine the final decision made by a system, also known as the
usage decision. Decision factors denote: _authorizations_ , _obligations_ ,
and _conditions_. Authorizations refer to constraints on subject or object
attributes that are used to enforce usage decisions. Attributes denote the
properties or the capabilities of subjects or objects. For instance, based on
our use case scenario, we could specify an attribute called _role_ that could
take the following values: admin for platform operators, owner for smart
device owners, and external for third parties. Additionally, we could define a
_subscription_ attribute that indicates whether a stakeholder has a
subscription to a data sharing platform or not. Another important aspect with
respect to attributes is the level of sensitivity attached to the data, which
may be different depending on the type of data, e.g., energy consumption,
location, medical, etc. An example of such a rule could be that _full access
to personal data that is classified as sensitive should only be given to the
data subject themselves_. While, obligations refer to activities that an
entity must carry out in order to be permitted to perform particular actions.
For example, in our motivating scenario, we assume that a stakeholder, namely,
the marketing company, is interested in performing data analysis with respect
to electricity consumption, however _if the marketing company wishes to
download user data (with the users consent) the company must delete the data
within 10 days_. Conditions, in turn, refer to environmental or system
requirements that have to be satisfied in order to perform certain actions on
data objects. For example, a condition can refer to the purpose for which the
data may be used, for instance _the marketing company may only use data for
scientific purposes_. Conditions are also used to refer to contextual
information, such as the _time_ and _location_ of environmental conditions.

Moreover, Park and Sandhu (2004) present an important aspect of usage control,
which is _the continuity of enforcement_. This feature implies that usage
decisions are enforced not only when data providers or data consumers generate
access requests, but also during the ongoing usage of the data. Continuity of
enforcement also implies that a usage control system must continuously
evaluate conditions and obligations. This means, that the conditions have to
be satisfied before (i.e., pre-condition) or during (i.e., ongoing-condition)
a usage process. In addition, the usage control system must ensure the
fulfillment of obligations before (i.e., pre-obligation), during (i.e.,
ongoing-obligation), and after (i.e., post-obligation) data are accessed. Once
the conditions no longer hold or the obligations are not met by data
consumers, the system can deny or revoke access to the data. In this paper, we
define usage control policies in terms of deontic concepts, both due to their
generality (Ortalo, 1996) but also because they provide support for what
should or should not as well as what can or cannot be done with data (Ortalo,
1996; Bettini et al., 2003). This definition is close to the definition of
Park and Sandhu (2004), but includes more specific decision factors (i.e.,
_permissions_ , _prohibitions_ , _obligations_ , and _dispensations_) that are
needed in order to represent legislative requirements. Bearing these different
definitions in mind, usage control policies can be defined in terms of the
continuity of enforcement and the following decisions factors: _permissions_ ,
_prohibitions_ , _obligations_ , _dispensations_ , _conditions_ , each of
which support a variety of _attributes_. Given that _obligations_ ,
_conditions_ , and _attributes_ have already been defined by Park and Sandhu
(2004), we build upon the definitions and examples presented above by
providing definitions and examples for the remaining concepts. _Permissions_
represent positive authorizations that allow entities to perform actions. For
instance, _the marketing company is permitted to download data about the
energy consumption of a specific neighborhood_. Prohibitions refer to negative
authorizations, implying that an entity is not allowed to perform the
specified actions. For example, _the marketing company is prohibited from
downloading personal information_. Dispensations refer to actions that an
entity is no longer required to perform, thus, they act as waivers for
existing obligations. For example, _a user is exempt from deleting their data
after usage because they are the owner_.

Figure 2 depicts a usage control model that encapsulates the various decision
factors that are necessary in order to create a usage control policy based on
the given definition. In the proposed model, a policy is made up of a set of
rules that encode permissions, prohibitions, obligations, or dispensations.
Each rule is associated with an action that is performed by a subject on a
target object. A rule can also be constrained by one or more conditions. The
various entities in the model can have specific attributes (e.g. policy
attributes and condition attributes). In addition, the model supports _nested
rules_ that can express nested requirements, which are needed to encode
regulatory requirements, such as those set forth by the GDPR. The modeling of
the nested rules is inspired by the _open digital rights language_ (ODRL)
regulatory profile proposed by Vos et al. (2019). Figure 3 shows an
instantiation of the model using a permission, a prohibition, and an
obligation with a nested dispensation that are inspired by our motivating use
case scenario.

Figure 2. A Usage Control Model based on Deontic Concepts

####  2.2.2. How?

According to Pretschner et al. (2008), usage control policies immediately
raise the question of enforcement. Indeed, policies depend on the actual
implementation and deployment of a usage control solution, which is limited to
the ability of the solution to continuously validate and enforce the usage
control decisions (Pretschner et al., 2006; Park and Sandhu, 2004). In this
paper, we refer to a usage control framework, as a complete framework that
allows for the specification, the enforcement, and the administration of usage
policies. According to Zhang et al. (2008), a usage control framework
addresses both the “how” and “what” aspects of policy enforcement. Generally
speaking, usage control frameworks are comprised of the following components:
(i) a formal machine-readable policy language that is used to express usage
control policies;  (ii) an enforcement mechanism that can monitor compliance
with said policies  (iii) an administration interface that can be used to
manage and monitor usage control policies.  Although there are several
frameworks in the literature, a detailed analysis is needed in order to better
understand how well the various usage control proposals support various usage
case requirements, which is the aim of this paper.

Figure 3. Usage Control Policies based on our Motivating Use case Scenario

##  3\. Methodology

Our survey was guided by the integrative literature review methodology
proposed by Torraco (2005). While, the requirements taxonomy generation
process followed the development methodology suggested by Nickerson et al.
(2013). Finally, the requirements taxonomy was used to perform a targeted
analysis of the predominant usage control frameworks found in the literature.

###  3.1. Literature Identification

The literature review involved the identification of concrete research
questions (_RQs_) and the corresponding review strategy (Torraco, 2005).
Considering that our overarching goal was to assess the status quo in terms of
usage control solutions found in the literature, and to identify open
challenges and opportunities, our research was guided by the following
research questions:
_RQ1._ What requirements are used to guide the development of usage control
solutions?
_RQ2._ Which specific requirements are supported by the predominant usage
control frameworks found in the literature?
_RQ3._ What are the open challenges and opportunities for the usage control
domain?

The papers subject to the review were found using the Google Scholar search
interface using keywords consisting of a combination of “usage control”,
“requirements”, and “framework” and the following inclusion and exclusion
criteria:  (i) include papers that mention usage control requirements;  (ii)
include papers that propose usage control frameworks and/or extensions  (iii)
exclude papers that focus on non-implemented frameworks.

First, we collected all papers that were returned using our Google Scholar
keyword search. Following on from this, the title, abstract, introduction, and
conclusion of all articles that matched our keyword search were examined for
relevancy based on our inclusion and exclusion criteria. Then, a full read
through of the remaining articles was performed in order to identify and
extract usage control requirements (_RQ1_) and to compare and contrast
existing frameworks (_RQ2_) as well as derive open challenges and
opportunities (_RQ3_). For every paper, an iterative backward (i.e., searching
the citations of the identified articles) and forward (i.e., locating the
papers that cite the identified articles) search was performed in order to
improve the coverage of related work.

Table 1. Usage Control Requirements and Sources

| Specification | Enforcement | Robustness
---|---|---|---
Authors | Expressiveness |  | Flexibility &
---
Extensibility
Unambiguous |  | Formal
---
Semantic
Preventive | Detective |  | Continuity
---
of enforcement
| Conflict Detection
---
& Resolution
Administration |  | Interoperability
---
& Compatibility
| Performance
---
& Scalability
Usability | Reliability
Katt et al. (2008) | X |  |  |  |  |  |  |  |  |  |  |  |
Hilty et al. (2006) | X |  |  |  |  |  |  |  |  |  |  | X |
Kumari (2010) | X |  |  |  |  |  |  |  |  |  |  | X | X
Pretschner et al. (2008) | X |  |  |  | X |  |  |  |  | X |  |  | X
Pretschner et al. (2006) | X |  |  |  |  | X | X |  |  |  |  |  | X
Munoz-Arcentales et al. (2020) |  | X |  |  |  |  |  |  |  | X | X |  | X
Clemente et al. (2005) |  | X | X |  |  |  |  | X |  | X | X |  |
Myers and Chong (2008) |  |  | X |  |  |  |  |  |  |  |  |  |
Mont (2004) | X |  | X |  |  |  |  |  | X |  |  |  | X
Jung et al. (2014) |  |  |  | X |  |  |  |  |  |  |  |  |
Feth and Pretschner (2012) |  |  |  | X |  |  |  |  |  |  |  |  |
Cao et al. (2020) | X |  |  | X |  |  |  | X |  |  |  |  | X
Schütte and Brost (2018) |  |  |  | X |  |  |  | X |  |  |  |  |
Teigão et al. (2011) | X | X | X |  |  |  |  |  |  |  |  |  |
Cirillo et al. (2020) | X |  |  |  |  |  |  |  |  |  |  |  | X
Bexheti and Langheinrich (2015) |  |  |  |  | X |  |  |  |  |  |  | X | X
Rath and Colin (2013) |  |  |  |  |  |  |  |  | X | X | X | X |
Zrenner et al. (2019) |  |  |  |  |  |  |  |  |  | X | X |  | X
Gil et al. (2020) |  |  |  |  |  |  |  |  |  |  | X |  | X
Keromytis and Smith (2007) |  |  |  |  |  |  |  |  |  |  | X |  |
Hilty et al. (2005) |  |  |  |  |  |  |  |  |  |  |  |  | X
Hilty et al. (2007a) |  |  |  |  |  |  |  |  |  |  |  |  | X
Kumari et al. (2011) |  |  |  |  | X |  |  |  |  |  |  |  | X
Hosseinzadeh et al. (2020) |  |  |  |  |  |  |  |  |  |  |  |  | X
Bier (2013) |  |  |  |  |  |  |  |  |  |  |  |  | X
Lazouski et al. (2010) |  |  |  |  |  |  | X |  |  |  |  |  |
Park and Sandhu (2004) |  |  |  |  |  |  | X |  |  |  |  |  |
Kagal et al. (2003) |  |  |  |  |  |  |  | X |  |  |  |  |

###  3.2. Taxonomy Generation

The method for taxonomy development proposed by Nickerson et al. (2013) was
subsequently used to build a usage control requirements taxonomy. We started
by determining the meta-characteristic of our taxonomy (essentially the goal
behind its development). In our case, the desire to identify requirements that
are used to guide the development of usage control solutions. Following on
from this, we identified the condition that would be used to end the taxonomy
construction process. In our case, when no new requirements are introduced.

The iterative taxonomy generation method identifies common characteristics
that are logical consequences of a meta-characteristic. In our case, the
(usage control) specification requirement encapsulates other fine-grained
requirements related to usage control specification, such as the
_expressiveness_ of the usage control policy language. Consequently,
individual requirements were grouped according to more general requirements,
for example, placing _expressiveness_ under _specification_. The taxonomy
building process ended once the final condition was triggered, i.e., when no
further requirements were introduced.

###  3.3. Comparison and Synthesis

The resulting taxonomy was subsequently used to compare the various usage
control frameworks that have been proposed to date. The analysis, which was
initially performed using Excel spreadsheets, was later synthesized using high
level comparative tables and supporting textual descriptions. Finally,
building upon the insights gained from our detailed analysis, we derived
opportunities and challenges for the usage control domain in general and
decentralized systems in particular.

##  4\. A Taxonomy of Usage Control Requirements

In the following, we describe our taxonomy of usage control requirements.
Table 1 displays a matrix of requirements and the corresponding sources from
which they are taken. The respective requirements are illustrated in Figure 4,
which depicts our final taxonomy. The taxonomy is divided into three high
level usage control dimensions: (i) the policy language; (ii) the enforcement
mechanism; and (iii) the robustness of the overall solution.

###  4.1. Specification

The specification dimension includes four sub-dimensions that represent
requirements relating to policy specification and policy representation.

Figure 4. Taxonomy of Usage Control Requirements

####  4.1.1. Expressiveness (Katt et al., 2008; Hilty et al., 2006; Kumari,
2010; Pretschner et al., 2008; Cao et al., 2020; Mont, 2004; Pretschner et
al., 2006; Teigão et al., 2011; Cirillo et al., 2020; Zhang et al., 2008; Bai
et al., 2010; Martinelli et al., 2016b; Feth and Pretschner, 2012; Jung et
al., 2013).

According to Pretschner et al. (2006), policy based usage control systems rely
on the ability of the policy language to formally express usage control
policies by translating high-level policies defined by data providers into
machine-readable usage policies. Mont (2004) argue that the language used to
encode usage control policies must be expressive enough such that requests for
access to objects can be permitted or prohibited. According to Zhang et al.
(2008), various usage control decision components (i.e., obligations,
attributes, and conditions) must be encoded using an appropriate language.
Moreover, Colombo et al. (2010) introduced a _mutability_ decision property,
which they argue is an important usage control requirement, as attributes
often need to be changed as a side effect of the subject’s use of an object.
Cao et al. (2020); Kumari (2010); Pretschner et al. (2008), and Zhang et al.
(2008) describe different types of conditions, which relate to time,
cardinality, purpose of use, and technical or governance constraints, which
may need to be included in usage control policies, in order to accommodate
different application contexts (e.g., privacy, copyright protection,
regulations) and different fields (e.g., IoT and _information and
communications technology_ (ICT)). Moreover, several studies (Hilty et al.,
2006; Bai et al., 2010; Martinelli et al., 2016b; Feth and Pretschner, 2012;
Jung et al., 2013) highlight the need for policies that can specify rules with
respect to contextual information, such as GPS information in the context of
mobile and ubiquitous applications.

####  4.1.2. Flexibility & Extensibility (Munoz-Arcentales et al., 2020;
Clemente et al., 2005; Teigão et al., 2011).

Usage control can be applied in different application contexts (e.g., _digital
rights management_ (DRM) and data privacy) or different fields (e.g., ICT and
IoT). This, as highlighted by Munoz-Arcentales et al. (2020), gives rise to
the need for flexible usage control solutions that can be adapted to cater for
various use case scenarios. Besides, Clemente et al. (2005) and Teigão et al.
(2011) highlight the need for an extensible usage control solution that allows
for new types of policies to be supported at a later point in time.

####  4.1.3. Unambiguous (Myers and Chong, 2008; Mont, 2004; Clemente et al.,
2005; Teigão et al., 2011).

In order to automatically enforce usage control policies, said policies need
to be translated from high-level goals to formal rules, such that they can be
deployed and enforced by the usage control system. This is only possible if
the usage control policy language is able to unambiguously specify the meaning
of such policies via a well-defined syntax and semantics (Mont, 2004; Clemente
et al., 2005). According to Myers and Chong (2008) and Teigão et al. (2011),
expressive, formal, and well-defined information policies can ensure the
correct enforcement of high level goals.

####  4.1.4. Formal Semantics (Jung et al., 2014; Feth and Pretschner, 2012;
Cao et al., 2020; Schütte and Brost, 2018).

Formal semantics refers to approaches that are used to specify the precise
meaning for the various concepts and rules encoded in usage control policies.
According to Lazouski et al. (2010) and Schütte and Brost (2018), the
formalization of usage control policies helps to facilitate system governance
by verifying compliance against higher level goals. Moreover, Jung et al.
(2014); Feth and Pretschner (2012) and Cao et al. (2020) state that formal
policies can help with automated analysis (i.e., automatizing the decision of
the system and checking for policy conflicts).

###  4.2. Enforcement

Enforcement refers to the mechanisms used to enforce and manage usage policies
throughout the usage process, which consists of three phases: before usage,
ongoing usage, and after usage (Cirillo et al., 2020). According to Pretschner
et al. (2006), in order for usage control policies to work as intended, the
policy enforcement must be applied continuously.

####  4.2.1. Preventive (Pretschner et al., 2008; Kumari et al., 2011; Bexheti
and Langheinrich, 2015; Park and Sandhu, 2004).

According to Pretschner et al. (2008); Kumari et al. (2011); Bexheti and
Langheinrich (2015), and Park and Sandhu (2004), the dynamic and proactive
enforcement of data usage policies implies the ability of the usage control
solution, in particular, the preventive mechanism to at least:  (i) allow or
prohibit requests for data usage;  (ii) revoke access in the event of policy
violations;  (iii) delay an attempted usage request until the corresponding
obligations are fulfilled;  (iv) update user or object attributes as a result
of usage decisions  (v) execute actions such as sending notifications to data
owners.

####  4.2.2. Detective (Pretschner et al., 2006).

According to Pretschner et al. (2006), detective mechanisms are very
important, particularly if the usage control framework is not able to
dynamically enforce the policy restrictions or prevent policy violations from
happening. For instance, it is difficult to see if data are actually deleted,
but there may be technical means to show that the respective command has been
executed by using different detective mechanisms, such as auditing, logging,
or simply notifying a user when the command is executed.

####  4.2.3. Continuity of Enforcement (Lazouski et al., 2010; Park and
Sandhu, 2004; Pretschner et al., 2006).

According to Lazouski et al. (2010); Park and Sandhu (2004), and Pretschner et
al. (2006), a usage control framework should be capable of handling the
continuous enforcement of policies. This implies the management of attributes,
conditions, and the fulfillment of obligation actions that reflect the
validity of the continuous usage of data objects.

####  4.2.4. Conflict Detection & Resolution (Kagal et al., 2003; Clemente et
al., 2005; Cao et al., 2020; Schütte and Brost, 2018).

Another aspect of enforcement is the management of conflicting rules, which is
particularly difficult in decentralized or distributed systems, as data may be
governed by a variety of policies (Kagal et al., 2003; Clemente et al., 2005).
According to Schütte and Brost (2018) and Cao et al. (2020), an enforcement
engine should be able to detect and resolve conflicting or incomplete rules.

####  4.2.5. Administration (Rath and Colin, 2013; Mont, 2004).

According to Mont (2004), a complete usage control solution must include an
administration tool, which provides an interface to manage (i.e., create,
edit, and delete) usage control policies. Rath and Colin (2013) highlight the
importance of administration interfaces, especially for users that use
healthcare information systems, as such a feature allows them to customize
their usage policies without the help of system administrators.

###  4.3. Robustness

Robustness is an all encompassing term used to refer to requirements that
relate to the overall effectiveness of the usage control system.

####  4.3.1. Performance & Scalability (Rath and Colin, 2013; Zrenner et al.,
2019; Munoz-Arcentales et al., 2020; Gil et al., 2020; Clemente et al., 2005;
Keromytis and Smith, 2007).

Several works (Zrenner et al., 2019; Rath and Colin, 2013; Munoz-Arcentales et
al., 2020; Gil et al., 2020; Clemente et al., 2005) highlight that a usage
control infrastructure should be performant enough to cater for the parallel
processing of a large number of requests by data requestors and for a short
loading time of the requested data. Furthermore, Keromytis and Smith (2007)
and Zrenner et al. (2019) highlight the fact that policy management systems
need to be realized using scalable architectures that can handle an increasing
number of users.

####  4.3.2. Interoperability & Compatibility (Rath and Colin, 2013; Zrenner
et al., 2019; Munoz-Arcentales et al., 2020; Clemente et al., 2005; Pretschner
et al., 2008).

Zrenner et al. (2019) state that usage control needs to work even if data
providers and data consumers have different infrastructures. While, Munoz-
Arcentales et al. (2020); Rath and Colin (2013), and Clemente et al. (2005)
highlight the importance of establishing interoperable mechanisms as without
them the system can only be utilized on particular devices, which according to
Pretschner et al. (2008) will limit the uptake of usage control technologies.
Besides, Jamkhedkar et al. (2010) attest that it is necessary to have
mechanisms that allow for the specification of usage policies that can be
interpreted and enforced across multiple different computing environments.
This can be fulfilled by: (i) applying standards; and (ii) separating the
usage control system components for policy expression, policy interpretation,
and policy enforcement. Such separation allows policies to express the
restrictions with minimal apriori knowledge of the IT environments in which
the policies will be interpreted.

####  4.3.3. Usability (Hilty et al., 2006; Bexheti and Langheinrich, 2015;
Rath and Colin, 2013; Kumari, 2010).

According to Rath and Colin (2013) and Hilty et al. (2006), the usability of
administration tools is an important requirement that should be supported via
user-friendly interfaces or easy-to-use languages. Hilty et al. (2006) state
that administration tools may be used by end users (as opposed to system
administrators) in order to enter their preferences and manage the use of
their data. Usability is especially important when it comes to mobile and/or
web applications (Bexheti and Langheinrich, 2015; Rath and Colin, 2013;
Kumari, 2010) where users need to manage how their data are used.

####  4.3.4. Reliability (Pretschner et al., 2008; Hilty et al., 2005; Mont,
2004; Gil et al., 2020; Hilty et al., 2007a; Bexheti and Langheinrich, 2015;
Kumari et al., 2011; Hosseinzadeh et al., 2020; Kumari, 2010; Zrenner et al.,
2019; Cao et al., 2020; Bier, 2013; Munoz-Arcentales et al., 2020; Pretschner
et al., 2006).

Reliability refers to the ability of a usage control mechanism to be compliant
with usage control policies and transparent with respect to the way data are
used (Pretschner et al., 2006).

##### System Reliability (Pretschner et al., 2008; Hilty et al., 2005; Mont,
2004; Gil et al., 2020; Hilty et al., 2007a).

Pretschner et al. (2008); Mont (2004), and Gil et al. (2020) highlight the
importance of system reliability when dealing with distributed usage control
systems, as sometimes the infrastructure of the provider is hosted by a third
party, leaving the owner with little or no control over how their data are
used. System reliability depends on the level of compliance with respect to
usage control policies that can be ensured by two factors: controllability and
observability, notions initially introduced by Hilty et al. (2005). On one
hand, controllable restrictions are policies by which the data provider can
ensure that the data consumer complies with everything that has been mentioned
in the policy. On the other hand, observable restrictions are policies that
the data provider cannot control. In this context, the data provider can only
observe violations and take compensatory actions, such as lowering the trust
or credibility rating of the data consumer or taking some form of legal
action.

##### Transparency (Bexheti and Langheinrich, 2015; Kumari et al., 2011;
Hosseinzadeh et al., 2020; Kumari, 2010; Zrenner et al., 2019; Cao et al.,
2020; Bier, 2013; Munoz-Arcentales et al., 2020; Pretschner et al., 2006;
Cirillo et al., 2020).

The usage control process should be transparent to and comprehensible by data
providers and data consumers alike (Bexheti and Langheinrich, 2015; Kumari et
al., 2011; Zrenner et al., 2019). Pretschner et al. (2006) mention data
auditing as a means to observe the fulfillment or the violation of non-
observable restrictions. Moreover, Hosseinzadeh et al. (2020) state that the
logging of data usage information can ensure both transparency and
reliability, as logs provide visibility with respect to the inner workings of
a software systems. Bier (2013) and Munoz-Arcentales et al. (2020) indicate
that data provenance tracking is complementary to distributed data usage
monitoring. Cao et al. (2020) and Kumari (2010) state that providing
explanations, with respect to actions performed by the system, is part of
ensuring transparency as explanations provide a basis for decision-making.
While, Munoz-Arcentales et al. (2020), Cao et al. (2020), and Cirillo et al.
(2020) highlight the importance of a trusted infrastructure, especially when
it comes to guaranteeing secure data sharing and adherence to usage policies.

##  5\. Frameworks

The goal of this section is to provide a detailed analysis of existing usage
control frameworks with a particular focus on the domain of usage, as well as
their support for the various policy specification, enforcement, and
robustness requirements.

###  5.1. Domain of Usage

In Table LABEL:tab:general-description-v1 we provide a high level overview of
the domain of usage of the various usage control frameworks. The
specification, enforcement, and robustness columns of the table, which serve
to provide a single snapshot of existing usage control proposals, are
discussed in detail in the subsequent sub-sections. Due to the variety of
usage control domains, we group together the usage control framework proposals
according to three application domains, namely, _mobile, cloud, IoT, and
industry 4.0_ ; _networking, operating systems and collaborative software_ ;
and _domain-agnostic_.

####  5.1.1. Mobile, Cloud, IoT, and Industry 4.0.

A prominent framework found in the literature is the _usage control systems_
framework proposed by Lazouski et al. (2012a) and Carniani et al. (2016),
which can be used to control data usage in modern decentralized and
distributed environments, for instance, IoT, cloud computing, mobile
computing, and data sharing platforms. The same framework was later refined
and used in various industry 4.0 use cases (Giorgi et al., 2017; Costantino et
al., 2018; La Marra et al., 2017a, 2019b). Additionally, an adaptation of the
proposed framework is used by Martinelli et al. (2016b) in a mobile computing
context. The _intent-oriented data usage control for federated data analytics_
or IntentKeeper framework proposed by Cirillo et al. (2020), which protects
data during federated data analytics, is applied in an automotive setting. The
_trusted usage framework_ proposed by Baldini et al. (2013); Neisse et al.
(2015) is intended to address the challenges of heterogeneity in IoT
technologies. The _trustworthy data sharing platform_ framework proposed by
Cao et al. (2020) is designed with a smart city use case in mind. Another
framework that deals with data sharing in smart cities is proposed by Munoz-
Arcentales et al. (2019) was later implemented by the same authors (Munoz-
Arcentales et al., 2020). In turn, the _integrated distributed data usage
control enforcement_ (IND2UCE) (Jung et al., 2014) framework is designed to
support usage control in cloud environments. IND2UCE is originally proposed by
Steinebach et al. (2016) in order to manage data usage in industry 4.0
environments. A technical implementation of IND2UCE, under the name _MYDATA
technologies_ , is described in (Eitel et al., 2017). The framework is also
mentioned as a solution for business ecosystems in (Zrenner et al., 2019). The
framework proposed by Wüchner et al. (2013) is designed to preserve regulatory
compliance in federated cloud storage. The _context-aware usage control_
(ConUCON) framework (Bai et al., 2010) is designed for mobile computing and
uses contextual information in order to enhance data protection. While, the
framework proposed by Feth and Pretschner (2012) aims to enhance Android
security by allowing users to manage fine-grained security policies.

####  5.1.2. Networking, Operating Systems and Collaborative Software.

The _usage control systems_ framework proposed by Lazouski et al. (2012a) and
Carniani et al. (2016) is further refined and used to enhance network security
(Martini et al., 2020; La Marra et al., 2019a, 2017b). The xDUCON framework,
proposed by Russello and Dulay (2009) is intended to regulate how data are
managed and shared among distributed environments and organizations. While,
LUCON (Schütte and Brost, 2018) is a message-based system that guarantees the
secrecy of messages routed between services. LUCON also appears in the context
of _MYDATA technologies_ for controlling data flows between endpoints. In
turn, the framework presented in (Wüchner and Pretschner, 2012) aims to
monitor the use of confidential data at the operating system level. The
frameworks proposed by Teigão et al. (2011) and Xu et al. (2007) cater for the
management of operating systems resources (e.g., files, network connections,
memory areas, and system applications). While, the framework proposed by Weber
and Silva (2010) is evaluated in an operating system context. Finally, the
framework proposed by Zhang et al. (2008) is applied in a collaborative
systems context. An architectural instantiation of the same framework with
some improvements can be found in (Katt et al., 2008).

####  5.1.3. Domain-agnostic.

The framework presented in (Lazouski et al., 2012b) is designed for modern
distributed computing systems, without a specific use case in mind. Although
the IND2UCE framework (Jung et al., 2014) is applied in a cloud computing
context, the framework was originally proposed for controlling data usage in
modern distributed environments, in general. Other usage control frameworks
proposed by Weber and Silva (2010) and Wüchner and Pretschner (2012) that are
meant to be domain agnostic are evaluated using operating system use cases.
While, Martinelli et al. (2019) demonstrate the effectiveness of the _usage
control systems_ framework proposed by Lazouski et al. (2012a) and Carniani et
al. (2016) as a general purpose architecture. The domain-agnostic OB-XACML
framework, proposed by Kateb et al. (2014), deals with enhancing XACML in
order to cater for usage control obligations and continuity of enforcement. In
turn, the framework proposed by Neisse et al. (2011) can be used to specify
and enforce general purpose usage control policies.

###  5.2. Specification

According to Bier (2013), when it comes to policy specification, one has to
differentiate between the policy language, the representation format, and the
model underpinning the usage control system. In Table 2, we present a
comparison of the various approaches used for policy specification.

####  5.2.1. Expressiveness.

The expressiveness of a policy language is reflected by the different decision
factors used to express high-level usage control policies. Decision factors
depend on the specification of policy rules, conditions, subject and object
attributes, as well as contextual information.

Table 2. Usage Control Policy Specification 111P= permission; Pr= prohibition; O= obligation; D= dispensation ; A= authorizations; E= event; C= conditions; P= predicate; Ac= actions, Al= allow; D= drop; S= Subject; T= Target; For attributes, if ’mutability’ then the policy supports mutable attributes, if blank then the policy doesn’t support mutable attributes, else the policy does not support attributes at all; For the rest of the columns, if ’-’, then not supported Framework | Expressiveness | Flexibility & Extensibility |  Unambiguous |  Formal Semantics
---|---|---|---|---
|  Operators/ Rules | Conditions |  Attributes |  Context |  Represent- ation |  Model |  |
Bai et al. (2010) |  A, O |  | environmental
---
system-oriented
mutability |  model based |  XML |  UCON |  _ |  _
Baldini et al. (2013); Neisse et al. (2015) |  E, C, A |  | cardinal
---
temporal
event-defined
|  model based |  XML |  _ |  _ |  OSL
Cao et al. (2020) |  P, Pr, O |  | actor
---
spatial
temporal
purpose
monetization
|  model based |  XML |  DUPO |  _ |  defeasible logic
Lazouski et al. (2012a); Carniani et al. (2016) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
Costantino et al. (2018) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
Cirillo et al. (2020) |  P, Pr, O |  | purpose
---
temporal
spatial
event-defined
_ |  _ |  XML |  ODRL |  _ |  _
Feth and Pretschner (2012) |  E, C, Ac |  | cardinal
---
temporal
spatial
_ |  _ |  XML |  _ |  _ |  OSL
Giorgi et al. (2017) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
Jung et al. (2014) |  E, C, Ac |  | cardinal
---
temporal
|  system- based |  XML |  _ |  _ |  OSL
Kateb et al. (2014) |  A, O |  | environmental
---
system oriented
|  model based |  XML |  XACML |  _ |  _
Lazouski et al. (2012b) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
Martini et al. (2020); La Marra et al. (2019a) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
La Marra et al. (2017a) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
La Marra et al. (2019b) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
La Marra et al. (2017b) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
Martinelli et al. (2016b) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
Martinelli et al. (2019) |  A, O |  | environmental
---
system-oriented
mutability |  system based |  XML |  XACML |  _ |  _
Munoz-Arcentales et al. (2020, 2019) |  P, Pr, O |  | temporal
---
spatial
amount-based
_ |  _ |  XML |  ODRL |  _ |  _
Neisse et al. (2011) |  E, C, Ac |  | cardinal
---
temporal
spatial
mutability |  _ |  XML |  _ |  _ |  OSL
Russello and Dulay (2009) |  S, T, Ac |  | temporal
---
spatial
mutability |  model based |  _ |  _ |  _ |  _
Schütte and Brost (2018) |  Al, D, O | _ |  |  _ |  Java |  DSL |  _ |  first order logic
Teigão et al. (2011) |  A, O |  | environmental
---
system-oriented
mutability |  _ |  LALR |  UCON |  _ |  _
Weber and Silva (2010) |  E, C, Ac |  | cardinal
---
temporal
spatial
_ |  _ |  XML |  _ |  _ |  OSL
Wüchner et al. (2013) |  E, C, Ac |  | cardinal
---
temporal
spatial
_ |  _ |  XML |  _ |  _ |  OSL
Wüchner and Pretschner (2012) |  E, C, Ac |  | cardinal
---
temporal
spatial
_ |  _ |  XML |  _ |  _ |  OSL
Xu et al. (2007) |  E, P, Ac | _ |  mutability |  _ |  XML |  UCON |  _ |  _
Zhang et al. (2008) |  A, O |  | environmental
---
system-oriented
mutability |  model based |  XML |  UCON |  PEI |  _

##### Operators/ Rules.

The policy languages presented in (Bai et al., 2010; Zhang et al., 2008;
Teigão et al., 2011; Xu et al., 2007) support the core UCON (Park and Sandhu,
2004) model components, namely, authorizations and obligations. UCONKI, a
policy language proposed by Xu et al. (2007), which only supports
authorizations, is an event-based UCON model that uses the Event-Predicate-
Action (EPA) language that originated from Event-Condition-Action (ECA)
(Alferes et al., 2006) rules. An event is an activity carried out by a
subject; the action part consists of preventive and detective mechanisms; and
the predicate part defines UCON authorizations.

The frameworks presented in (Lazouski et al., 2012b, a; Carniani et al., 2016;
Giorgi et al., 2017; Martini et al., 2020; La Marra et al., 2019a; Costantino
et al., 2018; La Marra et al., 2017a, 2019b, b; Martinelli et al., 2019,
2016b) use the U-XACML policy language and model, which was originally
proposed by Colombo et al. (2010). U-XACML is an extension of XACML that
introduces attribute updates and continuous policy evaluation. It mainly
supports UCON authroizations and XACML obligations. In the UCON model,
obligations are actions that have to be performed by subjects. Whereas, in
XACML obligations have different semantics and are considered as duties that
are performed by the enforcement mechanism in order to enforce access
decisions (Lazouski et al., 2010). Later Martinelli et al. (2019) extended
U-XACML in order to provide support for UCON obligations. A similar policy
language to U-XACML is OB-XACML, which is proposed by Kateb et al. (2014).
However, OB-XACML is able to formalize post-obligations and contextual
information via the OB-XACML model.

Cao et al. (2020) propose a _data usage control model_ , entitled DUPO, that
can be used to cater for diverse usage control policies. The policy language
is based on defeasible logic and enriched with deontic operators. Another
policy language that uses deontic operators to express usage control policies
is the _open digital rights language_ (ODRL) (working group, 2018), which is
used by both Munoz-Arcentales et al. (2019, 2020) and Cirillo et al. (2020).
ODRL is a World Wide Web Consortium (W3C)222W3C, https://www.w3.org/ standard
that provides an information model, vocabulary, and encoding mechanisms that
can be used to represent statements about content and services usage333ODRL,
https://www.w3.org/community/odrl/.

The policy language adopted by (Neisse et al., 2011; Wüchner and Pretschner,
2012; Wüchner et al., 2013; Weber and Silva, 2010; Feth and Pretschner, 2012;
Jung et al., 2014; Baldini et al., 2013; Neisse et al., 2015) uses ECA rules
to express policies. Conditions, which are mainly used to impose temporal and
cardinal constraints on data usage, are expressed using the _obligation
specification language_ (OSL) (Hilty et al., 2007b). The formal model of OSL
is logic based and specified in the Z language (Abrial, 1974). The action part
consists of preventive and detective mechanisms. Unlike the original UCON
model, OSL is able to formalize, alongside pre-obligations and ongoing-
obligations, post-obligations (Lazouski et al., 2010).

The policy language proposed by Schütte and Brost (2018), which is represented
in a _domain specific language_ (DSL), named LUCON DSL, is specified in Java
and compiled into first order logic. The DSL grammar is used to express the
rules that determine whether the sending of a message is allowed or
prohibited. This grammar also allows a decision to be linked to an obligation,
in particular a pre-obligation. The policy language underpinning the xDUCON
framework proposed by Russello and Dulay (2009) is represented in xDSpace, an
implementation of the _shared data space_ (Gelernter, 1985) programming
system. xDSpace allows rules to be expressed as tuples that include subjects,
targets (or objects), and actions to be performed on the object by the
subject.

##### Conditions.

UCON-based policy languages (Bai et al., 2010; Zhang et al., 2008; Teigão et
al., 2011; Xu et al., 2007; Kateb et al., 2014; Lazouski et al., 2012b, a;
Carniani et al., 2016; Giorgi et al., 2017; Martini et al., 2020; La Marra et
al., 2019a; Costantino et al., 2018; La Marra et al., 2017a, 2019b, b;
Martinelli et al., 2019, 2016b) allow different environmental and system-based
conditions to be expressed. However, the policy language proposed by Teigão et
al. (2011) only caters for four predefined conditions, namely, the current
time, the amount of CPU in use, and the amount of free memory and disk space.
ODRL (Cirillo et al., 2020; Munoz-Arcentales et al., 2020, 2019) allows
various conditions to be expressed, such as, temporal, spatial, amount-based,
purpose, and event-defined. The DUPO policy language presented in (Cao et al.,
2020) also allows event-defined conditions to be expressed. DUPO allows five
pre-defined conditions to be expressed, namely, actor, spatial, temporal,
purpose and monetization. The OSL-based policy languages presented in (Neisse
et al., 2011; Wüchner and Pretschner, 2012; Wüchner et al., 2013; Weber and
Silva, 2010; Feth and Pretschner, 2012; Jung et al., 2014; Baldini et al.,
2013; Neisse et al., 2015) are mainly used to express temporal and cardinal
conditions on the data using OSL. Moreover, the policy language used in the
framework proposed by Feth and Pretschner (2012) allows additional attributes
defined as XML spatial conditions to be captured. Whereas, the policy language
proposed by Jung et al. (2014) makes use of the condition part to refer to
additional attributes such as contextual information relating to the policy.
The xDUCON policy language (Russello and Dulay, 2009) allows for the
expression of two predefined conditions that represent the contextual
information captured by the framework, namely, temporal and spatial
conditions.

##### Attributes.

Most of the UCON-based policy languages presented in (Bai et al., 2010; Zhang
et al., 2008; Teigão et al., 2011; Xu et al., 2007; Lazouski et al., 2012b, a;
Carniani et al., 2016; Giorgi et al., 2017; Martini et al., 2020; La Marra et
al., 2019a; Costantino et al., 2018; La Marra et al., 2017a, 2019b, b;
Martinelli et al., 2019, 2016b) support attribute mutability by allowing
attribute updates. The authors of the framework presented in (Bai et al.,
2010) detailed the policy attributes responsible for controlling ongoing
obligations and attributes using the XML policy attribute _obligationTime_ and
an _update policy_ , respectively, which indicates the attribute to be updated
and the update time. In addition, the U-XACML policy language presented in
(Lazouski et al., 2012b, a; Carniani et al., 2016; Giorgi et al., 2017;
Martini et al., 2020; La Marra et al., 2019a; Costantino et al., 2018; La
Marra et al., 2017a, 2019b, b; Martinelli et al., 2019, 2016b) supports
attribute mutability by introducing _AttrUpdate_ in the policy specification.
The framework proposed by Neisse et al. (2011) allows attributes to be updated
by exploiting the _attributeMatch_ element in XML, which is bound to temporal
operators. The attributes supported by the various policy languages depend
significantly on the scope of the usage control solution.

##### Context.

Several authors (Jung et al., 2014; Cao et al., 2020; Bai et al., 2010; Zhang
et al., 2008; Russello and Dulay, 2009; Kateb et al., 2014; Baldini et al.,
2013; Neisse et al., 2015) introduced contextual information in their policy
specification. For instance, the policy languages adopted by Zhang et al.
(2008) and Jung et al. (2014) use conditions to support context-based
authorizations. Another framework, the one proposed by Bai et al. (2010)
presents the ConUCON policy language based on the ConUCON policy model, which
is an extension of UCON with a new component that caters for contextual
information. The new context component allows ongoing environmental (e.g.,
spatial and temporal) and system (e.g., CPU and battery) information to be
captured. The remaining frameworks presented in (Lazouski et al., 2012b, a;
Carniani et al., 2016; Giorgi et al., 2017; Martini et al., 2020; La Marra et
al., 2019a; Costantino et al., 2018; La Marra et al., 2017a, 2019b, b;
Martinelli et al., 2019, 2016b) are context based-systems, as they directly
make use of the contextual information collected via their system components.

####  5.2.2. Flexibility & Extensibility.

Some policies owe their flexibility and extensibility to the conceptual model
that expresses the policy in an abstract way and/or to the language used to
encode policies.

##### Representation Format.

Most of the policy languages are represented in XML. The remaining ones are
represented either in DSL specified in Java (Schütte and Brost, 2018) or the
_look-ahead-left-to-right_ (LALR) grammar (Teigão et al., 2011). Zhang et al.
(2008) state that the XML language is extensible enough to meet the
expressiveness and flexibility of the UCON model, but also its extensions.
Besides, Feth and Pretschner (2012) agree that XML allows new policy rules to
be added in order to express and extend different models, which is confirmed
by Colombo et al. (2010) who successfully incorporated UCON components in the
XACML policy language. For the remaining representation languages, Teigão et
al. (2011) and Schütte and Brost (2018) assert that their proposed languages,
which use the LALR grammar and Java, respectively, are sufficiently extensible
and flexible to meet new conditions and usage rules.

##### Conceptual Model.

The UCON model has demonstrated great flexibility as it has been used in
different application contexts, such as industry 4.0, operating systems, and
mobile computing. For example, Bai et al. (2010) claim that the ConUCON policy
model can be implemented not only for Android but also for other mobile
platforms due to the policy flexibility and extensibility. Moreover, Katt et
al. (2008) incorporated post-obligations in the context of an Industry 4.0
application and Bai et al. (2010) extended the original UCON model with
context components in order to develop context-aware ubiquitous systems. As
for ODRL, according to Munoz-Arcentales et al. (2019) and Cirillo et al.
(2020), the policy language presents a flexible policy model, which allows
various usage scenarios to be expressed, but also a fully extensible model,
which provides mechanisms to extend and/or deprecate the original model.
Regarding XACML, although the model was originally used for access control
specification, it has shown a high level of flexibility and extensibility to
support UCON components, as indicated by Colombo et al. (2010). Besides, the
framework proposed by Lazouski et al. (2012b) and the framework proposed by
Lazouski et al. (2012a) and Carniani et al. (2016) and its various extensions
presented in (Giorgi et al., 2017; Martini et al., 2020; La Marra et al.,
2019a; Costantino et al., 2018; La Marra et al., 2017a, 2019b, b; Martinelli
et al., 2019, 2016b) have underlined the degree of extensibility of XACML as
it has undergone various extensions over time in order to cater for different
types of attributes (e.g., attributes that account for different sensors in a
IoT scenario or describe the features of subjects, resources, and environment
change) and conditions (e.g., location, time, occurrence, and event-based).

####  5.2.3. Unambiguous.

Zhang et al. (2008) describe the highest level of policy (i.e., the high level
objectives of normative policies) as being informal and fuzzy, which makes it
difficult to enforce them effectively. In their work, the authors developed
their framework using the layered _policy-enforcement-implementation_ (PEI)
(Sandhu et al., 2006) methodology. PEI seeks to bridge the gap between
informal or high-level policies and the actual enforcement mechanism, thereby
undermining the ambiguity of informal usage control policies. PEI is composed
of five layers: security and system goals, policy models, enforcement models,
implementation models, and actual implementations. The first layer is
necessarily informal, while the second layer aims to take high-level informal
goals and provide concrete details using formal or quasi-formal notation. For
the authors, the UCON model presents the formal layer of their policy
language, while enforcement and implementation models are associated with the
actual code that implements the solution. The designers of the remaining
frameworks do not mention any methodology or formal ways of dealing with the
unambiguity requirement.

####  5.2.4. Formal Semantics.

Logic-based approaches that formalize the proposed policy languages were
employed by (Jung et al., 2014; Neisse et al., 2011; Wüchner and Pretschner,
2012; Wüchner et al., 2013; Weber and Silva, 2010; Feth and Pretschner, 2012;
Baldini et al., 2013; Neisse et al., 2015), which use OSL, and the ones
presented in (Cao et al., 2020; Schütte and Brost, 2018), which use defeasible
logic and first order logic, respectively. While the remaining policy
languages such as U-XACML and ODRL do not provide any formal foundations, some
works such as (Martinelli et al., 2016a; Steyskal and Polleres, 2015) propose
ways to formalize these languages.

Table 3. Usage Control Framework Components Framework |  Type |  Components
---|---|---
Bai et al. (2010) |  XACML |  PEP, PDP, PIP, PAP, evaluation engines
Baldini et al. (2013); Neisse et al. (2015) |  XACML |  PEP, PDP, context manager, role manager, policy management, graphical user interface, policy repository, policy server
Cao et al. (2020) |  custom |  identification, policy management, policy composition, data usage transparency, data usage traceability, jDUPO
Carniani et al. (2016); Lazouski et al. (2012a) |  XACML |  PEP, PIP, PDP, PAP, context handler, attribute manager, session manager
Cirillo et al. (2020) |  XACML |  policy management, PEP, graphical user interface, infrastructure services
Costantino et al. (2018) |  XACML |  PEP, PIP, PDP, PAP, context handler, usage monitor
Feth and Pretschner (2012) |  XACML |  PEP, PDP
Giorgi et al. (2017) |  XACML |  PEP, PIP, PDP, PAP, context handler, attribute manager, session manager
Jung et al. (2014) |  XACML |  PXP, PEP, PRP, PDP, PIP, PMP, PAP
Kateb et al. (2014) |  XACML |  PIP, PDP, obligation manager
Lazouski et al. (2012b) |  XACML |  PEP, PIP, PDP, PAP, context handler, usage monitor
Martini et al. (2020); La Marra et al. (2019a) |  XACML |  PEP, PIP, PDP, PAP, context handler, usage monitor
La Marra et al. (2017a) |  XACML |  PEP, PIP, PDP, PAP, context handler, usage monitor
La Marra et al. (2019b) |  XACML |  PEP, PIP, PDP, PAP, context handler, usage monitor
La Marra et al. (2017b) |  XACML |  PEP, PIP, PDP, PAP, context handler, usage monitor
Martinelli et al. (2019) |  XACML |  PEP, attribute manager, PIP, PDP, PAP, session manager, context handler, OEP, OOP, POP, ODP
Martinelli et al. (2016b) |  XACML |  PEP, PIP, PDP, PAP, context handler, usage monitor
Munoz-Arcentales et al. (2020, 2019) |  XACML |  PDP, PXP, PTP
Neisse et al. (2011) |  XACML |  policy manager, policy repository, PDP, attribute resolver, action resolver, PEP
Russello and Dulay (2009) |  XACML |  PEP, PDP, xDSpace
Schütte and Brost (2018) |  custom |  interceptor, Prolog engine
Teigão et al. (2011) |  custom |  reference monitor, usage mediator, rule parser
Weber and Silva (2010) |  custom |  policy editor, notification manager, policy monitor, control monitor, event signaler
Wüchner et al. (2013) |  XACML |  PEP, PIP, PDP
Wüchner and Pretschner (2012) |  XACML |  PEP, PIP, PDP
Xu et al. (2007) |  XACML |  enforcer, attribute repository, PDP
Zhang et al. (2008) |  XACML |  PDP, PEP, usage monitor, attribute repository

###  5.3. Enforcement

Table 4. Usage Control Enforcement Mechanisms Framework |  Preventive |  Detective |  Continuity of Enforcement |  Conflict Detection & Resolution |  Administration
---|---|---|---|---|---
Bai et al. (2010) |  permission, inhibition, revoke, delay, update |  _ |  monitor attribute and context updates, monitor obligation fulfillment |  _ |  PAP interface
Baldini et al. (2013); Neisse et al. (2015) |  permission, inhibition, revoke, delay, modification |  _ |  monitor condition updates and obligations fulfillment |  combining algorithms |  graphical user interface
Lazouski et al. (2012a); Carniani et al. (2016) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
Cao et al. (2020) |  permission, inhibition, revoke, delay |  _ |  monitor condition and context updates, monitor obligation fulfillment |  logic-based |  jDUPO
Costantino et al. (2018) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
Cirillo et al. (2020) |  permission, inhibition, execution |  execution actions |  _ |  |  graphical user interface
Feth and Pretschner (2012) |  permission, inhibition, revoke, delay, modification, execution |  execution actions |  monitor condition updates and obligations fulfillment |  _ |  Android interface
Giorgi et al. (2017) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
Jung et al. (2014) |  permission, inhibition, modification, execution, revoke |  execution actions |  monitor condition updates and obligations fulfillment |  _ |  PAP interface
Kateb et al. (2014) |  permission, inhibition, revoke, delay |  _ |  monitor obligation fulfillment |  _ |  _
Martini et al. (2020); La Marra et al. (2019a) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
Lazouski et al. (2012b) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
La Marra et al. (2017a) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
La Marra et al. (2019b) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
La Marra et al. (2017b) |  permission, inhibition, revoke, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
Martinelli et al. (2016b) |  permission, inhibition, suspend, resume, update |  _ |  monitor attribute, context, and condition updates |  _ |  PAP interface
Martinelli et al. (2019) |  permission, inhibition, revoke, delay, update |  _ |  monitor attribute, context, condition and updates, monitor obligation fulfillment |  _ |  PAP interface
Munoz-Arcentales et al. (2020, 2019) |  permission, inhibition, revoke, delay, modification |  _ |  monitor condition and obligation fulfillment |  _ |  PAP interface
Neisse et al. (2011) |  permission, inhibition, revoke, delay, modification, execution, update |  execution actions |  monitor condition and attributes updates, monitor obligations fulfillment |  _ |  _
Russello and Dulay (2009) |  permission, inhibition, revoke, delay, update |  _ |  monitor condition and context updates, monitor obligation fulfillment |  _ |  _
Schütte and Brost (2018) |  permission, inhibition, modification |  auditing |  monitor data flow |  logic-based |  Eclipse integrated development environment
Teigão et al. (2011) |  permission, inhibition, revoke, update |  _ |  monitor attribute updates |  _ |  _
Weber and Silva (2010) |  permission, inhibition, revoke, delay, modification, execution |  execution actions |  monitor condition updates and obligations fulfillment |  _ |  policy editor
Wüchner and Pretschner (2012) |  permission, inhibition, revoke, delay, modification, execution |  execution actions |  monitor condition updates and obligations fulfillment |  _ |  _
Wüchner et al. (2013) |  permission, inhibition, revoke, delay, modification, execution |  execution actions |  monitor condition updates and obligations fulfillment |  _ |  _
Xu et al. (2007) |  permission, inhibition, revoke, update |  _ |  monitor attribute updates |  _ |  LINUX command line
Zhang et al. (2008) |  permission, inhibition, revoke, update, delay |  _ |  monitor attribute updates and obligation fulfillment |  _ |  _

In Table 3, we outline the various components employed in each framework,
while in Table 4, we present a comparative overview of the predominant usage
control frameworks found in the literature. Most of the frameworks depicted in
Table 3 are XACML (Standard, 2013) reference architectures, and thus include
some or all of the following components: a _policy decision point_ (PDP) (Bai
et al., 2010; Baldini et al., 2013; Neisse et al., 2015; Carniani et al.,
2016; Lazouski et al., 2012a; Costantino et al., 2018; Feth and Pretschner,
2012; Giorgi et al., 2017; Jung et al., 2014; Kateb et al., 2014; Lazouski et
al., 2012b; Martini et al., 2020; La Marra et al., 2019a, 2017a, b, 2017b;
Martinelli et al., 2019, 2016b; Munoz-Arcentales et al., 2020, 2019; Neisse et
al., 2011; Russello and Dulay, 2009; Wüchner et al., 2013; Wüchner and
Pretschner, 2012; Xu et al., 2007; Zhang et al., 2008), a _policy enforcement
point_ (PEP) (Bai et al., 2010; Baldini et al., 2013; Neisse et al., 2015;
Carniani et al., 2016; Lazouski et al., 2012a; Cirillo et al., 2020;
Costantino et al., 2018; Feth and Pretschner, 2012; Giorgi et al., 2017; Jung
et al., 2014; Lazouski et al., 2012b; Martini et al., 2020; La Marra et al.,
2019a, 2017a, b, 2017b; Martinelli et al., 2019, 2016b; Neisse et al., 2011;
Russello and Dulay, 2009; Wüchner et al., 2013; Wüchner and Pretschner, 2012;
Zhang et al., 2008), a _policy information point_ (PIP) (Bai et al., 2010;
Carniani et al., 2016; Lazouski et al., 2012a; Costantino et al., 2018; Giorgi
et al., 2017; Jung et al., 2014; Kateb et al., 2014; Lazouski et al., 2012b;
Martini et al., 2020; La Marra et al., 2019a, 2017a, b, 2017b; Martinelli et
al., 2019, 2016b; Wüchner et al., 2013; Wüchner and Pretschner, 2012), a
_policy execution point_ (PXP) (Jung et al., 2014; Munoz-Arcentales et al.,
2020, 2019), a _policy administration point_ (PAP) (Bai et al., 2010; Carniani
et al., 2016; Lazouski et al., 2012a; Costantino et al., 2018; Giorgi et al.,
2017; Jung et al., 2014; Lazouski et al., 2012b; Martini et al., 2020; La
Marra et al., 2019a, 2017a, b, 2017b; Martinelli et al., 2019, 2016b), a
_policy retrieval point_ (PRP) (Jung et al., 2014), a _policy management
point_ (PMP) (Jung et al., 2014), and/or a _policy translation point_ (PTP)
(Munoz-Arcentales et al., 2020, 2019). Although the vast majority of
frameworks introduce usage control extensions for XACML, some frameworks (Cao
et al., 2020; Schütte and Brost, 2018; Teigão et al., 2011; Weber and Silva,
2010) also introduce novel enforcement mechanisms.

Various extensions of XACML include components for the continuous evaluation
and the enforcement of usage control policies. Existing proposals include a
variety of new components that are responsible for managing and evaluating
policy attributes, namely an _attribute manager_ (Carniani et al., 2016;
Lazouski et al., 2012a; Giorgi et al., 2017; Martinelli et al., 2019), a
_session manager_ (Martinelli et al., 2019; Carniani et al., 2016; Lazouski et
al., 2012a; Giorgi et al., 2017), a _usage monitor_ (Costantino et al., 2018;
Lazouski et al., 2012b; Martini et al., 2020; La Marra et al., 2019a, 2017a,
b, 2017b; Martinelli et al., 2016b; Zhang et al., 2008), an _attribute
repository_ (Xu et al., 2007; Zhang et al., 2008), a _role manager_ (Baldini
et al., 2013; Neisse et al., 2015), and an _evaluation engine_ (Bai et al.,
2010). Additionally, there are various proposals for managing and evaluating
policy obligations via an _obligation manager_ (Kateb et al., 2014), an
_evaluation engine_ (Bai et al., 2010), a _session manager_ (Martinelli et
al., 2019; Carniani et al., 2016; Lazouski et al., 2012a; Giorgi et al.,
2017), an _action resolver_ (Neisse et al., 2011), an _obligation enforcement
point_ (OEP) (Martinelli et al., 2019), an _obligation observation point_
(OOP) (Martinelli et al., 2019), and a _policy obligation point_ (POP)
(Martinelli et al., 2019). When it comes to managing contextual information,
extensions include a _context handler_ (Carniani et al., 2016; Lazouski et
al., 2012a; Costantino et al., 2018; Giorgi et al., 2017; Lazouski et al.,
2012b; Martini et al., 2020; La Marra et al., 2019a, 2017a, b, 2017b;
Martinelli et al., 2019, 2016b), a _context manager_ (Baldini et al., 2013;
Neisse et al., 2015), a _session manager_ (Martinelli et al., 2019; Carniani
et al., 2016; Lazouski et al., 2012a; Giorgi et al., 2017), and an _evaluation
engine_ (Bai et al., 2010). Whereas, _policy management_ (Baldini et al.,
2013; Neisse et al., 2015; Cao et al., 2020; Cirillo et al., 2020), _policy
manager_ (Neisse et al., 2011), and _policy repository_ (Neisse et al., 2011;
Baldini et al., 2013; Neisse et al., 2015) components have been proposed in
order to support the management of usage control policies. Finally, there are
a number of suggestions for managing the communication between various
components, including an _infrastructure service_ (Cirillo et al., 2020) that
can be used as a means to develop trust and a _shared data space_ (xDSpace)
(Russello and Dulay, 2009) that can be used as a tool for coordinating the
execution of distributed applications.

When it comes to the novel frameworks, various architectural designs are
motivated by different aims and requirements. For instance, the _trustworthy
data sharing platform_ (Cao et al., 2020) includes five predominant features:
_identification_ , _policy management_ (visualization tool), _policy
composition_ , _data usage transparency_ , and _data usage traceability_. The
framework proposed by Schütte and Brost (2018) uses a _Prolog engine_ as a PEP
and an _interceptor for events_ as a PDP. The enforcement architecture
proposed by Teigão et al. (2011) is based on three main components: a
_reference monitor_ that acts as a PDP, a _usage mediator_ that acts as a PEP,
and a _LALR rule parser_ that translates the rules expressed by the LALR
grammar into an internal representation, which is used by the _reference
monitor_. The framework proposed by Weber and Silva (2010) includes a _control
monitor_ and a _policy monitor_ that together act as a PDP, an _event
signaler_ that acts as a PEP, and a _notification manager_ that sends
notifications to the _control monitor_ in the case of violations.

####  5.3.1. Preventive.

The preventive mechanisms of a variety of frameworks are provided by the
enforcement points. With the exception of the frameworks described in
(Martinelli et al., 2016b), (Cirillo et al., 2020) and (Schütte and Brost,
2018), each of the frameworks can enforce: _permissions_ , _prohibitions_ ,
and _revocations_. These classes of enforcement are responsible for enforcing
usage decisions by allowing, denying access to or usage of a resource, and
revoking access in the case of policy violations. While, the _suspend_ and
_resume_ framework proposed by Martinelli et al. (2016b) allows access to be
resumed after suspension by the system as a result of an ongoing-evaluation.
The frameworks proposed in (Cirillo et al., 2020) and (Schütte and Brost,
2018) do not allow access to data to be revoked. Another class of enforcement
is _modification_. The frameworks presented in (Jung et al., 2014; Schütte and
Brost, 2018; Munoz-Arcentales et al., 2020, 2019; Neisse et al., 2011; Wüchner
and Pretschner, 2012; Wüchner et al., 2013; Weber and Silva, 2010; Feth and
Pretschner, 2012; Baldini et al., 2013; Neisse et al., 2015) modify certain
data values after access is granted in order to allow the user to use the data
while ensuring privacy protection and policy compliance. Only a few frameworks
(Neisse et al., 2011; Wüchner and Pretschner, 2012; Wüchner et al., 2013;
Weber and Silva, 2010; Feth and Pretschner, 2012; Jung et al., 2014; Cirillo
et al., 2020) cater for the _execution_ of actions or non-usage actions that
trigger required actions to be performed (e.g., sending a notification,
triggering a payment, or writing in logs). Cirillo et al. (2020) state that
their framework enforces three main types of actions, namely, anonymization of
the data before use by the data consumer; making sure that the data never
leave the providers domain; and deleting traces of data usage (e.g., search
results) in the data consumers domain-memory. The frameworks proposed in (Cao
et al., 2020; Bai et al., 2010; Zhang et al., 2008; Martinelli et al., 2019;
Munoz-Arcentales et al., 2020, 2019; Kateb et al., 2014; Russello and Dulay,
2009; Baldini et al., 2013; Neisse et al., 2015) provide mechanisms that allow
for the enforcement of obligation fulfillment, which is usually referred to as
a _delay_ class of enforcement, as the framework delays the access to or the
usage of a resource until users perform certain obligations, which in turn
trigger the re-evaluation of the relevant policies. The framework proposed by
Zhang et al. (2008) only enforces pre-obligations, whereas the rest can
enforce pre-obligations, on-obligations, and post-obligations. The frameworks
presented in (Lazouski et al., 2012b, a; Carniani et al., 2016; Giorgi et al.,
2017; Martini et al., 2020; La Marra et al., 2019a; Costantino et al., 2018;
La Marra et al., 2017a, 2019b, b; Bai et al., 2010; Schütte and Brost, 2018;
Xu et al., 2007; Martinelli et al., 2016b) only consider XACML-type
obligations that are handled internally. While, the framework presented in
(Teigão et al., 2011) considers obligations as external to the decision system
and thus said obligations are managed by external routines. The various
frameworks that are based on the UCON model (Lazouski et al., 2012b, a;
Carniani et al., 2016; Giorgi et al., 2017; Martini et al., 2020; La Marra et
al., 2019a; Costantino et al., 2018; La Marra et al., 2017a, 2019b, b; Bai et
al., 2010; Zhang et al., 2008; Martinelli et al., 2016b, 2019; Teigão et al.,
2011; Xu et al., 2007) and the frameworks proposed by Russello and Dulay
(2009) and Neisse et al. (2011) consider attribute _updates_ as a mechanism to
trigger the re-evaluation of policies. Zhang et al. (2008) support dynamic
resource attributes (e.g., virtual machine storage and network bandwidth) that
can affect the usage of data in the context of collaborative computing
systems.

####  5.3.2. Detective.

In addition to providing preventive mechanisms, the frameworks presented in
(Jung et al., 2014; Schütte and Brost, 2018; Neisse et al., 2011; Wüchner and
Pretschner, 2012; Wüchner et al., 2013; Weber and Silva, 2010; Feth and
Pretschner, 2012; Cirillo et al., 2020) also include detective mechanisms. The
detective mechanisms proposed by Jung et al. (2014), Neisse et al. (2011),
Wüchner and Pretschner (2012), Wüchner et al. (2013), Weber and Silva (2010),
and Feth and Pretschner (2012) allow for the enforcement of actions performed
by the PXP, the PEP, or the _event signaler_. According to Pretschner et al.
(2006), execution actions are actions that typically involve internal
interactions between system components. Feth and Pretschner (2012) group
execution actions into four main types: logging; notifying a user; starting an
activity; and faking information (e.g., a location). In turn, Cirillo et al.
(2020) enforce actions such as anonymizing data and deleting traces of data.
While, Schütte and Brost (2018) define detective enforcement as a statistic
type of enforcement that acts as a formal audit support system, which provides
evidence in the event of a policy violation or is used to manage policy
conflicts.

####  5.3.3. Continuity of Enforcement.

Continuity of enforcement involves re-evaluating a policy in order to test if
the subject still complies with the policy rules and checking the validity of
the continuous usage of an object, for instance checking for updates to
attributes, context, or conditions and/or the fulfillment of obligations. Most
of the usage control frameworks address one or more of the following factors:
(i) monitoring attribute updates;  (ii) evaluating the fulfillment of
obligations  (iii) evaluating changes to environmental conditions, system
conditions and/or contextual information.  Depending on the specific
framework, continuity of enforcement triggers the re-evaluation of a policy
by: a PDP, a _Prolog engine_ , an _evaluation engine_ , a _reference monitor_
, a _control monitor_ , or a _data usage transparency_ component. In cases
where the framework supports the mutability of attributes, some components are
used to observe and store attribute updates during an ongoing usage process.
For instance, the frameworks presented in (Lazouski et al., 2012b, a; Carniani
et al., 2016; Giorgi et al., 2017; Martini et al., 2020; La Marra et al.,
2019a; Costantino et al., 2018; La Marra et al., 2017a, 2019b, b; Bai et al.,
2010; Martinelli et al., 2016b, 2019) employ a _usage monitor_ or a _session
manager_ , the framework proposed by Zhang et al. (2008) uses an _attribute
repository_ , whereas the framework proposed by Bai et al. (2010) utilises an
_evaluation engine_. The remaining frameworks use a dedicated continuity of
enforcement component in order to monitor updates to policy conditions and
contextual information, as well as the fulfillment of obligations. While, the
framework proposed by Schütte and Brost (2018) continuously monitors data flow
by observing and controlling security breaches using a _Prolog engine_ and
_data flow tracking tools_ (DFT). The framework proposed by Cirillo et al.
(2020) performs _policy matching_ of data consumer requests against data
provider policies before allowing users to access the data. Although this
framework does not apply continuous monitoring of data usage after access is
granted, it does provide preventive execution actions performed via
_infrastructure services_ , such as anonymizing data or orchestrating services
that prevent users from performing certain actions on the data.

####  5.3.4. Conflict Detection & Resolution.

A handful of papers (Cao et al., 2020; Schütte and Brost, 2018; Baldini et
al., 2013; Neisse et al., 2015) specifically mention conflict detection and
resolution. The _data usage transparency_ component proposed by Cao et al.
(2020) employs a defeasible reasoning engine that can detect and resolve
conflicts that arise from usage control policies. However, the authors do not
elaborate on the specific conflict resolution strategies that they employ. In
the case of the LUCON framework (Schütte and Brost, 2018), policies are
compiled into Prolog programs. The authors highlight the importance of the
employed logic based formalism as it allows for reasoning over policies in
order to detect conflicting or incomplete rules. However, here again, the
authors do not specify any conflict resolution strategies. In turn, the
frameworks proposed by Baldini et al. (2013) and Neisse et al. (2015) uses
XACML combining algorithms (Huonder, 2010), such as _permit-overrides_ ,
_deny-overrides_ , or _first-applicable_ algorithms, in order to reach a
decision when multiple rules return conflicting responses.

####  5.3.5. Administration.

Interfaces that allow users to create and manage their usage control policies,
modelled on XACML _policy administration points_ , are proposed by (Lazouski
et al., 2012b, a; Carniani et al., 2016; Giorgi et al., 2017; Martini et al.,
2020; La Marra et al., 2019a; Costantino et al., 2018; La Marra et al., 2017a,
2019b, b; Jung et al., 2014; Bai et al., 2010; Martinelli et al., 2016b, 2019;
Munoz-Arcentales et al., 2020, 2019). Other frameworks propose _graphical user
interfaces_ (GUI) (Cao et al., 2020; Baldini et al., 2013; Neisse et al.,
2015; Cirillo et al., 2020), simple policy editors (Weber and Silva, 2010),
rely on operating system command line interfaces (Feth and Pretschner, 2012;
Xu et al., 2007), or leverage editors that are built into development
environments (Schütte and Brost, 2018).

###  5.4. Robustness

Table 5. Robustness of Usage Control Mechanisms |  |  |  | Reliability
---|---|---|---|---
Framework |  Performance & Scalability |  Interoperability & Compatibility |  Usability |  Transparency |  System Reliability
Bai et al. (2010) |  performance metrics comparison |  XML |  _ |  _ |  _
Baldini et al. (2013); Neisse et al. (2015) |  performance metrics |  XML |  use of templates |  trust |  support for trust management
Cao et al. (2020) |  performance metrics |  XML REST APIs |  technical expertise required |  explanations provenance |  _
Lazouski et al. (2012a); Carniani et al. (2016) |  performance metrics |  XML |  _ |  _ |  _
Costantino et al. (2018) |  performance metrics |  XML |  _ |  _ |  _
Cirillo et al. (2020) |  performance metrics |  XML |  _ |  audit provenance |  decentralized policy enforcement
Feth and Pretschner (2012) |  performance metrics other evaluation metrics |  XML |  _ |  trust |  _
Giorgi et al. (2017) |  performance metrics |  XML |  _ |  _ |  _
Jung et al. (2014) |  _ |  XML |  technical expertise required |  audit |  _
Kateb et al. (2014) |  _ |  XML |  _ |  _ |  _
Lazouski et al. (2012b) |  performance metrics |  XML |  _ |  _ |  _
Martini et al. (2020); La Marra et al. (2019a) |  performance metrics |  XML |  _ |  _ |  _
La Marra et al. (2017a) |  performance metrics |  XML |  _ |  _ |  _
La Marra et al. (2019b) |  performance metrics |  XML |  _ |  _ |  _
La Marra et al. (2017b) |  performance metrics |  XML |  _ |  _ |  _
Martinelli et al. (2016b) |  _ |  XML |  _ |  _ |  _
Martinelli et al. (2019) |  _ |  XML |  _ |  _ |  _
Munoz-Arcentales et al. (2020, 2019) |  performance metrics |  XML |  _ |  trust |  trusted technology stack
Neisse et al. (2011) |  performance metrics |  XML |  _ |  trust |  _
Russello and Dulay (2009) |  _ |  _ |  _ |  audit |  _
Schütte and Brost (2018) |  performance metrics |  Java |  technical expertise required |  explanations audit |  _
Teigão et al. (2011) |  performance metrics |  _ |  _ |  _ |  _
Wüchner and Pretschner (2012) |  performance metrics other evaluation metrics |  XML |  _ |  trust |  reduced system complexity
Wüchner et al. (2013) |  performance metrics other evaluation metrics |  XML |  _ |  trust |  _
Weber and Silva (2010) |  performance metrics |  XML |  _ |  audit trust |  _
Xu et al. (2007) |  _ |  XML |  _ |  _ |  _
Zhang et al. (2008) |  performance metrics |  XML |  _ |  _ |  _

Usage control robustness is an all-encompassing term used to refer to
performance, scalability, interoperability, compatability, usability,
transparency, and reliability. In the following, we elaborate on the various
robustness mechanisms employed by the usage control frameworks that are
summarized in Table 5.

####  5.4.1. Performance & Scalability.

The framework adopted by Lazouski et al. (2012a) and Carniani et al. (2016)
was originally employed in a cloud computing setting. In order to validate the
original proposal, different extended versions of the same framework are
evaluated in various use cases, such as, enforcing parental control using
Smart TVS (Giorgi et al., 2017); enhancing the security of Fifth Generation
(5G) network systems (Martini et al., 2020; La Marra et al., 2019a); enforcing
data protecting in industrial IoT settings, namely, collaborative smart
services (Costantino et al., 2018), smart homes (La Marra et al., 2017a),
general-purpose IoT architectures (La Marra et al., 2019b), and securing
communications between IoT devices (La Marra et al., 2017b). Moreover, another
extension is mentioned in (Martinelli et al., 2019) without any details on the
physical implementation or performance. Finally, the framework was used in a
mobile computing context (Martinelli et al., 2016b), however, the authors do
not provide any evaluation details. The frameworks presented in (Cao et al.,
2020; Schütte and Brost, 2018; Bai et al., 2010; Zhang et al., 2008; Lazouski
et al., 2012b; Munoz-Arcentales et al., 2020, 2019; Cirillo et al., 2020;
Teigão et al., 2011; Baldini et al., 2013; Neisse et al., 2015, 2011; Weber
and Silva, 2010; Feth and Pretschner, 2012; Wüchner and Pretschner, 2012;
Wüchner et al., 2013) are evaluated using various performance metrics, such as
_the time needed to evaluate a policy decision request_ ; _memory usage_ ; or
_the time needed to enforce a policy decision_. While, the frameworks
presented in (Cao et al., 2020; Munoz-Arcentales et al., 2020, 2019; Cirillo
et al., 2020; Baldini et al., 2013; Neisse et al., 2015) are validated using
different uses cases in the context of industry 4.0, particularly, for easing
and ensuring secure data sharing in ecosystems, such as smart cities. Only the
framework proposed by Bai et al. (2010) is evaluated in comparison to other
usage control proposals. The authors compared the execution time of ConUCON to
an existing security mechanism based on common actions that a user would
perform on their phone. In addition to using performance metrics to evaluate
their approaches, the frameworks proposed by Feth and Pretschner (2012),
Wüchner and Pretschner (2012), and Wüchner et al. (2013) employ others
measures that are relevant from a security perspective (e.g., analyzing
attacker models and evaluating security countermeasures).

####  5.4.2. Interoperability & Compatibility.

Most frameworks encode their policies using XML due to its strong
interoperability capability. Additionally, Cao et al. (2020) have designed
their framework components as an Application Programming Interface (API) in
order to support the interoperability of shared services between data
consumers and data providers that do not belong to the same domain. Although,
the authors highlight the fact that semantic technologies could be used to
facilitate exchange between users, they do not leverage semantic technologies
in their framework. In turn, Schütte and Brost (2018) adopt the Java
programming language, which supports different protocol adapters that are
particularly suitable for IoT scenarios where data from different sources must
be unified. Hence, the authors implemented their PEP using Apache Camel, which
supports more than 240 protocols (e.g., Hypertext Transfer Protocol (HTTP), MQ
Telemetry Transport (MQTT), etc.).

####  5.4.3. Usability.

The frameworks presented in (Bai et al., 2010; Martinelli et al., 2016b;
Lazouski et al., 2012b; Giorgi et al., 2017; Costantino et al., 2018; La Marra
et al., 2017a, 2019b; Martinelli et al., 2019; Munoz-Arcentales et al., 2020,
2019; Cirillo et al., 2020) do not discuss the usability of either their
policy languages or their user interfaces. Whereas, Feth and Pretschner (2012)
mention that the usability of a policy language is always a concern. On the
one hand, the expressiveness of a language can reflect the real use cases of
usage control policies. On the other hand, the correct and adequate use of
complex policies is hard for non-expert users. The authors of the framework
proposed by Teigão et al. (2011) claim that their policy language is an easy-
to-use and well-defined language, but they do not provide any evaluation of
the usability of their prototype. Cao et al. (2020) provide an interface
whereby users need to have basic knowledge with respect to defeasible logic in
order to manage policies. The GUI proposed by (Baldini et al., 2013; Neisse et
al., 2015) simplifies personal data management by providing a variety of
policy templates that can be employed by users. Additionally, although the
authors of the LUCON framework (Schütte and Brost, 2018) claim that their
language is easy to understand, users need to be familiar with the UCON DSL
grammar in order to write policies. The interface proposed by Jung et al.
(2014) can only be used by experts that know the various events and system
actions that can be used within the policy description. However, the authors
mentioned that they are researching approaches on how to build user-friendly
specification interfaces that allow even unskilled users to specify their
security demands. They also indicated that the use of different usability
patterns that include different user groups with varying skill levels and
expertise will be further studied.

####  5.4.4. Reliability.

The reliability of the usage control framework is highly dependent on
different mechanisms employed in order to ensure the transparency and
reliability of the system.

##### Transparency.

As depicted in Figure 4, transparency can be established through four
dimensions. The first dimension for ensuring transparency is the use of
auditing tools. Several authors (Jung et al., 2014; Schütte and Brost, 2018;
Cirillo et al., 2020; Neisse et al., 2011; Wüchner and Pretschner, 2012;
Wüchner et al., 2013; Weber and Silva, 2010; Feth and Pretschner, 2012;
Russello and Dulay, 2009) have emphasized the importance of using auditing
mechanisms by including logging tools in their frameworks in order to provide
evidence that users are using the data according to agreed policies, but also
to track violations that usage control solutions are not able to detect (i.e.,
uncontrollable policies). The second dimension relates to data provenance. Cao
et al. (2020) designed the _data usage traceability_ component based on
defeasible logic for the purpose of tracing data usage history, whereas
Cirillo et al. (2020) made use of blockchain technologies in order to ensure
traceability of data usage. The third dimension concerns explanations. Only
two frameworks (Cao et al., 2020; Schütte and Brost, 2018) provide proofs to
justify the decisions of the system using inference engines based on
defeasible and first order logics, respectively. Providing explanations of how
the decision of either granting, denying, or revoking access was reached can
help users to trust the decisions of the framework, but also support policy
authors in fixing issues. The last dimension concerns trust. According to Cao
et al. (2020), one important aspect of building trust is for the data owner to
be able to exercise control over the usage of the data by other actors. Munoz-
Arcentales et al. (2020, 2019) highlight the importance of using reliable and
transparent usage control mechanisms in order for trust to be fully ensured.
The frameworks presented in (Neisse et al., 2011; Wüchner and Pretschner,
2012; Wüchner et al., 2013; Weber and Silva, 2010; Feth and Pretschner, 2012)
employ _trusted computing technologies_ , which enhance usage control
mechanisms through the inclusion of hardware-based trust components. Whereas,
the reference architecture presented in (Munoz-Arcentales et al., 2020, 2019)
relies on _international data space_ (IDS) (Otto et al., 2018) connectors,
which ensure that all the connectors or mechanisms involved in a data exchange
run on top of a certified software stack. This is done through the IDS
certification body that provides certifications for the connectors in order to
establish trust among all participants. The framework presented in (Baldini et
al., 2013; Neisse et al., 2015) includes trust management by modelling trust
relationships and recommendations using the Seckit policy language.

##### System Reliability.

The level of reliability depends on the ability of usage control solutions to
guarantee that usage control policies are enforced correctly. Baldini et al.
(2013) and Neisse et al. (2015) relate the reliability of their usage control
framework to the support for trust management that can ensure reliable and
trusted relationships between architectural components and users. Cirillo et
al. (2020) mention that their choice of decentralized enforcement of policies
improves the reliability of their framework by ensuring a good orchestration
and synchronization between the system components. The framework proposed by
Munoz-Arcentales et al. (2020, 2019) relies on IDS trusted connectors, which
guarantee a reliable environment that enables usage control. Wüchner and
Pretschner (2012) claim that the reduction in complexity of their system
compared to other usage control systems increases the reliability of their
usage control framework. In turn, Russello and Dulay (2009) highlight the
importance of adopting robust and reliable usage control frameworks. Although
the authors do not consider or assess the reliability of their proposed
framework, they do stress the importance of employing mechanisms that can
protect usage control policies from unauthorized access, especially in
distributed environments.

##  6\. Discussion

In this section, we use the insights gained from our detailed usage control
framework analysis in order to highlight open challenges and opportunities for
the usage control domain in general and decentralized systems in particular.

###  6.1. Gaps Analysis

In the following, we identify open challenges and opportunities for the usage
control domain, which we categorize under the headings: generality of
policies; automated formal analysis, usability, verification and validation;
and benchmarking.

####  6.1.1. Generality of Policies.

The majority of frameworks rely on specific policy languages that were
developed according to domain-specific requirements in relation to _Mobile,
Cloud, IoT, and Industry 4.0._ (e.g., DUPO (Cao et al., 2020) and U-XACML
(Colombo et al., 2010)) and _networking, operating systems, and collaborative
software_ (e.g., LUCON (Schütte and Brost, 2018) and UCONKI (Xu et al.,
2007)). While, the policy languages that are meant to be _domain-agnostic_ are
either not validated using use cases (e.g, OB-XACML (Kateb et al., 2014)) or
are only evaluated in a specific domain (e.g., IND2UCE (Jung et al., 2014) and
(Weber and Silva, 2010)). Hence, it is unclear if the existing proposals could
be used for usage control in the general sense, where a single system may need
to support privacy preferences, regulatory requirements, licenses, etc. Given
that usage control policies require both domain and application specific
information, semantic technologies could potentially be used to develop a
common policy model that provides support for different types of usage control
policies. Semantic technologies are particularly suitable for the
specification of policies, as ontologies and vocabularies can be used to
formalize both policy concepts and rules in an extensible manner. In their
privacy and data protection survey, Esteves and Rodríguez-Doncel (2021)
examine various policy languages that leverage semantic technologies, such as
ODRL (working group, 2018), the _data privacy vocabularies_ (DPV) (Bonatti et
al., 2018), GDPRtExt (Pandit et al., 2018), and the SPECIAL _policy language_
(SPL). In another survey, Pellegrini et al. (2018) discuss how semantic
technology based policy languages can be used to express DRM restrictions.
Among the most prominent vocabularies are MPEG-21444MPEG-21,
https://mpeg.chiariglione.org/standards/mpeg-21, ODRL, the _creative commons
rights expression language_ (ccREL)555ccREL,
https://www.w3.org/Submission/ccREL/, and XACML, to name but a few. However,
here also, it is unclear if the existing proposals are suitable for a system
that needs to consider a variety of different usage control policies.

####  6.1.2. Automated Formal Analysis.

The majority of existing usage control frameworks do not include a reasoning
engine that could be used to automatically enforce usage control policies.
This is usually due to the fact that their policy languages lack underlying
formal semantics. According to Han and Lei (2012), formal approaches for
describing policy languages facilitate automated analysis, policy
verification, and explanations that can help manage the behavior of a system.
For instance, automatic formal analysis could help to continuously verify
compliance using usage policies, audit trails, and shared data. While, policy
verification could be used to manage conflicting policies and to ensure policy
consistency. Growing dynamic environments, such as the web or IoT-based data
sharing systems, where new users continuously join, pose new challenges in
terms of unpredictability and dynamicity (Dautov et al., 2017). When it comes
to automated policy analysis, the W3C community
group666https://w3c.github.io/odrl/formal-semantics/ is working on a formal
semantics for the ODRL standard, which could potentially be used to facilitate
the automated analysis needed to cater for system unpredictability and
dynamicity. Unfortunately, the provision of a usage control framework, which
provides a blueprint for the development of an architecture that leverages
said formal semantics, is outside of the remit of the ODRL community group.

####  6.1.3. Usability.

Based on our analysis of various usage control frameworks according to
application domain, we observe that the operating systems, collaborative
computer systems, and network security domains do not focus on the usability
of the interfaces that they provide. That being said, generally speaking
usability is a consideration when it comes to mobile computing and Industry
4.0 as these areas attempt to empower users to manage their own data and how
it is used by data consumers. Since the entry into force of the GDPR in 2018,
significant changes have been observed in the way personal data are processed
and the rights afforded to data subjects. The empowerment of users implies
facilitating user awareness via tools that enable users to:  (i) give their
consent for personal data processing;  (ii) provide preferences concerning how
their data should be handled;  (iii) benefit from data processing transparency
(iv) profit from explainable policy decisions . For this, administration
interfaces must be user-centered and user-friendly, thus enabling the user to
understand their rights while at the same time guiding them in the protection
of their data. In the case of the frameworks examined herein, most of them do
not mention usability and/or human-computer interaction (HCI) as important
design considerations. There is a broad body of literature that could
potentially be used to enhance the usability of existing usage control
systems. For instance, Mazumder and Das (2014) propose usability principles
that enable designers to consider the usability of a system early in the
development cycle. Whereas, different works from privacy/legal researchers,
such as (Milosevic et al., 2002; Drozd and Kirrane, 2020), could potentially
be used to guide both usage control solution design and evaluation.

####  6.1.4. Verification and Validation.

Usage control policy-based frameworks are intended to protect data from
malicious use and prevent unwanted operations such as the sharing data with
untrusted third parties. Usage control policies are usually based on high-
level goals provided by data providers/owners that are then translated into
machine-readable policies. The success of a usage control system relies
heavily on the absence of discrepancies between policy specification and their
intended high-level goals. A major drawback observed after comparing the
various usage control frameworks is the lack of verification and validation
tools that can be used to assess the accuracy and the correctness of the
proposed usage control mechanisms. When it comes to the broader verification
and validation literature, there are a number of possible techniques, such as
those examined by Karafili et al. (2017), which have already been successfully
applied to systems that employ _model checking_ , _algebraic solutions_ ,
_abductive reasoning_ , _answer set programming solvers_.

####  6.1.5. Benchmarking.

As for evaluating the effectiveness of the various usage control solutions,
the authors propose different evaluation schemes, which makes it difficult to
compare the various proposals against one another. For example, in (Zhang et
al., 2008) the execution time metric is calculated based on the time required
to update policy attributes, to interpret the policy rules, and to communicate
with other components; whereas in (Bai et al., 2010) the metric depends on the
type of actions performed by the users and the time needed to perform
obligations and retrieve contextual or attribute information. Consequently,
there is a need to develop a usage control benchmark that defines standardized
characteristics, such as performance, scalability, etc. In their work, von
Kistowski et al. (2015) give important insights on how to build standardized
benchmarks based on a set of quality criteria. The authors cite _relevance_ ,
_reproducibility_ , _fairness_ , _verifiability_ , and _usability_ as key
characteristics needed to build a benchmark. In our case, _relevance_ implies
choosing suitable and applicable characteristics for comparing different usage
control frameworks. Based on our comparative analysis, we have already
observed some common metrics for evaluating usage control frameworks, for
instance, the time to process usage control policies and the memory usage
needed to process policies. The remaining features imply that the benchmark is
capable of:  (i) reproducing similar results when the same test configuration
is used;  (ii) ensuring fair competition with other benchmarking tools;  (iii)
producing reliable and accurate results  (iv) providing user-friendly tools
that facilitate the execution of comparison experiments  .

###  6.2. Decentralized Usage Control

Decentralized IoT-based use case scenarios, such as the motivating scenario
which we introduced in Section 2, bring an additional set of considerations
from a usage control perspective. Thus, we end our analysis with a discussion
of the various usage control challenges and opportunities that have been
derived from our motivating use case scenario.

####  6.2.1. Data sharing and Lack of Control.

Once data are shared or accessed, they will move outside the premises of the
data provider and therefore out of their control. For instance, users of the
data sharing platform in our IoT-based scenario, will no longer be able to
control what happens to their data after they give their consent for
stakeholders to use this data. Besides, different copies and derivations of
the same data can be shared across the network, which makes it difficult to
control how data are used (Wüchner and Pretschner, 2012; Feth and Pretschner,
2012). When it comes to the literature with respect to increasing control over
data usage, proposals either involve employing _information flow tracking
tools_ or using _sticky policies_ (Hu et al., 2021; Demir et al., 2016;
Miorandi et al., 2020).

##### Information Flow Tracking Tools.

Dynamic _information flow tracking_ (IFT) involves the tagging and tracking of
data as they propagate across network systems (Hu et al., 2021). In
distributed usage control, IFT is deemed complementary to policy enforcement,
as it allows for the protection of the different data derivations shared
across system nodes in a distributed environment (Kelbert and Pretschner,
2015; Wüchner and Pretschner, 2012; Feth and Pretschner, 2012; Pretschner et
al., 2012; Kelbert and Pretschner, 2018). IFT tools are often tailored for
scenarios such as the web (Janic et al., 2013; Gomi, 2010; Yu et al., 2017)
and the cloud (Kunz et al., 2020; Fromm and Stepa, 2017; Pappas et al., 2013),
among others, in order to cater for different aspects of data usage control,
namely privacy preservation, regulatory compliance, and sensitive information
protection. Generally speaking, IFT tools are either hardware-based or
software-based. According to Hu et al. (2021), most of the hardware IFT
solutions can be vulnerable to security threats and are complex to debug.
While, Demir et al. (2016) point out that most IFT software solutions come
with low security guarantees and high programmability impacts, which increases
the reluctance to use such techniques.

##### Sticky Policies.

Sticky policies represent restrictions on the use of data, which are directly
attached to the corresponding data. Interest in sticky policies has increased
with the emergence of new distributed technologies (Miorandi et al., 2020). By
using sticky policies in a decentralized environment, data consumers could
potentially ensure that their usage policies are enforced after data are
transferred from one system to another. In their survey, Miorandi et al.
(2020) compare and contrast sticky policy solutions for the cloud, the IoT,
and context-aware applications, among others. Additionally, the authors
outline several approaches for sticky policies, such as, encryption (e.g.,
public-Key encryption (PKE), identity-based encryption (IBE), and attribute-
based encryption (ABE)), sticky policy languages (e.g., the enterprise privacy
authorization language (EPAL) and the PrimeLife privacy policy language
(PPL)), and sticky policy for access control (e.g., the purpose-aware role
based access control (PuRBAC) model). They also provide a list of challenges
that still need to be addressed before sticky policies can be adopted. For
instance, the need for robust encryption techniques; the standardization of an
expressive sticky policy language; and the adoption of mechanisms that are
able to distribute and synchronize policies across decentralized systems in a
controllable and secure way.

####  6.2.2. Distributed Trust Management.

A distributed environment can be composed of heterogeneous entities and
systems that interact with each other, which brings about trust issues in
relation to _dependability_ , _security_ , and _reliability_ (ahmed et al.,
2019). Accordingly, in our IoT scenario, smart objects (e.g., sensors, phones,
cars, and services) and entities (e.g, the marketing company, users, and
manufacturers) can be of different forms and types, hence, the interaction
between the different entities and devices should be trusted in order to
ensure secure and reliable infrastructure. In their survey, Artz and Gil
(2007) compare and contrast different approaches for trust management in
computer science, namely, policy-based trust, reputation-based trust, and
general models of trust that could serve as interesting starting points. The
establishment of trust can be facilitated via the use of trust negotiation
solutions that are based on enforcing trust policies and/or the exchange of
security credentials, among others. Different semantic languages have already
built-in mechanisms for trust negotiation. For instance, the _web services
security_ (WS-Security) policy777WS-Policy, https://www.w3.org/Submission/WS-
Policy/, a standard introduced by the W3C, in order to provide ways to attach
signatures and encryption headers or security tokens during communication
between system nodes, or the PeerTrust language (Nejdl et al., 2004) that
involves automated trust negotiation. The exchange of credentials implies the
presence of an _authority_ that can verify the provided credentials. An
example is the _international data space_ (IDS) (Otto et al., 2018) initiative
that specifies that all parties involved in data exchange need to use IDS
certifications issued by the IDS certification body, which is a trusted third
party. Another example concerns the use of blockchain smart contracts, where
there is no need for a third party to verify identities. Smart contracts are
very relevant in fields such as the IoT, where different parties are involved
in data exchange, as they can be used to facilitate trusted and reliable
transactions (Magazzeni et al., 2017). Several proposals that employ smart
contracts in order to establish trust have already been proposed (cf., (Wu and
Liang, 2021; Esposito et al., 2020; Kouicem et al., 2020; Singh et al.,
2021)). When it comes to other approaches to trust management, reputation-
based trust can be used to assess trust relationships, while general models of
trust involve trust properties and relationships from different domains with
different resources (Miorandi et al., 2020). That being said, distributed
applications impose challenges, such as the need for scalable trust management
solutions that support an increasing number of nodes; the importance of
considering different types of reputation metrics that vary from one domain to
another; and the automation of trust management using trust policies.

####  6.2.3. Distributed Enforcement.

In a usage control scenario, two main entities are always present: _the data
provider_ and _the data consumer_. In our IoT use case, the data consumer and
data provider roles may be interchangeable, as a data consumer may be a data
provider, and vice versa. For example, manufacturers can be data consumers of
residents’ data. However, they can also be providers of residents’ data to
other stakeholders, such as the marketing companies. Hence, a distributed
system must not only enforce usage control policies on data leaving the
providers domain, but also control the usage to resources or data in the
consumers domain.

##### Policy Enforcement Point and Policy Decision Point.

Using IFT to track data or sticky policies to enforce usage policies, or a
combination of both, requires techniques that are capable of ensuring that
policies and data usage are always observed and enforced in a decentralized
environment. Kelbert and Pretschner (2015) and Cirillo et al. (2020) highlight
the importance of using a reference architecture including a local policy
enforcement point and a policy decision point at every site. In addition,
mechanisms such as auditing should be put in place in order to trace the
various interactions and transactions that occur within a system, but also to
collect information provided by data monitoring tools.

##### Auditing.

Pretschner et al. (2006) state that detective mechanisms, particularly audit
logs, are of particular interest in a usage control framework in order to
verify that data consumers abide by usage control policies. Detective
mechanisms are complementary to preventive mechanisms, especially if data are
shared with third parties and the control of how data are used becomes more
difficult. Moreover, according to Bonatti et al. (2017), audit logs present
the core of any transparency architecture as they can be used to both record
data transactions and what happened to the data. In a decentralized usage
control framework, the use of a hybrid approach involving a local internal
ledger and a distributed ledger could be warranted. For instance, a local
ledger could provide information about what happened inside the local
component of the framework, while a distributed ledger could be used to trace
what happened between services/ components and their relationships. However,
this approach presents different challenges when it comes to the
interoperability between ledgers from different consumers, and difficulties in
retracing all events in a unified manner, which complicates compliance
checking. Modeling events using semantic technologies could potentially
resolve these issues by:  (i) using a common schema to describe logs  (ii)
modeling and describing what happened to data using description vocabularies
that represent and relate information from different sources (i.e., data
consumers) in an understandable and timely manner . There is already numerous
vocabularies that could potentially be adapted to describe the provenance of
data, such as _PROV_ 888PROV, https://www.w3.org/TR/prov-overview/.
Additionally, there are different vocabularies to describe the data processing
events, such as _Event_ 999Events,
http://motools.sourceforge.net/event/event.html and the _LODE_
ontology101010LODE, http://linkedevents.org/ontology/.

##  7\. Conclusion

This paper provides an overview of the usage control domain by comparing and
contrasting the predominant usage control frameworks found in the literature.
We started by examining various usage control concepts and providing a broad
definition for usage control policies based on deontic concepts. Guided by an
integrative research methodology, we collected and categorized requirements
that have been used to guide the development of various usage control
solutions. These requirements address both the “what” and “how” aspects of
enforcing usage control policies, in particular, the specification, the
enforcement, and the robustness of the proposed solution. We subsequently
compared and contrasted the predominant usage control frameworks based on our
resulting taxonomy of requirements.

We subsequently broadened the discussion to include opportunities and
challenges that can guide future research directions. We highlighted that due
to their flexibility and interoperability, semantic technologies are
particularly suitable for encoding usage control policies. Following on from
this, we discussed the key role played by reasoning when it comes to policy
compliance, consistency, transparency, and system security. Additionally, we
identified the need for additional research from a usability and a human
computer interaction perspective in order to enable users to manage their
data. We also highlighted the importance of benchmarking in order to
systematically assess and validate the robustness of different usage control
solutions. Finally, we showed the need to employ verification and testing
tools in order to enhance the reliability and accuracy of usage control
proposals.

Finally, we outlined further challenges and opportunities that arise with the
emergence of modern decentralized and distributed environments. Key
considerations include the potential brought about by information flow
tracking tools and sticky policies when it comes to tackling issues with
respect to controlling how data are shared and used. Additionally, we
highlighted the key role played by distributed trust management approaches in
order to establish dependable, secure, and reliable data sharing
infrastructures. Finally, we underlined the need for preventive and detective
enforcement mechanisms for ensuring the correct enforcement of usage policies.

## References

  * (1)
  * Abrial (1974) Jean-Raymond Abrial. 1974\.  Data Semantics. In _IFIP Working Conference Data Base Management_. North-Holland, Corsica, France, 1–60.
  * ahmed et al. (2019) Abdelmuttlib Ibrahim Abdalla ahmed, Siti Hafizah Ab Hamid, Abdullah Bin Gani, Suleman Khan, and Muhammad Khurram Khan. 2019.  Trust and reputation for Internet of Things: Fundamentals, taxonomy, and open research challenges.  _J. Netw. Comput. Appl._ 145 (2019).
  * Alferes et al. (2006) Jose Alferes, Federico Banti, and Antonio Brogi. 2006\.  An Event-Condition-Action Logic Programming Language. In _Logics in Artificial Intelligence_. Springer, Berlin, Heidelberg, 29–42.
  * Artz and Gil (2007) D. Artz and Y. Gil. 2007\.  A survey of trust in computer science and the Semantic Web.  _J. Web Semant._ 5 (2007), 58–71.
  * Bai et al. (2010) Guangdong Bai, Liang Gu, Tao Feng, Yao Guo, and Xiangqun Chen. 2010.  Context-Aware Usage Control for Android. In _Security and Privacy in Communication Networks_. Springer, Berlin, Heidelberg, 326–343.
  * Baldini et al. (2013) Gianmarco Baldini, Ioannis Kounelis, IgorNai Fovino, and Ricardo Neisse. 2013.  A Framework for Privacy Protection and Usage Control of Personal Data in a Smart City Scenario. In _Critical Information Infrastructures Security_. Springer International Publishing, Cham, 212–217.
  * Basin et al. (2011) David Basin, Matúš Harvan, Felix Klaedtke, and Eugen Zălinescu. 2011\.  MONPOLY: Monitoring usage-control policies. In _International conference on runtime verification_. Springer, Springer, Berlin, Heidelberg, 360–364.
  * Bettini et al. (2003) Claudio Bettini, Sushil Jajodia, X Sean Wang, and Duminda Wijesekera. 2003.  Provisions and obligations in policy rule management.  _Journal of Network and Systems Management_ 11, 3 (2003), 351–372.
  * Bexheti and Langheinrich (2015) Agon Bexheti and Marc Langheinrich. 2015.  Understanding usage control requirements in pervasive memory augmentation systems. In _Proceedings of the 14th International Conference on Mobile and Ubiquitous Multimedia_. ACM, New York, NY, USA, 400–404.
  * Bier (2013) Christoph Bier. 2013\.  How Usage Control and Provenance Tracking Get Together - A Data Protection Perspective. In _2013 IEEE Symposium on Security and Privacy Workshops, San Francisco, CA, USA, May 23-24, 2013_. IEEE Computer Society, Los Alamitos, CA, USA, 13–17.
  * Bonatti et al. (2018) P. Bonatti, B. Bos, S. Decker, Javier D. Fernández, S. Kirrane, Vassilios Peristeras, A. Polleres, and R. Wenning. 2018\.  Data Privacy Vocabularies and Controls: Semantic Web for Transparency and Privacy. In _Proceedings of the Workshop on Semantic Web for Social Good co-located with 17th International Semantic Web Conference, SW4SG@ISWC_ , Vol. 2182. CEUR-WS.org, USA.
  * Bonatti et al. (2017) Piero Bonatti, Sabrina Kirrane, Axel Polleres, and Rigo Wenning. 2017.  Transparent Personal Data Processing: The Road Ahead. In _Computer Safety, Reliability, and Security. SAFECOMP 2017_. Springer International Publishing, Cham, 337–349.
  * Cao et al. (2020) Quyet H. Cao, Madhusudan Giyyarpuram, Reza Farahbakhsh, and Noel Crespi. 2020.  Policy-based usage control for a trustworthy data sharing platform in smart cities.  _Future Generation Computer Systems_ 107 (2020), 998–1010.
  * Carniani et al. (2016) Enrico Carniani, Davide D’Arenzo, Aliaksandr Lazouski, Fabio Martinelli, and Paolo Mori. 2016\.  Usage Control on Cloud systems.  _Future Generation Computer Systems_ 63 (2016), 37–55.  Modeling and Management for Big Data Analytics and Visualization.
  * Cirillo et al. (2020) Flavio Cirillo, Bin Cheng, Raffaele Porcellana, Marco Russo, Gürkan Solmaz, Hisashi Sakamoto, and Simon Pietro Romano. 2020.  IntentKeeper: Intent-oriented Data Usage Control for Federated Data Analytics. In _2020 IEEE 45th Conference on Local Computer Networks (LCN)_. IEEE Computer Society, Los Alamitos, CA, USA, 204–215.
  * Clemente et al. (2005) Félix J García Clemente, Gregorio Martínez Pérez, Juan A Botía Blaya, and Antonio F Gómez Skarmeta. 2005\.  Representing Security Policies in Web Information Systems.  , 10-16 pages.
  * Colombo et al. (2010) Maurizio Colombo, Aliaksandr Lazouski, Fabio Martinelli, and Paolo Mori. 2010.  A Proposal on Enhancing XACML with Continuous Usage Control Features. In _Grids, P2P and Services Computing_. Springer, Boston, MA, USA, 133–146.
  * Commission (2018) European Commission. 2018\.  2018 reform of EU data protection rules.  https://ec.europa.eu/commission/sites/beta-political/files/data-protection-factsheet-changes_en.pdf
  * Commission (2021) European Commission. 2021\.  2021 reform of EU copyright protection rules.  https://ec.europa.eu/commission/presscorner/detail/en/IP_21_1807
  * Costantino et al. (2018) Gianpiero Costantino, Antonio La Marra, Fabio Martinelli, Paolo Mori, and Andrea Saracino. 2018\.  Privacy Preserving Distributed Attribute Computation for Usage Control in the Internet of Things. In _2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/ 12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE)_. IEEE Computer Society, Los Alamitos, CA, USA, 1844–1851.
  * Dautov et al. (2017) Rustem Dautov, Simeon Veloudis, Iraklis Paraskakis, and Salvatore Distefano. 2017.  Policy Management and Enforcement Using OWL and SWRL for the Internet of Things. In _Ad-hoc, Mobile, and Wireless Networks - 16th International Conference on Ad Hoc Networks and Wireless, ADHOC-NOW_. Springer International Publishing, Cham, 342–355.
  * Demir et al. (2016) Onur Demir, Wenjie Xiong, Faisal Zaghloul, and Jakub Szefer. 2016\.  Survey of Approaches for Security Verification of Hardware/Software Systems.  _IACR Cryptol. ePrint Arch._ 2016 (2016), 846.
  * Drozd and Kirrane (2020) O. Drozd and S. Kirrane. 2020.  Privacy CURE: Consent Comprehension Made Easy.  _ICT Systems Security and Privacy Protection_ 580 (2020), 124.
  * Eitel et al. (2017) Andreas Eitel, Christian Jung, Christian Haas, Chrstian Mader, Gerd Brost, Julian Schütte, Jaroslav Pullmann, and Johannes Zrenner. 2017.  _Usage Control in the Industrial Data Space_.  Technical Report. International Data Spaces Association.
  * Esposito et al. (2020) Christian Esposito, Oscar Tamburis, Xin Su, and Chang Choi. 2020\.  Robust Decentralised Trust Management for the Internet of Things by Using Game Theory.  _Information Processing & Management_ 57, 6 (2020), 102308\.
  * Esteves and Rodríguez-Doncel (2021) Beatriz Esteves and Víctor Rodríguez-Doncel. 2021\.  Analysis of Ontologies and Policy Languages to Represent Information Flows in GDPR. (2021).
  * Etalle and Winsborough (2007) Sandro Etalle and William Winsborough. 2007.  A posteriori compliance control. In _Proceedings of ACM Symposium on Access Control Models and Technologies, SACMAT_. ACM, New York, NY, USA, 11–20.
  * Feth and Pretschner (2012) Denis Feth and Alexander Pretschner. 2012.  Flexible Data-Driven Security for Android. In _2012 IEEE Sixth International Conference on Software Security and Reliability_. IEEE, USA, 41–50.
  * Fromm and Stepa (2017) Alexander Fromm and Vladislav Stepa. 2017.  HDFT++ Hybrid Data Flow Tracking for SaaS Cloud Services. In _2017 IEEE 4th International Conference on Cyber Security and Cloud Computing (CSCloud)_. IEEE, USA, 333–338.
  * Gelernter (1985) D. Gelernter. 1985\.  Generative communication in Linda.  _ACM Trans. Program. Lang. Syst._ 7 (1985), 80–112.
  * Gil et al. (2020) G. Gil, A. Arnaiz, F. J. Diez, and M. V. Higuero. 2020\.  Evaluation Methodology for Distributed Data Usage Control Solutions. In _2020 Global Internet of Things Summit (GIoTS)_. IEEE, USA, 1–6.
  * Giorgi et al. (2017) Giacomo Giorgi, Antonio La Marra, Fabio Martinelli, Paolo Mori, and Andrea Saracino. 2017.  Smart Parental Advisory: A Usage Control and Deep Learning-Based Framework for Dynamic Parental Control on Smart TV. In _Security and Trust Management_. Springer International Publishing, Cham, 118–133.
  * Gomi (2010) Hidehito Gomi. 2010\.  A Persistent Data Tracking Mechanism for User-Centric Identity Governance.  _Ident Inf. Soc._ 3, 3, Article 69 (Dec. 2010), 18 pages.
  * Han and Lei (2012) Weili Han and Chang Lei. 2012.  A survey on policy languages in network and security management.  _Computer Networks_ 56, 1 (2012), 477–489.
  * Hilty et al. (2005) Manuel Hilty, David Basin, and Alexander Pretschner. 2005\.  On obligations. In _Proceedings of the 10th European Conference on Research in Computer Security_. Springer, Berlin, Heidelberg, 98–117.
  * Hilty et al. (2007a) M. Hilty, A. Pretschner, D. Basin, C. Schaefer, and T. Walter. 2007a.  Monitors for Usage Control. In _Trust Management_. Springer, Boston, MA, USA, 411–414.
  * Hilty et al. (2007b) M. Hilty, A. Pretschner, D. Basin, C. Schaefer, and T. Walter. 2007b.  A Policy Language for Distributed Usage Control. In _Computer Security – ESORICS 2007_. Springer, Berlin, Heidelberg, 531–546.
  * Hilty et al. (2006) Manuel Hilty, Alexander Pretschner, Christian Schaefer, and Thomas Walter. 2006.  Usage Control Requirements in Mobile and Ubiquitous Computing Applications. In _Proceedings of the International Conference on Systems and Networks Communications (ICSNC 2006), October 29 - November 3, 2006, Papeete, Tahiti, French Polynesia_. IEEE Computer Society, Los Alamitos, CA, USA, 27.