Salameh Abu Rmeileh
email: salameh.aburmeileh@bcu.ac.uk

Esther Palomar
email: esther.palomar@bcu.ac.uk

Hanifa Shah
email: hanifa.shah@bcu.ac.uk

ALOC: Attribute Level of Confidence for a User-Centric Attribute Assurance

Keywords: attribute assurance, attribute-based identity, trust, level of confidence

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

A significant amount of our daily activities have been replaced by their digital counterparts (online services) such as banking, social networking, and shopping, to name a few. As their real life former selves, some online service providers (SPs) must be able to identify and authenticate their consumers in order to make informed access control decisions while others can be more flexible depending on the nature of the service. However, as [START_REF] Q Ethan Mccallum | Business Models for the Data Economy[END_REF] state, "modern businesses see data as a gold mine." This reliance on data incite inappropriate practices. For online service providers the certainty of proving a subjects digital identity is limited by the strength and/or some level of trust on one or more authentication attributes. On the other hand, consumers need to trust SPs to handle their personal information properly [START_REF] Lopez | Authentication and authorization infrastructures (AAIs): a comparative survey[END_REF].

However, todays online activities have evolved beyond what the username/ password format can effectively protect. Users then create multiple digital identities, one for each service provider that requires an acceptable level of security when granting access to the service [START_REF] Jøsang | Trust requirements in identity management[END_REF]. These identities may partly overlap, but can also be mutually inconsistent, e.g. shaving few years off their age or few pounds off their weight on online social networks, or a minor pretending to be a certain age in order to gain eligibility for certain entitlements. From users' perspective, this generates a huge burden for users to manage their identities, remember associated credentials, and keep their information up-to-date [START_REF] Bertino | Security for Web Services and Service-Oriented Architectures[END_REF] while from a business perspective, SPs will suffer from critical deficiencies in their access control decisions in case of false or inconsistent information been provided by the users.

A digital identity is the information about individual characteristics, distributed in the digital world, by which an entity, a thing or person, in the real world can be recognised or known [START_REF] Suriadi | Strengthening and Formally Verifying Privacy in Identity Management Systems[END_REF]. Technically, a digital identity comprises a limited set of attributes that holds the information about the entity's characteristics. These attributes are attested by some party (either the entity itself or a third party). Some attributes are for identification purposes and some others are not. While an attribute may not uniquely identify an entity, the aggregation of them could potentially cause entities to be uniquely identified within a scope. Identity is also dynamic. Assertions of someone's age, passport, email, phone number, friendships, convictions and beliefs change over time.

This leads to identity management (IDM) becoming one of the most pervasive parts of IT systems [20]. IDM comprises the whole processes and all underlying technologies for the creation (provision), usage, update and revocation (de-provision) of a digital identity once it is not needed anymore [START_REF] Bertino | Identity Management: Concepts, Technologies, and Systems[END_REF]. Thus, IDM systems are about controlling and using digital identities, enabling businesses to select and share user information [START_REF] Hansen | Privacy-enhancing identity management[END_REF]. Trying to overcome the limitations of traditional IDM models, Federated identity management emerged as a way of sharing identity information across several trust domains [START_REF] Alpár | The identity crisis. security, privacy and usability issues in identity management[END_REF]. However, inherent issue in these open models is heavy reliance on online identity providers.

Identity assurance frameworks then appeared to assess the trustworthiness of identity providers [START_REF] Baldwin | On identity assurance in the presence of federated identity management systems[END_REF]. As a result, identity providers obtain a level of assurance (LoA) that reflects the degree of confidence in the assertions they make. On the other hand, current identity assurance approaches do not consider the definition of trust at the level of attribute and mostly consider identity as a whole lacking distinction amongst different qualities of trust, and the ability to cope with changes of trust level over time, e.g. attributes are gathered during the registration phase and often fixed.

In this paper, we propose a privacy-enhanced user-centric attribute assurance model to ensure that identity attributes are authentic and accurately associated with the user while enabling the user to have control over his attributes. We assign trust levels to individual attributes not only registration and authentication process and we extend the attribute structure to hold the aggregation of its assertions by introducing attribute level of confidence (ALOC). Basically, ALOC is a data structure, within the attribute itself, which comprises a set of elements reflecting the correctness, authenticity, timeliness and integrity of the attribute value. Being a fundamental component of the attribute structure, ALOC defines trust on the same granular level as the attribute information. In particular, ALOC utilises the attribute's usage history, combined with its life cycle 1[12], to build its reputation and quantify its trust level. The user identity is then a unique dynamic structure compiling the attributes that can be selectively disclosed to the SP and according to a certain policy.

The rest of the paper is organised as follows. Section 2 overviews the related work. In Section 3 we present the new user attribute data structure. The architecture and our proposal integration into potential real scenarios and platform are described in Section 4. Finally, Section 5 concludes with the immediate future work.

Related Work

This work builds on and contributes to the fields of identity management, attribute assurance, attribute aggregation, trust, and privacy. Thus, related work has been investigated in these main different areas: trust and reputation systems, level of assurance and credibility of claims.

Several approaches have been proposed regarding trust levels for users' attributes. In [START_REF] Chadwick | Attribute Aggregation in federated identity management[END_REF][START_REF] Chadwick | A conceptual model for attribute aggregation[END_REF][START_REF] Chadwick | The Trusted Attribute Aggregation Service (TAAS) -Providing an attribute aggregation layer for federated identity management[END_REF], Chadwick et al. build on NIST's concept of assurance levels and propose to have separate metrics for the Registration LoA and the Authentication LoA instead of NIST's compound metric which is dependent upon both. The Registration LoA reflects the strength of the registration method the identity provider (IdP) used e.g. registering online is much weaker than registering in person while the Authentication LoA reflects the strength of the authentication method the IdP used e.g. username/password is weaker than public key certificates and private keys. Prior to any authentication taking place, a user needs to register with a service, and provide various credentials to prove his identity. After successful registration the SP creates a profile for the user and may offer different authentication mechanisms for the user to access, such as username/password with Kerberos, username/password with SSL, etc. Thus, Chadwick et al. argue that no Authentication LoA can be higher than the Registration LoA, since it is the latter that originally authenticated who the user is. In [START_REF] Mohan | AttributeTrust -A framework for evaluating trust in aggregated attributes via a reputation system[END_REF], Mohan et al. propose the AttributeTrust framework for evaluating trust in aggregated attributes which are provided by trusted attribute authorities. Similar to our approach, in AttributeTrust, service providers are asked to provide attribute authorities with feedback after each successfully completed transactions. However, Mohan et al. do not outline differences between trust in attribute authority and the attribute itself. Compared to this, in our work, we assign trust levels to individual attributes not only registration and authentication process and we extend the attribute structure to hold the aggregation of its assertions. Additionally, the proposed approaches by Chadwick et Several approaches to enhance the quality of attributes, user-centricity and privacy within national eIDs exist. In [START_REF] Laube | myIdP-The Personal Attribute Hub[END_REF][START_REF] Laube | myIdP-The Personal Attribute Hub: Prototype and Quality of Claims[END_REF], Laube and Hauser propose a service, as an extension to the SuisseID [START_REF]ECH: eCH-0113: Spezifikation SuisseID[END_REF] infrastructure, to handle and provide, to some extent, assurance of personal attributes with no official authority certifying or owning. Similar to our approach, the MyIdP service reuses data the user has already used as part of a transaction with a web application in order to assess the quality and trustworthiness of the data. In particular, the assessment is based on the freshness of information, quality of the attribute issuer and the recurrence of information. In [START_REF] Slamanig | User-Centric Identity as a Service-Architecture for eIDs with Selective Attribute Disclosure[END_REF], Slamanig et al, propose an identification and authentication model to be applied for eIDs which allows for selective disclosure to better protect citizen's privacy. Both approaches rely on the existence of IdPs.

In [START_REF] Thomas | Enhancing Claim-Based Identity Management by Adding a Credibility Level to the Notion of Claims[END_REF], Thomas and Meinel propose a model to consider trust on a claim basis. Their approach is to extend the notion of claim in claim-based identity management by a credibility value enabling service providers to specify the expected trust quality for attributes and the required user attributes. However, the credibility value is based on two factors: (i) whether the issuer is trusted or not and (ii) whether the claim is verified or not limiting the attributes' trustworthiness to only three possibilities, namely trusted, untrusted, and a third vague possibility where claim is verified by an untrusted issuer. In our approach we go beyond the credibility value by considering other attribute properties resulting in a more compliant and scalable level of confidence for user attributes and provide more choices for a SP to express its policy demands and for users to protect their privacy. In another study [START_REF] Thomas | An Attribute Assurance Framework to Define and Match Trust in Identity Attributes[END_REF], Thomas and Meinel present an attribute assurance framework for federated identity management based on a verification context class. However, their attribute assurance framework only offers the possibility to express which attribute has been verified by a federated IdP using a particular verification method in addition to which attributes are required. By contrast, our approach offers users and SPs a wider spectrum to express their policy demands.

