A Systematic Approach toward Extracting Technically Enforceable

Policies from Data Usage Control Requirements

Arghavan Hosseinzadeh, Andreas Eitel and Christian Jung

Fraunhofer IESE, Kaiserslautern, Germany

Keywords:

Data Sovereignty, Data Usage Control, Industrial Data Space, MYDATA Control Technologies, Policy

Classes, ODRL Policy Templates, Policy Speciﬁcation, Policy Transformation, Policy Negotiation.

Abstract:

Solutions for data sovereignty are in high demand as companies are willing to exchange their data in decen-

tralized infrastructures. Data sovereignty is tightly coupled with data security and therefore, with data usage

control policy speciﬁcation. In this paper, we propose an approach to facilitate the processes of policy spec-

iﬁcation by data owners, policy transformation from a technology-independent to a technology-dependent

language, and policy negotiation between the parties who exchange their data. We extracted an enterprise-

relevant set of policy classes from the parties’ security requirements in order to implement an editor that sup-

ports users in creating their machine-readable policies. Then, we developed an algorithm that beneﬁts from

the policy classes and constructs technology-dependent security policy instances. In addition, we proposed a

policy negotiation approach which is based on the parameters of the extracted policy classes.

1 INTRODUCTION

The digital transformation affects many companies

that are striving for industry 4.0. According to (Pauer

et al., 2018), 79 percent of large enterprises and 70

percent of SMEs faced very strong changes due to

digitization over the past ﬁve years. The authors state

that data exchange between companies is an essen-

tial feature of digitization and data economy. Al-

though data exchange is nothing new, it becomes

more complex as companies are able to collect more

data records in their silos and as they are going to

link them. Data alone does not create any societal

or economic added value, but if data is turned into

information, they clearly bring an economic added

value. This transformation can be achieved, for ex-

ample, by enrichment, such as data analytics or by

adding context information to data. Besides, data an-

alytics enables companies to generate new informa-

tion out of their existing data. Due to these possi-

bilities, data have become an economic good in their

own right. These changes enable companies to de-

velop new business models and bring new products

to the market. With all these changes, challenges and

barriers arise during data exchange. Companies be-

gin to fear that sensitive information (e.g., core data

and business secrets) could be exposed (Pauer et al.,

2018). In addition, companies ﬁnd it problematic that

they cannot control who will read their data (Pauer

et al., 2018) and how it will be used. In order to ad-

dress this issue, a joint committee of members from

business, politics and research launched the Indus-

trial Data Space (IDS) at the end of 2014 (Otto et al.,

2016).

One of the core concepts of the IDS architecture

is to provide a virtual data space for the secure decen-

tralized exchange of data. IDS is based on a common

governance model, thus provides data sovereignty for

data owners. Realizing data sovereignty in such an

architecture is a complex task and comes along with

many challenges such as proper description of data

access and usage restrictions and their technical en-

forcement on both data provider and data consumer

sides. In the IDS context, a data provider (data owner)

is an IDS party that offers his data on the IDS platform

together with the terms and conditions of using that

data; a data consumer is an IDS party that requests to

use the provided data.

In general, policy managers can specify the data

usage restrictions using various policy speciﬁcation

languages. These languages primarily differ in their

degree of formalization. For instance, a policy may

be expressed in natural language (e.g., “use my data

only for billing and delete it after ten days”) or in

a more formal language (e.g., “purpose: billing, duty:

Hosseinzadeh, A., Eitel, A. and Jung, C.

A Systematic Approach toward Extracting Technically Enforceable Policies from Data Usage Control Requirements.

DOI: 10.5220/0008936003970405

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 397-405

ISBN: 978-989-758-399-5; ISSN: 2184-4356

397

delete after 10 days”). In fact, most organizations

have high-level requirement speciﬁcation expressed

in natural language. Extracting the machine-readable

policies from their requirements is a considerable

challenge for them (Narouei et al., 2018). More-

over, the IDS Reference Architecture Model (Otto

et al., 2018) does not impose a speciﬁc usage con-

trol technology and therefore, the IDS customers may

use different technologies in order to enforce their

security demands. Therefore, there is a need to de-

