Personal Identification in the Web Using Electronic Identity Cards and a Personal Identity Provider

Abstract

This paper presents a new paradigm for implementing the authentication of individuals within Web sessions. Nowadays many countries have deployed electronic identity cards (eID tokens) for their citizens' personal identification, but these are not yet well integrated with the authentication of people in Web sessions. We used the concept of Personal Identity Provider (PIdP) to replace (or complement) the role ordinarily given to institutional Identity Providers (IdPs), which are trusted third parties to which service providers delegate the identification and the authentication of their clients. By running locally on a citizen's computer, the PIdP paradigm is well suited to assist his/her eID-based authentication. In this paper we describe an eID-based authentication protocol handled by a PIdP, its implementation and its integration in a production scenario (a campus-wide, Shibboleth IdP-based authentication infrastructure used in University of Aveiro).

An Architecture to Support the Invocation of Personal Services in Web Interactions

“…The proposed architecture was implemented on an HTTP proxy and successfully tested with an adapted implementation of the authentication protocol described in [8].…”

“…In [8] we explored the concept of personal services to extent the OASIS SSO authentication process with a Personal IdP (PIdP). This PIdP was able to interact with a local eID token in order to perform a user identification and authentication with it.…”

“…Section 4 presents the implementation of a prototype that was developed for experimenting our contribution. Section 5 presents an experimentation of our proposal with a personal service conceived for an eID-based personal authentication, presented in [8]. Section 6 discusses the usage of the proposed architecture by active code running on Web resources loaded by browsers, namely JavaScript.…”

“…This last approach is similar to the one already mentioned in the introduction [8], which uses HTTP redirections instead of HTTP requests from JavaScript code. The advantages of using JavaScript are twofold: first, different ports can be used (which tolerates collisions in port allocations), since with JavaScript it is possible to test all pre-established ports sequentially until finding a hit, while this is impossible with HTTP redirection codes (because after a failure the control does not return to the SP that did the redirection); second, a service can be implemented together by JavaScript code and an external application.…”

“…* , and some TCP port). As previously referred at the end of Section 1.2, this was explored in [8] to explore a single personal service.…”