The aforementioned models do not address the attribute dynamic nature nor its lifecycle which in reality affects attribute's correctness and timeliness. Drawbacks of these existing solutions motivated us to design an improved, more fine granulated yet more applicable user-centric attribute assurance model.

Our Model

In this section, we propose a new user-centric attribute assurance model which is applicable for the public cloud in terms of data assurance and privacy. Our model enables the users to have full control over their information while providing SPs with assured and well qualified attributes.

Roles

The following entities are involved in the architecture:

User A set of attributes will allow system users to be authenticated and authorised. For authentication reasons, the user can reveal a subset of these attributes that are endorsed by different types of endorsers and mechanisms. the user can ask for endorsements as well as endorsing other users' attributes.

Endorser This represents a trusted certification authority, a TTP, a SP, a user, or combination of all. The endorser issues an endorsement to the user for a particular set of attributes using a specific endorsing mechanism.

Service Provider The SP offers different resources or services which require user identity information. Also, a SP can act as an endorser.

Requirements

The model fulfills the following requirements:

Assurance The model must provide qualified but not necessarily certified attributes utilising various mechanisms to quantify attributes' trust levels, i.e. timeliness, correctness, and reputation as well as certification and verification by either TTPs and also fully distributed mechanisms such as crowdsourcing.

User-centricity The user always remains in full control over his attributes and benefits from the selective disclosure property when the SP supports it. However, the user cannot alter the ALOC part of the attributes structure. Nonetheless, the user can view all information about his attributes such as which attributes have been endorsed by whom.

Selective Disclosure In addition to disclose only required attributes' values to SP, the user must have the option to provide the SP with information about the attributes quality and authenticity.

Privacy The privacy of user attributes must be preserved in the presence of an honest but curious cloud storage, i.e., the cloud storage must not learn anything about the user's attributes, policies or transactions.

Dynamic & Self-Contained User attributes must be dynamic and selfcontained by holding all necessary information required to assess their trustworthiness without the involvement of any third party during a given transaction. The model must not involve IdPs. The user acts as its own attribute provider and only interact with third parties that endorse their attributes.

Extending Identity Attributes

Digital identities are dynamic, so are the online services they interact with. Similarly, attribute must be dynamic too. Traditionally, an attribute is defined as an ordered pair of label and value, i.e. attribute x = l, υ , e.g. N ame, John , Address, London . The current static structure of attribute does not provide any information about the authenticity, integrity, or correctness of the value the attribute holds. Our approach is not only to provide attribute assurance and trust but to also make attribute self-contained and more dynamic. We extend the current structure with third element, called Attribute Level of Confidence (ALOC). This element holds all required information to express attribute trustworthiness as we believe this information must be part of the attribute itself and nowhere else. Therefore, we define a dynamic attribute as follows:

Dynamic Attribute is a data structure that holds some property or piece of data about an entity as well as the required information to verify the trustworthiness of this property or data. Technically, it is tuple of label, value and ALOC, i.e. attribute x = l, υ, aloc where ALOC is a data structure that comprises a set of elements, illustrated in Figure 1.

The following section explains ALOC in detail.

Attribute Level of Confidence

Basically, ALOC is a data structure which comprises a set of elements that are required to assess an attribute's trust level. These elements reflect the attribute completeness, timeliness, reputation, and authenticity. The following is a detailed explanation of ALOC elements.

Timestamp This element represents the attribute's timeliness. It is important to measures the extent to which the age of an attribute is appropriate for the value it holds. We quantify timeliness as the time elapsed from the last update/revision of the attribute's value. In other words, It holds the date and time of the last revision.

Revision Represents the number of times the attribute's value has been changed, e.g. an attribute with a revision value of 7 shows that the attribute's value has been updated 7 times.

Endorsements This element holds a list of assertions by different entities, e.g. users, authorities, SPs. Each endorsement is a data structure comprising a number of elements as follows:

-Endorser Represents the entity that issued the endorsement.

-Timestamp The issuance date and time of the endorsement.

-Type This element represents the type of the endorsement. We have identified 4 types of endorsements, namely: Creation, Registration, Authentication and Authorisation endorsement, see Section 3.5. -Revision Shows the attribute's revision the endorsement has been issued for. -Mechanism Contains information about the certification mechanism used by the endorser.

• Description Defines the type of certification mechanism, e.g. X.509 certificate, username/password token, SAML assertions, digital signature, etc. • Version The version number of the mechanism.

• LoA Level of assurance of the mechanism indicates the strength of the mechanism, e.g. a X.509 certificate will have a higher LoA than a username/password token. • Result This element holds the result of the endorsing mechanism, e.g. if the mechanism is a digital signature then result is the signature itself.

Issuance and acceptance of endorsements depend on the ALOC policies of both the endorser and the attribute owner.

Endorsements Types and Mechanisms

We define four types of endorsements based on the phases of the attribute life cycle. Firstly, Creation endorsement is attached to the creation phase of the attribute. Secondly, we break down attribute's usage phase into 3 endorsements: Registration, Authentication, and Authorisation. We will further elaborate on these phases' processes in Section 4.2. For example, attribute 'Academic Qualification' gets a Creation endorsement issued by the corresponding academic institution upon the user request; when the user registers with a SP he gets a Registration endorsement. A single authority may not be able to certify every attribute and not all attributes have certifying authorities. Thus, the user is able to get endorsements not only from trusted third parties and SPs but also from referral-based trust models such as crowdsourcing.

A wide range of mechanisms are used for adding endorsements namely digital signature, reputation systems, voting schemes, or referral-based mechanisms. The result of the mechanism, i.e signature, score, value, is stored in the Result element of the endorsement.

SPs also define own classifications and trust of endorsers, endorsement mechanisms and mechanisms' results expressed using ALOC policies.

Architecture

System architecture comprises 4 components: User-centric ALOC Agent, Service Provider, Secure Storage, and the User. Figure 2 depicts the proposed architecture. The designed architecture adopts Kim Cameron's Laws of Identity [START_REF] Cameron | The laws of identity[END_REF] that are widely accepted as a guideline for the design of identity systems.

Components

Components of the architecture are explained in detail.

Attribute Token Is an encrypted token containing a set of attributes' elements to be sent to a SP by the user. The attributes' elements contained in the token are based on the user ALOC policies.

ALOC Policy

Represents the storage for the user to express rules and semantics of the attribute information to reveal, to whom, and under what conditions. The SP can also establish its own policies to express the conditions under which a service can be accessed. See Section 4.3.

Endorsement Token For every endorsing process, an endorsement token is created by the issuer containing the elements depicted in 1. -ALOC Engine This component is responsible for updating the user's attributes ALOC element after receiving information from the Endorsement Token Processor according to the user's ALOC policies. -Storage In order to preserve the users' privacy without violating the 8th Law of Location Independence [START_REF] Hoepman | Identity Management Lifecycle -Exemplifying the Need for Holistic Identity[END_REF] (which states that IDMs should not rely on any persistent data stored locally at the user's machine), the users' dynamic attributes and ALOC policies are stored encrypted on the public cloud. The cloud storage comprises two persistent storage components. The information stored in both components can only be accessed through an ALOC Agent. The data is encrypted by the ALOC Agent before being sent for storage; none of the data is revealed to the storage provider.

Service Provider The SP consists of several components:

-Attribute Token Processor/PEP This component is responsible for validating attribute tokens. In order to decide whether the information in the token is accepted or not, a request is sent to the Policy Decision Point component. If the information is accepted the Attribute Token processor provides the Endorsement Token Generator component with required information to issue an endorsement token and send it back to the user's ALOC Agent. -Policy Decision Point The Policy Decision Point compares the token information it receives to the ALOC policies of the service provider. -Endorsement Token Generator This component issues encrypted endorsement tokens back to the user's ALOC Agent based on requests from the Attribute Token Processor.

Processes

Creation and Management of Attributes A user access the ALOC Agent (Mobile app, web app, browser extension) using a passphrase, a smartcard, or a biometric credential. The user creates and manages (view, update, delete) his attributes, i.e. attributes values and ALOC policies through the Administration Point within the ALOC Agent.

The user is able to set label and value for an attribute. Also, the user can send a request to a TTP, SP, another user, or collection of them asking for a Creation endorsement depending on the attribute type and the user's ALOC policies. Figure 3 shows the attribute creation and registration endorsing processes.