scribe the data usage restrictions in a technology-

independent way. Besides, comparing policies is eas-

ier in a common machine-readable format than in nat-

ural language or in multiple technology-dependent

languages. Therefore, the IDS stakeholders agreed

on using the W3C standard Open Digital Rights Lan-

guage (ODRL) (Iannella and Villata, 2018) to specify

data usage restrictions in a technology-independent,

machine-readable way, hereinafter referred to as

“Speciﬁcation Level Policy” (SLP). It is easily inter-

pretable by the parties as well as their systems, and

can later be translated to any technology-dependent

language and eventually be enforced within the IDS

parties’ systems. An IDS party may use a usage

control technology like MYDATA (Fraunhofer IESE,

2018a) that has its own expressive language (Fraun-

hofer IESE, 2018b). We call the policies that are

speciﬁed in such a technology-dependent language,

“Implementation-Level Policies” (ILP).

In a platform like IDS, a data provider speci-

ﬁes the provider-side and consumer-side SLPs. The

provider-side policies are used to apply modiﬁcations

on the data before it is transferred, and they control

subsequent data access. The consumer-side policies

impose usage restrictions on the data consumer sys-

tems.

This paper describes an approach to enhance the

entire process of policy speciﬁcation in a context such

as IDS. The idea is to extract a set of policy classes

from the stakeholders’ requirements and to build a

corresponding ODRL policy editor that assists stake-

holders in specifying their SLPs. Policy classes are

also used to derive the mapping rules that translate

ODRL policies into MYDATA policies in a policy

transformation service. As illustrated in Figure 1,

a data provider can use the policy transformation

service in order to semi-automatically translate his

provider-side SLP (ODRL policy) to ILP (e.g., MY-

DATA policy) and then, enforce the generated MY-

DATA policy within his system. A data consumer can

as well use the policy transformation service to trans-

form the consumer-side SLP into an ILP, succeeding

a policy negotiation process. This paper also explains

how the policy classes facilitate the policy negotiation

Figure 1: An ODRL policy editor is used to specify the

provider-side and consumer-side ODRL policies. A pol-

icy transformation service translates them to a technology-

dependent policy language such as MYDATA. A consumer-

side policy has to be negotiated and conﬁrmed by both data

providers and data consumers before it is translated and en-

forced.

process between data providers and data consumers

by clarifying the policy negotiation parameters.

2 RELATED WORK

A policy editor can be used to facilitate the process

of specifying ODRL policies. ODRL experts pro-

vide an ODRL policy editor that supports users in

this task with a user-friendly interface (Lorenzo and

Rodr

ıguez-Doncel, 2018). The advantage of using

such an editor is that the generated ODRL policies

are validated and that users do not need to deal with

the syntax of the language. However, this editor

does not ensure that the generated policies reﬂect the

user’s actual demands. Therefore, they need to verify

for themselves whether the generated policies express

their usage control restrictions as intended.

Besides, Rudolph et al. suggested to collect

Speciﬁcation-Level Policy Templates (SLPTs), which

are the blueprints for the SLPs, to generate a suitable

security policy editor in natural language (Rudolph

et al., 2016). Persuing their framework, the speciﬁ-

cation of ILPTs is a manual task that has to be per-

formed by technology experts. Our method adopted

this approach and extended it to enhance the speciﬁ-

cation of ILPs as well as the policy negotiation pro-

cess.

According to (Pretschner and Walter, 2008), the

element of surprise is a part of a negotiation among

people and is unlikely to occur in an automated nego-

tiation. It introduces new dimensions and valuations

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

398

over the lifetime of the negotiation process. In this pa-

per, we reﬁne the parameters that are negotiated with

respect to the requirements in order to approximate

our semi-automated negotiation process to a human-

like approach.

3 POLICY SPECIFICATION

In the IDS context, policy speciﬁcation is about deﬁn-

ing security restrictions using the ODRL policy lan-

guage and transforming them into ILPs such as a MY-

DATA policy. In this paper, we propose an approach

to build an ODRL policy editor that not only vali-

dates the policies but also supports users by provid-

ing predeﬁned templates that are speciﬁc to their re-

