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 Prototypes5
Author: Work Package 4.26
Editor: Pete Bramhall (Hewlett-Packard)7
Reviewers: Hilko Donker (TUD)8
Peter Keller (Swisscom)9
Identifier: D4.2.a10
Type: Deliverable11
Version: 412
Date: 10 March 200613
Status: Final14
Class: Public15
Summary16
17
This deliverable contains the evaluation of the initial application prototypes - eLearning, Airport18
Security Controls and Location Based Services. The evaluation takes account of the following19
viewpoints: Human-Computer Interface (HCI), assurance, legal, economics and social/cultural20
aspects. It also includes evaluations by the application prototypes’ developers of the suitability of21
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 Page 2
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

PRIME D4.2.a
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.

PRIME D4.2.a

PRIME D4.2.a
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

PRIME D4.2.a
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.5 Conclusions ..................................................................................................................................... 20
2.5 Assurance evaluation – operational and functional aspects......................................................... 20
2.5.1 Assessed security functions............................................................................................................. 20
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.2 Conclusion....................................................................................................................................... 25
2.8 Legal evaluation – other aspects.................................................................................................... 25
2.8.1 Installation....................................................................................................................................... 25
2.8.2 Documentation ................................................................................................................................ 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.10 Economic evaluation – other aspects ........................................................................................ 28
2.10.1Documentation ................................................................................................................................ 28
2.10.2Installation and Platform Requirements .......................................................................................... 28
2.10.3Support Requirements ..................................................................................................................... 29
2.11 Social/cultural evaluation – operational and functional aspects ............................................. 29

PRIME D4.2.a
2.11.1Recommendation............................................................................................................................. 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.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.6 Conclusions ..................................................................................................................................... 36
3.4.1 Documentation ................................................................................................................................ 36
3.4.4 Conclusions ..................................................................................................................................... 37
3.5.2 Conclusions ..................................................................................................................................... 38
3.6.1 Documentation ................................................................................................................................ 39
3.6.2 Conclusions ..................................................................................................................................... 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.1 Installation....................................................................................................................................... 42
3.8.2 Documentation ................................................................................................................................ 42
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.12.1Recommendations ........................................................................................................................... 49
4 Location Based Services Application Prototype................................................................... 51
4.1 Descriptive summary...................................................................................................................... 51
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

PRIME D4.2.a
4.3.7 Conclusions ..................................................................................................................................... 55
4.4.1 Documentation ................................................................................................................................ 55
4.4.4 Conclusions ..................................................................................................................................... 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.1 Installation....................................................................................................................................... 58
4.6.2 Documentation ................................................................................................................................ 58
4.6.5 Conclusions ..................................................................................................................................... 59
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.1 Installation....................................................................................................................................... 62
4.8.2 Documentation ................................................................................................................................ 62
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.10.1Documentation ................................................................................................................................ 66
4.10.2Installation and Platform Requirements .......................................................................................... 66
4.10.3Support Requirements ..................................................................................................................... 66
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

PRIME D4.2.a
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

PRIME D4.2.a
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

PRIME D4.2.a
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.

PRIME D4.2.a
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.

PRIME D4.2.a
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

PRIME D4.2.a
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.

PRIME D4.2.a
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.

PRIME D4.2.a
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.

PRIME D4.2.a
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’

PRIME D4.2.a
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.

PRIME D4.2.a
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

PRIME D4.2.a
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.
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.

PRIME D4.2.a
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 .
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,

PRIME D4.2.a
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.

PRIME D4.2.a
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.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.

PRIME D4.2.a
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.

PRIME D4.2.a
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

PRIME D4.2.a
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]).

PRIME D4.2.a
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.

prime consortium

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie prime consortium

Ähnlich wie prime consortium (20)

prime consortium