prime consortium

Contract N° 507591

Copyright © 2006 by the PRIME consortium – All rights reserved.

The PRIME project receives research funding from the Community’s Sixth Framework Programme and the Swiss Federal Office for Education and Science.

File name: pub_del_D4.2.a_pt_wp04.2_V4Final-0.doc

1 2 3 4

Title: Evaluation of initial Application Prototypes 5

Author: Work Package 4.2 6

Editor: Pete Bramhall (Hewlett-Packard) 7

Reviewers: Hilko Donker (TUD) 8

Peter Keller (Swisscom) 9

Identifier: D4.2.a 10

Type: Deliverable 11

Version: 4 12

Date: 10 March 2006 13

Status: Final 14

Class: Public 15

Summary 16 17 This deliverable contains the evaluation of the initial application prototypes - eLearning, Airport 18 Security Controls and Location Based Services. The evaluation takes account of the following 19 viewpoints: Human-Computer Interface (HCI), assurance, legal, economics and social/cultural 20 aspects. It also includes evaluations by the application prototypes’ developers of the suitability of 21 the PRIME Integrated Prototype V1 as the basis for their identity management functions. 22

PRIME D4.2.a Privacy and Identity Management for Europe

Public Final Version 4, dated 10 March 2006

Members of the PRIME consortium: International Business Machines of Belgium Belgium IBM Zürich Research Laboratory Switzerland Unabhängiges Landeszentrum für Datenschutz Germany Technische Universität Dresden Germany Deutsche Lufthansa AG Germany Katholieke Universiteit Leuven Belgium T-Mobile International Germany Hewlett-Packard Ltd. United Kingdom Karlstads Universitet Sweden Università degli Studi di Milano Italy Joint Research Centre Italy Centre National de la Recherche Scientifique France Johann Wolfgang Goethe-Universität Frankfurt am Main Germany Chaum LLC United States of America Rheinisch-Westfälische Technische Hochschule Aachen Germany Institut EURECOM France Erasmus Universiteit Rotterdam The Netherlands Universiteit van Tilburg The Netherlands Fondazione Centro San Raffaele del Monte Tabor Italy Swisscom AG Switzerland

Published PRIME documents These documents are all available from the project website located at http://www.prime-project.eu.org

Excerpt of project “Description of work” 03-2004 Project presentation 09-2004 Overview of existing assurance methods 09-2004 Evaluation of early prototypes 12-2004 HCI guidance and proposals 02-2005 Framework Version 1 03-2005 Requirements Version 1 05-2005 White Paper Version 1 07-2005 Tutorials Version 1 06-2005 Architecture Version 1 08-2005



The PRIME Deliverable Series

Vision and Objectives of PRIME Information technologies are becoming pervasive and powerful to the point that the privacy of citizens is now at risk. In the Information Society, individuals need to be able to keep their autonomy and to retain control over their personal information, irrespective of their activities. The widening gap between this vision and current practices on electronic information networks undermines individuals' trust and threatens critical domains like mobility, healthcare, and the exercise of democracy. The goal of PRIME is to close this gap.

PRIME develops the PRIME Framework to integrate all technical and non-technical aspects of privacy-enhancing identity management and to show how privacy-enhancing technologies can indeed close this gap. PRIME elicits the detailed requirements from legal, social, economic, and application points of view and shows how they can be addressed. PRIME will enable the users to effectively control their private sphere thanks to the PRIME Architecture that orchestrates the different privacy-enhancing technologies, including the human-computer interface. To validate its results, PRIME develops prototypes and conducts experiments with end-users in specific application areas.

PRIME advances the state of the art far beyond the objectives of the existing initiatives to address foundational technology, through PRIME research on human-computer interface, ontologies, authorisation and cryptology, anonymous communications, and privacy-enhancing identity management systems architecture and assurance methods, taking into account legacy and emerging systems.

PRIME raises awareness of privacy-enhancing identity management through its white paper and tutorials, as well as press releases, leaflets, slide presentations, and scientific publications. The following PRIME materials are available from http://www.prime-project.eu.org:

Introduction to PRIME • Press releases, leaflets, and slide presentations outline the project objectives, approach, and expected

results; • The PRIME White Paper introduces privacy-enhancing identity management issues and PRIME's

vision, solutions, and strategy; • Tutorials introduce major concepts of privacy-enhancing identity management for use by the

software development community and the general public.

PRIME technical materials • PRIME Framework reviews privacy-enhancing identity management issues, PRIME legal, social,

and economic requirements, PRIME concepts and models, and PRIME architecture outline; • PRIME Requirements analyses in-depth the legal, social, economic, and application requirements.

They comprise generic requirements, as well as specific, scenario-based requirements of selected application areas including eLearning, location-based services, and airport security controls.

• PRIME Architecture describes in-depth the organisation and orchestration of the different privacy-enhancing technologies in a coherent PRIME system;

• Annual research reports review the research results gained in PRIME over the past years, and the research agenda for the subsequent years;

• HCI Guidance provides a comprehensive analysis of the Human-Computer Interface requirements and solutions for privacy-enhancing identity management;

• Assurance methods surveys the existing assurance methods that are relevant to privacy-enhancing identity management;

• Evaluation of prototypes assesses the series of early PRIME technology prototypes from the legal, social, and economic standpoints;

• Scientific publications address all PRIME-related fields produced within the scope of the project.

PRIME work plan PRIME global work plan provides an excerpt of the contract with the European Commission.



Foreword This document is the result of work done by many PRIME participants to evaluate the initial application prototypes and document the results. The HCI evaluation sections of this report were created by Camilla Carlander of Karlstads Universitet. The assurance evaluation sections of this report were created by Tobias Scherner of Johann Wolfgang Goethe-Universität Frankfurt am Main. The legal evaluation sections of this report were created by Michaël Vanfleteren of Katholieke Universiteit Leuven. The economic evaluation sections of this report were created by Jimmy Tseng, Peter van Baalen, Ruud Smit, Cesar Castrat, Federico Puccioni, Petros Cheretakis and Raymond Tsai of Erasmus Universiteit Rotterdam. The social/cultural evaluation sections of this report were created by Ronald Leenes and Marcel Hoogwout of Universiteit van Tilburg. The ICPP Privacy Seal sections of this report were created by Henry Krasemann and Thomas Probst of the Schleswig-Holstein Unabhängiges Landeszentrum für Datenschutz. The section that evaluates the PRIME Integrated Prototype V1 from the viewpoint of the eLearning application prototype was created by Katrin Borcea-Pfitzmann of Technische Universität Dresden. The section that evaluates the PRIME Integrated Prototype V1 from the viewpoint of the Airport Security Controls application prototype was created by Neil Mitchison and Ioannis Vakalis of the Joint Research Centre and Jean-Marie Willigens of Deutsche Lufthansa AG. The section that evaluates the PRIME Integrated Prototype V1 from the viewpoint of the Location Based Services application prototype was created by Mike Radmacher and Jan Zibuschka of Johann Wolfgang Goethe-Universität Frankfurt am Main. An internal review of an early draft of this document was conducted by Hilko Donker of Technische Universität Dresden and Peter Keller of Swisscom. Thanks to all. Pete Bramhall, Hewlett-Packard Editor



Table of Contents 1 Introduction ............................................................................................................................. 11

2 eLearning Application Prototype........................................................................................... 13 2.1 Descriptive summary ...................................................................................................................... 13 2.2 Suitability of the Architecture, IPV1 and its APIs for this application prototype ........................ 14 2.2.1 General statements towards the suitability of privacy-preserving identity management in eLearning 14 2.2.2 Statements about the suitability related to the architecture and the APIs of the PRIME IP ............ 15 2.3 HCI evaluation – operational and functional aspects................................................................... 16 2.3.1 Scope and focus ............................................................................................................................... 16 2.3.2 BluES’n in general........................................................................................................................... 16 2.3.3 Context Switch ................................................................................................................................ 17 2.3.4 The Context Management Configuration ........................................................................................ 18 2.3.5 The Info Center................................................................................................................................ 18 2.3.6 Chat ................................................................................................................................................. 18 2.3.7 PRIME and BluES’n ....................................................................................................................... 18 2.3.8 Recommendations ........................................................................................................................... 18 2.3.9 Conclusions ..................................................................................................................................... 19 2.4 HCI evaluation – other aspects...................................................................................................... 19 2.4.1 Documentation ................................................................................................................................ 19 2.4.2 Installation and Platform ................................................................................................................. 20 2.4.3 Support Requirements ..................................................................................................................... 20 2.4.4 Recommendations ........................................................................................................................... 20 2.4.5 Conclusions ..................................................................................................................................... 20 2.5 Assurance evaluation – operational and functional aspects......................................................... 20 2.5.1 Assessed security functions ............................................................................................................. 20 2.5.2 Recommendations ........................................................................................................................... 21 2.5.3 Conclusion....................................................................................................................................... 22 2.6 Assurance evaluation – other aspects ............................................................................................ 22 2.6.1 Installation ....................................................................................................................................... 22 2.6.2 Documentation ................................................................................................................................ 22 2.6.3 Platform requirements ..................................................................................................................... 23 2.6.4 Support requirements....................................................................................................................... 23 2.6.5 Conclusions ..................................................................................................................................... 23 2.7 Legal evaluation – operational and functional aspects................................................................. 23 2.7.1 Recommendations ........................................................................................................................... 23 2.7.2 Conclusion....................................................................................................................................... 25 2.8 Legal evaluation – other aspects.................................................................................................... 25 2.8.1 Installation ....................................................................................................................................... 25 2.8.2 Documentation ................................................................................................................................ 25 2.8.3 Support requirements....................................................................................................................... 25 2.8.4 Developer’s trial .............................................................................................................................. 26 2.9 Economic evaluation – operational and functional aspects ......................................................... 26 2.9.1 Scope and Focus .............................................................................................................................. 26 2.9.2 Privacy and Identity Issues in Learning Theory and Practice.......................................................... 26 2.9.3 Privacy and Identity Issues in BluES’n ........................................................................................... 27 2.9.4 Strengths and Weakness of BluES’n ............................................................................................... 27 2.9.5 The market and the players.............................................................................................................. 27 2.9.6 Recommendations ........................................................................................................................... 28 2.10 Economic evaluation – other aspects ........................................................................................ 28 2.10.1 Documentation ................................................................................................................................ 28 2.10.2 Installation and Platform Requirements .......................................................................................... 28 2.10.3 Support Requirements ..................................................................................................................... 29 2.11 Social/cultural evaluation – operational and functional aspects ............................................. 29



2.11.1 Recommendation............................................................................................................................. 31 2.12 Social/cultural evaluation – other aspects ................................................................................ 31 2.13 ICPP Privacy Seal evaluation.................................................................................................... 32

3 Airport Security Controls Application Prototype ................................................................ 34 3.1 Descriptive Summary ..................................................................................................................... 34 3.2 Suitability of the Architecture, IPV1 and its APIs for this application prototype ........................ 34 3.3 HCI evaluation – operational and functional aspects................................................................... 35 3.3.1 Scope and focus ............................................................................................................................... 35 3.3.2 The Olympischen Luft website........................................................................................................ 35 3.3.3 The enrolment form......................................................................................................................... 35 3.3.4 Other usability issues in the prototype............................................................................................. 36 3.3.5 Recommendations ........................................................................................................................... 36 3.3.6 Conclusions ..................................................................................................................................... 36 3.4 HCI evaluation – other aspects...................................................................................................... 36 3.4.1 Documentation ................................................................................................................................ 36 3.4.2 Installation and Platform ................................................................................................................. 36 3.4.3 Support Requirements ..................................................................................................................... 36 3.4.4 Conclusions ..................................................................................................................................... 37 3.5 Assurance evaluation – operational and functional aspects......................................................... 37 3.5.1 Recommendations ........................................................................................................................... 37 3.5.2 Conclusions ..................................................................................................................................... 38 3.6 Assurance evaluation – other aspects ............................................................................................ 39 3.6.1 Documentation ................................................................................................................................ 39 3.6.2 Conclusions ..................................................................................................................................... 39 3.7 Legal evaluation – operational and functional aspects................................................................. 39 3.7.1 Biometrics: the proportionality test ................................................................................................. 40 3.7.2 Enrolment phase .............................................................................................................................. 40 3.7.3 Check-In and RFID tags .................................................................................................................. 41 3.7.4 Passenger Restricted Area, Gate control and Boarding ................................................................... 41 3.7.5 Conclusion....................................................................................................................................... 41 3.8 Legal evaluation – other aspects.................................................................................................... 41 3.8.1 Installation ....................................................................................................................................... 42 3.8.2 Documentation ................................................................................................................................ 42 3.8.3 Platform requirements ..................................................................................................................... 42 3.8.4 Support requirements....................................................................................................................... 42 3.8.5 Developer’s trial .............................................................................................................................. 42 3.9 Economic evaluation – operational and functional aspects ......................................................... 43 3.9.1 Scope and Focus .............................................................................................................................. 43 3.9.2 Privacy and Identity Issues in Air Travel ........................................................................................ 43 3.9.3 The Market Players.......................................................................................................................... 44 3.9.4 The Business Case for a Trusted Traveller Scheme ........................................................................ 45 3.9.5 Recommendations ........................................................................................................................... 46 3.10 Economic evaluation – other aspects ........................................................................................ 47 3.11 Social/cultural evaluation – operational and functional aspects ............................................. 47 3.12 Social/cultural evaluation – other aspects ................................................................................ 49 3.12.1 Recommendations ........................................................................................................................... 49 3.13 ICPP Privacy Seal evaluation.................................................................................................... 49

4 Location Based Services Application Prototype................................................................... 51 4.1 Descriptive summary ...................................................................................................................... 51 4.2 Suitability of the Architecture, IPV1 and its APIs for this application prototype ........................ 52 4.3 HCI evaluation – operational and functional aspects................................................................... 53 4.3.1 Scope and focus ............................................................................................................................... 53 4.3.2 The overall usability in the prototype .............................................................................................. 53 4.3.3 The Pharmacy Search in general ..................................................................................................... 54 4.3.4 Issuing a pharmacy search ............................................................................................................... 54 4.3.5 Data Track ....................................................................................................................................... 55



4.3.6 Recommendations ........................................................................................................................... 55 4.3.7 Conclusions ..................................................................................................................................... 55 4.4 HCI evaluation – other aspects...................................................................................................... 55 4.4.1 Documentation ................................................................................................................................ 55 4.4.2 Installation and Platform ................................................................................................................. 56 4.4.3 Support Requirements ..................................................................................................................... 56 4.4.4 Conclusions ..................................................................................................................................... 56 4.5 Assurance evaluation – operational and functional aspects......................................................... 56 4.5.1 Assessed security functionalities ..................................................................................................... 56 4.5.2 Comments on the current prototype................................................................................................. 56 4.5.3 Recommendations for further prototypes ........................................................................................ 57 4.5.4 Conclusions ..................................................................................................................................... 58 4.6 Assurance evaluation – other aspects ............................................................................................ 58 4.6.1 Installation ....................................................................................................................................... 58 4.6.2 Documentation ................................................................................................................................ 58 4.6.3 Platform requirements ..................................................................................................................... 59 4.6.4 Support requirements....................................................................................................................... 59 4.6.5 Conclusions ..................................................................................................................................... 59 4.7 Legal evaluation – operational and functional aspects................................................................. 60 4.7.1 Recommendations ........................................................................................................................... 60 4.7.2 Legality of processing: Consent ...................................................................................................... 60 4.7.3 Policies ............................................................................................................................................ 61 4.7.4 Retention of data.............................................................................................................................. 61 4.7.5 Dispute resolution............................................................................................................................ 62 4.7.6 Conclusion....................................................................................................................................... 62 4.8 Legal evaluation – other aspects.................................................................................................... 62 4.8.1 Installation ....................................................................................................................................... 62 4.8.2 Documentation ................................................................................................................................ 62 4.8.3 Platform requirements ..................................................................................................................... 63 4.8.4 Support requirements....................................................................................................................... 63 4.8.5 Developer’s trial .............................................................................................................................. 63 4.9 Economic evaluation – operational and functional aspects ......................................................... 63 4.9.1 Scope and Focus .............................................................................................................................. 63 4.9.2 Privacy and Identity Issues in Location-Based Services ................................................................. 63 4.9.3 The Market Players.......................................................................................................................... 64 4.9.4 The Business Case for Pharmacy Search Application ..................................................................... 64 4.9.5 Recommendations ........................................................................................................................... 66 4.10 Economic evaluation – other aspects ........................................................................................ 66 4.10.1 Documentation ................................................................................................................................ 66 4.10.2 Installation and Platform Requirements .......................................................................................... 66 4.10.3 Support Requirements ..................................................................................................................... 66 4.11 Social/cultural evaluation – operational and functional aspects ............................................. 66 4.12 Social/cultural evaluation – other aspects ................................................................................ 68 4.13 ICPP Privacy Seal evaluation.................................................................................................... 68

5 Summary .................................................................................................................................. 69

6 Conclusions and Recommendations ...................................................................................... 69

References ....................................................................................................................................... 70

Appendix A Test Reports ......................................................................................................... 71 A.1 HCI Test Report – eLearning ........................................................................................................ 71 A.1.1 Testdesign........................................................................................................................................ 71 A.1.2 Test data........................................................................................................................................... 71 A.1.3 Test data........................................................................................................................................... 72 A.1.4 Revision of test tasks and introduction of interview, after AP meeting in Dresden ....................... 73 A.1.5 Test data........................................................................................................................................... 74 A.1.6 Test data........................................................................................................................................... 74



A.1.7 Printed Description – given to user.................................................................................................. 76 A.2 HCI Test Report – Location Based Services.................................................................................. 77 A.2.1 Testdesign........................................................................................................................................ 77 A.2.2 Test data........................................................................................................................................... 77 A.2.3 Test data........................................................................................................................................... 78 A.2.4 Test data........................................................................................................................................... 79 A.3 Developer’s Trial Report – Location Based Services .................................................................... 80 A.3.1 Test Scenario ................................................................................................................................... 80 A.3.2 Results ............................................................................................................................................. 80 A.4 Learning and privacy protection – social/cultural aspects............................................................ 82 A.5 ASC AP’s relationship to the principles of PRIME & the Data Protection Directive 95/46/EC. 84



List of acronyms AP PRIME Application Prototype

API Application Programming Interface

ASC Airport Security Controls

DPA Data Protection Authority

HCI Human-Computer Interaction

IDM Identity Management

ICPP Schleswig-Holstein Unabhängiges Landeszentrum für Datenschutz

IP Internet Protocol

IP PRIME Integrated Prototype

IPV1 PRIME Integrated Prototype Version 1

IPV2 PRIME Integrated Prototype Version 2

JRC Joint Research Centre

LBS Location Based Services

LI Location Intermediary

MO Mobile Operator

PII Personally Identifiable Information

PNR Passenger Name Record

POI Point of Interest

PRA Passenger Restricted Area

UI User Interface

WAP Wireless Application Protocol



1 Introduction This document is a compilation of reports of the evaluation of the initial application prototypes – eLearning, Airport Security Controls and Location Based Services. It is the result of work performed by specialists in the fields of HCI, assurance, legal, economic and social/cultural aspects. It also includes assessments by the application prototype developers of the suitability of PRIME architecture, IPV1 and its APIs for their purposes.

Its main purpose is to act as a vehicle for feeding back the results of the evaluations into the project activities that undertake technology research and produce the next iterations of the PRIME architecture, integrated prototype and application prototypes. As such, its main audience is the set of PRIME partners who will undertake that work. A secondary audience comprises the PRIME Reference Group, the European Commission project officer and the project reviewers. A tertiary audience is the general public and those with a specialist interest in this topic who are not participants in the project.

The evaluation objectives were to detect weaknesses with these initial APs and to provide recommendations for improvements with respect to the major goals of PRIME. The methodologies employed varied between the various evaluation specialisms. In total, these included examination of documents, experimentation with test subjects, briefings and discussions with developers.

For example, the HCI evaluation criteria were that the user can perform tasks relevant to a specific UI, can understand the privacy implications when they use the AP and feel satisfied with using the privacy-enhancing features present therein; these were assessed by general usability tests, feature-specific tests and interviews with test users. By contrast, the assurance evaluation commenced with an inspection of the provided documentation to address its criteria of threat analysis, implemented security and privacy functions and the mappings between these, noting that effective privacy and identity management have to rely on security and proper corresponding functionalities, and followed this with observations of the APs’ operation and interrogative discussions with the APs’ designers. The social/cultural evaluation is based on notions of user control and inclusion/exclusion; such notions are partly embodied in the legal data protection framework but also transcend the legal connotation.

The APs were also assessed against the criteria for the ICPP Privacy seal. This certifies that the compatibility of a product with the provisions governing data protection has been confirmed by an official process. ICPP therefore recommends that these products shall be given priority in authorities and public offices. The product is checked for compatibility with the provisions on privacy protection and data security. Particular attention is paid to data avoidance and minimization, to data security and revisability and to ensuring the rights of those concerned. The original ICPP Privacy Seal is based on the Data Protection Act Schleswig-Holstein and German privacy law. For evaluation in PRIME a version adapted to European privacy law is used. It is divided into four complexes: Complex 1: Fundamental Technical Design of IT-Products, Complex 2: Legitimacy of Data Processing, Complex 3: Accompanying measures for protection of the data subject and Complex 4: Rights of the data subject.

All the APs were demonstrated to the evaluators at sessions in Dresden on 17/18 November 2005 (eLearning) and at JRC’s facility in Ispra on 15/16 December 2005 (Airport Security Controls and Location Based Services).

The three APs were chosen in order to demonstrate and validate the PRIME approach from different aspects. The eLearning AP provides a very rich set of roles and actors; these lead to a diverse set of types of interaction with which to exercise the PRIME toolbox. The ASC AP tests the compatibility and integration of the PRIME principles with real-life identity management processes and interactions between users and services. The LBS AP involves a number of parties on the services side, and hence tests the ability of the PRIME architecture and IP to handle the resulting complexity of systems and data flows in a privacy-respecting manner.



This document is organized by application prototype. Within each chapter, one application prototype is evaluated from each of the viewpoints. The evaluations cover firstly the functional and operational aspects and then its installation, documentation, platform and support requirements. The developer’s assessment is also included, as is a descriptive summary of the application prototype. Each item is deliberately limited in length in order to focus on the main points that were identified by the evaluation, such focus reflecting the priorities that are determined by each evaluator. Where necessary, additional detail is provided in the Appendix.

The document also includes a list of references, a summary, conclusions and recommendations.



2 eLearning Application Prototype

2.1 Descriptive summary The eLearning Application Prototype (AP) was not selected because it possesses a large potency in the market or in the media. But rather, its strength lies in the intrinsic comprehension of scenarios that entail considerations of very different requirements on identity management. Thus, it allows for developing comprehensive concepts when developing a privacy-enhancing identity management system. Further, the eLearning AP forms an ideal testbed for researches in the field of identity management especially regarding multilateral interaction environments.

The eLearning application itself benefits from enhancement with privacy-preserving identity management. Since Internet users are increasingly aware of the necessity of protection of their privacy. Therefore, considering privacy issues is of growing importance when designing new Internet-based applications. Especially, eLearning comprises many different scenarios requiring interactions not only between a user and the system but also between the user and one or more other users. Additionally, those interactions may hold risks related to creating detailed user profiles or implying a biased learning environment etc. Those problems are to be prevented. Therefore, mechanisms provided by the PRIME integrated prototype (IP) v1.5 are applied to the eLearning AP v1.1.

The eLearning AP, which is developed within the scope of PRIME, enhances the BluES1 system and forms BluES’n2. It is in terms of its organisational structure a collaborative environment, i.e. users interact not only with the system itself but rather work together in order to achieve a common learning goal. For that, it provides special collaborative “rooms” – the shared workspaces. Workspaces are created on the basis of special workspace templates, which represent pre-configurations and pre-equip the new workspaces according to the aimed working or learning objectives and to the individual prerequisites of its members etc. The functional basis of a workspace is provided by functional modules. These are, for instance, chat modules, content presentation modules, glossaries etc. Furthermore, in a shared workspace, the work, the accesses as well as the content presentation modes are controlled by the implementation of specific roles.