quirements. As shown in Figure 2, the ﬁrst step is the

collection and reﬁnement of all IDS use cases related

to Data Usage Control. In a second step, the usage

control requirements are derived and clustered as nat-

ural language constructs. Section 3.1 describes these

constructs, also called policy classes, which form the

basis to create ODRL policy templates. Next step is

about mapping the policy classes to their correspond-

ing ODRL policy templates. An exemplary ODRL

policy template is explained in Section 3.2. Finally,

the mapping rules from ODRL language to MYDATA

language are extracted by studying these policy lan-

guages and with respect to the existing policy classes

and consequently, a system that semi-automatically

translates an ODRL policy template to a MYDATA

policy template is developed. Overall, this approach

can be generalized and also used for other ILPs.

Figure 2: Policy speciﬁcation approach.

3.1 Policy Classes

We collected Data Usage Control related use cases

from various application scenarios such as Digital

Supply Chain, Interconnected Enterprise Social Net-

works (ESN), Smart Urban Mobility, IDS Connectors

and Intelligent Sensors. Many of the collected use

cases reoccur (or can be applied) in different contexts.

We manually assigned each use case to a more ab-

stract class regardless of their context. Eventually, we

ended up with a list of fourteen elaborated classes of

policies:

1. Allow the usage of the data

2. Deny the usage of the data

3. Restrict the data usage for a group of users or sys-

tems

4. Restrict the data usage for speciﬁc purposes

5. Restrict the data usage when a speciﬁc event has

occurred

6. Delete data immediately after (one) use

7. Modify data in transit

8. Modify data at rest

9. Allow data usage at most N times

10. Allow data usage only within a speciﬁc time in-

terval

11. Log the data usage information

12. Notify a party when data is used

13. Share the data only under speciﬁc circumstances

14. Impose restrictions on the ﬁne-grained actions

The use cases that only addressed the permission

or prohibition of data usage were assigned to the ﬁrst

two policy classes. The use cases that restrict the us-

age of data to amount of usage or a speciﬁc time inter-

val or depending on the receiver systems, usage pur-

poses or occured events were assigned to the next dis-

tinguishable policy classes. Moreover, the use cases

that focus on deleting data, modifying data, sharing

data, logging information and notifying users were

assigned to their corresponding policy classes. Fi-

nally, the use cases that impose speciﬁc restrictions to

the ﬁne-graned actions (e.g., restricting the resolution

when printing data) were categorized as last deﬁned

policy class.

Although, these classes may be extended as IDS

requirements grow, we were satisﬁed for the time

being with supporting the policy classes mentioned

above and creating respective ODRL policy tem-

plates.

3.2 ODRL Policy Language

The ODRL information model is the foundational ba-

sis for the ODRL policy semantic and describes the

concepts, entities and their relationships (Iannella and

Villata, 2018). ODRL policies represent not only per-

missions and prohibitions of actions over a data as-

set (as ODRL rules) but also additional restrictions

A Systematic Approach toward Extracting Technically Enforceable Policies from Data Usage Control Requirements

399

Listing 1: Sample ODRL policy template.

1 {

2 ” @type ” : ? ,

3 ” u i d ” : ” h t t p : / / example . com / p o l i c y :

r e s t r i c t −u s a g e ” ,

4 ” p e r m i s s i o n ” : [ {

5 ” t a r g e t ” : ? ,

6 ” a s s i g n e r ” : ? ,

7 ” a s s i g n e e ” : ? ,

8 ” a c t i o n ” : ” u se ” ,

9 ” c o n s t r a i n t ” : [ {

10 ” l e f t O p e r a n d ” : ” d a t e t i m e ” ,

11 ” o p e r a t o r ” : ” g t ” ,

12 ” r i g h t O p e r a n d ” : { ” @value ” : ? ,

13 ” @type ” : ” x s d : d a t eT i me ” }

14 } , {

15 ” l e f t O p e r a n d ” : ” d a t e t i m e ” ,

16 ” o p e r a t o r ” : ” l t ” ,

17 ” r i g h t O p e r a n d ” : { ” @value ” : ? ,

18 ” @type ” : ” x s d : d a t eT i me ” }

19 } ]

20 } ]

21 }

