
 
other user and the communication can be encrypted 
in order to avoid malicious eavesdropping or 
dangerous attacks. 
Inside a PKI, certificates management is 
submitted to a specific authority: the Certification 
Authority (CA). The CA guarantees the identity of 
every entity belonging to the PKI, by furnishing, 
publishing, revoking and suspending Digital 
Certificates. The CA has a database (repository) 
containing all the released certificates together with 
their status (active, suspended, revoked). SSC 
assures authentication of both data flow and actors 
and at the same time it protects sensitive data, 
infrastructure resources and information on user 
terminal and personal/financial data. 
Security mechanisms are applied on the links 
between the terminal and the SB and in some cases 
between SB and VASP. This is done in order to 
avoid illegal use of contents and services and 
unlawful eavesdropping to the users whereabouts 
and actions. The security feature also protects the 
system infrastructure from any hacking activity and 
prevents even registered system users, system 
administrators and technicians from the ability to 
access personal data collected about any other user 
of the system. The SSC interacts directly and/or is 
the intermediary toward the SB and VHE for 
granting high level security and trust. 
The authentication mechanism validates the right 
to use the entity that is accessing the system, either 
when the access is originated by the users, by the 
terminal applications, or by the system’s initiative 
via the token. The administrator of the system is able 
to remove and prevent usage by terminals that have 
been marked as stolen. 
The adoption of the secure VPN allows to tailor 
the service delivery according to different usage and 
access to the system community. At the same time, 
the exploitation of a secure VPN allows us to 
distribute the whole infrastructure all over the 
Internet, with no cost impact due to leased lines. 
The token is the passport for gaining entry in this 
service infrastructure, allowing to access the same 
resources in the same way, irrespectively of 
operating systems and adopted terminals. 
5 RESULTS AND CONCLUSIONS 
Testing activities has been carried out in a multi-
service and multi-platform environment, involving 
many different users and access devices (PC, PDA 
and kiosk). Two types of tests have been conducted: 
a portability test, where a single user accesses the 
platform several times with different devices; a 
personalization test, where different users access the 
platform with the same device. 
Several service scenarios were considered, such 
as students requesting University certification of 
their scholastic carrier (with all data about their 
exams), to be downloaded and stored on the chip, 
but also citizens wishing to pay for their children the 
school canteen fee. Figure 5 reports some snapshots 
of the system output on different devices. As a 
matter of fact, a Common User Interface has been 
designed following the User Centred Design 
approach (Carroll, 1995, Andreadis et alii, 1997). 
According to this approach, we have carried out 
three iterative cycles of the following tasks: user 
requirements analysis – feedback to the designers – 
new implementation – user evaluation. As a result, a 
simple but efficient user interface has been achieved, 
allowing a user-friendly service interaction that has 
been positively evaluated by different groups of 
users involved in the testing. 
Figure 5: service output for kiosk and PDA. 
 
Referring to personalization, several tests have 
been performed, to provide users with the chance to 
define preferences in terms of both services and user 
interface. As for services, every single user is 
allowed to create his profile only with the services 
he is interested in. On the other side, several efforts 
have been devoted to user interface customizations, 
allowing users to modify many interface parameters 
(font color, type and size, background color, menu 
colors, etc.). Some default settings have been 
defined to match specific needs of  some groups of 
user. In particular, low-vision user requirements 
have been taken into account by designing a default 
WEBIST 2006 - WEB INTERFACES AND APPLICATIONS
308