EnCoRe Project Deliverable - HP Labs Project Deliverable ... Model allowing assignment of...

EnCoRe Project Deliverable

Title: Technical Architecture for the first realized

Case Study

Identifier: D2.1

Version: 1.0

Date: 10 February 2010

Status: Final

Authors: Marco Casassa Mont, Yun Shen,

Gina Kounga, Siani Pearson

Editor: Pete Bramhall

Reviewers: Edgar Whitley, Nick Papanikolaou,

Dave Lund, Liam Curren

Class: Public

Summary

This document is a formal deliverable of the EnCoRe project and contains the

definition of the EnCoRe Technical Architecture for the first realized Case

Study – an Enhanced Employee Data Scenario. It also describes that scenario

and its requirements regarding consent management.

EnCoRe: Ensuring Consent and Revocation

ii

About the EnCoRe project

The EnCoRe project is an inter-disciplinary research project into informational privacy,

undertaken collaboratively by UK industry and academia, and partially funded by the

Technology Strategy Board (TP/12/NS/P0501A), the Engineering and Physical Sciences

Research Council and the Economic and Social Research Council (EP/G002541/1).

Enabling individual citizens and consumers to retain control over their personal data can be

achieved in a number of very different ways that are based on different trust models. When

an individual discloses his or her personal data to commercial and other entities, he or she

also grants, sometimes implicitly, consent for it to be used for one or more purposes.

Subsequent control over the storage, use and onward sharing of that data relies on the notion

of trust that the given consent will be respected.

Currently, many organisations‟ personal data management operations do not justify the trust

placed in them by the data subjects. This is for a variety of legal, regulatory, process,

economic and technical reasons.

The EnCoRe project‟s aims are :

• To enable business to adopt scalable, cost effective and robust consent and revocation

methods for controlling the usage, storage, location and dissemination of personal

data.

• To benefit individuals by providing meaningful, intuitive mechanisms which will

allow them to control the use of their personal information held by others.

• To help restore individual confidence in participating in the digital economy and so,

in turn, benefit the wider society.

The overall vision of the project is to make giving consent as reliable and easy as turning on

a tap and revoking that consent as reliable and easy as turning it off again.

The project partners are:

• Hewlett–Packard Laboratories

• HW Communications Ltd

• London School of Economics and Political Science

• QinetiQ

• HeLEX Centre for Health, Law and Emerging Technologies; University of Oxford

• Warwick Digital Laboratory, University of Warwick

The EnCoRe project runs from June 2008 to November 2011.

Its website is www.encore-project.info and it tweets at www.twitter.com/encore_project

http://www.encore-project.info/

http://www.twitter.com/encore_project


iii

Executive Summary This document is a formal deliverable of the EnCoRe project. It contains the definition of the

EnCoRe Technical Architecture for the first realized Case Study: an Enhanced Employee

Data Scenario. It also describes that scenario – specifically the use, by employees of an

organisation, of a Web2.0-style service for work-related and personal purposes – and its

related requirements regarding consent management. These requirements were gathered and

defined by legal and social science research within the EnCoRe project, and were influenced

by its concept formalisation research.

The scope of the EnCoRe Technical Architecture for this first Case Study encompasses all

the technical functions required for the management (including capture and revocation) and

enforcement of individuals‟ consents that are pertinent to the Case Study‟s scenario. The

technical architecture is the block-level design of the necessary technical system, at the level

of functional blocks (i.e., software and service components) and the data flows between them

and to/from humans, other technical systems, compliance and other business processes and

regulatory environments. Its goal is to provide the basis for an EnCoRe reference

implementation that validates the approach and the technology. To that end this document‟s

approach is to start with contextual information and overviews, and incrementally refine the

level of detail. Most of this detail is contained within Appendices.

Document History Doc ID Description Date

V1.0 First published version 10Feb2010

Acknowledgements The editor and authors wish to thank those who reviewed the drafts and also those who

contributed ideas and material to this deliverable, including Simon Wiseman (the WorkBook

enhancement to the basic employee data scenario), Bassem Ammar (the sequencing of the

interactions), Liam Curren (legal input) and others in the EnCoRe project.


iv

Table of Contents Executive Summary ................................................................................................................. iii

Document History .................................................................................................................... iii Acknowledgements .................................................................................................................. iii Table of Contents ...................................................................................................................... iv List of Figures .......................................................................................................................... vii Abbreviations ............................................................................................................................ ix

1. Introduction ........................................................................................................................ 1 2. Analysis of Consent and Revocation Management ............................................................... 4 3. Enhanced Employee Data Scenario ....................................................................................... 9

3.1Assumptions of Scenario .................................................................................................. 9

3.2 Description of Scenario.................................................................................................. 11 3.3 Scenario Use Cases ........................................................................................................ 12

4. Functional Requirements ..................................................................................................... 15 5. High Level Principles & Technical Architecture................................................................. 17

5.1 High Level Principles .................................................................................................... 17 5.2 Technical Architecture ................................................................................................... 17 5.3 Mapping Architectural Components to Functional Requirements ................................ 21

5.4 Data Model..................................................................................................................... 23 5.5 Privacy-Aware Policies .................................................................................................. 24

Concept 1: Reference to protected resources (Personal Data) ......................................... 28

Concept 2: Coping with different access patterns/scalability .......................................... 29 Concept 3: Enabling “Conditional Yes” as an outcome of policy evaluation ................. 30

Concept 4: Supporting current security access control constraints ................................. 31 Concept 5: Supporting access control-based obligation policies ..................................... 31

6. Refined Technical Architecture ........................................................................................... 34 7. Conclusion ........................................................................................................................... 40

References ................................................................................................................................ 41 Appendix A: Use Cases for the Enhanced Employee Data Scenario ...................................... 44

A.1 General Legal Input ...................................................................................................... 44 A.2 Use Cases ...................................................................................................................... 45

UC1 - Mary is hired at Company X ................................................................................. 45 UC2 - Mary voluntarily joins a few company initiatives ................................................ 49 UC3 - Company X changes the provisioning of some services provided to Mary.......... 51 UC4 - Mary changes her affiliation to a few of Company X services ............................. 52

UC5 - Mary changes some of her personal data (profile) ................................................ 53 UC6 - Mary changes roles and gets promoted ................................................................. 54 UC7 - Mary is temporarily seconded in a new department, in a different country ......... 55

UC8 - Mary comes back to UK ....................................................................................... 57 UC9 - Mary goes on sick leave for 6 months .................................................................. 58 UC10 - Phil, a Contractor, joins Mary's team .................................................................. 58 UC11 - Company X introduces new data analytics tools ................................................ 59 UC12 - Mary fires Phil because of misconduct ............................................................... 64

UC13 - Mary gets demoted .............................................................................................. 65 UC14 - Mary leaves Company X ..................................................................................... 66 Use Cases Related to the WorkBook service ................................................................... 67

UC15 - Mary starts using the company's WorkBook service .......................................... 68


v

UC16 - Mary elects to allow a subset of her WorkBook data (her public profile) to be

given to external organisations ........................................................................................ 69

UC17 - Mary uses the WorkBook service to book holidays ........................................... 70 UC18 - Mary changes her preferences in the WorkBook Service ................................... 71

Appendix B: Architectural Interaction Flows .......................................................................... 73 Administrative Use Case 1................................................................................................... 73

High level component interactions .................................................................................. 74

Interaction details ............................................................................................................. 75 Administrative Use Case 2................................................................................................... 75

High level component interactions .................................................................................. 75 Interaction details ............................................................................................................. 77

Employee Use Case 1 (UC1) ............................................................................................... 78 High level component interactions .................................................................................. 78 Interaction details ............................................................................................................. 79

Employee Use Case 5 (UC5) ............................................................................................... 82


Employee Use Case 17 (UC17) ........................................................................................... 85 High level component interactions .................................................................................. 85

Interaction details ............................................................................................................. 87 Employee Use Case 14 (UC14) ........................................................................................... 90


Employee Use Case 16 (UC16) ........................................................................................... 93 High level component interactions .................................................................................. 93


High level component interactions .................................................................................. 96



Error Management Guidelines ........................................................................................... 101 Appendix C: Data Model ....................................................................................................... 102

C.1 Data collected from the data subject ........................................................................... 102

C.2 Preferences .................................................................................................................. 105 C.2.1 Consent and revocation preferences ..................................................................... 105 C.2.2 Revocation ............................................................................................................ 107 C.2.3 Choices ................................................................................................................. 107

C.2.3.1 A “level based” approach .............................................................................. 107

C.2.3.2 Assign preferences to each data item ............................................................ 107

C.2.3.3 Assign preferences to a group of data items ................................................. 107

C.3 A data model for relational databases ......................................................................... 108 C.3.1 Models for the case where different items have different preferences ................ 108

C.3.1.1 Proposal 1 ...................................................................................................... 108


vi

C.3.1.2 Proposal 2 ...................................................................................................... 109

C.3.2 Models for the case where different groups of items have different preferences 109

C.3.2.1 Proposal 1 ...................................................................................................... 109

C.3.2.2 Proposal 2 ...................................................................................................... 110

C.4 A data model for LDAP directories ............................................................................ 110 LDAP approach 1: Assign the same preferences to all the attributes that specify a same

entry ............................................................................................................................... 112

LDAP approach 2: Assign the same preferences to all the attributes that specify a group

of entries......................................................................................................................... 114

LDAP Approach 3: Assign the same preferences to all the attributes that belong to a

same defined group of attributes .................................................................................... 115 Revocation ..................................................................................................................... 115 Registry .......................................................................................................................... 115

C.5 Conclusion ................................................................................................................... 116

Appendix D: XACML Access Control Policies .................................................................... 117 D.1 XACML: Data Flow and Language Models ............................................................... 118

Data Flow Model ........................................................................................................... 118 XACML Language Model ............................................................................................. 119

Limitations ..................................................................................................................... 120 D.2 Examples of XACML policies .................................................................................... 120

Request example ............................................................................................................ 121 Access control policy example ...................................................................................... 121

D.3 Matching Process ........................................................................................................ 123 Analysis.......................................................................................................................... 124

Appendix E: Related Work .................................................................................................... 128


vii

List of Figures Figure 1: States of data with related consent ............................................................................. 7

Figure 2: High level architecture ............................................................................................. 18 Figure 3: Privacy-aware policy enforcement ........................................................................... 26 Figure 4: Privacy policy enforcement example ....................................................................... 27 Figure 5: Policies associated with protected resources and metadata ...................................... 29 Figure 6: Data access patterns .................................................................................................. 30

Figure 7: Conceptual model ..................................................................................................... 32 Figure 8: Refined architecture ................................................................................................. 38 Figure 9: SAR process for PD received from 3

rd party (Copied from [39], p40) .................... 48

Figure 10: Considerations relevant for employee monitoring (Copied from [39], p59) ......... 61 Figure 11: Administrative use case 1 interactions ................................................................... 74 Figure 12: Use case 1 interaction details ................................................................................. 75 Figure 13: Administrative use case 2 interactions ................................................................... 75 Figure 14: Instructions for administrator ................................................................................. 76

Figure 15: Use case 2 interactions ........................................................................................... 77 Figure 16: UC1 interactions ..................................................................................................... 78 Figure 17: UC1 interaction 2 ................................................................................................... 79

Figure 18: UC1 interaction 3 ................................................................................................... 80 Figure 19: UC1 interaction 4 ................................................................................................... 80 Figure 20: UC1 interaction 5 ................................................................................................... 81

Figure 21: UC2 interactions ..................................................................................................... 82

Figure 22: UC2 interaction 2 ................................................................................................... 83 Figure 23: UC2 interaction 3 ................................................................................................... 84 Figure 24: UC2 interaction 4 ................................................................................................... 84

Figure 25: UC17 interactions ................................................................................................... 85 Figure 26: UC17 interaction 1 ................................................................................................. 87

Figure 27: UC17 interactions 2 and 3 ...................................................................................... 88 Figure 28: UC17 interaction 3 ................................................................................................. 89 Figure 29: UC17 interaction 5 ................................................................................................. 89 Figure 30: UC14 interactions ................................................................................................... 90

Figure 31: UC14 interaction 3 ................................................................................................. 91 Figure 32: UC14 interaction 4 ................................................................................................. 91 Figure 33: UC14 interaction 5 ................................................................................................. 92

Figure 34: UC16 interactions ................................................................................................... 93

Figure 35: UC16 interaction 2 ................................................................................................. 94 Figure 36: UC16 interaction 3 ................................................................................................. 95 Figure 37: UC18 interactions ................................................................................................... 96

Figure 38: UC18 interaction 2 ................................................................................................. 97 Figure 39: UC18 interaction 3 ................................................................................................. 98 Figure 40: UC15 interactions ................................................................................................... 99 Figure 41: UC15 interaction 3 ............................................................................................... 100 Figure 42: UC15 interaction 4 ............................................................................................... 100

Figure 43: UC15 interaction 6 ............................................................................................... 101 Figure 44: A data subject oriented approach for the LDAP approach 1 ................................ 112 Figure 45: An organisational unit oriented approach for the LDAP approach 1 ................... 114

Figure 46: Model allowing assignment of preferences per group of entries or attributes ..... 115


viii

Figure 47: Data Flow Model .................................................................................................. 118 Figure 48: Language Model ................................................................................................... 120


ix

Abbreviations

The following abbreviations are used frequently in this document:

C&R Consent(s) and Revocation(s)

GUI Graphical User Interface

HCI Human-Computer Interaction

ICO Information Commissioner‟s Office

PD Personal Data

PDP Policy Decision Point

PEP Policy Enforcement Point

PII Personally Identifiable Information


1

1. Introduction A core objective of the EnCoRe project [7] is to progress and advance the state-of-

the-art in consent and revocation management and enforcement from a variety of

perspectives, including social, legal and technological aspects.

This document considers the technical angle, and describes the EnCoRe Technical

Architecture arising from the project‟s first selected case study, which focuses on

normal and enhanced uses of employee data in an enterprise scenario. The aim of this

document is to provide the project‟s first technical reference model and architecture

for the explicit management of consent and revocation within and across

organisations.

It is common practice for enterprises1 and other organisations to collect personal data

(PD)2 and confidential information in order to provide services to individual

consumers or employees and to enable business transactions. These personal data are

often stored, processed, aggregated and shared with third parties. In addition to

enterprises, government agencies and e-commerce sites, new Web 2.0 social

networking sites (e.g., Facebook, LinkedIn, YouTube, etc.) and federated and cloud

computing services are increasingly collecting and using personal information. These

data can range from personally identifiable information (PII), work-related and

financial information to personal pictures, videos and descriptions of personal

experiences and life matters.

However, people are increasingly raising concerns about the lack of effective control

over their3 data once they have been divulged by them, and over the fact that these

data could be misused or shared with other parties without proper consent. In essence,

these concerns involve security and privacy aspects. The main risks are that

personally identifiable information and other personal data could be collected when

not actually required to achieve an agreed goal, and later be used without

authorisation, or be widely exposed. Individuals, in general, are not aware of how

their personal information is actually used, for what purpose and which parties have a

copy. They are not usually given the opportunity to declare their specific consents and

privacy-related personal data management preferences. An interesting example,

highlighting these concerns, is that “88% of individuals want sites to gather their

consent” [1] (cf. [2]). Another example is that over 72% of people surveyed do not

know that charities do not need permission to sell or rent their names and addresses to

other charities [3].

1 In this document, we use the term “enterprise” to refer generically to any commercial or non-state organisation.

However, many of the points we make are equally applicable to non-commercial or state organisations. 2 In this document we mainly use the term “personal data” and its abbreviation “PD”, but also the terms “personal

information”, “personally identifiable information” (and its abbreviation “PII”) and others that we take to have

similar meanings, i.e., information pertaining to a specific individual. We sometimes refer to an individual as a

“data subject”. We use the term “personal data” in the strict sense of its legal definition only when we state

expressly that we are doing so. 3 In line with current English law, possessive references to personal data in this document do not assume that a

data subject has any proprietary rights in personal data. All such references should be read as personal data

relating to a data subject.


2

This applies also in an enterprise scenario where employees might have no choice but

to disclose a large amount of personal and financial information, both to the

employing organisation itself and potentially to third parties with links to the

organisation.

In theory, prior to disclosing their data and giving any consent, individuals (i.e., the

data subjects) should be informed about: the purpose(s) for which such data will (or

may) be used; where it will be stored; the expected retention time; if and which other

parties are involved; the amount and the sensitivity of the information exchanged;

whether the data will be shared onward to yet other parties; whether the consent to use

these data can be revoked. Laws (e.g., EU Data Protection Directive 95/46/EC and

national transpositions of this, etc.) and privacy guidelines [4, 5] are already in place

and (to some degree) mandate this, but there is little assurance that they are actually

enforced. The terms of consent for using personal data for specific purposes, under

certain conditions, and any subsequent revocation of this consent will determine how

personal data should be handled once they have been disclosed.

In practice, even well-intentioned organisations struggle to take into account and

enforce individuals’ preferences and consent statements. Some organisations do not

even fully know where customers’ and other individuals’ data are stored in their IT

infrastructures, who can actually access them and how they flow around. The practical

management of revocation of previously-stated consent is even more challenging.

Data are usually copied or moved around in different systems and can be released to

other parties. Consent declarations rarely follow these data. In this context, managing

revocation could be hard, if not impossible.

The concepts of consent and revocation are not new, at least from a legal perspective.

However, little progress has been made in understanding the practical implications, in

particular within large organisations, including actual requirements and potential

technical approaches to satisfy (part of) them. Further complexity comes from

changing legal requirements (and the global complications of different legal

jurisdictions having differing requirements and approaches), and hence the difficulty

organisations have in being compliant and also in knowing whether or not they are

compliant. In this document we take these legal notions into account but it is beyond

our scope to provide an analysis of all related laws and regulations.

A key problem is how to effectively enable individuals to express their consent for the

usage of their personal data and (subsequently) to revoke this consent if they change

their minds. A related problem is how to enable enterprises to effectively manage and

enforce both consent and revocation. Also, complexity in the processes of providing

detailed consent and expressing privacy preferences could undermine individuals’

trust and willingness to further disclose personal information and engage with web

services [6]. Ad hoc and reactive approaches to the management and enforcement of

consent and revocation by organisations also limit their chances to address effectively

the problem, especially when this is coupled with currently inadequate audit and

tracking approaches for personal/sensitive information. Progress needs to be made in

this space: there is an opportunity for research and development of new solutions that

take into account current IT and organisational constraints.


3

This EnCoRe Technical Architecture has been designed by taking into account a

variety of inputs from various EnCoRe project Work Packages (WPs), including WP1

(concepts and taxonomy), WP3 (user requirements and social aspects), WP4 (legal

requirements) and WP5 (risk analysis, assurance and compliance management), as

well as an explicit analysis of an enterprise scenario, related use cases and

implications for consent and revocation.

The remaining part of this document is structured as follows. Section 2 provides some

additional analysis of the concepts of consent and revocation. Section 3 describes the

specific Enhanced Employee Data Scenario that has characterised our first case study,

along with its various implications. Functional and technical requirements, derived

from our overall analysis, are described in Section 4.

Section 5 is the core part of this document, highlighting the high-level principles

underpinning our architecture, as well as providing a high-level overview of the

technical architecture and related assumptions, such as those on policies and data

models.

Section 6 provides a refined version of the technical architecture, based on further

assumptions and providing additional technical detail. The aim of this section (along

with the associated appendices) is to provide all the required specifications and design

details necessary for EnCoRe WP6 to provide a first implementation of a prototype.

Section 7 provides a conclusion.

More details about concepts, design choices, analysis of use cases and technical

aspects can be found in the Appendices. Specifically, Appendix A provides a detailed

analysis of the use cases involved in the Enhanced Employee Data Scenario.

Appendix B further discusses the technical interaction flows for the refined technical

architecture. Finally, Appendices C and D respectively provide more details about the

data model and policies. Appendix E summarises some related work by others.


4

2. Analysis of Consent and Revocation Management

A key aspect of the technical architecture described in this document is its ability to

explicitly manage data subjects‟ consent regarding the use, processing and disclosing

of their personal data, and the revocations of these consents. The data subjects can be

individual people in a variety of roles, e.g., employees, citizens, consumers, etc.

according to the context, although in the remaining part of this document we may

sometimes refer them generically as individuals. This section reflects our analysis of

these concepts by taking into account other EnCoRe work on terminology.

The concept of consent is not new. It has been discussed in a variety of scientific

papers, privacy reports and legislation (e.g. [4, 5]). In the latter, consent is often used

as a synonym for “informed consent”, i.e., the voluntary agreement of an individual

for the specific use of his personal information on the basis of knowledge of what it

will be used for, by whom, where it will be stored, how it will be protected, etc.

Fundamentally, it is a statement that captures the willingness of individuals (data

subjects) that their data could be used for specified purposes, under well-defined

conditions and circumstances. For example, individuals might be willing to allow an

organisation to use their financial data for transactional and payment purposes or to

allow companies to use their address information for delivery and sending contextual

mail. The term “informed” encompasses awareness (the individual must know why

his data are collected, who will have access to them, etc.) and comprehension (the

individual must have an accurate interpretation of what he is asked to consent to)

while “consent” encompasses voluntariness and agreement [2]. In other words,

consent should be freely (i.e., with no coercion) given after the individual has been

informed about the implications of his choices and has fully understood these

implications. In order to translate legitimate individual will, consent should be explicit

and authentic, i.e., it should not be given by another entity than a legitimate individual

and not be modifiable by other entities without valid authorisation. To fulfil the

former, the individual should perform an action that proves his consent, while for the

latter, the source of a consent statement must be authenticated and the integrity of a

consent statement must be guaranteed.

Consent can be conditional, e.g., given for specific purposes. It could be given by

people to be valid only in a well-defined timeframe or just under well-specified

circumstances. For example, individuals might give consent to use their personal data

just for a specific business transaction, and hence there would be no consent for

subsequent usages of this data.

Consent is sometimes confounded with blanket opt-in/opt-out choices. Such choices

define broad criteria and conditions under which data can be used, for example for

named purposes (e.g., marketing, research, etc.) or to receive notifications or to share

data with generic third parties. However, such opt-in/opt-out choices do not usually

define aspects of data retention, how personal data should be processed or to which

parties data could actually be disclosed. They are simple, binary, and typically not

fine-grained; they do not allow data subjects to specify how they would like their

personal data to be managed. For example, an individual can opt-out from receiving


5

further emails relating to commercial products, but doing so does not necessarily

mean that her email address is generally inaccessible or that the organisation is