and obligations as ODRL constraints and duties, re-

spectively. The ODRL vocabulary describes the terms

and expressions used in ODRL as well as how to en-

code them (Iannella et al., 2018). Both, the ODRL

information model and the ODRL vocabulary serve

as the core framework and represent the minimally

supported expressiveness of ODRL language. ODRL

proﬁles extend the vocabulary by new terms in order

to enhance an ODRL policy with additional seman-

tics.

As a second step of our policy speciﬁcation ap-

proach (shown in Figure 2), we manually created the

ODRL policy templates that represent the previously

mentioned policy classes. Obviously, there are some

values that need to be ﬁlled in by the policy manager.

For example, Listing 1 represents an ODRL policy

template for the policy class No. 10, ”Allow data us-

age only within a speciﬁc time interval”.

The type ﬁeld of the template accepts the follow-

ing values: set, offer, request and agreement. A set

policy is deﬁned by IDS infrastructure. An offer pol-

icy is offered by the assigner that denotes the data

provider in IDS. A request policy is proposed by the

assignee that denotes the data consumer in IDS, and

an agreement policy is a policy that has been con-

ﬁrmed by both data provider and data consumer af-

ter a preceding negotiation process. In the IDS con-

text, all ODRL rules of an agreement policy are de-

ﬁned by exactly one assigner and address exactly one

speciﬁc assignee. After ﬁlling in the type, assigner

and assignee values in the template, a policy manager

only needs to add the target data asset for the policy as

well as the start and end dates for his demanded time

interval in order to instantiate the intended ODRL pol-

icy. The datetime left operand together with its corre-

sponding type, xsd:dateTime, forms the time interval

constraint placeholder. The given value for the start

and end time will be added as right operands of these

pre-deﬁned constraints. In summary, the ODRL pol-

icy templates serve as a list of necessary ODRL ac-

tions, constraints and operators that are important in

the IDS context.

3.3 ODRL Editor

It is not sufﬁcient to only create a set of ODRL pol-

icy templates, since users still need further support in

choosing the proper template and ﬁlling in the empty

ﬁelds. Therefore, an ODRL editor is required. Such

an ODRL editor is described in (Fraunhofer IESE,

2019). A policy manager only needs to choose a tem-

plate from the classes that are listed on the left side

of the editor, as shown in Figure 3, and ﬁll in the re-

quired ﬁelds. The assigner ﬁeld is automatically set

to the unique ID of the data provider and the editor

may provide more data, such as list of provided data

and consumers, to assist the data provider in specify-

ing the policy. Figure 3 also shows an instance of an

ODRL policy created in the editor.

4 POLICY TRANSFORMATION

In order to transform an ODRL policy into a MY-

DATA policy, a set of mapping rules need to be ap-

plied. However, extracting a complete set of mapping

rules is a rather complex task, yet we can use our pol-

icy classes to facilitate the derivation of the mapping

rules required to transform SLP into ILP. In this sec-

tion, we explain the MYDATA policy language and

the algorithm for policy transformation.

4.1 MYDATA Policy Language

According to (Otto et al., 2016), data sovereignty en-

ables the data owner to deﬁne the terms of use of

his data assets. The Data Usage Control concept

extends different approaches of policy enforcement,

such as traditional Access Control mechanisms or

Digital Rights and Trust Management, and in doing

so, it realizes the data sovereignty concept of the IDS.

Data Usage Control adds restrictions to data in or-

der to control their future usage (Jung et al., 2014),

(Kelbert and Pretschner, 2012), (Pretschner et al.,

2008). In fact, it ensures that the receiver–after ac-

quiring the data–utilizes the data as described in the

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

400

a b

Figure 3: ODRL policy editor.

trol Technologies is a technical implementation of

Data Usage Control. It is based on the IND

UCE

framework (Fraunhofer IESE, 2018a) for Data Us-

age Control developed at Fraunhofer IESE. MYDATA

uses Policy Enforcement Points (PEPs) to implement

data sovereignty by monitoring or intercepting data

ﬂows. PEPs communicate with a Policy Decision

Point (PDP) that utilizes policies and other compo-

nents to make decisions. In addition, MYDATA pro-

