Author: Petros Kavassalis

E-commerce and online Service Providers, either private or public (such as e-government service providers) increasingly rely on third parties to identify and authenticate their users; Facebook, Google. Microsoft and others gradually become de facto providers of a personal e-identity that is, after a User’s request, transferred over the Internet to the requester Service Provider. In this perspective, an e-commerce or online Service Provider (SP) acts as a Relying Party who delegates web login to an Identity Provider (IdP), in the context of a web SSO (Single Sign-on) System. However, Social Networks and other popular identity web providers are not, by definition, authoritative sources of personal data. And, the authentication level they provide does not fully guarantee strong security and privacy with sensitive data.

Given the problems with authentication based on current web SSO, other solutions may appear more attractive to SPs. The success of eduGAIN as Identity Federation, for the needs of the academic community, is an interesting case to be carefully studied. Similar efforts to build federated identity systems to access e-government systems are now deployed by various countries. Specific regulations are also introduced to promote strong authentication and encourage SPs to re-organize the management of electronic identities of their users. eIDAS in Europe is perhaps the most complete regulatory framework for electronic identification and trusted service provision, as well as a best practice for cross-border authentication. Beyond regulation, eIDAS is a network of national proxy nodes and trusted IdPs providing different sets of personal a and legal identity attributes obtained from authoritative resources. Service Providers (SP) are becoming increasingly interested in connecting their services to eIDAS Network, in order to make their offerings accessible across EU countries borders and enjoy the legal coherence and (high) online safety requirements of the eIDAS framework. But how Service Providers can become familiar with eIDAS Network architecture and connect to this network with the minimum possible effort and cost?

LEPS introduces the concept of a stand-alone API Connector that can be easily deployed within SP’s premises and interoperate with existing applications and operations modes, thus making integration with a (proxy-based) eIDAS Node a standardized and lean process. An illustration of this is presented in the following Figure.


LEPS provides the ingredients of a cost-effective strategy that consists of using a standardized, open source (under EUPL license) and “of-the-shelf” Connection Facility that makes SP applications de facto interoperable with an eIDAS Node (proxy-based). Essentially, it is about using a REST-like API Connector that enables automated User Registration/Authentication to SP facilities via eIDAS eID_EU by efficiently streamlining the whole authentication process from the SP application login to eIDAS Node and back. Three (3) efficient API solutions (presented in the Table that follows) with different characteristics are currently offered, to cater for any usage and requirements scenario.

LEPS API interoperate with eIDAS Node software version 1.4 and progressively adapt to the new conditions introduced by eIDAS Node software version 2.0.