Endorsing Process

The following steps describe the endorsing process for the Registration endorsement. See also Figure 3 .

When the user register with a SP:

1. The Attribute Token Service asks the Dynamic Attribute Provider for a set of the requested attributes by the SP. 2. The Dynamic Attribute Provider checks the user ALOC policies and accordingly builds the set of requested attributes from the Attribute Repository.

3. The Dynamic Attribute Provider returns the set of dynamic attributes to the Attribute Token Service to issue a token. 4. The Attribute Token Service creates a token, in the requested format, which contains the set of dynamic attributes and sends it to the SP. 5. Upon receipt, the Attribute Token Processor parses the token, checks its validity then passes the information within the Token to the Policy Decision Point. 6. The Policy Decision Point checks the SP ALOC policies against the received information. 7. The SP applies the required verification mechanism. 8. Upon success of steps 6 and 7, the Attribute Token Processor requests the Endorsement Token Generator to issue a Registration endorsement token for the accepted attributes after providing it with the required information, i.e. the accepted attributes and the endorsing mechanism used. 9. The Endorsement Token Generator issues a token, which contains this information, signs it and then sends it back to the user's ALOC Agent. 10. The Endorsement Token Processor receives it, parses it, verifies and checks its validity, and then passes it on to the ALOC Engine. 11. The ALOC Engine checks the user's ALOC policies and accordingly decides whether to accept the endorsement or not. 12. If the endorsement is accepted, the ALOC Engine computes the attributes ALOC elements, i.e. weight and endorsements, and applies it the Attribute Repository.

The aforementioned steps also apply for the authentication and authorisation processes. However, the endorsement type changes to Authentication or Authorisation. Additionally, in the authentication process step [START_REF] Chadwick | A conceptual model for attribute aggregation[END_REF] the Attribute Token Processor checks if the received dynamic attributes have a Registration endorsement by the SP, otherwise it applies a required verification mechanism. Lastly, to securely and reliably support these processes, we assume that whenever we speak of public parameters or public keys, they are available in an authentic fashion, e.g., via a PKI. Furthermore, the channels between all parties provide confidentiality, as well as authenticity, e.g., via the use of TLS.

ALOC Policies

ALOC policies are a crucial part of the ALOC trust model as they enhance the decision making process at SPs, and the selective and/or minimal disclosure of users' attributes. There are two types of ALOC policies namely SP ALOC policies and user ALOC policies. Whereas the latter allows the users to control what to reveal to SPs the former allow SPs to define the trust requirements for user attributes.

User ALOC Policies Users can create their own policies to control information disclosure and endorsement acceptance. For instance, a user may create a policy that constraints what can be revealed out of the attribute data structure, e.g. a policy for particular when interacting with particular SPs to only disclose the attribute's label, timestamp, revision, and endorsements. Though the value of the attribute is not revealed, the SP will have some degree of assurance based on the ALOC elements. Additionally, the user can create policies for endorsement acceptance, e.g. a user policy for attribute DateOfBirth forces to be endorsed for Creation by An Interior Ministry or attribute Fullname can be endorsed for all endorsement types by any endorser.

SP ALOC Policies SPs can create policies for particular attribute information to be verified. In other words, a SP may create a policy that expresses what attribute elements required to compute the level of trust (confidence) of an attribute. For example, the SP expresses its requirements for 2 attributes (Fullname and DateOfBirth) to access a particular resource. For the Fullname attribute the SP enforces exactly one policy, in this case (A) which expresses that the attribute value is required, and it is willing to endorse the attribute if requirements are met. For DateOfBirth attribute the SP enforces 2 policies, A and B, and requires both policies to be met. In policy A the SP expresses that providing the value of the attribute is optional leaving the decision to the user. However, in policy B the SP requires the attribute weight, revision, and an endorsement from a particular endorser by a certain endorsing mechanism whether the user provides the attribute value or not.

In case of a conflict between a user policy and a SP policy then it is up to the user to make a decision to change his policy or not.

Conclusion and Future Work

In this paper, we dealt with attribute assurance by extending the structure of digital attributes and defining trust within the attribute itself without the involvement of a third party during a given transaction. We consider the user attribute as a dynamic data structure that extends the foundation of user attribute authenticity and trustworthiness by introducing the attribute level of confidence (ALOC). ALOC enables a multi-level selective disclosure where the user can reveal particular attributes' elements that can be to the SP and according to a certain policy. We also proposed a user-centric attribute assurance architecture based on ALOC. An ALOC agent can be locally-installed software running on a user's device, or its functionality can be distributed between a local and cloudbased entities to reach a higher level of security and accomplish the 8th law of identity, although the problem of protecting stored data on cloud is out of our work's scope. We also showed that our architecture does not require major changes to SPs, however, requires the addition of certain components.

Our implementation consists of developing a user side and a SP side applications. For the SP side, we are developing a simple online store web service that requires user registration and authentication. For the user side, we are developing a browser add-on where the user manages his attributes, attribute endorsements and policies. In our design the user's registration, authentication and policy negotiation will be managed by the add-on. Thus, the user does not need to create a username, a password or provide attributes or ALOC elements manually, e.g. when the user clicks the registration button in the service the service and the addon will establish communication, exchange policies, and then make a decision either the user will be registered or not based on both policies and provided ALOC elements. ALOC policies will adopt XACML policy language standard [START_REF]OASIS: eXtensible Access Control Markup Language (XACML) Version 3[END_REF]. Currently, both parts of the implementation are under development and will be evaluated against the requirements mentioned in Section 3.2.

Although our architecture satisfies the major properties of a usercentric IDM system, there are still some properties to be improved. It is our immediate future work to finish the implementation of both, the SP and user sides, to evaluate the architecture usability, security, and test the ALOC policy negotiation between users and SPs as well as to making the endorsement mechanism strong against collusion and Sybil attacks.

  al. and Mohan et al. assess the trustworthiness of IdPs not the individual attributes.

Fig. 1 .

 1 Fig. 1. Current (a) vs Proposed (b) Attribute Structure

Fig. 3 .

 3 Fig. 3. Attribute Creation and Registration Endorsing Processes

  -Dynamic Attribute Provider This component builds a set of dynamic attributes based on the requested attributes and on dependence of the user's ALOC policies. -Attribute Token Service This component is responsible to provide the Dynamic Attribute Provider with the requested attributes by the SP and to provide the SP with an encrypted token which contains what the Dynamic Attribute Provider returned. -Endorsement Token Processor This component parses and validates endorsement tokens received from a SP and pass it on to the ALOC Engine.

	Attribute	ALOC Policy
	Repository	Store
	ALOC Agent
	Administration Point Attribute Management & Policy Administration Point	Dynamic Attribute Provider	ALOC Engine
	Attribute Token Service	Endorsement Token Processor
			R
	Service Provider
		Attribute Token Processor Policy Enforcement Point	Endorsement Token Generator
		Policy Decision Point
	ALOC Policy
	Store		Service

R R Storage Profiling Fig. 2. Proposed Architecture for ALOC-based User-centric Attribute Assurance ALOC Agent ALOC Agent is a software application that implements the Attribute Level of Confidence model presented in Section 3.4 and comprises several components:

-Administration Point This component enables the user to manage his attributes (view, add, update, revoke), define own ALOC policies, and request endorsements from other entities.

Attribute lifecycle consists of four phases: creation, usage, update, and revocation. These phases are inspired by the IDM life cycle.


Carmen Fernandez-Gago

Siani Pearson
email: siani.pearson@hpe.com

Michela D'errico
email: michela.derrico@hpe.com

Rehab Alnemr
email: rehab.alnemr@hpe.com

Tobias Pulls
email: tobias.pulls@kau.se

Anderson Oliveira

Anderson Santana De Oliveira
email: anderson.santana.de.oliveira@sap.com

A4Cloud Workshop: Accountability in the Cloud

Keywords: Accountability, Tools, Control Tools, Facilitating Tools

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Cloud computing technology is becoming more and more popular and it is being widely used by companies and users nowadays. However, there are still some concerns about security and how personal data is dealt with by cloud providers. There should be mechanisms and tools in place that help users to have trust in the cloud. The goal of the A4Cloud project [START_REF]A4Cloud: The Cloud Accountability Project[END_REF] is to provide tools and mechanisms that help achieve accountability for cloud providers, including demonstration that they are accountable, and helping users to know whether the cloud provider of their choice is accountable. Accountability consists of defining governance to comply in a responsible manner with internal and external criteria, ensuring implementation of appropriate actions, explaining and justifying those actions and remedying any failure to act properly [START_REF] Catteddu | Towards a model of accountability for cloud computing services[END_REF]. The approach followed by A4Cloud is interdisciplinary and includes legal and regulatory, socio-economic and technical aspects.