vides a Policy Management Point (PMP) to manage

all the components and policies. The ability to adapt

the policies at any time makes the implementation of

data sovereignty very ﬂexible and adaptable to vari-

ous (also future) usage scenarios in the IDS.

The MYDATA policy language (Fraunhofer IESE,

2018b) is an XML-based language to express restric-

tions on data usage. It represents a policy as a set

of mechanisms that can describe the rules and actions

of an ODRL policy based on monitored, intercepted

or time triggered events. A MYDATA mechanism is

an if-then-else statement in which the conditions are

speciﬁed in the if-clause and the decision about allow-

ing or denying the data usage is speciﬁed in the then-

and else-clauses. The MYDATA policy language pro-

vides boolean and arithmetic logic as well as several

functions (e.g., date and time) to express the condi-

tions. In addition, it provides the connection to exter-

nal systems, called Policy Information Points (PIPs),

for information retrieval. It also provides execution of

actions using Policy Execution Points (PXPs) and en-

forcement of data modiﬁcation using MYDATA mod-

iﬁers (Fraunhofer IESE, 2018b).

4.2 Mapping Rules

We use the ODRL policy templates, which are based

on the policy classes, to create technology-dependent

MYDATA policies by mapping ODRL policy actions,

constraints and operators to MYDATA events, func-

tions and operators. Algorithm 1 implements the re-

quired mapping rules receiving an ODRL policy as

an input. In addition, it must be speciﬁed whether

the policy is a provider-side policy or a consumer-side

policy. This input will be given as a ﬂag to later set

the enforcement scope of the MYDATA policy, called

MYDATA solution. By running the algorithm, a MY-

DATA policy is generated and a policy identiﬁer is

assigned to it. For each ODRL rule that is speciﬁed

in the given ODRL policy, a corresponding MYDATA

mechanism is created. Then, for all reﬁnements and

constraints of the given ODRL policy, a condition is

deﬁned and ﬁnally, the rule type (permission or prohi-

bition) is speciﬁed as decision of the MYDATA pol-

icy.

We studied the policy classes to deﬁne the map-

ping rules for specifying the conditions. For each

ODRL duty or constraint, an equivalent function in

MYDATA policy language is used if available. Oth-

erwise, the algorithm creates a general condition that

is deﬁned by a PIP. For example, in order to specify

the ODRL constraint shown in Listing 2, the algo-

rithm speciﬁes a condition that uses a PIP to retrieve

the purpose of usage and is satisﬁed when the purpose

is ”marketing”.

A Systematic Approach toward Extracting Technically Enforceable Policies from Data Usage Control Requirements

401

Listing 2: ODRL Purpose Constraint.

1 ” c o n s t r a i n t ” : [ {

2 ” l e f t O p e r a n d ” : ” p u r p o s e ” ,

3 ” o p e r a t o r ” : ” eq ” ,

4 ” r i g h t O p e r a n d ” : { ” @value ” : ” M a r k e t i n g

” , ” @type ” : ” x sd : s t r i n g ” }

5 } ]

Overall, in order to transform an ODRL policy

into a policy that is speciﬁed in any other ILP than

MYDATA, we can follow the same mapping rules and

update the algorithm, correspondingly.

5 POLICY NEGOTIATION

A negotiation is a process that occurs between at least

two parties about a certain subject and is driven by

their demands (Bennicke et al., 2003). In a policy ne-

gotiation process in the IDS, the subject is the Data

Usage Control policy, and the demands reﬂect the

involved parties’ security and privacy requirements.

Thus, an agreed policy is the outcome of the process.

Data consumers may have different data us-

age preferences and system architectures than data

providers and use different policy enforcement tech-

nologies. Therefore, they may request changes on

the consumer-side policies that are published by the

data providers on the IDS platform. In the context

of the IDS, an offer policy addresses the usage policy

of a speciﬁc data asset. A data consumer evaluates

whether it is possible to technically enforce the offer

policy at the data consumer side and whether the pol-

icy complies with his demands. For example, when

the data consumer requires to use the data in a spe-

ciﬁc time interval, the policy needs to be evaluated to

check whether it is offering the usage of data within