required to delete it. Consent can be broadly characterised by a wider set of fine-

grained privacy preferences and constraints both on personal data and how such data

should be used, including specific permissions (to disclose data, for specific purposes,

to specific entities) and obligations (such as for deletion or minimisation or

anonymisation of data items, after a period of time or some events happen).

In other words, individuals‟ preferences are key aspects that qualify consent, rather

than just being a mere case of selection of options, such as for opt-in/opt-out choices.

An objective of the EnCoRe project is to enable the data subject to specify to a finer

degree than a simple opt-in/opt-out choice.

The specification of consent makes sense when associated with (or referring to) data.

It can be fine-grained, i.e., specifically refer separately to different items of personal

data. It defines constraints and refinements of organisations‟ policies on how to deal

with data (i.e., access control, privacy and obligation policies, etc.). It can be seen as

“metadata” associated with personal data.

Enforcement of consent requires that each time data are accessed by the organisation,

the constraints (and any additional related policies) specifying how the individuals

want their data to be dealt with, must be taken into account. Consent management and

enforcement is of little value if it can be easily bypassed by people or

applications/services.

Complexity comes from the fact that personal data can be copied into multiple

enterprises‟ systems and moved around. If individuals‟ consents and related

preferences are split from the data, then violations of privacy and their requirements

are likely to occur more casually, easily and often. Therefore, consent and related

preferences should be bound to data in such a way that they cannot be separated, and

data should be dealt with as specified by the individual and the constraints respected

by the data processors. This is particularly hard to achieve when data are disclosed by

an organisation to third parties (e.g., in a supply-chain). A third party receiving the

data should also comply with the individual‟s consent and associated preferences.

Hence, the management of consent has strong implications for the such third parties,

in terms of setting robust access control and privacy enforcement mechanisms, as well

as technological and legal solutions to enforce related obligations and constraints.

Consent declarations are not static. People should be entitled to change their mind,

hence consents can change over time and can be revoked. For example, a person

might have given consent to use her medical data for research purpose, for a

predefined period of time. She might then change her mind, and should be enabled to

revoke that consent, or change it, by qualifying it with different privacy preferences.

On the other hand, the concept of revocation of consent is currently not very well

understood, in particular in terms of its implications for enterprises.


6

In information security, revocation designates the process that renders an object (e.g.,

a public key, a certificate, etc.) invalid. When revocation is applied to the broader

concept of consent, there are wider and more subtle implications: “revocation”

designates the process that permits an individual to invalidate or modify previously

given consent relating to his or her personal data. This revocation should apply to any

copy or instance of these data, both within the organisation that initially collected it

and in any other third party to which these data were subsequently disclosed. In

practice this is hard to achieve.

As with consent statements, for revocation requests the source of a revocation request

must be authenticated and the integrity of a revocation request must be checked.

Mechanisms must be in place in organisations to check the current state of consent,

and ensure that it has not been revoked. A non-repudiable proof that revocation was

executed should be sent to the requester. Revocation requests could happen at any

time. Revocation should be enforced in a reasonable time, as requested by the

individual.

The management of revocation requests can have consequences on data stored at

different places within the organisation. If personal data were copied to various

systems of an organisation and also disclosed to third parties, a change of consent (or

revocation of consent) must be notified to all the involved entities and actioned by

them. Otherwise this would violate individuals‟ privacy preferences.

It is important to understand that revocation can be fine-grained and qualified by

particular attributes. It might not just be a matter of “turning off” the entire consent

given on a set of personal data; instead there could be degrees of revocation, affecting

specific data items. For example, an individual might give consent to use their

personal data (including email and home address) for financial, research and

marketing purposes, for a defined timeframe. Later on he or she might revoke their

consent to use their email address, for any purposes beyond notifications of financial

transaction, for another predefined period of time.

Revocation can be reversible or irreversible. In the above example, the revocation of

consent to use the email address could be reversible. The email address is still likely

to be stored by the organisation, only the way it can be used has changed. On the

other hand, the individual might have qualified their revocation request, by requiring

the deletion of the email address. In this case, revocation is irreversible. Depending on

the context, setting and involved parties, there can be a significant range of

implications of managing consent and revocation.

In the remaining part of this document we focus on the Enhanced Employee Data

Scenario.

The lifecycle management of personal data within and across organisations is affected

by consent, individuals‟ preferences and other constraints, along with the enforcement

of access control policies and related obligations. Consent and revocation themselves

have a lifecycle that need to be managed, impacting how personal data are managed.


7

Figure 1 illustrates some of the different states of data (at different times) along with

related consent.

Data

With No Consent

Data

With Consent

Data

With (Partial)

Consent

Individual:

Data Disclosure

Individual:

Consent

Individual:

Revocation

of Consent

Individual:

Data Disclosure &

Consent

Individual:

Partial Revocation

of Consent

Individual:

Consent

Consent &

Revocation

Lifecycle

No Data

Individual:

Partial

Consent

Users’ Preferences, Access Control & Obligation Policies

Enforcement, Monitoring and Auditing of Policies and Preferences

Individual:

Consent/

Partial Revocation

Individual:

(Partial) Revocation

of ConsentIndividual:

(Partial)

Revocation

of Consent

Figure 1: States of data with related consent

This lifecycle covers an individual firstly giving consent and then changing it over

time, (revoking or partially revoking it) and the management and enforcement of

related obligation policies. Consent and revocation actions can be driven by an

organisation‟s standard policies, qualified by individuals‟ preferences. These have an

impact on the enforcement, monitoring and auditing of the related organisational

standard privacy-aware access control and obligation policies.

Data could have initially been disclosed by an individual with no expression of

consent (so, in theory, these data should not be used but only retained) or have ended

up in this situation, after he or she revoked consent. Alternatively, data might have

been deleted (“No Data”), as a result of revoking consent and/or enforcing related

individual preferences (such as obligations requiring the deletion of data after a

predefined period of time).

However, it is currently hard for individuals, in the first instance, to express and/or

change consent: they might not be provided with a mechanism to do it, or it may be

just partially enabled. Currently there is a lack of a flexible and systematic approach

to the management of consent and revocation, in a way that provides effective

individual control [36]

Research has been carried out to define privacy-aware access control [9, 23, 24] and

privacy obligation policies [10] to enforce aspects of consent when accessing or

manipulating stored personal data.


8

However, in practice, enforcement of consent and revocation is still a problem: actual

control and enforcement points (such as the ones required for privacy-aware access

control and obligation management systems) may not be deployed within an

organisation or might be purely driven by security policies and considerations, etc.

Most current approaches still are based on costly human-operated processes that are

subject to failure. This is partially due to a lack of effective processes to map consent

declarations and changes of consent (e.g., revocations) into actionable commands and

automated processes.

It is not uncommon that organisations might not even know where personal data are

actually stored, as data might have been extensively copied or disseminated. If data

have been disclosed to third parties, there is the very complex problem of how to

propagate consent and revocation to these third parties and how to have assurance

they are going to act on them.

Stickiness of consent to data is a related topic. Consent and revocation statements,

along with related individuals‟ preferences, can be seen as “metadata” that must stick

to the personal data. This affects the enforcement of related policies and obligations

that are contextually affected by this metadata.

However, the data and metadata binding could be broken when copying data, moving

it around or sharing to third parties. This negatively impacts individuals‟ control and

the enforcement of their requests.

A related issue is the lack of effective standards for representing and disseminating

consent and revocation statements and commands within organisations and across

parties. This undermines the possibility of easy collaboration between well-

intentioned organisations, and currently requires the definition of limited and ad hoc

solutions.

How can we help well-intentioned organisations to improve and check on their

practices? On the one hand there is a need for better processes and technological

solutions to sustain them. On the other hand, there is a need for risk assurance and for

better assurance that all the involved parties are behaving as agreed. There is also a

need to provide assurance to individuals about current practices and how effectively

their consents and revocation requests are handled.

This is a complex research area impacting not only individuals and organisations but

also legislation and standardisation. The next section provides more details about the

specific approach and work undertaken by EnCoRe, in an Enhanced Employee Data

Scenario.


9

3. Enhanced Employee Data Scenario

The EnCoRe project selected the Enhanced Employee Data Scenario as its first case

study to explore the implications of handling consent and revocation. This choice has

been motivated by the fact that, on the one hand, the management of employee

privacy in organisations is a well-understood problem, and on the other hand, this area

presents interesting issues in terms of management of consent and revocation in a

context where different business, legal and personal requirements need to be taken

into account. Furthermore, we have been able to leverage direct expertise from

EnCoRe members in this space, in terms of legislation, user needs, processes, issues

and implications. Use cases are introduced and analysed from different perspectives,

including: technical, legal and individuals' requirements (see Appendix A for the

details). These use cases are meant to illustrate key points affecting the management

of consent and revocation (C&R) such as: gathering consent or revoking it from a

user perspective; enforcing consent and revocation within organisational boundaries

and between organisations; dealing with the overall C&R lifecycle and its impact on

data lifecycle, inclusive of notifications, auditing, assurance aspects, etc.

3.1Assumptions of Scenario

We consider employee data, specifically PII and data assumed to be „sensitive‟ (even

if not defined as such in legislation) such as trade union membership,

financial/payment details, home address details, family details, etc. We focus on an

organisational scenario where personal data (primarily of employees) are collected,

stored and handled by individuals, applications, services and (external) third parties.

Personal data can be gathered by different sub-organisations and services within the

enterprise (e.g., HR department, Payroll, Occupational Health department, pension

plan, customer care department, help-desk and customer relationship management

services, web applications to sell products, etc.). A variety of human and automated

processes can affect these data. Data can be moved around, within the organisation,

for processing purposes, e.g., to deal with financial transactions, to handle help-desk

requests, for marketing and research purposes. In this scenario, data can also be

aggregated and manipulated. Under some circumstances, it can flow outside

enterprise boundaries, for example in the case where some of its services are provided

in the context of a supply chain or by outsourced applications.

Individuals (e.g., employees and customers) can interact with the organisation in

multiple ways, ranging from potentially anonymous interactions (e.g., a customer

querying for information online) to the point where personal details need to be

disclosed to enable further interactions (e.g., at the time of employment, for

purchases, delivery of goods, etc.). In this context, individuals make decisions about

how to proceed, for example in terms of disclosing data (if they have a choice -

employees might have no choice for certain types of data), based on a variety of


10

factors, such as reputation of the organisation, perceived level of trustworthiness and

degree of risk, perceived benefit of the transaction and clarity of the involved steps.

We specifically considered the case of a well-intentioned enterprise (e.g., an employer

that is willing to improve its current C&R practice) that is interested in systemically

managing consent and revocation. Current identity management solutions and other

ad hoc security solutions used by enterprises can be leveraged to protect the access

and usage of data, but primarily from traditional security perspectives. Information

lifecycle management solutions (including the ones dealing with data storage,

manipulation and minimisation processes, etc.) generally take into account business or

legislative requirements (e.g., on data retention) but they are rarely driven by privacy

aspects and/or specifically consent and revocation requirements (see Appendix A,

Section A.1, General Legal Input).

Individual preferences and consents, and their dynamic management, are usually not

directly factored into these processes, or are so but just in a limited way. When

dealing with privacy matters, there is usually reliance on human processes that are ad

hoc and more subject to failures than automated processes. We explore the case where

additional solutions and processes are available to track the flow of data and enforce

the terms of consent and revocation when accessing and managing data. In this

context, the actual accessed personal data will depend on the context, consent

specifications and deployed policies.

Ideally, the enterprise should be aware of where personal data are stored and used

within its boundaries, and of how and where data are flowing across them. Risk

assessment solutions should be available to assess the enterprise‟s current compliance

state and make privacy-aware decisions on its practice and processes. Individuals, at

the time of disclosing data, should be entitled to provide their consent, freely and on

an informed basis, in terms of privacy preferences, related permissions and

obligations imposed on the enterprise. Clarity and degree of ease of how an individual

could express this are important (but are not covered in this document). They would

include the possibility for the individual to check on the status of their data, actions

taken on the data, related consent statements, and subsequently to partially or

completely revoke their consent. Changes to consent specifications and revocations

will affect the way people, applications and services (both within the organisation and

in third parties to which data were disclosed) access and use related data.

Of course, this scenario is far away from what can be achieved today, at least in terms

of consent and revocation management. Nevertheless we believe it is important to set

a target, analyse the requirements and suggest steps to enable enterprises and other

organisations to make progress towards it and improve their practice. In doing this,

reality checks are important. Many ideal solutions could be designed and architected,

but their likelihood of being adopted depends on the impact they are going to have on

the organisation, whether or not legislation is mandating their use, the risks at stake

and the eventual mitigation factors they can provide.

More details follow about the chosen scenario and use cases.


11

The Enhanced Employee Data Scenario focuses on Company X, a generic medium-

large enterprise in the UK. This enterprise is willing to provide mechanisms and

solutions to support the management of consent and revocation to employees (and

customers) about personal data that are collected, stored, processed and potentially

disclosed to third parties.

3.2 Description of Scenario

We consider the lifecycle of an employee, Mary, who joins the enterprise, changes

roles, uses various of the enterprise‟s administrative and employee-related services,

and eventually leaves the enterprise. Various use cases have been identified to

describe significant stages and related requirements and needs in terms of the

management of consent and revocation.

Specifically, Mary might need to disclose personal and financial information to the

organisation. Some information, e.g., her employee ID badge number, is also

generated by the organisation itself. We consider the cases where (1) Mary can define

her privacy preferences (e.g., in terms of allowed purposes for using her data,

disclosure to third parties, notifications, etc.) by giving explicit consent, and (2)

subsequently change her mind and revoke her consent.

It is anticipated that personal data are stored within the enterprise and are sometimes

disclosed to third parties.

Personal data can potentially be accessed, processed and managed by other employees

(e.g., managers, payroll clerks) as well as by enterprise applications and services.

Specifically we consider the case of an internal service provided by the organisation,

called WorkBook – a private version of a service that provides functionalities similar

to those of FaceBook and Twitter and operates on the company intranet – providing

social networking capabilities within the organisation. Employees can subscribe,

disclose additional personal data (in addition to information already known by the

organisation) and interact with colleagues. The WorkBook service is enhanced with

consent and revocation management capabilities, supporting degrees of employees‟

preferences and enabling enforcement of these within the organisation.

Employees can use WorkBook to talk about their skills, the projects they are working

on and also for personal information about their social life. Use of WorkBook is

optional, but is encouraged by management to promote teamworking and to help get

maximum benefit from the workforce‟s skills. Data published on WorkBook are not

moderated, but it is considered a disciplinary offence to publish offensive material.

The company‟s privacy policy regards treatment of personal data disclosed on

WorkBook as straightforward: data published „belong‟ to the employee and can be

deleted by him/her at any time. A record of WorkBook data is kept to support

disciplinary and regulatory inquiries, but internal controls over this data prevent

access thereto unless and until it is required for these purposes.


12

Personal WorkBook data may also be provided to external organisations under

arrangements agreed by the company. The agreement is for the company to provide

the data in return for the external organisation providing employees with

advantageous offers. The company will supply personal data and WorkBook content

regarding an employee only if the employee agrees to this. Such agreement requires

an explicit consent. The employee can agree to some or all of their published

(personal) data being shared, and can specify the types of organisation that can be

given their data and the kind of offers they receive in return.

Offers may be made in general terms to all employees, based on the anonymised

aggregated data supplied. These offers can be delivered through advertisements

carried by the WorkBook system. Alternatively, offers can be made to specific

employees, delivered by the corporate email system. In addition, an employee can

agree to their personal email address being handed to the external organisation,

allowing the organisation to send them offers to their personal address.

For example, employees may post information about their skiing holidays on

WorkBook. An external organisation with access to these data may consider it

advantageous to offer employees a good deal on group skiing holiday packages on the

basis of the data they are given. The holiday company gets the opportunity to use

highly targeted advertising and the employees can benefit from the discounts that can

be offered as a result of the advertising being highly targeted.

Another example is that a research company may use the WorkBook data to select

candidates for a research project, based on lifestyle information and high integrity

biographic data. The employees can then be asked if they would like to participate in

research that they are likely to consider a good cause, e.g., support for a cancer

research investigation.

At any time an employee can change their privacy preferences and revoke their

consent.

3.3 Scenario Use Cases

A comprehensive set of use cases has been identified and explored to capture user,

legal and technical requirements, as shown in Table 1.

Table 1: Use Cases

ID Generic Use Cases

UC1 Mary is hired at Company X

UC2 Mary voluntarily joins a few company initiatives

UC3 Company X changes the provisioning of some services provided to Mary

UC4 Mary changes her affiliation to a few of Company X services


13

UC5 Mary changes some of her personal data (profile)

UC6 Mary changes roles and gets promoted

UC7 Mary is temporarily seconded in a new department, in a different country

UC8 Mary comes back to UK

UC9 Mary has a sick leave for 6 months

UC10 Phil, a Contractor, joins Mary's team

UC11 Company X introduces new data analytics tools

UC12 Mary fires Phil because of misconduct

UC13 Mary gets demoted

UC14 Mary leaves the company

ID

WorkBook Specific Use Cases

UC15 Mary starts using Company X‟s WorkBook service

UC16 Mary elects to allow a subset of her WorkBook data (her Profile) to be

given to External Organisations

UC17 Mary uses the WorkBook service to book holidays

UC18 Mary changes her preferences in the WorkBook service

ID

Enterprise Administrative Use Cases

UC0.1 Setting the storage of personal data and Consent and Revocation

preferences

UC0.2 Setting the policies

This list of use cases also includes generic use cases related to Mary‟s career

evolution in the organisation, and choices and use cases specific to the usage of the

WorkBook service and Administrative use cases.

A detailed analysis of each use case is available in Appendix A. This analysis has

identified a comprehensive list of needs and functional requirements that have been

subsequently used to drive the design of the EnCoRe technical architecture. This list

is presented and described in Section 4.

This analysis has also helped to identify a significant subset of the use cases, to focus

our effort on consent and revocation management as well as to provide a manageable

set of use cases to be implemented in a prototype by the EnCoRe project. The selected

use cases have been highlighted in red in Table 1.


14

These use cases have been selected to cover the basic functionalities in terms of

consent and revocation management. These include giving consent, changing it,

allowing for data to be disclosed to third parties, revoking it and exercising the subject

access request rights. UC1 and UC14 have also been included to enable the

management of the two extreme situations for an employee and related PD.


15

4. Functional Requirements

A list of needs and related functional requirements (FRs) has been extracted from the

selected use cases (see Appendix A for details):

FR1: Capturing data subject‟s Consent with data

FR2: Changing data subject‟s Consent

FR3: Capturing data subject‟s Revocation

FR4: Changing data subject‟s Revocation

FR5: Association of Consent/Revocation to Data

FR6: Tracking Data and associated Consent & Revocation (metadata)

FR7: Enforcement of Consent and Revocation

FR8: Auditing

FR9: Compliance Checking

FR10: Feedback & Notification

FR11: Transmission of data and associated Consent

FR12: Propagation of consent changes (on various data instances)

FR13: Propagation of revocation changes (on various data instances)

FR14: Deletion of data and/or metadata

FR15: Exercising the data subject‟s right to know data that is held by the

organisation, along with Consent & Revocation

Table 2 (consisting of two parts) illustrates the outcomes of our analysis, in terms of

which needs and functional requirements have been derived from each selected use

case (we exclude UC 0.1 and UC0.2 as they deal with administrative issues).

Table 2: Functional requirements

Part I FR1 to FR8

FR1 FR2 FR3 FR4 FR5 FR6 FR7 FR8

UC1 X X X X

UC5 X X X X X X

UC14 X X X X X

UC15 X X X X X

UC16 X X X X X

UC17 X X X X X

UC18 X X X X X


16

Part II FR9 to FR15

FR9 FR10 FR11 FR12 FR13 FR14 FR15

UC1 X X

UC5 X X X

UC14 X X X X

UC15 X

UC16 X X X

UC17 X X X

UC18 X X X X

It is important to note that functional requirements FR8 (Auditing) and FR9

(Compliance Checking) are currently not explicitly covered by the use cases. This

reflects decisions and assumptions that are discussed in Section 6.

Specifically, in FR8, we currently assume that logging capabilities are available for

each use case. FR9 requires additional work and exploration of the technical

implications within EnCoRe.


17

5. High Level Principles & Technical Architecture

5.1 High Level Principles

The principles which underpin the high-level architecture are the following:

Individual employees are entitled to express, in detail, their consents and

revocations about the usage, processing and disclosure of their personal

data;

Mechanisms are made available to the organisation to explicitly enforce

consent and revocation;

Privacy-aware access control policies can be used and customized to enforce

consent and revocation, along with traditional security policies and

constraints;

The organisation is able to track where personal data are stored and used;

Degrees of (indirect) control are retained by the organisation and employees

when personal data are disclosed to third parties.

The resulting high-level architecture is an ideal model that makes some strong

assumptions. For example, it assumes some “standard” way to deal with

account/record provisioning and configuration management, e.g., by using Identity

Management solution suites. This might not be the case for particular organisations

that have developed ad hoc IT infrastructures or rely on manual administration of

accounting and IT systems. Applications and services should also be instrumented, to

allow the enforcement of policies (along with expressions of consent and revocation)

and interactions with the other model components. This might be possible for new

applications and services, by applying a “Privacy by Design”[38] approach. For

legacy applications, ad hoc wrappers (of varying degrees of security) might be the

only possible solution, or no changes might be feasible at all.

Another strong assumption is that there is a need to have knowledge of where data are

stored and to have ways to intercept programmatic or manual flows of data. This

again might not be the case, in general, as organisations might not even fully know

where customer data or other personal data are stored. However, in the absence of

this, only limited management of consent and, more importantly, revocation might be

possible. Hence, it is a key requirement to know where data are.

Finally, to work systemically across organisations, a similar model should be adopted

by all the involved parties. In some contexts this might be achievable (e.g., in supply

chains), but others might require expensive changes and adaptations.

5.2 Technical Architecture

Based on the analysis of use cases and related needs and functional requirements, a

high-level EnCoRe architecture has been produced, as shown in Figure 2. This

architecture is also an evolution of prior work and analysis described in [34].


18

The diagram and list below are an abstraction of the architecture, for which the more

refined descriptive diagram and list are given in Section 6.

Personal

Consent &

Revocation

Assistant

Po

rta

ls &

Acce

ss P

oin

ts

(Virtual)

Data

Registry

Enterprise

Data

Repositories

Applications

Services

Business Processes

Disclosure &

Notification

Manager

Data + Consent

Data location

& consent/

revocation

registration

Policy & Preferences

Configuration

