Towards a Declarative Approach to Stateful and Stateless Usage Control

for Data Protection

Francesco Di Cerbo

, Fabio Martinelli

, Ilaria Matteucci

and Paolo Mori

Security Research, SAP, France

IIT-CNR, Italy

Keywords:

Personal Data Protection, GDPR, Privacy, Security.

Abstract:

Virtually any online website or service has a rising need for data protection mechanisms, especially for per-

sonal data, considering initiatives such as the new General Data Protection Regulation to operate on the EU

economic space, or the Cybersecurity Law for the Chinese market. It seems therefore necessary to dispose of

mechanisms that help both users, as well as legal experts and practitioners to automatically manage the pro-

cessing of personal and sensitive data in a secure and compliant manner, to reduce the probability of human

errors. To this aim, we show here our initial proposal for an automatically enforceable policy language, UPOL,

for access and usage control of personal information, aiming at transparent and accountable data usage. UPOL

extends and combines previous research results, U-XACML and PPL, and it is part of a more general proposal

to regulate multi-party data sharing operations. A use case is proposed, considering challenges brought by the

new EU’s GDPR.

1 INTRODUCTION

The advent of the new European General Data Privacy

Regulation (GDPR Regulation (EU) 2016/679) (Eu-

ropean Parliament and Council, 2016), entered in

force in May 2018, changed the legal framework and

the requirements for data processing of European ci-

tizens. Such changes are applicable for all entities,

anywhere in the world, that process EU personal data.

At least the same magnitude of changes are reque-

sted to actors operating on the Chinese market, ac-

cording to the prescriptions recently (Bird and LLC,

2018) published in the framework of the Chinese Cy-

ber Security Law (Standing Committee of the Nati-

onal People’s Congress, 2017). This imposes, to all

such entities, modiﬁcations in their processes and li-

kely in their software to be compliant with the new

prescriptions.

In our work, we focussed in particular on a num-

ber of key requirements of GDPR that are also simi-

larly prescribed by the Chinese law. These require-

ments are formalised in Articles 5 and 25as follows:

“lawfulness, fairness and transparency”, “purpose

limitation” and “data minimisation”.

The “lawfulness, fairness and transparency”

principle refers to the mandated requirements for a

data processing, taking the point of view of the data

subject (i.e., the owner of the personal data). The

“purpose limitation” principle requires data proces-

sing to take place only for pursuing predetermined ob-

jectives (or purposes), explicitly accepted by the data

subject (explicit consent) with a contract prepared un-

der the fairness and transparency principles. “Data

minimisation” imposes to data controllers (e.g., com-

panies collecting personal data of customers) to re-

duce the amount of collected data to the strict mini-

mal necessary to carry out the requested service, also

reducing “the extent of processing, the period of their

storage and their accessibility”.

In the past, a number of research results had si-

milar objectives. In particular, we observed that the

security features of access and usage control seem to

fulﬁll the data minimisation requirement in the part

that refers to computation purpose veriﬁcation, data

retention and data access. Access control refers to the

ability of permitting or denying requests to access a

resource, according to a predetermined policy or con-

ﬁguration. Multiple access control models exist, from

access control lists where authorized requesting sub-

jects, operations and resources are explicitly menti-

oned, to the more complex Attribute-Based Access

Control (ABAC) where rules are expressed on the ba-

sis of attributes of such entities (e.g. for requesting

subjects, their role in a company). Access control

308

Di Cerbo, F., Martinelli, F., Matteucci, I. and Mori, P.

Towards a Declarative Approach to Stateful and Stateless Usage Control for Data Protection.

DOI: 10.5220/0006962503080315

In Proceedings of the 14th International Conference on Web Information Systems and Technologies (WEBIST 2018), pages 308-315

ISBN: 978-989-758-324-7

ends its role when access is granted or denied; usage

control on the contrary, deals with the observation of

the usage of a resource that a requestor does, inter-

rupting or reacting dinamically to requestor’s actions

according to predetermined directives.

Our activity identiﬁed two solutions, whose com-

bination would allow a data controller to achieve

a transparent usage of personal data. T hey are

PPL (Trabelsi et al., 2010; Di Cerbo et al., 2015) and