The main component of the BluES'n-GUI is a tabbed panel where each tab holds 3 different areas with specific objects of the corresponding workspace. The most important area is the Point of Interest (PoI) being the actual working area of the users and, therefore, using the major space of the workspace panel. Besides this, space is reserved for the InfoCenter, which is used to deliver awareness information, and for an area containing at most 2 medium-sized functional modules that are supplementary (functional modules displaying content relevant for performing the current task connected to the objects of the PoI). A more detailed description of the concepts of the eLearning system BluES that provides also a comprehensive overview of the components of the graphical user interface, such as the Point of Interest and the different states of the functional modules can be obtained from [1] as well as from the BluES’n v1.1 handbook, which is available via http://blues.inf.tu-dresden.de/prime/AP_v1_Eval/Handbook_BluESnext_v1-1.pdf. The scope of the AP v1.1 realized within the project PRIME is described in [2].

BluES’n uses particular PRIME technologies (cf. also [3]), which are: First, the offered possibilities of creation and handling of credentials (which means the need for a specific interplay of the PRIME console with the BluES’n client) are used to realise a capability-based access control. Second, BluES’n uses release policies in order to define the according access rules. And third, it builds on top of the communication infrastructure provided by PRIME. In order to provide reasonable identity management functionality within the eLearning environment BluES’n integrates further components: The Context Management is responsible for supporting the user in partitioning the processes (by

1 BluES means BluES like universal eEducation System 2 BluES enhanced



determining separate tasks) within the system to facilitate sustaining the user’s privacy, i.e. it assists the user in choosing the corresponding partial identity when starting to work on new tasks. The Info Center of BluES, which aims at arising the user’s awareness by comprehensive information about the situation the user currently works, is enhanced with additional functionality for privacy awareness.

2.2 Suitability of the Architecture, IPV1 and its APIs for this application prototype

This section is split into two main parts. The first part motivates the suitability of the approach of privacy-preserving identity management in general by illustrating the results of different surveys among eLearning users. The second one addresses the suitability of the interplay of the PRIME IP and the eLearning application prototype BluES'n by looking at the architecture and the APIs in detail.

2.2.1 General statements towards the suitability of privacy-preserving identity management in eLearning

In order to motivate the discussion about the necessity of considering security and privacy aspects while designing eLearning applications, our project team initiated a survey in 2005. That survey [4] was addressed to eLearning users who reside in Europe. Inquiries with respect to support the survey were sent around to very different European institutions that are engaged in eLearning (e.g. universities; partners of projects which are concerned with eLearning; European community action programmes; developers, distributors, and users of eLearning software, organisations hosting eLearning related websites, etc.). 107 questionnaires were received that are currently being analysed. Even though the results are not yet published, at this point it seams reasonable to reflect some issues of the outcome:

Beside some questions regarding the common attitude of the users towards the protection of their personal data, it was asked if the users would favour or oppose if all of their private and personal data could be seen by everyone being part of the eLearning application. The answers were almost unanimous: About 88% of the users selected the options “somewhat oppose” (16%) or “strongly oppose” (72%). In contrary, to the question to which degree the users would appreciate to have a function in an eLearning application that displays which of the private and identifying data they have disclosed to different groups of users and which of these data they hide from them about 73% of the participants responded “strongly favour” (49%) or “somewhat favour” (24%). A further question, which throws light on the necessity to integrate identity management functionality, related to the attitudes of the participants towards handing personal and identifying data to other users only with the user’s explicit permission. Here, about 75% of the participants (24% “somewhat favour”, 52% “strongly favour”) indicated an explicit interest to self-determinating the kind of processing personal data.