Enterprise A

Enterprise B

Revocation

Audit

- Data

and Consent

(& Constraints)

- Revocation

Risk

Assessment

-Data and Consent

(& Constraints)

- Revocation

Notifications

Privacy–aware

Policy Enforcement Policies

Update

Update

Access to

Services

Data +

Consent &

Revocation

Requests

Service

Requests

Agent

User Account

Provisioning &

Data Storage

Consent & Revocation

Provisioning

Data

Storage

Trust

Authority

Compliance

Checking

Policy

Administrator

Data Subject

Admins

Trust

AuthorityTrust

Authority

Data Viewer

& Manager

To Employee

(Data Subject)

Figure 2: High level architecture

In order to move towards the satisfaction of the requirements identified in Section 4,

we envisage that the high-level architecture should include the following components:

Personal Consent & Revocation Assistant: this component assists and provides

a human-computer interface to help employees express their consent (opt-in/opt-

out choices, privacy preferences, etc.) and revocation requests, along with an

explanation of privacy practices provided by the organisation. It can be triggered

(e.g., via a plug-in in a web browser) during data disclosure processes, in order to

provide suggestions and default values for consent, given the nature of the data. It

keeps historical traces of data disclosures, along with revocation requests.

(Virtual) Data Registry: in order to be able to deal properly with consent and

revocation management, an organisation must know all the locations where data

are stored. This is the goal of the (virtual) Data Registry, which is a special

repository (or an aggregation of synchronised repositories) that keeps track, for

each known individual, where their data have been stored (in operational data

repositories) within the organisation, which type of data has been disclosed

outside the organisational boundaries and to whom. This component keeps track

of expressions of consent and revocations for each managed personal data item. It

is a critical component that has to be secured and protected. It also needs to be

continually updated, in order to provide value to the organisation. This can be


19

achieved by a mixture of automation (provisioning services) and manual

intervention by administrators, for example in the context of well-known business

processes and procedures.

Data Viewer & Manager: this component enables employees (and customers) to

make data subject access requests, i.e., to explicitly ask the organisation about the

types of information that have been collected and stored about them – along with

their expressions of consents and revocations. This information can be retrieved

from the (Virtual) Data Registry.

Consent and Revocation Provisioning: this component is in charge of

automatically and systematically updating the Data Registry every time there is a

new expression of consent and revocation (either for new, i.e., previously

unknown, individuals or known ones). It can be seen as a component of

consolidated individual record and system provisioning solutions, specialised to

deal with the provisioning of consent and revocation. In this context, it is in

charge of updating individuals‟ preferences and constraints that affect the

enforcement of access control and obligation policies. An expression of consent or

a subsequent revocation of consent will affect how applications and services will

access data.

Privacy-aware Policy Enforcement: this is a component that deals both with

access control policies on data and data lifecycle management, driven by

individual preferences, consents and revocations of consent. It mediates access to

data by intercepting applications‟ and services‟ requests, and is driven by

enterprise policies and individuals‟ preferences, including the consents given by

individuals (e.g., allowing the usage of personal data for specific purposes, in a

given timeframe). This can be achieved by using enhanced Policy Enforcement

Points (PEP) and Policy Decision Points (PDPs). It can also support privacy-

aware lifecycle management of data, driven by obligation policies and

individuals‟ preferences (e.g., deletion or minimisation of data after a predefined

period of time). Interception points are required for applications and services

when accessing data. For legacy applications this might be a difficult requirement

to satisfy.

Disclosure and Notification Manager: this is a component (with a related

notification infrastructure) to intercept and keep track of flows of personal data,

within and between organisations, and to propagate the associated consent and

revocation preferences. Applications and services might need to be instrumented

with agents that communicate with this component. It interacts with the Data

Registry to update data locations and related consent information. Changes of

consent and revocations are propagated to known data locations (within and

outside the organisation) by means of notifications. Requests for reconfiguration

may be sent to the consent and revocation provisioning system to reflect any

change. These notifications might require (non-repudiable) acknowledgements, by

the involved parties, that are going to be logged and audited. Ideally, third parties

that receive personal data from the organisation, (along with associated consent

and revocation preferences) should adopt a similar model and architectural


20

approach, to ensure a consistent management and enforcement of consent and

revocation. However, the EnCoRe architecture does not mandate this. The

EnCoRe architecture and approach ensures that, at least, information of disclosed

data is tracked in the Data Registry and can be retrieved later on, for example for

audit trails.

Audit: this is an component to log and keep track of what happens to PD, consent

and revocation during operational and administrative activities, inclusive of flows

of personal data within and outside the organisation.

Trust Authority: this is a component to deal with any required certification and

issuance of digital certificates for information security purposes.

Risk Assurance: this is an offline component that is used by the enterprise‟s

privacy administrators to assess current risks, based on known threats, and to

provide indications of compliance. Based on these threats, known information

flows, involved types of data and security aspects (of IT infrastructures, people

and applications/services), this component can identify the level of risks, using

known risk heuristics and rules, and suggest actions, such as investing in the

instrumentation of critical applications or forbidding particular flows of

information, etc.

This model is compatible with the PRIME Toolbox [24], with regards to privacy-

aware policy enforcement (inclusive of privacy-aware access control, data handling

capabilities [24] and obligation management [10, 11]). However, it aims at explicitly

providing consent and revocation functionalities by introducing the concepts of

“consent and revocation provisioning” and “data registry”, along with the “disclosure

and notification manger capability”.

At the time of disclosing personal information, individuals can express their consents

in detail. The Personal Consent and Revocation Assistant is a critical part of helping

people in assessing the situation. This requires further research in Human-Computer

Interaction (HCI), in the directions suggested by [22, 33]. Once data are disclosed, the

location of where data are stored, along with a copy of the consent statement, is stored

in the Data Registry during the provisioning phase.

Access requests to data (by individuals, applications and services) are intercepted by

the privacy-aware policy enforcement component to ensure the enforcement of

security and privacy policies, including individuals‟ fine grained consents and

preferences. This component handles the lifecycle of data, driven by the enforcement

of obligation policies [10]. When personal data are disclosed to other locations within

and outside the organisation, the Disclosure & Notification Manager keeps track of it

and updates the Data Registry. Non-repudiable notifications of success or failure (by

the involved parties) are logged by the auditing system. Similarly, changes of consent

or revocations by individuals are propagated by this component to all the involved

parties and the Data Registry is updated.


21

5.3 Mapping Architectural Components to Functional Requirements

The architectural components have been designed to implement each functional

requirement described in Section 4.

The following list shows, for each functional requirement, the components that are

involved in handling it:

Requirement: Capturing end-user consent with data

o Personal Consent & Revocation Assistant

o Offline Process and C&R Mapper (mapping C&R into the system)

Requirement: Changing (end-user) Consent



Requirement: Capturing end-user Revocation



Requirement: Change end-user Revocation



Requirement: Association of Consent/Revocation to Data

o Consent & Revocation Provisioning

o Data Registry

o Privacy-aware Policy Enforcement

o Trust Authority (see sticky policy approach)

Requirement: Tracking Data and Metadata (Consent & Revocation)


o Data Registry

o Privacy-aware Policy Enforcement

o Disclosure and Notification Manager

o Agent (instrumenting Apps/Services)

o Offline Processes


Requirement: Enforcement of Consent and Revocation

o Privacy-aware Policy Enforcement (access control, obligations, etc.)

Requirement: Auditing

o Audit (logging, ...)

Requirement: Compliance Checking


22

o Risk Assessment

o Compliance Checking

Requirement: Feedback & Notification

o Disclosure & Notification Manager

o Agent (instrumenting Apps/Services)


Requirement: Transmission of Data and Associated Consent


o Standard Enterprise Processes and Systems

o Communications between various EnCoRe and non-EnCoRe

components

Requirement: Propagation of consent changes (on various data instances)

o Agent


o Data Registry


Requirement: Propagation of revocation changes (on various data instances)

o Agent


o Data Registry


Requirement: Deletion of Data and Metadata

o Agent


o Data Registry

o Offline Processes

Requirement: Exercising right to know data that is held by the enterprise,

along with Consent and Revocation

o Data Viewer & Manager

Administrative Requirement: Enterprise Privacy Policy Administration and

Management

o Policies

o Policy Administrator

Two related core aspects have been analysed to animate the architecture and further

make progress towards its refinement to implementable solutions:

Data Model: this is concerned with how personal data are stored and how

consent and revocation preferences can be associated to these. This is an

important aspect, as it has an impact on privacy-aware policies. Section 5.4

provides more details.


23

Privacy-aware policies: privacy policies (coupled with traditional security

policies) are key to determining who can access which personal data,

consistent with data subjects‟ consent and other privacy and security

constraints. They are a core part of the architecture, and require proper

analysis to ensure the satisfaction of various needs and requirements in terms

of consent and revocation management. Section 5.5 provides more details.

5.4 Data Model

The definition of privacy policies that allow personal data to be accessed only if data

subjects‟ consent/revocation preferences are satisfied (along with other security and

privacy constraints) needs to be able to:

Refer to these preferences and understand their meaning;

Refer to the personal data to be protected;

Understand how preferences relate to personal data.

A data model is required to specify this information, so that it can be taken into

account within policies at enforcement time. We took into account current

UK/European data protection legislation and data protection/privacy guidance from

bodies such as the Information Commissioner‟s Office and the Article 29 Working

Party. The data model helps to achieve this by defining where and how the personal

data and the corresponding preferences are stored in the EnCoRe system.

Various considerations have an impact on the data model. Among these, there is the

nature of the data stores. Indeed, as different data stores can have different data

representations and different data access mechanisms, the data model can change

when the nature of the data store changes. If, for instance, data are to be stored in

some LDAP directories, then the data model will need to be hierarchical; however, it

will need to be flat if relational databases are used.

Another aspect that impacts on the data model is the manner in which preferences are

to be linked to personal data. Three approaches are possible (refer to Appendix C.2.3

for details):

Predefining types of “profile”

Assigning preferences to each data item

Assigning preferences to a group of data items

Each approach can require different mechanisms to be defined to allow the

preferences associated with data items to be retrieved.

Finally, the location(s) where the data are stored can also impact on the data model.

Indeed, if personal data and preferences are stored at different locations, then it is

important to guarantee that it is always possible to link any data item to the

corresponding preference (i.e., to locate the preferences associated to a data item).

This may require specific identifiers to be defined.


24

For this first case study, we have chosen to:

Use relational databases

Store personal data in the enterprise databases

Store preferences in the database of the registry component

The definition and full discussion of the data model is available in Appendix C: Data

Model.

5.5 Privacy-Aware Policies

The EnCoRe project analysed various privacy policies using a top-down approach,

starting from high-level (legal and social) policies and proceeding down to technically

enforceable policies.

We took into account current privacy and data protection legislation and guidelines.

We then extracted common policy patterns, requirements and constraints of relevance

in terms of privacy & consent and revocation.

We subsequently analysed how these requirements could be mapped into technically

enforceable policies. It is beyond the scope of this document to provide details of this

process. More details can be found in [35].

The remaining part of this section describes the technical aspects related to privacy

aware policies.

Privacy-aware policies can cover a wide variety of aspects, including access control

[9] and privacy obligations [10]. For the purpose of this first EnCoRe case study and

technical architecture, only privacy-aware access control policies have been

considered, as they are essential to the management and enforcement of consent and

revocation. Future versions of the EnCoRe architecture will explicitly handle

obligation policies [10].

Our drivers have been the following:

Enable the protection of personal data.

Avoid creating yet another policy language and framework.

The remaining part of this section provides more details about the rationale

underpinning the suggested management of privacy-aware access control policies and

related important principles that we have taken into account. This includes a brief

analysis of the technical concepts and requirements underpinning technical privacy-

aware policies.

The Privacy-aware Policy Enforcement component of the EnCoRe architecture

provides two enhanced versions of the:


25

Policy Enforcement Point (PEP): this component intercepts requests to access

all data and, for personal data, requires access decisions to be made by the

Policy Decision Point

Policy Decision Point (PDP): this component makes access control decisions

based on a variety of aspects, including security, privacy and data subjects‟

preference constraints.

To ground this analysis in how policies can actually operate to enable the enforcement

of consent and revocation, two simple technical privacy-aware policies have been

considered and consistently used in this section:

1) “Access to PD must be allowed only to people with approved access

rights/roles” AND

“for purposes agreed with the data subject” AND

“by enforcing any additional privacy preference agreed with the data

subject”

2) “A data subject must be notified of any disclosure of their PD to third parties,

in accordance with the data subject's privacy preferences”

Policy (1) is an access control policy, taking into account:

Security constraints (checking the access requestor‟s credentials, role, etc.)

Privacy constraints: checking for the purpose of accessing data and

satisfaction of data subjects‟ privacy preferences (e.g., limitations on who and

where data can be disclosed, specific preferences on secondary usages, etc.)

Policy (2) is actually an obligation, more specifically an access-control driven

obligation. It can be addressed in the traditional context of access control policies and

hence is within the scope of this first EnCoRe technical architecture. (This first

version does not consider obligations that are not driven by access control [9,10], e.g.,

deletion or minimisation of data after predefined period of time, etc.)

These policies are enforceable within the underlying technical Privacy-aware Policy

Enforcement component discussed in the EnCoRe high-level architecture, and

conceptually illustrated in the figure below:


26

Figure 3: Privacy-aware policy enforcement

One of the desired outcomes of the enforcement of privacy-aware policies is to ensure

that only the appropriate data/information can be accessed by the data requestor, in

accordance with pre-existing constraints and preferences.

For example, see the following figure, illustrating a simple case where PD is stored in

database along with simple expressions of individuals‟ preferences/consents regarding

purposes for using their data.

Here, a privacy-aware access control system is deployed to enable control of access to

data based on (a) traditional security constraints (checks on roles and identity of the

requestors) and (b) privacy constraints (based on individuals‟ preferences/consents)


27

Figure 4: Privacy policy enforcement example

In this example, a basic privacy-aware access control policy (in a pseudo-technical

language) could look like the following:

Target: <Database:DB1, Table:T1>

If DataRequestor.Role==“Statistician” and DataRequestor.Intent == “Marketing”

Then Allow Access (T1.Condition,T1.Diagnosis)

& Enforce (Consent)

Else If DataRequestor.Role==”Scientist” and DataRequestor.Intent == “Research”

Then Allow Access (T1.Diagnosis)

& Enforce (Consent)

Else Deny Access

The effect is that the data requestor can access only the data he/she/it has rights to

access (based on security constraints) and has consent for (based on privacy

constraints), for a specific intent. Any other PD would be filtered out/not accessible.


28

In general, the enforcement of access control policies might have a wider range of

outcomes, from executing associated obligations (e.g., notifications, auditing) to

having a direct impact on the information that is eventually accessed (including data

minimisation, association of data to sticky policies, etc.).

An important reality check is that privacy policies, to be usable in modern IT

environments, need to be flexible to enable the representation, management and

enforcement of a wide variety of constraints including legislative constraints, internal

organisational (security & privacy) constraints, individuals‟ preferences, etc.

This requires additional analysis of the implications, as follows.

In this context we focus on technical access control policies that:

Enable the protection of PD, once deployed in suitable enforcement

frameworks, based on security constraints, privacy constraints and additional

consent/revocation preferences dictated by data subjects

Could be potentially mapped in existing framework, for example XACML

(see Appendix D)

A few important concepts about the expressiveness of the policies emerged from the

analysis of policies and related data models.

Concept 1: Reference to protected resources (Personal Data)

With regards to the protection of PD, access control policies need to be expressive

enough to allow:

Full references to protected (stored) personal data (resources)

Full references to data subjects‟ preferences (e.g., consents, revocations)

Linking these privacy preferences to the relevant stored personal data

In the EnCoRe technical architecture, PD can be stored in a variety of data

repositories (e.g., databases, LDAP directories, etc.). Data subjects‟ preferences can

be stored in the data repositories themselves (when possible) and/or in the Data

Registry.

The following figure illustrates the fact that technical policies must be expressive

enough to denote what the protected resources are and also any additional metadata,

e.g., where preferences are and how they link to the protected resources, to further

qualify how the resources should be protected.


29

Technical Policy

Protected

Resources

Metadata

Constraints

Data Registry

Data Repository

Privacy Preferences

Personal Data (PD)

PD - Preferences Links

Data Model

Figure 5: Policies associated with protected resources and metadata

Technical policies must be aware of the underlying data model to enable their

enforceability.

Concept 2: Coping with different access patterns/scalability

In addition, there are at least two categories of patterns to access PD. These access

patterns, 1-1 and 1-N, are illustrated in the following figure:


30

• (1-1) Type of Data Access

−Entity X Trying to Access “Individual Y”’s Data

• (1-N) Type of Data Access

−Entity X Trying to Access a Set of {Individual Yi} Data

Which Data Access Patterns?

1 Individual’ PII

1 Individual’ PII1 Individual’ PII1 Individual’ PII

Figure 6: Data access patterns

Technical policies need to cope with both patterns:

Individual/role trying to access a single data subject‟s data ( that relating

themself or to someone else)

Individual/role trying to access a set of other data subjects‟ data

In both cases, for each set of data belonging to a data subject, it is important to ensure

that each specific data subject‟s privacy preferences are enforced.

Scalability is important. We do not want to create an ad hoc policy for each new data

subject, repeating identical constraints and conditions but differing only because of

preferences. This would create a proliferation of policies that are hard to maintain.

We rather want to have general-purpose parametric policies that are flexible enough

to cope with the variability of where protected data are located and the different

instantiations of preferences for different data subjects.

Concept 3: Enabling “Conditional Yes” as an outcome of policy evaluation

This concept is strictly related to the previous one.

Given the privacy-aware access control model in the EnCoRe architecture, the Policy

Decision Point (PDP) can only make decisions based on these policies (the PDP has

no direct access to PD and preferences, for security reasons): it is the task of the

Policy Enforcement Point (PEP) to enforce decisions and eventually grant access to

them.


31

To enable scalability of policies and the capability to cope with different access

patterns, these policies must be able to:

Represent general constraints on which data can be accessed based on the

associated expression of preferences and other conditions

Ensure that these constraints can be communicated back to the PEP

component for their actual enforcement, in the case of “Conditional Yes”

(e.g., when a data requestor can access sets of various data subjects‟ data as it

has the right role, but only if that data subjects‟ nominated purposes are also

consistent with the data requestor‟s purpose)

Concept 4: Supporting current security access control constraints

As highlighted in various parts of this document, policies need to be able to support

traditional access control/security constraints, in addition to privacy-aware

constraints.

We do not want to have two categories of policies but rather blend together different

types of constraints.

It is important to notice that traditional access control/security constraints include:

Constraints on a data requestor‟s rights and properties (credentials, roles, etc.)

Constraints on context and environment (location, date/time, used devices,

etc.)

Concept 5: Supporting access control-based obligation policies

As previously highlighted in this document, we want to support access control-based

obligation constraints as part of the overall access control policies.

For example, an obligation constraint could dictate that each time a data subject‟s PD

are disclosed, the data subject should be notified, if he/she gave consent for this in

his/her preferences.

It is important to notice that this obligation is also conditional, i.e., is subject to the

actual evaluation of a data subject‟s preferences at the time of accessing/using data.

Based on the above points and concepts, we have derived a conceptual model for the

necessary technical access control policies. It is still, intentionally, high-level and

subject to further refinement. A potential instantiation of this model, which leverages

and extends the XACML language and framework, is described in Appendix D.

The following picture illustrates the key aspects of this conceptual model:


32

Targeted Resource

Metadata

RULE

Obligations

Condition:

If Constraints

THEN

Outcome

Figure 7: Conceptual model

Specifically this conceptual model consists of:

Targeted Resource: this contains a full identifier/locator of the resource to be

protected. For example, it can specify a specific table contained in a specific

database, or a specific record in that table, or an object in a class hierarchy,

within a LDAP directory

Metadata: this contains information about:

o Where data subjects‟ preferences are stored (full identifier/locator),

e.g., a table or set of tables in a data repository or in the data registry

o How these preferences link back (e.g., keys) to the correspondent PD

Rule: this is a set of conditions, each testing a set of constraints and

determining an Outcome. Constraints can include checking for security

properties, credentials and contextual properties. The Outcome is a decision

that, conceptually, could be any of the following types:

o Yes – allow access

o ConditionalYes – allow access subject to the satisfaction of additional

conditions, to be enforced by the PEP

o No – disallow access

o No + indications – disallow access but provide further indication on

what to do next

Obligations: this is a set of obligations, as described in Section 2, to be

returned to the PEP for enforcement. As previously discussed, these

obligations might be conditional too, e.g., may need to be instantiated to the

specific data subject‟s preferences.


33

It is beyond the scope of this document to describe in more details any process to deal

with conflicting policies and, within a policy, conflicting constraints.


34

6. Refined Technical Architecture

Section 5 illustrated the core concepts, principles and criteria underpinning the

EnCoRe high level architecture as well as the underlying data model and policies.

This architecture can be instantiated in a variety of ways. To be implementable by the

EnCoRe project‟s work on the Enhanced Employee Data Scenario – for the selected

subset of use cases - further analysis and refinement has been necessary.

This section describes a simplified and refined EnCoRe Architecture, consistent with

a set of assumptions agreed within the project.

The list of general assumptions that were made to refine the EnCoRe technical

architecture follows:

1. We want to define a refined architecture that is still general purpose, hence

fully reusable for different situations and scenarios

2. We make simplifications for the purpose of meeting project deadlines and

enabling early implementation efforts, but without compromising the

generality of the architecture and approach to consent and revocation

3. In this first version, for simplicity, we will not use cryptographic approaches

to bind personal data to consents/preferences. This implies there will be weak

ways to provide non-repudiation and enforcement integrity. However, the

resulting framework must be designed to add the cryptographic and sticky

policy capabilities layer as a potential feature of future versions.

4. We make the assumption that all versions of the EnCoRe prototypes and

components (i.e., Personal C&R Assistant, C&R Provisioning, Data Viewer &

Manager, Data Registry, Privacy-aware Policy Enforcement, Policies & Policy

Administrator, Disclosure & Notification Manager, Audit, Trust Authority,

Compliance Checking, Risk Assessment, etc.) are designed and built to satisfy

good security practices (e.g., secure communication & authentication,

protected access to stored information, future data encryption, data

minimisation, etc.). We assume that the systems and platforms running these

components are secure and managed following good security practice. As

such, these components should be, under normal circumstances, perceived as

trustworthy by organisations and users from a security perspective. We

assume that, in later versions, audit and compliance checking capabilities will

include checking for integrity and security.