U-XACML (Lazouski et al., 2012). The novelty of

our proposal consists of an approach (policy language

and reference architecture) that uniﬁes both beneﬁts

and allows to achieve new results, namely:

R1: to meet GDPR’s transparency requirement by

fully controlling information processing operati-

ons. This is achieved through the full support of

the Usage Control model proposed by Park and

Sandhu (Park and Sandhu, 2004; Zhang et al.,

2005), achieved through our contribution as sim-

ple extension to a well-known access control stan-

dard, XACML (OASIS, 2010)

R2: the control and tracking of processing purpose(s),

for the operations requesting an access to the pro-

tected pieces of information, both at the moment

of the access request and during their consump-

tion. This aims at meeting GDPR’s purpose limi-

tation,

R3: the support for GDPR’s data minimisation, consi-

dering for example data retention conditions.

In summary, we propose a language powerful

enough to express legal, data protection and usage

control policies in several contexts, such as the com-

pliant collection and usage of a resource in a cloud

environment and on mobile devices. Its adoption can

be part of an effort to achieve GDPR compliance in

an infrastructure.

The paper is structured as follows: next section

describes the motivation of this work that is mainly

part of a EU FP7 project named Coco Cloud about

the sharing of sensitive data through the Cloud, and

how parts of this effort are continued in project C3ISP.

Section 3 brieﬂy recalls the existing access and usage

control policy languages while Section 4 presents the

new one, named UPOL able to integrate and enhance

in a unique language the expressiveness of both lan-

guages. Section 5 presents a use case for an UPOL

policy and ﬁnally Section 6 draws the conclusion of

the paper and discusses about ongoing and future

work.

2 USAGE CONTROL IN Coco

Cloud AND C3ISP

The Coco Cloud project (Coco Cloud Consortium,

2016) aims at allowing cloud users to securely and

privately share their data in the cloud, to increase

the trust of users in the cloud services and, conse-

quently, to increase their widespread adoption. Since

companies or public bodies are involved in the data

sharing, this sharing must be regulated by real digi-

tal contracts, called Data Sharing Agreements (DSA),

which must be paired with data and enforced every

time the data are used (Caimi et al., 2015). Besides

enforcing the constraints deﬁned by the sharing par-

ties, a goal among the Coco Cloud project goals, is

to address also key challenges for legally compliant

data sharing in the cloud. Hence, the project places

an early emphasis on understanding and incorpora-

ting legal and regulatory requirements into the data

sharing agreements which are paired with the data.

The European data protection legal framework has

been one of the key legal focuses of our work.

Since the factors that are taken into account in

the data sharing agreements are mutable, i.e., they

can change over time, the policies paired with the

shared data follows the Usage Control model (Park

and Sandhu, 2004). In this way, the usage control po-

licy is continuously evaluated during the data access

time, and the access can be interrupted when the po-

licy is not satisﬁed any more. For instance, the DSA

could state that a subject can read the data only when

she is located within a given area (e.g., the building

of a company). Hence, a subject could open the docu-

ment on her mobile phone when she is located within

the building but, as soon as she exits the building, the

usage control policy (gracefully) interrupts the docu-

ment reading (for instance, it closes such document

saving the unsaved changes in a temporary document

copy). An obligation may also be attached, so that,

when the user leaves her country, the data is automa-

tically deleted from the device.

Moreover, the DSA also requires that some acti-

ons, called obligations, must be executed as a con-

sequence of the execution of other actions or when

certain events occur. For instance, the data sharing

agreement of a piece of data could include an obli-

gation, which requires that the ﬁle is deleted after a

given date. This concept has clear application in ex-

pressing a personal data retention period, according

to the GDPR. These actions can be naturally expres-

sed through obligations by adopting the Usage Cont-

rol model.

Hence, in this paper we describe UPOL, the lan-

guage we deﬁned for expressing the enforceable ver-

Towards a Declarative Approach to Stateful and Stateless Usage Control for Data Protection

309

sion of the usage control policies representing the

Coco Cloud DSAs.

The usage control model allows to deﬁne very

expressive data sharing agreements which can be

successfully applied in many scenarios. For example,

we applied it to e-government, corporate and healt-

