Context-Aware Policy Analysis for Distributed Usage Control

Abstract

To boost data spaces and benefit from the great opportunities that they present, data sovereignty must be provided by Distributed Usage Control (DUC). Assuming that DUC will be managed by implementing and enforcing policies, notable efforts have already been undertaken in the context of Access Control (AC) regarding policy analysis due to the impact of low-quality policies on security. In this regard, this paper proposes that policy analysis in the DUC context should be understood as an extension of the AC, which is further affected by other challenging features, chief among which are context-aware control and extended control through action requirements. This paper presents a novel Context-Aware Policy Analysis (CAPA) algorithm for detecting inconsistencies and redundancies for DUC policies by supporting a large set of heterogeneous conditions. In this regard, the dependent relationship of conditions is formulated which will lead to more efficient conflict detection. By implementing this concept, a novel tree structure that combines a resource and a policy structure is presented to search for and compare relevant rules from policies. Built on the tree structure and through the formalization of rule conflicts, CAPA is developed and the security and performance it provides is tested in a wind energy use case.

1. Introduction

In a study conducted by the European Commission [1] in which many companies of different sizes and sectors were interviewed, companies recognized the importance of Business-to-Business (B2B) data sharing. Among others, the following benefits stand out: improvements in the design of products and services, the generation of new business models, and the establishment of new partnerships. As a result, the European Commission is promoting the development of European Data Spaces [2] where companies can participate in distributed collaborative ecosystems as data providers by making their data available under certain requirements, and as data consumers by exploiting the data available. This serves to boost the data economy, competitiveness, and innovation at the European level.

In the energy sector, being able to process data acquired from different stakeholders in the course of power generation, transmission, transformation, distribution, and consumption would significantly advance knowledge to improve the performance of the value chain [3]. However, stakeholders are reluctant to share data if they lose control over its use once it reaches the distributed consumer to be exploited. As a result, knowledge extraction from data becomes a challenge. In this regard, ensuring data sovereignty [4], defined as the self-determination of individuals and organizations regarding the use of their data, becomes the key enabler to boost data sharing, enable data processing, and gain knowledge to take a big step in the energy sector. This is the case in areas such as wind energy generation, where recent analyses have highlighted data sharing as an important drawback [5,6,7]. For instance, access to data from e.g., turbine performance, usually retained by wind farm operators and OEMs (original equipment manufacturers), by different stakeholders (e.g., component OEMs) would optimize the maintenance & operation of the value chain [8]. Data sovereignty calls for future control over the usage of the data in distributed infrastructures, also denoted as Distributed Usage Control (DUC) [9]. In this sense, Access Control (AC) models can be considered a good starting point from which to address the development of DUC approaches.

Assuming that DUC will be managed through the implementation and enforcement of sticky policies [10], AC research literature [11] has already demonstrated that expressing policies without conflicts, i.e., providing good quality, is not trivial. Furthermore, low-quality policies have a great impact on:

• Security: leading to unauthorized data disclosure and/or denial of legal access, thus affecting data sovereignty.
• Performance: requiring longer policy enforcement times, which affects data sharing performance.

Thus, ensuring security in DUC through policy quality becomes crucial to ensure data sovereignty and to encourage data sharing.

The DUC model can be considered as an extension of AC models [12], but it introduces some significant features that further affect policy quality and render the adoption of existing AC policy analysis methods [13,14] non-feasible. These are the following:

• Context-aware control: due to the importance of context information for policy enforcement in distributed infrastructures, permission and prohibition rules are refined through much more numerous and diverse conditions than in AC. That is, while some conditions may apply to different domains (e.g., time or location), as they are non-dependent, dependent conditions such as those related to time can be heterogeneously described (e.g., time intervals or an event in time).
• Extended control by supporting action requirements: to further control distributed data usage, permission rules are refined by supporting duty rules that define the actions that must be executed before and after data usage is granted.

This paper addresses data sovereignty by providing security in DUC. Addressing both new features of DUC is of great importance, but we focus on analyzing the rules within policies that support context-aware control. In this regard, we take the policy quality requirements already defined in AC [11], ensure policy correctness by implementing semantic technologies, and we address security through a policy-analysis-based approach that ensures policy consistency and minimality. Consistency ensures that two policies do not express contradictory rights that may lead to unauthorized data disclosure, while minimality makes sure that there are no redundant policies, so security risks are avoided in policy management. Policy completeness and relevance may certainly affect security but providing them requires a data usage transaction-based analysis which lies outside the scope of this paper.

Following a logical approach, we face the challenge of supporting DUC-specific features based on existing AC policy analysis approaches. In this regard, we consider tree-based modeling to be the most suitable approach, because it enables all consistency and minimality conflicts to be detected. This means that security is always ensured. Thus, it guarantees data sovereignty, which is of utmost importance for DUC to reduce the reluctance to share data. This approach can also be adapted to the complexity introduced by conditions on rules. On this basis, this paper makes the following contributions:

• A novel tree structure combining a Policy Tree (PT) and a Resource Tree (RT) is presented. Using this tree structure, security can be assessed and provided by efficiently analyzing consistency and minimality for DUC with the support of context-aware control. On the one hand, by identifying, formulating, and implementing the dependent relationship of conditions, relevant rules are efficiently searched and irrelevant analyses are thus avoided. On the other hand, dependent conditions are stored in reference formats. In this way, efficient comparisons can be made between heterogeneous conditions.
• A method for assessing rule conflicts in the form of inconsistencies and redundancies is formalized. In this regard, depending on whether rules are of permission or prohibition, the inferences of their refinement with conditions (e.g., time intervals) for dependent but non-overlapping conditions (the rest of the time) are considered.
• A Context-Aware Policy Analysis (CAPA) algorithm is presented. It is built on the tree structures presented and implements the proposed assessment method for rule conflicts.

Lastly, to assess the feasibility of this approach, CAPA is formalized and implemented in a real wind energy use case. It is demonstrated that security can be provided. Thus, ensuring data sovereignty, leading to the sharing of data from wind turbine performance along the value chain, which will allow wind farm maintenance and operation to be optimized. Its own performance is also analyzed.

The rest of the paper is structured as follows: Section 2 reviews existing work on policy quality in DUC. Due to the lack of research in this domain, related work on AC is also reviewed with special focus on the tree-based modeling approach. Section 3 defines and formulates a DUC model encompassing existing models, thus generalizing the contributions presented throughout the paper. Section 4 introduces several definitions, which are used to present the tree structure and the rule conflict assessment method that enable policy analysis algorithms to be developed. To enable an efficient policy analysis to be conducted, Section 5 describes the tree structure composed of an RT and a PT. Section 6 sets out the assessment method for conflicts between rules. Section 7 presents CAPA, based on the tree structure explained in Section 5, and implements the rule conflict assessment method defined in Section 6. Section 8 confirms the feasibility of CAPA in a wind energy use case by presenting its ability to ensure security and by analyzing its performance. Finally, conclusions about this work and future lines of research are highlighted.

2. Related Work

Below, we provide an overview of the related work published so far about policy quality in DUC. The related work on policy quality in AC is considered of great interest as a starting point for developing DUC solutions, so it is also analyzed, with particular focus on the tree-based modeling approach.

