Siani Pearson
email: siani.pearson@hp.com

Privacy Management and Accountability in Global Organisations

Keywords: Accountability, compliance, data protection, privacy, risk, security Privacy, Data Protection and Security

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

Introduction

This paper focuses on 'good willing' organisations that wish to meet, and even exceed, legal privacy and data protection requirements. It considers some of the challenges that they face, best practice today in addressing these challenges and points to examples of cutting edge thinking that may shape future corporate privacy governance.

It is outside the scope of this paper to consider economic incentives for privacyfriendly organisational behaviour and different organisational attitudes towards investment in privacy enhancing mechanisms and privacy-related risk (see for instance [START_REF]The Privacy Dividend: The Business Case for Investing in Proactive Privacy Protection[END_REF]), the tension between data minimisation and the value and usage of personal data for organisations (for example, for marketing purposes) and related discussions including issues of market forces leading to erosion of moral standards within an entrepreneurial system (as described for example in [START_REF] Tressell | The Ragged Trousered Philanthropists[END_REF]) countered to a greater or lesser extent by national regulatory standards, consumer pressure and other mechanisms [START_REF] Bennett | The Governance of Privacy: Policy Instruments in Global Perspective[END_REF]. Instead, the focus will be on how organisations can satisfy regulatory requirements and provide good data stewardship.

The structure of the paper is as follows: Section 2 considers how privacy requirements are challenging for global organisations, Section 3 describes central aspects and options for privacy governance within organisations, Section 4 shows how accountability forms part of the solutions needed and Section 5 discusses two particular examples of accountability-based privacy management solutions currently being developed or refined by the author. Finally, conclusions are given.

At the broadest level (and particularly from a European standpoint), privacy is a fundamental human right, enshrined in the United Nations Universal Declaration of Human Rights (1948) and subsequently in the European Convention on Human Rights and national constitutions and charters of rights. There are various forms of privacy, ranging from 'the right to be let alone' [START_REF] Warren | The Right to Privacy[END_REF], 'control of information about ourselves' [START_REF] Westin | Privacy and Freedom[END_REF], 'the rights and obligations of individuals and organisations with respect to the collection, use, disclosure, and retention of personally identifiable information' [START_REF]CICA: Generally Accepted Privacy Principles[END_REF], focus on the harms that arise from privacy violations [START_REF] Solove | A Taxonomy of Privacy[END_REF] and contextual integrity [START_REF] Nissenbaum | Privacy as Contextual Integrity[END_REF].

For further discussion about the nature of privacy, see for example [START_REF] Bennett | The Governance of Privacy: Policy Instruments in Global Perspective[END_REF].

In the commercial, consumer context, privacy entails the protection and appropriate use of the personal information of customers, and the meeting of expectations of customers about its use (which may be reflected as informed consent or within private contracts). What is appropriate will depend on the applicable laws, individuals' expectations about the collection, use and disclosure of their personal information and other contextual information.

Data protection is the management of personal information, and is often used within the European Union (EU) in relation to privacy-related laws and regulations, although in the United States (US) the usage of this term is focussed more on security.

The terms 'personal information' and 'personal data' are commonly used within Europe and Asia, whereas in the US the term 'Personally Identifiable Information' (PII) is normally used, but they are generally used to refer to the same concept. This can be defined as information that can be traced to a particular individual, and include such items as: name, address, phone number, social security or national identity number, credit card number, email address, passwords, date of birth. Some personal data elements are considered more sensitive than others, although the definition of what is considered sensitive personal information varies depending upon jurisdiction and even on particular regulations.

Privacy differs from security, in that it relates to handling mechanisms for personal information, although security is one element of that. Security mechanisms, on the other hand, focus on provision of protection mechanisms that include authentication, access controls, availability, confidentiality, integrity, retention, storage, backup, incident response and recovery. Privacy relates to personal information only, whereas security and confidentiality can relate to all information.

2.2

Organisational Privacy Obligations

We have seen that for organisations, privacy entails the application of laws, policies, standards and processes by which personal information is managed. The fair information practices developed in the US in 1970s [START_REF]Privacy Protection Study Commission: Personal Privacy in an Information Society, United Statues Privacy Protection Study Commission Fair Information Practices[END_REF] and later adopted and declared as principles by the Organisation for Economic Co-operation and Development (OECD) and the Council of Europe [START_REF]OECD): Guidelines for the Protection of Personal Data and Transborder Data Flows[END_REF] form the basis for most data protection and privacy laws around the world. These principles are shown in Table 1. This framework can enable sharing of personal information across participating jurisdictions without the need for individual contracts. It imposes requirements on organisations including data collection, subject access rights and data flow restrictions.

Principle Description Collection limitation

There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.

Data quality

Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.

Purpose specification

The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.

Use limitation

Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with the above except: a) with the consent of the data subject; or b) by the authority of law.

Security safeguards

Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.

Openness

There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.

Individual participation

Individuals should have the right: a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to them; b) to have communicated to them, data relating to them i. within a reasonable time;