hcare (Caimi et al., 2015) solutions. Moreover, part

of the described approach is used in C3ISP

, an EU-

funded H2020 project focussing on cyber security and

in particular on the sharing of particularly critical pie-

ces of information, that are necessary for organising

an effective defense against online attacks but that

may also be used, if in wrong hands, to conduct ma-

licious activities. This is the case of information des-

cribing cyber attacks trace logs: other defenders may

tune up their countermeasures in order to identify the

latest attacks (malware received per email, specially

crafted web requests targeting a software’s vulnera-

bility etc) but on the other hand, an attacker may get

to know where and how a target system is vulnerable

and may be successfully breached. Speciﬁc extensi-

ons are being studied and they will be discussed in the

future.

3 BACKGROUND

As mentioned, we aim at achieving the fulﬁllment of

requirements R1, R2 and R3. We identiﬁed the usage

control model as the theoretical underpinnings for our

objective but we observed a number of limitations

in the current approaches. Essentially, we looked at

a number of declarative solutions (i.e. controllable

through a conﬁguration policy) and we concentrated

on three technologies that have available implementa-

tions. They are:

• XACML it is an OASIS standard with several

open source and commercial implementations.

The main limitation is that it only covers access

control models and not usage control. It could

only partially fulﬁll R1, R2 and R3.

• U-XACML extends XACML in order to bring

some usage control functionalities, most notably

the continuous veriﬁcation of access control con-

ditions during processing of requested resources.

It can be used to fulﬁll R1, partially R2 but not

R3.

• PPL as well extends XACML with the possibi-

lity to verify resource processing purposes against

a policy plus it caters the automatic execution of

obligations deﬁned by a resource owner. It can be

homepage: https://c3isp.eu/

used to implement R3 especially with respect to

data retention, R2 but not completely R1.

From these ﬁndings, we decided to work on a new

concept, UPOL. It extends XACML, combining the

advantages brought in by two other extensions, U-

XACML and PPL, later described more in depths.

From their combination, UPOL achieves new capa-

bilities as detailed in Sections 4. It is the language

we used to express DSAs terms and conditions in a

machine-enforceable manner. UPOL policies there-

fore regulate the usage of the data they are paired

with: following the sticky policy model (Pearson and

Casassa Mont, 2011), each policy (that regulates the

access to a resource) get attached to a resource to form

a bundle, normally protected by means of strong en-

cryption. This imposes that data can be processed

only by means of special mechanisms able to decrypt

the bundle and to allow its access in accordance to

the associated policy. Any attempt to consume arbi-

trarily a resource once it is protected by such bundle,

is destined to fail. The UPOL language is based on

the Usage Control model, which extends traditional

access control model by dealing with attributes rela-

ted to the subjects and of the objects which change

their values over time. The Usage Control model al-

lows to deﬁne policies which are continuously eva-

luated during the execution of an access, in order to

revoke such ongoing access when the corresponding

policy is not valid any longer. In particular, the usage

control policies deﬁne authorization and condition ru-

les which must be satisﬁed before and/or during the

usage of such data ( pre-/ongoing-authorizations and

pre-/ongoing-conditions), along with obligations (si-

milarly, pre-/ongoing-obligations). UPOL comprises

all such categories, extending the XACML capabili-

ties with two new contributions the asynchronous and

synchronous obligations, normally implemented by a

trusted third party. The asynchronous obligations are

usage control obligations which have to be fulﬁlled

when an event occurs. Events may used to model re-

actions to mutable attributes as in Park and Sandhu

model but, extending it, they may not be connected

to an access request, as such as when the retention

period for a piece of data expires (as requested for

GDPR’s data minimization). The synchronous obli-

gations are again usage control obligations. For in-

stance banners that appears while one watches a strea-

ming video, or logging of the exact consumption time

of a resource, for accountability purposes. Such kind

of obligations may also be considered as session obli-

gations and can be used in order to pinpoint when an

user starts and terminates to use a resource as well as

when the user’s access right to the resource is revo-

ked.

WEBIST 2018 - 14th International Conference on Web Information Systems and Technologies

310

In UPOL, the violation of pre-authorization or

pre-condition rules prevents the access to the pro-