that desired time slot. After the evaluation, either the

data consumer entirely agrees to the conditions spec-

iﬁed in the offered policy, or it requires to slightly

change the policy. Consequently, the data consumer

creates a suitable request policy, attaches it to a re-

quest message and sends it to the data provider. The

policy negotiation process is initiated as soon as the

data consumer sends the request message to the data

provider as shown in the Figure 4. The data provider

evaluates the received request policy and creates a

corresponding new offer policy and send it back to the

data consumer. The parties may build their own pol-

icy evaluation components that automatically evalu-

ate the received policies and generate the correspond-

ing new offer or request policies. The policy nego-

tiation process continues until the data provider and

data consumer agree on a Data Usage Control policy

that addresses their needs and can be enforced within

their systems. When the request policy matches the

offer policy, the data provider creates an agreement

policy, and sends it to the data consumer as an agree-

ment message. Next, the data consumer has to ac-

knowledge the agreement policy. The data provider

can always send a reject message as a reply to a re-

quest message and thus require to terminate the policy

negotiation process.

It might be a drawback of an automated policy ne-

gotiation process that the data consumer can create

new request policies aiming to achieve an agreement

with the least restrictions. However, the policy nego-

tiation process is not necessarily about achieving an

agreement that minimizes the security restrictions of-

fered by the data provider, but it is about achieving

an agreement that ﬁts best to both parties’ demands

and the technical feasibility of the enforcement tech-

nologies. In fact, the demands may have inverse cor-

relations. For example, a data provider may accept

that the data consumer uses the data in a different sys-

tem and for different purposes than originally offered,

but may in return insist on a shorter usage period.

However, the details of the policy negotiation process,

such as where the policy evaluation component is lo-

cated or the mode of operation of the time-out han-

dling mechanism, is not the focus of this paper, but

rather the policy negotiation approaches and their pa-

rameters.

5.1 Policy Negotiation Approaches

In an ideal case, the negotiation process lasts only

for one round since the data consumer accepts an of-

fer policy as it is published and the data provider is-

sues the agreement policy accordingly. At most, a

data provider provides the possibility to choose N out

of M optional ODRL policy rules and the data con-

sumer then selects those rules that match his demands.

We call this approach a fully automated approach in

which no further modiﬁcation of the offered policies

is accepted. On the other hand, in order to automate a

human-like interactive approach with no restrictions,

the parties need to build the policy evaluation com-

ponents that interpret and deﬁne the policies like hu-

mans. This is a very complex task. Therefore, we pro-

pose to build a policy evaluation component that ben-

eﬁts from the extracted policy classes and evaluates

the received policies, accordingly. Also, it generates a

corresponding new policy with or without user inputs.

As listed in Table 1, the interactive approach with lim-

ited modiﬁcations provides a platform that uses such a

proposed policy evaluation component and allows the

parties to negotiate over predeﬁned, known negotia-

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

402

Algorithm 1: Transform ODRL Policy to a MYDATA Policy.

Input: ODRLPolicy op, bool provider-side

Output: MYDATAPolicy mp

1: MYDATAPolicy mp := NULL;

2: Mechanism mech := NULL;

3: function transformODRLtoMYDATA(op, provider-side)

4: mp := createMYDATAPolicy();

5: mp.pid := op.pid;

6: if provider-side = true then

7: mp.solution := op.rules[0].assigner;

8: else

9: mp.solution := op.rules[0].assignee;

10: end if

11: for all Rule rule in op.rules do

12: mech := createMechanism();

13: mech.event := rule.action;

14: mech.conditions.add(createPIPCondition(”target”, ”equal”, rule.target));

15: if rule.duty is not NULL then

16: if rule.duty 6= ”anonymize” then

17: mech.conditions.add(createPXP(rule.duty.action, rule.duty.reﬁnement));

18: else

19: mech.conditions.add(createModifyFuntion(rule.duty.reﬁnement));

20: end if

21: end if

22: //The same for refinements

23: if rule.constraints is not empty then

24: for all Constraint rc in rule.constraints do

25: if rc.leftOperand = ”event” then

26: mech.conditions.add(createCountCondition(rc.rightOperand, 1));