5. We make the assumption that both EnCoRe components and

applications/services will have to access protected data. In both cases this will

happen in a controlled manner, i.e., subject to Privacy-aware Policy

Enforcement. This will happen in a variety of ways, for example by including


35

PEPs within applications, or using them as interception points next to the

protected resources.

6. We make the assumption that protected data will need to be exchanged

between EnCoRe components and between applications, and that this

exchange of information will happen in a controlled way, subject to policies.

Communication between the involved EnCoRe components will be secure, by

using authenticated components and secure channels. We assume that the

methods of authenticating the components and securing the channels are

outside the scope of the architecture, as a variety of standard means for these

exist and we do not wish to tie the architecture to any specific one or to devote

project resources to such details.

7. We make the assumption that the platforms and systems running the back-end

EnCoRe components are secure and observe good security practices. However

the end-user platform might be insecure or have vulnerabilities. This means

that it could be potentially compromised. However the impact of that would

just be local - affecting one end-user and potentially all stored data (including

metadata) that relate to him/her. We might use encryption techniques (and/or

TPM-based machines [37]) to provide further security in terms of stored data

e.g., local copies of PD, history, etc. It is beyond the purpose of this work to

solve the problem of phishing or identity theft - so the user is assumed to be

responsible for securing their credentials.

8. The final architecture must deal with legacy applications, data repositories and

related integration. However, this is not addressed in this first EnCoRe

technical architecture. In future versions we will identify proper mechanisms

to manage and enforce consent/revocation and related policies. We aim at

ensuring that the first version can be further extended in that direction.

9. A system that is EnCoRe-compliant shall (a) conform to the EnCoRe

architecture, and (b) if it sends personal data to other systems, e.g., those

operated by other entities, shall do so only to other EnCoRe -compliant

systems. (N.B. These conditions require that, for a system to be EnCoRe -

compliant, all other systems which send, receive, store or process any personal

data that are collected by it and sent by it to one or more of them, must also

conform to the EnCoRe architecture.) However, within the scope of the

EnCoRe project, aspects of implemented systems may be mocked-up in order

to display or simulate the required behaviour.

A list of specific assumptions made for this first EnCoRe technical architecture

follows:

1. We will allow, via the user-side component(s), individual data subjects (in this

case employees) to define their own basic expressions of consent such as (1)

opt-in/opt-out of privacy preferences/attributes (e.g., usage of data for specific

purposes, disclosure of data to specific third parties, etc.) and (2) specification


36

of values of privacy preferences/attributes (e.g., periodic notification time,

time-to-revoke)

2. We will allow, via the user-side component(s), individual data subjects (in this

case employees) to modify their own consent (i.e., as an aspect of revocation),

but potentially restricted to selected points in time/points in the process.

3. An expression of consent or revocation by an individual can affect single data

items or groups of data items pertaining to that individual.

4. A revocation request by an individual can potentially include instructions to

delete data immediately and/or on a deferred basis (based on time or an event)

and/or conditionally.

5. No support for privacy obligation management (e.g., deletion of data after

predefined period of time, etc.) is provided, but the architecture will allow for

future support of this capability.

6. Consent and revocation expressions are bound to personal data just by using

non-cryptographic associations (e.g., data item --> list of consent preferences).

7. The user-side component (Personal Consent and Revocation Assistant)

provides a basic historical track of the URLs to which data area disclosed,

along with the latest expressions of consent and revocation.

8. The Personal Consent and Revocation Assistant is a simple set of web pages

served by the enterprise web portal, along with a simple local plug-in for

interactions with the employee's PC/laptop (e.g., to store historical

information). In this first EnCORe technical architecture, relevant data (e.g.,

historical data) are stored in the employee‟s platform. However, these data can

be copied/moved around (as a file exchange, between laptops and PCs). Future

versions will potentially enable the storage of these data in a remote

server/service and remote access to them. This first EnCoRe technical

architecture provides the basic functionalities by means of a plug-in for

Firefox browsers.

9. No offline consent and revocation will be implemented.

10. The enterprise web portal is a simple web server with basic applications that

can be accessed after user authentication.

11. The set of basic applications supported by the enterprise web portal includes:

(1) enterprise application supporting the Personal Consent and Revocation

Assistant functionality; (2) front-end to the User Account Provisioning & Data

Storage component(s); (3) one or more simple applications (such as

WorkBook) to be accessed by the individual data subjects (in this case

employees) to get services.


37

12. All applications accessed by the enterprise web portal are completely under

the system developers‟ control, i.e., they can access and modify the

applications‟ code, e.g., to embed enforcement points. This is also true for

applications‟ agents.

13. All data repositories are simple relational databases (RDBMS, e.g., MySQL),

including the Data Registry and Enterprise Data Repository.

14. The Consent & Revocation Provisioning component is a simple service that

inserts, updates and deletes information in the various affected data

repositories driven by employees' interactions (e.g., specification/change of

consent and revocation).

15. System developers have full control of data repositories (Data Registry and

enterprise data repository), including the ability to modify schemas.

16. Expressions of consent (i.e., preferences) will be stored in these data

repositories, along with the associated personal data.

17. The privacy-aware policy enforcement component will consist of a PEP

embedded in the controlled applications and external PDP components.

18. Policies will be authored in files/databases via a simple editing tool, and made

available to the PDP.

19. Access and privacy-aware policies are implemented by leveraging the

XACML framework and potentially by extending it.

20. A basic implementation of the Disclosure & Notification Manager is provided,

purely to: (1) deal with disclosure of data to a third party, by enforcing

consent/revocation; (2) notify employees, based on their expressions of

consents; (3) notify the Consent & Revocation Provisioning component of any

events happening on the data disclosed to the third party; (4) propagation of

changes of consent/revocation and other relevant events to the third parties

and internal components. As already stated, no cryptographic binding of data

to policies/consent and revocation preferences is provided.

21. Compliance Checking and Risk Management capabilities are not necessarily

provided, but the architecture must support their future deployment.

22. Basic audit is provided to log all events happening in the implemented

architectural components .

23. A basic implementation of the Data Viewer and Manager is provided. This

allows responses to Subject Access Requests to be supported. Each will be a

simple report about the requestor's stored PD and related consent/revocation,

and is achieved by reporting on information stored in the Data Registry.


38

The following figure provides a view of the refined EnCoRe architectural components

and their breakdown into sub-components, derived from the high-level EnCoRe

architecture and by taking into account the various assumptions listed above:

Web Browser

+

C&R Privacy

Assistant

Plug-in

Po

rta

ls &

Acce

ss P

oin

ts

(Virtual)

Data

Registry

Enterprise

Data

Repositories

Applications

Services

Business Processes

Disclosure & Notification

Manager

Data + Consent

Data Ref +

C/R preferences

- C&R Preference

Configuration

- PII Data Storage

Enterprise A

Enterprise B

Revocation

Audit

LogsNotifications

Privacy–aware

Policy Enforcement

Policies

Access to

Services

Data +

Consent &

Revocation

Requests

Service

Requests

Agent

Consent & Revocation

Provisioning

Data Subject

Admins

Data Viewer

& Manager

To Employee

(Data Subject)

C&R

Provisioning

Daemon

C&R

Verification

Workflow

Manager

C&R

Registration

Process

Data

Registry

Daemon

Data

Registry

Mapping

Process

Data Registry Manager

PEP

PEP

PEP

PEP

Policy

Decision

Point

Context

Handler

PEP

Notification

Orchestrator

Notification

Issuer

Data

Disclosure

Manager

User

Interaction

Manager

PEP

Disclosure & Notification

Manager

Figure 8: Refined architecture

The current refined architecture includes the following components and sub-

components:

Web Browser + C&R Privacy Assistant Plug-in

Data Viewer & Manager

o PEP component

Consent & Revocation Provisioning

o C&R Provisioning Daemon

o C&R Verification

o Workflow Manager (+ local PEP)

o C&R Registration Process

Privacy-aware Policy Enforcement

o PEP (central)

o Context Handler

o Policy Decision Point (PDP)



39

o Data Registry Daemon

o Data Registry Mapping Process (+ local PEP)

Data Registry

Application Instrumentation

o Agent

o local PEP

Disclosure & Notification Manager

o Notification Orchestrator (+ local PEP)

o User Interaction Manager

o Notification Issuer

o Data Disclosure Manager

Audit Logs

The above figure shows how the various components and sub-components fit

together. The high-level interaction flows are consistent with the ones briefly

described in Section 5. The detailed interaction flows, as well as the details on the

specific sub-components characterising this architecture, can be found at Appendix B.

It is important to note few important aspects:

The Data Viewer and Manager just simply interacts with the Data Registry

and returns a report about PD distribution, for a given data subject.

Various EnCoRe components/sub-components and applications have a local

Policy Enforcement Point (PEP) - consistent with the agreed list of

assumptions. These PEPs interact with the Privacy-aware Policy Enforcement

components, either directly to the corresponding PDP or proxied via a central

PEP manager

The Audit Logs service just stores audit log information, based on messages

sent in input.


40

7. Conclusion

This document describes the EnCoRe project‟s D2.1 Technical Architecture, derived

from the project‟s first selected case study which focuses on an enterprise scenario

that is centred around the treatment of employee data. It provides the EnCoRe

project‟s first technical reference model and architecture for the explicit management

of consent and revocation within and across organisations. It is aimed at exploring and

defining the core architectural functionalities needed for explicit management of

consent and revocation and at providing an initial reference for implementation.

Nevertheless, we believe that the current architecture is generic enough to

accommodate potential extensions required by future scenarios within EnCoRe, and

that it provides the core functional components that can be used in those contexts.

The concepts of consent and revocation have been analysed. The subsequent

exploration of the Enhanced Employee Data Scenario, by means of various use cases,

has taken into account social, legal and user requirements.

This helped to identify a set of functional requirements that have used to drive the

specification and design of this EnCoRe D2.1 Technical Architecture.

This architecture has first been presented from a high-level perspective, to highlight

all the potentially required components. Subsequently, a refined architecture has been

discussed in detail (including a description of components, sub-components and

interaction flows), based upon specific listed assumptions. Full technical details are

provided in the Appendices.

We anticipate that this architecture will be further refined and extended within the

EnCoRe project, based on further input and additional requirements gathered from

analysis of new scenarios in subsequent case studies.


41

References 1. Harris, Poll: Business Week, http://www.businessweek.com/

2000/00_12/b3673010.htm, 2000

2. Friedman, B., Howe, D.,Felten, E.: Informed Consent in the Mozilla Browser:

Implementing Value Sensitive Design, Proc. of HICSS '02, 2002

3. Anonymous, Test Your Personal Privacy IQ, Privacy Journal, Dec, 2008

4. Federal Trade Commission, Privacy Online: Fair Information Practices in the

Electronic Marketplace: A Federal Trade Commission Report to Congress.

Washington DC: FTC, 2000

5. Organisation for Economic Co-operation and Development (OECD), Guidelines

governing the protection of privacy and transborder flows of personal data, Paris

(1980) and Guidelines for consumer protection for e-commerce

www.ftc.gov/opa/1999/9912/oecdguide.htm, 1999

6. Tweney, E., Crane, S.: Trustguide2, An exploration of privacy preferences in an

online world, Expanding the Knowledge Economy: Issues, Applications, Case

Studies, P. Cunningham and M. Cunningham (eds), IOS Press 2007

7. EnCoRe project, Ensuring Consent and Revocation, Project web site,

http://www.encore-project.info, 2008

8. Schunter, M., Waidner, M.: Platform for enterprise privacy practices: Privacy-

enabled management of customer data, in Privacy Enhancing Technologies,

Second International Workshop, PET 2002, San Francisco, CA, USA, April 14-

15, 2002, Revised Papers, vol. 2482 of Lecture Notes in Computer Science, 2003

9. Casassa Mont, M., Thyne, R.: Privacy Policy Enforcement in Enterprises with

Identity Management Solutions - 4th International Conference on Privacy,

Security and Trust 2006, PST 2006, 2006

10. Casassa Mont, M.: Dealing with Privacy Obligations, Important Aspects and

Technical Approaches - 1st International Conference on Trust, Privacy and

Security in Digital Business 2004, TrustBus 2004, 2004

11. Casassa Mont, M. Thyne, R.: A Systemic Approach to Automate Privacy Policy

Enforcement in Enterprises - 6th Workshop on Privacy EnhancingTechnologies

2006, PET 2006, 28-30 June, Cambridge, United Kingdom, 2006

12. Elahi, T., Pearson, S.: Privacy Assurance: Bridging the Gap Between Preference

and Practice, C. Lambrinoudakis, G. Pernul, A.M. Tjoa (eds.), Proc. TrustBus

2007, LNCS 4657, Springer-Verlag Berlin Heidelberg, 2007, pp. 65-74

13. PrimeLife project, Privacy and Identity Management in Europe for Life,

http://www.primelife.eu, 2009

14. Casassa Mont, M., Pearson S., Bramhall, P.: Towards Accountable Management

of Identity and Privacy: Sticky Policies and Enforceable Tracing Services, Proc.

DEXA 2003, IEEE Computer Society, pp. 377-382, 2003

15. Pearson, S.: Trusted Computing: Strengths, Weaknesses and Further

Opportunities for Enhancing Privacy, Trust Management, Proc. iTrust 2005,

LNCS 3477, ed: Peter Herrmann, Valérie Issarny, Simon Shiu, 2005

16. IBM, The Enterprise Privacy Authorization Language (EPAL), EPAL

specification, v1.2, http://www.zurich.ibm.com/security/enterprise-privacy/epal/,

2004

http://www.ftc.gov/os/2000/05/index.htm#22

http://www.ftc.gov/os/2000/05/index.htm#22

http://www.ftc.gov/opa/1999/9912/oecdguide.htm

http://www.encore-project.info/

http://www-ifs.uni-regensburg.de/trustbus04/

http://www.primelife.eu/


42

17. OASIS, eXtensible Access Control Markup Language (XACML),

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

18. W3C, The Platform for Privacy Preferences, v1.0, http://www.w3.org/TR/P3P/,

2002

19. Cranor, L.: Web Privacy with P3P, O'Reilly & Associates, September 2002.

ISBN 0-59600-371-4.

20. Damianou, N., Dulay, N., Lupu, E., Sloman, M.: The Ponder Policy Specification

Language, http://wwwdse.doc.ic.ac.uk/research/policies/index.shtml, 2001,

21. Solove, D.J.: A Taxonomy of Privacy, University of Pennyslavania Law Review,

vol 154, no 3, January 2006, p. 477.

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=667622

22. Patrick, S., Kenny, S.: From Privacy Legislation to Interface Design:

Implementing Information Privacy in Human-Computer Interactions, R.

Dingledine (ed.), PET 2003, LNCS 2760, pp. 107-124, Springer-Verlag Berlin

Heidelberg, 2003

23. Ardagna, C., Vimercati, S., Samarati, P.: Enhancing user privacy through data

handling policies, Data and Applications Security, volume 4127, LNCS, pp. 224–

236, 2006

24. PRIME, Privacy and Identity Management for Europe, http://www.prime-

project.eu, 2008

25. Schunter, M., Waidner, M.: Simplified privacy controls for aggregated services -

suspend and resume of personal data, Privacy Enhancing Technologies, 7th

International Symposium, pp. 218–232. Springer, 2007

26. Pöhls, H. C.: Verifiable and Revocable Expression of Consent to Processing of

Aggregated Personal Data, ICICS 2008, 2008

27. Pöhls, H. C.: Authenticity and Revocation of Web Content using Signed

Microformats and PKI Technical Report, number 276-07, University of

Hamburg, Germany, February 2007

28. Merkle, R.C.: Secrecy, Authentication, and Public Key Systems, PhD thesis,

Stanford, 1979

29. Housley, R., Polk, W., Ford, W., Solo, D.: Internet X.509 Public Key

Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC

3280, 2002

30. Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.: X.509 Internet

Public Key Infrastructure Online Certificate Status Protocol - OCSP. RFC 2560 ,

1999

31. Camenisch. J., Shelat, A., Sommer, D., Fischer-Hübner, S., Hansen, M.,

Krasemann, H., Lacoste, G., Leenes, R., Tseng, J.C.: Privacy and identity

management for everyone, in Digital Identity Management, pp. 20–27, ACM,

2005

32. Andersson, C., Camenisch, J., Crane, S., Fischer-Hübner, S., Leenes, R.,

Pearson, S., Pettersson, J.S., Sommer, D.: Trust in PRIME, in Signal Processing

and Information Technology, 2005. Proceedings of the Fifth IEEE International

Symposium on, pp. 552–559, 2005

33. Pettersson, J. S., Fischer-Hübner, S., Danielsson, N., Nilsson, J., Bergmann, M.,

Clauss, S., Kriegelstein, T., Krasemann, H.: “Making PRIME usable,” in SOUPS,

ACM, 2005

http://www.w3.org/TR/P3P/

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=667622

http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/posegga/publications/2008-Poehls_verifiably_consented_data_aggreagtion.pdf

http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/posegga/publications/2008-Poehls_verifiably_consented_data_aggreagtion.pdf

http://events.cs.bham.ac.uk/icics08/

http://typo3.fim.uni-passau.de/fileadmin/files/lehrstuhl/posegga/publications/2007-Poehls_B-276-07.pdf

http://typo3.fim.uni-passau.de/fileadmin/files/lehrstuhl/posegga/publications/2007-Poehls_B-276-07.pdf

http://www.informatik.uni-hamburg.de/bib/medoc/B-276-07.pdf

http://www.informatik.uni-hamburg.de/bib/medoc/B-276-07.pdf


43

34. Marco Casassa Mont, Siani Pearson, Gina Kounga, Yun Shen and Pete Bramhall.:

On the Management of Consent and Revocation in Enterprises: Setting the

Context, HP Labs External Technical Report, HPL-2009-49, February 2009

35. Marco Casassa Mont, Siani Pearson, Sadie Creese, Michael Goldsmith, Nick

Papanikolaou.: Towards an Integrated Approach to the Management,

Specification and Enforcement of Privacy Policies, position paper at W3C

Workshop on Access Control Application Scenarios, 17-18 November 2009,

Luxembourg

36. Edgar A. Whitley.: Informational privacy, consent and the 'control' of personal

data, Information security technical report, 14(3), pp. 154—159. 2009, ISSN

1363-4127.

37. Siani Pearson (Editor).: Trusted Computing Platforms: TCPA Technology in

Context, Prentice Hall PTR, 2002, ISBN:0130092207

38. Information Commissioner’s Office: Privacy by design, report, 26 November

2008, http://www.ico.gov.uk

39. Information Commissioner’s Office: The Employment Practices Code -

Supplementary Guidance, June 2005, http://www.ico.gov.uk

http://www.w3.org/2009/policy-ws/agenda.html

http://www.w3.org/2009/policy-ws/agenda.html

http://www.ico.gov.uk/

http://www.ico.gov.uk/


44

Appendix A: Use Cases for the Enhanced Employee Data Scenario

Appendix A describes, in more detail, a few use cases in the context of the Enhanced

Employee Data Scenario. The objective is to capture the relevant requirements about

the management of Consent and Revocation, specifically:

user requirements

legal requirements

technical requirements

We achieve this by going through various uses cases related to an employee, at

different stages of her career, along with the lifecycle of her personal data within the

organisation.

The current architecture also converts an employee‟s preferences (about attributes in

the employee‟s WorkBook profile) into access control settings and additional

annotated constraints (e.g., consent, obligations, etc.) for their WorkBook data. When

data are provided to an external organisation these settings filter what is released.

When an offer is received, the same settings can be used to control whether the offer

is displayed to the employee.

A.1 General Legal Input

This section provides general legal input about these use cases. Before turning to the

specifics below, here are a few basic concepts/definitions of data protection law that

are referred to frequently throughout our comments in Appendix A. The legal input

consists of high-level guidance based principally on relevant sections of the Data

Protection Act 1998. Its role is solely to assist interpretation of the hypothetical case

studies by members of the EnCoRe Project. It does not constitute formal legal advice.

Under the Data Protection Act 1998 (the Act):

Personal data (PD) are defined as:

„data which relate to a living individual who can be identified: (a) from those

data; or (b) from those data and other information which is in the possession

of, or is likely to come into the possession of, the data controller; and includes

any expression of opinion about the individual and any indication of the

intentions of the data controller or any other person in respect of the

individual‟.

The Act refers to data/other info which is/is likely to come into the possession of the

data controller. As such, identifiability is not based on data/other info held by others

if the data controller is not likely to come into contact with it. This is different to the

treatment in the Directive (Recital 26) where identifiability is based on information

held by the data controller or any other person. Whilst the Act represents the law in


45

the UK, the additional breadth of PD as per the Directive should, however, be borne

in mind.

Sensitive Personal Data (SPD) are defined as:

PD „consisting of information as to: (a) the racial or ethnic origin of the data

subject; (b) his political opinions; (c) his religious beliefs or other beliefs of a

similar nature; (d) whether he is a member of a trade union; (e) his physical or

mental health or condition; (f) his sexual life; (g) the commission or alleged

commission by him of any offence; or (h) any proceedings for any offence

committed or alleged to have been committed by him, the disposal of such

proceedings or the sentence of any court in such proceedings.‟

The Data Protection Principles (DPPs) are:

1st DPP: PD shall be processed fairly and lawfully and, in particular, shall not

be processed unless certain conditions are also met.

2nd DPP: PD shall be obtained only for one or more specified and lawful

purposes, and shall not be further processed in any manner incompatible with

that purpose or those purposes.

3rd DPP: PD shall be adequate, relevant and not excessive in relation to the

purpose or purposes for which they are processed.

4th DPP: PD shall be accurate and, where necessary, kept up to date.

5th DPP: PD processed for any purpose or purposes shall not be kept for

longer than is necessary for that purpose or those purposes.

6th DPP: PD shall be processed in accordance with the rights of data subjects

under this Act.

7th DPP: Appropriate technical and organisational measures shall be taken

against unauthorised or unlawful processing of PD and against accidental loss

or destruction of, or damage to, personal data.

8th DPP: PD shall not be transferred to a country or territory outside the

European Economic Area unless that country or territory ensures an adequate

level of protection for the rights and freedoms of data subjects in relation to

the processing of personal data.

A.2 Use Cases

UC1 - Mary is hired at Company X

Mary is hired at Company X. She has to go through the hiring process, provide

personal data: address, bank account details, etc.

Before she starts work she reports to Human Resources (HR) where she fills out

various forms for them. This includes providing health information, next of kin,

references, etc. She is also given a copy of her conditions of employment and terms of

use for the computer systems. She signs a form agreeing to these terms and conditions