tected data. Instead, when pre-authorization and

pre-condition rules are satisﬁed, the user can access

the data, and the ongoing-authorization and ongoing-

condition rules are enforced continuously while the

access is in progress. In this case, the violation of

ongoing rules interrupts the usage of the data. Ses-

sion obligations may be associated to passed or failed

checks, in order to model a desired behavior.

3.1 U-XACML

The U-XACML language is an extension of the XA-

CML language which includes additional constructs

to express Usage Control policies. XACML is a stan-

dard developed by the OASIS consortium for expres-

sing and managing access control policies in a distri-

buted environment (OASIS, 2010). Brieﬂy, the XA-

CML standard deﬁnes a policy meta-model, syntax,

semantics, and the related enforcement architecture.

The top-level element of a policy is <PolicySet>,

which includes a set of <Policy> elements (or ot-

her distinct <PolicySet>), each of which, in turn, in-

cludes a <Target>, which denotes the target of the

policy, and a set of <Rule> elements which repre-

sent the authorization rules. A rule is deﬁned by three

main components: the <Target>, the <Condition>,

and the effect of the rule which can be either Permit

or Deny. The <Target> denotes the target of the rule,

i.e., to which authorization requests the rule can be

applied. The <Condition> elements are predicates

evaluating the attributes. Optionally, a rule can in-

clude also the <ObligationExpression> element. A

rule is applicable to an access request if the target of

the access request matches the target of the rule and

if all the conditions included in the rule are satisﬁed.

If a rule is applicable to an access request, the effect

declared for the rule determines whether the access

request is permitted or denied, and the related obliga-

tion must be executed.

XACML allows to express traditional access con-

trol policies dealing with immutable attributes and it

does not have speciﬁc constructs to express the con-

tinuity of policy enforcement. Hence, the U-XACML

language extends XACML with some constructs for

usage control as follows. To represent the peculiarity

of the Usage Control model, i.e., the continuity of po-

licy enforcement, the U-XACML language allows to

specify in the <Condition> element a clause, called

DecisionTime, which deﬁnes when the evaluation of

this condition must be executed. The admitted values

are pre and on denoting, respectively, pre-decisions

and on-decisions. In this way, the conditions whose

decision time is set to pre are usual XACML conditi-

ons. On the other hand, the conditions whose decision

time is set to on must be continuously evaluated while

the access is in progress. We recall that XACML con-

ditions are exploited to represent both UCON authori-

zations and conditions. In the same way, U-XACML

extends the <ObligationExpression> element with

the DecisionTime clause to deﬁne when the obliga-

tion must be executed. In this case too, the admit-

ted values for the DecisionTime clause are: pre (pre-

obligations, i.e., usual XACML obligations) and on

(on-obligations), and post (post-obligations).

To deal with mutable attributes, U-XACML intro-

duces a new element, <AttrUpdates>, which repre-

sents the attribute updates in the policy. This ele-

ment includes a number of <AttrUpdate> elements

to specify each update action. Each <AttrUpdate>

element also speciﬁes when the update must be per-

formed through the clause UpdateTime which can

have one of the following values: pre (pre-update),

on (on-update), and post (post-update). U-XACML

language, please refer to (Colombo et al., 2010).

3.2 PPL

PPL (Primelife Policy Language) is another XACML

extension that allows to express personal data hand-

ling and credential capabilities. It achieves this result

by providing access and usage control functionalities.

In particular it was designed for modelling personal

data exchanges between data subjects and data con-

troller , according to deﬁnitions provided by the Euro-

pean Data Protection Directive 95/46/EC. PPL adopts

the sticky policy approach: once data handling terms

have been agreed between data subject and control-

ler, a policy gets associated to the personal data given

to the data controller. This policy cannot be detached

from the data and regulates each usage. One notable

aspect is the expression of usage control obligations.

Normally in XACML, an obligation must be fulﬁlled

by the actor that issues an access request. In PPL,

they are deﬁned as “a promise made by a data con-

troller to a data subject in relation to the handling of

his/her personal data. The data controller is expected

to fulﬁll the promise by executing and/or preventing a

speciﬁc action after a particular event, e.g. time, and

optionally under certain conditions”. PPL obligations