2.1. DUC Policy Quality

Lazouski et al. [15] conducted a survey on the pioneering Usage Control (UCON) model [16]. This paper identifies security analysis, policy completeness, and consistency as important fields of research within usage control that have not yet been studied but that need to be addressed as fundamental points.

Kelbert et al. [17] present the Distributed Usage Control Framework. For the implementation of DUC policies, the Obligation Specification Language (OSL) [18] was followed. However, policy quality analysis is not addressed.

The International Data Spaces Association (IDSA) Reference Architecture Model [19], based on the reference Open Digital Rights Language (ODRL) information model (IM) (https://www.w3.org/TR/odrl-model/ accessed on 26 September 2022), formalizes the IDSA usage policy language (UPL) within the IDSA IM (https://w3id.org/idsa/core accessed on 26 September 2022) for the implementation of DUC policies [20]. Furthermore, built on the IDSA UPL, Bader et al. [21] present an overview of the challenges posed by DUC policies if they are to be enforceable. However, this work is incomplete and policy quality is not mentioned.

2.2. AC Policy Quality

In AC research literature, major efforts have been dedicated to policy quality assessment. In this regard, Aqib et al. [13] report the first survey on policy analysis mechanisms. This paper finds that policy can be analyzed through different approaches, denoted as formal methods, model checking, matrix-based approaches, mining techniques, mutation testing techniques, and others. Policy quality requirements are also limited to consistency and completeness. In this regard, based on existing work, each mechanism is reviewed and classified according to the policy analysis strategy used and the policy quality requirements addressed. Later, Bertino et al. [11] analyze policy quality in more depth. As a result, policy quality requirements are extended by including minimality, relevance, and correctness.

Based on these defined policy quality requirements and the increased number of papers on policy analysis in AC, Jabal et al. [14] conducted a more extensive and mature survey. Formal methods, model checking, data mining, graph/tree-based modeling, and mutation testing were identified as the most widely used approaches for policy analysis. Additionally, the large body of existing research was reviewed and classified based on the approach used and the policy quality requirements addressed. As a result, a comparison was drawn between the most widely used approaches and the policy quality requirements most widely addressed.

Because of the extensive research on policy analysis for AC, gathered in the previous survey, and due to some common features considered of interest for our approach for analyzing the quality of policies in the DUC context, we will deepen and narrow the research on specific tree-based modeling policy analysis approaches, with a special focus on papers that address context-aware control.

Chao et al. [22] formally define inconsistency for the role-based AC model [23] and address it through a checking algorithm that analyzes a set of rules defined for hierarchical classified roles. However, consistency is highly oriented to ensure the concepts of separation of duty and the cardinality constraint.

Sun et al. [24] present a conflict detection algorithm to ensure consistency in the purpose AC model by supporting hierarchically classified usage purposes. Specifically, inconsistencies are defined in a novel way. It is defined that if a usage purpose is already permitted for a resource, dependent usage purposes are denied by inference for the same resource and cannot be permitted. Otherwise, an inconsistency is detected. In this approach, it is assumed that rules are always defined as permissions.

Aqib et al. [25] present an algorithm for detecting inconsistencies for XACML [26], addressing rule refinement through Boolean expressions. However, it is limited to time-related Boolean expressions, which are always expressed as time ranges. Inconsistency is defined as contrary decisions for the same resource in overlapping time intervals. Thus, conditions are oversimplified because their inferences for dependent but non overlapping conditions are not considered.

Finally, although the concept of dependent relationship of resources is presented by Mohan et al. [27], Deng et al. [28] address it in depth and the transmission relationship of access authority is presented. In this regard, a conflict algorithm is presented for XACML by supporting time-based conditions expressed through time ranges. This paper focuses on detecting inconsistencies not only for common resources but also for dependent resources. However, inconsistencies are limited to overlapping time spans. Therefore, the concept of condition is also oversimplified, as inferences are not considered.

In short, from the AC research literature, the algorithms presented for policy analysis following the tree-based modeling approach are oriented towards providing policy consistency. Furthermore, only one condition is addressed in each algorithm. This means that roles are supported for role-based AC, usage purpose is addressed for purpose AC, and time is considered for XACML. Moreover, conditions are always expressed homogeneously. Roles and usage purposes are hierarchically classified, and time is expressed through time ranges. In addition, the concept of condition is oversimplified. Depending on whether rules are of permission or prohibition, their refinement with conditions has inferences for dependent but non-overlapping conditions. However, this issue is not considered for conflict detection. Finally, the dependent relationship of resources is introduced for XACML through the transmission relationship of access authority. However, it has all the above-mentioned limitations.

That said, although these papers can be considered a good starting point for building DUC solutions and providing support for DUC specific features, the importance of context-aware control for DUC means that policy analysis must be addressed by managing a broad set of heterogeneous conditions. Otherwise, policy quality will not be completely ensured. In this regard, we present CAPA in this paper: a policy analysis algorithm which seeks to provide security in DUC through policy consistency and minimality for context-aware policies. CAPA is built on a tree-based structure that implements the dependent relationship of resources and conditions and thus enables conflicts between rules refined through multiple heterogeneous conditions to be detected efficiently. It also detects inconsistencies and redundancies by considering the inferences of rule refinement. Thus, security is ensured through an algorithm that also provides good performance.

3. Distributed Usage Control Model

The DUC model has followed an incremental approach in which the pioneering UCON model has evolved into more refined and expressive models. Cases in point are the reference ODRL IM and, later, the IDSA UPL which, formalized within the IDSA IM, is the most mature DUC model to date. On that basis, we define a generic DUC model below that encompasses all the above.

Formula (1) formalizes the set of policies $p\in P$ that are composed of the subset of rules $r\in R$. These rules will be analyzed for policy consistency and minimality.

$$p=\left\{r_i\right\}, i=1, \dots , N$$

(1)

where N is the number of rules.

A rule $r_i$ describes the usage control statement related to permission for or prohibition of data usage and the duty that DUC may be required to perform under a permission. It is described through the $typ{e}_i=\left\{permission, prohibition, duty\right\}, su{b}_i \in S, ac{t}_i \in A, re{s}_i \in Res$ and $C_i \subset C$ which refer respectively to the rule type, subject, action, resource, and the set of conditions so that Formula (2) is satisfied.

$$r_i=\left(typ{e}_i, su{b}_i, ac{t}_i, re{s}_i, C_i\right), i=1,\dots , N$$

(2)

$$C_i=\left\{co{n}_j\right\}, j=1, \dots , M$$

where M is the number of conditions.

The rule type $typ{e}_i$ refers to whether the usage control statement is a permission, prohibition, or duty. Action requirements specified as duty rules in the DUC model are an additional feature that further affects policy quality. Addressing them in policy analysis is a very interesting line of research, but the scope of this paper is focused on context-aware control, so only permission and prohibition rules are considered in the rest of the paper.

A subject $su{b}_{i }$represents a participant within a data usage relationship. These may have the role of assignee or assigner. The assigner is responsible for defining $r_i$, while the assignee is responsible for its enforcement. Thus, the assigner has no impact on policy quality. Therefore, in the rest of the paper $su{b}_i$ always refers to the assignee.

An action $ac{t}_i$ describes the activity that a $su{b}_i$is permitted or prohibited from performing.

A resource $re{s}_i$represents the target digital content to which a $r_i$applies.

Conditions $C_i$ describe the specifications under which $r_i$ applies. Each $co{n}_j \in C_i$ is in the form of a Boolean expression, and thus composed of two operands ($leftOperan{d}_j \mathrm{and} rightOperan{d}_j$) compared by an operator $\left(operato{r}_j\right)$ which results in either true or false. Thus, we define condition $co{n}_j$ satisfying Formula (3).

$$co{n}_j=\left\{leftoperan{d}_j, operato{r}_j, rightOperan{d}_j\right\}$$

(3)

The rest of our work is presented below, based on this general DUC model.

4. Definitions

This section presents some definitions and axioms which constitute basic aspects and statements assumed in our approach.

Definition 1. Atomic Condition Rule:

if a rule $r_1$is refined by only one condition such that $M=1$, we define that $r_1$ is an atomic condition rule.

Definition 2. Composite Condition Rule:

if a rule $r_1$ is refined by more than one condition such that $M>1$, we define that $r_1$ is a composite condition rule.

Axiom 1. Rule Condition Atomization:

given a composite condition rule $r_1=\left(typ{e}_1,su{b}_1, re{s}_1, ac{t}_1, C_1=\left\{co{n}_{11}, co{n}_{12}\right\}\right)$, we can split it into atomic condition rules $r_{11}=\left(typ{e}_1,su{b}_1, re{s}_1, ac{t}_1, \left\{co{n}_{11}\right\}\right)$ and $r_{12}$$=\left(typ{e}_1,su{b}_1, re{s}_1, ac{t}_1, \left\{co{n}_{12}\right\}\right)$ maintaining the entire scope.

Thus, a set of rules $R_1$, which can be refined by atomic conditions and/or composite conditions can be split into a set of atomic condition rules $R_2$. From $R_2$, the tree structure is built, and the rule conflict assessment method is applied, enabling policy analysis algorithms to be developed. Thus, hereinafter we refer to atomic condition rules.

Definition 3. Dependent Relationship of Conditions:

for conditions $co{n}_1$and $co{n}_2$, we define them as satisfying the dependent relationship of conditions $co{n}_1 \leftrightarrow co{n}_2$ if they apply to the same domain, such as time, so that they may overlap. Furthermore, we define them as applying to the same domain and thus, that the dependent relationship of conditions is satisfied if their corresponding $leftoperan{d}_{1 }$and $leftoperan{d}_{2 }$ are related to the same application domain $L_{ad}$ so that Formula (4) is met.

$$co{n}_1 \leftrightarrow co{n}_2=\left(leftoperan{d}_1\in L_{ad}\wedge leftoperan{d}_2\in L_{ad}\right)$$

(4)

For example, two conditions $co{n}_1$ and $co{n}_2$ which refine $r_1$ and $r_2$ apply to the same domain if their corresponding $leftoperan{d}_1=current time \in L_{time}$ and $leftoperan{d}_2=duration \in L_{time}$ are related to time. However, $co{n}_1$ and $co{n}_3$ which refine $r_1$ and $r_3$ are not dependent, for example, if $leftoperan{d}_1=current time \in L_{time}$ and $leftoperan{d}_3=connector\in L_{connector}$ are respectively related to time and the connector.

Definition 4. Overlapping Relationship of Conditions:

for conditions $co{n}_1$and $co{n}_2$, if $co{n}_1\cap co{n}_2 \ne \varnothing$, we consider that $co{n}_1$ and $co{n}_2$ satisfy the overlapping relationship of conditions.

$$co{n}_1 \cap co{n}_2 \ne \varnothing$$

(5)

Definition 5. Conditions Whitelisting Approach:

in this approach, policies are described only through permission rules that explicitly define all the conditions that must be met to allow data usage. This leads to Axiom 2, which we define as follows.

Axiom 2.

If a rule $r_1$ of $typ{e}_1=permission$ is set for subject $su{b}_1$ on resource $re{s}_1$ with action $ac{t}_1$ given a condition $co{n}_1$ related to a specific application domain such that $leftoperan{d}_1 \in L_{a{d}_1}$ as shown in Formula (6), the enforcement of $r_{1 }$ for dependent but non-overlapping conditions with respect to $co{n}_1$ will always lead to a prohibition. Furthermore, complementary permissions such as for $co{n}_2$ can be defined on dependent and overlapping conditions so that permission is refined at $co{n}_1 \cap co{n}_2$.

$$r_1=\left(typ{e}_1=permission, su{b}_1, re{s}_1, ac{t}_1, co{n}_1=\left(leftOperan{d}_1\in L_{ad}{}_1, operato{r}_1, rightOperan{d}_1\right)\right)$$

(6)

For example, the enforcement of a rule $r_1$ of the permission type leads to permission from 1 January 2022 to 1 January 2023, but condition enforcement at any other time will result in a prohibition. Moreover, a permission rule $r_2$ can be defined as complementary at maintenance time so that permission is only granted at maintenance time between 1 January 2022 and 1 January 2023.

Definition 6. Conditions Blacklisting Approach:

following this approach data usage is granted by default, and only prohibition rules are described, so that if only one prohibition is met, i.e., if only one condition is met, data usage is blocked. From this, we define Axiom 3.

Axiom 3.

If a rule $r_1$ of $typ{e}_1=prohibition$ is set for subject $su{b}_1$ on resource $re{s}_1$ with action $ac{t}_1$ given a condition $co{n}_1$ related to a specific application domain such that $leftoperan{d}_1 \in L_{a{d}_1}$ as shown in Formula (7), the enforcement of $r_{1 }$ for non-overlapping but dependent conditions with respect to $co{n}_1$ will lead to permission by default. However, complementary prohibitions such as for $co{n}_2$ can be defined on dependent but non-overlapping conditions, so that prohibition is extended to $co{n}_1+co{n}_2$.

$$r_1=\left(typ{e}_1=prohibition, su{b}_1, re{s}_1, ac{t}_1, co{n}_1=\left(leftOperan{d}_1\in L_{ad}{}_1, operato{r}_1, rightOperan{d}_1\right)\right)$$

(7)

For example, the enforcement of a rule $r_1$ of type prohibition leads to a prohibition for a Connector A, while a rule $r_2$ also of the prohibition type will complement the previous one, describing a prohibition also for Connector B. However, for all other connectors data usage is permitted.

Definition 7. Dependent Relationship of Resources:

for resources $re{s}_i$ and $re{s}_j$, if $re{s}_j$ is part of $re{s}_i$ so that $re{s}_i \to re{s}_j$, we say that they satisfy the dependent relationship of resources.

$$re{s}_i\to re{s}_j$$

(8)

Definition 8. Time Complexity:

This measures the time required to execute an algorithm. It is measured as the number of times that the statements of an algorithm are executed. It is expressed using the big $O$ annotation.

5. Tree Structures for Efficient Policy Analysis

Our approach is based on building tree structures for resources and the rules defined on them. This section presents some initial concerns related to efficient policy analysis and the most significant features of the trees.

For N atomic condition rules, conflicts can be detected by brute force by making a total of $N\ast \left(N-1\right)$comparisons between each of the rules. However, that results in poor performance for the following two reasons:

1.

Irrelevant analysis of rules that never lead to conflict: For two rules, $r_1$ and $r_2$, inconsistencies and redundancies appear only for the same subject and action, so $su{b}_1=su{b}_2 \wedge ac{t}_1=ac{t}_2$. Furthermore, they may appear for common resources $re{s}_1=re{s}_2$ as well as for dependent resources $re{s}_1\to re{s}_2$ As a result, only rules satisfying Formulas (9) and (10) must be analyzed for common and dependent resource conflicts respectively.

$$su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j$$

(9)

$$su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i\to re{s}_j$$

(10)

These rules that must always be analyzed because they may lead to conflicts that are denoted below as relevant rules.

In DUC, with the refinement of rules through a wide set of conditions, not only does the number of rules increase considerably but rules for a subject and action also apply to different condition application domains which are non-dependent and thus never lead to a conflict, so their analysis is irrelevant. From this, we define Axiom 4.

Axiom 4. Efficient analysis of DUC relevant rules.

To efficiently detect common and dependent resource conflicts in DUC, only relevant rules that satisfy Formulas (11) and (12) respectively, which introduce the dependent relationship of conditions, must be analyzed.

$$su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge co{n}_i\to co{n}_j$$

(11)

$$su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i\to re{s}_j\wedge co{n}_i\to co{n}_j$$

(12)

These relevant rules must also be efficiently detected through the rule set.

2.

Inefficient comparison between relevant rules: In the AC context, conditions are always homogeneously defined. For example, time is always expressed as a range. Therefore, no conversions are needed for conditions to be made comparable. In DUC, by contrast, the conditions that apply to the same domain may be heterogeneously expressed. Time conditions are a case in point. Time may be expressed as a range or as an event in time. As a result, direct comparisons cannot be made, and condition conversions are required. On this basis, we define Axiom 5.

Axiom 5.

Efficient comparison of DUC relevant rules. Based on the dependent relationship of conditions, reference formats must be established for each condition application domain so that heterogeneous conditions are converted once and then efficiently compared as many times as necessary.

The following subsections present a novel tree structure based on Axiom 4 and Axiom 5 that combines a Resource Tree (RT) and a Policy Tree (PT). This enables relevant rules for common and dependent resources to be detected and compared efficiently.

5.1. Resource Tree

In the RT class diagram, shown in Figure 1, all the resources available in a use case are stored and structured according to their dependent relationships.

Specifically, each resource is represented via a RT node denoted as resourceNode. Each resourceNode contains its parent resourceNode and child resourceNodes satisfying the dependent relationship. Each resourceNode also contains a PT that stores and structures all the rules defined on it. Thus, relevant rules not only for common resources but also for dependent resources can be efficiently searched and compared.

5.2. Policy Tree

As shown in Figure 2, the PT of each resourceNode is composed of 5 types of nodes: the resource $re{s}_i,$the action $ac{t}_i$, the subject $su{b}_i$, the condition application domain $L_{ad}{}_i$, and the conditions $co{n}_i$.

The process of building the PT for each resourceNode is as follows. In the first instance all the rules defined within policies are sequentially analyzed in search of common resource conflicts. In this process, each rule is analyzed in relation to every relevant rule already stored in the PT of the corresponding resourceNode. Then the rule is stored in that PT. In this way, the following rules can be compared with that rule to check for common resource conflicts in further analysis and once all the rules have been analyzed, dependent resource conflicts can be checked for throughout the tree structure. To enable policy analysis to take place efficiently, the rules are structured in the PT following a set of guidelines.

First, to detect dependent resource conflicts, when common resource conflicts are detected and all the rules are stored in the PT of each resourceNode, searches are made from the root resourceNode through the RT branches sequentially comparing the resulting permissions or prohibitions defined for each subject $su{b}_i$on each action $ac{t}_i$ with those defined for dependent resources. Therefore, to run this search efficiently and avoid redundancies, starting from the root node $re{s}_i$, we built the PT by classifying the rules based on the actions $ac{t}_i$ and subjects $su{b}_i$to which they refer. Given that there are typically fewer actions than subjects, and to reduce the number of branches and improve the search efficiency, the resource node $re{s}_i$ has one branch for each node related to the action $ac{t}_i$involved in data usage, but each action node $ac{t}_i$ has one branch for each node related to the subject $su{b}_i$ to which the rule refers.

Second, we classify the rules according to the dependent relationship of conditions in application domains $L_{a{d}_i}$. Specifically, in the PT each $su{b}_i$ has a set of branches each of which contains a child node with one condition application domain $L_{a{d}_i}$where the rule applies. These condition application domains are identified from each $leftoperan{d}_i$that may describe a condition. Furthermore each $L_{ad}{}_i$node has two branches depending on the type of the rule defined. Finally, each of these branches has the list of conditions under which each type of rule applies for the corresponding application domain $L_{ad}{}_i$. The PT is represented by a hash table where the key represents the node itself and the value, the child node. Thus, for common resource conflicts it takes $O \left(1\right)$ to search for relevant rules on a specific application domain $L_{ad}{}_i$. For dependent resource conflicts, the analysis is performed individually comparing the resulting relevant permissions and prohibitions for two dependent resources for each subject $su{b}_i$, action $ac{t}_i,$ and condition application domain $L_{ad}{}_i$. Therefore, taking at most $O \left(S\mathrm{x}A\mathrm{x}{L}_{ad}\right)$.

Finally, we store the lists of conditions for each application domain through reference formats. Thus, time-related conditions are stored as time intervals regardless of whether they are expressed in that term or, for example, as an event in time, while user-related conditions are stored as a list of users regardless of whether they are explicitly expressed as such or defined through membership. Consequently, every time a rule is analyzed, the condition that refines it is only converted once and many unnecessary conversions between stored heterogeneous conditions are avoided. This improves performance in comparing conditions.

6. Conflict Detection

In the following subsections we propose an assessment method for detecting conflicts between relevant rules in DUC for common and dependent resources in the form of inconsistencies and redundancies. The method is individualized depending on the approach used for rule definition (whitelisting or blacklisting).

6.1. Common Resource Conflicts

Below, we define how inconsistencies and redundancies appear between two relevant rules defined for a common resource depending on the approach used for rule definition.

6.1.1. Whitelisting

For two relevant rules $r_i$ and $r_j$ described through the whitelisting approach, we define that two non-overlapping conditions such that $co{n}_{i }\cap co{n}_j=\varnothing$ lead to an inconsistency when Formula (13) is satisfied, but if one condition is encompassed by another such that $co{n}_{i }\cap co{n}_j=co{n}_i$ or $co{n}_{i }\cap co{n}_j=co{n}_j$ a redundancy appears when Formula (14) is satisfied. Regarding the former, two non-overlapping conditions will never be satisfied at the same time. Therefore, a prohibition will always result. For the latter, one condition encompasses the other one, so the first one is unnecessary because it is less restrictive.

$$typ{e}_i=typ{e}_j=PERMISSION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge co{n}_i\cap co{n}_j=\varnothing$$

(13)

$$typ{e}_i=typ{e}_j=PERMISSION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge \left(co{n}_i\cap co{n}_j=co{n}_i\vee co{n}_i\cap co{n}_j=co{n}_j\right)$$

(14)

As shown in Figure 3, for the relevant rules $r_1$, $r_2$, $r_3$, and $r_4$ that satisfy the dependent relationship of conditions such that $leftoperan{d}_{1,2,3,4 }\in L_{time}$,$co{n}_2$ refines $co{n}_1$. However, while $co{n}_1$and $co{n}_3$ lead to an inconsistency as $co{n}_{1 }\cap co{n}_{3 }=\varnothing$ because permission would never be granted, $co{n}_1$ and $co{n}_4$ lead to a redundancy because $co{n}_1\cap co{n}_4=co{n}_4$ and permission would only be granted for $co{n}_4$.

6.1.2. Blacklisting

In this case, for two relevant rules $r_i$ and $r_j$ described through the blacklisting approach, we say that a common resource conflict appears (always as a redundancy) if a condition such as $co{n}_i$ encompasses the other condition $co{n}_j$, or vice versa so that Formula (15) is satisfied.

$$typ{e}_i=typ{e}_j=PROHIBITION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge \left(co{n}_{i }\cap co{n}_j=co{n}_i\vee co{n}_i\cap co{n}_j=co{n}_j\right)$$

(15)

As shown in Figure 4, for the relevant rules $r_1$, $r_2,$and ${\mathrm{r}}_3$, which satisfy the dependent relationship of conditions such that $leftoperan{d}_{1,2,3 }\in L_{con},$while ${\mathrm{con}}_1$ complements $co{n}_2$, a conflict arises as a redundancy when a condition $co{n}_2$ encompasses $co{n}_3$. This is because $co{n}_3$ is not necessary as it is already defined within $co{n}_2$.

Within this approach, we consider that prohibition rules can be combined with permission rules so that exceptions are introduced to the permissions granted. Thus, relevant rules $r_i$ and $r_j$ described through the whitelisting and blacklisting approaches respectively do not lead to a conflict if the prohibition refines the permission to some extent so that $co{n}_i\cap co{n}_j \subset co{n}_i.$

In other words, on the one hand we define that a redundancy appears that satisfies Formula (16) when the two rules do not overlap so that $co{n}_i \cap co{n}_j=\varnothing$. This is because the prohibition rule is redundant with respect to the prohibition already set by the permission rule on dependent but non-overlapping conditions. On the other hand, we define that an inconsistency appears that satisfies Formula (17) if the prohibition rule makes an exception to the entire permission so that $co{n}_i \cap co{n}_j=co{n}_i$ and the permission becomes invalid.

$$typ{e}_i=PERMISSION\wedge typ{e}_j=PROHIBITION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge co{n}_i\cap co{n}_j=\varnothing$$

(16)

$$typ{e}_i=PERMISSION\wedge typ{e}_j=PROHIBITION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge co{n}_i\cap co{n}_j=co{n}_i$$

(17)

As shown in Figure 5, for the relevant rules $r_1$, $r_{2,} r_3, r_4$refined through dependent conditions, an exception is correctly made for $r_1$ when $r_2$ is defined. Whereas $r_4$ leads to a redundancy as the prohibition is already made by $r_1$, and $r_3$ results in an inconsistency because it makes the permission already defined invalid regardless of the condition.

6.2. Dependent Resource Conflicts

Dependent resource conflicts may arise between the resulting relevant permissions or prohibitions defined for a subject to perform an action on a resource for each condition application domain.

Deng et al. [28] define the transmission relationship of access authority, based on the idea that if a prohibition is defined on an upper resource, it is deduced that access for child resources is also denied. However, the oversimplification with which conditions are supported means that this axiom is not correctly translated. Based on the real inferences of refining rules through conditions, we fully translate the axiom proposed in what we call the transmission relationship of usage authority. Depending on how rules are defined, the transmission relationship of usage authority changes. However, the idea is the same: for a set of rules defined on a resource, the resulting permissions must be more restrictive through dependent resources.

The following subsections present the concept of the transmission relationship of usage authority for each approach used in rule definition. On that basis, we also define how inconsistencies appear depending on the conditions.

6.2.1. Whitelisting

For the whitelisting approach, we define the transmission relationship of usage authority as per Figure 6.

Based on the resulting permissions from all the relevant rules defined for two dependent resources on a specific application domain $L_{ad}$, it can be said that if a permission is defined on an upper resource, the transmission relationship of usage authority is satisfied if a more restrictive permission is defined on child resources such that $co{n}_j \subseteq co{n}_i$. But if a less restrictive permission $co{n}_j \supseteq co{n}_i$ satisfying Formula (18) or a prohibition is defined, an inconsistency appears.

$$typ{e}_i=PERMISSION\wedge typ{e}_i=PERMISSION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge co{n}_j\supseteq co{n}_i=0$$

(18)

6.2.2. Blacklisting

We define the transmission relationship of usage authority for the blacklisting approach as per Figure 7.

In particular, also based on the results obtained for two dependent resources from all the relevant rules on an specific application domain $L_{ad}$, if a prohibition is defined on an upper resource, it can be said that the transmission relationship of usage authority is satisfied if either a more restrictive prohibition is defined on child resources such that at least the upper resource conditions are also included satisfying Formula (19), or a permission is explicitly defined on a condition where a prohibition has not been explicitly defined that satisfies Formula (20).

$$typ{e}_i=PROHIBITION\wedge typ{e}_i=PROHIBITION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge co{n}_j\supseteq co{n}_i$$

(19)

$$typ{e}_i=PROHIBITION \wedge typ{e}_i=PERMISSION\wedge su{b}_i=su{b}_j\wedge ac{t}_i=ac{t}_j\wedge re{s}_i=re{s}_j\wedge co{n}_j\cap co{n}_i=0$$

(20)

7. Context-Aware Policy Analysis Algorithm

Figure 8 presents the flow diagram of the CAPA algorithm, which is based on the tree structures described in Section 5 and implements the method for detecting rule conflicts outlined in Section 6. The flow diagram describes how CAPA detects common and dependent resource conflicts between the policies defined in a use case.

Initially, the algorithm retrieves the information needed to connect to the domain-specific ontology where the resources of a given use case are described (resourceDescriptionBackend) and to the backend where the target policies to be analyzed are stored (policyStorageBackend). From the resourceDescriptionBackend, a first instance of the RT is built in the rootResourceNode through the resourceTreeInitialization algorithm by sequentially storing child resources as child resourceNodes based on their dependent relationships. Next, from the policyStorageBackend, the target policies $P$ to be analyzed are retrieved. Then, from the rootResourceNode, through the commonResourceConflictDetection algorithm, each rule of $P$ is sequentially checked for common resource conflicts. As a result, the rootResourceNode is retrieved with the rules of each policy stored in the PT of the corresponding resourceNode. Lastly, dependent resource conflicts are finally detected by the dependentResourceConflictDetection algorithm by running a backtracking process from the rootResourceNode along all its branches.

The resourceTreeInitialization, the commonResourceConflictDetection and the dependentResourceConflictDetection algorithms (marked in blue in Figure 8) illustrate the impact of our contributions on the policy analysis procedure, leading in addition to the optimized performance provided by CAPA. The following subsections describe these algorithms in depth. Furthermore, for each of them the time complexity is identified to highlight their performance.

7.1. Resource Tree Initialization Algorithm

With the resourceDescriptionBackend as input, Figure 9 represents the flow diagram of the algorithm that builds the RT in the rootResourceNode for a given use case.

Initially, the information stored in the domain-specific ontology is retrieved through the getResourceDescription algorithm and stored in a HashMap $res$ containing the URI of the resource as the key and the list of URIs of the resources that satisfy the dependent relationship as the value. Then, the information about the root resource is stored in the rootResourceNode and the RT is built by sequentially analyzing in $res$ the resources that satisfy the dependent relationship. Specifically, for each resourceNode denoted as $crn$, dependent resources are identified from $res$ (childResources). If there are child resources ($cr$), a resourceNode is constructed (childResourceNode) for each one and they are joined to the RT through the parent resourceNode and stored to be analyzed in the following iteration.

As a result, for a set of resources $Res$, the resourceTreeInitialization algorithm takes $O \left(Res\right)$ to build the RT.

7.2. Common Resource Conflict Detection Algorithm

Figure 10 shows the flow diagram of the algorithm that detects common resource conflicts for a set of policies $P$. It is built on the RT previously stored in the rootResourceNode.

To that end, all the rules $r$ defined on each of the policies $p \in P$ are sequentially analyzed. Specifically, for each $r$, the resourceNode from the RT that belongs to the resource defined in $r$ is first identified through the findResourceNode algorithm. Second, the condition application domain $L_{ad}$is identified from the condition that refines $r$. Third, through the conflictDetection algorithm and from $L_{ad}$, conflicts are efficiently searched for and detected between $r$ and the relevant rules already stored in the PT of the resourceNode found. The condition $cond$ that refines $r$ is also retrieved in its reference format. Finally, $r$ is added with $cond$ to the PT of the corresponding resourceNode through the addRuleToPT algorithm so that it can be efficiently compared in the analysis of the following rules. As a result, the RT is retrieved as an output with all the rules stored in the corresponding PTs of each resourceNode.

The findResourceNode and the conflictDetection algorithms become too complex, so they are further analyzed in the following subsections. In the opposite way, the addRuleToPT algorithm is limited to adding a rule to the HashMap that makes up the PT. This algorithm has a time complexity of $O \left(1\right)$.

7.2.1. FindResourceNode Algorithm

Taking the rootResourceNode and the target rule $r$ as inputs, Figure 11 describes the flow diagram of the algorithm that retrieves from the RT the resourceNode belonging to the resource defined on $r$.

Starting with the rootResourceNode, the resourceNodes belonging to each level of the RT are sequentially analyzed. If the resourceNode belongs to the resource defined in $r$, the search is stopped and the resourceNode is returned. Otherwise, its child resourceNodes are stored for further analysis.

Therefore, for a set of resources $Res$ it takes $O \left(1\right)$ to find the corresponding resourceNode in the best case if $r$is defined for the rootResourceNode and $O \left(Res\right)$ in the worst case if all the branches of the RT are analyzed until the resourceNode is found.

7.2.2. ConflictDetection Algorithm

Figure 12 shows the algorithm based on $L_{ad}$ that efficiently retrieves and compares with $r$ the relevant rules stored in the PT of the resourceNode previously found throughout the RT.

The flow diagram is represented for time-based conditions, but the logic is extended to other condition application domains. To detect conflicts, the condition that refines $r$ is first converted to the reference format so that it can be efficiently compared with all the relevant time-based conditions stored in the PT of the resourceNode. Second, through the getPermittedTimes and getProhibitedTimes algorithms and based on $L_{ad},$relevant time-based conditions related to $r$are respectively efficiently retrieved for permissions and prohibitions from the PT of the resourceNode. Thus, from them and through the compareTimeConditions algorithm that implements the evaluation formalized in Section 6.1, common resource conflicts are efficiently detected.

The time complexity of the conflictDetection algorithm can be analyzed in the following 2 complementary ways:

• Relevant conditions search: for a resourceNode, it takes $O \left(1\right)$ for getPermittedTimes and getProhibitedTimes algorithms to find either permission or prohibition relevant conditions through the HashMap that makes up the PT.
• Relevant conditions comparison: if done by brute force, comparing heterogeneous conditions requires one conversion for the condition that refines the target rule and another for each relevant condition stored in the PT. However, in the algorithm presented, condition comparisons through the compareTimeCondition algorithm for a set of $R$ rules only require $R$ conversions: one for each target rule.

7.3. Dependent Resource Conflict Detection Algorithm

Figure 13 shows the backtracking process along the RT for dependent resource conflict detection via a flow diagram.

First, starting from the rootResourceNode, the algorithm checks whether each resourceNode denoted as $crn$, has child resourceNodes. If so, each child resourceNode denoted as childrn is stored for further backtracking and is then analyzed for conflict detection. In this analysis, a sequential search is performed over the actions of each subject that are controlled by at least one rule. For each one, if the childrn is also controlled for the same subject and action, conflicts are sequentially searched for and detected for each condition application domain $L_{ad}$. Figure 13 shows the flow diagram for time-based conditions, but the method is extensible to all other domains. This said, for each $L_{ad}$, through the getTime algorithm, the list of conditions defined for both the parent resourceNode $crn$ and child resourceNode $childrn$ are retrieved and the resulting $parentTime$ and $childTime$ permissions are respectively calculated. Thus, by executing the compareDependentTimeConditions algorithm that implements the assessment formalized in Section 6.2, any dependent resource conflicts are detected.

The time complexity of the dependentResourceConflictDetection algorithm can be analyzed in the following 3 complementary ways:

• Dependent Resource Conflicts Search: given a resource controlled for a set of subjects $S$ on a set of actions $\mathrm{A}$ and refined through $l_{ad}$application domains, it takes at most $O \left(SxAx{L}_{Ad}\right)$ to search for dependent resource conflicts for the resourceNode.
• Relevant conditions search: for a resourceNode, it takes $O \left(1\right)$ for the getTime algorithm to find the permitted and prohibited conditions through the HashMap that makes up the PT.
• Relevant conditions comparison: conditions are already stored in reference formats, so conversions in the compareDependentTimeConditions algorithm are not required.

8. Experimental Assessment

The aim of the experimental assessment is to prove that CAPA provides security by detecting all inconsistencies and redundancies on all the policies defined by a data owner in a DUC solution that has been implemented in a wind energy use case. The performance provided by CAPA is also analyzed by measuring its efficiency. It is worth mentioning that this considerable efficiency increase is obtained by including support for the dependent relationship of conditions. To that end, the lack of context-aware policy analysis approaches leads to a Basic Policy Analysis, denoted as BPA, being implemented. BPA implements the algorithms described in Section 7 but omits the contributions presented in Section 5 related to the efficient search and comparison of DUC relevant rules. In this regard, conditions are not structured in the PT based on their dependent relationship and they are stored in the same format in which they are expressed.

On this basis, this section presents the most significant results obtained in the wind energy use case where CAPA and BPA are implemented and tested. To do so, the components of the use case that are most relevant in terms of implementation are identified and explained. Next, due to the lack of large-scale sets of rules related to DUC, specific rule sets are created for the purposes of assessment. The settings used in the environment where CAPA and BPA are deployed are also detailed. Finally, the results of the experimental assessment are analyzed.

8.1. Wind Energy Use Case

In wind energy, wind farm competitiveness is closely connected with the maintenance of wind turbines. Therefore, analyzing and learning from the data collected from the wind turbine operation is of the utmost importance [8]. However, due to current reluctance to share private data, the data collected from wind turbine operations is retained by wind farm operators and OEMs. As the data owners, they are the only actors who usually extract added value from the data [5]. Thus, other stakeholders in the value chain such as component suppliers and third-party service providers are missing the opportunity to analyze and learn from wind turbine operation data. This issue has a major impact not only on the competitiveness of each individual stakeholder, but also on that of the entire value chain. To increase competitiveness, reluctance to share data must be overcome by encouraging trusted data sharing. In this regard, there are already architecture models such as IDSA [19] which provide a reliable reference for driving the development of ecosystems that can boost data sharing by providing trust, data sovereignty, and interoperability.

Figure 14 presents a use case for wind energy, where the IDSA ecosystem is adopted to enable trusted sharing of gearbox-related data across the value chain. This use case features a company that deploys sensors which monitor the gearbox of a wind turbine and provide condition data from the lubrication system. From that data, edge computing services developed by a service company estimate gearbox health status. The gearbox is one of the components of a wind turbine that has the greatest impact on maintenance. Therefore, sharing such information with other stakeholders in the value chain such as the component supplier is of great interest because their combined data and expertise can significantly improve gearbox operation and maintenance (e.g., by improving component design, by establishing specific maintenance policies, etc.). To promote trustworthy sharing of this data by providing data sovereignty, a technology provider deploys two IDS DataSpace Connectors to share data between a data owner and user, an Identity Provider to provide trust between the IDS DataSpace Connectors, and a Vocabulary Provider for resource description. The Connectors and the Vocabulary Provider are directly involved in this DUC demonstration, so they are described in more detail below.

IDSA DataSpace Connectors (https://international-data-spaces-association.github.io/DataspaceConnector/ accessed on 26 September 2022) are the technical components responsible for correct data sharing between a data owner (e.g., the wind farm operator) and a data user (e.g., a component supplier) through the trusted IDSA ecosystem. Among other tasks, they are responsible for providing data sovereignty through DUC. On the side of the data provider, they are responsible for implementing the DUC policies defined by the data owner. On the side of the data consumer, they are responsible for enforcing DUC policies correctly. To provide semantic interoperability through these connectors, DUC policies are implemented following the IDSA UPL by integrating the IDSA IM through a Java Library. In the IDSA IM, usage requirements are defined through IDSA contracts (called simply contracts hereafter). A contract comprises two sections: The contract metadata and the IDSA Usage Control Policy. The metadata contains contract-specific information (e.g., the date of issue and the participants), while the IDSA Usage Control Policy, following the IDSA UPL, comprises IDSA Rules that describe the usage control statements that must be examined for policy quality. Therefore, policy analysis takes place within the IDSA DataSpace Connector in the role of the data provider through the implementation of CAPA or BPA.

The Vocabulary Provider manages and provides a domain-specific Wind Farm Ontology (in this case WFOnt) (https://w3id.org/wfont) that describes the resources shared by the IDSA DataSpace Connectors through the IDSA ecosystem. As a result, not only common but also dependent resource conflicts can be detected through policy analysis by CAPA and BPA. WFOnt is inspired by the SANDIA Report [29] and reuses the AffectedBy and EEP (execution-executor-procedure) ontology design patterns to discover sensors or actuators that observe or act on a given quality or feature of interest.

8.2. Datasets and Setting

For the experimental assessment, we have developed a dataset generator that creates the rule sets summarized in

Table 1. Experimental Assessment Rule Sets.

Rule Set	R	Res	AxS	C	${\mathit{L}}_{\mathit{a}\mathit{d}}$
1	200	2	1 × 10	10	5: Time, Connector, Location, Security Level, and Count
2			10 × 1
3			1 × 1	100
4	2000		1 × 100	10
5			10 × 10
6			100 × 1
7			1 × 10	100
8			10 × A
9	20,000		1 × 1000	10
10			10 × 100
11			100 × 10
12			1000 × 1
13			1 × 100	100
14			10 × 10
15			100 × 1

.

These rule sets have been created following these guidelines:

• Each rule set contains 200, 2000, or 20,000 rules.
• For 50 resources available in a use case, which are classified into 5 levels of dependency, the rules of each rule set are equally divided into 10, 1000, or 10,000 rules defined for two dependent resources: the deepest one and its parent.
• For each of these two resources, the combined number of subjects and actions controlled varies exponentially from 1 to 10, 100, and 1000. In the rest of the analysis, this combination of subjects and their controlled actions is denoted as the product AxS.
• All subjects have the same number of rules defined for each action, 10 or 100, which are refined respectively by 2 or 20 Conditions for each of the following 5 application domains: Time, Connector, Location, Security Level, and Count.

CAPA and BPA are implemented in Java 17. All the experiments were performed on a Linux Server running Ubuntu 20.04 with 1 core and 2 GB RAM.

8.3. Results

In the following subsections, we first indicate the extent to which CAPA and BPA ensure security by detecting all inconsistencies and redundancies. Next, we focus on the measurement and analysis of CAPA’s performance for this purpose compared to BPA. To provide a better insight, CAPA and BPA performances regarding common and dependent resource conflict detection are individually analyzed below.

8.3.1. CAPA and BPA Security

Conflicts were intentionally generated in the rule sets to assess the detection capabilities of the tree-based approach (included in both CAPA & BPA).

A 100% conflict detection is observed for CAPA and BPA. Therefore, we consider that the current policy analysis algorithm approach provides full security regarding policy consistency and minimality. In this way, this algorithm can boost data sharing in these ecosystems by providing data owners with trust and thus helping to overcome their reluctance to share their data.

8.3.2. CAPA and BPA Performance on Common Resource Conflict Detection

For a more detailed, more comprehensive analysis, we split the analysis of the performance provided by both algorithms regarding common resource conflict detection into findResourceNode, conflictDetection, and addRuletoRT algorithms, as done in Section 7.2 in describing the conflict detection algorithm.

1. findResourceNode: Section 7.2.1 theoretically defines that the time complexity to find the resource defined in a rule within the RT is $O \left(1\right)$ in the best case if the rule is defined for the root resourceNode and $O \left(Res\right)$ in the worst case if all the branches of the RT are analyzed until the resourceNode is found. In the experiment performed, for the rules defined for the deepest resource the time required to find the resourceNode is not significant: it takes at most 1 ms for CAPA and BPA.

2. conflictDetection: from the resourceNode found by the findResourceNode algorithm, the time required to detect common resource conflicts for a rule depends on the time required to search and compare relevant conditions through the corresponding PT.

The experimental assessment proves that regardless of the number of subjects and actions, if the product AxS is the same (e.g., 1 × 100, 10 × 10, or 100 × 1) then the performance provided by the conflictDetection algorithm in CAPA and BPA depends only on the number of conditions (10 or 100). For a clearer analysis, Figure 15 represents the total time that the conflictDetection algorithm takes in CAPA and BPA to detect conflicts in all the rules defined for the deepest resource in each rule set based on AxS. In both Figures, the volume handled by the policy analysis algorithms increases from 10 to 100 and 1000 rules. In case of Figure 15a, AxS ranges from 10 to 100 and 1000 with 10 Conditions set in each controlled action for each subject. In Figure 15b AxS ranges from 1 to 10 and 100 AxS with 100 Conditions.

Figure 15 shows that CAPA always provides a better performance. Conditions are demonstrated to be the component of the rule with a major impact on the performance provided by policy analysis algorithms. In this regard, CAPA also proves to be more adaptive to an increasing number of conditions.

On the one hand, for the same number of rules, for example, 1000, if conditions increase from 10 to 100 at the cost of reducing AxS from 100 to 10, both algorithms show a loss of performance, but CAPA drops by only 50% while BPA drops by 100%. In addition, for the same AxS, if conditions increase from 10 to 100, for 10AxS the conflcitDetection algorithm requires 6 s more in BPA, while in CAPA it requires just 3.

On the other hand, it is observed that these issues become even more evident as AxS increases. For 10AxS the conflcitDetection algorithm requires 6 and 3 more s in BPA and CAPA respectively when the conditions increase from 10 to 100, but for 100AxS CAPA requires 5 more s and in BPA the performance becomes clearly worse, requiring 24 more s. Furthermore, for 10,000 rules an increasing number of conditions at the cost of AxS also has a greater impact on performance with respect to 1000 rules. This is demonstrated by the fact that the performance of CAPA drops by just 2 s while BPA drops by 26 s.

3. addRuleToRT: when conflicts are detected, the time complexity of adding a rule to the PT of the resourceNode is theoretically defined as $O \left(1\right)$ in Section 7.2, but in practice it takes at most 1 ms for both policy analysis algorithms. Thus, it is considered non-significant.

In short, the results show that conditions are the component of the rule that has the greatest impact on the performance provided by CAPA and BPA in detecting common resource conflicts. This becomes even more critical as the number of conditions increases. In this regard, the results show that CAPA provides a better performance than BPA and is also more adaptable to an increasing number of conditions because of the dependent relationship of conditions that it supports.

8.3.3. CAPA and BPA Performance on Dependent Resource Conflict Detection

The experimental assessment only addresses the detection of dependent resource conflicts between the deepest resource within the RT and its parent. That is because this enables us to make a more accurate analysis of CAPA and BPA performance in this area, and the results can be extrapolated to the analysis of a larger number of dependent resources considering the time required for the backtracking process through the RT.

The dependentResourceConflictDetection algorithm performs a sequential search over the actions for each subject that are controlled for two dependent resources. So, if the product AxS is the same, for the same number of conditions then the performance provided for CAPA and BPA is observed to be the same. Therefore, to make a more comprehensive analysis, Figure 16 represents the total time that the dependentResourceConflictDetection algorithm requires to detect conflicts between the deepest resource and its parent based on AxS for 10 conditions and 100 Conditions.

For dependent resource conflict detection, CAPA also provides better performance and deals better with increasing numbers of conditions.

First, for the same number of rules, note that reducing AxS and increasing the number of conditions provides better performance. This is because of the time required for the sequential search for relevant rules for each subject in each action between dependent resources.

Second, for the same number of AxS (e.g., 10AxS), when the conditions increase from 10 to 100 CAPA shows little impact on performance, but BPA takes 500 ms longer. Furthermore, as the number of AxS increases, performance becomes even more critical. For 100AxS CAPA also shows the same performance for 10 and 100 Conditions, but in BPA there is a drop of 16 s.

Therefore, although the product of AxS seems to be critical for dependent resource conflict detection, the fact that CAPA supports the dependent relationship of conditions means that it not only always provides better performance but also reduces the impact of increasing numbers of conditions.

9. Conclusions

Data sharing has become one of the main barriers to making significant progress in the energy sector. To solve this issue, data sovereignty must be ensured through DUC solutions. In this regard, it is essential to ensure security in DUC through policy quality.

On the understanding that context-aware control is one of the main new challenging features in the DUC context with respect to AC scenarios for providing data sovereignty in distributed ecosystems, this paper highlights its increased impact on policy quality and the challenges that it poses for efficient policy analysis. Not supporting conditions for policy analysis in DUC significantly increases the appearance of low-quality policies, leading to security breaches which may jeopardize the adoption of distributed collaborative ecosystems, but an efficient policy analysis which supports a wide set of heterogeneous conditions is challenging with respect to existing AC policy analysis approaches.

Accordingly, this paper presents CAPA, a tree-based modeling policy analysis algorithm for secure DUC approaches that ensures policy consistency and minimality for context-aware policies. To that end, CAPA is supported on previous AC policy analysis approaches: a consolidated area of research. Formalization and application to a wind energy use case shows that CAPA avoids security issues in DUC solutions, thus, facilitating data sharing throughout the value chain which have allowed and will allow researchers to advance in the knowledge of efficient wind energy generation. Furthermore, due to the complexity introduced by conditions and the lack of policy analysis algorithms that support them, it is not possible to compare performance with CAPA. However, by implementing a basic policy analysis algorithm (BPA), it is proven that CAPA significantly improves the performance provided in the policy analysis process by supporting the dependent relationship of conditions.

In conclusion, although data sharing presents great benefits, it depends largely on the implementation of secure, high-performance DUC solutions. In this regard, implementing good-quality policies is of the utmost importance. This paper addresses one of the main challenges in DUC: support for context-aware policies for policy consistency and minimality.

Future work will focus on extending CAPA to permit the real-time analysis of new rules by efficiently comparing them with relevant rules previously defined, analyzed, and thus stored in the tree structure. Completeness and relevance will be also addressed by complementing CAPA with transaction-based analysis is to provide full policy quality. Finally, the impact of action requirements on policy quality will be analyzed in depth, and an extension of CAPA will be studied to include adequate support for them. Additionally, based on the idea that ensuring security by detecting all the conflicts is crucial to promote data sharing, other approaches followed in the AC domain for policy analysis, different from tree-based modelling, will be explored. This analysis will have a particular focus on their ability to adapt to the complexity introduced by the DUC model, and, if any, comparing the performance provided with respect to CAPA. Moreover, unlike AC, policies in DUC are differently implemented by the data provider and consumer, negotiated and agreed to be afterwards enforced. In this regard, the applicability of CAPA in the policy negotiation process will be studied to ensure good quality agreed policies. Finally, future work will also address ongoing work related to the extraction of knowledge from the wind energy value chain, as the number of stakeholders and data grows, to make significant progress in its performance.