To conclude from the results of the survey it is clear that consideration of security, privacy, and informational self-determination already plays an important role in the eLearning community. Furthermore, it may be expected that the awareness towards privacy will increase in the future (79% of the participants of this survey share this view). But, there is another issue based on the results of an additional survey and a few interviews, which the project team did within a group of students of Computer and Media Sciences, that has to be addressed: Even though the students have skills and awareness about the necessity of protecting personal data they do not possess profound knowledge of the concepts which underlie the field privacy and data security. So, we asked them to define “pseudonyms”, “policies”, and “credentials” (those are the basic PRIME concepts that are used in the eLearning application prototype BluES'n). Less than 35% of the participants were able to correctly reflect the asked meanings. For this reason, it is very important to attach more value to education not only of educated people but also of the general public.



2.2.2 Statements about the suitability related to the architecture and the APIs of the PRIME IP

During the development of concepts as well as the implementation of the identity management related BluES components, which form the BluES’n system, we encountered a few problems, which mainly related to the limited functionality provided by the PRIME suite when applying the PRIME philosophy to such a multilateral interaction system like BluES. Most of those issues could be remedied in close cooperation with the developers of the PRIME IP. Other issues were temporarily fixed by direct incorporating as BluES’n components3 - this relates to missing pseudonyms and context management in PRIME IPV1.

In order to reflect the suitability of the architecture of the PRIME suite for the eLearning AP in general, it has to be stated that most of the system internals (e.g. communication, policies) as well as user/human aspects (represented by the PRIME Console) which are required by the AP were considered. In the following, we give short evaluation statements itemized by the PRIME concepts used for BluES’n:

• The communication infrastructure API is designed universal and not specific for only one protocol. The BluES communication is based on value objects. The realisation of transferring those value objects via the message based API was easily possible. However, in spite of internally supporting encrypted communication, the encryption of the AP’s communication is not possible by the IP v1.5. Furthermore, it is desired to at least support anonymous communication using the according technologies, such as JAP, ANON, Tor, etc.

• Access control is a very crucial issue in eLearning. That is why BluES'n strongly relies on the access control policy API provided by PRIME. It forms one pillar (in conjunction with credentials) for the capability-based access control [5], the approach of which has to be pursued in non-identity focussed collaboration systems. During the development we very appreciated that fine-granular policies can be defined. Nonetheless, the current IP v1.5 does not implement all functionality that is defined in the interfaces of the API. This especially relates to dynamic creation, modification, and deletion of policies.

• Credentials (which in BluES'n are used as certified values) are absolutely necessary for the eLearning AP because they represent the basis of the implementation of the capability-based access control. Although the credential concept itself is very suitable for the purposes in BluES'n the current concept of user interactions with the PRIME Console in order to allow them to select and disclose credentials turned out4 to be not intuitive enough. An additional open question is still the issue of how the interplay of the PRIME Console with AP should be realized. There are two options: considering the PRIME Console and the AP as separated applications vs. integrating the functionality of the PRIME Console into the AP system.

• As already mentioned, one of the main issues raised during the concept development and the implementation of the privacy-enhanced BluES is the problem that the architecture of IP v1.5 is mainly construed for bilateral scenarios, i.e. interactions between one user and the application, which perfectly applies to such scenarios like eShopping. Even though the current architecture is usable in a complex and circuitous manner for collaborative scenarios like the AP BluES'n addresses, a better support for multilateral scenarios (where different users interact with each other mediated by the application) by the PRIME suite is necessary to gain a better performance and a higher flexibility of the system design.

In order to assess the current approach of integrating the PRIME suite into BluES’n, internal trials were carried out. Those trials were introduced by a short educational presentation about the system’s concepts as well as about the used PRIME concepts. After that, the participants had to perform one

3 This will be temporarily valid for the application prototype v1.1 until the needed functionality is provided directly by the PRIME suite. 4 The interviewed students struggled with the user guidance of that concept.



eLearning-specific task and to fill in a prepared questionnaire. The evaluation data was gathered by 2 methods: While the interactions with the system of a smaller group of participants (5 persons) have been recorded and compared with the responses of interviews we did with them, the larger group of students (11 persons) just worked on their own.

The results of those trials have shown that 80% of the participants basically knew what they have to do next in the case when PRIME-related dialogues appeared during work. 70% of the participants thought that the bonding of the dialogues in the working process is in principle comprehensible. But, the participants claimed that too many PRIME-related dialogues appeared and that, after a while, they just clicked away the annoying dialogues. This issue mainly related to the dialogues of the context management, which is part of the BluES’n application and which was improved in AP v1.1.

To summarise the evaluation, from the perspective of the AP the architecture of the PRIME suite and the IP v1.5 are promising and challenging at the same time. More stress should be laid on multilateral interaction systems.

2.3 HCI evaluation – operational and functional aspects

2.3.1 Scope and focus This evaluation covers the usability of BluES’n with a special focus on its privacy features: Context Management, Chat, PRIME interplay, and Info Center. The most mature parts of BluES’n were presented to three test users at individual sessions. Each session consisted of an introductionary part, ten test tasks, and an interview at the end. For a full description of the scope and a summary of the results from every test session, see Appendix A.1. The parts of BluES’n which have not been put to user testing have been inspected by the HCI evaluators.

2.3.2 BluES’n in general When introduced to BluES'n one test user, an experienced eLearning teacher, seemed to think that she had to be anonymous while she could clearly see situations where one wants to be known, both as teacher and student in eLearning environments. Another question raised were how to introduce BluES’n to new eLearning students that sometimes have a hard time understanding the eLearning platforms that exists now.

The first display of BluES’n is an empty Point of Interest in the personal workspace. That should be replaced with a more appealing view. What happens now is that users have to push the toggle button to understand that there are materials in this workspace. Moreover, the toggle button itself seemed to be troublesome. Some users did not find it and some thought it was cumbersome o click on it every time to change between the PoI view and the map of functional modules, especially when solving a test task that needed both the structure and the material viewer. The former module was supposed to be put in medium view and the latter in the PoI position. Another point stated by all three test users, when performing that test task, was that once the structure viewer were in medium view a double click on a link should present the actual material in the PoI automatically without having to put the material viewer in the PoI. It seems as having two different modules for selecting and viewing information puts too much strain on the user. #One solution is to incorporate the structure viewer in the material viewer and whenever that new module is put in PoI both of them are launched.

Users thought the Map of Interest was an interesting new site but the module names are not fully visual making it hard to understand which functionality they cover.

The credential handling, for example, is a complex procedure that makes the system busy for quite some time. In that case it’s critical to visualize that the system is occupied. Without such indications users can misinterpret the situation and wrongly believe that the system does not work any longer.

The parts in BluES’n that enables users to create new structures and edit materials are too immature and there was no point in putting much effort in evaluating these right now. Even with guidance from the User Guide document the HCI evaluator herself found that it is, in some parts, hard to manage.



Things to consider when revising these parts in order to achieve a sufficient usability level are: usage of drag-and-drop especially if following the suggestion of the present evaluation to join the modules; there exist good word processors and therefore BluES’n needs a possibility to import different file types (pdf, doc, etc.) instead of always creating new structures/materials; reduce number of popup windows to a minimum.

2.3.3 Context Switch When a Context Switch occurs the user gets information from one out of three alternatives: notification, dialogue, none. The two former are penetrated in detail below and as concerns the latter there is no question about the usability since it may fulfill a user’s wish to not interact with the system during a Context Switch.

Users have appreciated to be able to choose in which way they get information about a Context Switch. The test participants have also stated that they understand that the switch occurs because BluES’n takes care of their identity management so they can remain unknown in the environment.

In general, the notification and the dialogue windows have been confusing for the test participants to understand and manage. The objective of the Context Switch is clear to them but the interaction is probably too technical. It is suggested to strip all technicalities and make the windows minimalistic in the sense that they only reveal what is necessary to help the user get the picture. The user needs to know why this window is shown and what (s)he should do with it. Below the most major problems are highlighted and concluded with proposals, based on the results of the usability tests, on how to improve the usability in the Context Switch interactions.

The notification window

All test participants were a bit confused with the information displayed. To help them understand the intention, wipe out everything but the most critical parts like the title bar and the explanation to why this window is displayed. That explanation should be adapted to meet usability demands rather than spelling out all technical terms. The checkbox “don’t ask me anymore” is contradictory to the intent of the window; it is not a question but merely a notification. It should be removed or rephrased depending on if it is adequate to use in this window. A severe problem has been that users can’t distinguish between the different actions (open, activate, open first, create etc.) that triggered the Context Switch. Although it is stated in the window that for example an ‘open’ activity fired the switch, it has not been clear enough for the users to see. In fact, the test users ended up believing the system malfunctioned because the same popup window was displayed contiguously several times. To rectify this one can imagine several options, e.g.:

• In the explanation text, put in the action notice on a strategic place to make things clearer to the user. The action word will of course change depending on which event occurred.

• Change the wording on the OK-button to the action that triggered the switch. The user will push that button and the button text will help users perceive what is happening.

The dialogue window(s)

All comments and proposals stated for the notification window are valid for the dialogue window too. Besides that and without going into details some sentences are misspelled and there are too many technical terms. The configurate button was misinterpreted as holding a function for configuration of the Partial Identity in question rather than the intended functionality, i.e. Context Management at large. Suggestions to make it consistent with the other parts of BluES’n: remove the button or put it also in the notification window.

If a user chooses to create a new Partial Identity, a new window for Creating new Partial Identity is displayed. Some test users had trouble to understand that the first text box is editable and therefore should be managed by the user to get a relevant name for the partial identity. The combobox for pseudonyms sometimes just contained one alternative to choose from, which is in contrast to users’



expectation that a combobox is a selection container. Some test users also declared that they wanted more realistic pseudonym names rather than numbers.

To ease the load on the user, join the dialogue windows by putting the Creating new Partial Identity window inside the main dialogue and make it deactivated/uneditable so long as the user does not explicitly chooses to create a new Partial Identity via a radiobutton or the like. To obtain a good user interface for this new window it is utterly important to remove everything that is not informative and instead put in easy to understand word/sentences that clearly states the purpose and the user actions needed.

2.3.4 The Context Management Configuration Although updated and changed due to comments from HCI inspection earlier in the development process this window is too complicated and all three test users failed to understand and manage the configuration. A suggestion to simplify: give more support to the user when dealing with the configuration and possibly split the configuration into one novice view and one expert view. The support could take the form of tutorials, hints and tool tip etc. The novice view would only comprise the most basic functionality and should be very easy to manage. The expert view will be more extensive but possibly without the complexity of the current version of BluES’n.

2.3.5 The Info Center The Info Center is not yet fully implemented, but from an HCI point of view it seems as a promising feature to increase user awareness regarding the Context Management and the PRIME functionality.

2.3.6 Chat The Chat was easy to use and straightforward. The only difficulty for the test users was to send anonymous messages since that demanded them to do Context Management Configurations. One minor issue is that a push on the return key sends the message in most instant messaging services today but not in BluES’n. If this is not an intentional privacy protecting feature, it seems advisable to follow the practice of existing services.

2.3.7 PRIME and BluES’n The credential handling is a time-consuming process and the test users’ understanding of the cut and paste procedure was low. Sometimes the credential handling didn’t even start for some obscure reason and that made it virtually impossible to test the PRIME interplay with BluES’n. The intention in future BluES’n versions ought to be to simplify the credential process possibly by making it totally transparent to the user and truly incorporate the PRIME system into BluES’n, instead of having it as a standalone application. Only then may it be possible for users outside the PRIME sphere to grasp the whole picture.

2.3.8 Recommendations Incorporate extensive help pages: New eLearning students sometimes have a hard time understanding the eLearning platforms that exists now. One solution to this problem and a necessity to improve the overall usability is to incorporate extensive help pages and a tutorial that focus particularly on new beginners. The help pages should focus on explaining the main functionality in BluES’n and after that an easy to understand guide to Context Management. They would also serve as a shortcut from reading the whole User Guide document.

Agreement when starting BluES’n the first time: The Privacy Policy is too complex to read at every startup and would probably be better suited as a kind of agreement once stated at the very first time a user starts BluES’n. The bullet list was a source of confusion for some of the test users who thought the bullets were clickable radio buttons.



Context switch / Make the notification and the dialogue windows minimalistic: In general, these windows have been confusing for the test participants to understand and manage. The interaction is probably too technical. Therefore, strip all technicalities and make the windows minimalistic in the sense that they only reveal what is necessary to help the user get the picture. More proposals how to improve the usability in these windows can be found in chapter 2.3.3 about Context switch.

2.3.9 Conclusions Test users seemed to understand mostly of the BluES’n application prototype. However, there are still things to improve in the following version. For example, simplification needs to be done and there may be a need for more user support, i.e. incorporated extensive help pages and a tutorial focused particularly on beginners.

2.4 HCI evaluation – other aspects

2.4.1 Documentation The documentation has been evaluated by inspecting the accuracy of their content in respect to what really exists in the implemented prototype. Usability aspects have also been considered.

2.4.1.1 Handbook/Users Manual The handbook is a very ambitious document that in many aspects fulfils a user’s needs when getting acquainted to BluES’n. However, there are some discrepancies and missing features that may degrade the usability of the document. Section 4.2 describes the Workspace templates that exist in BluES’n but at some points it is inaccurate (inconsistent):

• Library and Generic Workspace are not mentioned or described but they are available as templates in the system.

• Personal Workspace is mentioned and described but does not exist as a template in the system; rather it is a pre-defined workspace that is automatically created and opened at startup.

• Three of the templates described have mismatching names compared to the system, viz., Dynamic Group Learning, Synchronous Learning/Working, Asynchronous Learning/Working. The word ‘Learning’ should be dropped from these names for the manual to be consistent with the names in the system.

For new users the Handbook may be too extensive and for that reason it would be preferable to have a short version for introducing the basics. That could also be a tutorial under the help menu in BluES’n as already proposed in the usability evaluation. The introduction section in the Handbook was put to some test users before starting BluES’n to see how the text was perceived. The results indicate that the text may be on a too deep level and too long. The introduction part of every usability test session (see Appendix A.1.7) is an attempt to reduce the complexity. The test users claimed they could understand most of that text and that it made them aware of BluES’n functionality and capabilities. Probably an approach that lies between the Handbook and the introduction to test sessions would serve as a base for the tutorial/short version of the handbook.

2.4.1.2 Other documentations Installation Guide User Scenarios Description of Workspace Concept Description of Context Management Concepts to establish a privacy-aware collaborative eLearning environment Publications



Probably the only document, other than the handbook, that will be put to users is the Installation Guide. It covers everything one would need to install the system and leaves no loose ends. The User Scenario document contains four different scene settings but only the first one, slightly modified, has been used in the usability tests due to the complexity of BluES’n and because some parts still need to be developed. As far as the rest of the documentations concerns they are all mainly intended as in-PRIME and as such are usable.

2.4.2 Installation and Platform The installation has run smoothly under Windows, which is the only platform tested. It is important to run the system on a computer that fulfills the System Requirements to get the most out of the application.

2.4.3 Support Requirements As stated in the Usability Evaluation, new users to BluES’n probably would need some support to understand the concepts depending on how successful the help pages and tutorials are.

2.4.4 Recommendations Use introduction in every section: Sections 4.2.6 and 4.2.7 lack an introduction part that explains intention behind the workspace template, which may cause confusion for a user since every other template is properly introduced.

Explain the acronym ‘FM’ earlier in the handbook: The acronym ‘FM’ is frequently used throughout the document but it is first explained in section 4.3. The acronym also occurs several times in the table of contents which indicates that it is an important abbreviation. To an uninitiated user an addition in the glossary could be helpful or an explanation the first time FM is mentioned.

Brush up the English: In some sections the document suffers from insufficient English that may mislead the user. Although it is not a major problem it should be considered to brush up the English in a future live release.

2.4.5 Conclusions The installation guide and the handbook are ambitious documents. However, some aspects are missing in the handbook to completely fulfill a user’s needs when learning to use BluES’n. Besides that, it would be helpful for beginners to have a short version for introducing the basics, as said in the usability evaluation.

2.5 Assurance evaluation – operational and functional aspects The eLearning prototype in its current state is an early prototype and has to be evaluated in its settings. From an assurance perspective, it has to be pointed out that most of the features to evaluate are based on the Integrated Prototype version 1. The latter is also a very early prototype with presently only few implemented security functions that can be used by the application prototype. Thus, it is nearly impossible to evaluate the application prototype isolated from the underlying integrated prototype because the main security functions are currently provided by the IP. Therefore, the assurance evaluation does not have the major focus on the current implementation. The assurance group rather wants to provide additional comments on how to improve the following versions of the BluES’n system from an assurance point of view.

2.5.1 Assessed security functions Most of the security functions will be provided in future versions or are lying in the responsibility of end-users or server- and network-administrators. At the moment, the only serious obstacle for attackers is access control based on credentials combined with a check of policies.



The provided documentation is a little ambiguous concerning the access control based on credentials. Hence, the assurance evaluators want to clarify the current situation of the status of credentials.

In the current version of the prototype, credentials are only implemented in a light-version without cryptographic support. Consequently, it is possible to change user rights by changing the authorisation part of the credential, e.g. changing from “write” to “delete” and not only to gain reading rights like it is stated in the documentation.

The implementation of anonymous credentials were planned to be finished after the beginning of the evaluation and thus will be part of the IPV2. Consequently, BluES`n prototype V2 will use anonymous credentials when they will be available .

2.5.2 Recommendations Within this section, the assurance evaluators are formulating recommendations that, from their point of view, might be an important contribution for the application prototype and therewith for PRIME. Recommendation 1: An integrated visualisation approach of providing credential related information to the user of the BluES’n system Currently, users have to deal with dispatches of the application and the prime console. While creating, changing, or closing workspaces users get informed by BluES’n about which credential has to be presented by the PRIME client towards the services-side. This credential has to be copied into the right profile of the PRIME-client and has to be selected for a presentation towards the services-side. The current procedure should therefore be modified to reduce the necessary steps undertaken by users to avoid confusions and faulty operations. The responsibility seems to lie within the group of the developers of the IP. Recommendation 2: Allocation of credentials to pseudonyms within the PRIME console Currently, provided credentials are available in all stored pseudonyms of the PRIME-console. Consequently, users are endangered to choose another than the intended pseudonym. Therefore, it is recommendable to bind credentials to certain pseudonyms while providing users with the possibility of transferring credentials to other pseudonyms, so wanted. Recommendation 3: Transparency of utilisation of credentials Currently, users are able to bypass the above-mentioned procedure of dealing with credentials by ticking a box “Don’t ask me for any credentials, show the requested credential always!”. In this case, the credential will not be displayed in the PRIME console anymore and cannot be inspected by the users anymore. The only hint is given by the PRIME console of having had interaction with the BluES’n server by inspecting the data track section of the PRIME console. The assurance group strongly recommends establishing a standardised way to manage credentials in a proper and consistent way. Especially the possibility for inspections of used credentials should be given by PRIME. Recommendation 4: Rights management A related issue is the currently not implemented rights management of managing and granting different rights to certain users within workspaces. This issue is currently under construction. Recommendation 5: Tests We recommend having some further functionality and stability tests on different operating systems and hardware constellations to avoid confusions and attempts of evaluators to get the prototype running. Recommendation 6: Secure Pseudonyms Up to now, the BluES’n system runs its own proprietary solution of creating and administrating pseudonyms. This can only be seen as an interim solution as part of an overall identity supporting system. Presently, it is possible to create the same pseudonyms and, regarding the BluES’n context,



partial identities more than once and therefore, users cannot be sure to interact with the same person only having the indicator of the presented pseudonym.

2.5.3 Conclusion The eLearning team did a fair job in developing the prototype up to now. Furthermore, they are aware of the most problems that may come up from an assurance perspective.

As a general comment, we recommend having some further functionality and stability tests before presenting prototypes. Especially, having internal user-driven trials on different operating systems and hardware constellations is an important aspect.

2.6 Assurance evaluation – other aspects The assurance evaluators made pre-tests for providing valuable input for the developers of the eLearning prototype right from the beginning of the evaluation period to improve the application prototype and for having a stable version of evaluation. This was managed by inspecting the requested documentation in the run-up to the evaluation as well as by the installation and stress test of the provided versions. Please compare to section 2.5, in which more details are mentioned in the actual part of the assurance evaluation of the eLearning prototype.

2.6.1 Installation The assurance group installed the eLearning prototype on several computers; one based on a Linux distribution but based their evaluation on a Microsoft Windows XP version. During installation preparation, the evaluators observed some difficulties related to the decompressing procedure using the Windows explorer. The developers had previously mentioned that the explorer might cause a lot of problems but nevertheless, the assurance group tried to decompress the zip-archive using the windows explorer, which took about two hours and the content has been corrupted. Hence, it is recommendable for windows users to follow the notes and use other tools to decompress the zip-archive.

2.6.2 Documentation The eLearning group did quite a good job in providing information for the assurance evaluation.

Before the evaluation, the assurance group requested several documents to enable themselves to evaluate the eLearning prototype as well as to be able to understand underlying processes. The developers produced a well-structured and adequate list of documents, which included:

• Handbook eLearning Application Prototype v1 Evaluation Version

• A top-level overview diagram adjusted by further descriptions

• A list of security functionalities

• Threat analysis and mapping of security functions to threats

• Control points of data flow

The assurance evaluators supported the eLearning group by giving feedback on pre-versions, which was integrated within the end version.

The documentation of the planned and currently provided security functions is adequate for an early stage of a prototype with only minor curtailments.. Actually, it is recommendable to be very precise by describing security functions starting from the developer of the component up to the application developer.



2.6.3 Platform requirements The assurance evaluation did some tests about platform requirements, especially concerning the most commonly used operating system Windows XP. We started with a sample of three computers running on XP with the latest updates and one computer running on the last version (5.10) of the Ubuntu Linux distribution.

The previously mentioned pre-tests brought up several problems regarding the stability of the prototype, which was not mainly caused by the eLearning prototype itself. Our analysis showed that in the first pre-evaluation version of the application prototype the PRIME server produced several out of memory exceptions. The feedback was reported to the developers and they provided a revised software version, which was mutually accepted by evaluators and developers to be the final evaluation version 1.1.

The platform requirements themselves are still quite high and are, therefore, a weak point of stability. Furthermore, it may currently not fit widespread hard- and software constellations. The situation will be improved as soon as client and server are running on distributed systems.

2.6.4 Support requirements Support was especially required during the first trials while using the pre-final version of the application prototype.

Firstly, this was required to get a better understanding of the background of abnormal system ends.

Secondly, the correct procedure of how to show the right credential is not intuitively obvious. Therefore, the assurance evaluators required some support, which was provided during the evaluation meeting held in Dresden. Other support requirements have not been discovered during the evaluation period.

2.6.5 Conclusions The eLearning prototype is still an early version and has to face some problems around the enrolment and utilisation. Nevertheless, from an assurance point of view the prototype seems to be on the right way. During the discussions, especially while the eLearning AP presentation meeting, the developers presented a clear vision of the upcoming features and associated privacy and security issues. They stressed their requirements concerning the IPV2 also due to attending and expressing their specific needs during the IPV2 kick-off meeting. Hence, we believe that the BluES’n team is on the right way of coming up with a highly sophisticated version of the BluES’n prototype.

2.7 Legal evaluation – operational and functional aspects The eLearning application prototype provides a first development of the BluES’n platform using the functionalities of the PRIME identity management middleware. Some elements regarding the rights of the data subject, the security requirements and the use of partial identity through the employ of both credentials and context management are analysed.

2.7.1 Recommendations 2.7.1.1 Information The presence of the privacy policy is welcomed by the legal evaluators. However, some words (pseudonymised / context management component / workspaces) might not be understood by most of the users. Data protection rules not only require that information is provided to data subjects, but also that this information is given in a clear and intelligible way. For instance, such purpose could be achieved either through an easily accessible glossary or some help files or through the simplification of the terms used.



2.7.1.2 Security Article 17 of the data protection Directive requires that controllers implement security measures which are appropriate to the risks presented for personal data in storage or transmission and this, at the time of the design of the processing system, and at the time of the processing itself. When starting the system, the prototype launches the BluES’n and PRIME console at the same time. As the PRIME access request window is based on the IPV1, which does not provide password security, there is currently no password protection. The currently only security feature of PRIME which implements the legal requirements usable for BluES’n is access control. Because of the nature of the personal data processed by the eLearning system - not just user details, but potentially also the user’s submitted work and their academic results, amongst other things - it is vital that these data are securely maintained. It is therefore important to implement additional security functions, which have to be provided by the IP PRIME developers. Access controls to resources of the BluES'n server are realised by the PRIME features “access control policies” and “certified values” (credentials). The policies are stored with the server-side and the credentials at the client side. This configuration allows the users to remain in control of his information and to manage his data, therefore enforcing the rights to access, correct or erase his data and the data minimisation principles towards the services side.

2.7.1.3 Credentials The interactions between the PRIME user-side identity management middleware and the BluES’n client are requested by the BluES’n server whenever data allowing writing, editing or deleting resources are processed. For the sake of transparency, the user has to know what (kind of) data, where, when, why is processed, whether (and to whom) it is disclosed/transferred and what is happening after processing. However, the implementation of the use of credentials does not, at the moment, enhance transparency and simplicity of the system. It is however expected that the next version, enhanced through the next IP, should correct the current difficulty but some practical explanations will have to be added as well (i.e. to be certain that users understand the purpose of the processing and transfer of the credential to the BluES’n application). Regarding the automatic request of credential, we think that the BluES’n server request to disclose a credential could be allowed for specific uses of credentials, where it relates to repetitive actions for which processing has already been accepted during the same session. However, the automatic and direct synchronization of any credential into the PRIME Console should be avoided because the prototype should enhance the ability of the users to keep control over the management of their data and this function would reduce the control of the user. In cases where the user would decide to allow the automatic use of the credential into the PRIME console for a specific use of credentials, there should have an available option to reverse the possibility. From the legal point of view, it is not enough for PRIME technology to be merely compliant with privacy laws. Rather, to qualify as a truly privacy-enhancing technology, PRIME should strive to offer a more extensive protection, and in particular offer the highest possible degree of anonymity. The use of anonymous credentials is also foreseen in the prototype. As it was already underlined in the evaluation of the IPV1, this use is not yet available. In the prototype anonymous or pseudonymous functions have similar consequences.

2.7.1.4 Context management/linkability The context management is configured by the user. Configurations as well as already created contexts are managed and stored solely at client side. The server is not able to link different partial identities which are generated within the application. This approach should enable users to manage their partial identities within the system. Moreover, actions performed under different partial identities within one BluES’n session are not linkable by other users.



In the context management, the prototype provides for multiple partial identities, even within a specific context. Generally, a context describes the current situation of the user, "in which context he is performing a task". Contexts are used as means for intra-application partitioning of personal data. Consequently, contexts used in PRIME separate tasks which a user wants to perform under different conditions regarding his partial identity. Particularly, the actions of a user in different contexts must not be linkable by other users. Pseudonyms are used in order to enable unlinkability. However, it is possible that, even if as little information as possible should be processed, a user wants to join a group or wants to receive information about specific working groups, then there could have a necessity to collect some information about the user’s preferences. Moreover, in order to officially grant results, there should have a mechanism to ensure that users could take benefit from the eLearning programme. However, the possibility to use real name instead of pseudonyms is not implemented in the prototype. Finally, the lack of some PRIME components makes that the prototype can not provide for anonymous and encrypted network communication nor for secure pseudonyms.

2.7.2 Conclusion The prototype is already well developed and also contains numerous eLearning functionalities. The PRIME components will be improved on the basis of IPV2. Regarding the weaknesses of the prototype, the developers already signaled most of them in their own documentation, proving that collaborative work is necessary between the AP developers and the IP developers.

2.8 Legal evaluation – other aspects The version of the prototype used for the evaluation was agreed during the evaluators’ meeting in Dresden on the 18th of November 2005. Therefore, this version, and only this one, is considered for the legal evaluation.

2.8.1 Installation The eLearning Application Prototype components were installed on a computer running Windows XP operating system. No specific problems were detected through the installation process. The sole difficulty came from the fact that the evaluators’ meeting with the developers required the installation of the new version of the prototype. This required the deleting of the previous version and the installation of the new one. These steps took some time but the length was created by the important number of files which had to be installed. The eLearning AP team was able to provide quick answers to any installation problems we met.

2.8.2 Documentation During the preparatory meeting, it has been asked by the legal evaluators, as well as the assurance to be provided with documentation on the AP. From a legal point of view, the documentation of the eLearning AP prepared by the developers was sufficient to legally evaluate the prototype at its current state of development. Especially important documents were the Handbook eLearning AP v1 Evaluation Version; the documentation on control of data flows Moreover, the developers made available additional relevant documents and publications presenting the eLearning concept and their vision of the eLearning prototype using PRIME.

2.8.3 Support requirements The main support was delivered during the session, where the prototype was installed on computer and a presentation of its functionalities took place. Moreover, a specific session with some of the



developers took place during the whole session to allow more detailed explanations from a legal and assurance point of view. During this session, the developers showed the limits of the current prototype, which developments are limited to the extent of the developments of the PRIME functionalities by the integrated prototype developers.

2.8.4 Developer’s trial During the different training and practising sessions held to evaluate the eLearning AP, some incompatibilities appeared from time to time, for instance in the connection between BluES’n and PRIME (sometimes, it was necessary to type several times the credential into the PRIME for it to be recognised). However, we did not specifically report them to the developers as it should not be considered as a critical problem. The stability of the prototype will anyway have to be improved for the next version.

2.9 Economic evaluation – operational and functional aspects BluES’n is an eLearning environment using the PRIME architectural components. It is designed for experimenting with the latest privacy and identity management software features. The BluES’n system is developed to grant utmost flexibility and utmost autonomy to the user of the system. BluES’n is therefore primarily a user-driven eLearning environment in which the end user determines who will get access to the system and in which the user determines which role he/she wants to play in the eLearning environment. BluES’n enables the user to switch easily and flexibly between different contexts. The PRIME-technology secures the identity of the learner. BluES’n provides a solution to reduce privacy risks and provide “as much anonymity as possible while still enabling assistance” (Borcea et al., [6]).

2.9.1 Scope and Focus The scope of the economic evaluation is limited to the operational and functional aspects of the BluES’n eLearning prototype and documentation. The focus of the evaluation is limited to the user scenarios for a privacy-enhanced eLearning environment within an educational setting. At this pre-commercial stage, the software features offered are more important than the business impact. It may be worthwhile to investigate the user scenarios for privacy-enhanced eLearning in a corporate environment since this market is growing.

2.9.2 Privacy and Identity Issues in Learning Theory and Practice It is important to distinguish two different approaches in which privacy and identity issues can play a role in eLearning. The first is account management approach. The main function is to establish a secure, protected and private learning environment which can be only accessed by those who are authorized. The use case that is described in the eLearning scenarios of the PRIME Requirements V1 document clearly illustrates the relevance of this option.

The second approach refers to how partial identity can be ‘managed’ in learning processes. The underlying assumption is that learning is an identity constructing process. The academic articles that are written by the developers emphasize the relevance of an unbiased learning environment which is under full control of the user. In the pedagogical/eLearning literature there exists a wide range of pedagogical models, each defining the roles of instructors and learners, the role of practice and experience, and the role of learning styles etc. in various ways. The BluES’n platform is clearly designed from a user/learner perspective which allows him to switch between educational contexts and thereby determining his own learning trajectory.. Other models of learning (objectivist, collaborative etc.) can be set up in the BluES’n system only at the will of the individual user. There is no incentive inherent in the system to apply the other types of learning models (Leidner and Jarvepaa, [7]).



2.9.3 Privacy and Identity Issues in BluES’n BluES’n is presented as an open and flexible learning management system. Technologies for enhancing privacy and identity management are based on a pedagogical model that gives the learner utmost flexibility and autonomy to determine and design his own learning environment. The learner switches between different contexts and decides in which role he/she participates in this contexts. Other users of the system don’t have access to the learner’s personal information until they are authorized by the learner. He can develop his own personal learning environment. One can make a distinction between the (instrumental) account management view and the (social constructivist) learning view. In the former view identities can be molded by inserting, adapting and protecting attributes. In the latter view identity-development is an open-ended process which is not under full control of the BluES’n. We think that the PIM-technology in the BluES’n system does not contribute to identity development online but to preservation of the current identity (in a sociological sense). By allowing the learner to choose between different identities the learner protects him/herself from unwanted instructional feedback that may contribute to learning.

2.9.4 Strengths and Weakness of BluES’n The BluES’n system is an application prototype still under development. A lot of works needs to be done yet before it can be considered a user-friendly learning management system for commercial purposes. This has already been considered in section 2.3. Strengths

• A clear strength of the BLUES’N system is that it is based on open source software. This allows other potential users to take advantage of it and to develop the system to their own needs. Moreover users will become less dependent on vendors of eLearning platforms.

• Another strength is that the technology is advanced and will be very useful in globally open learning environments. It gives learners access to a private and secure learning environment at any time and at any place.

Weaknesses • There is an over-determination of the role of identity and privacy issues in online learning

environment. Emphasizing these issues too much might harm the natural learning processes. The continuous, explicit switching between different contexts can make the learning in an eLearning environment an elaborate and arduous activity.

• There is no clear pedagogical foundation or practical evidence yet that will convince future users to adopt this eLearning technology.

2.9.5 The market and the players ELearning is a broad and complex field. The market for learning management systems is still growing, competition is fierce. The market is dominated by a few big players like Blackboard (recently merged with WebCT), SCT, SAGA. Open source platforms, like SAKAI and Moodle, have recently entered the market. Reputed academic institutions like Indiana University, MIT, Stanford and Michigan participate in the SAKAI open source project. Many other universities in the world look how progress is made in this open source project.

The market for eLearning platform is not only facing fierce competition but is also becoming segmented and specialized. On the supply side we observe content providers, technology providers, and service providers. Mergers and acquisitions are taking place between different types of providers. Moreover strategic alliances and networks of strategic partners are set up to gain firm position in the eLearning market. A few small niche players enter the eLearning market (e.g. Cordys with Educator). As far as we know the current eLearning platform providers do not have a niche focus on privacy and identity issues. However, privacy-enhancing features are especially useful in eLearning environments where the results of assessment are sensitive. Therefore, there is potential for servicing a niche market with the proper features and positioning strategy.



On the demand side one can distinguish three customer segment: K-12 public and private school, higher education or post-secondary market, the corporate market. The later is the largest and fastest growing market. It probably is also the environment in which the account management supports the BluES’n system provides will be most appreciated.

2.9.6 Recommendations • Make a clear distinction between the two roles identity issues can play in eLearning. The

sophisticated account management support of the BluES’n system might be very attractive to the corporate environment and be readily accepted.

• In the academic context the introduction of BluES’n should focus more on the (pedagogical) role of identity management and this will need more mission work than is needed for its account management role. Here, the issue is not so much the protection of one’s identity but the development of one’s identity in interaction with instructors and fellow students. Although the BluES’n system might have all the functionalities and flexibilities needed to facilitate such collaborative learning scenario’s, use cases that convincingly illustrate the appropriateness of the BluES’n architecture are until now lacking.

• Other Open Source initiatives, like SAKAI, are obvious sparring partners for the BluES’n system. We recommend that the BluES team seeks contact with them to exchange ideas and more clearly position the BluES’n system in the spectrum of emerging eLearning environments.

• Develop new, clear use cases which demonstrate the value of the BluES’n system. The privacy enhancing features within the functional modules for assessment of learning results and course evaluation may provide benefits not available on other eLearning systems.

• Emphasize the role of the extensible capabilities of the BluES’n system through the functional modules. The prototype may also be positioned as a knowledge management system in addition to eLearning.

• Work from a business model-perspective. This might help to specify market segments, the potential of the system in relation to other technologies, the potential acceptance of potential users, the cost and benefits for potential adopters.

2.10 Economic evaluation – other aspects

2.10.1 Documentation The eLearning application prototype is well documented. The D4.1.a eLearning AP deliverable serves as a roadmap for the rest of the documents which guides the evaluator in assessing the high level design and the actual installation and usage. Several conference papers highlight the principles behind the design of the BluES’n system. The Handbook, Installation Guide and User Scenarios were particularly relevant for the economic evaluators.

2.10.2 Installation and Platform Requirements The installation process was straightforward. The process of starting the servers and clients was provided by two scripts. The message consoles also assisted in understanding the interaction between the PRIME client, the BluES’n client, and the PRIME+BluES’n server. The development of the BluES’n system on the Java platform makes it suitable for deployment in many computing environments. This makes it easy for organizations to roll out the BluES’n system on servers and desktops. The networking requirements can be elaborated through a list of network ports used, which may be necessary for configuring firewall settings.



2.10.3 Support Requirements The detailed documentation makes the BluES’n system and document portal a good starting point for an open source project. The meeting with evaluators in Dresden was an opportunity for user involvement and co-development during the system development process.

2.11 Social/cultural evaluation – operational and functional aspects

For the purpose of the social evaluation we will refrain as much as possible from evaluating the merits of BluES’n as an eLearning environment and focus on the interaction between the PRIME console and the concept of privacy-enhanced online learning. Also, general observations as provided in previous evaluations (like the ability of the software to adapt symbols and text to local cultural and language settings)5, will not be repeated. Given the constraints of the present evaluation, we were not able to test the BluES’n environment and PRIME in a multi-user setting. The effects of the use of PRIME to protect identity information from other users of the eLearning environment could therefore not be assessed.

Central to the social evaluation is a focus on the choices with respect to the disclosure of PII the various actors in the eLearning scenario can make. The evaluation is centered around these moments of choice.

Although the choice to develop an eLearning scenario was not based on its market potential (see section 2.1), identity management can be useful to be applied in a learning environment. Acquiring knowledge and skills can give a person prospects on more wealth, social status and power over others. It increases his self esteem. Most education experts, however, also agree that effective learning benefits from a protected environment in which people can make mistakes without being afraid for the consequences. The more vulnerable a person dares to be, the less afraid he or she is to make mistakes, the more effective he or she might learn.

On the other hand, the process of learning also might uncover peoples' imperfections. Others might take advantage of these vulnerabilities. Therefore privacy protection within learning may be of importance:

• The choice of a course might show that a person considers this a lack in his current knowledge and skills (entrance knowledge-skill level).

• It also reveals information about peoples interests in certain courses or training programs (interests).

• During the course, others might discover the real amount of talent a person has to learn certain knowledge or acquire certain skills. In an eLearning environment, analysis of the click paths and log files might also reveal much about learning habits. (talent)

• Others might discover how people really react on interactions, or how people deal with alleged mistakes (character).

• If the course results are shared, people have the tendency to connect social consequences to the differences in grades (exit knowledge-skill level).

The privacy requirements for students, teachers, and other actors involved in the learning process vary (see the Appendix A.4 for a brief analysis). A privacy enhanced eLearning environment should be able to cope with these different requirements. The evaluation of the BluES’n/PRIME environment from a social perspective explores this requirement. We identify several stages where privacy is a consideration:

5 See, for example, the PRIME deliverable Requirements V1 document: pub_del_D1.1.b_part1_ec_block1_v3_final.pdf



1. orientation

2. enrolment into the e-learing course

3. course interaction

4. testing and grading the students skills and knowledge

5. issuing/receiving a certificate

6. evaluation of the course

In each of these stages, both the student and the teacher can make choices that influence the disclosure of privacy sensitive information. As the stages build on each other, the identity management should be approached as a consistent concept: a flaw in one stage has direct effect on the privacy protection and possibilities of identity management in the next stage.

Stage 1: Orientation

In the orientation stage, a potential student collects information about eLearning and other courses. This leaves identity data online and/or offline. The general PRIME privacy protection concepts can be applied in this stage. However, as this phase is not embodied in the current prototype it will not be evaluated.

Stage 2: Enrolment

From the user's point of view, the enrolment into an eLearning course is the first real moment of choice where privacy sensitive information can be revealed to the eLearning provider or third parties. The BluES’n prototype currently does not provide an enrolment procedure or module. Therefore evaluating the PRIME abilities to conduct identity management in this crucial stage for revealing and managing privacy sensitive information, does not make sense. Because of its importance from a privacy perspective, we recommend that the enrolment phase be included in the next version of this AP.

After the enrolment into a course, a student gets access to an eLearning environment, probably by means of a user name and a password. While logging into the BluES’n system, a password screen appears for the PRIME console. The function of this screen is not immediately clear: the help button does not provide context sensitive help on the questions users might have while logging into the system:-

- Why this login screen/

- Am I logging into PRIME or into BluES’n? (is there a difference?)

Creating a workspace:

It is, for a just-enrolled first-time user, not clear how he or she can create his/her own workspace. A kind of wizard might be helpful here.

Selecting an eLearning course:

Also selecting a course is not an obvious step yet. It is not clear to what courses the student might have access and to what extent the eLearning environment provider can trace click paths connected to the username.

Stage 3: Course interaction

Because of the inability to test the prototype in a multi-user environment, we were only able to evaluate some user aspects in a self study course. Testing the prototype in a guided class or a dynamic group learning environment was impossible with the means and technical knowledge. The same for synchronous and asynchronous learning and working.

Stage 4: Testing and grading the acquired student skills and knowledge



According to the handbook documentation, the BluES'n eLearning environment is designed to provide a function to assess learning results in the predefined workspaces for 'self study' and 'guided class'. It is not clear to us if this functionality is only meant for self assessment of learning progress, or that it can also be used for testing and grading the results of students in order to grant them rights (on a certificate or to access a next course level). The functional model for the Assessment of Learning Results module is, however, not realized in the Application Prototype version 1. The consequences of disclosing privacy sensitive information about exit knowledge or exit skills levels can therefore not be evaluated in this context.

Stage 5: Issuing and receiving a certificate

In the current application prototype in combination with the BluES’n eLearning environment there is no functionality for grades management or the communication about grades, certificates and/or diploma’s. It is therefore not possible to evaluate the application prototype in a setting in which the protection of privacy sensitive information has to be combined with the necessity to verify the identity of the student who is about to receive a certificate or diploma.

Stage 6: Evaluation of the eLearning course

Evaluation of eLearning courses is crucial for a professional development of the courses. The moment of evaluation is also a moment whereby the access to identity information of the assessors might influence their openness about their experiences. Depending on the shaping of the course evaluation process, privacy protection can be very crucial. The BluES’n application prototype environment does not (yet) provide a module for course evaluation. It will therefore not be evaluated.

2.11.1 Recommendation The positioning of PRIME in eLearning privacy protection and the use of PRIME can be a decisive argument to convince potential students to use an eLearning environment. It will especially appeal to people in social groups that are anxious to share their learning interests and abilities with others. This will often be in social environments where people value the possession of knowledge very high and the activity to acquire knowledge very low.

For that reason the privacy aspects of a PRIME-enhanced eLearning environment seem less convenient for use in a learning setting with under-aged children. The privacy management might easily intervene with the responsibilities of parents for the education of their children.

In promoting the PRIME concept in eLearning environments it is however important also to position the use of PRIME in all identified stages of the learning process, from orientation and enrolment to issuing certificates and evaluation of the attended course or program.

2.12 Social/cultural evaluation – other aspects The installation, documentation, platform and support requirements are not evaluated from a social perspective as no social context could be created (nor was it useful to do so) for the present evaluation. The documentation and installation procedures are primarily aimed at PRIME insiders and PRIME evaluators. With these user groups in mind however we have assessed the documentation, support website and installation.

Documentation

The documentation appears to be well taken care of. Outsiders of the PRIME project may need more explanation on the following topics in the BluES’n handbook, though:

• The PRIME concept of identity management: Why is it important and how does it work in general (paragraph 1.2.2.)

• The BluES’n eLearning concept (paragraph 1.2.1)

• The combination of PRIME and BluES’n



• The installation process. At present, a reader is advised to visit the installation pages on the BluES website. This is not user friendly: people have to open and read different documents at the same time to get the prototype running.

We also recommend a paragraph in chapter 5 for a first time user configuration scenario that should lead him through the popup screens that determine the initial PRIME and BluES’n configuration up to the moment he can see his personal workspace. A software wizard could of course replace this paper based guidance.

Support website

The support website for installing the application is simple and relatively clear for the use by PRIME insiders. The only confusing thing we noticed is the configuration file update. It is not clear who needs to update this file. If this applies to all users, then make it part of the downloadable application files. If not, make clear on the website who should update the configuration file and who might skip the download.

Installation

The installation process went relatively flawlessly. For distribution among bigger groups and outsiders a more elaborated introduction on what is happening and why things are happening might contribute to the comprehension of the BluES’n eLearning environment and the PRIME console.

2.13 ICPP Privacy Seal evaluation Complex 1: Fundamental Technical Design of IT-Products and Complex 2: Legitimacy of Data Processing

The extended use of pseudonyms in the BluES’n System shifts the processing of (identifiable) personal data to the PRIME platform. The following remarks assume that the currently known implementation problems of pseudonyms (e.g., copy & paste workaround between the PRIME console, multiple generations of equal pseudonyms, the lack of cryptographic strong credentials) will be solved in the next version. This includes also the PC resources consuming implementation.

In case that BluES’n plans to offer test/exam-taking, it should pay attention to the following recommendations: It could be necessary/desirable for a learner to act as an identifiable person or have access to an instance which is able to de-pseudonymise a user’s action: E.g., a user might wish to take a test or an exam using a pseudonym, but to receive a certificate proving her/his knowledge stating her/his name. In this case, the functionality of BluES’n might to be extended in case that “multiple exam taking” of a user and choosing of the best exam result for requesting a certificate is forbidden by a policy (as this is the case for final university exams): Before presenting an exam, the BluES’n system needs an answer to the question “Did the current user already take that exam”. This could be done by checking whether pseudonyms of users that already have taken the exam belong to the current user. In this case, pseudonyms would have to be checked whether they are linked or not, preferably by the PRIME platform. Such a “link check” has to be made transparent to the uses taking an exam. Otherwise mechanisms as one-time-credits or electronic coins would be necessary. Under the assumption that de-pseudonymisation are not possible and that BluES’n can not track users by their IP addresses (e.g., by using anonymous IP addresses), BluES’n do not need legal permissions to process theses data.

Up to now, a functionality to log chats has not been implemented. Such a functionality will be critically in two ways: On the one hand, everybody participating on a recordable chat has do be aware of the fact that a recording takes place and that caution might be necessary in order not to release personal identifiable information (such as phone numbers) which would be stored a long time. One the other hand, a long-lasting recording of chats might lead to the linkage of different pseudonyms of a single user if an analysis (e.g., of common typos or style of writing) identifies different pseudonyms.

Complex 3: Technical-Organisational Measures: Accompanying Measures for protection of the data subject



It is not clear who operates the BluES’n system and whether parts of the system are operated by a third party (e.g., somebody hosting servers). In the latter case, it will be necessary to instruct the operator in cases that he must implement security mechanisms (e.g., logical and physical access control to server hardware and software) as they are named in the file ThreatAnalysis.doc.

Complex 4: Rights of the data subject

If no personal (identifiable) data are stored in the BluES’n system, there is no legal obligation to implement mechanisms for deletion, correction or notification of such data. Of course, they are desireable.

In conclusion with respect to the requirements of the Privacy Seal for IT-Products, the eLearning module processes only pseudonymous data (up to IP addresses). If new functionalities such as the de-pseudonymisation of exam-takers or a reputation system (e.g., for judgement and evaluation of tutors or authors) are implemented, a closer look is necessary.



3 Airport Security Controls Application Prototype

3.1 Descriptive Summary The Airport Security Controls Application Prototype is intended to test the application of privacy principles (both those of PRIME and those of the Data Protection Directive) in the very challenging setting of airline and airport passenger processes between check-in and boarding the plane, including the mandatory security controls. The challenge of the prototype is to enable a traveller to enrol in and use an airline’s trusted traveller programme, which, for reasons of using automated processes, must include biometric checks (so as to verify that the physical person travelling is really the “trusted” ticket holder) while respecting the principles of privacy and data protection. Refer to Appendix A.5 for a summary of the means in which this AP’s design addresses those principles. Additional functions foreseen in the application scenario, particularly the “data vault” which is intended to maximize the privacy of such personal data of the traveller as may be required by destination countries, have not yet been implemented.

The ASC prototype consists of two principal components: enrolment and airport checks. The enrolment component uses the PRIME Integrated Prototype V1, and enables the trusted traveller to enrol for the programme on-line at an airline website. In the course of this enrolment, the would-be trusted traveller has to supply much information to the airline (including affidavits or credentials) in order that the airline can fulfil the obligations imposed by public authorities. The enrolment also includes the capture of some passenger biometrics, of which a template is subsequently encrypted on his “trusted traveler” card. Generally the “trusted traveler” card functionality will be contained on the same customer card which most frequent travellers hold already and which is used for automated check-in (E-Tix) schemes. As evaluated, this component of the ASC prototype only uses a limited range of functionalities of the IPV1, but it demonstrates how it would be possible to extend the range of functionalities used.

Once the traveller comes to the airport, he interacts with a system which does not use the PRIME IPV1. Instead he confirms his identity through supplying biometric information, which is stored on his “trusted traveller” card (NOT on the central system). At the check-in stage, the traveller may either be provided with a paper boarding card, similar to the one currently issued by E-tix machines, or a virtual boarding card, by which the airline/airport system would link his “trusted traveler” card with a certain flight to be boarded or (an optional solution) with an RFID boarding chip that simply holds a code which corresponds to his flight and seat number. He then proceeds to the Passenger Restricted Area entry stage, and then to the gate stage. At each stage of verification in the airport, his biometric data is compared to the data on his “trusted traveller” card, which is in turn checked against his boarding card, (which may be either conventional or virtual or in RFID form). The systems he interacts with therefore have no need at any point to hold his biometric data (though for obvious physical reasons they have to collect these data and pass them through to the card for checking).

As stated in Chapter 1, this AP was chosen to test the compatibility and integration of the PRIME principles with real-life identity management processes and interactions between users and services; its limited usage of the PRIME IPV1 is compatible with that intention.


The PRIME IPV1 components were used in the part of this AP in which the intended trusted traveler is informed online about the service offered. It was found that some of the settings required conflicted with other web services running on the same server, and this was solved by running the information service on its own server. The general impression is that IPV1 covers much more than is needed by the current ASC AP.




3.3.1 Scope and focus This evaluation covers the usability of the ASC AP as far as it can be evaluated in its current shape. All steps in the AP are only functional on site in Ispra, Italy, and therefore the major part of the evaluation is based on the HCI evaluator’s analysis during the evaluator December 2005 meeting in Ispra. Consequently, the only involvement of end-users has been to test the wording on the trusted traveler webpage and to some extent a screen capture of the enrolment form. The five test persons were selected by convenient sampling and they were asked to state if they understood the purpose of the trusted traveler scheme, after reading through the webpage, and if they thought it would be a usable service.

No formal test report was set up since the data collection was very simple (ad hoc) and the results as a whole can be presented in this report.

3.3.2 The Olympischen Luft website The website can serve as a first draft to the final version. It suffers from several obvious design flaws that ought to be easily repaired to get the page in a more usable status. The colouring and the presentation layout are probably the most crucial parts to reconsider first.

The Privacy Policy seems to be a copy from Lufthansa, since they are mentioned in the paragraph “Data Protection Declaration”. Test users had no comments on the policy.

The page that informs about the trusted traveler program did not result in any particular criticism from test users, only minor language remarks and comments about the layout. Some test users wondered about the last sentence on the page, that says:

YOU CAN CONTROL OUR PAGE WITH YOUR PRIME

PRIVACY ENABLED BROWSER.

YOU MAY USE PSEUDONYM FOR THIS TEST. This function is not implemented in the AP. The only justification for PRIME-enabling this web site would be to help the user to test which personal data items need to be disclosed to the airline when applying to be accepted as a trusted traveler and how the airline’s privacy policy conforms with whatever privacy preferences the user has selected in his user-side PRIME console. The utility of this for a demonstrator application might be questioned. In any event, only when that functionality is present in the AP, the text should be put on the webpage.

3.3.3 The enrolment form The test users did not have any apparent usability problems with the enrolment form. It is only a screen dump of the actual enrolment form and therefore cannot be interacted with. If a more functional mockup had been used the test results may have looked slightly different. On the other hand, responses on the screen shot were not alarming in any case so the evaluator took the decision not to put any work on getting a mockup running.

Future end users will be the employees at those airlines that will implement the trusted traveler scheme, and they will probably receive training by the company in order to use and understand the software in the enrolment phase. When the AP is mature enough to be properly evaluated the enrolment form could be tested more thoroughly with representatives from the appropriate user group.



3.3.4 Other usability issues in the prototype To ensure users’ awareness regarding the functionality of the smart card (and the optional RFID tag to be included in the case of selection of that option for the boarding card), the information on the website will not be enough. This issue must be addressed before the AP is finalised. A first step could be a leaflet provided to every frequent flyer that applies to become a trusted traveler along with a thorough verbal survey at the application desk. It would also be interesting to see the agreement signed between airline and customer to evaluate its intelligibility.

The test persons that were put to the website had all been to an airport but were in general non-frequent flyers. Even so they understood the purpose and intent of the trusted traveler scheme and thought it to be a nice service.

3.3.5 Recommendations Make it easier to manage the devices: Once a trusted traveler it should be easy to manage and understand the devices used to read the biometrics, the RFID tag, and the smart card. Feedback from the Ispra session shows the need for clear statements regarding the amount of time needed at every device, for example:

• Put your smartcard in the device for 10 seconds

• Press your finger against the device until the verification is complete

That would surely improve usability for first time users.

3.3.6 Conclusions Since the prototype was so immature, the only involvement of end-users has been to test the wording on the trusted traveler webpage and a screen capture of the enrollment form. The test persons had no major usability problems with the wording or the enrolment form, but more testing is recommended when the prototype is mature enough.


3.4.1 Documentation Airport Security Controls - Application Prototype Specfication

The specification concerns the functionality and the techniques behind the AP. The document serves its purpose as an internal PRIME specification but is not valid to use as for example a user guide. Installation documents and device specifications are missing.

3.4.2 Installation and Platform For apparent reasons, a full installation of the AP has been impossible to evaluate. The website, distributed by the developers, demanded minor changes to make the links work properly. Another minor issue about the website is the form presented in the trusted traveler page. It has a nonfunctional submit button at the moment. The POST method directs it to a link that doesn’t exist in the website distribution.

3.4.3 Support Requirements From an HCI point of view there is no obvious need for support to end-users regarding the functions in the AP other then the usual airport staff, that helps all travelers to feel comfortable at the check-in, Passenger Restricted Area, gate etc. The support to the airlines implementing the service will probably be more considerable and challenging, at least at installation and test time.



3.4.4 Conclusions The application prototype specification does not serve as a user guide. However, there is no obvious need for support to end-users, other than the airport staff that helps the travellers at check-in etc

3.5 Assurance evaluation – operational and functional aspects The Airport Security Controls Prototype is, unlike the other PRIME prototypes, not based on PRIME IPV1 components in its primary functions. Later on, only the enrolment phase will be supported by the PRIME console, but will normally be executed independently via a standard web browser. Unfortunately, the stability of the presented version of the prototype has to deal with some limitations. The problems seem to be related to the used smartcard readers or the used smartcards, which may mainly be caused by the lack of allocated resources to fix the problem. Furthermore, the scenario of this prototype is very complex and the quality of security and privacy protection depends mainly on the concrete implementation on each chosen airport and its special settings. Especially, the dependency on the implementation makes it very hard to assess the quality of the prototype without having a real working environment. Therefore, the assurance evaluators decided to comment current security functions, like cryptography and smartcard related issues, the planned features, and give some advice for future practical adoption of such a highly sophisticated system:

3.5.1 Recommendations Recommendation 1:

The management of the secret keys is the sticking point of the system6. The worst-case would be breaking or publishing of the private signing key for issuing smartcards. In that case, all issued trusted traveller cards have to be revoked and the system would have lost its creditability. From an assurance point of view, this key should be stored securely in a protected environment, separate from the enrolment office. However, this would mean to collect the passenger’s biometric data and to send it to the issuing office. Thus, the control over the flow and storage of this PII would get lost and the passenger would have to trust the airline that this data will not be stored persistently or used otherwise. The ASC team should enhance the scenario on how to deal with this problem.

Another point of attack is the storage and protection of the keys used at the check-in station for writing credentials.

The problem is that the verification of the passenger later on is not based on the originally proved biometric data. It is rather planned to grant rights by inspecting credentials that have been uploaded during the check-in process. If the corresponding keys for signing, writing and encrypting such credentials are not well protected or get published, an attacker would be able to grant someone access to the Passenger Restricted Area by using his own biometric characteristics combined with the passport details and the booked flight of the other passenger (which includes stealing the boarding card). Therewith, access would be granted to the gate and boarding area without having an indication that this person is not the one he or she pretends to be. Unfortunately, these (especially signing) keys have to be available at each check-in counter, which will make protecting them carefully very challenging and difficult, taking into account that check-in counters are shared with other airlines. A possible solution would be to change these signing keys from time to time. Recommendation 2:

6 Some details about the use of cryptography used in the scenario can be found in chapter 8 of the “Airport Security Controls” Application Prototype Specification.



Currently, it is planned to leave the decision of the protection of the Smartcard by PIN up to the holder of the card. Furthermore, according to the ASC team, it is planned to combine the smartcard with a payment function like it is provided by VISA. Therefore, at a point of sale the holder has to hand over the card to sales personnel and loses the direct control over his card. If a reader key has leaked, the sale clerk could therewith authorise himself to the card. The consequence would be that attackers might get access to PII without the knowledge of the holder. The utilisation of contactless smartcards might increase the risk additionally. Consequently, mandatory protection of the card by PIN is recommended. Recommendation 3: From a technical point of view, it seems reasonable to prefer smartcards that can only be used while having direct contact to the reader instead of using contactless smartcards. This would, among other previously mentioned reasons, ensure that the reader could only communicate with the card while having direct contact. Furthermore, during the demonstration session it was problematic for the readers to have more than one contactless card located next to them. Recommendation 4: A result of the discussion with the ASC team is that it is an option to substitute parts of the passenger body control for participants of the trusted traveller program. One example was to reduce the rate of special security controls of passengers. The assurance group does not agree that a participant of such a program is more trustworthy than normal travellers. This aspect is seen as very critical, especially considering the latest regulations, like the Commission Regulation (EC) No 1138/2004 of 21 June 2004 establishing on how to protect critical parts of airports. The enhancement of convenience for participating travellers must never reduce the aimed security level. Recommendation 5: Up to now the iris scan is not in use. Therefore, the only working authentication mechanism is fingerprint scanning and comparison to the deposited credentials and schemes stored on the smartcard. It is strongly recommendable to add other authentication and identification mechanisms to avoid known problems of such systems:

a) High false rejection rates (This might be due to insufficient characteristics on fingertips.) b) High false acceptance rates (Characteristics of fingertips may be forged or there may be

insufficient characteristics on fingertips.) The first of these might be only a question of loss of convenience. The second, however, has to be taken much more seriously because unauthorised persons might get access to Passenger Restricted Areas. The error rates actually experienced depend on the scanner itself and its configuration. If biometric systems are chosen for granting access to critical parts of the airport, other safeguards like presenting the passport should be considered. Recommendation 6: Up to now it is not transparent, which kind of PII is stored, processed and deleted within the trusted traveller scenario. The assurance recommendation is that this has to be made available to the potential users to support their sovereignty and to assess whether they want to join the program, or not.

3.5.2 Conclusions The stability of the prototype system might only be a matter of time and should be solvable. The mentioned problems related to the management of the different keys will be much more difficult to solve in a living environment like an airport than it seems to be in the first place. Therefore, the assurance group recommends improving the scenario by some clarifications of deployment details. The replacement of official ID documents during the travel scenario is associated with many problems that may countervail the advantages of the approach as it is drafted at the moment. A reduced amount of functionalities may help to improve the scenario.



3.6 Assurance evaluation – other aspects The assurance evaluators do not have any comments, neither concerning the installation or platform requirements nor regarding support requirements of the prototype. Their only contact to the ASC prototype was the evaluation meeting hosted by the JRC in Ispra. During that meeting, the evaluators had the chance to observe performances accompanied by explanations by the ASC team.

3.6.1 Documentation The documentation of the airport security prototype would benefit from deeper analysis of possible security and privacy threats and from dissecting how endangering of the system is preventable. Especially the question how to organise the key management of the underlying cryptographic solutions needs some clarification. During the evaluation session, the ASC team declared that the documentation of the key management and the protection of the keys were not deemed necessary for an adequate evaluation. Hence, the evaluators had to deal with the provided input. This circumstance certainly limited scope and quality of the evaluation. In general, the ASC team has not followed the evaluation guideline provided by the assurance group. This basic guideline would normally cover the basic required documentation:

• High-level design • Implemented security functions • Threat analysis, countermeasures and the strength of the implementation • Test plans

Completely missing are the last two bullet points. Without these inputs, it is nearly impossible to assess the quality of the delivered prototype. One example is the utilisation of RFID chips in general. If all passengers get a boarding card containing an RFID chip that responds to interrogation requests, it would be possible to track the carrying passengers. If only trusted traveller passengers are using this kind of boarding cards additionally an allocation gets possible for an attacker that this passenger is a trusted traveller. Unfortunately, the documentation does not provide any information about that aspect of the system. Because airport security is a highly sophisticated and complex subject, the documentation is often quite ambivalent and leaves a lot of space for adaptations to different possible scenarios of how to deploy a similar system at a real airport.

3.6.2 Conclusions The recommendation of the assurance evaluators is to choose one typical, easily manageable setting of an airport and try to detect possible threats to the planned setup. Starting from this point, other airport-scenarios and use-cases may be adapted gradually.

3.7 Legal evaluation – operational and functional aspects The legal evaluation of the Airport Security Control prototype raises some legal issues related to its implementation in a practical environment, as regards the respect of European Law7. The evaluation reviews the most significant issues associated with the prototypes, which relate to the use of biometric technologies and specific issues arising in the different phases of the prototype. However, it must be underlined that the implementation of some phases of the prototype could also vary depending on factors peculiar to airports in which the prototype could be developed in a real experimental context.

7 The legal background has been developed in previous PRIME deliverables (i.e. Requirement V1, Framework V1, as well as in deliverable Evaluation of early Prototypes) and is therefore not repeated here.



Moreover, an evaluation of a privacy statement’s model and agreement contract’s model has not been possible in this version, the application prototype being in its first evolution.

3.7.1 Biometrics: the proportionality test As a general remark, the legal evaluators are wondering whether it would not be useful for the developers to include in the description of the scenario the (possible) interaction of the trusted traveller card with the passport with biometric identifiers that will soon be used in all airports8. This may also have consequences for the proportionality test. The prototype foresees the use of two biometrics (i.e., fingerprint and iris) as part of its implementation. Measures of biometric identification (raw data) or their digital translation in a template form are, in most cases personal data9. Therefore an evaluation of the respect for proportionality and the respect for legitimacy must take into account the risks for the protection of fundamental rights and freedoms of individuals and notably whether or not the intended purpose could be achieved in a less intrusive way. Different decisions by DPA exist on the interpretation of this principle in the use of biometrics:

- Although the use of iris scan of frequent flyer card holders for Airport control has been authorised in the Netherlands10 and the use of fingerprints of passengers in France11, two decisions from the Greek and the Italian DPA12 on a proposal similar to the ASC concluded that the collection and processing of both iris and fingerprint data for the verification of passenger identity in specific flights was not deemed lawful, even within a voluntary scheme. The reason was that the purpose sought (facilitation for frequent traveller) is achieved in a milder way with the passenger showing the identity card along with the ticket and the boarding card. Besides, the method provided for did not mainly serve flight security requirements but organisational issues of airline companies instead. Therefore, there is a serious risk that the use of biometrics in the implementation of the prototype in a real world environment would not be deemed proportionate, once it would be submitted to the authorisation of the relevant Data Protection Authority. We would advise the developers to adapt their prototype in a way that not too intrusive biometric systems are in use.

- It must also be underlined that the accepted systems only involve airports and no air carriers, the system being only allowed within this delimited area. It is unclear whether the deployment of such technology by an airline company would receive a different interpretation.

3.7.2 Enrolment phase This phase plays a key role and presents more risks from a security and data protection point of view because it is the only one in which raw data, extraction and protection algorithms (cryptography, etc.) and templates are all simultaneously present. It is also at this time that the right of the data subjects can best be enforced (information, access, correction, erasure, objection to processing) and there that the data subject would give its informed consent to the processing. However, it is not clear what happens with the raw data and if there are appropriate remedies to cover the security risks involved. Moreover, although it does not appear from the presentation of the prototype, the two processes (data capture and the approval of the agreement) can only take place in the respect of the relevant data

8 Council Regulation (EC) No 2252/2004 of 13 December 2004 on standards for security features and biometrics in passports and travel documents issued by Member States”, which states that Member States will have to introduce such passports within 3 years. 9 Working Group 29, Working document on Biometrics, WP80, 1 August 2003, p. 5. 10 The Privium system was approved by the Dutch Data Registration Authority and has also been recognized by the Ministry of Justice and the Koninklijke Marechaussee as satisfying all the security requirements. 11 See CNIL advice (10/02/2005) on the testing of the PEGASE system in one terminal of the Charles de Gaulle Airport and CNIL decision (07/06/2005) on the testing of a loyalty scheme at Nice Airport. 12 Decision 52/2003 of the Greek DPA and point 38.1 of the 2003 annual report of the Italian DPA



protection laws and the legislation regulating national border controls13 (reference is made, for instance to the rules from the Schengen acquis). The reason is to enable the border police to perform its duties in the respect of the existing legislation.

3.7.3 Check-In and RFID tags The proposed boarding pass, embedded with a RFID tag might also prove to be at risk. The prototype proposes that the RFID tag number be stored in the passenger’s credentials on the smartcard for future crosschecks. However, in case of security leak of the smartcard and clandestine scanning of the RFID, one could possibly make a connection between the information in the card and the RFID tagged boarding pass. Data protection rules would then have to be applied, although not foreseen at the beginning14. Moreover, in the above situation, if tagging of boarding pass makes it possible to compartmentalize the airport by scanning the tags in the boarding pass at certain locations, the use of information from the localisation of the passenger within the PRA should also be strictly assessed and would also depend on the accuracy of the localisation. Regarding the protection of the encryption of the passport and biometric layers, contact-less systems are more susceptible of attacks and the use of a PIN, presented as an optional function would certainly enhance the security of the system and the control that the passengers have on their data.

3.7.4 Passenger Restricted Area, Gate control and Boarding Control of access to the PRA and gate control by means of both biometrics and RFID tags seems to be a disproportionate measure in regard to the existing PRA procedure. Moreover, access to restricted area of airport is submitted to specific provisions15, which would still be valid with the proposed system. With the data vault concept, a possibility is to propose to the trusted travellers to enter themselves the data (PNR) which could be required on specific flights (i.e. to the US). They would use their smartcard, which would be loaded using a personal reader at home. This seems, at this stage difficult to implement, unless specific and appropriates measures are taken to allow a clear follow up of the process. Moreover, the storage of data required for PNR and data which are not necessary data should be done in two different parts of the relevant layer, as to avoid processing of more data than necessary.

3.7.5 Conclusion In conclusion, the ASC application prototype may face some risks. We believe that the use of biometrics based on both iris scanning and fingerprint should be considered with great attention, as it is likely not to fulfil the proportionality principle. Other alternatives should be studied for the purpose of the trusted traveller’s scheme. Moreover, we estimate that the prototype does not implement the main components of the PRIME architecture, as developed for the Integrated Prototype. Besides, the complexity of the prototype itself does not facilitate the comprehension of the different mechanisms involved. Clarification should be made. This should also be one of the next steps of development. Finally, security aspects of the system have to be carefully monitored and are important aspects in the development of the smart card.

3.8 Legal evaluation – other aspects The version of the prototype submitted to the evaluators as well as its technical specificities was agreed during the evaluators’ meeting on the 16th of December 2005. Therefore, this version is the one considered for the legal evaluation. 13 Called ‘background check’ in the prototype. This background check should not be an a-posteriori checking but should be performed before the processing of biometric information. 14 See WP105 document on data protection issues related to RFID technology, Art. 29 Working Party. 15 See for instance Commission Regulation EC 1138/2004 and 2320/2002.



3.8.1 Installation Given the particular implementation of this application prototype (departure control for trusted travellers) and the environment in which it is intended to be developed (airport environment), no computer installation has been necessary to carry on the presentation of the AP, nor was it necessary for its evaluation. The developers set up a practical presentation for a fair and correct comprehension and explanation of this AP. This presentation of the AP does not create a specific problem for the legal evaluation, being understood that sufficient documentation is provided to evaluate the AP from a legal point of view.

3.8.2 Documentation The developers provided a link to a web page as well as the required deliverable (title: “Airport Security Controls”: Application Prototype Specification, hereinafter the documentation). Moreover, two additional presentations were made available to the evaluators during the presentation’s meeting in Ispra. The deliverable gives a precise overview, step by step of the different phases present in this AP. Some additional information regarding the use of Cryptography and Data Structures (especially regarding the smartcard status database and the departure control system) are also provided. However, it must be underlined that during the evaluation, the PRIME technology or components were missing in the Airport Security Control prototype.

3.8.3 Platform requirements As already mentioned in the installation paragraph above, no installation on computers had to take place. However, for the presentation of the AP, a mock-up presentation on computers was provided by the developers on four desktop computers. According to the documentation, the clients (enrolment, check-in, PRA and boarding) ran under MS Windows and the server (departure control system) ran under Linux. The presentation also included a fingerprint sensors and RFID readers. An Iris scan is also part of the prototype. Regarding the Iris scan hardware (using LG Iris EOU 3000 model), although it was not usable during the evaluation, it is considered as one of the most widespread and reliable Iris scan on the market.

3.8.4 Support requirements As no test has been organized before the AP meeting, support was mainly provided during the presentation session of the AP. A specific session was also held between the legal, assurance people and the developers in order to discuss different legal points and questions which could occur for this prototype and which allowed a better understanding of the goals of the prototype.

3.8.5 Developer’s trial The trial took place in Ispra at JRC premises on the 15th of December 2005. The prototype is based on 5 phases, whose four were proposed to the evaluators during the trial (the gate phase being a subset of the PRA phase):

- Enrolment

- Check-In

- PRA



- Boarding Different high technologies are used in the prototype, which have different legal consequences (analysed in the evaluation report):

• In the enrolment computer: a fingerprint sensor, iris scanner and a smartcard reader.

• In the check-in and the PRA computers: a fingerprint sensor, the smartcard reader and the RFID reader.

• In the boarding computer: a fingerprint sensor, the iris scanner and smartcard reader. The interactions between those technologies proved to be successful during the first trial conducted. However, some problems (bugs) appeared with the smartcard reader, when used in a second time. This may only be a stability problem of the prototype and could probably be fixed.

3.9 Economic evaluation – operational and functional aspects

3.9.1 Scope and Focus The scope of the economic evaluation of airport security controls prototype is limited to the foreseeable conditions within airline and airport operations through discussions with Lufthansa. The focus of the evaluation is on whether the prototypes currently at an early stage of development meets the business requirements for future business deployment. A business case is developed to help business decision-makers assess the financial implications of the proposed solution. The business case in 3.9.4 details the expected cost and benefits of the prototype using the best estimates available. Further work is required to translate the intangible privacy benefits to quantifiable figures with the assistance of the application providers. The business case also focuses on benefits for the airlines. Other stakeholders in the network such as passengers and airports are not included in the current version.

3.9.2 Privacy and Identity Issues in Air Travel Traditional airlines have developed sophisticated customer relationship management systems as part of their frequent flyer clubs programmes. The privacy of air travelers is under increasing scrutiny as regulatory requirements for tighter security controls and passenger checks are implemented. The demand for technological solutions to facilitate the flow of passengers in airports under the new circumstances are well established. Schiphol and Orlando airports have introduced solutions involving biometric identification for expediting the processing of frequent travellers. The airport security controls prototype was constructed to satisfy such demand, and to incorporate additional privacy enhancing features from an airlines perspective.

The use of biometric technologies in airport security controls not only improve security but help in the long term to substantially reduce costs. However biometric implementations have been blocked for not being privacy compliant, examples are the failed trail test at Athens airport within the S-Travel project, or the concerns raised by the French authority. An Airport Security Controls prototype constructed to comply with privacy legislation can improve the chances of acceptance. Biometrics solutions respond in general to the more stringent regulation and requirements in terms of security in air travel. Vis-à-vis growing passengers flow the introduction of technologies seems to be a must rather than an option. The use of biometric technologies to improve safety and simplifying passenger travel is due to become widespread in the next few years.

The transfer of passengers’ personal details currently mandated by regulation can be become more intrusive as a result of new passenger screening requirements. For airlines to comply with new APIS+ requirements, some airlines and travel agents are entering destination addresses as part of the booking process, which can then available to other booking agents. For airlines to comply with such requirements during check-in would increase the time spent processing passengers during the check-in



process. The consequences are increased costs for check-in and additional liability should the data be misused.

3.9.3 The Market Players A brief overview of the market players in airport security controls is provided below. The solutions deployed at different airports in collaboration with different technology partners utilising different biometric technologies is shown. These solutions provide fast track access lanes for “trusted travellers” which do not incorporate privacy enhancing features. A brief summary of the enrolment fees and specific features are described in the table below. A more comprehensive description of the market for airport security controls can be found in the business case in 3.9.4. Airport Biometric

Technology Used

Target Users Description

Schiphol, is Europe's fourth-busiest airport, with about 40 million passengers a year. Privium Programme Status: Deployed Use: Check-in-Immigration

Iris Recognition

All citizens of European Union, versus payment of a fee (55€ - 119 €) Currently 20.000 enrolled

Biometric Data stored in 15 minutes session on a card (no central database). Passengers can use business check-in counter irrespective of the class they are travelling. Fast track access lane for subscribers, random check of tickets. Project owned by the airport in partnership with 18 airlines. Investment: Unknown Results: immigration procedures cut to11 seconds for passengers on the programme16

Singapore Changi Airport Fully Automated Seamless Travel (FAST) Status: Deployed Use: Immigration

Fingerprint Technological Partner: LG's IrisAccess platform

Open to all Singapore residents (The card costs 30$ for three years)17

Biometric Data stored in a card provided at enrolment. Authentication of identity will be done at a one-stop kiosk in the FAST lane, where the traveller can check-in, select seat allocation, collect the boarding pass and clear immigration from a user-friendly interactive touch-screen monitor Investment: Unknown Results: one stop check, time reduced from 15 to 2 minutes

Dubai International Considered the Middle East’s premier and busiest airport, in 2004, a total of 21.7 million passengers Status: Deployed Use: Immigration

Fingerprints Technological Partner: Biocrypt Inc.

Dubai Residents and non-residents from 24 approved countriesError!

Bookmark not

defined. (60.000 users, cost 25 £)

Biometric Data stored in a card provided at enrolment. Fast track lanes provided. Note: Entry-Exit enabled Investment: Unknown Results: time reduced to 1 minutes from original 3 – 4 minutes

Ben Gurion International Airport Status: Deployed Use: immigration

Handprint Technological Partner: EDS.

Israeli Citizens (160.000 enrolled, mostly frequent fliers, the service is provided free of charge)

Registered travellers are issued at registration a card in which biometric data is stored. The kiosk-based system uses biometrics to positively validate travellers' identities, corroborate information with security databases and print receipts to allow travellers to proceed18. Investment: unknown

16 Privium, http://www.schiphol.com/ 17 Business Travel, “Business Week”, http://www.businessweek.com/adsections/2004/pdf/0420_biztravel.pdf 18 Ben Gurion Airport Authority Security Study, EDS, http://www.eds.com/services/casestudies/bgaa.aspx



Results: waiting time reduced from as much as two hours to 10-14 seconds (not including time for use of the kiosk)

Orlando International Airport 31 million passengers use Orlando’s airport each year Name: Clear Status: Deployed

Fingerprint & iris Technological Partner: Lockheed Martin Corp. Verified Identity Pass Inc.

4000 passengers enrolled, fee (programme started in June) $79.95/year

Data stored on smart cards. Passengers can use speed track lanes in the airport. Commercial venture operated by Verified Id though a revenue sharing plan with the airport. Data stored in a database privacy assessed though regular privacy assessment from third party Investment: Unknown Results: Not specified, significantly reduced boarding time

3.9.4 The Business Case for a Trusted Traveller Scheme A business case was developed using the assumptions and known costs as provided by Lufthansa for operations at Frankfurt airport alone. The consolidated costs and expenses of operating such a systems is described in the business case. Using market assumptions in terms of pricing and enrolment, it is estimated that positive results can be accomplished when there is an enrolment fee. A sensitivity analysis serves to identify the profitability ranges according to two of the strongest assumptions, the number of enrolled passengers and the fee they are willing to pay for such a service. Assuming 15,000 passengers enrol in the “trusted traveller” program at the end of the first year, and the number double every year thereafter, the financial impact is assessed at the end of the fifth year. Without an enrolment fee, the costs savings will not be able to compensate for the costs. However, when an enrolment fee as low as 50€ (which is half the estimated enrolment with a fee) is introduced, positive results for the can be accomplished, resulting in a positive cash flow of 14 million €. With the fee-based scenario we have a return on investment of 20.7% and a payback period of 3.6 years. Additionally, with a 12.4% discount rate this case presents a strong 7.8M € net present value and have a 77.2% MIRR. Double Sided Sensitivity Analysis, MIRR Values

% of forecasted enrolled "Trusted Travellers" at the end of five years

25% 50% 75% 100% 125%20 N/A N/A N/A -0.4% 21.3%40 N/A -8.5% 27.6% 56.1% 81.4%50 N/A 9.6% 46.4% 77.2% 105.3%75 N/A 43.4% 85.3% 123.3% 159.6%

100 2.3% 70.1% 119.0% 165.2% 210.7%Enrolment

Fee

Variation

(€)

However, this case is not only about the financial benefits, but rather a combination of positive financial results plus enhancing identity management and privacy solutions. The major business issues relevant for decision-makers are summarised according to the stage of the process.

3.9.4.1 Enrolment The operation of the enrolment centre is an additional cost compared to current check-in and boarding operations at Lufthansa. This cost has been estimated to be 470,666€ on the first year including 144,000€ for renting space at Frankfurt airport. The going rate for renting square meter at FA is 400€. The cost increase per year can be observed at the cash flow analysis.

The enrolment centre capacity is estimated to handle up to 15,000 registrations on the first year of operation and have this number duplicate every year thereafter. 240K is the number of enrolled



passenger that we estimate can be achieved during the first five years of the “trusted traveller” program. The cost of enrolment per customer during the first year will be 33€. This cost is estimated to decrease in the years thereafter. At the end of the fifth year, we expect to have captured at least 1/10th of Lufthansa frequent travellers.

3.9.4.2 Check in According to the information received from Lufthansa, currently the e-check-in counters have a utilization rate of about 60%. We estimate that the “trusted traveller” program will encourage further the utilization and broaden the savings mainly by reducing check-in personnel and counter space rental.

We estimate that the program can increase utilization rate by at least 1% in the first year and twice that amount every year until reaching 10%. Therefore, the utilization will reach by means of the “trusted traveller” program a utilization rate of 70%. This translated into actual net savings is translated into approximately 7.5% fewer transactions handled through the regular counters given current ratio between e-check-in and manual check-in at Lufthansa’s Frankfurt hub. The increased utilization rate translates into fewer personnel, less rental check in counters and lower “other” IT infrastructure related costs. The figures for these savings are detailed in the cash flow sheets.

As the business case currently does not take the APIS+ requirements into consideration, further improvements in check-in time can be accomplished with the proposed solution.

3.9.4.3 Passenger Restricted Area The benefits of expedited processing of passengers as they enter the PRA and immigration controls are accrued by the passengers and airports, and hence not considered in business case, which focuses on the benefits for the airlines. The application providers have suggested additional benefits such as customer tracking once the passenger has entered the passenger restricted area. This is considered by the evaluators as currently outside of the scope of evaluation, but can be the basis for new business models.

3.9.4.4 Boarding the Plane In some airports separate lanes for boarding of passengers in the “trusted traveller” are available. The reduction in boarding time do not result in significant improvements for the airline. As a policy in Lufthansa, flights that have less than 120 passengers are attended by one gate attendant, the minimum possible as required by law. Savings at this level are considered negligible.

3.9.5 Recommendations There are significant differences between a solution relying on a centralised data base for storage of personal and one where personal details are held on smart cards. While the cost of the smart cards and the hardware and software infrastructure needed for their use can regarded as differential cost, the privacy benefits of the smart card can be further elaborated through higher project success rate, enhanced customer perception, and reduction in liability from handling of personal data. The business case can be elaborated further to take these potential benefits into consideration. Based on the results of the business case, decision-makers are recommended to continue the development and testing of the airport security controls prototype with an enrolment fee of 50€ per customer.

3.9.5.1 The Smart Card Solution A contactless smartcard was used to store personal data. This choice of a contactless solution was explained by the developers as an arbitrary choice for a “more friendly” technological solution. However, a traditional contact-based smart card may be preferred in order to demonstrate transparency to the end-user, and put them in control of their personal data.



3.9.5.2 The Identity Store In the current prototype, biometric identification such as fingerprint templates is currently stored on the smart card. While the prototype demonstrates the sensitivity of such personal details and protects it accordingly, a range of personal details could also be protected in similar fashion. Passengers should in principle be allowed manage a range of personal data using their own personal computers equipped with smart card readers and the PRIME console (or identity manager) to store and manage the relevant credentials and personal data on the smart cards. Personal details required by authorities can then be handed over only when necessary, and not go through a third party like an airline. The data track function could be used to keep track of which personal details were disclosed to which parties.

In discussions with the application provider, the notion of user-centered identity management is especially relevant when the new APIS+ requirements are implemented. Such an implementation utilising the PRIME architecture may have broader applications beyond the airport security controls. Since this feature has yet to be implemented, it falls outside the current scope of evaluation.

3.9.5.3 Federation of Identity The number of passengers enrolling in a specific “trusted traveller” program is currently limited due to the small number of airports in which the program can be used. The attractiveness of a program grows as the number of airports and airlines adopt the same standards, and accept affiliate programs. The federation of identity can create significant network effects, benefiting the early entrants to the market.

3.10 Economic evaluation – other aspects Lufthansa was very helpful in providing the basic information for building the business case. The documentation for the airport security controls contain specific detail regarding the protection of personal data on the smart cards and not always useful for the purpose of the economic evaluation. The changes in business processes before and after the implementation of the airport security controls can be documented more precisely for the economic evaluators to assess the impact. Specific information regarding the hardware, software costs would also make a more precise financial assessment. Since the prototype entailed specific hardware and was not installed locally, the documentation requirements will not be considered in the evaluation.


For the purpose of evaluating the ASC prototype from a social perspective, we will take the traveller as the principal agent. From her perspective, the scenario contains four relevant spheres: enrolment as a trusted traveller, booking a flight, check-in (which may be at home or at the airport), and the process at airport itself: (check-in) entering the passenger restricted area thru boarding the plane. This focus departs slightly from the ASC scenario as this scenario excludes the stage of booking the flight. The reason for including this step in the present evaluation is that PRIME, in our view, primarily seems to plays a role in the stage from booking until check-in, rather than in the stages after check-in. PRIME offers the user control over her PII, and this is precisely what is lacking to a large extent in the Airport Security Controls context. The data requested from the traveller in the process of travelling are compulsory and determined by external forces. Airlines need certain data for operational purposes as well as for compliancy with statutory obligations, national, European and stemming from third countries, such as the USA (e.g. the APIS+ requirements). The passenger has 'the choice' of either to disclose the requested data or to abstain from travelling. Once the data, such as date of travel, origin and destination of the flight, have entered the process, they can be inspected by a large number of organizations and individuals. The passenger then practically has lost control over her data. The present ASC scenario does not change this situation significantly. By using PRIME in the process before check-in, the passenger can determine when the data enters the process. The prospected passenger, when booking a flight, can determine that the relevant personal data is to reside within the PRIME console until check-in. The PRIME console then serves as an IDM terminal for the smartcard,



allowing the user to download the necessary data as part of the check-in procedure, instead of at the time of booking the flight as is currently the case.

The individual's control over her personal data is an essential aspect of identity management form a social perspective, and so are matters of in/exclusion of individuals in processes. We will discuss these issues in relation to the present application prototype.

User control as an important social notion transcends the legal data protection framework in which it is embedded. Jutla and Boderik [8] conveniently summarize the key aspects of user control with respect to online privacy in seven C's:

• Comprehension - the user should understand how PII is handled, who collects it and for what purpose, and who will process it and for what purpose;

• Consciousness - the user should be aware of when data collection occurs, when a contract is being formed and with whom, when their PII is set to expire etc;

• Choice - the user should have choices regarding data collection activities (opt-in/opt-out, whether to provide data or not);

• Consent - the user should typically first consent (meaning informed, explicit, unambiguous agreement) to data collection, storage and use. In the case data disclosure is mandatory, this requirement should be made clear to the user;

• Context - the user should be able to change privacy preferences according to context, situational or physical;

• Confinement - the user should be able to set limits on who may access their PII, for what purpose etc;

• Consistency - the user should be able to anticipate with a reasonable certainty what will occur if any action involving their PII is taken.

The prototype, primarily as a result of government regulation and airport and airline requirements, falls short on a number of these requirements. The limitations imposed on the user's control should be clearly communicated (in line with the comprehension requirement), especially during enrolment, but also in the later stages in the process. This clarification should be done through online means, e.g. help screens and dialogs, and by means of contracts and written documents. Although drafting proper legal documents and accompanying documentation is not part of the current prototype it is important to acknowledge that this kind of material is crucial in a real life context (see also section 3.12).

The prototype itself can also be improved in the light of the seven C's. The current RFID card can be read without the passenger's knowledge, and hence the card and its holder can be traced unobtrusively. This means that consciousness and (specific) consent are sacrificed for convenience. Although many passengers may agree to this trade-off, we feel that it would be in their interest if access to the boarding card is only granted after explicit consent, e.g. by entering a PIN code by the passenger. The prototype specification includes this option, but the present prototype does not seem to have this option implemented. The transparency of data collection (consciousness) can also be improved if contact cards instead of contactless RFID smartcards would be used, even though this would appear to be less convenient. How actual passengers value the trade-off needs to be studied. Related to the transparency issue is the issue of trust. As there are multiple card readers and systems involved in the prototype data can be collected and aggregated at various points. Can the user be sure that this does not happen, can the user trust the system?

Another important area of interest from a social perspective is in/exclusion. The ASC prototype hinges on biometrics as a means to authenticate the holder of the trusted traveller card. Biometrics have not been used in significant numbers yet, and the large scale implementation of the new European Biometrics passports starting this year, will be an interesting project. The use of biometrics from a social point of view raises at a number of issues that also touches upon the current application prototype.



We briefly discuss exclusion of parts of the population, accuracy of the process, processing time, and cultural issues. The implemented biometrics, fingerprints and iris, are not suitable for parts of the population. A large study in the Netherlands [9] has shown that fingerprints of children under 4 years of age are unusable. Also the quality of fingerprints deteriorates rapidly above 65 years of age. This means that fingerprints are useless as a biometric feature for these age groups. There are also problems with taking fingerprints from people from various ethnics groups (e.g. some Asian people hardly have fingerprints) or people with certain hobbies (e.g. gardening) or professions (e.g. building constructors). Iris data can also be hard to obtain, for instance as a result of aniridia (absence of iris, a phenomenon found in a proportion of 1.8 out of 100.000 births) or blindness [10]. This means that fall-back procedures have to be present to accommodate for people unable to enrol, but also for errors (false rejects). False acceptance and false rejections in itself pose (social) problems. Again, large scale use data is unavailable, but various studies, such as [10,11] show that these can be considerable. This has consequences both for people slipping through, but even more for people falsely rejected: they won't like being rejected, especially if this happens frequently. Frequent false rejection may be a show-stopper for users. Also the time required to perform the authentication may be an important factor in the adoption and use from a user's point of view. Scanning times can easily take up to 20-30 seconds [9,10], especially if multiple biometrics are used. Finally, one has to bear in mind that the adoption of particular kinds of biometrics is influenced by cultural factors. Fingerprint scanners (or biometric sensors that depend on bodily contact more generally) are seen as unhygienic by Japanese people, for instance, and as a consequence they are less likely to adopt fingerprints as a means of identification/authentication.

3.12 Social/cultural evaluation – other aspects From a social perspective, the setup of the ASC prototype was unrealistic as it was implemented in a lab at the JRC in ISPRA. The airport context with people waiting in line, (armed) guards and border police, time pressure, travel stress, etc, influencing the perception of users of the prototype was completely absent. The evaluators were able to book a flight using a PC on which the PRIME Console was installed. Installing the PRIME console itself on a user's machine was not considered to be part of the scope of the present evaluation. The rest of the ASC prototype required no installation on the part of the evaluators.

The documentation of the prototype is deemed sufficient from a social perspective, apart from the omissions in the documents pertaining to what data is stored and when as addressed in the previous section.

3.12.1 Recommendations The ASC scenario shows that users lose much control over their personal data once check-in commences due to regulation (APIS+ requirements) and facts (systems can be accessed by many people). The use of a smartcard or other device under the user's control to store PII and associated credentials between booking a flight and check-in offers a way to regain some control. Development of the ASC scenario/application in this direction would, in our view, be very useful.

The ASC application uses, but does not depend on, a contact-less smartcard. In order to give the user more control over her personal data and to provide more transparency a contact-based smartcard is preferred.

Biometrics are at the point of being introduced at a large scale without a clear view of the risks and benefits of such large scale implementation. We recommend to be cautious not to be over-reliant on biometrics and to consider proper fall-back procedures and alternatives as well.

3.13 ICPP Privacy Seal evaluation With respect to the fundamental technical design the Airport Security Controls prototype currently cannot be as anonymous or pseudonymous as train or bus travel in EU because of the different legal



and political restrictions airlines and airports have to follow. The implementation of the Identity Management techniques of the IPV1 was not present in the actual tested AP version. The prototype makes use of smartcards and RFID carried by the trusted traveller to store personal data for data avoidance. But at different stages, esp. boarding, these personal data are logged and stored in databases. The use of RFID chips imply the danger of automatically being tracked while caring them and identify oneself as member of the trusted traveller program. There is no information in the specification how to avoid this. It is also intransparent what is also happening on the one central server of the prototype with respect to logging and separation of data bases. For the user there is also a lack of information when using the prototype about what is happening with his personal data and his rights which could also be a problem of the legitimacy of data processing and the question of consent. For the planned transmission of data to foreign countries, a special decision by the European Commission of 2004 has to be considered. 19 This allows a non-discrimination, reciprocity and direct access for US Bureau of Customs and Border Protection to the airlines' data bases for as long as there is not an EU system in place to transfer such data. Accompanying measures for protection of the data subject are partly implemented like encryption, PIN / fingerprint authentication. Others like intrusion detection or restriction of people having access to the system are not arranged till now because of the early stage of the prototype. Questions about technical implementation of the rights of the data subject like automatic correction of wrong data and complete and irreversible erasure are not mentioned in concrete.

In conclusion with respect to the requirements of the Privacy Seal for IT-Products the general design is in line with actual regulations with only limited privacy enhancing functionality. But the prototype has lacks of transparency, information and implementation of the rights of the data subject.

19http://europa.eu.int/rapid/pressReleasesAction.do?reference=IP/04/650&format=HTML&aged=1&language=EN&guiLanguage=en



4 Location Based Services Application Prototype

4.1 Descriptive summary Location-based services (LBS) answer three questions: Where am I? What is around me? How do I get there? They determine the location of the user by using one of several technologies for determining position, and then use the location and other information to provide personalized applications and services. Some of this information is highly sensitive and belongs to the user. Different parties are interested in this information but not necessary need all of it to provide the requested service. The protection of personal information as e.g. the real name, special interests or location information is the aim of this prototype. It demonstrates the usage of a location based service while it protects the privacy sphere of an individual. It discloses the needed information after the user himself authorizes the transfer.

The LBS application prototype represents one of the prototypes that PRIME is developing. It demonstrates research results in the area of privacy enhanced IDM in a real life scenario. The initial LBS application prototype (searching for a pharmacy) is an active location-based service, which means the user himself is requesting information. In this scenario a database with pharmacies and their respective locations is maintained by the LBS application service provider. When a user requests information about the closest pharmacy to his position, his location is retrieved and the pharmacy database is queried. Then a list with the closest pharmacies is returned to the user.

The architecture behind this prototype comprises four parties, as shown in Figure 1:

Figure 1 LBS Parties

• The User who accesses the service over a WAP connection,

• The LBS application service provider which serves the pharmacy search service to the user,

• The mobile operator (MO) that serves as location source and as communication provider and



• The location intermediary (LI), which separates the mobile operator from the LBS application service provider for an added layer of privacy protection and also represents the user’s interests on the service side.

The prototype shows many aspects of PRIME and privacy enhanced IDM in a practical m-commerce environment. From it, the PRIME project is learning how it can be incorporated into a real life environment with strong infrastructural and legal restrictions.

For T-Mobile and the University of Frankfurt the prototype leads to new insights into how privacy enhanced identity management can be introduced without restricting the business models. An idea on how privacy enhancing IDM can generally be deployed within a telecommunication environment, especially as a standardized IDM management system can leverage new and efficient business models in a telecommunications environment. The prototype demonstrates, how the user is given extended control of his personal information, but is still able to use realistic/real mobile m-commerce applications.


The suitability of the architecture, the integrated prototype and its APIs for the LBS application prototype is considered in the section at hand. In general the overall framework contains many aspects of security and privacy as e.g. policies, access control mechanism, obligations, secure communication and credentials. Most of these aspects, like authentication, authorization, policy management and data track are used for the implementation of the LBS application prototype. The results point out some difficulties during its development with reference to the architecture, the Integrated Prototype and the APIs. In order to provide a better overview, we divided the identified problems in five subsections:

• Confidentiality protection

• Ontology

• Interface

• Policy handling

• General

With reference to confidentiality protection, we identified two different but related issues.

Firstly, the whole communication modules in the architecture as well as in the Integrated Prototype are experimental and produce a huge source of problems. One example that was observed regularly during the development is characterized by a mix-up of session ids when two different sessions are created at the same time. This problem has to be fixed in order to serve a high amount of users with privacy enhanced technology in a real life environment.

Secondly, the ontology itself is very inflexible which is not based on the nature of ontology but on the internal process within PRIME to get new fields in it. In our case we need additional fields within the ontology to serve LBS. Therefore we used already reserved attributes in order to map LBS specific attributes. User.Name.Given (name of the user) is mapped to Service.Name (name of the service), and User.HomeInfo.Postal.Street (home address of the user) is mapped to Service.Costs (costs of service usage). In addition we found redundant definition and inclusion of the same PII-definition file in more than one module, which could lead to inconsistent configurations. Furthermore user pseudonym (IP-address in the LBS scenario) also have mapped on other PII attributed what we identified as a lack of supporting pseudonyms in this stage of the integrated prototype.

With regard to the interface, from our point of view an abstraction library has to be written in order to overcome several problems. For instance, this library has to include a base protocol to communicate over the prime application channel which is one missing features, we needed for the LBS application prototype. Therefore we have proposed in the LBS prototype a simple request/response model over the



application channel which fulfils the requirements. After looking into the access control mechanism a lot of source code and configuration is necessary to make it simple, especially definition of new credential types requires a lot interface implementations. Under load, answers of access control mechanism are not always the same even though the transmitted data is the same. If case the transmission fails a "null" answer is sent instead of exception. Already transmitted PII disappears without any reason.

The LBS application prototype has empowered the user to handle his policies at the intermediary (one component of our architecture). The template of policies we found in PRIME are designed from a client-service/server point of view and not really suitable for managing user policies in delegation as a special trusted service provider for this purpose. The evaluation of policies that PRIME offers is too slow. It may be practicable for less than 20 policies, but in realistic environment for the location intermediary there will be over 100.000 policies necessary. Workarounds for policy handling are needed as adding, deleting, editing are not supported by the integrated prototype. Furthermore the policy expression language is not as expressive as the XACML standard e.g. modelling "or-conditions" is only possible by defining several policies.

As a general remark we can say the lack of documentation makes the usage of PRIME components very difficult. In addition a lot of memory leaks and missing cleanup-methods like "destroyContext" and also incorrect implementation of destroying a session are present. So the implementation of the prime console is a far way from usable for productive environments as for the LBS application prototype. Also a complicated build process, which is not easy to use "out of the box", is used. One major problem is the handling of module (library) dependencies. No unique handling of resources like database interfaces and configuration files is present, which leads to deployment and configuration problems.

Finally, looking at the architecture, the Integrated Prototype and its APIs for all application prototype shows us that there is a lot of work to do before PRIME it is practicable for an productive environment to empower as much as possible users to control their personal information as one of the prime principles declares.


4.3.1 Scope and focus This evaluation covers the usability of the LBS AP Pharmacy Search. The evaluation focuses especially on the privacy features in the PRIME-Console of the Location Intermediary. The results of three individual test sessions form the basis for this evaluation report. A full description of the scenario and the test tasks brought to the test users, as well as the results are presented in Appendix A.2.

4.3.2 The overall usability in the prototype From a first expert inspection of the prototype the following ideas and general proposals for improvements were made:

• It must be obvious for users that they are supposed to scroll down the window if necessary. This is not obvious in the first version of the AP.

• The main menu on the front page of the Pharmacy Locator should be visible at once when starting the application.

• The “Return to Application” link in the PRIME-Console should be replaced by for example “Return to Pharmacy Search”.

• The user interactions demanded to run the application should be made minimal since the pharmacy search is a service that one would want to reach fast.



Regrettably the suggestions could not be taken into consideration by the application providers for this version of the prototype before the evaluation started. However, the application providers managed to simulate a device with a slightly larger display than the first one. This took care of most of the major usability deficiencies. In future live versions of the prototype, however, the proposals stated still holds because of the variation of mobile devices in real life.

4.3.3 The Pharmacy Search in general In general, the test users’ beliefs in the service are strong and they could all see the use of it. The necessity to use the PRIME system, due to potential threats regarding the localization, seemed to be understood although they may have been influenced by the scenario explicitly spelling that out.

Even uninitiated non-WAP users could, with minor exceptions, fairly easily handle and grasp the system. The longest test session took about ten minutes, including introduction and post-interview. That indicates that the system is manageable and does not demand too much from the user.

4.3.4 Issuing a pharmacy search Test sessions always started with the assumption that the user had never used the service before and therefore had to grant the application access to do the localization. The Pharmacy Locator

The first page of the Pharmacy Locator, as it looked in the simulator device used, is shown in Figure 2 The Pharmacy Locator. Even though the scroll bar is visible on the right to show that the window contains more information below, one test user had a problem understanding this. One reason for that could be the user’s lack of WAP experience but it also indicates that the application would serve its purpose better if the main menu could be visual in the start window. Another solution would be to have a broader scroll bar, as in computer windows, but this does not seem possible since the scroll bar is part of the mobile handset functionality and thus outside of what the WML page programmer can influence.

Figure 2 The Pharmacy Locator

Access Denied



All three test users had problems in the Access Denied page. The PRIME-Console link was confused with the Home link just beneath. The latter was pushed on several occasions contiguously forcing the test user to reinitiate the pharmacy search every time. The two links are too close to each other. Grant a pending policy in the PRIME-Console

Two test users didn’t understand the word “pending”. It could for example be replaced by “new” instead. They also proposed to have the “Accept and return” link as the first option to speed things up by avoiding going back to the “Return to application” link. That would certainly make the application more usable, under the presumption that in most cases users would want to go directly back to the pharmacy search results instead of playing around in the PRIME-Console. Search results

When the nearest pharmacy was presented on the screen, all test users enjoyed the application and were pleased with the appearance. Especially the opening hours seemed to be of interest.

4.3.5 Data Track Test users had no major problems to understand the intention behind and functionality of the Data Track. Usability would improve if the Data Track entries were sorted in reverse, starting by the last made entry. A feature that needs to be evaluated further is that the text becomes red after pressing the first next-link, possibly to mark that it has already been displayed. A minor comment on the detail view is that it says “provider” instead of “receiver” as the title word for the service provider who received the data.

4.3.6 Recommendations The main menu design: The title of the main menu is underlined, which may cause confusion since that is the common layout of a link. There ought to be a better, maybe standardized, way to introduce a menu, for instance by displaying it in bold. One could also consider to completely drop out the title and just have the links.

Move the PRIME-Console link: This link as being the most important one on the page is better off clearly stated and highlighted up front the window. That would also ease the interaction as the user would not have to scroll down the whole window to get further into the application.

Make it easier to make a call: In future version the phone number to the pharmacy, if possible, could be somehow highlighted to let the user just click on the call-key on the device to make the call.

4.3.7 Conclusions The test users, with as well as without WAP experience, found the system in general easy to use and could see the need for it. But it can be improved by making a few changes to the user interface. The test users also seemed to understand the necessity to use PRIME, although the Data Track needs some improvement in the user interface.


4.4.1 Documentation Pharmacy Search – Architecture Pharmacy Search High Level Design Installation Guide User Guide (User documentation) Pharmacy Search – Detailed Design



The documentation of the installation and the user guidelines are the most interesting from an HCI perspective. They were evaluated by one of the HCI team. The rest of the documentation is better analyzed by other expert evaluators.

There are no problems to follow the instructions for the two platforms served, Linux and Windows, although the Window version is probably preferable since the installation procedure of the Windows-based AP is more or less automatic.

The User Documentation’s audience is the PRIME evaluators rather than the future end-users. There are some parts in it that could serve as a true user guide but since the system is a straight forward service and should be fairly self explanatory, under the assumption that users understand the PRIME-part, maybe an extensive user guide is not necessary.

4.4.2 Installation and Platform The installation runs without any problems under both Linux and Windows.

4.4.3 Support Requirements The HCI evaluator can not see any support needs at this point in the AP version.

4.4.4 Conclusions The User documentation is more useful for the PRIME evaluators than future end-users. But since the prototype should be fairly self explanatory, maybe an extensive user-guide is not necessary.

4.5 Assurance evaluation – operational and functional aspects The evaluation from the assurance point of the LBS-prototype is organised in the following way: The first part shows critical parts of the prototype and minor bugs that can be fixed easily. The second part is mainly embossed by recommendations for further versions and progresses of the LBS prototype.

4.5.1 Assessed security functionalities The encryption of traffic between mobile operators, location intermediary and service provider is an additional feature provided by the LBS team. This feature is implemented and can be used. Nevertheless, it has been switched off so that the evaluators are able to create log files. Other assessed security functionalities are mentioned in the following sections.

4.5.2 Comments on the current prototype Comment 1: session handling In reality, the LBS prototype is aimed to serve several users simultaneously. Currently, the components provided by the IP do not ensure that sessions of different users can be handled separately. The result is a mixture of the different sessions, given back to the user. Definitely, this has to be fixed for later versions to avoid revealing of PII to other users and to ensure a reliable processing of using services. Comment 2: policy protection All user-defined policies are currently stored in one configuration file located on the server of the location intermediary. From an assurance point of view, each user has to have the whole sovereignty about his policies and therefore, this data must be stored in in a securely separated manner for each user with adequate protection by access control. Comment 3: clarification of communication partner



After some end-user tests, it seems to be unclear to a lot of users where the process of localisation starts and what kind of information is provided to which actor at which stage of the process during the usage of a PRIME-LBS-service. Therefore, it would be helpful to have a special optional window before changing over to the sphere of the next actor that informs the user about the new communication partner. Furthermore, to increase transparency, the user should have the possibility to assess which data is transmitted to whom and for what purpose. This might be done by publishing relevant passages of the contract between mobile operator, service provider, and location intermediary.

4.5.3 Recommendations for further prototypes Recommendation 1: confidentiality of communication A weak point of the Wireless Application Protocol (WAP) lower than version 2 is that all data transferred via the air interface is available in plaintext within the WAP Gateway which is typically not secured by PRIME. This should be taken into account for providing real end-to-end security for further, much more privacy-invading services. One possibility for the future would be to restrict utilisation of more privacy invading services to other transfer modes that enable end-to-end encryption, which will be implemented in the second tranche of the LBS prototype. Recommendation 2: policy adaptations Currently, users have only the opportunity to give general consent using a service for a certain amount. The functionality of policies should be enhanced by different possibilities selectable by the user:

• One-Time-Policies for services. • Determination of upper limits for spending money for PRIME-enabled services per period to

avoid unintentional overspending. • Secure deletion of policies to minimize sensible data.

Recommendation 3: identification process The current procedure of identifying users towards the location intermediary through the mobile operator by the dynamic IP-address should be modified in future versions. This has mainly three reasons:

The first reason pertains to data minimisation. Mobile operators do not need to know that a user is establishing a connection to the location intermediary for maintaining policies and data track inspections. Identification via credentials directly towards the location intermediary without involvement of mobile operators should be feasible and supported by the IPV.2.

The second reason is about interoperability and using other sources of location data (like the Global Positioning System and GALILEO directly provided by the user) in the future. Consequently, mobile operators would only have the role of organising payment processes for used services of service providers and intermediaries. Therefore, the mobile operator does only need a unique identifier from the location intermediary for starting the accounting process.

The third reason is that one account might be used through various Subscriber Identification Modules (SIM) and different accounts might be used by only one SIM, as well as switching off roles on the fly.

Recommendation 4: ontology specification The ontology should be more flexible and meaningful to allow the adaptation of services and to ease up gaining inside the world of PRIME. The current workaround misuses existing fields, like given.user.name to place required attributes with a totally other meaning than indicated. Especially when the wrong fieldname is displayed to the users, it might be a reason that policies cannot be configured in the intended way and which leads to unintended operations initialised by the user. This has to be replaced by a well-defined and flexible solution. Recommendation 5: user centric approach



Future prototypes should have a focus on not providing too much PII to the location intermediary. This would alleviate the accumulation of information within the location intermediary and therefore strengthen the user’s sovereignty.

4.5.4 Conclusions The assurance evaluation has a positive impression of the LBS-prototype. The stability of the prototype is satisfying under Windows as well as under Linux. The developers themselves spent a lot of effort in adapting the IP to the needs of their prototype and added the possibility to encrypt the traffic between mobile operator, service provider and location intermediary. Using WAP version 1.x was a conservative decision that may have complicated the flow of information within the scenario and has some slight weak points concerning security (e.g. the WAP Gateway). Respecting that this is the first PRIME LBS prototype and that the underlying protocol will be changed in the second tranche of prototypes, the developers did an acceptable job. Taking into account that many useful features of the IP have not been ready yet, a lot of communication effort will be needed between the developers of the IP and the LBS-prototype to have a well-prepared common basis.

4.6 Assurance evaluation – other aspects The LBS team provided two different versions of the LBS prototype. The first one is for Linux operated systems and the second one for Windows. Both have been tested during trials, but for the evaluation, the Windows version was chosen due to the general availability of the operating system.

4.6.1 Installation The assurance group installed the LBS prototype on several computers, one of them based on a Linux distribution, but based their evaluation on a Windows XP version. Supported by the provided documentation, the installation itself has not offered critical or mentionable aspects on Linux as well as on Windows.

4.6.2 Documentation The LBS team provided several documents for gaining insight the LBS prototype.

• A High-level design of the pharmacy search prototype

• A detailed installation guide for Linux

• A comprehensive installation guide for Windows

• A user guide for the prototype

• Threat analysis and mapping of security functions to threats

A threat analysis including the mapping of threats to security functions is integrated within the high-level design and all most likely threats are considered. The user guide including log file examples and the high-level design were the primary assistive documents for the evaluation from an assurance point of view. The log files created for the evaluation have been a great contribution to understand the activities between mobile operator, location intermediary and service provider. Additionally, they are describing the flow of information between these parties, even though the amount of logged data is enormous and takes some time to get familiar with it.



The provided information itself was quite satisfying and helpful for the evaluation. Some parts of the user guide seemed to base on an older version of the prototype with some slight impacts on the congruence of documentation and presentation of the prototype. For example, some of the screenshots had a different look or some menus had a different style. However, these issues are only on an editorial level and not critical for comprehending the context or for security and privacy aspects. To improve the documentation, the assurance group has three recommendations:

Recommendation 1

The first recommendation is to document already known bugs or malfunctions. This could be achieved by a living online document where developers and evaluators can state discovered problems. This would ease-up the work of both groups in getting an impression which problem is already known and which the reasons are.

Recommendation 2

The second recommendation is that it would be helpful to have some further information about architectural decisions. One example is the question why currently the mobile operator has to be involved in each interaction of the user and the location intermediary. Another example is why the encrypted Mobile Subscriber Integrated Services Digital Networknumber (MSISDN) was chosen as a persistent user-pseudonym for associating users between mobile operator and location intermediary and not a randomly generated string for instance. Nevertheless, those questions have been resolved and mostly the reason for the decision was to find in an interim solution, so that there exists a workaround until more sophisticated solutions can be provided by PRIME.

Recommendation 3

The third recommendation is the amelioration of the documentation of future prototypes by specifying the role of the location intermediary. From an assurance point of view, it is recommendable to know whether the location intermediary will be independent from mobile operators, or not. Additionally, descriptions of the used security feature will be required. Here, the question of securing the users PII stored within the intermediary is of highest importance.

4.6.3 Platform requirements The assurance evaluation was conducted on various computers. Some of them were slightly below the recommended hardware configuration but the assurance group did not assess any abnormal malfunctions or overstraining of the system in a critical way. The developers reported some special adaptations and tunings of the used components of the IP. This may be a reason for the comparatively low hardware requirements, taking into account that four server instances have to run on the used computer.

4.6.4 Support requirements Most of the steps for using the prototype could have been managed by using the documentation. Support was only required during the process of editing policies. Under certain circumstances, it is possible that a user is caught in the interface of the PRIME console. Thereby, the link to go back to the application is not displayed to the user and the service has to be reinitialised manually. However, this seems to be a minor issue, which can be fixed without investing major effort.

4.6.5 Conclusions Taking into account that this is the first version of the LBS prototype, the assurance group is convinced by the present state of the prototype, including its stability and performance.

During the presentation session of the prototype, the LBS team presented interesting ideas on how to improve the projected prototype by several aspects.



For avoiding the mentioned differences between documentation and evaluation version of the prototype, internal user-trials are recommendable. The reported feedback would also support the developers on a very early stage and enable them to react on minor comments before entering the evaluation.

All in all, the LBS team and their prototype seem to be on the right way.

4.7 Legal evaluation – operational and functional aspects The legal basis for the evaluation of the LBS AP is the general data protection directive 95/46/EC and the e-privacy directive 2002/58/EC. We also considered the new data retention Directive20 and we also refer to the new published Opinion of the Article. 29 WP21. The main criteria of this evaluation are laid on the respect of the general data protection principles, the respect of the data subject’s consent, the determination of privacy policies and the assessment of dispute resolution procedures. The legal relations between the three main actors (LBS AP – LI – MO) could not be assessed based on existing or draft agreements. The fact that the prototype is in its first phase explains this. Therefore, only recommendations regarding their mutual relations and their relations with the user are expressed in this evaluation.

4.7.1 Recommendations Service providers should provide clear, complete and comprehensive information on the features of the service proposed when data will be transmitted to a third party for the purpose of providing the value-added service and the users should have the possibility to have access to this information by a simple method in the general terms and conditions of the service or directly each time the service is used.

The same transparency should take place for the different re-directions of the users within the prototype. For instance, it should be provided to the users to which actors they are being redirected as to provide them with correct and clear information. This is partly implemented when accessing the PRIME console, but the information is not displayed long enough to make the user aware of it.

The Working Party, in the above-mentioned Opinion, believes that it is a precondition for the exercise of the rights of the data subjects that individuals are kept informed, not only when they subscribe to a service but also when they use it. Where a service requires ongoing processing of location data, the Working Party takes the view that the service provider should regularly remind the individual concerned that his or her terminal equipment has been, will be or can be located. This will allow that person to exercise the right to withdraw under Article 9 of Directive 2002/58/EC, should he or she wish to do so.

The Working Party takes the view in the same Opinion that this information should be provided by the party collecting the location data for processing, i.e. by the provider of the value-added service or, where the provider is not in direct contact with the data subject, by the electronic communications operator.

4.7.2 Legality of processing: Consent The consent is a persistent issue in LBS. From the current interpretation by the art 29 WP, consent is not given only as part of accepting the general terms and conditions for the LBS offered. In the prototype, the following elements could be enhanced:

20 The document is still under first reading to the Council of the European Union as the 10th of January 2006 but has been adopted by the European Parliament in December 2005. 21 On the use of location data with a view to providing value-added services WP 115, Adopted 25 November 2005, available at the EU Commission website: http://europa.eu.int/comm/justice_home/fsj/privacy.



• When a policy is already set in an ongoing situation (i.e. the first scenario proposed) the search of a pharmacy starts automatically when pressing the ‘find pharmacy’ function on the display screen. Even though the policy set in Prime has been accepted, we estimate that the processing should not start immediately but that an intermediary screen requesting the user’s consent should be introduced at that time. Two reasons explain this. The first is to respect the provision that the consent given once by the user is not being used every time. A second reason is that we should ensure that the user really understands what he is agreeing to when using this service and that he did not only make a wrong operation. The same is applicable in the new service scenario when the user is redirected from the PRIME console to the application provider. We think that the localization should not start automatically when the user exits the Prime console, unless the user is made aware that the localization will start as soon as he exits the Prime console.

• When subscribing to a service, the service provider must confirm the subscription to the service by sending a message to the user’s terminal equipment after reception of the consent and if necessary, request confirmation of the subscription. The reason is to avoid fraudulent subscription without the individual’s knowledge.

4.7.3 Policies The policies which are currently available only allow service preferences and price preferences, there are therefore no real privacy preferences implemented in the Prime console at the moment. Moreover, the erasure of these policies, while they are no more deemed necessary, is not working properly. The sequence of log files in a new service scenario show that some information (like the IP address, the Service Name, the Service Password and the Service cost) is processed by the LBS AP before the question whether there is an existing policy authorizing the localisation of the user is resolved. If the policy set by the user does not yet allow localisation, another process to set the requested policy has to start. It does not seem necessary to process the above mentioned information as long as the policy is not set to grant the required rights and accept the localization. Otherwise, if the user does not proceed with the service after he accepted the policy, this information would have been transferred anyway to the AP.

4.7.4 Retention of data It is also important to take into account the new Directive on mandatory data retention, which requires (in its Article 4) telecommunications companies to retain phone data and internet logs for a minimum of six months and at most 24 months in case they are needed for investigations of serious crimes. The data retention directive applies to ‘providers of publicly available communications services or of public communications networks'. As a consequence, on one hand, if the provider of the value-added service is not in direct contact with the data subject, but the data are transferred to him by the telecommunications operator, then the data retention legislation does not apply, because we don't have a 'provider of publicly available communications services or of public communications networks'. On the other hand, if the provider of the value-added service is in direct contact with the data subject, offering directly his services, then we have a 'provider of publicly available communications services' and the data retention directive does apply. This Directive is important as it has an impact on the data minimisation principle and early erasure of data.

Art. 5 of the data retention Directive includes a list of categories of data to be retained. According to this Article providers need to retain the data related to the user [position etc. – Art. 5 (a)(1)(ii)], data relating with date and time of the start and end of the communication [Art. 5(c)(1)], data revealing the type of communication (e.g. LBS by X. provider – Art. 5(d)(1)], data to identify the equipment [Art. 5.(e)(2) –ALL) and location data of the exact location of the mobile communication equipment. From the aforementioned analysis we presume that the location data of the user are indeed needed according to the data retention directive, while the data related to which pharmacy is closer should not be retained. Furthermore and just to strengthen this opinion, if we would retain data that show that this



specific user was looking for a pharmacy, it could be also considered as content data (which are deliberately left out of the directive). In any case, and in order to conclude, we believe that this kind of data could be compared with web browsing data, left though again deliberately out of the scope of the directive.

This Directive will of course create legal burdens in terms of data protection and data security but the prototype is in a too early stage to be able to assess the precise consequences of it. Obviously, it will be based on the data which are processed, the categories which have to be stored and if it includes the chain of relations or only the data related to the final connections with the MO.

4.7.5 Dispute resolution. It is important to notice that if a dispute arises and involves different countries, within the Community, the processing of location data is subject to the national law of the Member State where the controller (the provider of the value-added service). In the case of dispute, the bill is backed up by the credentials that the MO has sent. However, this should be avoided, as it might put at stake the user’s privacy towards the MO.

4.7.6 Conclusion. The LBS prototype has some promising possibilities in the growing mobile sector. Even though several elements could still be improved in order to be legally compliant with the regulatory framework, the first version of the application prototype already implements several principles and is a relatively acceptable implementation of the IPV1. Moreover, such embedded Identity Management System solution for LBS is also supported by the Art. 29 WP in the use of LBS.

4.8 Legal evaluation – other aspects The Location-Based Services (LBS) application prototype proposed by the developers is primarily intended to demonstrate the implementation and feasibility of the Prime features. This prototype has already reached a high level of development of the available Prime components, although it has only recently been developed within the project. The specific implementation shows the functionality and the demonstration session to present the prototype was fruitful.

4.8.1 Installation The “Installation guide for the LBS Application Prototype – Pharmacy Search” is a clear, easily readable and understandable document. The installation, after having solved the operating system’s requirements (see below) was easy. The user documentation was also useful in this respect. We did not come across any problem of stability when using prototype. The Frequently Asked Questions chapter of the guide is also very useful.

4.8.2 Documentation The “User documentation on the LBS Application Prototype – pharmacy search” was well documented with screenshots which facilitated the evaluation under the Linux environment. The developers made a very good job in providing this well explained and structured documentation.

However, we would have appreciated to receive some drafts of contractual agreements between the different actors involved and between the Mobile Operator and the user/subscriber. This information has not been provided by the developers for this evaluation and is therefore not part of it. It would give the possibility to verify that several legal provisions are respected and comply with legal regulation.

We particularly would like to underline the respect of the rights of the data subjects, the rule on the applicable national law, the identity of the controller, the purpose of the processing, and the different obligations attached to this



4.8.3 Platform requirements The prototype has been first proposed under a Linux environment, which we must admit created some technical problems and some waste of time. The reason is that Linux is not a common operating system used by the evaluator, nor by its institution. Some days after the trial, a Windows version has been submitted to the evaluators. We think that if the next LBS prototype still has to be installed on computers, it should be available, from the beginning, in both operating systems. We tested the prototype under both Linux and Windows XP systems, the comments for the evaluation of this AP will then reflect the results of these tests.

4.8.4 Support requirements No real test has been proposed to the evaluators before the AP meeting. The evaluator received the files to install the prototype, but due to technical problems, it has been more time consuming than expected to install it properly under a Linux operating system. Any drawback was solved during the session and support was provided by the developers during this time. Similar to the ASC AP, a specific session was also held between the legal, assurance people and the developers in order to discuss different legal points and questions which could occur for this prototype and which allowed a better understanding of the prototype, especially for the communication between the servers.

4.8.5 Developer’s trial Although the evaluation of the prototype has been done under Linux, an additional testing under the Windows platform was run. We saw that when starting the prototype under the windows environment, the system was not able to connect to the service directly (the following error message appeared: “Connection to localhost:9000 failed: connection refused”). We had to re-type the address, which was the correct one (see FAQ2 of the User Guide) to have the system working. This is probably a simple bug of the system.

4.9 Economic evaluation – operational and functional aspects

4.9.1 Scope and Focus The scope of the economic evaluation of the LBS prototype is limited to the pharmacy search application prototype. In the absence of input from the application provider, it was difficult to build a precise business case to help business decision-makers assess the financial implications of the proposed solution. The business case in Section 4.9.4 details the expected cost and benefits of the prototype using available market information on location-based services in Europe.

4.9.2 Privacy and Identity Issues in Location-Based Services Mobile operators in their search for additional sources to boost their revenues are rolling out data services such as location-based services. This involves passing of highly personal data to third parties such as application and content providers. According to a study conducted by AT Kearney [12], users consider security and privacy as their second major reason (after cost) for not subscribing to data services. Taking into consideration legislations passed by the EU regarding privacy, it is important for MOs to comply with regulations and incorporate privacy in their offerings.

Apart from the legal requirements, according to ABI Research [13], lack of standardization, competing technologies, slow connection, complex interfaces, users’ privacy and security concerns prohibited LBS to realize their potentials. The non-standardized environment in which LBS application providers function in addition with the number of parties that are involved in the LBS value chain increases transaction costs and leads to expensive pricing for end users, which are not willing to incur all these costs.



The perplexed legal environment imposed by the different data protection country laws and the lack of a privacy friendly solution that respects legislation and individuals’ privacy concerns, could create significant opportunities for the application prototype.

4.9.3 The Market Players Market researches are very positive about prospects of LBS. A recent study from research firm Berg Insight in July 2005 [14] states that revenues from LBS in the European market will grow by 153 percent during 2005 to reach € 274 million. Also the same report states that for the coming five years, the average annual growth rate is expected to be 83%. According another report from ARC Group [15], Location-Based Services could generate revenues of 18.5 billion dollars worldwide in 2007 with 44% of mobile users using some kinds of LBS at that point. This implies that LBS applications will be one of the main additional revenue streams for MOs that will help them maintain their growth.

The following table summarizes the LBS services offered by operators in Germany in 2005.

Operator Services

T-Mobile T-D1 Searches for taxis, hotels and ATMs as well as local weather

D2 Vodafone

Search for traffic and shopping information and detailed hotel guide Search for the nearest gas station, D2 shop, ATM, pharmacy, restaurant and cinema Locate friends and children Business services in the field of sales and logistics allowing employers to locate field agents and vehicles

E-Plus Search Yellow pages, restaurants, hotels, E-Plus shops and route planner

O2

Two ways of accessing LBS services: via the WAP portal M-Kompass and via SMS. WAP portal M-Kompass offers route planner, yellow pages and information about ATMs, hotels, restaurants and traffic. Users can also query keywords via SMS.

4.9.4 The Business Case for Pharmacy Search Application A business case is usually used by decision-makers to assess the financial impact of deploying a new service. A financial model was built with Frankfurt University using the assumptions and best estimates. The model serves as a template for refinement until more precise figures can be obtained from the application providers.

Projections were made on the number of T-Mobile subscribers over a five year period. This is then used to estimate the number of subscribers to the pull-based service which is assumed to be 10,000 in the first year. A price per localization of € 50c is proposed without any additional monthly fee. The model also assumes a revenue sharing scheme of 50/50 between the mobile operator and the other service providers. The expected revenues from sales of pull-based services is then estimated at 1.5 million € at the end of five years.



PRIME Business Case

€ in 1000s FULL VALUE CASH FLOW STATEMENT

For the year ending Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6Sep Sep Sep Sep Sep Sep Sep2005 2006 2007 2008 2009 2010 2011 TOTAL

BENEFITS / GAINS

Number of subscribers 27,470,000 28,843,500.0 30,285,675.0 31,799,958.8 33,389,956.7 35,059,454.5% of subscribers using LBS 0.000% 0.045% 0.064% 0.092% 0.131% 0.188%Number of pull LBS sub 0 10,000 15,000 22,500 33,750 50,625 75,938Number of push LBS sub 0 3,000 4,500 6,750 10,125 15,188 22,781Increase of LBS sub per year 50.00%

Pull servicesPrice per pull query 0.50 €Pull Queries per user/m 10Annual Queries per user 120Queries per year 0 1,200,000 1,800,000 2,700,000 4,050,000 6,075,000Revenue sharing 50%Revenue per user /m 2.50 €Revenue per user /y 30.00 €Sales of LBS Applications 0.00 € 300,000.00 € 450,000.00 € 675,000.00 € 1,012,500.00 € 1,518,750.00 € 3,956,250.00 €

Push servicesActive allergy period in months 4Daily subscription fee 1.00 €Revenue sharing 50.00%Active users per day 0.33 1,000 1,500 2,250 3,375 5,063 7,594Users per month 30,000 45,000 67,500 101,250 151,875 227813Users per year 120,000 180,000 270,000 405,000 607,500 911,250Revenues from subscriptions 60,000.00 € 90,000.00 € 135,000.00 € 202,500.00 € 303,750.00 € 455,625.00 € 791,250.00 €Warnings per user per month 10Price per warning 1.00 €Warnings per month 300,000 450,000 675,000 1,012,500 1,518,750 2,278,125Warnings per year 1,200,000 1,800,000 2,700,000 4,050,000 6,075,000 9,112,500Revenue per warning 0.05 €Revenues from warnings 60,000.00 € 90,000.00 € 135,000.00 € 202,500.00 € 303,750.00 € 455,625.00 € 791,250.00 €Total Benefits/Gains 420,000.00 € 630,000.00 € 945,000.00 € 1,417,500.00 € 2,126,250.00 € 911,250.00 € 5,538,750.00 €

The costs of providing such a service are rather optimistic estimates, but the operating costs are likely to be low relative to the initial fixed costs related to the investment.

€ in 1000s FULL VALUE CASH FLOW STATEMENT

For the year ending Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 Year 6Sep Sep Sep Sep Sep Sep Sep2005 2006 2007 2008 2009 2010 2011 TOTAL

ASSET ITEMS

Hardware ExpensesCost of access control Privacy and location applicatio 3,000.00 € 3,000.00 €Cost of Credential management servers 50,000.00 € 50,000.00 €Secure Storage server cost for billing and consent m 5,000.00 € 5,000.00 €Total H/W cost 58,000.00 € 58,000.00 €Total Investment 116,000.00 € 0.00 € 0.00 € 0.00 € 0.00 € 0.00 € 116,000.00 €H/W depreciation per year 23,200.00 € 23,200.00 € 23,200.00 € 23,200.00 € 23,200.00 €

OPERATING EXPENSE ITEMS

Personnel ExpensesNumber of staffs 5% 1 1 1 1 1 1Annual salary of PRIME developer 5% 55,000.00 € 57,750.00 € 60,637.50 € 63,669.38 € 66,852.84 € 70,195.49 € 374,105.20 €Total salary of PRIME developers 55,000.00 € 57,750.00 € 60,637.50 € 63,669.38 € 66,852.84 € 70,195.49 €Training days allocated per year 10.0Staff training 2,000.00 € 2,000.00 € 2,000.00 € 2,000.00 € 2,000.00 € 2,000.00 € 12,000.00 €

% cost of maintenance per purchase 5%Hardware maintenance 2,900.00 € 2,900.00 € 2,900.00 € 2,900.00 € 2,900.00 € 14,500.00 €Other small equipment expenses 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 5,000.00 €

Software ExpensesSystem integration 26,400.00 € 26,400.00 €

Other ExpensesElectrical power 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 6,000.00 €Insurance 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 1,000.00 € 6,000.00 €Other Admin expenses 18,333.33 € 19,250.00 € 20,212.50 € 21,223.13 € 22,284.28 € 23,398.50 € 124,701.73 €Marketing 20% 84,000.00 € 126,000.00 € 189,000.00 € 283,500.00 € 425,250.00 € 182,250.00 € 1,290,000.00 €Liabilities and legal cost 3% 0.00 € 12,600.00 € 18,900.00 € 28,350.00 € 42,525.00 € 63,787.50 €General overheads 20% 84,000.00 € 126,000.00 € 189,000.00 € 283,500.00 € 425,250.00 € 182,250.00 €Total Operating Expenses 271,733.33 € 349,500.00 € 485,650.00 € 688,142.50 € 990,062.13 € 529,781.48 € 2,032,706.94 €

The Pharmacy Search application entails a pull-based scenario whereby a mobile phone user initiates a localization request to search for the address and opening hours of the nearest pharmacy. To maintain the privacy of the user initiating the request, the application prototype segregates the functions of the application provider, location intermediary, and mobile operator. Such a setup enables the mobile operator to provide location-based services without incurring scrutiny from the regulators. A technical solution was constructed to enable a business which would otherwise be subject to scrutiny from the data protection authority.



4.9.5 Recommendations The application prototype demonstrates that the PRIME architecture can be extended for management of personal data in intra- and inter-organisational transactions in addition to the original focus on management of personal data between consumers and organizations. The adaptation of the PRIME architecture to accommodate business to business transactions was fascinating. The parameters of some messages were tweaked to come up with an operational pharmacy search application. The application developers should utilise this opportunity to provide concrete feedback to the architectural developers to accommodate business to business transactions.

4.9.5.1 The fee-based business model The design of the prototype was able to demonstrate the ability to bill for services while maintaining some degree of privacy. However, it is questionable whether an advertising model would not be more appropriate whether the companies wishing to be located pay for the services per localisation. The service can then be made free to the end-users thereby removing one of the barriers to adoption.

4.9.5.2 Customer privacy preferences The PRIME console was designed to manage different privacy preferences. While it is difficult to imagine variations in privacy preferences for such a limited application, the prototypes illustrates the potential for giving the customer choice over their privacy preferences in a location-based service setting.

4.10 Economic evaluation – other aspects

4.10.1 Documentation The documentation details the message flows between the functions of the application provider, location intermediary, and mobile operator. The walkthrough provided in the documentation together with the console messages should be sufficient to convince an auditor that personal data is not disclosed to third parties.

4.10.2 Installation and Platform Requirements The installation of the pharmacy search prototype was straightforward. The deployment of the services appears to be simple enough, and does not require extensive maintenance.

4.10.3 Support Requirements Frankfurt University provided support in the development of the business case. However, without direct contact with T-Mobile, it was difficult to assess what the real concerns are from a mobile operator’s perspective.


The location based services application prototype suffers from a similar drawback as the ASC prototype: the role of PRIME at the user side is rather limited. In the LBS prototype, PRIME primarily functions in the backend. It facilitates the separation of the three players involved in providing the service, the LBS provider, Location Intermediary and T-Mobile, and appears to be very suitable for this purpose, even though this was not a primary research and development aim at the current phase in the project. We will not discuss the backend of the LBS prototype from a social perspective, but only focus on the user-side of the prototype.

The issues at stake on the user-side of the LBS prototype can, again, be discussed in the light of user control, trust and in/exclusion. The prototype 'scores' well on most of the seven C's. (Refer to Section 3.11 for a definition of these.) Comprehension, and to some extent also consciousness, require special



attention. The prototype uses standard mobile phones, most of which have displays with a very limited resolution. The small screen size obviously hampers the interaction in general which means that interaction design has to be very careful. With respect to comprehension, the limited screen real estate means that the mobile device is hardly usable to convey to the user what PII is collected, by whom, and for what purpose. Besides, it would probably be confusing and undesirable to introduce the complex back-end arrangement to the user. Users, therefore, probably need written documentation outlining the necessary requirements, relevant actors, procedures, information on contract formation, sign on for services, etc, when they enroll for the LBS service for the first time.

Consent is an issue in the LBS scenario: is it required and/or desirable for each query, for a particular service or for a whole range of services. This question is addressed in Section 4.7.2.

The PRIME console as it is implemented in the prototype is capable of handling choice, context and confinement. The mechanisms to handle preferences and set contexts and conditions are available. However, the current prototype incorporates a very limited application of these mechanisms. It is solely used to allow the user to select the price she is prepared to pay for the location based service. A more mature prototype should contain privacy preferences and actual contexts the user can associate to these preferences. However, given the current prototype domain, locating a pharmacy, we find it very difficult to elicit real privacy preferences that could be relevant here. Especially if these actually have to be enforced by the system without human intervention. Nevertheless, the infrastructure to implement privacy preferences, set contexts, and allowing the user to choose amongst them is present.

The current choices implemented in the prototype, the price the user is willing to pay for the location based service, raises some issues that have to considered for a real service. In our view, selecting payment schemes for services should be distinguished from managing privacy preferences. The privacy preferences could be considered to be more or less stable for a particular context: one is either prepared to provide one's name or phone number to a second hand car salesperson or not (see for instance [16]). The price to be paid for a service is much more flexible and can be determined in the light of a concrete request. Therefore, setting certain privacy preferences for a particular LBS should take place in the PRIME console, whereas negotiating, or agreeing to, a price for a concrete request should/could be part of the interaction during this request.

The payment scheme implemented in the prototype raises questions with respect to the meaning of the choice and its consequences. What does it mean when the user selects that she is prepared to pay €0.49? Does this result in pharmacies that are further away than when one selected €1.02? Is the quality lower? Does one get less choice? What if no results appear? Should the user try again for a higher price? We would rather see an offer: I can provide you with a pharmacy for €0.42, do you want this? Suppose that another mechanism is adopted: one of a sponsored service. What do the data returned to the user mean then? It may be difficult for the user to assess the value of the service if the model is too complex and offers too much choice. Setting privacy preferences may not improve on this opacity.

The prototype, and indeed this kind of pull scenario, raises a number of other social issues. The pharmacy finder prototype provides the location of the nearest pharmacy. But what is the use of a location if directions to this location are not given. If the user has to ask passers by to provide these directions, then she might as well have asked them for the nearest pharmacy in the first place. This would clearly impact the user's privacy, albeit in a different way. The limited possibilities of providing accurate directions using a GSM phone therefore limit the kinds of services that can usefully be provided by LBS providers.

Finding a pharmacy may be a useful service in an unfamiliar city, possibly abroad. The LBS service should be capable of providing interaction in different languages. It is not clear if and how the prototype could accommodate for this kind of flexibility, but it may be a requirement from a socio/cultural perspective.

Trust is an issue in any LBS system, and also in the current prototype. The telecom provider by definition has knowledge of the location of the mobile device, and will even be obliged to retain these data in the light of the recently adopted EU data retention regulation. What guarantee does the user



have that the containers as sketched in the scenario really exist? This trust has to come from outside the LBS. Certification and oversight will be required. How this has to be accomplished remains to be investigated.

The application prototype does not appear to introduce special in/exclusion issues. Anyone with a mobile phone (and a T-Mobile account) should in principle be capable of signing up for the service. An issue that may have a bearing on the design of the prototype is the fact that mobile phones in some social circles (teenagers) are much less a personal device than for other age groups [17]. This means that one can not assume automatically that a service requested from a particular mobile device originates from the owner of the phone (or more precisely, mobile phone service subscriber). This should/could have consequences for accessing privacy settings in the mobile device, as well as access to the LBS services. We recommend to give each user an option to have a PIN on these settings. The user can then self-choose to deal with the inconvenience of an extra PIN security setting or rely upon the fact that his or her personalized device will not be used by others.

4.12 Social/cultural evaluation – other aspects The documentation raises no special social issues. The documentation is comprehensible and extensive. The current prototype has two incarnations. One of them runs in a mobile phone emulator which runs in a Linux environment. We don't consider this platform to be an essential aspect of the LBS prototype to evaluate from a social perspective, apart from the obvious remark that not everyone (Mac users for instance) can run the emulator. Another incarnation runs on actual mobile phones. These do not require installation.

4.13 ICPP Privacy Seal evaluation The fundamental technical design of the Location Based Services prototype is aligned to be as much anonymous / pseudonymous opposite to the involved parties as possible. The application provider shall not get to know the real identity of the user and the mobile operator shall not get information about the service used. The problem is that the IP address of the user is used for localisation which can be considered as personal data itself. The user is not really anonymous with respect to the application provider, the intermediary and naturally the mobile operator, where anonymity in front of the mobile operator is hardly to realise because of the technique and the legal regulations. There are also lacks concerning the legitimacy of data processing evaluating the given information and transparency offered to the user. Once stored a policy, starting the service causing localisation and charging is possible only with one click without additional request. And it is hardly to investigate for the user who are the involved parties and who is transmitting which data to whom. Also missing is explicit information in the policy about the purpose of the data processing.

Accompanying measures for protection of the data subject are partly implemented. Transmissions are (partly) encrypted and logged by the data track function of the IPV1. Others like intrusion detection or restriction of people having access to the system are not arranged and mentioned yet. With respect to the support of the rights of the data subject there is only (because of the IPV1) a simple erasure of the stored policies implemented and not an overwriting. The application is not supporting the user getting access to the information stored at the involved parties. Objection is only implemented by deletion of stored policies. Also separated storage of policies is suggested.

In conclusion with respect to the requirements of the Privacy Seal for IT-Products the problem of the design is the usage of the IP address for localisation. As told by the developers the next version will change this by doing localisation by the user himself. There is a lack of information and transparency. It is too easy for the user to activate functions by mistake.



5 Summary This summary will not attempt to condense all the detailed points from the evaluations, as the value of those points is in their specific detail.

Some of the evaluations were hampered by the incompleteness or immaturity of the prototypes or their documentation, and also by defects in their behaviour. Some of the evaluations were limited in the extent of investigation and analysis that could be performed in the time available. On the other hand, these initial application prototypes did provide a sufficient basis for the first detailed evaluations to be made of the PRIME technical approach from multiple viewpoints, and there is much useful comment from these to feed back into subsequent PRIME work, particularly in research, the future versions of the architecture, integrated prototype, application prototypes and the evaluations of all these.

6 Conclusions and Recommendations The principal conclusions are that, for eLearning and LBS, the IPV1 does not provide all the necessary component-level functions that are required by these applications, and that further consideration of the extent and methods of the provided user controls is required. These conclusions are to be expected, given the early prototypical nature of IPV1 and these initial APs.

The principal recommendations are as follows:

For eLearning:

• Allow users the possibility to use their real names, instead of pseudonyms, for some functions.

• Provide a privacy-respecting logging capability for the chat function.

• Simplify the choices for the user.

For ASC, address the following concerns before undertaking further prototypes:

• The possibility of undetected observation that is an inherent aspect of using RFID

• The disproportionality of using biometrics for the purpose, and the poor technology reliability

• The inadequate management and protection of the secret keys

• The use of smart cards that are contact-less and not PIN-protected

• The low level of user control over her PII

For LBS:

• Improve the HCI in line with the detailed comments

• Resolve the session-ID confusion issue, which was a consequence of IPV1

• Avoid using dynamic IP address and encrypted MSISDN as identifiers

• Improve the extent and management of user consent

• Feed the requirements for service-to-service communications and the need for large scaleability in policy handling back to the PRIME Architecture and IPV2 definition processes.



References [1] Katrin Borcea-Pfitzmann, Katja Liesebach, Hagen Wahrig: The Concept of Workspaces – re-defined for

eLearning! English translation of the paper: Das Workspace-Konzept - neu verpackt im eLearning! Workshop Proceedings of DeLFI 2005 and GMW05, September 13-16, 2005, Rostock, Germany. URL: http://blues.inf.tu-dresden.de/prime/AP_v1_Eval/Workspaces_en.pdf

[2] Katja Liesebach, Katrin Borcea-Pfitzmann, Alexander Böttcher: Initial application prototypes – eLearning v1. PRIME Deliverable D4.1.a, 23 December 2005. http://blues.inf.tu-dresden.de/prime/AP_v1_Eval/cnf_del_D4.1.a_ec_wp4.1_pt4.pdf

[3] Hagen Wahrig: Implemented security functions. 31 October 2005. http://blues.inf.tu-dresden.de/prime/AP_v1_Eval/SecurityFunctions.pdf

[4] Anne-Katrin Stange, Katrin Borcea-Pfitzmann: Survey - Privacy in eLearning. 13 January 2006. http://hades.inf.tu-dresden.de/phpsurveyor/index.php?sid=4

[5] Elke Franz, Hagen Wahrig, Alexander Böttcher, Katrin Borcea-Pfitzmann: Access Control in a Privacy-Aware eLearning Environment. Accepted for presentation at AreS SEL 2006, Vienna, April 2006.

[6] Borcea, K., H. Donker, E. Franz, A. Pfitzmann, H. Wahrig, (2005) “Towards Privacy-Aware eLearning”, Workshop Proceedings PET 2005, Dubrovnik (Cavtat), Croatia.)

[7] Leidner and Jarvepaa (1995) The use of information technology to enhance management school education: a theoretical view. In: MIS Quarterly, September 1995, pp.265-291

[8] Dawn N. Jutla & Peter Bodorik, Sociotechnical Architecture for Online Privacy, IEEE Security & Privacy, March/April 2005, pp. 29-39.

[9] Dutch Ministry of the Interior and Kingdom Relations, 2b or not 2b - evaluatierapport praktijkproef Biometrie 2b or not 2b (evaluation study: biometric trial 2b or not 2b), in Dutch, The Hague, 2005.

[10] IPTS, Biometrics at the Frontiers: Assessing the Impact on Society - For the European Parliament Committee on Citizens' Freedoms and Rights, Justice and Home Affairs (LIBE), JRC-IPTS: Seville (Spain), 2005, report 21585.

[11] UK Passport Service, Biometrics Enrolment Trial - Report, May 2005, http://www.passport.gov.uk/downloads/UKPSBiometrics_Enrolment_Trial_Report.pdf.

[12] AT_Kearney, (June 2004) "Mobinet Index 2004". AT Kearney and University of Cambridge study [13] ABI_Research, (2004) "Location-Based Services". [14] Berg_Insight, (July 2005) "The Structure of the European LBS Market 2005". [15] ARC_Group, (2002) "Location Based Services" [16] Perri 6, Can we be persuaded to become PET-Lovers? in OECD Working Party on Information Security

and Privacy, REPORT ON THE OECD FORUM SESSION ON PRIVACY-ENHANCING TECHNOLOGIES (PETs) Held at the OECD, Paris, 8 October 2001, (pp. 40-71).

[17] Howard Rheingold, Smart Mobs: The Next Social Revolution, New-York: Basic Books, 2002.



Appendix A Test Reports

A.1 HCI Test Report – eLearning

A.1.1 Testdesign Pre-test actions: Testparticipant (TP) signs agreement. Testleader (TL) gives TP a printed description, see Section A.1.7, of the different concepts and a verbal summary of the intended functionality in BluES’n. Test method: Guided Walkthrough / Think Aloud. Test events/tasks: 1. Start BluES’n. 2. Open the workspace IDM-Beginners Tutorial. (Let the credential-handling be done automatically) 3. Find and read the material about PGP. 4. Add a functional module that lets you use the chat-functionality in BluES’n. (Let the credential-handling be done automatically) 5. Send a message in the chat-room. 6 a. Change to your personal workspace. 6 b. In the Select Partial Identity dialogue switch to the configuration of Partial Identities. 7. Do the following setting to the Generic Workspace: When the Generic Workspace is activated you don’t want the Select Partial Identity dialogue to be shown to you. 8. Change to the IDM-Beginners Tutorial (it’s a Generic Workspace) to confirm that your settings worked. 9. Add a new functional module and do the credential-handling in the PRIME client. 10. Find the function in PRIME that stores the data sent to the BluES’n server, i.e the credentials. Test environment: A laptop running BluES’n and Camtasia Studio with screen and sound recorder.

A.1.2 Test data

Prior experience in ID Date Time Age Gender Profession Privacy Settings

eLearning Computer use Test tasks

TP1 051110 19:00 – 20:00 26-35 Male Teacher None None Average User (Internet, MS Office)

1-4

General comments

A pilot test that had to be terminated after test task 4 due to BluES’n severe communication problems with the PRIME client during the credential-handling. Response times at over 20 minutes made TP1 frustrated and certain that BluES’n had crashed. Restarts of the system didn’t improve the performance and TL stopped the test.



Primary test results The Privacy Policy window at startup was confusing, TP1 tried to click in the hollow circles that constitute the list at the end. TP1 was under the impression that he was supposed to choose the data to be revealed. The Select Partial Identity dialogue: Troublesome to understand what PI to choose Thought the PI attributes were to be filled out manually Commented on the object name/type as hard to understand Didn’t understand or saw the difference between the dialogue for open/activated The Select Pseudonym dialogue: It wasn’t clear to TP1 that he could/should write a name in the Partial Identity field but he commented on the Pseudonym field where he wanted more realistic name to choose from, e.g MyCoursePseudo etc. TP1 thought the Functional Modules in the Workspace Management Workspace was fairly easy to understand and manage. TP1 concluded fast what actions to take to accomplish task 4. Conclusions

UI not really mature enough to be put to users. Especially the Select Partial Identity and Pseudonyms dialogues need to be adapted in the way described in Appendix C (Usability/Functionality inspection results).

If the credential process continues to occupy the system the test tasks need to be simplified and shortened in order to reduce the frustration that may degrade the test results in an unwanted manner (tiring the user out).

A.1.3 Test data Prior experience in ID Date Time Age Gender Profession

Privacy Settings eLearning Computer use Test tasks

TP2 051115 17:00-18:00 18-25 Male Student Info. Systems

None None Expert (4th year Information Systems student)

1-4, 6-9

General comments

This test was much more guided than for TP1 and a thorough explanation of BluES’n and its concepts were conducted during the test tasks. TL could see a dramatic improvement in test completion time versus previous test with TP1. TP2 completed all test tasks except 5 and 10 due to credential handling processes that engage the system for a vast amount of time. Primary test results The Select Partial Identity Dialogue:

The first time TP2 was prompted with the dialogue he thought he was supposed to configure the Partial Identity he chose. This made him push the configurate-button to make settings for that particular Partial Identity. When TL hinted that he was on the wrong track TP2 commented on the title bar – Partial Identity Configuration - as ambiguous since it made him believe that configurations for one Partial Identity was intended. TP2 didn’t see the difference between the open/activate dialogues and wondered why he had to make the same things many times. After TL explains the difference between the dialogues TP2 suggests that the OK-button could have another label depending on the dialogue, e.g Open, Activate. The Select Pseudonym dialogue:



After TP2 understood the Open vs Activate dialogues he wondered if the PI he used for the opening should be reused during the activation. TL encouraged him to do what he thought best and then TP2 more or less by chance chose the same name for the PI as for opening.

The Pseudonym combobox sometimes lacked items to choose from which confused TP2. Why is there a combobox when there only exist one alternative to choose?

After the test TP2 states that he understands that he acted under different identities to not be recognizable within BluES’n.

Test Tasks 3-4:

A double-click in the structure module should present the chosen material in PoI even if the material viewer is not yet put in PoI. TP2 also suggests a drag-and-drop solution as convenient.

When TP2 adds a new chat-module all directories in Associated Modules are expanded, is that a bug?

Test Tasks 7:

TP2 does the correct configuration but for the action open instead of activate.

Test Task 9:

Total confusion! Not mature enough to be put to users that don’t have any insight in PRIME.

Conclusions

Overall conclusion is that the Selection of PI and Pseudo put too much load on the user. It is hard to understand why open/activate demands two choices of Partial Identity.

A.1.4 Revision of test tasks and introduction of interview, after AP meeting in Dresden

The test tasks are slightly different from former test sessions due to BluES’n updates. Test events/tasks: 1. Start BluES’n. 2. Open the workspace IDM-Beginners Tutorial. (Let the credential-handling be done automatically) 3. Find and read the material about PGP. 4. Add a functional module that lets you use the chat-functionality in BluES’n. (Let the credential-handling be done automatically) 5. Open the Context Management configuration and make settings to send chat messages anonymously. 6. Send a message in the chat-room. 7a. Change to your personal workspace. 7b. Open the Context Management configuration again and do the following settings: Whenever the IDM-Beginners Tutorial is activated the context management automatically uses the Partial Identity you used the last time in this workspace. You just want a notification about the switch. 8. Change to the IDM-Beginners Tutorial to confirm that your settings worked. 9. Add a new functional module and do the credential-handling in the PRIME client. 10. Find the function in PRIME that stores the data sent to the BluES’n server, i.e the credentials. Post-test action: After the test TP is asked 4 questions, to highlight users understanding of the AP and make it possible for them to make remarks about improvement possibilites.



A.1.5 Test data The test tasks are slightly different from former test sessions due to BluES’n updates.

Prior experience in ID Date Time Age Gender Profession Privacy Settings eLearning Computer use

Test tasks

TP2 051208 14:45 – 15:15 18-25 Male Student Info. Systems

Some from test session 051115

Some from test session 051115

Expert (4th year Information Systems student)

1-9

General comments

TP2 is reused to analyze the usability when already acquainted to BluES’n. Test task 9 had to be interrupted since the credential handling never started. Unfortunately due to technical problems the test session wasn’t recorded properly but TL took notes and interviewed TP afterwards to make sure the most important test results are highlighted in this summary.

Primary test results TP2 commented on the lack of visuals when the system is occupied, one might believe it hangs. In test task 3, TP2 has forgotten how to view material, indicating that it is too complex to involve two modules for material viewing. TP2 wants to just double click on the specified link in the structure viewer and then get the text in POI without putting the material viewer in POI first. This view has been stated from other test persons too.

Context Management Configuration:

Test task 5 is hard to solve, chat doesn’t show in the object list (a bug?) so TL tells TP2 to choose topic instead. It is hard to understand the setting alternatives, especially the action settings in the lower half of the window. In test task 7b more problems appear. The difference between open and activated is unclear and TP2 fail to make the proper settings until guided by TL.

Interview

The most major flaw in BluES’n is the Context Management Configuration since it is hard to understand. The most positive feature is the choice to get a notification instead of a dialogue. The BluES’n GUI is overall easy to comprehend. One would feel safer if there was a well-known certified logo for PRIME.

Conclusion

Material view still problematic, users are used to only double click the things they want to read/see. The Context Configuration Management needs to be easier to use. Split in two halves, the first one is for the newbie user and the second one (hidden under advanced-button) has all the advanced features. The newbie user configuration should only concern the most critical settings, like notification vs dialogue vs none. The Context Management Configuration as it is now needs users high educated in BluES’n and is not very user-friendly at all. Are all action settings really needed for the average user?

A.1.6 Test data Prior experience in ID Date Time Age Gender Profession

Privacy Settings

eLearning Computer use Test tasks

TP3 051209 14:50 – 15:30 26-35 Female Information Systems Teacher

None Expert Expert 1-8



General comments

TP3 is a highly experienced eLearning teacher and as such can give valuable insights in how a teacher may experience BluES’n. Test task 9 and 10 could not be performed since BluES’n never launched the credential handling window (as happened to TP2).

Primary Test Results Privacy Policy contains too much text and TP3 believes the last section is meant for her to choose from (as did TP1). TP3 suggest the policy to be shown the very first time BluES’n is ever launched by a user, as a kind of license agreement. During the first test tasks the idle time is to long. The checkbox don’t ask me anymore on the partial identity window may be misinterpreted, it is unclear to TP3 what it is meant for. Also the Notification window contains too much technical text, eg null.

Test task 2

The toggle button is not obvious how to use, TP3 needs guidance to find it. TP3 wonders if system hangs when idle/greyed out and suggests windows-like time-glass or blue filling bar. When the open and activated windows for partial identity appears TP3 is frustrated and doesn’t understand why there are several windows that she thinks are the same keep popping up.

Test task 3

Same remarks as TP2.

Test task 4

Why does all the directories expand? Can’t find the save-button because focus lies on the right side of the window where the modules in wsp are.

Test task 5

Severe difficulties, the window is not well structured to be used by TP3. TL guides TP3 through it.

Test task 6

The send-button should react on Enter as in other chat-programs.

Test task 7

It’s still difficult to comprehend the configuration possibilities. Believes open = activate in the right upper window.

Interview

As an experienced eLearning teacher TP3 misses a function for revealing ones identity in BluES’n, ie acting under your real identity as normally done in other eLearning platforms. TP3 has no problem to understand the PRIME-concept and its use in BluES’n but sees problems when it’s introduced to students. Unexperienced eLearning students today sometimes have a hard time understanding the eLearning Platform that exists now and she suggests using the BluES’n system in later classes when the students are familiar with the environment.

Conclusion

Configuration Window should be stripped of all unnecessary information and the configuration must be made easier to understand/handle.



A.1.7 Printed Description – given to user

Introduction to BluES’n BluES’n An eLearning system (for research purpose) that uses pseudonyms to achieve anonymity among its users. This means that you act under different aliases in the eLearning environment to protect your personal identity data and to not be recognized by other users (i.e tutors, students etc). Partial Identities and Pseudonyms You can have several different Partial Identities in BluES’n. A Partial Identity is intended to reflect a unique role that you have in BluES’n (e.g student, author, teacher). Every Partial Identity is connected to a pseudonym, that is presented to other users when/if you interact with them. Context Switch BluES’n collects data about and evaluates your movements in BluES’n to be certain that you can’t be recognized in any situation. When BluES’n thinks your privacy is at jeopardy a Context Switch occurs that lets you choose another Partial Identity and possibly a new pseudonym to work under. This means simplistically that your actions in different contexts are separated and can’t be linked to each other. Workspace When you work in BluES’n you will be in different workspaces. Roughly a workspace corresponds to some kind of a learning premise (e.g a lecture hall, a teacher’s office, a group room, a conference room etc). There are different workspaces for different situations and they can be shared among users, for instance a group of eLearning students registered to a specific course. You also have your own private workspace that is not shared by other users. A workspace can be viewed as an icon, in medium or in Point-of-Interest. When you start BluES’n the test leader will explain this to you. PRIME PRIME is a system that cooperates with BluES’n to maintain your anonymity in situations when evidence about your identity needs to be transferred to the central BluES’n server. For example when you open a workspace BluES’n wants to know if you are supposed to have access to it. To prove that you provide PRIME with a credential. PRIME sends it to the server and hopefully you can proceed with the opening of the workspace. Credential A credential is your evidence that you are for example a valid user in BluES’n. When you register for a course a credential is given to you that proves you as a user in BluES’n with access to some workspaces. This is not fully supported yet so at the time being the credential-handling is only prototypically incorporated in BluES’n.



A.2 HCI Test Report – Location Based Services

A.2.1 Testdesign Pretest actions: Testparticipant (TP) signs agreement. Testleader (TL) gives TP a printed description of the scenario and a verbal summary of the intended functionality in the LBS prototype. Test method: Guided Walkthrough / Think Aloud. Background to the Scenario New Service: Test user has never used this specific service before. When he requests the service from the AP, the AP notifies him that the access rights must be modified to get the service delivered. The user is redirected to the PRIME system to grant the service access to his location and after that the service is delivered. Scenario brought to test users: You and a friend are on a vacation in Bonn, Germany. You have never been there before so on your first day you go out sightseeing. Suddenly you suffer from an allergic reaction. You realize that you left the medicine at the hotel room and although it’s not an emergency you need to get hold on some medication to soothe the reaction. By using a service installed on your mobile phone you can issue a search to find the pharmacies in your surroundings. The service will respond, within a few seconds, with the pharmacy address closest to your current location. To be able to give you the address, the service must locate where you are which can be done by locating your mobile phone and then compare its location with a pharmacy address register to figure out which pharmacy is closest to you. When you first installed the pharmacy-finding service, a few days ago, you were a bit concerned about the localization procedure since it could jeopardize your privacy. If for example a corrupt location-finding service gets permission of your telephone operator to find your location, you could not be sure of what happens. They could start using it for commercial advertising or even attacks by criminals. In the telephone emulator you will see on the computer screen the PRIME system has been installed. PRIME allows you to send limited rights to service providers to access your location from the telephone operator. PRIME does this for you every single time you use the service, so that the location-finder cannot localize without you asking for it. Test tasks

1. Find the nearest pharmacy 2. The PRIME-Console has a function to store data about who locates you and when the

localization is performed. Find that function and read the data that was stored when you performed the pharmacy search.

A.2.2 Test data

Prior experience in ID Date Time Age Gender Profession Privacy Settings WAP Computer use

TP1 060102 12:50-13:00

46-55 Female Private sector administrator None None Average/Experienced



General Comments TP1 is a non WAP-user but has no real problems understanding the functionality, only needed guidance to understand the scrollbar. Performs test tasks swiftly after understanding the device. Primary Test Results The only problem TP1 had was to understand she should scroll down the text to find the PRIME-Console in the Acess Denied window. After the test TP1 stated that she first hadn’t noticed the scroll bar on the side, indicating that there is more text under the current position, but once clear to her test task 1 was easy to conduct. Test task 2 is also rather easy to comprehend and TP1 only comments on the red text that suddenly shows in the Data Track (a bug?). Interview Application is useful and appreciated by TP1. No suggestions how to improve the GUI, thinks it is ok. Understands the usefulness of the PRIME-concept as a filter between her mobile phone and the mobile operator/service provider. Conclusion Although non experienced WAP user TP1 shows that the prototype is easy to use. Probably her daily use of computer software in her work is a factor that contributes to that. TP1 has low level English skills but that doesn’t stand in the way for the understanding of the English worded prototype which indicates that it is indeed easy to use.

A.2.3 Test data

Prior experience in ID Date Time Age Gend

er Profession

Privacy Settings

WAP Computer use

TP2

060102

13:30-13:37

26-35 Male University student None Non-frequent user

Average

General Comments TP2 has used some WAP functions on his mobile phone but is not an experienced user. Primary Test Results Test task 1 TP2 misses the link to Prime-Console on the Acess Denied page. Instead he pushes the Home link several times and TL guides him to reinitiate a pharmacy search to be able to move on. The word pending, when granting policies, is unknown to TP2. Test task 2 The Data track is easily found and managed Interview TP2 thinks the product is useful and a good service. Understands the PRIME-concept and its functionality. TP2 suggest a more obvious link to the Prime-Console when granting a pending policy and that the link should be presented at the top of the page to make the interaction smoother and more evident. TP2 stresses that he would only use the service if not in an emergency situation. TP2 also states that the policy granting must be made easier and proposes the “accept and return”-functionality that already exists in the prototype as a good solution. It’s noticeable that TP2 didn’t find that link at the session, suggesting that its current position (it lies after accept, reject) is the wrong place.



Conclusion The link to the Prime-Console in the Access Denied page needs to be changed to be more evident to the user, put it up on top of the page or something similar. When granting policy use new instead of pending? Put the accept and return link in a more obvious place. The Data Track seems to be understandable.

A.2.4 Test data

Prior experience in ID Date Time Age Gender Profession Privacy Settings WAP Computer use

TP3 060102 14:00-14:10

18-25 Male University Student None None Expert

General Comments Same problems as TP2 had with the Prime-Console Link in the Access Denied page and doesn’t know what pending means. Primary Test Results Test task 1 Believes that the two last links in the Access Denied page are the same or connected (Prime-Console and Home). When pushing accept in the granting procedure TP3 wants to come back to the Pharmacy Search application instead of ending up in the Prime-Console and having to push the link “Return to Application”. Which is exactly what TP2 commented on too. Doesn’t understand the word pending. Test task 2 No problems, understands the Data Track concept. Interview Good service that TP3 could see himself use if available on the market. Understands the privacy implications of the localization procedure and the need for the PRIME-system. TP3 suggests to improve the granting of a pending policy by putting the “accept and return” functionality first in the menu list (i.e before accept, reject ). Conclusion In most aspects same conclusions as for TP2.



A.3 Developer’s Trial Report – Location Based Services

A.3.1 Test Scenario Most test participants were employees of Frankfurt University, among them students, assistants, and other personnel. The age of the testers ranged from 20 to 55. Some of them were familiar with WAP-enabled cell phones, while others didn’t have any such experience. Also, some of them were aware of the high level goals of the PRIME-project, while others didn’t have any information technology background at all. The user trials were conducted based on a combination of a journal that the users had to fill in during their session and a questionnaire. Basic instructions were given in an introductory explains how to use the journal and questionnaire step by step. At the end of the introduction an exemplary journal was given. After the introduction, the actual trials commenced. The respondent had to fill in the journal, beginning with his starting time, whereas every step was labelled with a timestamp. The journal was necessary to measure how long the installation and evaluation of the user guide takes and with which kind of problems the respondent was confronted with during the installation and evaluation without requiring permanent surveillance. When the user had successfully completed the scenarios, the questionnaire was handed out and the user had to mark sixteen multiple choice questions. The questions can be classified in questions about the following categories:

1. User Background (Experience in using a computer/WAP browser and the ambitions of the PRIME-project).

2. Comprehensibility of the documentation (usage and installation guides).

3. Usability of the program and the installation procedures.

4. Stability and performance of the implementation.

5. Users’ evaluation of the privacy and security-enhancing features of the program. In the last part of the questionnaire, the respondent was given the possibility to express the experiences he made during the installing und using the program and may give suggestions for improving the program by filling out several free text fields.

A.3.2 Results The overall results of the user trials were very encouraging, with marks for the prototype 8 or better, on a scale from 1-10 (where 10 is good). Overall usability, performance and documentation all did very well. Lowest scores went to understandability of privacy functions and installation procedure. All participants of the trial were able to successfully complete the given scenarios. However, several minor issues were identified during the tests, which will be discussed in detail in the following paragraphs. Most of them seem to be due to the prototypical state of the implementation, and are given here mainly for reasons of completeness.



Generally, users didn’t have any problems while registering a new policy for the service or performing a localisation of the nearest pharmacy. The documentation for these scenarios was evaluated as very helpful. Some users were irritated by the amount of log file documentation presented in the current version of the guides. This information was mainly aimed at people evaluating the system’s inner workings (e.g. legal and assurance evaluators) and should preferably be omitted from a final version of the guide which would be aimed at the general public. Also, some smaller faults of the documentation (like spelling mistakes or confusing illustrations) were brought up. These will be corrected in future versions of the user guide. Additionally, the specific functions of the prime console were often non-obvious for the users. Specifically, the role and purpose of the location intermediary remained unclear for most users, who tended to mix up client and server-side functionality. Some of them stated they could not identify any privacy functionality at all. This is probably at least partially due to the inherent complexity of the concept “location intermediary”. The problem of designing an easy-to-understand user interface for LBS privacy functionality seems at least partially unresolved as of this version. There was also a case of a user getting stuck in the PRIME-console, with no obvious way to return to the pharmacy service via the user interface. This problem was tracked to the back-link disappearing if it was not used the first time it appeared. An additional type of usability problems was related to the specific type of phone emulated by the prototype version. Several users reported problems related to differences between Nokia phones and phones of other brands, which they were used to. This problem might be fixed by using a more feature-complete emulator, and is a non-issue in a real-life implementation, where everybody would be using his own phone. Also, some users described the WAP-interface as generally old-fashioned and restrictive. Attributing this to the prototype seems unfair, as it is of course dependent on the underlying infrastructure, and was aiming at the broadest possible user base. However, users that had some experience with WAP services tended to describe the user interface as quite attractive and usable, and most users agreed that they might use such a service every day. Another usability problem was that it was unclear to some users whether closing the console windows opened by the server (Tomcat) instances (LI, MO…) would affect the system. Some users supposed that closing the windows would only hide the logs and have no impact on the running state of the servers. However, this is not a real problem, as the server instances will not normally run on a real mobile phone. There were several suggestions for improvements or additional features. While the installation procedures were generally seen as quite easy to complete, some users reported problems. An automatic installation package was seen as a very nice to have improvement by most of the trial participants, who disliked the additional manual steps necessary for installation. User feedback also included the request that an agreement contract similar to the ones used for software licenses be displayed to illustrate the privacy agreement between user and service provider. Some users also requested additional confirmation dialogues, to reduce the risk of giving unwanted privacy clearances. All in all, the prototype performed quite admirably. The user trials suggest some minor improvements to prototype and documentation, but overall results were as high as 9 out of 10 points on the average.



A.4 Learning and privacy protection – social/cultural aspects In a standard learning situation several parties are involved:-

• the student

• one or more teachers

• authors of teaching material

• the education institution that processes privacy information

• fellow students

• parents (especially in case of under aged pupils)

• the outside world If the object of the student is to protect his privacy, this protection relates to the world outside the learning environment, maybe less from fellow students, while it is sometimes inevitable to share his mistakes and vulnerabilities with his teacher. When the student is under aged, the parents play a role here as well. Although the pupil may want to protect his privacy against parent intrusion in his study progress, parents have a responsibility for the raise and education of their children. This responsibility requires certain information about study progress. The opinions about parents responsibilities for children’s education and their rights to interfere with their children’s privacy differs between cultures and social groups. Also, the age until which parents are responsible for the education of their children, might differ from country to country.

Outside world

Parents of under aged

children

Educational institution

Fellow students Authors Teacher

Entrance knowledge /skill level

Disclosure at disposition of student

To be shared For legal and logistical reasons

Want to know is some situations for effective collective learning

No knowledge of individual students required

Wants to know for effective teaching

Interests Disclosure at disposition of student

To be shared For logistical reasons



To be protected

Talent Disclosure at disposition of student

To be shared To be protected Disclosure at disposition of student


Wants to know for effective teaching

Character Disclosure at disposition of student

To be shared To be protected Disclosure at disposition of student


To be protected

Exit knowledge/ skill level


To be shared For legal and logistical reasons (evidence)

To be protected to prevent comparison of grades


Creates grades

Table 1.1: Assumed privacy levels in a learning environment

A comparable analysis of the privacy needs of the teacher can be made. Also the teacher might have needs to protect his privacy in the relation to his students, the education institution he works for, and the outside world. For example: he might not want to be personally accountable for the grades he gives to individual students. ELearning can potentially be completely anonymous. The teacher does not have to know who takes his course. Some eLearning courses don’t even need a teacher and are self explaining. Sometimes the teacher needs to know the person's entrance knowledge and skills in cases a minimum entrance level is required, or in case he has to intervene on an individual basis. He and/or the educational institution also has to know whether the person he wants to grade, is entitled to receive the grade. This is



especially important if the grades create legal consequences, for example if the student receives a certificate or diploma that entitles him to attend higher level courses or programs. The educational institution has to know the correctness of the identity in order to receive payment for the (eLearning) course and to guarantee the status of the issued certificate at the end of the course.



A.5 ASC AP’s relationship to the principles of PRIME & the Data Protection Directive 95/46/EC

The PRIME project sets out the following principles:

PR 1: “Design must start from maximum privacy”:

PR 2: “Explicit privacy rules govern system usage”

PR 3: “Privacy rules must be enforced, not just stated”

PR 4: “Privacy enforcement must be trustworthy”

PR 5: “Users need easy and intuitive abstractions of privacy”

PR 6: “Privacy needs an integrated approach”

PR 7: “Privacy must be integrated with applications”

We also note the following principles from the Data Protection Directive (95/46/EC):

DP 1: “Data must be adequate, relevant, and not excessive in relation to the purposes for which they are processed” (recital 28; Article 6(c))

DP 2: “The data subject ... must be given adequate and full information ... (recital 38; Article 10)

DP 3: “Any person must be able to exercise the right of access to data relating to him (recital 41; Article 12)

The ASC prototype enacts these principles as follows:

PR 1: The basis of the whole design

PR 2-4: These principles are enacted by the various systems in the airport component (not all of which are under the control of the airline) having explicit verifiable rules on their treatment of the traveller’s data. This is not implemented automatically in the prototype, since the treatment of data is defined by the PRIME team. In a real airport environment, this would be implemented by audited code and systematic monitoring.

PR 5: The notion that the traveller’s data are physically in his possession is easy and intuitive - perhaps more so than any other such system.

PR 6,7: These are exactly why the ASC prototype has been built!

DP 1: To the extent that this is possible by law, the system aims at the minimisation of the data which has to be supplied.

DP 2: This is respected by the enrolment process, which uses the PRIME IPV1.

DP 3: The data is physically in his possession!

prime consortium

Documents