may also apply to data processors, i.e., entities autho-

rized by data controller to carry out computations on

the data, under the responsibility of the data control-

ler. PPL obligations are expressed as follows:

Obligation = Do Action when Trigger (1)

where

Trigger = Event ∧ Condition (2)

Towards a Declarative Approach to Stateful and Stateless Usage Control for Data Protection

311

Obligations modelled in this way are not depen-

dent on access requests and therefore differ from

access control obligations. They can be used to ex-

press a data retention period, e.g., data must be de-

leted by the data controller after 30 days from their

submission. As shown in (Di Cerbo et al., 2015), trig-

gers may also depend on contextual conditions like

geographic location.

4 UPOL

As mentioned, the UPOL language originates from

XAMCL, adding statefulness to its interaction model.

To cater for that, a number of contributions are propo-

sed, in terms of reference architecture and language

syntax, explained in the remainder of this section.

The UPOL reference architecture originates from

XACML, mutuating many of the main components

for its enforcement engine (depicted in Fig. 1):

PEP Policy Enforcement Point intercepts the reque-

sts to perform security relevant actions, triggers

the decision process and enforces the results.

PEP is normally integrated in a client applica-

tion.

CH Context Handler coordinates the internal com-

ponents of the enforcement engine.

PDP Policy Decision Point evaluates requests (also

continuously) against UPOL policies.

PAP Policy Administration Point is in charge of re-

trieving applicable policies for PDP evaluation.

PIP Policy Information Point(s) retrieves all the ne-

cessary attributes of any actor (subject, action,

resource, environment) for enabling PDP evalu-

ation.

The new components, respectively inherited by U-

XACML and PPL are:

SM Session Manager is responsible for keeping

track of the ongoing usage sessions, i.e., of the

access that are currently in progress, and it is re-

sponsible to store the meta-data regarding these

sessions. It is the key component of the conti-

nuous authorization phase, enabling the PDP to

operate continuously.

OE Obligation Engine is responsible for keeping

track of obligation triggers and executing the as-

sociated action(s).

In UPOL, the CH has also the role to exchange

status information among SM and OE, in order to al-

low session obligations to be triggered.

The UPOL architecture is necessary to implement

Figure 1: The UPOL Reference Architecture.

its new obligations; they go beyond the capabilities

of XACML/U-XACML and PPL. Table 1 enume-

rates UPOL obligations as extension of XACMl/U-

XACML, PPL and the newly deﬁned UPOL obligati-

ons. U-XACML inherits the standard XACML obli-

gations, they are pre-, or post-obligations associated

with an access request.

Instead, PPL obligations are not (necessarily)

bound to an access request (see Formula 1). PPL

supports triggers (see Formula 2) like proximity to

a speciﬁc geographic location, but also data deletion

or time interval expiration (Di Cerbo et al., 2015).

A trusted third party, different from Data Subject

and Data Controller and trusted by both actors, is in

charge of automatic obligation enforcement. Lastly,

UPOL obligations can be deﬁned leveraging the no-

tion of session: UPOL deﬁnes three new event types

StartAccess, EndAccess and RevokeAccess that can

be part of UPOL triggers. Therefore, UPOL obligati-

ons may prescribe the execution of actions associated

with a session work-ﬂow. A UPOL obligation can

start during a data consumption operation and termi-

nate at its end. We recall that a session is created when

an access request is approved and the requestor (or an

agent) notiﬁes the beginning of a resource consump-

tion. EndAccess obligations are triggered when the

requestor interrupts a resource consumption opera-

tion. RevokeAccess on the contrary takes place when

a policy violation is detected and a session is inter-

rupted by initiative of the access control mechanism.

UPOL obligations also differentiate from other obli-

gations in that they can be used to execute continu-

ous actions, particularly helpful in streaming scena-

rios: like showing banners in streaming videos or in

Big Data streaming Analytics computation. Last but

not least, obligations differentiate also with respect to

the enforcement actor. XACML/U-XACML obligati-

ons are normally enforced at the requestor’s end, by

the PEP. PPL obligations, instead, are enforced by a

third party (for example, a cloud provider) trusted by

data subject and data controller. UPOL obligations