This paper describes the outcomes of the workshop held during the IFIP summer school 2015 on the topic of accountability for data protection in the cloud. At the time of this workshop some of the A4Cloud prototypes were in a mature enough state to be demonstrated. We chose different kinds of such prototypes to be shown at the workshop. The chosen tools offered complementary functionalities that will be also described in this paper. On the one hand, we concentrated on the Cloud Offering Advisory Tool (COAT) and Data Protection Impact Assessment Tool (DPIAT) that facilitate users in finding and assessing a suitable cloud provider that may fulfill their needs. On the other hand, we also considered tools that aid users having control over their data, such as the Data Track (DT) tool or the Accountability-PrimeLife Policy Language (A-PPL), that is the reference language for representation of accountability policies. These policies can be defined by using the Data Protection Policies Tool (DPPT) and enforced by the associated engine.

The structure of the paper is as follows. Section 2 provides an overview of the A4Cloud project, whereas the following sections provide insights on specific tools demonstrated within the workshop. Thus, Section 3 describes tools for facilitating users' choice of providers: in particular, COAT and DPIAT. Section 4 describes some control and transparency tools, namely DPPT and A-PPL Engine. The feedback given by the participants in the workshop is analysed in Section 5. Finally, Section 6 concludes the paper.

Overview of the Accountability Project

The goal of the A4Cloud project is to provide an increased basis for trustworthiness in cloud computing by devising methods and tools, through which cloud stakeholders can be made accountable for the privacy and confidentiality of personal data held in the cloud. These methods and tools combine risk analysis, policy enforcement, monitoring and compliance auditing. They will contribute to the governance of cloud activities, providing transparency and assisting legal, regulatory and socio-economic policy enforcement. The A4Cloud tools are grouped into different categories depending on their functionality or their intended usage. They are classified as follows [START_REF] Pearson | An interdisciplinary approach to accountability for future internet service provision[END_REF]:

-Preventive tools are those that aid mitigation of the consequences of any unauthorised action. These tools include assessing risk, selection of providers or identification of appropriate policies to mitigate the risks. These tools are the Data Protection Impact Assessment Tool (DPIAT), Cloud Offerings Advisory Tool (COAT), Accountability Lab (AccLab), the Data Protection Policies Tool (DPPT), Accountable Primelife Policy Engine (A-PPL Engine) and Assertion Tool (AT). -Detective tools are those that monitor for and detect policy violations. The corresponding A4Cloud tools are the Audit Agent System (AAS), Data Transfer Monitoring Tool (DTMT), Data Track (DT) and Transparency Log (TL).

-Corrective tools are those designed to mitigate the consequences of any incident occuring. They are the Incident Management (IMT) and the Remediation Tool (RT).

Among the preventive tools we are going to concentrate in this paper on those designed for facilitating the choice of a cloud provider. They are DPIAT and COAT. We will be also concentrating on the definition of policies and enforcement and will pay special attention to the DPPT tool to define policies and A-PPL engine to enforce and handle policies specified in A-PPL and created by DPPT. Among the detective tools we consider in this paper the DT tool. This tool can be classified as a Data Subject Control tool that provides controls for the management and protection of the personal data of the users.

For the scope of this work no corrective tools were included in the workshop as they were not mature enough to be demonstrated.

3 Tools for Facilitating Choice

COAT

The Cloud Offerings Advisory Tool (COAT) is a cloud brokerage tool that facilitates evaluation of cloud offerings and contract terms with the goal of enabling more educated decision making about which service and service provider to select. It allows potential cloud customers -with a focus on end users and Small and Medium Sized Enterprises (SMEs) -to make informed choices about data protection, privacy, compliance and governance, based upon making the cloud contracts more transparent to these cloud customers. This type of tool is useful for a number of reasons: reading and interpreting terms and conditions in cloud service offers can be challenging, and indeed non legal experts cannot easily make out the differences between contracts relating to cloud offerings. SMEs and individuals in particular do not typically have enough technical and financial resources to assess cloud offers in this way. However, there is no current brokering service that focuses on the user's data protection requirements.

A number of related factors vary across cloud providers, and are reflected in the contracts. For example, security measures (including the type of encryption and key management solution), processing locations (that determine which law applies), data protection roles (which reflect the capacity of the cloud service provider acting in relation to the personal data), data deletion procedures, notification about changes to terms and conditions, the ways in which subcontracting to a third party is allowed, notification in the event of a security breach involving the customer's data, notification when law enforcement requests a customer's data, the period during which the CSP keeps a customer's data after service termination, and so on. The tool highlights these differences, and explains to the user what implications this might have. The focus of the tool is on providing feedback and advice related to properties that reflect compliance with regulatory obligations rather than providing feedback on qualitative performance aspects (such as availability), although potentially the tool could be integrated with other tools that offer the latter.

From the cloud customer point of view, the tool aims to ease the comparison of alternative cloud offerings, and provide greater transparency and guidance when considering which provider to use. From the cloud service provider point of view, the tool can provide benefits in terms of decreasing the complexity for customers when choosing a cloud provider, highlighting the unique criteria in the cloud service provider's offer, increasing market exposure, and ultimately matching cloud demands with their offerings. The overall system is depicted in Figure 1, in which a Web User Interface enables interaction with the target users. During this interaction, potential cloud customers can provide as input to the graphical interface a collection of answers to a questionnaire (that can change according to the inputs already provided), but most of this information is optional and need not be provided although the interactions help guide the users as to their needs and provide a more targeted output. Such information includes the data location, the roles involved in the scenario to be built on the cloud, contact details of those responsible for defining the purpose of use for the involved data, contextual information about the environment setting and the user needs and requirements. Other knowledge used by the system includes the cloud service offerings in structured form, models of cloud contracts and points of attention and reputation information with respect to the agents involved in the offering process. During this process of interaction, guidance is provided on privacy and security aspects to pay attention to when comparing the terms of cloud service offerings. The outcome of COAT is an immediate and dynamically changeable feedback panel that includes an overview of compatible service offerings matching the user requirements and links to further information and analysis. A familiar store-type interface is used to reduce complexity and improve usability. See Figure 2 for an example, which shows the questionnaire on the left hand side, the results on the right hand side and an example of advice that is provided in a dynamic way as the user considers the answer to individual questions. The matching is based on data protection requirements, and transparency is improved about what exactly the service providers are offering from a data protection perspective and how those choices might impact the potential cloud customer.

Ongoing research involves usage of ontologies for more sophisticated reasoning and linkage to PLA terms, and usage of maturity and reputational models to optimise ordering of the outputs. For further information about the system, see [START_REF] Alnemr | Coat: Cloud offerings advisory tool[END_REF].

DPIAT