which are stored by HR. Some of the information she provided during her interview

process (CV, presentations, application and interview forms, etc.) might be part of the

information that both HR and Mary's boss retain.


46

Mary is asked to register for a few mandatory enterprise services, such as the

employee portal, pension scheme, corporate travel reservation service, etc.

She is offered the opportunity to express degrees of consent relating to some of the

personal data affected by these activities. This might include notifications about

access/internal usage/disclosure to third parties of these data. Otherwise, default

settings might apply.

Legal Input

Personal Data (PD) The nature of the PD supplied by Mary (the data subject) needs

to be ascertained. It is likely that some of the PD will be SPD – a subset of PD – as

defined by the Act. Mary‟s PD is being supplied to Company X. X is clearly the data

controller in this situation.

At this stage, given the generality of the case, it is not possible to know precisely what

data (of which it is assumed some will be PD) must be obtained by Company X.

These will not be matters prescribed by the Act, but rather by other specific, non-data

protection, legislation (e.g. taxation, health and safety, child benefits) that requires

certain data (including PD) to be collected. Under the Act, only the PD actually

required (3rd DPP) need be collected for the particular processing (as per 2nd DPP)

details of which should be made available to Mary.

Consent and Fair Processing The Act confers no absolute obligation on Company X

to obtain Mary‟s consent to process any PD because of exemptions detailed below.

Consent to processing is one of several conditions required for „fair‟ processing of PD

under the Act (listed below). At least one of these conditions needs to be met to

legitimise the processing. There is a further set of conditions (a much longer list)

again of which at least one needs to be met, to legitimise the processing of SPD.

Consent (in this instance „explicit consent‟) is one of these additional conditions.

The fair processing conditions under the Act are as follows:

1. Processed with the consent of the data subject

2. Required by contract, or pre-contractual negotiations, with data subject

3. Legal obligation for data controller to process the personal data

4. Necessary to protect the „vital interests‟ of the data subject

5. Necessary for the administration of justice, parliament, under an Act,

crown/government, public interest

6. Necessary for the „legitimate interests‟ of the data controller/third party

unless the „processing is unwarranted … by reason of prejudice to the rights

and freedoms or legitimate interests of the data subject‟, unless ordered

otherwise by Secretary of State

The Act does not define consent or explicit consent. The Data Protection Directive

95/46/EC (the Directive) defines consent as „any freely given specific and informed

indication of his wishes by which the data subject signifies his agreement to personal

data relating to him being processed‟, which must be given „unambiguously‟. This


47

does not mean that a consent needs to be in writing (though this is preferable if

possible): consent can be implied by way of other actions e.g., clicking through on

websites, etc.

It is important that the process by which a consent is given is as clear and user-

friendly as possible. Any consent should be unambiguous (see below) and thus the

data subject should be as informed as possible throughout the process.

It is common for processing of PD to be legitimised on the basis that it is necessary

for the performance of a contract (e.g., the terms and conditions of employment here)

– as per Sch 2, 2(a) of the Act. For SPD, processing can be legitimised on the basis of

a legal obligation conferred on X in connection with Mary‟s employment – Sch 3,

2(1) of the Act.

Fair Collection Information Aside from meeting the fair processing conditions for

PD / SPD, the Act contains additional obligations on data controllers to avoid

misleading the data subject about processing, and further to make a data subject aware

of „Fair Collection Information‟ to data subjects. Broadly, this information is: (i) the

identity of the data controller; (ii) the purpose(s) of the processing of the PD; (iii)

anything else required to make such processing objectively „fair‟. This information

need not form part of the terms and conditions of employment (i.e., the consent

element), just so long as the information is brought to Mary‟s attention during the

procedures involved in beginning her employment at Company X e.g., by way of

references in an employee handbook.

Despite there being no absolute requirement to do so, it is best practice for employers

to obtain the consent of the employee for processing of PD in the context of the

employer/employee relationship. At the very least, the employer should seek to be

transparent as to the nature of the processing it carries out using employee PD. As

such, the terms and conditions of employment need to make specific reference to any

SPD that needs to be collected by the employer: this will form the basis of the explicit

consent for the processing of such SPD. There should also be a description of: (i) who

will be processing SPD within Company X; (ii) who will be processing SPD outside

Company X; (iii) the reasons for the processing of SPD.

DPPs More generally, Company X will have to comply with the eight DPPs under the

Act. Of particular relevance here is the 3rd DPP i.e., only PD that is relevant to X‟s

legitimate requirements should be processed, and the amount of PD should not be

excessive.

Access Under the Act (section 7) a data subject has the right to apply for, and be

given a description „in a form that is capable of being understood‟ of: (i) the PD of

which they are the data subject; (ii) the purposes for which this PD is being processed;

(iii) the recipient/classes of recipients to whom the PD may be disclosed. This is

known as the subject access right (SAR).

There are exemptions to the SAR in an employment context, these concern PD: (i)

that is held for management forecasting/planning purposes – if access would prejudice


48

such purposes; (ii) concerning an employer‟s intentions in relation to negotiations

with a data subject - if access would prejudice such negotiations; (iii) in the form of a

confidential reference; (iv) that is held for the prevention of crime/prosecution of

offenders/tax collection purposes; (v) that if disclosed may affect the employer‟s

share price.

Furthermore, there are considerations to be taken into account if the PD that is subject

to a SAR contains PD about other individuals (i.e., other than the data subject making

the SAR). The following diagram from the ICO provides guidance here:

Figure 9: SAR process for PD received from 3rd party (Copied from [39], p40)

Technical and Architectural Aspects

Focus on personal data (including sensitive data). Distinction between mandatory and

optional data to be provided and policies/approaches about how data is going to be

treated.


49

Need to describe how consent can be captured (from Mary) at the time she

discloses her data.

Need to associate consent to data in the enterprise back-end, by taking into

account various locations/departments where data could actually be

stored/used

Need to consider (enforce) consent at the time of accessing/using data

Need to translate paper-based or offline consent into online/digital consent

Initial focus on default mechanisms to handle C&R, then extend by introducing

preferences and individual-driven customization.

UC2 - Mary voluntarily joins a few company initiatives

Mary decides voluntarily to join a few initiatives offered by the Company, including a

hardware & software purchase scheme (offered by an external company), Sport and

Social Club (SSC) and Holiday Cottage Service some are provided by third party

companies.

Some of Mary's personal data have to be disclosed to these third party companies,

including address, employee references and financial details. Mary is made aware that

these data need to be disclosed and she gives consent for this. She also sets some of

her privacy preferences, in terms of notification, feedback, etc.

Legal Input

Processing of Privacy Preferences For PD to fall under the ambit of the Act, it must

be either „processed by means of equipment operating automatically in response to

instructions given for that purpose‟ or „recorded as part of a relevant filing system or

with the intention that it should form part of a relevant filing system‟. It is likely that

all PD stored on computer systems will be covered by the Act. A relevant filing

system must comprise some degree of ordering, so it would not cover a box of papers

sitting in an office, nor a loose-leaf file of information if there were no dividers etc.

Given the wide scope of „processing‟ under the Act, keeping track of data flows etc.

would fall within the Act.

It is important to consider whether privacy preferences for PD i.e., a set of

instructions for the permitted uses of PD, will amount to PD in its own right. If they

do not, then the „processing‟ of such privacy preferences will not fall within the scope

of the Act. In all likelihood, given that the data controller will have access to other

PD, the privacy preferences will become PD when pieced together with the PD (see

above for definition of PD under the Act). NB: This view is not entirely consistent

with the English courts’ interpretation of PD (where a more biographical approach

has been adopted) however ICO Guidance, legislation in other European countries,

and the influential Article 29 Working Party all view PD in much broader terms. In

fact, there has been criticism of the English courts’ approach, and a re-positioning is

widely thought to be needed.


50

Best practice would be to treat privacy preferences as being PD, and thus apply the

relevant provisions of the Act to any processing. One important consideration here is

that all of the PD processed by Company X (including, it is assumed, any privacy

preferences) must be accurate and, where necessary, kept up to date (4th DPP).

Data Controllers / Processors The most important consideration here is the identity

of the data controller(s).

It is likely that both the third party companies and Company X would be data

controllers of Mary‟s PD here. The third parties are unlikely to be data processors, as

they will be using Mary‟s PD for their own purposes, and not entirely on the

instruction of Company X. Data processors are not afforded any autonomy when it

comes to the processing of PD.

SSC Company X could be seen as using PD (e.g., by compiling a mailing list) to

provide certain information to its employees. If such a practice was made clear to

employee/data subject when they joined, there is unlikely to be any issue, as consent

to this type of processing would have been given by way of signing up to the

employment contract. Furthermore, the emails will not be considered as „direct

marketing‟ under the Act (data subjects have a right to prevent such materials being

sent to them).

Whilst this may technically fall under the Act, it is questionable as to whether this is

the type of activity the Act seeks to regulate – it is essentially just an internal

messaging system. Nevertheless, it would be best practice to give the employees the

right to opt out of receiving such messages.

As to Consent and Fair Collection Information, see above, and for Revocation, see

below.



discloses her data.



stored/used


Need to track the flow of PD across boundaries (e.g., to these third parties).

In case C&R was managed by Company X, what are now the implications for

these third parties?

Need to ensure C&R enforcement by third parties


51

UC3 - Company X changes the provisioning of some services provided to Mary

Company X outsources the provisioning of a few mandatory enterprise services

(including travel agency services, pension fund management) and voluntary services

(SSC). Part of Mary's data (financial details, address, employee references, etc.) need

to be disclosed to these third parties.

With regards to these services, she is offered the opportunity to express degrees of

consent about some of the personal data affected by these activities. This might

include notifications about access/internal usage/disclosure to third parties of these

data. Otherwise default settings might apply.

Mary decides to withdraw from the voluntary SSC service. She revokes her consent to

use her personal data and expresses the preference that her personal data should be

deleted.

Legal Input

Revocation is not a concept that is considered by the Act or Directive. There is no

mention of revocation in any preamble, and there are no specific clauses that set out

what a revocation is, nor how one would go about making a revocation. As such, there

is no general express right under the Act or Directive to revoke a consent given by a

data subject to processing PD. Consequently, there is no legal right for a data subject

to make a complete revocation/withdrawal of a consent given to enable processing of

PD.

What the Act does do is give a data subject certain rights to object to processing of

PD in particular circumstances. These rights of objection provide a data subject with a

limited method of modifying existing consents. They do not go as far as giving a data

subject complete control over such consents, and thus a „revocation‟ under the Act is

probably best considered as an amendment of an existing consent, rather than a

complete withdrawal.



discloses her data.

Need to describe how consent changes and/or revocation can be captured



stored/used

Need to enforce revocation


Need to track the flow of PD across boundaries (e.g. to these third parties).


52




UC4 - Mary changes her affiliation to a few of Company X services

Over time, Mary reassesses her affiliation to a few voluntary services she joined in the

past.

She decides to leave a few of them, including the stock purchase program and pension

fund service (because she wants to use a pension fund of her choice). She revokes her

consent to use her personal data and she requires her data to be deleted, where

possible,

She decides to (partially) revoke her consent for notification to the Holiday Cottage

Service, whilst still using this service.

Legal Input

Any action regarding leaving the stock purchase and pension fund schemes is likely to

be determined by the contracts it is assumed will be in place to govern the relationship

between Mary and the providers of those schemes. As such, the contract will almost

certainly override any relevant provisions of the Act.

Despite the termination of these contract(s), the data controller/data subject

relationship will persist. Accordingly, if, after leaving the scheme(s), Mary is

concerned about the PD held by her by the scheme providers, we must look to the Act

for potential remedies. The most relevant DPP here is the 5th (data to be stored only

for certain purposes, and only for so long as those purposes require). As discussed

above, there is no general express right of revocation in the Act for Mary to rely on.

Unless significant harm or damage is likely to be caused to Mary by the continued

use/retention of her PD by the scheme providers, and she is willing to go to court to

prove it, Mary is reliant upon those providers meeting their obligations as data

controllers under the Act (e.g. the 5th DPP). There is nothing to stop Mary requesting

that the PD are deleted in accordance with the Act; there is just no statutory basis to

make this an enforceable right against the data controller(s).








53

UC5 - Mary changes some of her personal data (profile)

Mary is getting married. She has to update her personal profiles and data within

Company X and some of the third party services (including change address, financial

details, indication of next of kin, etc.).

This requires updating previously given consent and revoke consent on other data

(such as data related to her pre-marriage status). With regards to newly added data,

she is offered the opportunity to express degrees of consent. This might include

notifications about access/internal usage/disclosure to third parties of these data.

Otherwise default settings might apply.

Mary might decide to give consent to next of kin to access some of the services she is

entitled to.

Legal Input

Company X has a duty to ensure that all PD are accurate and kept up to date (4th

DPP). Practically, this requires suitable policies to ensure that data subjects, such as

Mary, are reminded of the importance of keeping PD accurate and up to date e.g. by

notifying HR as to changes to PD that are related to the purposes for which Company

X processes Mary's PD. For example, unless there were legitimate reasons related to

her employment with Company X (e.g. change in tax status), Mary would not have to

inform HR about change in marital status.

As for the granting of 'consent' by Mary to allow next of kin (NOK) access to certain

services; in essence this creates a new data controller/data subject relationship. The

NOK is the new data subject, and Company X (and/or the scheme provider) the data

controller, assuming of course that Company X needs PD relating to the NOK in

order to enrol them on the services. The 'consent' from Mary in this instance is for her

NOK to become member(s) of the particular benefit scheme (e.g. SSC). In order to

become a member, it is assumed that PD of the NOK will be needed to authenticate

entitlement to the scheme in question.

Each NOK enrolled on a particular scheme will be subject to the terms and conditions

applicable to that scheme. It may be that the NOK can take no action directly

regarding the use of their PD by the scheme provider e.g. they are merely

associate/secondary members with limited entitlements, and everything must be done

via Mary. It may be that they are given 'full' membership. In either case, the

contractual nature of the NOK's (and Mary's) relationship with the scheme provider

will most likely take precedence over any terms of the Act as it relates to the PD when

it comes to consent and revocation issues. The Act would, of course, continue to

apply to whoever was the data controller in each case, and compliance with the DPPs

would be required.


54



discloses her data.




stored/used


Need to consider automation of revocation. Default revocation?






UC6 - Mary changes roles and gets promoted

Mary‟s internal role changes. She is promoted. She has a team reporting to her. She

has new duties and responsibilities. Becoming a manager implies further access to

internal services (e.g., Project Management tools, Performance Evaluation services,

etc.) that are going to be aware of (some of) her personal data. She can also access

some of the personal data of her team.

She is offered the opportunity to express degrees of consent about some of the


access/internal usage/disclosure to third parties of this data. Otherwise default settings

might apply.

Her access to personal data of her team's members is constrained by the consent

defined by these members.

Legal Input

There do not appear to be any significant issues here. The data controller and data

subject remain the same, as does the PD. Processing of PD for any new activities

(e.g., being put on a list of those able to use certain facilities) will be a legitimate

interest of X, and most probably covered by any new contract/variation agreement

signed by Mary.



discloses her data.



55



stored/used








Need to allow Mary's attributes (potentially stored in various parts of the

organisation) to be updated.

Need to discriminate between data that are potentially private (and hence

might be subject to expressions of consent) and other types of data.

UC7 - Mary is temporarily seconded in a new department, in a different country

Mary is asked to temporarily move in a new department, in a different country. Some

of her data need to be updated (temporary address) and new information added (local

bank account, health care service, etc.)

She also uses new local services that are provided in the new country by local service

providers.

Some of her personal data might need to flow across national borders. This has

implications from a legal perspective.

She is offered the opportunity to express degrees of consent about some of the


access/internal usage/disclosure to third parties of these data. Otherwise default

settings might apply.

She might temporarily, while she is abroad, revoke access to her personal data to

services she joined in UK.

Legal Input

To comply with the 8th DPP, Company X must not transfer PD to a country or

territory outside the EEA unless there is an adequate level of protection for the PD

and for the rights of individuals. (NB: The EEA countries are: Austria, Estonia,

Iceland, Luxembourg, Romania, Belgium, Finland, Ireland, Malta, Slovakia,

Bulgaria, France, Italy, Netherlands, Slovenia, Czech Republic, Germany, Latvia,

Norway, Spain, Cyprus, Greece, Liechtenstein, Poland, Sweden, Denmark, Hungary,

Lithuania and Portugal. The EC has determined that Argentina, Canada, Guernsey,

Isle of Man ,Switzerland and Jersey all have adequate levels of protection.) There are


56

special provisions for the USA: if a US company signs up to a 'Safe Harbor

arrangement' it agrees to follow seven principles of information handling and that it

can be held responsible for keeping to those principles by the Federal Trade

Commission or other oversight schemes.

Even if a transfer is proposed to a non-EC approved state, Company X can still

proceed if, following its own risk assessment, it is satisfied that the particular

circumstances of the transfer ensure an adequate level of protection. In these

circumstances, the Act requires the following factors to be taken into account:

the nature of the information being transferred;

how the information will be used and for how long; and

the laws and practices of the country to which it is transferring the PD.

Other options, typically only applicable to multinational organisations transferring PD

outside the EEA within their group of companies) is to adopt binding codes of

corporate conduct known as binding corporate rules (BCR). These may include intra-

group agreements, policies or procedures, and special arrangements among the group

of companies that provide the necessary protection. To use BCR to transfer personal

information freely within the group, they must be approved by all the relevant EU

data protection authorities who will co-operate with one another when making

authorisations and to make sure that the rules are complied with.

The nature of a transfer needs to be considered, particularly the distinction between

that and transit. The Act does not define „transfer‟ but the ordinary meaning of the

word is transmission from one place, person, etc to another. The fact that the

electronic transfer of PD may be routed through a third country on its way from the

UK to another EEA/compliant country does not bring such transfer within the scope

of the 8th DPP. The Act requires that the transfer of information which is not initially

PD, but is intended to be processed automatically or as part of a „relevant filing

system‟ only after it has been transferred should be afforded the protection of the Act.

An example of this would be where information is provided by someone in the UK

over the telephone to someone in a third country who then enters the information on a

computer.

Guidance from the European Court of Justice in the Lindqvist case should be borne in

mind. Here it was held that there was no transfer of PD to a third country where an

individual loaded PD onto an internet page in a Member State using a internet hosting

provider in that Member State, even though the page was accessible via the internet

by people based in a third country. Instead, a transfer was only deemed to have taken

place where the internet page was actually accessed by a person located in a third

country. In practice, data are often loaded onto the internet with the intention that the

data be accessed in a third country, and, as this will usually lead to a transfer, the

principle in the Lindqvist case will not apply in such circumstances. However, in

situations where there is no intention to transfer the data to a third country and no

transfer is deemed to have taken place as the information has not been accessed in a

third country (ie the 8th DPP does not apply), data controllers will still need to ensure

that the processing complies with all of the other DPPs. In particular, data controllers


57

must consider the requirement in the 1st DPP that the processing must be fair which

may be contravened by making the data so widely accessible.

The ICO guidance on consent for transfers from employees recommends that such

consent should be explicit, given freely and capable of being subsequently be

withdrawn by the individual (though note there is no express requirement for this

under the Act). Consent, say the ICO, is unlikely to be valid if the individual has no

choice but to give their consent e.g., if Mary was asked to agree to the international

transfer of her PD, her consent will not be valid if the penalty for not agreeing was her

dismissal from Company X. In all circumstances, the employee must know and have

understood what they are agreeing to. Employers should specify the reasons for the

transfer and as far as possible the countries involved. Any known risks involved in the

transfer should be communicated to the employees concerned. Consent, of course,

may not be required if Mary's contract of employment already necessitates the

transfer of her PD. Alternatively, any amendment to Mary's contract of employment

as a result of the secondment arrangement could in itself represent a new consent.



discloses her data.




stored/used


Need to consider implicit revocation




Need to consider the case of transborder flow of data






UC8 - Mary comes back to UK

This is the symmetric case to UC7. There are no additional requirements, but a need

to consider the implications of coming back to UK, in terms of services, data flow,

etc. It is necessary to consider the role of automatic C&R management to deal with

these predictable cases, for example to reinstate previous consent, etc.


58

UC9 - Mary goes on sick leave for 6 months

Mary gets sick. She needs to stay away from work for 6 months,

She might have little access to enterprise services and portal.

She might have expressed her preferences in terms of consent and revocation on how

to handle this situation, in particular in terms of accesses to her data whilst off sick.

Legal Input

As far as processing of PD is concerned, the employment contract between Company

X and Mary will legitimise all the necessary activities envisaged by this scenario. It is

difficult to see how and when additional consent/revocation will be required.

Furthermore, the level of sick pay will be determined by Company X at its discretion

(subject to the statutory minimum and any agreements with Mary).

It is not clear what PD Mary may require access to whilst off sick, and how that may

be altered by the fact that she is not in the office. The Act does not distinguish

between healthy and unhealthy data subjects! Arrangements made between Mary and

Company X as regards remote working, for example, will not bring the Act into play:

this will be an employment matter and thus subject to the contract of employment or

any relevant company policy in place.


It is necessary to deal with automation of C&R, based on the context and events.

UC10 - Phil, a Contractor, joins Mary's team

Mary is expanding her team. Phil, a contractor, joins this team, from contracting

company Y. Company Y already has a copy of Phil's personal data. Phil might have

expressed degrees of consent and preferences about these data. Now part of this data

(address, bank account information, etc.) might need to be disclosed to Company X.

Legal Input

The Act does not distinguish between employees and contract workers, nor indeed

does it distinguish between PD processed about individuals in their work or personal

capacities. The Act is only concerned with PD as between data subjects and data

controllers/data processors that process such PD. Here, Phil will be the data subject,

and X will be the data controller.

It is likely that both a recruitment agency (R) and Company X would be data

controllers of Phil‟s PD here. X is unlikely to be a data processor, as it will be using

Phil‟s PD for its own purposes, and not purely on the instruction of R. Data

processors are not afforded any autonomy when it comes to the processing of PD.


59

On the assumption that there are two data controllers (X and R), Phil will be able to

make a SAR to either, or both, data controllers. Whilst there is a relationship between

X and R, the Act will treat them as separate entities when it comes to the application

of the data subject‟s rights, or the obligations placed upon them as data controllers

(unless it can be shown that the data controllers are acting jointly when it comes to

deciding how the PD is processed).


Need to describe how consent can be passed from Company Y to Company X

at the time Phil's data are disclosed.




stored/used

Need to enforce revocation. What is the contact point for revocation? Should it