are triggered by the Obligation Engine run by a trus-

WEBIST 2018 - 14th International Conference on Web Information Systems and Technologies

312

Table 1: Obligations part of an UPOL policy.

Obligation Type Reference Event Obligation Action

Type

Obligation Enforce-

ment

U-XACML pre- or

post-obligations

at the moment of the

request

punctual actions PEP

PPL obligations dependent or indepen-

dent from access re-

quest

punctual actions trusted third party

UPOL session obliga-

tions

at the beginning, end

or during data con-

sumption

punctual or continu-

ous actions

trusted third party or

PEP

ted third party but they may be also executed by the

PEP, according to the associated actions.

4.1 Comparison with UCON ABC

The Park and Sandhu model (Park and Sandhu, 2004)

deﬁnes a number of core usage control models, or-

ganised according to their characteristics with respect

to:

1. access control constituents, namely authorizations

(A), obligations (B) and conditions (C);

2. the continuity of the decision: is the access control

decision made when a request is received (like in

standard AC, pre) or its validity is continuously

evaluated during object consumption (typical trait

of UC, ongoing)?

3. mutability of attributes: are subject or object at-

tributes changing following to a decision? and

when? This originates: immutable, pre − update,

ongoing − update or post − update models re-

spectively for models where no attribute changes

are foreseen, updates takes place before, during or

after an access takes place.

We claim that our UPOL language can describe

all control models described by Park and Sandhu, by

means of, respectively:

1. the native XACML constructs.

2. the constructs brought in by U-XAMCL.

3. the speciﬁc extensions offered by U-XACML

combined with PPL: pre and ongoing conditi-

ons can originate speciﬁc events to trigger the ne-

wly deﬁned UPOL obligations (synchronous and

asynchronous).

Moreover, if used in conjunction with the sticky

policy approach, UPOL spans its scope beyond access

and usage control, as UPOL obligations can be trig-

gered also without the reception of an access re-

quest. Such functionality is particularly helpful in

cases like GDPR’s data minimisation requirement,

where a piece of data may reside on the Data Control-

ler cloud only for a limited amount of time. Provided

that a trusted third party runs a UPOL-aware enforce-

ment mechanism to control the UPOL-regulated data

on the cloud, such requirement may be fulﬁlled.

5 USE CASE

As an example, we may consider a simple online

commerce scenario involving a company, ACME

(data controller according to the GDRP), one of its

customers, Customer as data subject and a third-party,

a Marketing service provider that proﬁles customers

and suggests marketing campaigns to ACME.

The use case is depicted in Figure 2. The cus-

tomer submits a set of personal data, necessary for

ACME to serve the customer’s orders and of course,

to keep track of payments, warranties etc. This ex-

change is regulated by recording the data subject con-

sent to a data sharing agreement (Caimi et al., 2015)

stating precisely data controller’s rights and obligati-

ons, detailed as follows. Data submission and consent

recording take place through a speciﬁc service, called

“Usage Control Service” (the proposed contribution)

in the ﬁgure, that:

• associates to the personal data, a UPOL po-

licy (using the sticky policy model) that states

their access and usage terms (the data sharing

agreement);

• enforces the UPOL policy upon incoming perso-

nal data access requests;

• monitors usage of personal data, through inte-

ractions with the ACME information systems, en-

forcing continuous authorizations as well as usage

control obligations.

When the third party uses the ACME information sy-

stems, it interacts with the enforcement system, crea-

Towards a Declarative Approach to Stateful and Stateless Usage Control for Data Protection

313

Figure 2: An eHealth use case.

ting requests to access the protected resources. Infor-

mation systems cater for a number of attributes that

allow their requests to be evaluated by the enforce-

ment system, as well as providing indications about

the beginning and the end of information processing

operations. The interaction protocol between systems

and enforcement also allows the interruption of an

operation, in case of changes in the evaluation con-

ditions.

It is out of the scope of the current work to include

a detailed analysis of the interaction protocol and of

the architecture of the enforcement system. Focus-

sing instead on the policy expression, it can be model-

led as a (sticky) UPOL Policy where a Rule with Tar-

get: subject role = marketing-third-party, contractor

= ACME may access the data. Two conditions (pre

and ongoing) control the geographic location of the