The Data Protection Impact Assessment Tool (DPIAT) is a decision support tool focusing on assessment of the risks associated with the proposed usage of cloud computing, involving personal and/or confidential data. It assesses the proposed use of cloud services, helping users to understand, assess, and select CSPs that offer acceptable standards in terms of data protection. The tool is tailored to satisfy the needs of SMEs that intend to process personal data in the cloud; it guides them through the impact assessment and educates them about personal data protection risks, taking into account specific cloud risk scenarios. The approach is based on legal and socio-economic analysis of privacy issues for cloud deployments and takes into consideration the new requirements put forward in the proposed European Union (EU) General Data Protection Regulation (GDPR) [START_REF]Proposal for a regulation of the european parliament and of the council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (general data protection regulation[END_REF], which introduces a new obligation on data controllers and/or processors to carry out a Data Protection Impact Assessment prior to risky processing operations (although the requirements differ slightly across the various drafts of the Regulation).

Figure 3 shows the high level approach of DPIAT. The assessment is based on input about the business context gathered within successive questionnaires for an initial screening and for a full screening for a given project, combined with risk assessment of cloud offerings [START_REF] Cayirci | A cloud adoption risk assessment model[END_REF] based upon information generated voluntarily by CSPs, and collected from the CSA Security, Trust and Assurance Registry (STAR) [7]. The output Fig. 3. The High Level Approach of the Data Protection Impact Assessment Tool of the first phase of the DPIAT reflects advice about whether to proceed to the second phase of assessment. The second phase questionnaire contains a set of 50 questions. An example of part of this input questionnaire, which is responsive to the questions asked in the sense that the next questions to be asked depend partly upon previous answers, is given in Figure 4, which also illustrates how guidance related to the particular answers selected is provided dynamically during the process of answering the questions. The output of this phase is a report that includes: the data protection risk profile, assistance in deciding whether to proceed or not, and the context of usage of this tool within a wider DPIA process. Amongst other things, the tool is able to demonstrate the effectiveness and appropriateness of the implemented practices of a cloud provider helping him to target resources in the most efficient manner to reduce risks. The report from this phase contains three sections. The first, project-based risk assessment, is based on the answers to the questionnaire and contains the risk level associated with: sensitivity, compliance, transborder data flow, transparency, data control, security, and data sharing. An example is shown in Figure 5. The focus here is on assessment of potential harm to individuals and society, which is not typically part of a classic organisational risk assessment process. The second part of the report displays risks associated with the security controls used by the selected CSP. It contains the 35 ENISA risk categories [START_REF]ENISA: Cloud computing -benefits, risks and recommendations for information security[END_REF] with their associated quantitative and qualitative assessments. The last section highlights additional information that the user needs to know related to requirements associated with GDPR article 33 [START_REF]Proposal for a regulation of the european parliament and of the council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (general data protection regulation[END_REF]. The system also logs the offered advice and the users decision for accountability purposes. For further information about the system, including a full list of questions, see [START_REF] Alnemr | A data protection impact assessment methodology for cloud[END_REF].

Control and Transparency Tools 4.1 Data Track

The Data Track (DT) is a tool that enables data subjects to get an overview of what information they have disclosed to online services [START_REF] Angulo | Usable transparency with the data track: A tool for visualizing data disclosures[END_REF]. DT provides several different Trace View The Trace View is a view for the Data Track tailored for answering the question "What information about me have I sent to which online services?". Figure 6 shows the Trace View. In the middle of the view there is a picture representing the user him-or her-self. At the top of the view are attributes: each attribute has a type (like e-email or username) and one or more values (like "alice@example.com" or "bob"). At the bottom of the view are services like Spotify or Facebook. The view is called the Trace View because when the user clicks on a service there is a trace (line) drawn from the service to the user, and from the user to all the attributes the user has sent to the service in question. Furthermore, there are lines drawn from the service to any other downstream services used by the service provider to provide the service. In Figure 6, Spotify is as an example using Visa (presumably to accept creditcard payments for subscriptions). Exercising Control For compatible services, the Data Track enables the user to request access to, correction of, or deletion of their personal data stored remotely at services. In A4Cloud, a DT-compatible service is provided by the A-PPL Engine (presented in Section 4.2). Outside A4Cloud, the vast majority of conventional services do not provide data subjects with online APIs to excercise control over their personal data.

Privacy Policy Definition and Enforcement

Implementation of privacy policies can be thought of as a two phase process, as shown in Figure 7. Tasks carried out in the first phase have the objective to formally specify the policies that describe the different aspects of the practices related to the cloud service provision. During this phase different types of artifacts are designed and produced. For privacy policy statements that can be technically enforced by means of software tools, appropriate technical representation of the statements need to be generated. The specific language for the technical representation of the policies is tied to specific components tasked with the policy enforcement. The A4Cloud Project has designed i) a language, called A-PPL, whose expression capabilities address the need for accountability related policies; ii) an engine, the A-PPL Engine, which is able to translate into actions policies In the following subsections we will describe the tools used in the policy definition and the policy enforcement phases, respectively DPPT and the A-PPL Engine, along with the artifacts produced and used.

Policy Definition: DPPT The Data Protection Policies Tool (DPPT) is a GUI-based tool that cloud service providers (CSPs) can use to specify privacy policy statements to produce two different artifacts: an ontological representation of the policy statements (OWL file); an A-PPL (basically, an xml-based) policy file, that contains a representation in A-PPL of the policy statements that need to be enforced through the A-PPL Engine. The OWL Privacy Policy is linked to the A-PPL policy, in that a subset of the statements will have a corrisponding A-PPL policy element.

The DPPT GUI, shown in Figure 8, presents a set of data protection aspects, organised in graphical panes. For each data protection aspect the CSP's privacy officer can specify a set of statements. When all the choices have been made, an A-PPL policy file can be created. The creation of the different policy elements involves using the data provided through the GUI to customise an appropriate policy element template. In orto bind a privacy policy statement with an A-PPL element template we have carried out an analysis of A-PPL Engine capabilities and mapped those to the data protection statements that can be fulfilled by enforcing that A-PPL element. The different A-PPL elements produced as a result of the templates customisation are then composed according to A-PPL schema to create a valid A-PPL policy file. Once created, the policy can be sent to the A-PPL Engine by clicking the botton "Send to Engine". The result of the action is that the policy is stored by the A-PPL Engine, which is then ready to enforce them. We clarify that the actual enforcement will be done once data subjects' personal data will be stored and bound to the policy. This is done at service registration phase, when data subjects are asked to provide data in order to start using the cloud service.

In the following, we will provide details about the options that can be selected to create a set of enforceable privacy policy elements.

Data Processing A CSP can specify the personal data elements that the service will process. In our A4Cloud reference scenario, the privacy officer will select data items be-Fig. 8. DPPT GUI: configuration of notification sending longing to two different personal data categories: "User Account" and "Health Data". "User account" includes typical elements such as email address, username. "Health Data" refers to data elements that are processed by CSPs providing health statistics services. Examples of this category are blood pressure, blood sugar level, heart rate. Personal data categories are bound to ontological classes that describe them as belonging to specific data sensitivity categories. For example, the "Health Data" class is classified as "Sensitive Data", according to the definition of sensitive in EU privacy laws [11]. The set of data items selected will be referenced in other policy statements to specify additional policies that apply to them.

CSPs need also to specify for how long data will be kept. This can be done by providing the time period value through the GUI. The A-PPL element generated for this statement will enable the engine to automatically manage the deletion of data.

Notification Notification is an essential element of accountability and should be used by CSPs to notify (within a predefined timeframe) about relevant events related to data processing operations. Depending on the types of events that can be captured by the components deployed for audit and monitoring purposes, sending of notifications can be automated. DPPT GUI allows the provider to configure the A-PPL Engine for notifications sending. The GUI presents a set of options for the type of events, which reflect the capabilities of the audit and monitoring tools developed within A4Cloud. Examples of event types are: data personal data deletion, data transfer policy violation, access denied. Specific type of events that affect personal data, such as data leakage or data loss, assume particular relevance and are specified in a separate section of the GUI. The information required to be provided for the generation of the corrisponding A-PPL policy element includes: the type of event to notify about, the relevant stakeholder identifier to be notified, the communication channel (basically e-mail or post), the address and the timeframe.

Control Rights Access rights (read, write, delete, update) need to be granted to different actors over different sets of personal data items. The GUI allows the provider to create different access rules for each actor that needs to process personal data collected from data subjects. Data Subjects need to be given access to their own personal data, therefore the CSP should create a specific rule that specifies that a given data subject can access her own data to perform all the available operations. The creation of the A-PPL policy elements for enforcement of access control requires the CSP to provide information such as the set of personal data, the identifier of the actor that should be given access, its role (relevant if the underlying access control system is role-based) and the access rights to grant.

Policy Enforcement: A-PPL Engine Organizational cloud customers usually assume the role of data controller, thus they are held accountable for the way cloud services respond to many regulations, including the EU Data Protection Directive [11]. Appropriate policies mitigate risks to data protection as they clarify in which way obligations regarding personal data are carried out. In particular, machine-readable policy languages, such as A-PPL [START_REF] Azraoui | A-PPL: An accountability policy language[END_REF][START_REF] Benghabrit | A cloud accountability policy representation framework[END_REF] make organizations accountable, ensure that obligations to protect personal data and data subjects' rights are fulfilled by all who store and process the data, irrespective of where that processing occurs.

In the cloud, mechanisms to automatically enforce organizational and data governance policies are fundamental for compliance management. Using the A4Cloud policy enforcement tools, cloud providers can offer more transparency about the data handling. As far as assurance is given about the deployment and configuration of the tools, which in general can be achieved with independent audits, the policy enforcement will happen in a predictable manner, satisfying the data controller needs and obligations, but also as determined by the data controller, giving back control to the (cloud) data subject. The enforcement engine works in cooperation with further A4Cloud tools to reinforce the assurance about the correct policy execution.

A-PPL Engine High Level Architecture

The A-PPL engine has been created as an extension of the PPL engine in order to enforce the new A-PPL language policies. The first step was to extend the PPL XML schema with the new obligations defined in A-PPL. Many PPL engine functionalities have been simplified since the notion of sticky policy is no longer used.

The new A-PPL engine is a simplified version of the PPL engine. Many PPL engine functionalities have been removed since they are no longer needed in A-PPL: the matching engine is no longer used since the notions of sticky policy and data handling preferences do not exist in the A-PPL language.