be Company Y, as the source of data?




In case C&R was managed by Company Y, what are now the implications for



Need to allow Phil's attributes (potentially stored in various parts of the


Need to discriminate between data that are potentially private/confidential

(hence might be subject to expressions of consent) from other type of data

UC11 - Company X introduces new data analytics tools

Company X decides to introduce new data analytics tools, in particular a tool to

process emails exchanged by employees and produce graphs and information

describing the flow of information and intensity. This includes linkage back to

individuals (e.g., reflecting work or personal-related exchanges of emails, on work

machines).

In particular this applies to Mary's and Phil's email traffic. Despite this being

potentially legally compliant, they might need to be notified, made aware about these

changes and acknowledge them.

They might be allowed to opt-in to/opt-out of a service that allows them to see some

of the trends and personally-related information, to check for the correctness of this

information and/or explain behaviours.

Legal Input

The first question to ask here is whether the monitoring amounts to processing of PD

under the Act. If it does not, then the Act will not apply. If the Act does not apply,


60

then it may be the case that the Regulation of Investigatory Powers Act 2000 (RIPA)

and the Telecommunications (Lawful Business Practice) (Interception of

Communications) Regulations 2000 (LBP Regulations) come into play, however this

is not entirely straightforward.

ICO guidance on the monitoring of employee communications makes the following

recommendations:

Tell employees what monitoring is taking place and why, and keep them

aware of this, unless covert monitoring is justified.

Ensure that employees are aware of the nature and extent of any monitoring

e.g. set up a system (via an employee handbook/intranet) to ensure workers

remain aware that monitoring is being conducted, and tell employees when

significant changes are introduced.

If monitoring employees‟ performance or conduct results in the collection of

information on such matters as health, racial origin, trade union activities or

sex life (e.g., SPD) check that at least one of the sensitive data conditions in

the Act is met.

Other soft law (e.g., International Labour Office's guidance on the 'Protection of

workers‟ personal data') recommends that consent of employees is given to any

monitoring of employees in the workplace that involves PD of the employees.


61

The following diagram summarises whether the provisions of RIPA and the LBP

Regulations may be met in relation to employee monitoring:

Figure 10: Considerations relevant for employee monitoring (Copied from [39], p59)

The ICO's explanatory notes4 for this diagram are as follows:

1. Is there an interception?

Interception takes place if the contents of a communication are made available, during

the course of its transmission, to someone other than the sender or intended recipient.

Depending on the nature of the communication the intended recipient may be simply

a business or a specific individual. Examples where interception may take place

include a supervisor listening in to calls, a business opening e-mails stored on a server

before they have been opened by the intended recipient, and an automated system that

opens e-mails and/or their attachments to check them for viruses. Examples that do

4 Copied from [39], pp59-62


62

not involve interception include a business accessing a stored collection of e-mails

that have been received and opened or deleted by the intended recipient, and a

business accessing a stored collection of sent e-mails.

2. Have senders and recipients both given consent?

Interception is allowed if the business has reasonable grounds for believing that both

the sender and recipient have consented to the interception. Interception is also

allowed in certain other circumstances without the consent of the sender or recipient.

However, if a business is to rely on consent in order to legitimise an interception,

there must be some action from which consent can be inferred, for example, the caller

saying “yes” when asked or proceeding with a telephone call after hearing a message

saying that calls are recorded. Consent must be freely given. Businesses might choose

to rely on consent to cover the interception of telephone calls or internal e-mails but it

is hard to see how consent can readily be obtained from external senders of e-mail.

3. Is the interception connected with the operation of the communications system

itself?

Interception without consent is allowed if:

it is undertaken by or on behalf of a business that provides a

telecommunications service, and

it takes place for purposes connected with the provision or operation of that

service.

Providing a telecommunications service means providing access to and facilities for

making use of an electronic communications system. Employers will often be

providers of a telecommunications service in respect of their own networks. They

might rely on this provision where, for example, incoming e-mails are intercepted by

the IT department in order to divert them so as not to block up an e-mail gateway.

4. Is the interception only for monitoring business-related communications?

Interception without consent is not allowed by a business unless the interception is

solely for monitoring (or recording) communications which:-

involve the business entering into transactions, or

relate in another way to the business, or

take place in some other way in the course of carrying on the business.

These categories cover most business communications but they do not include

personal communications by workers unless they relate to the business. Interception

will not be allowed if it is carried out wholly or partly to gain access to the contents of

personal communications sent to or by workers that do not relate to the business. This

does not prevent interception which is carried out only to gain access to the contents

of business communications but which may incidentally and unavoidably involve

some access to other communications on the system.


63

5. Is the interception to decide whether a communication is a business related one?

Interception without consent is allowed if it is to monitor, but not record,

communications to check whether they:

involve the business entering into transactions

relate in another way to the business

For example, an employer may open e-mails in an absent worker‟s in-box if this is

necessary to see whether there are business communications that need to be dealt with

in the worker‟s absence. However, the employer should not open e-mails that in their

unopened state appear not to relate to the business, e.g., e-mails that are marked

„personal‟ in the header, unless there are convincing grounds on which to believe they

are in fact business related.

6. Is a confidential telephone counselling or support service involved?

Interception without consent is allowed if it is to monitor, but not record,

communications to a confidential, free, telephone counselling or support service

operated in such a way that users can remain anonymous. This is to enable help-line

workers to receive appropriate supervision and support.

7. Is the interception for an authorised business purpose?

Interception without consent is allowed if it is part of monitoring (or recording)

business communications for one of the following purposes:

To establish the existence of facts (e.g., to collect evidence of transactions

such as those involved in telephone banking or to keep records of other

communications where the specific facts are important, such as being able to

prove that a customer has been given certain advice).

To check that the business is complying with regulatory or self-regulatory

procedures (e.g., to check that workers selling financial services are giving

customers the “health warnings” required under financial services regulation).

To check the standards that workers are achieving (e.g., to check the quality of

e-mail responses sent by workers to customer enquiries).

To show the standards workers ought to achieve (e.g., for staff training).

To prevent or detect crime (e.g., to check that workers or others are not

involved in defrauding the business).

To investigate or detect unauthorised use of the telecommunications system

(e.g., to ensure that workers do not breach the employer‟s rules on use of the

system for business purposes, for example by sending confidential information

by e-mail without using encryption if this is not allowed. Note that

interception that is targeted at personal communications that do not relate to

the business is not allowed regardless of whether the use of the system for

such communications is authorised).

To ensure the security of the system and its effective operation (e.g., to check

for viruses or other threats to the system or to enable automated processes

such as caching or load distribution).


64

8. Have all reasonable efforts been made to inform users of the interception?

The requirement of the LBP Regulations is to make reasonable efforts to inform users

of the system that an interception may take place. Workers, including temporary or

contract staff, will be users of the system but outside callers or senders of e-mail will

not be. Where, as will usually be the case, interception involves the collection, storage

or use of personal information, the requirements of the Act to provide information to

those whose data are processed will come into play. Information required under both

the LBP Regulations and the Act overlaps and can of course be provided at the same

time.


Expression of consent and revocation in contexts beyond "classic" personal

data, including access and participation to services containing information

determined from aggregation/analysis of data


Need to associate consent and preferences to data in the enterprise back-end,

by taking into account various locations/departments where data could

actually be stored/used

Need to enforce revocation.



Need to discriminate between data that is potentially private/confidential


UC12 - Mary fires Phil because of misconduct

Mary is notified about abnormal Phil's behaviour, both in terms of exchanged emails

with external people and access to gambling sites. This is against Company X

policies. Phil cannot justify the reasons of this behaviour. Mary has to sack him.

Phil might still be entitled to revoke consent to use some of his personal data, for

which he gave consent at the employment time. Alternatively this could be done

automatically, based on Phil's preferences.

Legal Input

As per the 5th DPP, only the relevant PD needs to be retained. The relevance is most

likely to be defined by employment law/guidelines, and there are no specific

provisions in this regard under the Act. It is prudent for data controllers to have a

(reasonable, i.e., objectively justifiable) data retention policy.

It is questionable as to whether there is any workable right for a data subject to object

to retention of PD if it is deemed to be "inaccurate" by way of its redundancy. The

Act defines inaccurate data as any which are "incorrect or misleading as to any


65

matter of fact". Avenues to object require a court order, and are thus not likely to be

feasible in the majority of circumstances.

The data subject / data controller relationship persists despite the sacking.


It is necessary to provide expression of revocation and its limits (e.g., which data are

going to be affected)

Need to describe how revocation can be captured

Need to enforce revocation.

Need to provide feedback to Phil about the implications of revocation and

enforcement status


Need to deal with the flow of revocation from Company X to Company Y

Need to discriminate between data that is potentially private/confidential


UC13 - Mary gets demoted

Mary is unhappy with the working environment. Her team is shrinking and she is

frustrated about her inability to deliver. She is eventually demoted as her role cannot

be justified anymore.

Mary feels there has been a breach of trust. She decides that some of the consent she

gave about her personal and confidential data should be revoked along with the

revocation of her subscription to a few corporate services (e.g., stock purchase

scheme, etc.).

Legal Input

As with promotion, there do not appear to be any significant issues here. The data

controller and data subject remain the same, as does the PD. Processing of PD for any

new activities will be a legitimate interest of Company X, and most probably covered

by any new contract/variation agreement signed by Mary.


Need to describe how consent changes and/or revocation can be expressed and

captured

Need to associate consent to data in the enterprise systems‟ backend, by taking

into account various locations/departments where data could actually be

stored/used







66







UC14 - Mary leaves Company X

Mary eventually decides to leave the company. She decides to revoke all (optional)

consent on usage of her data and requires deletion of data where possible,

Legal Input

The ICO recommends seeking consent from workers/employees as to the provision of

references. This can be done by way of a specific clause in an employee‟s contract or

a specific „consent‟ form to be completed once it is clear the individual is leaving.

The data subject / data controller relationship persists despite the end of the contract.

The 5th DPP is particularly relevant here: PD must not be kept for longer than is

necessary for a particular purpose. There are no statutory limits in the Act for the

retention of data for references (or indeed any PD) so this will be a matter of company

policy. The 2nd DPP also comes into play: only the PD required for giving references

needs to be retained. As does the 3rd DPP: the PD retained should be relevant and not

excessive.

X should make data subjects aware of their policy in this regard i.e., set out the

categories of information (which may or may not include PD) that they could include

in references requested by or on behalf of a data subject.

If a data subject does not consent to a data controller using PD to complete a reference

(e.g. they do not agree by way of a separate form towards the end of their time at the

company) then the data controller should delete such records as soon as is reasonably

practicable to do so (5th DPP) in line with their data retention policy.


Need to describe how consent changes and/or revocation can be expressed and

captured



stored/used







67







Use Cases Related to the WorkBook service

The following addresses four additional use cases centered on employees' usage of an

internal social networking WorkBook service (similar to Facebook, but used for

professional purposes).

The company operates a system called WorkBook. This is a private version of a

service that provides similar functionalities to those of FaceBook and Twitter and

operates on the company intranet. Employees can use it to talk about their skills, the

projects they are working on and also for personal information about their social life.

Use of WorkBook is optional but encouraged to promote team working and to help

get maximum benefit from the workforce‟s skills.

Personal WorkBook data may be provided to external organisations under

arrangements agreed by the company. Refer to Section 3 for more details.

General legal comments on WorkBook

The WorkBook use cases, described below, raise a number of legal issues.

Firstly, there is the issue of 'direct marketing' (defined in the Act as being

communication, by whatever means, of any advertising or marketing material which

is directed to particular individuals). Data subjects have particular rights as regards

direct marketing, and these rights are more robust than the

problematic/cumbersome/non-existent general right of revocation under the Act.

Secondly, there is the issue of who is the Data Controller in any given circumstance:

will it be Company X; WorkBook (assuming there is a separate legal entity distinct

from Company X); the third parties seeking to advertise via WorkBook; or the

individual employees using WorkBook. As discussed above, there are a number of

legal obligations which a Data Controller must comply with under the Act.

Thirdly, and closely related to the previous point, is what the nature of the processing

carried out by a Data Controller.

Fourthly, and finally, it is safest to assume that all the data entered by Mary and other

WorkBook users will be PD when in the hands of the various Data Controllers.


68

UC15 - Mary starts using the company's WorkBook service

Mary starts using the Company X‟s WorkBook service. She simply connects to the

application on the intranet and edits her profile (containing default entries), adding a

description of her technical skills and adding a bigger piece on her leisure time

activities (skiing) and preferences (white wine). Her employee information (e.g.,

location, telephone number, organisation, role, etc.) are directly retrieved from the

central enterprise directory supported by the organisation. At this point the data are

only accessible to work colleagues.

Legal input

Mary enters certain PD into WorkBook herself. Other PD is uploaded onto

Workbook, and linked to Mary's profile it is assumed, by Company X. Both of these

sets of PD will be accessible to the entity operating WorkBook, be that Company X or

a separate legal entity. In either case, that entity would be the data controller as they

will be processing the PD in question, i.e. they are making decisions about how the

PD will be used/allocated within WorkBook. Mary's processing of PD in this instance

(solely within Company X) is highly unlikely to constitute processing in excess of the

'household exemption', and as such she will not be considered a data controller. Nor

indeed will other employees of Company X using WorkBook as users (i.e., in the

same way as Mary) be considered data controllers, as opposed to any employees who

assume the role of administrator (e.g. those in the HR department that monitor/control

WorkBook).

The privacy policy of WorkBook needs to provide adequate Fair Collection

(discussed above) to ensure that the processing is fair. It is assumed that Mary

consents to the processing of her PD. Even if she has not fully understood the nature

of the direct marketing that may soon come here way, the Act will give her a strong

right to take action.



discloses her data (e.g., setting access & visibility only to a list of selected

colleagues or all employees, etc).

Need to allow simple setting of preferences by GUI along with customisation

(e.g., who can access what information and under which constraints)

Need to associate consent to data in the enterprise back-end (WorkBook

Service and related sub-services), by taking into account various

locations/departments where data could actually be stored/used

Need to enforce consent at the time of accessing/using data.


69

UC16 - Mary elects to allow a subset of her WorkBook data (her public profile) to be given to external organisations

Mary elects to allow a subset of her WorkBook data (her public profile) to be given to

external organisations. She has control of what should be included in this profile (by

opting-in profile fields). She hears from colleagues of some great offers they received

after signing up for the WorkBook external bonus scheme. She visits the WorkBook

intranet site and skim reads the introduction to the scheme, then clicks on the “sign

me up” button, giving consent to access this information. She also requires to be

notified by email (on a daily basis) with a list of who has been accessing and viewing

her profile. This is achieved by specifying an additional privacy preference, supported

by WorkBook.

Legal Input

Here we see the introduction of new Data Controllers: the external organisations. If

the WorkBook privacy policy does not adequately address the requirements of the

principles of Fair Collection Information in respect of the processing to be carried out

by these organisations, then each will be required to duly notify Mary about what they

will be doing with her PD in order for the processing to be fair. Again, it is assumed

that Mary is consenting to the processing in question.



discloses her data (e.g., setting access & visibility only to a list of selected

colleagues or all employees, etc).

Need to allows simple setting of preferences by GUI along with customisation










Need to provide mechanisms to support the enforcement of enterprise

obligations, i.e., notification. This must be an orchestrated effort among all the

involved parties (that received Mary's data + privacy preferences)

Need to provide mechanisms dealing with "stickiness" of policies and

preferences to PD, once disclosed to a third party


70

UC17 - Mary uses the WorkBook service to book holidays

Mary accesses the WorkBook site one day and sees an advert for a group skiing

holiday in the Alps. She discusses this with some employees through WorkBook and

they agree it‟s an offer that can‟t be refused. The group signs up, takes the holiday and

have a really good time. On their return they populate WorkBook with an account of

their adventures (thereby encouraging others as to the benefits of the scheme).

Legal Input

It is questionable as to whether individual WorkBook users e.g., Mary, could be

deemed Data Controllers if other users post their own PD on Mary's page. If the

privacy settings on Mary's page, and other users' profiles, were such that Mary's page

could be used as a portal by which all the others' PD could be viewed, it is perhaps the

case that Mary becomes a Data Controller. Given the context of a relatively closed

Network (i.e., within Company X) it is perhaps unlikely that this is a realistic label to

apply to Mary or other users; contrast the situation where a Facebook user's page

could be used as a source of PD if it gave access to the PD of all of that users friends

(who had not adjusted their privacy settings accordingly).

In short, there are probably no significant legal concerns under the Act with this use

case.


Need to describe how default consent (based on previous preferences) can be

managed at the time Mary discloses her data.

Need to enable flexible expression of consent on data, based on group

membership, private and public profiles.

Need to allows simple setting of preferences by GUI along with customisation










Need to provide mechanisms to support the enforcement of enterprise

obligations i.e., notification. This must be an orchestrated effort among all the

involved parties (that received Mary's PD and privacy preferences)

Need to provide mechanisms dealing with "stickiness" of policies and

preferences to PD, once disclosed to a third party


71

UC18 - Mary changes her preferences in the WorkBook Service

Mary has a bad week at work and every day finds an email message offering

insurance from a WorkBook-associated external company. She notices from her daily

reports (sent by WorkBook) that her current profile is primarily viewed by

unwelcome organisations (including marketing and financial sites). She‟s annoyed by

this intrusion and as a result accesses the WorkBook control panel to alter her consent

parameters. She sets her preferences about the type of offers received to decline offers

relating to financial services. As a result, she receives no more insurance offers. She

also modifies her external profile by changing the settings (and consent) of what can

and cannot be displayed externally.

Legal Input

All data subjects have the right to prevent processing carried out for direct marketing

purposes. This right means that a data subject can make a specific request, in some

form, to the relevant Data Controller to demand that the direct marketing ceases and

that the processing of the PD that facilitated the direct marketing also stops. There are

no exceptions to the right to prevent processing for the purposes of direct marketing.

Assuming the instructions given to the external company, via WorkBook, are

sufficiently clear then the insurance emails must stop. Both WorkBook and the

external company will be considered as Data Controllers here, and both must comply

with the request from Mary within a reasonable period of time regardless of any time

limit mentioned by Mary in her instructions.

The terms and conditions that Mary signed up to before she started to use WorkBook

would not be able to deny Mary the right to prevent direct marketing in this way. If

the terms suggested this was the case, it is highly likely that they would be considered

void. Similarly, claims to 'ownership' of PD by WorkBook users are unlikely to have

any basis: UK law does not recognise anything akin to a proprietary right in data or

information.

The 'research company' mentioned in the WorkBook preamble is likely to be

considered as providing 'direct marketing' if the communications it sends to users

relate to the 'aims and ideals' of the company. As such, users will have the same right

to opt out of receiving such communications.

Finally, it is worth mentioning that any of the external companies signed up to

WorkBook that sent email messages to users that could be considered unsolicited (i.e.,

not in accordance with the privacy policy/terms and conditions) are likely to be

considered unlawful (all unsolicited email SPAM is unlawful). It will, however, be

difficult to define any communications from WorkBook-associated companies as

being unsolicited (unless there has been a previous request by a data subject that such

communications stop).


72


Need to describe how consent changes and/or revocation can be captured.

How to do this in case multiple profiles are involved (e.g., internal and

external profiles, membership groups, etc.)

Need to enable flexible expression of revocation on data, based on group

membership, private and public profiles.

Need to allows simple setting/changes of preferences by GUI along with

customisation (e.g., who can access what information and under which

constraints)






73

Appendix B: Architectural Interaction Flows

Appendix B details how the components of the architecture specified in Section 6

(Refined Technical Architecture) interact (in accordance with the high-level

architecture described in Section 5) to allow the actions described in Section 3

(Enhanced Employee Data scenario).

We have selected a few sequences that permit illustration of all the different types of

interaction. We present these in a sequence which represents realistic chronological

ordering, rather than in use case number order. Two administrative use cases have

also been introduced, to illustrate the link between the Data Model and the

configuration of the data stores and of the policies. We also provide some brief

guidelines for the management of errors and failures that could happen in various

EnCoRe components (and other systems EnCoRe relies on).

It is important to note that currently, in order to request the authorisation to access to

some resources, the Notification Manager uses its local PEP to contact the PDP.

However, in principle the local PEP should contact the central PEP first. The central

PEP then transmits the access request to the PDP.

In this document, each interaction flow has a brief description on how components

interact; for some flows, details are shown in following UML sequence diagrams. We

assume that the reader will be viewing this document on a screen and hence be able to

enlarge the display of these, if necessary, to read the detail.

Administrative Use Case 1

This use case is where an administrator initially sets the storage of personal data and

C&R preferences.


74

High level component interactions

Figure 11: Administrative use case 1 interactions

1. Data stores must be configured (1.1 and 1.2) to store the personal data and

C&R preferences as specified by the selected data model

See messages 1 and 2 in the sequence diagram Figure 12

2. Mechanisms should be set that make it possible to store the personal data and

C&R preferences in the right data stores after data subjects have submitted

them

See message 3 in the sequence diagram Figure 12


75

Interaction details

Figure 12: Use case 1 interaction details

Administrative Use Case 2

This use case is where an administrator sets the policies.


Figure 13: Administrative use case 2 interactions

The actions that should be performed by the administrator to configure the policies

are described in the figure below.


76

Figure 14: Instructions for administrator


77

Interaction details

Figure 15: Use case 2 interactions


78

Employee Use Case 1 (UC1)


Disclosure &NotificationManager

To Employee

AuditLogs

4

4.1

4.2

4.3

4.7

4.6

Web Browser +

C&R Privacy AssistantPlug-in

Port

als

&A

cces

s Po

ints

(Virtual)Data

Registry

EnterpriseDataRepositories

Data + Consent

Data Ref +C/R preferences

- C&R PreferenceConfiguration

- PII Data Storage

Company X

Data +Consent &Revocation Requests

Consent & RevocationProvisioning

Data Subject

C&RProvisioning

Daemon

C&RVerification

WorkflowManager

C&RRegistration

Process

DataRegistryDaemon

DataRegistryMappingProcess


PEP

PEP

1

2

3

Privacy–aware Policy Enforcement

Policies

5

4.4

4.5

4.8

Figure 16: UC1 interactions

1. After Mary‟s login through the portal, data and C&R preferences are provided

through GUIs.

2. C&R provisioning module uses workflow manager to store data and C&R

preference in enterprise data repository.

3. Data registry stores data reference together with C&R preference.

4. The Disclosure & Notification Manager is informed (4.1) that a new

registration has happened. It runs the notification process (4.2 to 4.8) to notify

Mary that the registration has been effective.The interactions 4.1 to 4.8 are

detailed in the sequence diagram Figure 19.

5. Between the Interactions 4.2 and 4.3, the access authorisation process is run

privacy aware enforcement module to authorise the access to the data

necessary for the notification.


79

Interaction details

Interaction 2:

Figure 17: UC1 interaction 2


80

Interaction 3:


Interaction 4: The sequence diagram below details the interactions required to notify Mary that the registration was

effective.



81

Interaction 5:



82




To Employee

AuditLogs

4

4.1

4.2

4.3

4.8

4.7Privacy–aware Policy Enforcement

Policies

Web Browser +


Port

als

&A

cces

s Po

ints

(Virtual)Data

Registry


Data + Consent



- PII Data Storage

Company X



C&RProvisioning

Daemon

C&RVerification

WorkflowManager

C&RRegistration

Process

DataRegistryDaemon



PEP

PEP

1

2

3

5

Third Party

4.4

4.5

4.6

optional

4.9

Data Subject


1. After Mary logs in through the portal, the data and C&R preferences she wants

to update are provided through GUIs.

2. C&R provisioning module uses workflow manager to update data and C&R

preference in enterprise data repository.

3. Data registry updates data reference together with C&R preference.

4. The Disclosure & Notification Manager is informed (4.1) that an update has

happened. It runs the notification process (4.2 to 4.9) to notify Mary that the

update has been effective and, if Mary has updated her preferences and if the

associated data were disclosed to a third party, to notify the third party that

was disclosed Mary‟s personal data, that her preferences have been updated.

The interactions 4.1 to 4.9 are detailed in the sequence diagram Figure 24

5. Between the Interactions 4.2 and 4.3, the access authorisation process is run to

authorise the access to the data necessary for the notification


83

Interaction details

Interaction 2:



84

Interaction 3:


Interaction 4:

The sequence diagram below details the interactions required to notify Mary that the

update has been effective and, if Mary has updated her preferences, to notify the third

party, that was disclosed Mary‟s personal data, that her preferences have been

updated.



85




1. The WorkBook‟s agent advertises that data are about to be disclosed to the

Holiday Company (0.1). The EventListenerModule intercepts (1.1) the

advertisement and informs the Disclosure & Notification Manager that then

runs the process allowing to request Mary‟s authorisation to disclose the data

(1.2 to 1.7).



by the policy enforcement module to authorise the access to the data necessary

for the notification

3. Mary accepts her data to be disclosed to the Holiday Company. The

Disclosure & Notification Manager runs the process allowing the disclosure of

Mary‟s personal data to the Holiday Company. This includes getting the data

to be disclosed from the enterprise data repository after having obtained the

required authorisation.



policy enforcement module to authorise the access to the data necessary for

the notification


86

5. Related disclosure information is stored in DR (and/or enterprise data

repository).

It is important to note that alternative cases are possible. Interactions 1 can

alternatively correspond to the cases where:

Mary has specified that the disclosure should always be permitted.

Mary has specified that the disclosure should always be denied.

In both of these cases it is unnecessary to request Mary's authorisation to disclose the

data to the third party. No sequence diagram has been generated for these cases.

However, they would be similar to those corresponding to the cases where Mary

permits or denies the disclosure except that there would be no interaction with Mary

to request an authorisation.

The interactions 3 can alternatively correspond to the cases where:

Mary denies the disclosure of her data to the third party.

For a reason, Mary does not respond to the authorisation request but has

specified that, when she is unable to respond to an authorisation request, the

system should consider that the disclosure is permitted.

For a reason, Mary does not respond to the authorisation request but has

specified that, when she is unable to respond to an authorisation request, the

system should consider that the disclosure is denied.

All these cases have been dealt with. However, they have been illustrated in this

document.


87

Interaction details

Interaction 1: The sequence diagram below details the interactions required to

request Mary‟s authorisation to disclose her personal data to the Holiday Company.



88

Interactions 2&4:

Figure 27: UC17 interactions 2 and 3


89

Interaction 3:

The sequence diagram below details the interactions required to disclose Mary‟s

personal data to the Holiday Company after Mary has authorised the disclosure. This

includes getting the data to be disclosed from the enterprise data repository after

having obtained the required authorisation


Interaction 5:



90



Web Browser +


Port

als

&A

cces

s Po

ints

(Virtual)Data

Registry



- PII Data Storage

Company X

Revocation Requests


C&RProvisioning

Daemon

C&RVerification

WorkflowManager

C&RRegistration

Process

DataRegistryDaemon



PEP

PEP

1

2

5


To Employee

AuditLogs

3

3.1

3.2

3.3

3.8

3.7Privacy–aware Policy Enforcement

Policies

4

3.4

3.5

Revocation

Third Party

3.6

optional

3.9

Data Subject


1. Mary logs in to the portal and sends out the revocation requests.

2. C&R provisioning identifies these requests and notifies disclosure &

notification manager.

3. The Disclosure & Notification Manager is informed (3.1) that a revocation

has been requested. It runs the notification process (3.2 to 3.9) to notify Mary

that the revocation has been effective and inform the third party that was

disclose the data in the past that the revocation was requested by Mary.



privacy enforcement module to authorise the access to the data necessary for

the notification and allow data (e.g. those to be used for the notification) to be

deleted

5. C&R receives the confirmation from Disclosure & Notification Manager and

proceeds to delete data in the Data Registry.

Interaction details

Interaction 3:

The sequence diagram below details the interactions required to notify Mary that the

revocation has been effective and inform the third party that was disclose the data in

the past that the revocation was requested by Mary.

It has been assumed that the Disclosure & Notification Manager accesses the personal

data required to notify Mary and then deletes these from the data repositories.


91


Interaction 4:



92

Interaction 5:



93



Web Browser +


Port

als

&A

cces

s Po

ints

(Virtual)Data

Registry


Data + Consent



- PII Data Storage

Company X



C&RProvisioning

Daemon

C&RVerification

WorkflowManager

C&RRegistration

Process

DataRegistryDaemon



PEP

PEP

1

2

3

Data Subject


1. Mary signs into portal and choose to allow part of WorkBook data to be

accessible by external parties.

2. C&R provisioning binds default C&R preferences with selected data.

3. C&R stores information in the Data Registry.


94

Interaction details

Interaction 2:



95

Interaction 3:



96



Web Browser +


Port

als

&A

cces

s Po

ints

(Virtual)Data

Registry


Data + Consent



- PII Data Storage

Company X



C&RProvisioning

Daemon

C&RVerification

WorkflowManager

C&RRegistration

Process

DataRegistryDaemon



PEP

PEP

1

2

3

Data Subject


1. Mary signs into portal and choose to update C&R preference.

2. C&R provisioning binds new C&R preferences with selected data.

3. C&R update information in the Data Registry.


97

Interaction details

Interaction 2:



98

Interaction 3:



99



Company X

Web Browser

+

C&R Privacy

Assistant

Plug-in

Po

rta

ls &

Acce

ss P

oin

ts(Virtual)

Data

Registry

Enterprise

Data

Repositories

WorkBook

Data Ref +

C/R preferences

- C&R Preference

Configuration

- PII Data Storage

Privacy–aware

Policy Enforcement

Policies

Access to

Services

Data +

Consent &

Revocation

Requests

Service

Requests

Agent

Consent &

Revocation

Provisioning

Data Subject

C&R

Provisioning

Daemon

C&R

Verification

Workflow

Manager

C&R

Registration

Process

Data

Registry

Daemon

Data

Registry

Mapping

Process


PEP

PEP

PEP

Policy

Decision

Point

Context

HandlerPEP

Data + Consent

Revocation

1

2

3

5

EventListenerModule


To employee

AuditLogs

4

4.1

4.2

4.3

4.8

4.7

Third Party

4.4

4.5

4.6

optional

0.1

Admins

4.9

0.2


Interaction details

1. Mary accesses the WorkBook service through portal.

2. All relating requests are sent to WorkBook application.

3. WorkBook related data are stored in enterprise data repository by triggering

policy enforcement module.

4. The Disclosure & Notification Manager is informed by the

"EventListenerModule" components that Mary has used the application to add

some data in the system. The Disclosure & Notification Manager runs the

process allowing to inform Mary that her changes have been effective in the

system and, if Mary has updated her preferences and if the associated data

were disclosed to a third party, to notify the third party, that was disclosed

Mary‟s personal data, that her preferences have been updated.

This is detailed in the sequence diagram Figure 42.

5. (optional) Mary may disclose further data with C&R preference as required by

WorkBook. (See SD in UC1)

6. (optional) Mary uses Data viewer to get all the information that Company X

holds.


100

Interaction 3:


Interaction 4:

The sequence diagram below details the interactions required to notify Mary that her

data have been properly updated by the application.



101

Interaction 6:


Error Management Guidelines

Three approaches could be used to manage errors and failures in the EnCoRe system:

1. Each component could capture, by means of exceptions (e.g., Java

exceptions), the errors and failures (and, optionally, inform the notification

manager if needed). Errors and failures are conveyed to the components that

are coordinating the interactions in EnCoRe. Note: No attempts are made to

remediate these problems - expectations are just notified to the end user (in a

suitable way). Usually the coordinating components in charge of this are:

a. The C&R provisioning component

b. The Agent component deployed within applications

2. As at point 1. In addition each EnCoRe component (at least the ones that

orchestrate activities) now also manages a log/trace of the activities that have

been carried out, including the failure points. This can be used for auditing

3. As at point 2. In addition each component (at least the ones that orchestrate

activities) could have a rollback and remediation functionality that permits to

cancel some actions in the case where there was an error/failure and then try to

remediate them.

It is recommended that the first of these be used by the EnCoRe project‟s reference

implementation of this first EnCoRe Technical Architecture.


102

Appendix C: Data Model

In this appendix, we discuss possible data models for the EnCoRe Enhanced

Employee Data Scenario. It aims at highlighting some of the different approaches that

can be used. It also aims at identifying the possible problems that must be dealt with.

Most of these arise from the need to consider different types of data repositories.

Here, we focus on relational databases and on repository relying on the Lightweight

Directory Access Protocol (LDAP).

This appendix is organised as follows. In C.1, we identify the data items that have to

be collected, used or modified in the selected use cases. Then, we define in C.2 the

preferences that are needed to allow the data subject to specify her/his preferences

(consent, requirements regarding the revocation of her/his data and the way she/he

would like to be notified by the EnCoRe system). In C.3, we define a data model for

relational databases and, in C.4, a data model for LDAP directories that respectively

present how data items and preferences can be stored in relational databases and

LDAP directories to allow the association of preferences to the suitable data items.

We conclude this appendix in C.5.

C.1 Data collected from the data subject

Different types of data need to be managed by the EnCoRe system:

Data specified by the data subject, i.e., the personal data and the

corresponding preferences;

Data generated by the system after a data subject (or a third party) has

sent data to or has received data from the EnCoRe system.

Among the data that need to be generated by the system one finds:

“The moment consent was granted”;

“The volume of personal data”;

“The sensitivity of personal data”;

“Forced consent”;

“Inherited consent”;

Etc.

These data are called consent variables and have been detailed in the EnCoRe

Taxonomy5.

Consent variables are important as they help the EnCoRe system to manage personal

data. They can also, as preferences, be used by the EnCoRe access control

5 To be published by the EnCoRe project


103

architecture for the authorisation decision making. However, in this document, we

focus on the personal data and preferences specified by the data subject. It is

important to note that the model discussed here can be extended as needed.

The data collected from the data subject in the selected uses cases are represented

below, in Table 4. It should be noted that the data items used in the use case 18 do not

appear in this table because they are discussed in C.2. The columns of the table are

ordered in a realistic chronological sequence, instead of by use case number.

Table 4. Data used in the selected use case of the Enhanced Employee Data Scenario

UC1 Mary (M.) is Hired

UC5 M. changes some of her personal data

UC15 M. starts using the companies WorkBook

UC16 M. elects to allow a subset of her WorkBook data (her public profile) to be given to external organisation

UC17 M. uses the WorkBook service to book holidays

UC18 M. changes her preferences in the WorkBook Service See Section C.2

UC14 M. leaves the company

Required data

Name X X X X X X

Surname X X X X X X

Date of Birth X X X X X X

Nationality X X X X X X

Postal address X X X X X X

Status(Employee/Applicant permanent/student/contractor)

X X

Landline telephone number X X X X X X

Mobile telephone number X X X X X X

Primary email address X X X X X X

Secondary Email Address X X X X X X

Bank details X X X X

Ethnicity X X

Health issues X X X X

Health insurance details

National insurance number X X X

Next of kin details X X X X

Referees’ details X X

Former salary X X

Current salary X X

Pension details X X

Resume X X X X


104

ID credential (e.g., passport, ID card, etc.)

X X X X

Employee number X X X X X

Copy of security badge X X

Photo X X X X X X

Signed employment Contract X X

Signed terms of use of computers

X X

Signed terms of employment X X

Signed contracts for the provision of mandatory service

X X

Dietary requirements X X X X X X

Job title X X X X X

Hobbies X X X X

WorkBook pseudonym X X X X

Signed Work-Book consent form

X X X

WorkBook friends (and groups)

X X X X

WorkBook discussion traces X X X X

Personal (Friends and family) pictures

X X X

Signed Vacation booking contract

X X

It is important to remember that, among the data items specified in Table 4, some are

to be assigned values by the data subject and some others by the organisation.


105

C.2 Preferences

C.2.1 Consent and revocation preferences

The preferences that can be used to represent consent and revocation in the Enhanced

Employee Data Scenario are defined in Table 5. All these data are impacted by the

use cases considered in this document. Table 5. Consent and revocation preferences

Preferences

isProces-sing Consen-ted

consen-tedPro-cessingPurpo-se

con-sented-Third-Party-Disclo-sure

consen-ted Disclo-surePur-pose

toBe Revo-ked

revoca-tionType

Revoca-tionTime (Date, occasion, etc.)

isNotifica-tionRequi-red

notifica-tionTime

notifica-tionPur-pose

notificationChannel

notifica-tionDe-fault

Date: Occasion:

Date:

Occasion:

Date:

Occasion:

Email: Phone:

Email: Phone:

Email: Phone:

Their meaning is as follows:

1) isProcessingConsented

Specifies whether the processing of the associated data is authorised or

not. In the example of Table 5, the checkbox represents consent when it is

checked in and an absence of consent otherwise.

2) consentedProcessingPurpose

Specifies the purpose for which the data subject consented her/his personal

data to be processed.


106

3) consentedThirdPartyDisclosure