doctor, provided by the information systems, in order

to protect against data export clauses (GDPR Article

49). We can model the notiﬁcation obligation by me-

ans of session obligations, triggered by StartAccess,

EndAccess and RevokeAccess. In this way, the begin-

ning and the end of sessions can be recorded for future

use. Last but not least, each access of the third-party

will trigger an email notiﬁcation to the data subject, in

order to fully meet the transparent processing requi-

rements. It might be worth noting that other acces-

ses performed by the data controller will not trigger

such notiﬁcation. Data minimization (with respect to

retention directives) is also enforced by means of a

speciﬁc obligation to delete the data associated to the

policy after 3 months from the moment when the per-

sonal data is received. The UPOL representation of

such policy can be found at Listing 1.

Listing 1. UPOL Use Case.

2 <!−− DETAILS OMITTED −−>

3 <!−− XACML Target: ABAC check for

,→ attribute ’marketing−third−party’ of

,→ requestor

4 in the authentication system, i .e.

,→ role == ’marketing−third−party’ −−>

5 <!−− Continous Authorization: requestor must

,→ be in EU to process the information

,→ −−>

6 <upol:Condition DecisionTime=”ongoing”>

7 <xacml:Apply FunctionId=”

,→ urn:oasis:names:tc:xacml:1 .0

,→ :function:string −equal”>

8 <xacml:Apply FunctionId=”

,→ urn:oasis:names:tc:xacml:1 .0

,→ :function:string −

9 one−and−only”>

10 < xacml:AttributeDesignator

11 AttributeId =”

,→ urn:oasis:names:tc:xacml:1 .0

,→ :subject:subject −location”

12 Category=”

,→ urn:oasis:names:tc:xacml:1 .0 :subject −

,→ category:

13 access−subject”

14 DataType=”http: // www.w3.

,→ org/2001/XMLSchema#string”

15 MustBePresent=”true”>

16 </ xacml:AttributeDesignator >

17 </xacml:Apply>

18 <xacml:AttributeValue DataType=”

,→ http: // www.w3.org/2001/XMLSchema#

,→ string”>

19 EU</xacml:AttributeValue>

20 </xacml:Apply>

21 </upol:Condition>

22 <ob:ObligationsSet

23 xmlns:ob=”http: // www.primelife.eu/ppl /

,→ obligation ”>

24 <ob:Obligation>

25 <ob:TriggersSet>

26 <!−− UPOL Session Obligations −−>

27 <upol:TriggerRuleEvaluated

,→ FulﬁllOn =”StartAccess” />

28 <upol:TriggerRuleEvaluated FulﬁllOn =”

,→ EndAccess” />

29 <upol:TriggerRuleEvaluated FulﬁllOn =”

,→ RevokeAccess” />

30 </ob:TriggersSet>

32 <!−− Action : notify data subject

,→ −−>

33 <ob:ActionNotifyDataSubject>

34 <ob:Media>Mail</ob:Media>

35 <ob:Address>customer.

,→ email@email.provider</ob:Address>

36 </ob:ActionNotifyDataSubject>

37 </ob:Obligation>

38 <!−− Obligation: delete after 3 months

,→ from information received −−>

39 <ob:Obligation>

40 <ob:TriggersSet>

41 <TriggerAtTime>

42 <MaxDelay>

43 <Duration>

,→ P0Y3M0DT0H0M0S</Duration>

44 </MaxDelay>

45 </TriggerAtTime>

46 </ob:TriggersSet>

WEBIST 2018 - 14th International Conference on Web Information Systems and Technologies

314

47 <ob:DenyAllAndDeleteNow/>

48 </ob:Obligation>

49 </ ob:ObligationsSet>

6 CONCLUSION

Data protection, especially for personal information,

has a growing attention and demand. For example,

the EU General Data Privacy Regulation require sig-

niﬁcant changes in the way entities collect personal

data of EU citizens, anywhere in the world. In this

paper we presented our effort towards the expression

of data protection policies to achieve compliance as

combination of access and usage control measures.

Our policy language, UPOL, was developed in the

context of the EU FP7 Coco Cloud project. Its main

aim is to obtain a unique language that is powerful