27: else if rc.leftOperand = ”count” then

28: mech.conditions.add(createCountCondition(rule.action, rc.rightOperand));

29: else if rc.leftOperand = ”dateTime” then

30: mech.conditions.add(createDateAndTimeCondition(rc.operator, rc.rightOperand));

31: else

32: mech.conditions.add(createPIPCondition(rc.leftOperand, rc.operator,

rc.rightOperand));

33: end if

34: end for

35: end if

36: if rule.rule = ”permission” then

37: mech.decision := ”allow”;

38: else if rule.rule = ”prohibition” then

39: mech.decision := ”inhibit”;

40: end if

41: mp.mechanisms.add(mech);

42: end for

43: return mp;

44: end function;

tion parameters. This approach does not support un-

limited adjustments and modiﬁcations, however, the

data provider and data consumer parties may collabo-

rate when the human interaction is needed. For exam-

ple, when a data consumer proposes a new time slot,

the policy evaluation component detects the changes

and can decide autonomously whether the request is

accepted or not by comparing the proposed time slot

with the deﬁned demands (e.g., it can be demanded

that the proposed time slot does not cross the lim-

A Systematic Approach toward Extracting Technically Enforceable Policies from Data Usage Control Requirements

403

Table 1: The policy negotiation approaches.

Unlimited ad-

justments

Further policy eval-

uation

Applicable in IDS

context

Human-like approach 3 3 5

Fully automated approach 5 5 3

Interactive approach with limited

modiﬁcations

5 3 3

Figure 4: Policy Negotiation sequence diagram.

ited duration of one month). On the other hand, when

a data consumer requests to use the data for differ-

ent purposes than what has been offered, the approval

of the detected request may need the data provider’s

manual intervention.

5.2 Policy Negotiation Parameters

We extracted the parameters that can be modiﬁed and

thus negotiated during the policy negotiation process,

with respect to the policy classes. To this end, we cat-

egorized the policy negotiation parameters into ﬁve

groups: decision, condition left operand, condition

right operand, modiﬁcation method and action.

• Decision: In a ﬁrst place, one can negotiate over

a decision that is proposed in a Data Usage Con-

trol policy. Although, the request to change the

decision of a policy (e.g., from prohibition to per-

mission) is not frequently demanded, it still is a

valid change. For example, a data provider pro-

vides an offer policy consisting of various rules,

one of which inhibits the data consumer to print

the data. In this case, it is worthwhile that the data

consumer requests printing permission while ac-

cepting the other rules.

• Condition Left Operand: As described in Sec-

tion 3.1, the stakeholders control the usage of

data by restricting the usage to speciﬁc dates, time

slots, systems, purposes, roles or users as well as

on occurrences of speciﬁc events. In fact, one can

negotiate about the left operands of these condi-

tions. For example, a data provider may propose

an offer policy that restricts the usage of data to

marketing purposes. Here, a data consumer can

request to restrict the data usage to marketing sys-

tems instead.

• Condition Right Operand: In most cases, the

parties negotiate not to change a condition left

operand, but to adjust the value, called right

operands, that is assigned to it. The right operands

and their corresponding value types must be cer-

tainly deﬁned and known to the parties, since they

deﬁne under which circumstance a condition is

satisﬁed. Correspondingly, the policy evaluation

components can detect and evaluate the proposed

right operands and decide whether they accept it

or not.

• Modiﬁcation Method: Some policy classes de-

scribe that IDS use cases require data modiﬁca-

tion and data anonymization (at rest or in tran-

sit). The modiﬁcation method (e.g., aggregate or

delete sensitive information) is also a parameter

that is negotiable between data provider and data

consumer.

• Action: The policy action is another policy ne-

gotiation parameter. For example, a policy eval-

uation component on the data provider side may

automatically accept a data consumer’s request to

print the data on paper rather than displaying it

or to send a notiﬁcation rather than sending the

entire usage logs. The data provider may conﬁg-

ure the policy evaluation component by setting the

exchangeable actions that are equally acceptable.

Using such a predeﬁned table, the least interven-

tion of the data provider is required to obtain an

agreement.

Overall, the policy negotiation parameters may