Specifies the list of entities to which the data subject consented her/his

personal data to be disclosed to.

4) consentedDisclosurePurpose

Specifies the purpose for which the data subject consented her/his data to

be disclosed.

5) toBeRevoked

Specifies whether the associated data should be revoked or not. In the

example of Table 5, the checkbox represents the fact that data should be

revoked, when it is checked in, and that data should not be revoked

otherwise.

6) revocationType

Specifies the type of revocation (e.g., deletion of data, etc.) requested by

the data subject.

7) revocationTime

Specifies the time when the data subject requests revocation to be

performed. This could be a date or a specific occasion such as before or

after a specific event.

8) isNotificationRequired

Specifies whether the data subject would like to be notified or not.

9) notificationTime

Specifies when the data subject would like to be notified. This could be at

a specific occasion such as before or after a specific event.

10) notificationPurpose

Specifies the purpose for which the data subject would like to be notified.

This could be, for instance, to require the EnCoRe system to obtain a

positive authorisation from the data subject to disclose her/his personal

data to a third party before any data item is disclosed.

11) notificationChannel

Specifies the channel that the data subject would like the organisation to

use in order to notify her/him. This could be an email address or a

telephone number.

12) notificationDefault


107

Specifies the default action that should be performed if no authorisation

response has been received from the data subject after a notification for the

specified purpose(s) was sent.

C.2.2 Revocation

The preferences that trigger revocation are:

1) toBeRevoked;

2) revocationType;

3) revocationTime.

These preferences can be set at registration in the case where time based revocation is

required. They can further be set whenever the data subject wants to revoke some

data. As soon as these preferences have been set, the EnCoRe system should take

them into account to set the mechanisms that ensure that revocation will be enforced

as specified by the data subject.

C.2.3 Choices

Three different approaches can be chosen to allow the data subject to specify her/his

consent and revocation preferences, as discussed in the following sub-sections.

C.2.3.1 A “level based” approach

If this approach is used, the data subject will have to choose among a finite number of

profiles – the data subject is only given as many choices as there are profiles – and the

associated consent and revocation preferences will be automatically filled by the

EnCoRe system.

C.2.3.2 Assign preferences to each data item

The opportunity could be given to the data subject to assign different preferences for

different data items. The advantage of this approach is that it gives more freedom to

the data subject to define how she/he would like her/his data to be used by an

organisation. However, the drawback of this approach is that it is not elegant, as it

requires the data subject to specify the same information many times. The more

personal data items are collected by the organisation, the more cumbersome this

approach is.

C.2.3.3 Assign preferences to a group of data items

An alternative to the approach defined in the previous section is to assign the same

preferences to a group of data items. The advantage of this approach is that it reduces

the number of “actions” that must be performed by the data subject in order to specify

her/his preferences. The drawback of this approach is that, depending on how the data

are grouped, the data subject can have to make some concessions regarding how

she/he would like her/his personal data to be used.


108

The choice to be done regarding the approach to be used to allow the data subject to

specify his personal data will have to be a trade-off between usability and freedom of

choice.

C.3 A data model for relational databases

Different choices can be made in order to organise the data items specified in Table 5

in a relational databases. Here, we present some of them. A factor that impacts on the

organisation of these data is the degree of freedom given to the data subject to specify

her/his preferences. In order to take this factor into account, we divide this section in

two different subsections. The first subsection presents possible organisations of data

that apply when the data subject is given the choice to assign different preferences to

different data items (this corresponds to the case discussed in C.2.3.2). The second

subsection presents possible organisations that apply when the data subject is given

the choice to assign different preferences to different group of data items (this

corresponds to the case discussed in C.2.3.3).

C.3.1 Models for the case where different items have different preferences

C.3.1.1 Proposal 1

Data items and preferences can be organised in the following relational tables, where

underlined attributes designate primary keys and dotted underlined attributes

designate foreign keys:

Data subject details(subjectID, subjectStatus, ethnicity, name,

surname, postalAddress, dateOfBirth, nationality,

landlineTelephoneNumber, mobileTelephoneNumber,

primaryEmailAddress, secondaryEmailAddress)

Benefit(employeeNumber, subjectID, jobTitle, bankDetails,

currentSalary, pensionDetails, healthIssues,

nationalInsuranceNumber, nextOfKinDetails,

healthInsuranceDetails)

Employment profile(employeeNumber, refereesDetails,

formerSalary, resume, IDCredential, applicantPhoto,

signedEmploymentContract, signedTermsOfEmployment,

employmentStatus)

Security(employeeNumber, securityBadgeCopy, photo,

signedTermOfUseOfComputers)

Services(employeeNumber, serviceName, serviceDetails,

dietaryRequirements, signedContract)

WorkBook profile(wbID, employeeNumber, name, Surname,

jobTitle, wbPseudonym, hobbies, signedwbConsentForm,

wbFriends)

Applicant/employee

Permanent/contractor/student


109

WorkBook services(wbID, wbServiceName, wbServiceDetails,

wbServicePostalAddress, dietaryRequirements, signedContract)

Preferences(prefID, subjectID, attributeName,

consentedThirdPartyDisclosure, consentedDisclosurePurpose,

toBeRevoked, revocationType, revocationTime,

isNotificationRequired, notificationTime, notificationPurpose,

notificationChannel, notificationDefault)