enough to express, legal, security, and privacy con-

straints in automatically enforceable policies, focus-

sed on the sharing and management of (personal or

otherwise sensitive) data over the Cloud. Now, our

development continues in the EU H2020 C3ISP pro-

ject, extending data protection also to Big Data ana-

lytics scenario, especially considering cyber security

information sharing.

Our preliminary results, with obligations enforced

automatically by the policy engine are promising es-

pecially with respect to the fulﬁllment of some data

controller obligations as stated by the GDPR. We are

currently working towards structuring and extending

more our language, in order to support more data pro-

tection use cases, looking at personal data but also at

more in general, conﬁdential information especially

in the cyber security domain.

ACKNOWLEDGEMENTS

This work was partly supported by EC-funded pro-

jects Coco Cloud [grant no. 610853] and by C3ISP

[grand no. 700294].

REFERENCES

Bird and LLC, B. (2018). China cybersecurity law update:

Personal information national standards ofﬁcially pu-

blished. https://www.twobirds.com. Accessed: 2018-

06-20.

Caimi, C., Gambardella, C., Manea, M., Petrocchi, M., and

Stella, D. (2015). Legal and technical perspectives

in data sharing agreements deﬁnition. In Berendt,

B., Engel, T., Ikonomou, D., M

etayer, D. L., and

Schiffner, S., editors, Privacy Technologies and Po-

licy - Third Annual Privacy Forum, APF 2015, Lux-

embourg, October 7-8, 2015, Revised Selected Papers,

volume 9484 of Lecture Notes in Computer Science,

pages 178–192. Springer.

Coco Cloud Consortium (2016). Coco Cloud website.

http://www.coco-cloud.eu.

Colombo, M., Lazouski, A., Martinelli, F., and Mori, P.

(2010). A Proposal on Enhancing XACML with Conti-

nuous Usage Control Features, pages 133–146. Sprin-

ger US, Boston, MA.

Di Cerbo, F., Some, D. F., Gomez, L., and Trabelsi, S.

(2015). PPL v2.0: Uniform data access and usage

control on cloud and mobile. In Matteucci, I., Mori,

P., and Petrocchi, M., editors, 1st IEEE/ACM Inter-

national Workshop on TEchnical and LEgal aspects

of data pRIvacy and SEcurity, TELERISE 2015, Flo-

rence, Italy, May 18, 2015, pages 2–7. IEEE Computer

Society.

European Parliament and Council (2016). Regulation

(EU) 2016/679 of the European Parliament and of

the Council (General Data Protection Regulation). 27

April 2016 - http://goo.gl/LfwxGe.

Lazouski, A., Mancini, G., Martinelli, F., and Mori, P.

(2012). Usage control in cloud systems. In Savage,

N., Assad, S. E., and Shoniregun, C. A., editors, 7th

International Conference for Internet Technology and

Secured Transactions, ICITST 2012, London, Uni-

ted Kingdom, December 10-12, 2012, pages 202–207.

IEEE.

OASIS (2010). eXtensible Access Control Markup Lan-

guage (XACML) Version 3.0.

Park, J. and Sandhu, R. (2004). The UCON ABC usage

control model. ACM Transactions on Information and

System Security (TISSEC), 7(1):128–174.

Pearson, S. and Casassa Mont, M. (2011). Sticky poli-

cies: An approach for managing privacy across multi-

ple parties. Computer, 44(9):60–68.

Standing Committee of the National People’s Con-

gress (2017). Cyber security law (draft).

http://www.npc.gov.cn/npc/xinwen/lfgz/ﬂca/2015-

07/06/content 1940614.htm. Accessed: 2018-06-20.

Trabelsi, S., Njeh, A., Bussard, L., and Neven, G. (2010).

Ppl engine: A symmetric architecture for privacy po-

licy handling. In W3C Workshop on Privacy and data

usage control, volume 4.

Zhang, X., Parisi-Presicce, F., Sandhu, R., and Park, J.

(2005). Formal model and policy speciﬁcation of

usage control. ACM Trans. Inf. Syst. Secur., 8(4):351–

387.

Towards a Declarative Approach to Stateful and Stateless Usage Control for Data Protection

315