ii. at a charge, if any, that is not excessive; iii. in a reasonable manner; and iv. in a form that is readily intelligible to them; c) to be given reasons if a request made under (a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to them and, if the challenge is successful to have the data erased, rectified, completed or amended.

Accountability

A data controller should be accountable for complying with measures which give effect to the principles stated above.

The collection and processing of personal information is subject to regulation in many countries across the world. Figure 1 illustrates how many different countries have national data protection legislation in place. The US does not have a comprehensive regime of data protection but instead has a variety of laws targeted at the protection of particularly sensitive types of information that tend to be sector-based or enacted at the state level. This (sometimes inconsistent) matrix of national laws can make it really hard for businesses to ensure full compliance if they are operating in multiple jurisdictions. Hence there is pressure from organisations for greater global interoperability to be achieved via development of a clear and consistent framework of data protection rules that can be applied, in order to reduce unnecessary administrative burdens and risks. Transborder flow of personal information, including access to this information, is restricted by some of these laws. For example, the European Data Protection Directive 95/46/EC [START_REF] Warren | The Right to Privacy[END_REF] (and its supporting country legislation) is an important piece of privacy legislation that restricts the movement of data from EU to non-EU countries that do not meet the EU 'adequacy' standard for privacy protection. Legislation similar to the European Data Protection Directive has been, and continues to be, enacted in many other countries, including Australia, New Zealand, Hong Kong, Japan and Asia-Pacific Economic Cooperation (APEC). In practice contractual mechanisms like Binding Corporate Rules or Model Contracts might need to be put in place in order to allow data access. However, these arrangements typically take several months to set up, and hence are not well suited to dynamic environments. Hence the OECD revised guidelines [START_REF]OECD: Guidelines Concerning the Protection of Privacy and Transborder Flows of Personal Data[END_REF] now recommend the practical implementation of privacy protection through an approach grounded in risk management and stress the need for improved global interoperability.

With regard to security, it is a common requirement under data protection law that if a company outsources the handling of personal data to another company, it has some responsibility to make sure the outsourcer uses "reasonable security" to protect those data. This means that any organisation creating, maintaining, using or disseminating records of personal data must ensure that the records have not been tampered with, and must take precautions to prevent misuse of the information.

Of course, in addition, organisations need to take into account the privacy-related expectations of their customers, which may be specified within private contracts, and this is likely to involve a combination of process-based and access control mechanisms. The legal obligations vary according to the regulatory context and indeed there are likely to be some quite significant changes in the near future. Problems with the 1995 EU Data Protection Directive [START_REF] Warren | The Right to Privacy[END_REF] as a harmonisation measure and in relation to new technologies including cloud computing have led the European Commission (EC) in January 2012 to publish a draft of replacement General Data Protection Regulation [START_REF] Westin | Privacy and Freedom[END_REF] that is currently being discussed and revised, in which accountability features and privacy by design take greater precedence. Amongst other things, this imposes new obligations and liabilities for data processors, new requirements on data breach notification and stricter rules on international data transfers. It also empowers National Regulatory authorities to impose significantly higher fines. In addition, a European Cloud Computing Strategy [START_REF]European Commission, Unleashing the Potential of Cloud Computing in Europe[END_REF] has been launched aiming at more clarity and knowledge about the applicable legal framework and making it easier to verify compliance with the legal framework (e.g. through standards and certification). Furthermore, in February 2013 the European Commission published a cybersecurity strategy [START_REF]Cybersecurity Strategy of the European Union: An Open, Safe and Secure Cyberspace[END_REF] alongside a draft directive on network and information security [START_REF]European Commission, Directive on Network and Information Security[END_REF]. Once implemented, many service providers will be covered by a range of data security obligations including adopting risk management practices and reporting major security incidents.

Privacy Risks and Challenges

Privacy challenges for businesses include data breaches, risk of litigation due to country-specific laws, the complexity of managing privacy and negative public attention and loss of brand value if exposures occur. Data breaches can be costly -on average 204 US dollars per record, according to a 2010 Ponemon Institute study. When cus-tomers are concerned for the welfare of their privacy, it can affect a company's ability to do business. This concern may arise for example due to worries about unsolicited marketing, identity theft, surveillance or unwanted inferences about behavior. Privacy issues depend upon the role of the company. For example, an organisation could be a custodian of employee personal data, could collect end-user personal information, or could just be providing outsourcing services for another organisation. Legally, the requirements are quite different depending upon whether the organisation is a data controller or a data processor in that situation (although it might be both).

A data controller is an entity which alone or jointly with others determines the purposes for which and the manner in which any item of personal information is processed. It could be a person, public authority, agency or other body and is legally responsible for ensuring compliance requirements are met. Obligations and risks of the data controller include: regulatory fines, criminal liability, civil liability if data subjects enforce their rights, investment risk, business continuity impact and reputational damage. In environments such as cloud computing, a data controller has a responsibility to ensure that the service providers are meeting regulatory obligations and this can be challenging [START_REF] Pearson | Privacy, Security and Trust in Cloud Computing[END_REF].

A data processor is an entity which processes personal information on behalf and upon instructions of the data controller. Contractual agreements may add additional responsibilities or constraints with respect to privacy, although data protection laws stipulate that the organisation that is transferring personal information to a third party for processing remains responsible for the personal information. The data processor may also face issues such as lack of training of key personnel and deliberate targeting of sensitive information by criminals.

When considering privacy risks, context is an important aspect, as different information can have different privacy, security and confidentiality requirements and privacy threats differ according to the type of scenario: for example, they would tend to be higher for services that are dynamically personalised, based on people's location, preferences, calendar and social networks, etc. Privacy need be taken into account only if a service handles personal information, in the sense of collecting, transferring, processing, sharing, accessing or storing it. Even if the same information is involved, there may be different data protection requirements in different contexts, due to factors including location and trust in the entities collecting and processing it. There are special laws concerning treatment of sensitive data, and data leakage and loss of privacy are of particular concern to users when sensitive data is processed. In addition, privacy issues vary across different stages of the information lifecycle, e.g. data collection, processing, storage, archival and destruction. Some companies might choose to ignore the issue and pay the penalties if they are found to be in breach, but at the time of writing, regulations, enforcement activities and sanctions are currently increasing the world over.

Privacy risks and concerns are increasing, not least due to the recent revelations about the extent of government surveillance [START_REF] Guardian | NSA Prism program taps in to user data of Apple, Google and others[END_REF] and to the rapid rise in big data analysis [START_REF] Barabási | Scientists must spearhead ethical use of big data[END_REF]. Correspondingly there is a need to push compliance and reduce risks throughout organisations, including to untrained people that might expose hundreds of files by the click of a button, lose a laptop containing unencrypted confidential infor-mation or switch sensitive information to the cloud almost instantly using a credit card. However, requirements can be complex to ascertain and a privacy staff is typically small, making effective oversight over hundreds or possibly thousands of projects per year difficult. Hence the role of both process and technology is important. This is considered further in the following section.

Corporate Governance for Privacy

In this section it is briefly explained how privacy governance may be achieved within an organisation.

The Role of Corporate Governance

Companies differ in the resources they have available to deal with privacy. Many larger organisations have a Chief Privacy Officer and privacy staff in order to implement compliance in their organisations. Smaller organisations often do not have the resources for hiring qualified privacy experts and instead the person appointed who is responsible for overseeing the organisation's compliance with applicable privacy legislation could well be the owner or operator. Key elements of privacy management such as defining a corporate privacy policy can often be difficult to achieve in such situations. However, small companies are largely domestically bound, and hence driven by domestic legislation, except in the case for certain small companies in niche areas that might quickly become multinational. For multinational companies, requirements are more diverse and privacy management is more difficult. Nevertheless, data is an asset, so proper privacy management will be valuable for forward-thinking companies, quite apart from being mandatory from a legal point of view. Privacy management programmes serve as the core operational mechanism through which organisations implement privacy protection. In addition, a related element that needs to be in place within an organisation is data security breach notification, which may require both notice to an authority and notice to an individual affected by a security breach affecting personal data.

Key elements of a successful privacy programme include:

garnering senior management support and establishing a comprehensive organisational privacy policy establishing clear processes and assign responsibilities to individuals using proven, existing standard and frameworks for security and IT management establishing proper monitoring and audit practices, in order to verify and assess what is happening in the organisation against the privacy policies, and take action where required to achieve alignment More specifically, a privacy management program would ideally include the following measures [START_REF]Office of the Information and Privacy Commissioner of Alberta[END_REF]:

1. establishing reporting mechanisms and reflecting these within the organisation's privacy management program controls 2. putting in place privacy management program controls, namely:

a Personal Information Inventory to allow the organisation to identify the personal information in its custody, its sensitivity and the organisation's authority for its collection, usage and disclosure policies relating to: collection, use and disclosure of personal information (including requirements for consent and notification); access to and correction of personal information; retention and disposal of personal information; privacy requirements for third parties that handle personal information; security controls and role-based access; handling complaints by individuals about the organisation's personal information handling practices risk assessment mechanisms training and education breach and incident management procedures for informing individuals about their privacy rights and the organisation's program controls 3. developing an oversight and review plan that describes how the organisation's program controls will be monitored and assessed 4. carrying out ongoing assessment and revision of the program controls above

Privacy by Design

Privacy by Design refers to the philosophy and approach of embedding privacy into design specifications, as first espoused by Ann Cavoukian and others [START_REF] Cavoukian | Privacy by Design: Origins, Meaning, and Prospects for Assuring Privacy and Trust in the Information Era[END_REF][START_REF][END_REF]. It applies to products, services and business processes. The main elements are: 1. recognising that privacy concerns must be addressed 2. applying basic principles expressing universal spheres of privacy protection 3. mitigating privacy concerns when developing information technologies and systems, across the entire information life cycle 4. integration of qualified privacy input 5. adopting and integrating privacy-enhancing technologies (PETs) [START_REF] Shen | Privacy Enhancing Technologies: A Review[END_REF] In essence, companies should build in privacy protections at every stage in developing products, and these should include reasonable security for consumer data, limited collection and retention of that data, as well as reasonable procedures to promote data accuracy. Various companies have produced detailed privacy design guidelines (see for example [START_REF]Microsoft Corporation: Privacy Guidelines for Developing Software Products and Services[END_REF]). In addition to the Canadian regulators, there has been strong emphasis and encouragement from Federal Trade Commission (FTC) and EC amongst others on usage of a privacy by design approach [25,[START_REF]Protecting Consumer Privacy in an Age of Rapid Change: Recommendations for Business and PolicyMakers[END_REF].

'Privacy by policy' is the standard current means of protecting privacy rights through laws and organisational privacy policies, which must be enforced. Privacy by policy mechanisms focus on provision of notice, choice, security safeguards, access and accountability (via audits and privacy policy management technology). Often, mechanisms are required to obtain and record consent. The 'privacy by policy' approach is central to the current legislative approach, although there is another approach to privacy protection, which is 'privacy by architecture' [START_REF] Spiekermann | Engineering privacy[END_REF], which relies on technology to provide anonymity. Unfortunately, the latter is often viewed as too expensive or restrictive. Although in privacy by policy the elements can more easily be broken down, it is possible (and preferable) to enhance that approach to cover a hybrid approach with privacy by architecture.

In summary, perfection is not reachable in a complex and moving global context, but companies are expected to think upfront about the impact and the risk they create, and privacy by design has a strong role to play in helping organisations balance innovation with the expectations of individuals. In addition, both regulators and individuals expect organisations to act as a responsible steward of the data which is provided to them, and the way in which companies need to do more to live up to their promises and ensure responsible behaviour is considered in the following section. In particular, corporate governance plays a central role in providing accountability within an organisation, by means of the organisation identifying risks, having appropriate policies that mitigate risks, mechanisms for enforcement internally and for monitoring that these are effective within the enterprise, and for internal and external validation of this. In addition, provision of transparency can help enforce privacy obligations along the service provision chain.

Accountability

In this section the role of accountability is explained, in the sense of being an essential aspect of privacy governance. Furthermore, a model of accountability is presented and it is explained how organisations can be accountable. Accountability is a broader notion than just data protection and privacy, but the scope of discussion within this section is largely restricted to that domain as this is the area of interest for this paper.

What is Accountability?

Accountability is a notion of which there is no universally agreed definition, although it is generally agreed that responsibility, transparency and holding to account are key elements. It is a complex notion that is used in a slightly different sense in different domains. For example, in computer science it is often used to refer to formal verification, compliance and privacy and security policy enforcement; in information security, accountability is meant to generate assurance, transparency and responsibility in support of control and trust; from a corporate governance perspective accountability is an organisational privacy management program and from a social, legal and ethical perspective the emphasis is often on holding organisations and actors accountable for their actions.

In data protection regulation, as we have seen in Section 2, accountability is normally about complying with measures that give effect to practices articulated in given guidelines. For example, a data controller is responsible for complying with particular data protection legislation and, in most cases, is required to establish systems and processes which aim at ensuring such compliance. Indeed, the notion of accountability appears in several international privacy frameworks in addition to the OECD Privacy Guidelines (1980) already considered above, including Canada's PIPEDA (Personal Information Protection and Electronic Documents Act) (2000), APEC Privacy Framework (2005), Article 29 Working Party papers [28] and some elements of the draft European Data Protection Regulation (although in that case not directly associated with the word 'accountability' largely for reasons of translatability) [25]. The usage of this notion by regulators is evolving towards an 'end-to-end' personal data stewardship regime in which the enterprise that collects the data from the data subject is accountable for how the data is shared and used from the time it is collected until when the data is destroyed. This extends to onward transfer to and from third parties.

Building on such analysis, a definition of accountability that is applicable across different domains and that captures a shared multidisciplinary understanding is [START_REF]MS:C-2.2, Internal Project Report, A4Cloud project[END_REF]:

Accountability consists of defining governance to comply in a responsible manner with internal and external criteria, ensuring implementation of appropriate actions, explaining and justifying those actions and remedying any failure to act properly.

Internal criteria are not necessarily visible to stakeholders external to that organisation, as they might for example reflect the risk appetite of that organisation or known security vulnerabilities; external criteria could include best practice on security, data protection and breach notification, as well as privacy regulatory and contractual requirements and societal expectations.

Although it is a complex notion, it could be argued that its core, accountability is a very simple idea. It says that not only should an organisation do everything necessary to exercise good stewardship of the data under its control, it should also be able to demonstrate that it is doing so. Good stewardship is achieved by designing systems appropriately, so that they reflect privacy principles and security expectations from partners, regulators and data subjects, as well as by the organisation living up to its promises and ensuring responsible behaviour. The demonstration -via provision of an account -is an essential aspect, but can be challenging to provide. Furthermore, if events do not work out as planned, organisations need to provide a means of remediation as well as needing to try to prevent such an occurrence happening again. These elements are captured in Figure 2, which shows how accountability should complement the usage of appropriate privacy and security controls in order to support democratically determined principles that reflect societal norms, regulations and stakeholder expectations. Governance and oversight of this process is achieved via a combination of Data Protection Authorities, auditors and Data Protection Officers within organisations, potentially supplemented by private Accountability Agents acting on their behalf.

Fig. 2. Accountability context

At its core, in the sense that a data controller should be accountable for complying with measures which give effect to principles that have been set within a democratic context, and that they will be held to account in case of failure, as well as the provision of tools to help organisations to 'do the right thing' (including for better remediation, breach notification, etc.), accountability is obviously a good thing and not very controversial. However, there are a number of different and even conflicting opinions related to additional (or even alternative) potential features of an accountability-based approach. In the main these relate to how accountability can help address the issue of the lack of take up of privacy by design by organisations to date, the role of accountability in moving towards greater regulatory interoperability, the importance of measures that prevent privacy harm and the extent to which punishment for a privacy violation should be lessened by evidence that appropriate privacy and security measures have been taken by an organisation. The former can be done in particular by easing transborder data flow constraints and regulatory complexity in favour of a single set of organisational requirements that need to be adhered to that could apply globally (as is the case with Binding Corporate Rules for instance [START_REF]Information Commissioner's Office (ICO): Binding Corporate Rules[END_REF]), allowing differentiation in terms of privacy (so long as legal requirements are met), being less prescriptive in terms of the specification of regulatory requirements, encouraging (or even mandating) usage of privacy impact assessments to guide design and also of course increasing punishment in cases of non-compliance as well as taking into account the controls an organisation has used when determining punishment. Opinions about the relative merits of these approaches differ. In addition, Weitzner views accountability as retrospective (arguing that a shift is needed from hiding information to ensuring that only appropriate uses occur) [START_REF] Weitzner | Information accountability[END_REF] whereas preventive risk identification and mitigation is viewed as an essential element of accountability by others [START_REF]CIPL): Data protection accountability: the essential elements[END_REF][START_REF]Office of the Information and Privacy Commissioner of Alberta[END_REF].

It is often regarded as underpinning an accountability-based approach that organisations should be allowed greater control over the practical aspects of compliance with data protection obligations in return for an additional obligation to prove that they have put privacy principles into effect (see for example [START_REF]CIPL): Data protection accountability: the essential elements[END_REF]). Hence, that whole approach relies on the accuracy of the demonstration itself. If that is weakened into a mere tickbox exercise, weak self certification and/or connivance with an accountability agent that is not properly checking what the organisation is actually doing, then the overall affect could in some cases be very harmful in terms of privacy protection. As Bennett points out [33: p45], due to resource issues regulators will need to rely upon surrogates, including private sector agents, to be agents of accountability, and it is important within this process that they are able to have a strong influence over the acceptability of different third party accountability mechanisms. This can be achieved via independent testing of practices, provision of evidence that is taken into account, including auditing against the ISO 27001 series and associated security standards.

Hence, the way in which accountability is achieved is key, which includes the need for adequate resources in checking and enforcing whether organisations are indeed using appropriate measures, involvement of different stakeholders, including the public (or representatives of the public) in data privacy regulation, provision of suitable accountability tools and help for organisations to form appropriate risk assessment mechanisms and policies. In the next two sections the type of measures are elucidated that are needed as part of such an approach.

A Model of Accountability

In Figure 3 a model of accountability is presented that shows how accountability can be captured at different layers of abstraction. The top layer of the triangle shown in Figure 3 corresponds to the definition of accountability, as given in the previous subsection. Moving down the model in terms of becoming less abstract, the other layers correspond in turn to the following aspects: Accountability attributes. These are the central taxonomic components of accountability, namely: observabililty, verifiability, attributability, transparency, responsibility, liability and remediability. Further details are given in [START_REF] Catteddu | Towards a Model of Accountability for Cloud Computing Services[END_REF].

Accountability practices. These define the central behavior of an organisation adopting an accountability-based approach. From the definition given above, it can be seen that these are: defining governance, ensuring implementation of appropriate actions, explaining and justifying those actions and remedying any failure to act properly. These map to the Galway project's 'essential elements' of accountability [START_REF]CIPL): Data protection accountability: the essential elements[END_REF]. Further details are given in the following section.

Accountability mechanisms and tools. These tools and mechanisms offer enhanced accountability; organisations in addition will need to use privacy and security controls appropriate to the context, as described in the previous subsection. The tools may form a toolbox from which organisations can select as appropriate. They can be (extensions of) existing business processes like auditing, risk assessment and the provision of a trustworthy account, or non-technical mechanisms like formation of appropriate organisational policies, remediation procedures in complex environments, contracts, certification procedures, and so on. Or they can be technical tools, which would include tracking and transparency tools, detection of violation of policy obligations, notification of policy violation, increased transparency without compromising privacy, and so on. The tools are targetted at different stakeholders, and some are designed for usage as a preventive measure (for example, to assess and reduce privacy harm before personal data is collected), some as a detective measure (for example, to assess the degree to which privacy obligations are actually being met) and others as a corrective measure (for example, to facilitate redress).

How can Organisations be Accountable?

This subsection provides more detail about the third layer of the model above, namely how to be accountable. An accountable organisation must commit to responsible stewardship of other people's data, which in brief entails that it must define what should be done, monitor how it is done, remedy any discrepancies between definition and fact, and explain and justify relevant actions. We now consider these aspects further below. First and foremost, an accountable organisation must demonstrate willingness and capacity to be responsible and answerable for its data practices with regard to personal data. Analogously, the same applies more broadly with regard to confidential data that may or may not be personal data -for example, business secrets, although that takes us out of the remit of privacy concerns and hence we do not say too much more about that in this paper.

In order to achieve this, senior management support for an accountability-based culture within the organization must be obtained and a reporting structure set up with responsibilities allocated to individuals, as discussed already in Section 3.1. In addition, an accountable organisation must address the following four central aspects:

1. define and deploy policies regarding their data practices that link to relevant external criteria and are supported by senior management. The policies include specification of the entities involved in the processing of data and their respon-sibilities; the scope and context of processing data; the purposes and means of processing and data handling and data access policies. The policies need to take account of relevant external legal obligations. In addition, policies need to be defined related to risk monitoring and risk mitigation. Mechanisms are also needed in order to put these policies in place, including risk assessment and means to make uses transparent to individuals and to assure that their rights are respected. 2. monitor their data practices: this includes how they process data, evidence that the organisation has acted according to its policies, and a running account that is a record of the monitoring and its results. In particular, periodic internal reviews are needed to provide assurance that the mechanisms are working and improve over time. 3. correct policy violations: this includes both the effects of the violation that need to be addressed, as well as causes of the violation that need to be addressed, and the informing of appropriate stakeholders, who include authorities, customers and affected data subjects. The effects of the violation could involve errors that need to be corrected and damages that need to be compensated, financially or otherwise. 4. demonstrate policy compliance: policy violations need to be reported and compliance with policies needs to be demonstrated in a timely fashion, reactively and where possible, proactively. The organisation must demonstrate that the controls selected and used within the service provision chain are appropriate for the context and should provide evidence that the operational environment is indeed satisfying the policies. There must be openness to oversigh by enforcement agencies, together with remediation if the goals of data protection have been abused in a harmful fashion.

So far, this analysis corresponds in a general way to that given within the Accountability Project [START_REF]CIPL): Data protection accountability: the essential elements[END_REF] and other opinions influenced by that [START_REF]Office of the Information and Privacy Commissioner of Alberta[END_REF]. But in addition, two other important aspects need to be emphasised.

First, accountable organisations must ensure that accountability extends through across their service supply chains, in other words ensuring that the services and partners they use are accountable too, which involves amonst other things proper allocation of responsibilities and provision of evidence about satisfaction of obligations along the service provision chain.

Second, there are implications in terms of the way that the enforcement and verification mechanisms for accountability will operate, the scope of risk assessment and the ways in which other stakeholders are able to hold an organisation to account.

Two Example Solutions

Solutions to the above issues could take a number of forms. As considered above, there is a wealth of different privacy and security controls that an organisation could choose to use.

Risk assessment (a core security process) is particularly important for accountability because it is a central part of the process used to determine and demonstrate that the policies (whether reflected in corporate privacy and security policies or in contractual obligations) that are signed up to and implemented by the organisation (that is taking an accountability-based approach) are appropriate to the context. The type of procedures and mechanisms vary according to the risks represented by the processing and the nature of the data [START_REF] Pearson | Privacy, Security and Trust in Cloud Computing[END_REF].

We now consider further two particular solutions for privacy management and accountability within global organisations, namely HP Privacy Advisor, which is a type of privacy risk assessment system, and a range of solutions being developed within the EU Cloud Accountability project. The latter includes further research to provide risk assessment mechanisms in relation to cloud service provision.

HP Privacy Advisor

Existing organisational risk assessment processes need to be enhanced to meet the requirements above, or else supplemented with separate privacy-specific risk assessment [START_REF]Privacy Impact Assessment and Risk Management[END_REF]. Privacy impact assessments are already being rolled out as part of a process to encourage privacy by design [START_REF]Privacy Impact Assessment and Risk Management[END_REF]: in November 2007 the UK Information Commissioners Office (ICO) (an organisation responsible for regulating and enforcing access to and use of personal information), launched a Privacy Impact Assessment (PIA) [START_REF]Privacy Impact Assessment and Risk Management[END_REF] process (incorporating privacy by design) to help organisations assess the impact of their operations on personal privacy. This process assesses the privacy requirements of new and existing systems; it is primarily intended for use in public sector risk management, but is increasingly seen to be of value to private sector businesses that process personal data. Similar methodologies exist and can have legal status in Australia, Canada and the US [START_REF]Privacy Impact Assessment and Risk Management[END_REF]. The methodology aims to combat the slow take-up to design in privacy protections from first principles at the enterprise level. Usage is increasingly being encouraged and even mandated in certain circumstances by regulators [START_REF]Privacy Impact Assessment and Risk Management[END_REF]. Data impact assessment may also become an obligation for some high risk contexts within the forthcoming EU regulation [cf. Article 33: 25].

As we have considered in Section 4, accountability, as articulated by the Article 29 Working Party [28], begins to shift our thinking from only having an obligation to comply with a principle, to an obligation to prove that you can put those principles into effect. Technology can assist organisations in ensuring proper implementation. New laws and regulations are increasingly having explicit requirements that an organisation not only comply, but that they have programs that put the principles into effect. Hence companies will need to do more to ensure that privacy is indeed considered in their products and services.

HP Privacy Advisor (HP PA) is an intelligent online rule-driven system that assesses activities that handle personal data within HP and provides privacy by design guidance. It is a web-based decision support system used internally within HP to assess risk and degree of compliance for projects that handle personal data and to guide individual employees in their decisions on how to handle different types of data. HP PA elicits privacy-relevant information about a project via a customised sequence of questions. It uses a dynamic interface to minimise unnecessary questions and maintains a record of activities.

As shown in Figure 4, based on the answers given, HP PA:

-Assesses a project's degree of compliance with corporate privacy policy, ethics and global legislation, and the privacy promises the company makes -Integrates privacy risk assessment, education, and guidance into the process -Scores projects for a list of ten privacy compliance indicators including transborder data flows, compliance, business controls, security, transparency, and so forth -Generates tailored privacy design guidance or a tailored compliance report for each project and, if appropriate, notifies an appropriate member of the corporate privacy team for further guidance/intervention -Provides checklists, reminders, customised help and warnings to users -Maintains a record of activities for audit purposes. HP PA is a standard three tier web application using Java Enterprise Technology, where the client is a standard web browser, the application tier is a standard Java application server, and the persistence layer is a standard relational database. An accurate representation of organisational privacy policies is provided that encodes HP's 300 plus page privacy policies. HP PA uses JBoss Drools 5, a forward chaining rules engine both for validating the users' responses against a set of privacy rules, and to dynamically tailor the user experience using a questionnaire generated by a set of questionnaire rules. Desirable system properties are ensured such as deterministic behaviour of questionnaire and report generation, tailoring, and completeness of the questionnaire generation. For further information about this system, see [START_REF] Pearson | A Decision Support System for Privacy Compliance[END_REF].

EU Cloud Accountability Project

As data moves to the cloud, new risks and vulnerabilities arise and in addition there are concerns over data security, integrity and privacy due in particular to reduced transparency and less control. As a result, organisations are reluctant to let data flow outside the organisations' boundaries into the cloud, and in addition individuals have concerns over privacy and their relative lack of control. Cloud computing creates new dynamics in that there is an additional role of cloud provider, and indeed there could be several such parties. This not only can cause legal uncertainty in certain cases, but there is more general a need for clarification of distributed privacy and security responsibilities and control. Privacy is a difficult issue to tackle, because of the underlying complexity across multiple dimensions and the interdisciplinary nature of the problem. For example, location matters from a legal point of view and there are restrictions about how information can be sent and accessed across boundaries as briefly discussed in Section 2 above, but in cloud computing data can flow along chains of service providers both horizontally between softwareas-a-service providers and vertically, down to infrastructure providers, where the information can be fragmented and duplicated across databases in different jurisdictions. Furthermore, the cloud model can magnify existing issues (such as transborder flow, data deletion, loss of control and transparency) and new vulnerabilities are also possible (such as security attacks exploiting the vulnerabilities of virtualisation mechanisms). The risks, as well as responsibilities, will vary according to the combination of cloud service and deployment models. Correspondingly, security and privacy requirements will vary widely from one use case to the next. Within a cloud ecosystem, issues from one cloud service provider (CSP) may have ramifications further up the chain, for example in terms of loss of governance. Loss of governance may arise in cloud computing for example as the client cedes control to the CSP, but service level agreements may not offer commitment to provide such services on the part of the CSP, thus giving a gap in security. For further discussion of privacy risks in the cloud, see [START_REF] Pearson | Privacy, Security and Trust in Cloud Computing[END_REF].

The overall goal of the EU Cloud Accountability project [START_REF]EU Cloud Accountability project[END_REF] is to develop and validate techniques for implementing accountable cloud ecosystems. This includes development of techniques that can enable improved trustworthiness of cloud service provision networks, and to prevent breaches of trust by using audited policy enforcement techniques, assessing the potential impact of policy violations, detecting violations, managing incidents and obtaining redress. The outputs of the project include an accountability framework (including recommendations, guidance, models of data governance, accountability metrics and a reference architecture) as well as a range of accountability tools and mechanisms. These are being developed for organisations using cloud services as well as cloud service providers, regulators and data subjects.

The focus of the project is on personal data, but in addition certain types of confidential information that may not involve personal data, such as business secrets, are being considered. The focus is particularly on the accountability of organisations using and providing cloud services to data subjects and regulators. Government surveillance, including government acquisition of data from cloud service providers, is outside the scope of this project, except where it relates specifically to a data protection law accountability mechanism: no accountability controls of the types considered in the project (which are based upon assisting compliance with domestic data protec-tion legislation and private contracts) are likely to provide effective protection against such activities.

The overall approach is as follows. The legal and contractual context defines obligations, responsibilities and liabilities of actors in a given cloud ecosystem. Businesses need to meet these obligations and mitigate risk and uncertainty in dynamic and global environments. This is a challenging problem especially where service provision chains are complex. Actors within cloud ecosystems may select mechanisms and tools to support accountability practices, and thereby help them to comply with relevant regulatory regimes within specific application domains. Overall, the project aims to move beyond a tick-box culture by providing organisations with the appropriate support to take an accountability-based ethical approach and make that a business advantage.

Conclusions

Privacy for companies is about managing privacy requirements end-to-end. Technical point solutions, such as encryption and auditing tools, are vitally important, but often address only a small part of overall privacy concerns. Although a number of different privacy-enhancing technologies are available, privacy requirements for global organisations can still be challenging to properly address. The way that business environments are changing means that more automation (including much greater adoption of anonymisation techniques and encryption governed by consumers where possible) is needed in order to protect privacy online [START_REF] Mowbray | Protecting Personal Information in Cloud Computing[END_REF]. The challenge is how to move towards this model, including extension of that beyond the 'good willing' enterprises to others who are not necessarily willing to invest in governance practice that lessens privacy risks. Transparency, responsibility, privacy impact assessment and assurance -key aspects of accountability -are an important part of such a solution.

New technologies and business models can bring a higher risk to data privacy and security. For example, there can be rapid scaling (through subcontracting), remote data storage, and the sharing of services in a dynamic environment. This is a key user concern, especially for sensitive information like financial and health data. In global and dynamic environments especially, the associated lack of consumer trust -whether from individuals or Chief Information Officers in large organisations -can act as a barrier to business, and lack of regulator trust is resulting in increased penalties for non-compliance right across the world at present. The necessary increased trust can come from improved transparency and sound stewardship of information by service providers for which they are held accountable. Ongoing development of complementary solutions in the area of privacy by design and accountability is needed. Some examples of such an approach have been given in this paper.

Fig. 1 .

 1 Fig. 1. Global data protection laws

Fig. 3 .

 3 Fig. 3. Conceptual model of accountability

Fig. 4 .

 4 Fig. 4. Functional overview of HP Privacy Advisor

Table 1 .

 1 OECD privacy principles

Acknowledgements. The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement no: 317550 (A4Cloud). In particular, acknowledgement is given to Daniel Pradelles for assistance in creating Figure 1 (which gives a rough indication of the situation in 2012 and should not be regarded as completely accurate for all countries) and input from other members of Work Package C2 within the Cloud Accountability Project in collectively forming the accountability model discussed in Section 4.


Jan Camenisch

Concepts Around Privacy-Preserving Attribute-Based Credentials

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

Introduction

The Internet has transformed our environment and how we interact with each other dramatically. Soon all things surrounding us will be part of the Internet, producing, processing, providing, and consuming enormous amounts of data. It seems impossible to protect all devices and systems, virtually or physically. Therefore secure authorisation and communication and protecting stored data are of vital importance. To this end, it is necessary to authenticate and encrypt every single bit as well as explicitly define who is allowed to do what with the bit, i.e., to attach a data-usage policy to each bit. However, authenticating every bit communicated will most probably decrease users' privacy substantially and, more generally, the security of the overall system.

To alleviate this, privacy-preserving authentication mechanisms, in particular attribute-based authentication together with anonymous credentials, should be applied. Unfortunately, today they are not employed in practice. One reason for this might be the complexity of privacy-preserving authentication mechanisms due to the large numbers of features they provide. Also, the security properties, such as unlinkability, of privacy-preserving authentication mechanisms are often counterintuitive. To address this, the ABC4Trust project [START_REF]ABC4Trust -Attribute-based Credentials for Trust[END_REF] has put forth a number of concepts that capture, simplify, and unify the properties of privacypreserving authentication technologies. These concepts aim to make these authentication technologies easier to understand, deploy, and use. The ABC4Trust project also runs two pilots to show the applicability of these technologies in real-world scenarios [START_REF]ABC4Trust -Attribute-based Credentials for Trust[END_REF][START_REF] Stamatiou | Privacy Respecting ICT Innovation in Education: Electronic Course Evaluation in Higher Education and Beyond[END_REF].

In this article we summarise and explain these concepts. To this end, we first discuss the basic authentication scenario and the entities involved. Then we discuss each of the concepts. Next, we describe the realisation of these concept in the ABC4Trust architecture and the reference implementation. Finally, we conclude with a discussion on obstacles that need to be overcome in order for privacy-preserving authentication to be used practice.

The basic entities of a privacy-protecting authentication system with attributebased credentials (privacy-ABC system) include a user, an issuer (often called identity provider), and a verifier (often called relying party). These entities essentially occur in any authentication scenario, in particular also if authentication is performed with X.509 certificates or the OpenID protocol. The remaining two entities are the revocation authority and the inspector. The former also occurs in traditional certificate-based authentication systems, whereas the latter is a specialty of privacy-preserving authentication. All these entities are depicted in Figure 1. In a real deployment, there are further entities involved, for instance the providers of the computing platforms, different software components, and a public key infrastructure, etc. In this article, however, we do not consider such entities as they are not particular to privacy-ABC systems. These parties each perform a number of tasks and interact with each other to make the authentication system work. First, to initiate the overall system, each issuer generates a secret issuance key and publishes the issuer parameters that include the corresponding public verification key. Similarly, each inspector generates a private decryption key and a corresponding public encryption key, and each revocation authority generates and publishes its revocation authority parameters. It is assumed that all entities have a means to retrieve the public keys of the issuers, revocation authorities, inspectors, and verifiers, e.g., by using some form of public key infrastructure.

Most parties interact with each other, as can be seen from Figure 1, where these interactions are depicted and named according to their purpose. Now, depending on which (privacy-preserving) authentication technology is used, these interactions might be realised differently and consist of only a single flow or an interactive protocol. Also the time at which they occur depends on the technology used.

The first interaction, the credential issuance protocol, allows a user to obtain credentials from an issuer. A credential contains attributes that its issuer vouches for with respect to the user. A credential can also specify one or more revocation authorities who are able to revoke the credential if necessary for some reason. To issue a credential that is revocable, the user and/or the issuer might need to interact with the revocation authority prior to or during the issuance protocol. Using her credentials, a user can form a presentation token that contains a subset of the certified attributes, provided that the corresponding credentials have not been revoked. This process does not require the user to interact with the issuer! However, the user might need to retrieve information from the revocation authority, depending on the specific revocation scheme used. Additionally, some of the attributes can be encoded in the presentation token so that they can only be retrieved by an inspector. The user can attach inspection grounds specifying under which conditions the inspector should reveal these attributes. Upon receipt of a presentation token from a user, a verifier checks whether the presentation token is valid with respect to the relevant issuers' public keys, the inspectors' public keys, and the latest revocation information (thus, the verifier will interact with the revocation authority). If the verification succeeds, the verifier will be convinced that the attributes contained in the presentation token are vouched for by the corresponding issuers. Finally, if a presentation token contains attributes that can only be retrieved by an inspector and the inspection grounds are met, the verifier can forward the token to the inspector who will then follows the instructions defined in the inspection grounds, e.g., to reveal the attribute to a designated party.

Informally, a secure realisation of a privacy-ABC system guarantees (1) that users can only generate a valid presentation token if they were indeed issued the corresponding credentials that have not been revoked, (2) that attributes encoded in the presentation token for an inspector can indeed be retrieved by that inspector, and (3) that the presentation tokens do not reveal any further information about the users other than the attributes contained in them.

Concepts

In this section we provide a brief explanation of the main features of privacy-ABCs. We start by explaining what we mean by an identity as all the concepts are based on this view of identity. We then discuss the concepts underlying the authentication and authorisation with a privacy-ABC system.

Attributes and Identities

For the purpose of this exposition, we consider an identity to consist of the attributes that another party knows linkable a user, say Alice. Figure 2 shows Fig. 2. An identity is a collection of attributes someone knows about. Shown here are some of Alice's identities [START_REF] Camenisch | Electronic Identities need Private Credentials[END_REF][START_REF] Leenes | PRIME White Paper -third and final version[END_REF]. some identities that Alice has with some parties. For instance, she has an identity with her employer comprising her full name, salary, address, education, and the languages she speaks. Her identity with an on-line shop may comprise her name, address, credit card number, and purchase history. Her identity with an on-line forum may comprise a nickname and her hobbies. There might of course be many other people who have a similar or the same identity as Alice with some party, i.e., the set of attributes that the party knows about Alice is the same as the set of attributes the party knows of another person, say Jim. Thus, the party can per se not distinguish whether it is communicating with Jim or Alice. Often parties ensure that this does not happen by requiring some attributes to be unique, e.g., by requiring users to provide different nick names. Nevertheless, we do not want to rule out that different users can have the same identity with the same party or with different parties. Now, for this concept of identities is to be useful, we require two basic mechanisms: one that allows a user to authenticate as the owner of an identity and one that allows a user to transfer an attribute from one identity to another identity, i.e., to let the latter learn an attribute that the former entity knows and vouches for.

These mechanisms shall protect the privacy of the user, i.e., the parties with which the user has established these identities shall not be able to link themunless this is implied by the uniqueness of an attribute value or a set of attribute values.

While we consider an identity to be a set of attributes that someone knows about a user, the same set of attributes can be different identities. That is, a party might know the same set of attribute values about two different users and indeed should consider these to be different entities. Similarly, two parties who know a single or two users by the same set of attribute values, should consider these as different identities. Here the concept of the authentication mechanism becomes especially useful. If the specific authentication parameters (e.g., public key or pseudonym value) associated with different sets of attribute values are identical, then the identity should considered to be the same. Also, a user can link different identities of hers together using the authentication mechanism by either using the same authentication parameters with the different identities or, preferably, by using specific properties of the authentication mechanism to prove that she is the holder of both identities. We discuss such mechanisms next.

Pseudonyms

To authenticate as the owner of an identity, a user can establish a (cryptographic) pseudonym with a party. Technically, a pseudonyms is essentially a public key of a cryptographic identification scheme. However, different from a traditional cryptographic identification scheme where there is a single secret key and public key pair, here an unlimited number of pseudonyms (public keys) can be derived from the same secret key. Pseudonyms are unlinkable, i.e., a party cannot tell whether two given pseudonyms correspond to different secret keys. While technically, a user can also have different secret keys, it is instructive to consider each secret key to define a separate user -very much like a real-world passport defines a person's identity.

In some situations, however, the possibility to generate an unlimited number of unlinkable pseudonyms is undesirable. For instance, a verifier might want to allow only one account per user. To still support privacy in such cases, ABC technologies allow scope-exclusive pseudonyms. Such pseudonyms are generate from the secret key and a scope identifier (string) and are unique per scope for a given user secret key. Nevertheless, scope-exclusive pseudonyms for different scopes remain unlinkable.

Credentials

A credential is a set of attributes that is (digitally) signed by an issuer. While in principle an issuer could first generate a credential and then send it to the user, e.g., by email, privacy-ABCs typically require an interactive issuance protocols to realise the enhanced privacy properties to ensure that the issuer does not learn the secret key of the user and, for some special applications, to allow the user to keep some of the attributes hidden from the issuer. An example of such a special application is one-show credential: here the user encodes a random attribute in the credential that is hidden during issuance but is require to be revealed during presentation.

The validity of a credential can be verified with regard to the issuer parameters published by the issuer and a credential specification. The latter defines the semantic of a credential such as what attribute types the credential contains. While the issuer parameters are specific for each issuer, a credential specification can be shared by many issuers. The credential specification further defines whether a credential is revocable and/or bound to a key of the user. We discuss these two features next.

Binding Credentials to Keys

When a credential specification requires that a credential be key bound, the issuance protocol will require the user to input a secret key to which the credential will be issued without the issuer learning any information about the secret key.

A key-bound credential can only be presented with knowledge of the secret key. Per se, the secret key can be any secret of the user's choice. However, for some applications, it might make sense to restrict the user in this choice. To this end, the issuer can specify in the issuance policy that the credential be bound to the same key as some other credential(s) or to the secret key underlying some particular pseudonym that the user has sent to the issuer earlier. For instance, to enforce that all of a user's credentials be bound to the same secret key, one could require each user to register with some root authority from which a user would get a key-bound (root) credential. Later, whenever some issuer issues a credential to a user, he would specify that the credentials issued be key-bound to the same key as a root credential.

Revocation of Credentials

There might be many reasons why a credential should be revoked. A user might have lost the right that the credential attested to her or her secret key and all her credentials were compromised. In this case, the issuer(s) of the credential(s) concerned must be able to invalidate them. For ordinary credentials, this is typically done by some whitelist or blacklist containing the serial numbers to the valid or invalid credentials, respectively, or by letting credentials be valid for only a short time. The latter works for privacy-ABC as well, whereas the former does not as it would require users to reveal the serial number of their credential and thus all privacy would be lost again. Fortunately, the cryptographic literature provides several mechanisms that allow users to convince a verifier that the serial number of their credential is on a whitelist or not on a blacklist. These mechanisms all have in common that the issuer publishes some public revocation information which both users and verifiers should consult. Some mechanisms further require that users be able to retrieve specific information related to their credential so that they will be able to perform the proof of validity of their credential. We refer to this as issuer-driven revocation.

Sometimes, however, a credential might not need to be revoked globally but rather some verifier might want to stop accepting a credential from a specific user. For example, a hooligan may see his digital identity card revoked for accessing sport stadiums, but may still use it for all other purposes. The specification therefore also allows for verifier-driven revocation Here, verifiers can specify their own lists and have users prove to them whether or not they figure on such a list.

The ABC4Trust specifications define revocation very generically and just define a revocation authority who manages and publishes the revocation information. The only difference between issuer-driven and verifier-driven revocation is that the former is performed based on the revocation handle (which is treated as a dedicated attribute), whereas the latter can be performed based on any attribute value or even a combination of values, possibly even from different credentials.

Presentation Policy and Presentation Token

The probably most important difference between privacy-ABCs and ordinary credentials is how a user authenticates to a verifier with them. In an ordinary PKI, the user sends her credentials (thereby revealing all attribute values!) to the verifier and authenticates as the holder of the credentials. The verifier then verifies the validity of the credentials and whether or not the attributes contained therein match his access control requirements.

A privacy-ABC system is much more privacy friendly than such traditional approaches. It first requires the verifier to specify which attributes certified by whom it requires from the user. We call this statement the presentation policy. In fact, the policy allows an even more privacy-friendly option. Instead of requiring a user to reveal an attribute, the verifier could request only a predicate over an attribute such as "over 18" instead of "reveal birthdate" or just ask that the last name in one credential be the same as in another credential without having to reveal the value of the last name. It can further be specified that a user also send a pseudonym and authenticate with regard to it. A presentation policy further allows one to restrict verifiers in what attributes they learn, e.g., by requiring that policies be signed by a data protection authority.

In a second step, once the user has received the presentation policy from the verifier, the user can decide whether she wants to reveal this information to the verifier, and if so, which credentials she wants to use (in case multiple credentials apply) provided she possesses all necessary credentials. If not, the user will have to somehow get the missing credentials issued. To support the user in these tasks, ABC4Trust provides a graphical user interface (identity selector) showing the user the different choices. Once the user has made her choices, she creates a presentation token from the credentials she selected. A presentation token can be seen as a transformed (set of) credential(s) that contains only the attributes from the original credential(s) that the user wishes to reveal. Cryptographically, a presentation token verifies with regard to the signature verification keys of original credentials' issuers, just like the original credentials themselves.

Inspectable Presentation Tokens

In some situation, the information required from a user changes depending on the behaviour of the user. So, while it might be fine that a user can access some service by convincing the service provider that she has obtained a subscription credential, it might be necessary that additional information be available in case of abuse. To address such scenarios, a presentation policy can state that certain attributes need to be provided in encrypted form, encrypted under the public key of a designated party -the inspector. That is, the verifier will not be privy to inspectable attributes unless he forwards the presentation token to the designated inspector and the inspection grounds stated in the presentation policy are met. An inspection ground is a free format text that cannot be modified and that the inspector is expected read and comply with before handing the decrypted attributes to the verifier.

Issuance of Credentials

As mentioned, a credential is issued in a protocol between the user and the issuer. Issuing a credential is in some sense just a special case of providing a service and so an issuer might require a user to present a number of credentials issued by other parties or to authenticate with regard to a pseudonym beforehand. While in many cases, the issuer might know all the attributes values of the issued credential, that is not always necessary and sometimes even undesirable. Therefore, ABC4Trust an advanced issuance protocol that allows the issuer to "carry over" attribute values from credentials that a user already possesses into the credential that gets issued without the values getting revealed. To enable this technically, the presentation policy is extended into an issuance policy, and accordingly the user will generate an issuance token.

Realisation

The concepts discussed in the preceding section can be implemented with a number of cryptographic schemes and algorithms, such as credential systems, group signatures, blind signatures, and verifiable encryption. More precisely, a full-fledged privacy-ABC system that realises all the concepts can be built from signature schemes with special properties (e.g., Camenisch-Lyskanskaya signatures [START_REF] Camenisch | An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation[END_REF][START_REF] Camenisch | A Signature Scheme with Efficient Protocols[END_REF][START_REF] Camenisch | Signature Schemes and Anonymous Credentials from Bilinear Maps[END_REF] and Brands signatures [START_REF] Brands | Rethinking Public Key Infrastructure and Digital Certificates -Building in Privacy[END_REF]), commitment schemes, verifiable encryption schemes [START_REF] Camenisch | Practical Verifiable Encryption and Decryption of Discrete Logarithms[END_REF], and generalised Schnorr proofs [START_REF] Camenisch | On the Portability of Generalized Schnorr Proofs[END_REF].

As the combined cryptographic protocols get quite complex and therefore hard to use, the ABC4Trust project developed a policy language to deal with these concepts and to orchestrate the cryptographic protocols. The ABC4Trust privacy-ABC system thus can be used merely by understanding the concepts and not having to worry about the underlying cryptography. More precisely, the architecture provides XML schemas for all artefacts, including issuer parameters, revocation authority parameters, inspector parameters, credential specification, issuance policies and tokens, presentation policies and tokens, and pseudonyms [START_REF] Camenisch | D2.1 Architecture for Attribute-based Credential Technologies -Version 1[END_REF]. The architecture further defines the components of a privacy-ABC system and their interfaces. The (main) components of the user and the verifier are depicted in Figure 3.

The architecture has three layers: an application layer, a policy layer and a crypto engine layer.

The application layer is the consumer of the privacy-ABC system, it could be a browser on the user's side and a web service on the verifier's side. The application layer interacts with the policy layer by means of the APIs provided and is responsible for exchanging policies and tokens between the parties. How this is done is outside of the scope of the ABC4Trust architecture. On the user's side the application layer is also responsible for the presenting the presentation (and issuance) policy to the user and for allowing her to make her choices.

The policy layer processes presentation and issuance policies, matches credentials against policies and tokens against polices (policy credential matcher and policy token matcher), and orchestrates the generation and verification of presentation and issuance tokens (evidence generation orchestration and evidence verification orchestration). The policy layer is also responsible for storing a user's credential and tokens that a verifier receives (store) and for managing the credentials and tokens (credential manager and token manager). The latter includes dealing with revocation information and updating the credentials accordingly.

The crypto engine layer implements the cryptographic operation of privacy-ABCs. It contains the u-Prove and the IBM identity mixer (idemix) signature schemes (Sig), the idemix verifiable encryption (Enc) and revocation schemes, pseudonyms, commitment schemes (Com), and various cryptographic mechanisms to prove and verify attribute predicates, including zero-knowledge proof protocols (ZKP). The forthcoming ABC4Trust crypto architecture will describe this in detail. In the mean time, the reader is referred to the identity mixer specifications [START_REF] Bichsel | Mixing Identities with Ease[END_REF][START_REF]Specification of the Identity Mixer Cryptographic Library -Version 2[END_REF], which can be seen as a preliminary versions of this architecture.

The reference implementation of ABC4Trust encompasses all components of the policy and crypto layer, the identity selector, as well as an example application. The reference implementation is available from the GitHub repository [START_REF]Privacy-preserving attribute-based credential engine (p2abcengine[END_REF] (and the sites linked from there).

We believe that privacy-ABCs should be the default technology to be used to implement any form of access control and that they will be as essential for a secure Internet just as there would be no e-commerce without SSL (Secure Socket Layer). The technology per se is ready for this. Indeed, the ABC4Trust project is currently conducting two pilots that, on the one hand, validate the architecture and the reference implantation and, on the other hand, show that privacy-ABC technology is ready to be used in practice. Also, a number of other research groups have successfully run pilots and demonstrator showing that the technology is ready for deployment. A number of obstacles, however, remain to be overcome before the privacy-ABCs will be in widespread use.

First of all, privacy-ABCs are more complex than ordinary attribute-based credentials, and their features are somewhat counterintuitive. This makes them challenging to deploy and use. To address this, the complexity of these technologies needs to be reduced and their possibilities communicated to the various stakeholders.

Furthermore, to enable the use of privacy-ABCs, the different cryptographic mechanisms and the policy languages need to be standardised. The architecture of ABC4Trust is a step towards this goal.

The obstacle that is probably the most difficult to overcome is the design of intuitive user interfaces for privacy-ABCs. A few approaches have been proposed, but for all of them it seems that users were not able to clearly understand what information they will reveal to verifiers (see, e.g., [START_REF] Wästlund | The Users' Mental Models' Effect on their Comprehension of Anonymous Credentials. Privacy and Identity Management for Life[END_REF]).

Finally, the speed with which the Internet evolves and new applications are introduced and embraced makes it very challenging to address the emerging security and privacy problem, in particular because privacy and security too often are not taken into consideration by design. Thus, without privacy becoming a mandatory design principle, privacy technology will not be used as it is always easier to build applications without addressing security and privacy. Fortunately, the general public is becoming increasingly aware of the need of proper security and privacy protection and we have reason hope that future applications will only succeed when taking this into account.

Fig. 1 .

 1 Fig. 1. Entities and the interactions between them [4].

Fig. 3 .

 3 Fig. 3. ABC4Trust architecture, partial view on user and verifier [4, 6].

Acknowledgements

The author enjoyed many discussions with his IBM colleagues and the people participating in the ABC4Trust project. The paper benefitted a lot from the comments by the reviewers. Thank you! This work was supported by the ECfunded project ABC4Trust.