WorkBook preferences(wbPrefID, wbID, attributeName,





The registry could contain the following relational tables:

Attribute info(subjectID, organisationID, holderID, tableName,

attributeName, prefID, wbPrefID)

Preferences(prefID, subjectID, attributeName,





WorkBook preferences(wbPrefID, wbID, attributeName,





The proposal takes into account the possibility that tables are in different databases.

The proposal also makes it possible to link data items to the suitable preferences even

in the case where tables are stored in different locations.

C.3.1.2 Proposal 2

A second approach would be to define three tables: the first for the personal details,

the second for the WorkBook data and the last for all the preferences. However, this

solution would create tables with a very large number of attributes and hence is not

taken further.

C.3.2 Models for the case where different groups of items have different preferences

C.3.2.1 Proposal 1

If we assume that data subjects are given the choice to specify preferences for groups

of data items, the additional following table should be added:


110

preferences groups(ID, subjectID, wbID,

preferenceGroupName, attributeName)

This table makes it possible to assign a data item to a group of preferences.

Then, the preferences and WorkBook preferences tables used in the example defined

in Section C.3.1.1 must be slightly changed as follows:

Preferences(prefID, subjectID, preferenceGroupName,





WorkBook preferences(wbPrefID, wbID,

preferenceGroupName, consentedThirdPartyDisclosure,

consentedDisclosurePurpose, toBeRevoked, revocationType,

revocationTime, isNotificationRequired, notificationTime,

notificationPurpose, notificationChannel, notificationDefault)

In the two previous tables, the “attributeName” attribute has been replaced by the

“preferenceGroupName” attribute.

C.3.2.2 Proposal 2

The second approach defined in C.3.1.2 is possible if one adds the “Attribute

groups” as defined in C.3.2.1 and adds the “preferenceGroupName” attribute in the

preferences table.

C.4 A data model for LDAP directories

In LDAP directories, entities – that can be persons, organisational units such as

departments, physical equipments such as routers, etc. – are represented by entries

characterised by attributes. The entries are organised in a hierarchy that translates the

logical relationships between these entries.

Since in LDAP, data items characterising entities are LDAP attributes, the preferences

and data items used to characterise employees, WorkBook users, etc., in the EnCoRe

Enhanced Employee Data Scenario are to be represented as LDAP attributes. Then,

allowing the data subjects to define different preferences for different data item

becomes difficult. This is because a preference attribute associated to an entry

representing a data subject entirely (the data subject and its other attributes)

characterises that data subject.

An approach to solve the previous problem can be to define different set of preference

attributes for different data items. For instance, to define the preferences for the

LDAP directory:

Surname attribute (SN), used to store the surname of an entry, the following

attributes can be associated to that entry:


111

o isProcessingConsentedSN;

o consentedProcessingPurposeSN;

o consentedThirdPartyDisclosureSN;

o consentedDisclosurePurposeSN;

o toBeRevokedSN;

o revocationTypeSN;

o revocationTimeSN;

o isNotificationRequiredSN;

o notificationTimeSN;

o notificationPurposeSN;

o notificationChannelSN;

o notificationDefaultSN.

Title used to store the title of an entry, the following attributes can be

associated to that entry:

o isProcessingConsentedTitle;

o consentedProcessingPurposeTitle;

o consentedThirdPartyDisclosureTitle;

o consentedDisclosurePurposeTitle;

o toBeRevokedTitle;

o revocationTypeTitle;

o revocationTimeTitle;

o isNotificationRequiredTitle;

o notificationTimeTitle;

o notificationPurposeTitle;

o notificationChannelTitle;

o notificationDefaultTitle.

This approach is not elegant and significantly increases the number of attributes that

must be used to characterise entries. Therefore, the most suitable approach for LDAP

is the one defined in C.2.3.3, and which consists of assigning preferences to a group

of data items. Then, three approaches can be used:

Assign the same preferences to all the attributes that specify a same entry;

Assign the same preferences to all the attributes that specify a group of

entries;

Assign the same preferences to all the attributes that belong to a same

defined group of attributes.


112

In the remainder of this appendix, we propose different models for these three

approaches.

LDAP approach 1: Assign the same preferences to all the attributes that specify a same entry

1) A data subject oriented approach

Figure 44: A data subject oriented approach for the LDAP approach 1

Figure 44 represents a data subject oriented approach where data are organised around

the data subject. This approach permits to characterise, under a same parent node, the

properties of a same data subject.


113

The attributes for each entry can be defined as proposed in the following

example. For the entry cn=Mary MarysSurname, ou=employees, ou=HR,

o=CompanyX, c=UK one can use the following attributes:

title;

landlineTelephoneNumber;

mobileTelephoneNumber;

postalCode;

emailAddress;

nextOfKin;

nationality;

...;

..;

consentedDisclosurePurpose;

toBeRevoked;

revocationType;

revocationTime;

isNotificationRequired;

notificationTime;

notificationPurpose;

notificationChannel;

notificationDefault.

2) An organisational unit oriented approach

Another approach is presented in Figure 45. This model increases the

length of the distinguish names (DNs) to be used to identify each entry, as

it relies on a tree i.e., a LDAP Directory Information tree, with a bigger

depth. However, this approach can better represent the internal

organisation of the company. Since information is spanned over well-

divided organisational units, the data related to a same data subject are

stored at more places than in the model proposed in the previous section.

This presents the interesting aspect that the attributes specifying the entries

can be more specific. This can allow giving more freedom to the data

subject regarding the definition of her/his preferences. Indeed, as the

attribute specifying each entry are more specified, the data user is able to

specify some preferences for a smaller group of attributes. Therefore, the

data subject can specify more different preferences than in the model

proposed in the previous section.

These attributes, that represent the personal

data characterising Mary, are derived from

the attributes defined in the relational tables

in Section C.3.1.1. Some of these are not

already defined in LDAP. Therefore, they

need to be defined.

These attributes, that represent the

preferences specified to characterise the

use of some of Mary‟s personal data,

are derived from the attributes defined

in the relational tables in Section

C.3.1.1. Some of these are not already

defined in LDAP. Therefore, they need

to be defined.


114

Figure 45: An organisational unit oriented approach for the LDAP approach 1

LDAP approach 2: Assign the same preferences to all the attributes that specify a group of entries

This approach requires:

Adding to the tree the branch defined in Figure 46;

Associating a group name - corresponding to one of the names of the

entries located below the entry ou=PreferenceGroups, ou=Preferences,

ou=dataProtection, ou=Privacy, o=CompanyX, c=UK - to each entry in

Figure 46.


115

Figure 46: Model allowing assignment of preferences per group of entries or attributes

LDAP Approach 3: Assign the same preferences to all the attributes that belong to a same defined group of attributes

This approach permits having in the same entry attributes to which different

preferences have been assigned. It requires:

Adding to the tree the branch defined in Figure 46

Associating a group number to each attribute

Assigning a group number to each attribute significantly increases the number of

attributes to be used to characterise an entry.

Revocation

In LDAP, since data items and preferences are attributes associated to entries,

revocation can mean an update of one or many entries. It can further mean the

deletion of one or many entries.

Registry

Preferences could be stored in the registry as defined above. The LDAP entries will

have to be composed of the suitable attributes (prefID, wbPrefID, subjectID, etc.) to

allow links to be made between LDAP entries and records in the registry.

Preferences could also be stored in other databases. This could make it possible to

deal with the case where data subjects are allowed to define different preferences for

different attributes. For that, a table would have to be defined for each entry level

where personal data are stored. Then, in each table, each record (line) will contain the


116

preferences specified by a data subject for the attributes composing the corresponding

LDAP entry. For this case also, the LDAP entries will have to be composed of the

suitable attributes (prefID, wbPrefID, subjectID, etc.) to allow links to be made

between LDAP entries and records in the databases.

C.5 Conclusion

In this appendix we have defined different approaches allowing specification of the

data model to be used in the EnCoRe Enhanced Employee Data Scenario. Different

aspects have to be taken into account in order to choose the one that most suits

EnCoRe requirements. One of these requirements is usability. The degree of liberty

that is given to the data subject regarding the specification of her/his preferences can

degrade the usability of the EnCoRe solution by requiring the data subject to perform

many actions. Usability also impacts on the structure of the LDAP tree – i.e., the

LDAP Directory Information tree – to be used. Indeed, in order to give the data

subject the possibility to specify different preferences for different small groups of

data items, it may be necessary to specify more entries than in the case where

preferences are to be assigned to big groups of data items. Another aspect that impacts

on the structure of the LDAP tree is the way in which the stored data are to be

physically stored within the organisation. Depending on the organisational units that

need to store or use the data, the LADP model can be composed of more or less

entries organised in a deeper or wider tree. This can impact in the length of the DN to

be used to identify a specific entry. It can also have an impact on the time needed to

evaluate requests.


117

Appendix D: XACML Access Control Policies Within EnCoRe it is necessary to select a low-level, technical policy language

representation that can be used at the operational level to express machine-readable

policies that can be enforced within the EnCoRe system. Rather than creating a new

language for this, it is preferable if an existing language could be used, and extended

if necessary. There are several candidates for this (as discussed in Appendix E), but

after investigation of different options and taking into account what was likely to be

taken up by others as well in the future, we focused on the XACML policy framework

[17] as the most promising candidate to fill this role. This is the current state-of-the-

art language and framework for expressing access control policies and dealing with

their enforcement. Moreover, it has already been selected by the PrimeLife project

[13] as the policy language to be used within that project. This Appendix assesses the

suitability of this framework for EnCoRe purposes.

Version 3 of XACML states its aims to be

To provide a method for combining individual rules and policies into a

single policy set that applies to a particular decision request

To provide a method for flexible definition of the procedure by which

rules and policies are combined

To provide a method for dealing with multiple subjects acting in different

capacities

To provide a method for basing an authorisation decision on attributes of

the subject and resource

To provide a method for dealing with multi-valued attributes

To provide a method for basing an authorisation decision on the contents

of an information resource

To provide a set of logical and mathematical operators on attributes of the

subject, resource and environment

To provide a method for handling a distributed set of policy components,

while abstracting the method for locating, retrieving and authenticating the

policy components

To provide a method for rapidly identifying the policy that applies to a

given action, based upon the values of attributes of the subjects, resource

and action

To provide an abstraction-layer that insulates the policy-writer from the

details of the application environment

To provide a method for specifying a set of actions that must be performed

in conjunction with policy enforcement

In addition to the features listed above, XACML 2.0 has various profiles (e.g., DSIG

profile, hierarchical profile, multiple profile, privacy profile, RBAC profile, SAML

profile) to express certain policies. Note that the work on Privacy RBAC (P-RBAC)

offers a similar privacy aware access control extension, however, there is no

implementation released yet.


118

D.1 XACML: Data Flow and Language Models

XACML is an access control language, standardised by OASIS. It aims to define

which entity can access what, under what conditions and for what purpose. To support

this goal, XACML provides policy, request and response languages, combining

algorithms and models for both data flows and languages. Figures 47 and 48 are

extracted from [17].

Data Flow Model

XACML‟s data flow model is shown in Figure 47, and the steps are listed below the

figure. Acronyms and XACML terminology used in this section are defined in [17].

Figure 47: Data Flow Model

1. PAPs write policies and policy sets and make them available to the PDP.

These policies or policy sets represent the complete policy for a specified

target.

2. The access requester sends a request for access to the PEP.


119

3. The PEP sends the request for access to the context handler in its native

request format, optionally including attributes of the subjects, resource, action

and environment.

4. The context handler constructs an XACML request context and sends it to the

PDP.

5. The PDP requests any additional subject, resource, action and environment

attributes from the context handler.

6. The context handler requests the attributes from a PIP.

7. The PIP obtains the requested attributes.

8. The PIP returns the requested attributes to the context handler. Optionally, the

context handler includes the resource in the context.

9. The context handler sends the requested attributes and (optionally) the

resource to the PDP. The PDP evaluates the policy.

10. The PDP returns the response context (including the authorization decision) to

the context handler.

11. The context handler translates the response context to the native response

format of the PEP. The context handler returns the response to the PEP

12. The PEP fulfills the obligations. (Not shown: If access is permitted, then the

PEP permits access to the resource; otherwise, it denies access.)

This data flow model can also be leveraged and extended by the EnCoRe architecture

to meet its need, in particular in terms of refining its components into an

implementable prototype. This is particularly true for the Privacy-aware Policy

Enforcement component.

A common problem is that both the Context Handler and the PIP may need to access

external attributes and their values (which in this context might be personal data)

which may create concerns in terms of privacy management. Our approach ensures

that no PII data is disclosed to these components, but rather references to this data are

used.

XACML Language Model

The XACML language model contains three core components: rule, policy, and

policy set. A rule is the most elementary unit of policy. Rules can only be exchanged

between actors when embedded in the policy. A PAP combines rules in a policy.

Each policy contains target, rule combining algorithms, a set of rules and obligations.

A policy set, similarly, contains target, policy combining algorithms, a set of policies

and obligations.


120

Figure 48: Language Model

Limitations

XACML was designed for representing access control policies and providing a

reference framework for their enforcement. Its major focus is on security policies,

although privacy is mentioned in the 2.0 specification. It is verbose and complex.

Interactions involving PAP, PIP, PEP, etc. are not standardised. Another concern is

that policy administration, policy versioning, etc. are also not standardised yet.

Another remark on XACML is that it lacks reasoning ability with regards to privacy

constraints on protected data which, if not addressed by EnCoRe, may limit the

applicability of the XACML framework. Specifically XACML shows limitations

when its rules need to be extended to return “conditional results/conditional Yes” [9]:

these include complexity in aggregating the outcomes of the evaluation of multiple

rules within a policy. In the current version of EnCoRe architecture and policies we

adopt the simplification of using just one rule per policy, which addresses the above

limitation but introduces proliferation of policies.

D.2 Examples of XACML policies

A few examples of XACML policies are given below, using the healthcare database

example given in Figure 4 of Section 5.


121

Request example

A natural language request to access protected resources can look like: “Dave requests

to read information contained in Table T1, Medical Record Data Repository”

The corresponding XACML format request follows:

<?xml version="1.0" encoding="UTF-8"?>

<Request

xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os xacml-2.0-context.xsd">

<Subject>

<Attribute

AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"

DataType="http://www.w3.org/2001/XMLSchema#string">

<AttributeValue>Dave</AttributeValue>

</Attribute>

</Subject>

<Resource>

<Attribute

AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"


<AttributeValue>Medical Record Data Repository</AttributeValue>

</Attribute>

<Attribute



<AttributeValue>T1</AttributeValue>

</Attribute>

</Resource>

<Action>

<Attribute

AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"


<AttributeValue>read</AttributeValue>

</Attribute>

</Action>

<Environment/>

</Request>

Access control policy example

A natural language policy can look like: “Dave can read and write Table T1 in

Medical Record Data Repository and must fulfil the obligation that he notifies the

corresponding patient by email.”

The corresponding XACML format policy follows:


<Policy

xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"


xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:os

http://www.w3.org/2001/XMLSchema-instance

http://www.w3.org/2001/XMLSchema#string






122

context-schema-os.xsd"

PolicyId="urn:oasis:names:tc:xacml:2.0:conformance-test:IIA1:policy"

RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

<Description>

Policy for EnCoRe.

</Description>

<Target/>

<Rule

RuleId="urn:oasis:names:tc:xacml:2.0:conformance-test:IIA1:rule"

Effect="Permit">

<Description>

Dave can read and write Table T1 in Medical Record Data Repository and must fulfil the

obligation that he notifies the corresponding patient by email.

</Description>

<Target>

<Subjects>

<Subject>

<SubjectMatch

MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">

<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">Dave</AttributeValue>

<SubjectAttributeDesignator


DataType="http://www.w3.org/2001/XMLSchema#string"/>

</SubjectMatch>

</Subject>

</Subjects>

<Resources>

<Resource>

<ResourceMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">Medical Record Data

Repository</AttributeValue>

<ResourceAttributeDesignator



</ResourceMatch>

<ResourceMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">T1</AttributeValue>




</ResourceMatch>

</Resource>

</Resources>

<Actions>

<Action>

<ActionMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>

<ActionAttributeDesignator



</ActionMatch>










123

</Action>

<Action>

<ActionMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">write</AttributeValue>




</ActionMatch>

</Action>

</Actions>

</Target>

</Rule>

<Obligations>

<Obligation ObligationId="urn:oasis:names:tc:xacml:example:obligation:email"

FulfillOn="Permit">

<AttributeAssignment

AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:mailto"


Method to retrieve patient’s email address

</AttributeAssignment>


AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:text"


Your medical record has been accessed by:









</Obligation>

</Obligations>

</Policy>

D.3 Matching Process

The PEP component receives the access request and forwards it to the context

handler. The context handler sends the request to the PDP and obtains required

attributes from the environment, if any. The PDP makes a decision and sends back the

decision together with the associated obligations, if any. The PEP receives the

decision from the context handler and enforces it along with ensuring that also the

obligations are enforced.








124

Analysis

As anticipated in this section, XACML cannot return a "Conditional Yes", an

important requirement when dealing with privacy policy enforcement, as argued in

[11].

If there are late-binding conditions (i.e., not enforced by the PDP) that should be

enforced at the time of accessing the protected resource (e.g., T1), XACML has no

obvious mechanism to express them in the policy language.

EnCoRe explored possible approaches to address this issue. The remaining part of this

section discusses possible solutions, along with their pros and cons.

Solution 1 - User obligation part in XACML:

One option to include the conditional constraints (of the “Conditional Yes”) will be to

embed them in the user obligation part of XACML policies. However, the main

concern is that it violates the semantic and commonly accepted understanding about

what obligations are. In other words, we would treat access control constraints as

obligation constraints. This would be incorrect, as different enforcement mechanisms

are involved.

Solution 2 - Use a customised version of the PDP engine

A customised PDP engine can insert conditions into the Status Message which will be

included in the PDP decision and the PEP will enforce the conditions first before

fulfilling the obligations. This approach is limited as it only allows the usage of

policies with one rule. Furthermore, no rule combination algorithm is allowed.

An example using this approach follows:


<Response xmlns:ns0="http://www.w3.org/2001/XMLSchema-instance"

ns0:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os http://docs.oasis-

open.org/xacml/2.0/access_control-xacml-2.0-context-schema-os.xsd"

xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os">

<Result>

<Decision>Permit</Decision>

<Status>

<StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>

<StatusMessage>Conditions go here...</StatusMessage>

</Status>

<Obligations xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os">

<Obligation FulfillOn="Permit"

ObligationId="urn:oasis:names:tc:xacml:example:obligation:email">




SQL query goes here... :) hahaha!




http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-context-schema-os.xsd

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-context-schema-os.xsd



125












</Obligation>

</Obligations>

</Result>

</Response>

Solution 3 - Use customised XACML schema

XACML provides an XML schema file to validate XACML policies and requests. In

order to return “Conditional Yes” and any other possible responses/requests, the

ultimate solution is to create a customised XACML schema to enable the capability of

parsing/processing EnCoRe specific policies. However, this implies that we can not

re-use current XACML engines and a standard XACML schema. This solution also

suffers from the same constraint that a customised rule combination algorithm is

required to handle “Conditional Yes”.

Solution 4 - Use the description element provided by XACML schema

XACML provides an element called Description (whose data type is String) to allow

policy administrators to describe the policy. It is accessible by the PDP.

This is the approach considered by EnCoRe.

The feasibility of this approach as been demonstrated by building a prototype that

shows how “late-binding” conditions (to be used in case of “conditional yes”

outcomes) can be explicitly expressed and handled by PDP to provide access control

responses.

The example is listed below.


<Policy

xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os"


xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:policy:schema:os

context-schema-os.xsd"

PolicyId="urn:oasis:names:tc:xacml:2.0:conformance-test:IIA1:policy"

RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">

<Description>

Dave can read and write Table T1 in Medical Record Data Repository with certain conditions

and must fulfil the obligation that he notifies the corresponding patient by email. </Description>

<Target/>

<Rule






126

RuleId="urn:oasis:names:tc:xacml:2.0:conformance-test:IIA1:rule"

Effect="Permit">

<Description>

<specific EnCoRe conditions>

conditions go here!

</specific EnCoRe conditions> </Description>

<Target>

<Subjects>

<Subject>

<SubjectMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">Dave</AttributeValue>




</SubjectMatch>

</Subject>

</Subjects>

<Resources>

<Resource>

<ResourceMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">Medical Record Data

Repository</AttributeValue>




</ResourceMatch>

<ResourceMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">T1</AttributeValue>




</ResourceMatch>

</Resource>

</Resources>

<Actions>

<Action>

<ActionMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>




</ActionMatch>

<ActionMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">Research</AttributeValue>











127


AttributeId="urn:oasis:names:tc:xacml:1.0:action:purpose"


</ActionMatch>

</Action>

<Action>

<ActionMatch


<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">write</AttributeValue>




</ActionMatch>

</Action>

</Actions>

</Target>

</Rule>

<Obligations>

<Obligation ObligationId="urn:oasis:names:tc:xacml:example:obligation:email"

FulfillOn="Permit">




Method to retrieve patient’s email address














</Obligation>

</Obligations>

</Policy>









128

Appendix E: Related Work

Existing policy specification, modelling and verification tools include EPAL [16],

OASIS XACML [17], W3C P3P [18, 19] and Ponder [20]. However, these do not

include explicit modelling of the concepts of consent and revocation. The concept of

privacy and the notion of consent has been explored in the context of a taxonomy

[21]. Mechanisms for implementation of consent from an HCI point of view have

been considered in [22, 24], and should be built upon within our solution.

A technical solution for sticky policies and tracing services is introduced in [14] that

leverages Identifier-Based Encryption (IBE) and trusted technologies. This solution

requires enforcement for third-party tracing and auditing parties. One drawback of

this approach is that data are bound to the policy itself, which makes data heavy-

weighted and potentially not compatible to current information systems. However, its

traceability function can be treated as the start point of consent and revocation. An

alternative solution to bind privacy preferences to data, and to convey the consent of

the individual as well, has been proposed by Pöhls in [26, 27]. The solution relies on

a Merkle hash tree [28] whose leaves are the tuples <data item, privacy preferences>.

The root of the tree is signed by the individual to indicate his consent for each data

item to be handled as specified by the associated preferences. This solution permits

individuals to anticipate future aggregation by giving their consent in advance.

Revocation of consent is managed with existing solutions [29, 30] used in X.509

public key infrastructure. However, as explained in [26, 27], the solution does not

avoid the non-consented use of data.

A unified policy model is discussed in [25], which discusses steps towards privacy

management for organisations or across organisations within a federated identity

management environment. A coherent entry point was proposed to enable consumers

to easily review and manipulate stored personal information, which may in turn

provide improved control over suspension and resumption of individuals‟ personal

data. This method is elegant but its potential application to consent and revocation

needs to be further studied.

A Platform for Enterprise Privacy Practices (E-P3P) is discussed in [8]. It separates

the enterprise-specific deployment policy from the privacy policy and facilitates the

privacy-enabled management and exchange of customer data. The authors also

proposed the E-P3P language to formalise privacy policies. The authors claimed that

the proposed method might possibly be extended to multiple enterprises, though such

scenario is not discussed. This research effort further led to the Enterprise Privacy

Authorization Language (EPAL) [16]. IBM [25] introduced a unified policy model

towards privacy management in an organisation or between organisations within a

federal identity management environment. The authors proposed a coherent entry

point at web sites, enabling consumers to easily review and manipulate stored

personal data. This scheme provided improved control over suspension and

resumption of individuals‟ personal data, though limited enterprise scenarios were

discussed. Its potential application to consent and revocation needs to be further

studied.


129

A data handling policy is introduced in [23] to define how the personal information

should be dealt with at the receiving end. The authors also proposed a DHP language

to enable the building of customised policies. This method was

developed/implemented in the framework of the PRIME project [24] although the

management of revocation is not explicitly addressed. PRIME aimed to develop a

working prototype of a privacy-enhancing identity management system. Its purpose

was to foster market adoption of novel solutions for managing identities, as

demonstrated in real-world scenarios. A systematic approach is proposed [31]

including an anonymous credential system, an access control system, negotiation

functionality, and an automated reasoning system, to serve both individuals and

service providers needs in order to implement the EU Directives 95/46/EC and

2002/58/EC in PRIME. Within this architecture, Christer Andersson et al. [32]

discussed the socio-psychological factors and HCI aspects that influence the

individuals‟ trust in privacy-enhancing identity management, and demonstrated that

HCI research, user studies, and socio-psychological research are indispensable steps

in privacy system design.

The usability research work that has been done within the first year of PRIME is

summarised in [33]; three UI paradigms - role-centred, relationship-centred and town

map-based - for privacy-enhanced identity management are discussed. Our suggested

model and approach for EnCoRe is consistent and compliant with PRIME outcomes,

but it extends them by explicitly suggesting how to handle consent and revocation,

along with their lifecycle. We currently have technologies and working prototypes to

animate aspects of the model we illustrated in Section 5. However, we believe that the

management of consent and revocation in enterprises is an important, open issue that

requires research and further understanding of the involved problems. This is work in

progress: we will carry out further R&D work in this space within the EnCoRe

project. There is also scope to build upon other technological ideas, including trusted

computing [15] to provide a basis for trust and automated checking of policies that

can translated into natural language clauses [12].

EnCoRe Project Deliverable - HP Labs Project Deliverable ... Model allowing assignment of...

Documents

Transcript of EnCoRe Project Deliverable - HP Labs Project Deliverable ... Model allowing assignment of...