expand according to the updates on the policy classes.

6 CONCLUSIONS

In this paper, we used the policy classes that are

extracted from the IDS requirements speciﬁcation

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

404

as a basis for a systematic approach to create the

technology-dependent policies. Since the companies’

requirements evolve over time, the extracted policy

classes must be updated or extended accordingly. The

policy templates, policy transformation rules and the

policy negotiation parameters will be updated as well

and therefore, the IDS platform can claim to support

users in their policy speciﬁcation process. As a fu-

ture work, we plan to implement our proposed policy

negotiation platform and attach it to our policy editor.

ACKNOWLEDGEMENTS

This research has been funded by the Federal Min-

istry of Education and Research (BMBF) of Germany

in the project ”Architekturtopologien f

ur Datensou-

ver

anit

at in Gesch

afts

okosystemen auf Basis des In-

dustrial Data Space” (grant agreement number FKZ

01IS17031).

REFERENCES

Bennicke, M. et al. (2003). Towards automatic negotiation

of privacy contracts for internet services. In The 11th

IEEE International Conference on Networks, 2003.

ICON2003., pages 319–324. IEEE.

Bussard, L., Neven, G., and Preiss, F.-S. (2010). Down-

stream usage control. In 2010 IEEE International

Symposium on Policies for Distributed Systems and

Networks, pages 22–29. IEEE.

Fraunhofer IESE (2018a). Mydata control technologies.

https://www.mydata-control.de/.

Fraunhofer IESE (2018b). Mydata policy language docu-

mentation. version 3.2.69. https://developer.mydata-

control.de/language/.

Fraunhofer IESE (2019). Odrl pap. http://odrl-pap.mydata-

control.de/.

Iannella, R., Steidl, M., Myles, S., and Rodr

ıguez-Doncel,

V. (2018). Odrl vocabulary & expression 2.2.

https://www.w3.org/TR/odrl-vocab/.

Iannella, R. and Villata, S. (2018). Odrl information model

2.2. https://www.w3.org/TR/odrl-model/.

Jung, C., Eitel, A., and Schwarz, R. (2014). Enhancing

cloud security with context-aware usage control poli-

cies. In GI-Jahrestagung, pages 211–222.

Kelbert, F. and Pretschner, A. (2012). Towards a policy

enforcement infrastructure for distributed usage con-

trol. In Proceedings of the 17th ACM symposium on

Access Control Models and Technologies, pages 119–

122. ACM.

Lorenzo, G. G. and Rodr

ıguez-Doncel, V. (2018). Odrl ed-

itor. http://odrleditor.appspot.com/.

Narouei, M., Takabi, H., and Nielsen, R. (2018). Automatic

extraction of access control policies from natural lan-

guage documents. IEEE Transactions on Dependable

and Secure Computing.

Otto, B., Auer, S., Cirullies, J., J

urjens, J., Menz, N., Schon,

J., and Wenzel, S. (2016). White paper: Industrial data

space. http://s.fhg.de/juA.

Otto, B. et al. (2018). Ids reference architecture model. in-

dustrial data space. version 2.0. http://s.fhg.de/2Qu.

Pauer, A., Nagel, L., Fedkenhauser, T., Fritzsche-Sterr, Y.,

and Resetko, A. (2018). Data exchange as a ﬁrst step

towards data economy. http://s.fhg.de/EAr.

Pretschner, A., Hilty, M., Basin, D., Schaefer, C., and Wal-

ter, T. (2008). Mechanisms for usage control. In Pro-

ceedings of the 2008 ACM symposium on Information,

computer and communications security.

Pretschner, A. and Walter, T. (2008). Negotiation of usage

control policies-simply the best? In 2008 Third In-

ternational Conference on Availability, Reliability and

Security, pages 1135–1136. IEEE.

Rudolph, M., Moucha, C., and Feth, D. (2016). A frame-

work for generating user-and domain-tailored secu-

rity policy editors. In 2016 IEEE 24th Interna-

tional Requirements Engineering Conference Work-

shops (REW), pages 56–61. IEEE.

A Systematic Approach toward Extracting Technically Enforceable Policies from Data Usage Control Requirements

405