A new module called Policy Administration Point (PAP) is responsible for storing, updating and deleting PIIs and their policies in the database.

The access control is performed in the Policy Decision point (PDP) module which uses the Heras XACML engine [START_REF] Heras Af Team | HERAS AF (Holistic Enterprise-Ready Application Security Architecture Framework[END_REF] exactly the way it was implemented in PPL. The usage control is enforced in the obligation handler module which includes the event and action handlers sub-modules.

The Policy Enforcement Point (PEP) is the main module of the engine, which enforces the A-PPL policy of a PII when access is requested to it. For this reason, it communicates with the frontend of the engine (ppl-rest module) as well as the PDP and obligation handler Upon storing the PII, the engine receives also an A-PPL policy that contains the rules and obligations related to how that piece of personal data has to be handled. For this reason, PII and their associated policy are represented in A-PPLE with the <PIIType> element, which has the following attributes:

owner: Denotes the owner of the PIIs -attributeName: It is the name of the PII element.

-attributeValue: The value of the PII element -policySetOrPolicy: One or more "sticky" policies describing the access and usage control rights for this PII. -creationDate: The creation date of PII.

-modificationDate: The modification date of PII.

When PII is retrieved from the engine, the policy associated with this personal data is analysed by the Policy Decision Point (PDP) that takes into account access and usage control rules.

In addition, obligations related to the personal data handling are executed when certain events occur inside the engine. The Obligation Handler component is responsible for analysing these A-PPL obligations (pairs of triggers and actions).

All actions happening inside A-PPLE are logged by a central component called Logging Handler. It stores the log entries related to decisions and actions (e.g. Action-Log) concerning the PIIs stored inside the engine.

We can see in Figure 9, that A-PPLE adopts a two-layer high-level architecture so that isolation between the engine components and data is performed: The core elements responsible for the policy enforcement functionalities reside in the Business layer. The Persistence layer consists of the PII Store and the Policy Repository where PIIs and the associated sticky policies are stored as well as the Logs produced by the Logging Handler component. Access to the persistence layer is achieved through a Persistence Handler component, which abstracts the underlying location and storage data model to the above business layer functions [START_REF] Garaga | D:C-4.1: Policy Representation Framework[END_REF].

Discussion

In this section we will describe how we structure the workshop and the the feedback and questions that we received from the audience. Firstly, we introduced a general overview of the A4Cloud project in order to give the audience a general view on it. Then, the group was split into four different subgroups of four or five people each. Each of these Fig. 9. A-PPL Engine architecture subgroups approached specific booths for each of the tools (there was a shared booth for DPIAT and COAT), where a member of A4Cloud explained their corresponding tool. They introduced the group to their main features and showed how the tools work in practice. The presentation was interactive and anyone could ask questions at any time.

DT

Since the nature of the DT tool is mainly how data is dealt with, some concerns were related to mainly how it is stored or visualised, or how to input the information into the tool. The audience was also concerned about the resolution of conflicts or the evaluation of this tool as well as about monitoring aspects. These aspects led to the question of how this tool improves the accountability of the service provider. In general, attendees viewed the tool as an interesting one for auditing companies.

They also pointed out that security aspects should be considered in order to move forward. For the sake of usability, it was mentioned that it would be interesting if the DT tool worked in a mobile environment.

DPIAT

The comments and concerns raised by the audience with respect to the DPIAT are manifold. They relate to different aspects such as the selection of providers, how risk is considered and how the rating and the evaluation are performed.

Concerning the selection of the providers, some issues arose with respect to the way that the overall flags compute. The main question is whether the algorithm needs tweaking. It was suggested to be convenient for the user if there would be an option to select more than one CSP at the beginning (perhaps, up to three?). Then, on the final output screen it would be a good idea to have the different options selected shown up in the second band of output. This way the user does not have to go through the whole questionnaire each time if they were not quite sure about which CSPs to use but had a good idea. This would also help highlight the differences between them.

This functionality could indeed be added fairly easily to allow comparison of several providers at once, but there was a difference of opinion amongst the attendees as to whether this would be a good idea, or appropriate for typical contexts in which the tool might be used. Also, it would be interesting to clarify in which category governments fall as they could also be users of the tool.

Attendees' concerns about risk were related to how it is presented for users to understand it. The distinction between the risks to data subjects (the core of a DPIA), and those related to a more classic organisational risk assessment (on the proposed service provider) should be clear. Also, the attendees suggested that the colour code and used signs for the DPIAT overall output, e.g. a high risk should show up as red, not green (this seemed due to a glitch with the system on the day). It was noted that risk mitigation is missing and also other factors that might be relevant for assessing risk, e.g. who owns the key?

There was a difference in opinion about how helpful an overall rating would be for the first section. Perhaps, the consensus was that it would be helpful indeed for decision making, but one would have to be very careful how that was done. It is important that there would be some explanation about what this overall rating would mean, and what the implications would be. It was highly stressed by the more mature researchers and experts that it should be clear how the user should interpret the findings, and what it meant for them in terms of what they should do next, etc.

It was advised to check whether or not the very high and extremely high, etc. of the second part were indeed the same bands (and associated meaning) as those used in the first part -it seemed that there might be a mismatch with different terms being used.

Perhaps it needed to be clearer how DPIAT should be used in the context of an overall DPIA process, and how things like consultation of stakeholders fit in. We do have some information on this, but it still seems not so clear about what else must be done, and when and how often the DPIAT tool could be used. Questions raised related to how and who assess cloud providers. An important issue is also time consuming for running the tools. It would be very interesting to run all the tools at once.

The major concern that attendees had was that there was no justification of why the results were given, or explanation of how the results were obtained, or way of the user or a third party to check the verification of the process used to obtain these results. One aspect of dealing with this is that an explanation of how the results were obtained should be added within the tool in a way that it could be accessed by a user exactly, even if the particular chain of processing leading to that particular result might not be exposable in other words, to be able to click to see how it was done, and provide more evidence about that. Which results from the system can be relied on, and why? There should be more explanation about how the risk was obtained, to what extent probability and impact are taken into account, etc., and whether that differs across the different sections of output. In what way is the output to be regarded as a proof for interpretation and used by the user, and in what way could it be provided as a proof for a data protection authority? The legal implications are different. What is the outcome of the result (single answer, guidelines, etc.)? What is it useful for?

COAT

Some options in the answers given seem very odd, e.g. in the encryption options there should be a distinction made between data at rest and during transit, and also the types of weaker and stronger encryption should be brought out more accurately. We had already realised this and updated the questionnaire offline, although that was not yet reflected within the demo version. Instead of just having the option of Europe in some of the questions, there should be the possibility (by another question popping up to bring up certain countries if Europe were selected) to allow more specific selection of countries (i.e. local is not enough, it may need to be local and Belgium, or whatever). This is necessary for various reasons (legal and user preferences).

There were also issues relating to what we have been showing for some time in this same demo versus our proposed improvements that were not yet reflected within it, such as more sophisticated ordering of results, display of certification/seals, etc. Questions from the audience were related to the use of standards, in the sense of how everything related to the tool would be documented.

Concerning legal regulations it was pointed out that different regulations depending on the countries should be taken into account.

A-PPL

One of the first questions that arose from the audience was why the A-PPL language was chosen. If the reason is a question of scalability this seems to be a good reason. The way requirements are dealt with is also another of the questions: are all the requirements translated into the policy? The A-PPL tool is based on the existence of a privacy officer. We have to check what is going to be done in the case where there is not such an officer, as it could be the case for example of SMEs.

Conclusion and Future Work

In this paper we have described the tools and the feedback provided by attendees during the A4Cloud workshop held at the IFIP summer school 2015. The A4Cloud project tackles the problem of providing accountability from an interdisciplinary perspective involving technical, legal and socio-economic aspects. A4Cloud provides a set of tools and mechanisms for the different stakeholders involved in the cloud for achieving accountability. Thus, in this paper, we have concentrated on tools for facilitating choice (COAT and DPIAT) and tools for offering control (DT, DPPT and A-PPL Engine). At the time of the workshop all these tool prototypes were in a mature enough state to be demonstrated. Therefore, the attendees could have a very good idea of how they could be used by users or providers.

The feedback from this workshop is being taken into account as the tool prototypes are further modified. Many of the issues raised have already been addressed within improved versions of the tools. We are carrying out further validation of the tools, for example, within a wearables scenario, as well as their socio-economic impact assessment.

Fig. 1 .

 1 Fig. 1. COAT High Level Architecture

Fig. 2 .

 2 Fig. 2. Example COAT Screenshot

Fig. 4 .

 4 Fig. 4. Example Section of DPIAT Full Screening Questionnaire

Fig. 6 .

 6 Fig. 6. The Trace View of the Data Track.

Fig. 7 .

 7 Fig. 7. Privacy Policy Definition and Enforcement

This work has been partially funded by the European Commission through the FP7/2007-2013 project A4Cloud under grant agreement number 317550. The first author is supported by the Ministery of Economy of Spain through the Young Researchers Programme: project PRECISE (TIN2014-54427-JIN). The authors would like to thank Saul Formoso for taking notes during the workshop and all the members of A4Cloud involved in the development of the tools.


Olha Drozd
email: olha.drozd@wu.ac.at

Privacy Pattern Catalogue: A Tool for Integrating Privacy Principles of ISO/IEC 29100 into the Software Development Process

Keywords:

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Any software that processes personally identifiable information (i.e. any information that can be used to identify the natural person to whom such information relates, or is or might be directly or indirectly linked to that person [1]) should protect the privacy of data subjects. In order to develop qualitative privacy-friendly software, privacy should be integrated into software at early stages of the software development process. At the design stage of the software development cycle one can utilize the privacy patterns to facilitate privacy integration [START_REF] Hoepman | Privacy design strategies[END_REF]. "A pattern is a piece of literature that describes a design problem and a general solution for the problem in a particular context [START_REF] Coplien | Software Patterns[END_REF]." Some attempts were made to collect privacy patterns, but those collections were limited to a very specific context. For example, Hafiz concentrates on patterns for the design of anonymity systems [START_REF] Hafiz | A collection of privacy design patterns[END_REF]. The Privacy and Identity Management in Europe for Life pattern collection provides a list of human-computer interaction patterns [START_REF] Fischer-Hübner | HCI Pattern Collection -Version 2[END_REF]. The University of California (UC) Berkley School of Information's collection [START_REF]Privacy Patterns, privacypatterns[END_REF] broadens the application context of privacy patterns, but describes only 9 privacy patterns. PRIPARE project [START_REF]eu -Collecting Patterns for Better Privacy[END_REF] presents the newest attempt to collect privacy patterns. Howev-er, their list of patterns is also limited. They added some new patterns but omitted some old ones that were mentioned in the previous work.

While reviewing the literature, no pattern classifications, catalogues or tools providing a structured approach to privacy pattern integration into the software development process in connection with the ISO (the International Organization for Standardization) /IEC (the International Electrotechnical Commission) 29100 standard were found. To fill this gap an interactive online privacy pattern catalogue was developed. This structured solution-oriented representation of patterns that collects numerous patterns in one place and allows end user to easily navigate through the catalogue, could convince companies to adopt privacy by design approach.

The target audience of the catalogue is software architects and software developers. The catalogue enables them to efficiently integrate the privacy principles of ISO/IEC 29100 into the software development process. The ISO/IEC 29100 privacy principles were selected because they comprehensively cover the domain of privacy requirements and because the standard is internationally applicable.

The paper is divided into 5 parts. The background part provides the background information on the design patterns and the ISO/IEC 29100 standard. The method section describes the structured-case method employed in this research project. The part following the methodology section explains the idea of the privacy pattern catalogue and describes its functionality. The discussion part provides an overview of the issues that appeared during the compilation of the catalogue and describes how those issues were addressed in the catalogue as well as how they might be solved in the future work. Finally, the conclusion summarizes the main points of the paper.

Background

Privacy by design aims to integrate privacy requirements into every stage of the software development process [START_REF] Hoepman | Privacy design strategies[END_REF]. This paper addresses the problem of privacy integration at the design stage of the system development process by using design patterns as one of the main components of the catalogue. The descriptions of 11 privacy principles from the ISO/IEC 29100 standard were selected as the source of the privacy requirements.

Design Patterns

As it was mentioned before, privacy patterns may help to integrate privacy at the design stage of the software development process [START_REF] Hoepman | Privacy design strategies[END_REF]. There exist many definitions of patterns. For instance, in building and architecture pattern describes an iterative problem in a specific environment and a reusable solution to it [START_REF] Alexander | A Pattern Language: Towns, Buildings, Construction[END_REF]. In software engineering "patterns codify reusable design expertise that provides time-proven solutions to commonly occurring software problems that arise in particular contexts and domains [START_REF] Schmidt | Patterns, frameworks, and middleware: their synergistic relationships[END_REF]." Another definition of the term pattern in software engineering field describes pattern as "a description of communicating objects and classes that are customized to solve a general design problem in a particular context [START_REF] Gamma | Design patterns: elements of reusable object-oriented software[END_REF]."

All the above-mentioned definitions suggest describing patterns in terms of problem description, solution to the problem and context where this problem occurs. The existent lists of privacy patterns describe them in different ways. Hafiz provides a very detailed description of patterns and uses the following sections: intent, also know as, motivation, context, problem, forces, solution, design issues, consequences, known uses, related patterns [START_REF] Hafiz | A collection of privacy design patterns[END_REF]. PRIPARE project uses a similar approach in its description of privacy patterns. Every pattern here is described with the help of summary, problem, context, goals, motivating example, solution, constraints and consequences, known uses, tags, categories and technology readiness level. Patterns collected at the UC Berkeley School of Information use a less detailed description template. The sections intent, context, problem, solution and examples are used in that project. The template of the PrimeLife project contains the following sections: problem, solution, use when, how, why, related patterns [START_REF] Fischer-Hübner | HCI Pattern Collection -Version 2[END_REF]. The sections problem, solution and context seem to be a universal way to describe patterns because they are always present, in various formulations, in the definitions as well as in the pattern lists. That is why for the purpose of this research the patterns were explained with the help of those three sections. The consequences section was added to the description to provide a better understanding of the results after implementation of the pattern. This section proved to be useful in the above-described pattern lists as well.

For example, the pattern Data Track from the PrimeLife project is described in the catalogue as follows: [START_REF] Fischer-Hübner | HCI Pattern Collection -Version 2[END_REF] Table 1. Description of the Data Track pattern.

Section Description Problem

Users may lose an overview of what kind of data they disclosed to whom under which conditions Solution Provide an end-user transparency tool that provides the user with a detailed overview of all the user's personal data releases to communication partners Context Implement when personal data are released Consequences Easier recollection of where, when and under what conditions the user posted which data

ISO/IEC 29100 as the Source of the Privacy Requirements

The aim of the catalogue is to facilitate the integration of privacy requirements at the design stage of the software development process. There are a number of data protection laws that could be used as a requirement sources but they are often specific to every country and are, unfortunately, slightly outdated. For example, "Privacy Online: Fair Information Practices in the Electronic Marketplace" [START_REF] Anthony | Privacy Online : Fair Information Practices in the Electronic Marketplace a Report To Congress[END_REF] is specific to the United States, "Organization of Economic Co-Operation and Development Guidelines on the Protection of Privacy and Transborder Flows of Personal Data" [START_REF]and Development: OECD guidelines governing the protection of privacy and transborder flows of personal data[END_REF] is somewhat outdated, General Data Protection Regulation [13] covers only the European Union and still needs to be finalized.

The ISO/IEC 29100 standard was chosen as the source of the privacy requirements, as it is an international standard that "provides a high-level framework for the protection of personally identifiable information (PII) within information and communication technology (ICT) systems [1]." Moreover, the ISO/IEC 29100 standard was compiled to help, inter alia, architect, design and develop ICT systems or services in a privacy-friendly way [1]. In addition to the advantageous characteristics mentioned above, being international, this standard could be equally applied in different countries. It also comprehensively covers the domain of privacy requirements.

In the standard the requirements are presented in the form of 11 privacy principles: consent and choice; purpose legitimacy and specification; collection limitation; data minimization; use, retention and disclosure limitation; accuracy and quality; openness, transparency and notice; individual participation and access; accountability; information security; privacy compliance [1]. Each principle is then described in more detail with the help of the list of bullet points. Every bullet point explains, in the form of an instruction, what adhering to this or that principle means. For instance, to adhere to the collection limitation principle one should limit "the collection of PII to that which is within the bounds of applicable law and strictly necessary for the specified purpose(s) [1]." Other principles are explained in a similar way. The number of bullet points varies depending on the privacy principle.

The privacy principles of ISO/IEC 29100 and the instructions form the first and the second level of the catalogue hierarchy respectively. The third level of the catalogue is filled with the privacy patterns that help (directly or indirectly) to implement the corresponding privacy principle instruction (Figure 1).

Method

The catalogue was compiled by applying a structured-case methodological framework for building theory in information systems research [START_REF] Carroll | Structured-case: a methodological framework for building theory in information systems research[END_REF]. The structured-case consists of 3 structural components, namely "the conceptual framework, the research cycle and the literature-based scrutiny of the theory built [START_REF] Carroll | Structured-case: a methodological framework for building theory in information systems research[END_REF]." The general idea of the structured-case research method is shown in Figure 2.

Conceptual Framework

According to Miles and Huberman, "a conceptual framework explains either graphically or in narrative form, the main things to be studied -the key factors, constructs or variables -and the presumed relationships among them [START_REF] Miles | Qualitative Data Analysis[END_REF]." Figure 1 depicts the concept of the privacy pattern catalogue -the elements of the catalogue and the hierarchical relationship between them. The first list of privacy patterns for the conceptual framework was compiled from the reviewed privacy pattern literature. As it is allowed, or even welcomed, in structured-case methodology to update the framework if valuable knowledge is gained during the research process [START_REF] Carroll | Structured-case: a methodological framework for building theory in information systems research[END_REF], new patterns were added and the description of some patterns was refined in the course of the project.

Research Cycle

Each research cycle was divided into four stages: plan, collect, analyse and reflect [START_REF] Carroll | Structured-case: a methodological framework for building theory in information systems research[END_REF].

Plan. 11 interviews with privacy experts (PhD candidates, PhDs, professors and professionals in the field of data protection) from Austria, Germany, Greece, Ireland, Sweden and the USA were planned. The three main goals of those interviews were to classify the patterns according to the privacy principle instructions of ISO/IEC 29100, to expand the set of privacy patterns derived from the literature review and, if necessary, to update the description of patterns. To make the process of interviewing easier, the online questionnaire was developed. The questionnaire consisted of 55 privacy principle instructions and 28 privacy patterns with the descriptions. The patterns and their descriptions were derived from the literature review.

Each instruction of the privacy principle formed a separate question. For example, the consent and choice principle is described with the help of a bulleted list of 5 instructions [1]. Therefore, there were 5 questions concerning the consent and choice principle in the questionnaire. The privacy patterns were described in terms of what context they can be used in, what problem they solve, what solution they offer and what consequences should be expected after the implementation of the patterns. That is, in the same way as it was planned to describe the patterns in the catalogue. The description was shown upon mouseover on the 'i' icon. Figure 3 illustrates the cropped version of the first page of the questionnaire.

It was decided that the results of this research project would be presented in the form of the interactive online privacy pattern catalogue.

Collect. 11 interviews were conducted at the collection stage of the research cycle. The privacy experts were asked to choose patterns that, in their opinion, could implement the instructions of the privacy principles. They also chose what connection (direct or indirect) the pattern had to the privacy principle instruction. The interviewees were asked to explain their decisions briefly. The questionnaire also presented a possibility to add privacy patterns if the experts suggested patterns that were missing from the list. The interviewees also commented on the descriptions of patterns and on the questionnaire in general. The answers from the questionnaire were saved into the database and the experts' comments were recorded. Reflect. The fellow researchers evaluated the results of the analysis and reflected on the interviewees' comments regarding the research process and the conceptual framework. The conceptual framework was updated with the new knowledge acquired at previous stages of the research cycle.

Theory Building

The research cycles were stopped at 11 interviews because the amount of new data, improvement suggestions and ideas received from the experts were low in the last interviews.

The last component of the structured-case methodology requires the results to be compared to the existent literature.

The findings were compared with the scarce literature on privacy patterns as well as with the technology descriptions suggested during interviews. To the best of my knowledge there were no attempts made to classify privacy patterns according to the privacy principles of ISO/IEC 29100, so no comparison was performed on the findings concerning this matter.

Privacy Pattern Catalogue

The interactive online privacy pattern catalogue (Figure 5) [START_REF]Privacy Pattern Catalogue, privacypatterns[END_REF] has been developed to present the results in a comprehensible and usable way. This online tool presents 40 privacy patterns in a structured way by grouping them according to the privacy principle instructions. The catalogue could be useful for software architects and software developers in the projects where ISO/IEC 29100 certification is required. Depending on the status of the project, software architects can use the catalogue in both top-down and bottomup directions. A top-down approach is used to identify which patterns implement a specific ISO/IEC 29100 privacy principle or instruction. A bottom-up approach provides the information on the ISO/IEC 29100 privacy principle and the corresponding instruction implemented by the chosen privacy pattern. Additionally, one can utilize the catalogue for the training purposes.

Two extra functionalities were integrated into the catalogue:

─ Search by privacy pattern ─ Export the report

The first feature gives a possibility to view what instructions and privacy principles are (to some extent) covered by the chosen privacy pattern.

The second feature could be very useful for the top-down approach. Because of the large amount of possible combinations, it could be difficult and time-consuming for a software architect to document the principles, instructions and patterns that are relevant to the project. To address this issue the system allows software architects to select required elements, stores all chosen items in a database through the whole selection process and offers a possibility to generate a report (Figure 6) that contains all selected elements.

Discussion

While compiling the above-described catalogue a number of issues occurred.

Although the interviews are considered to be one of the powerful methods for gaining knowledge, there are some problems connected with this way of gathering information. In the case of this project the interviews lasted up to 4.5 hours and the interviewees mentioned the problem of time pressure and the need to complete the questionnaire as quickly as possible. Indeed, the lack of time can cause two problems: either the information gathered will be incomplete or the interviewees will generate more input than they usually would do in the normal situation but the obtained information could be unreliable [START_REF] Myers | The qualitative interview in IS research: Examining the craft[END_REF]. In order to examine how this issue might have influenced the results, the existent catalogue could be compared to the results obtained from the answers to the questionnaire that was filled out without time pressure.

The conceptual framework illustrates a clean tree structure of the catalogue. However, the privacy pattern instructions of the ISO/IEC 29100 overlap in some cases. This makes it possible that the same pattern could be assigned to different instructions. To mitigate this issue and to give a better overview of what instructions could be covered by one and the same pattern, the catalogue offers the 'search by privacy pattern' functionality. By using this functionality the user can obtain a summary of all the privacy principle instructions and corresponding privacy principles that are (to a certain extent) implemented by the chosen pattern.

Another issue mentioned by some interviewees was that sometimes the name and the description of the pattern were formulated in a very broad or very narrow manner. This may explain why abstract patterns appeared more often in the catalogue compared to the concrete ones. To partially solve this issue the comments from the interviews will be used to extend the catalogue by categorizing patterns into different dimensions and adding various angles of view in terms of context. This should bring even more structure to the pattern collection.

Additionally, the patterns could be described in more detail using more sections in the description template. One area that is currently under investigation is the compilation of a standardized template for privacy patterns. After the template is finalized the patterns in the catalogue should be updated according to it.

Another issue arises due to the fact that there are some privacy principle instructions, which do not have corresponding direct privacy patterns. This research project showed that "technical" patterns cover only a part of the ISO/IEC 29100 requirements. Some requirements could only be implemented by the organizational measures and processes. This means that the privacy patterns in the field of information technology governance should be identified and described.

The catalogue could also be extended by adding another hierarchy level (Figure 7) to cater for privacy enhancing technologies (PETs) that would be assigned to the corresponding patterns.

Conclusion

This work presents an interactive online privacy pattern catalogue for software architects and software developers drawing both on a review of existing privacy patterns and on the interviews with privacy experts.

In the catalogue, privacy patterns are matched with the privacy principle instructions of the ISO/IEC 29100 standard, i.e. the users can view the list of patterns that implement a particular privacy principle instruction and read detailed information about those patterns. The users can also search by a particular pattern to see what privacy principles and their instructions could be implemented by that pattern. The catalogue provides a possibility to select patterns that are relevant to the project, from the software architect's point of view, and then automatically generate a report that presents all the selected items in a structured manner.

The process of privacy pattern classification showed that "technical" privacy patterns cover only a part of the privacy principle instructions of the ISO/IEC 29100 standard. As a result, the catalogue contains privacy principle requirements without corresponding direct privacy patterns. Those principle instructions could be implemented with the help of organizational processes.

Fig. 1 .

 1 Fig. 1. Catalogue concept

Fig. 2 .

 2 Fig. 2. The structured-case research method (Source: Carroll, J.M., Swatman, P. A.: Structuredcase: a methodological framework for building theory in information systems research. Eur. J. Inf. Syst. 9, 235-242 (2000))

Fig. 3 .

 3 Fig. 3. The first page of the questionnaire (cropped version)

Fig. 4 .

 4 Fig. 4. The results for the 'collection limitation' principle

Fig. 5 .

 5 Fig. 5. The interactive privacy pattern catalogue

Fig. 6 .

 6 Fig. 6. Generated report (shortened version)

Fig. 7 .

 7 Fig. 7. Concept of an extended catalogue