Introduction to the Connecting Europe Facility eID ... · ... DIGIT Unit B1 Introduction to the...

Copyright European Commission — DIGIT Unit B1

Introduction to the Connecting Europe Facility

eID building block

Version 1.01

Introduction to the Connecting Europe Facility eID building block Version 1.01

Copyright European Commission — DIGIT Unit B1 of 34

Document history

Version Date Reason for modification Modified by

0.01 20/04/2015 First draft JS - DIGIT B.1

0.09 29/04/2015 Second draft JS - DIGIT B.1

1.0 30/04/2015 Published JS - DIGIT B.1

1.01 13/05/2015 Update DIGIT B.1



Table of contents

1. INTRODUCTION ......................................................................................6

Purpose of this document ............................................................................................... 6

2. BACKGROUND .........................................................................................7

Connecting Europe Facility (CEF) ............................................................... 7 2.1

What is CEF? .................................................................................................................... 7

Why do we need building block DSIs? ............................................................................ 8

What is included in each building block package? .......................................................... 9

CEF eID Building Block ............................................................................. 9 2.2

3. THE NEED FOR, AND CHALLENGES OF, AN EID SOLUTION .................... 11

Why is there a need for a cross-border eID solution? ................................... 11 3.1

What are the challenges for such a cross-border eID solution? ...................... 12 3.2

What are the benefits of using the CEF eID solution? ................................... 12 3.3

Who can benefit from CEF eID? .................................................................................... 13

4. THE CEF EID INTEGRATION PACKAGE — THE BIG PICTURE .................. 15

STORK beginnings .................................................................................. 15 4.1

e-SENS and CEF ..................................................................................... 16 4.2

CEF eID integration package – high level description ................................... 17 4.3

Use case scenarios ................................................................................. 19 4.4

4.4.1 User from a proxy country accessing a service in another proxy country ....... 19

4.4.2 User from a Middleware country accessing a service in a proxy country ........ 21

4.4.3 User from a proxy country accessing a service in a Middleware country ........ 22

4.4.4 User in a Middleware country accessing a service in another Middleware country ............................................................................................... 23

Interfaces .............................................................................................. 23 4.5

Standards for exchanging authentication data between Member States .......... 25 4.6

4.6.1 Features of SAML .................................................................................. 27

4.6.2 Messaging standards ............................................................................. 27

Confidentiality and integrity ..................................................................... 28 4.7

5. SOLUTION ARCHITECTURE OVERVIEW ................................................. 30

6. GETTING STARTED ................................................................................ 33

7. SUPPORT .............................................................................................. 34

End-user support .................................................................................... 34 7.1

Service Provider support .......................................................................... 34 7.2

Member State support ............................................................................. 34 7.3



List of abbreviations

The following abbreviations are used within this document.

Abbreviation Meaning

AP Attribute Provider.

C-PEPS Citizen Country PEPS: PEPS in the citizen's country. This is the eIDAS-NODE Service.

DSI Digital Service Infrastructures

e-SENS Electronic Simple European Networked Services

IdP Identity Provider. An institution that verifies the citizen's identity and issues an electronic ID.

MW Middle Ware. Architecture of the integration of eIDs in Services, with a direct communication between SP and the citizen's PC without any central server. The term also refers to the piece of software of this architecture that executes on the citizen's PC.

MS STORK Member State

PEPS Pan European Proxy Service or Server. This is an eIDAS-NODE.

QAA Quality Authentication Assurance Level.

SAML Security Assertion Markup Language

S-PEPS Service Provider PEPS – PEPS in the Service Provider's country. This is an eIDAS-Node Connector.

SP Service Provider

STORK Secure idenTity acrOss boRders linKed



List of definitions

Term Definition

Building block DSIs Basic digital service infrastructures which are key enablers to be reused in more complex digital service infrastructures.

Digital Service Infrastructures

Networked services to be delivered electronically, typically over the internet, providing Trans-European interoperable services of common interest for citizens, businesses and/or administrations.

Sector-specific or thematic DSIs

More complex digital service infrastructures within one policy area; often supporting the implementation of EU legislation.

Disclaimer

This document is for informational purposes only and the Commission cannot be held responsible for any use which may be made of the information contained therein. References to legal acts or documentation of the European Union (EU) cannot be perceived as amending legislation in force or other EU documentation.

The document contains a brief overview of technical nature and is not supplementing or amending terms and conditions of any procurement procedure; therefore, no compensation claim can be based on the contents of the present document.



1. Introduction

Purpose of this document

This document describes the Electronic Identification (eID) building block which is one of the Connecting Europe Facility (CEF) Digital programme's essential digital services. These essential digital services, called building block Digital Service Infrastructures (DSIs) will play a vital role in the flow of data across borders and sectors.

The document will help Service Providers, Service Operators and Implementers who are interested to know more about to better understand the CEF eID facility. In particular it provides information on the background, terminology, concepts, roles, components, connectivity, features and architecture of the CEF eID.

What information will you find in this document?

This document is divided into the following sections:

Section 1 −Introduction, this section.

Section 2 − Background discusses the background to CEF eID facility.

Section 3 — The need for, and challenges of, an eID solution, discusses the political motivation behind the rolling-out of an eID facility.

Section 4 —The CEF eID integration package — the big picture, introduces the main components and describes how they interact by way of several use case scenarios.

Section 5 — Solution architecture overview, shows a more functional view of an eIDAS-Node.

Section 6 — Getting started, suggests what you can do to get hands-on experience of building your own eIDAS implementation.

Section 7 — Support, provides information on the support services provided.

Who is it intended for?

This document is intended for anyone interested in the CEF eID facility, in particular:

Service Providers interested in integrating in an existing online platform (e.g. ERASMUS registration of students) of this eID DSI in order to enable citizens from any Member State to use its national eID to access a public service;

Service Operators interested in operating the Pan-European Proxy Services (eIDAS-Nodes) at national level in order to guarantee the availability of the service for the first years of operation;

Implementers interested in setting-up Pan-European Proxy Services (eIDAS-Nodes) at national level in order to link the national eID service to the core platform.



2. Background

Connecting Europe Facility (CEF) 2.1

What is CEF?

The Connecting Europe Facility (CEF) is the common financing instrument of trans-European networks for the period 2014-2020. During this period, CEF will help to complete the European single market by making available €33.24 billion in the form of procurement, grants and innovative financial instruments.

CEF will finance projects of common interest in three different sectors:

transport (€26.25 billion);

energy (€5.85 billion); and

telecommunications (€1.14 billion).

CEF Digital

Within the telecommunications area, CEF is anchored to the Europe 2020 Strategy for smart, sustainable, and inclusive growth, which put digital infrastructures at the forefront with the Digital Agenda for Europe (DAE) initiative. To contribute to the vision of an interconnected Europe, the CEF telecommunications area works on broadband and digital service infrastructures (DSIs).

Two types of DSIs are financed:

Building block DSIs: DSIs that offer utility services which can be reused in several sectors and in other more complex DSIs. These DSIs can be understood as the

https://ec.europa.eu/digital-agenda/news-redirect/15541



utilities (water, electricity and gas) of the digital era and are therefore called 'building block DSIs';

Sector-specific DSIs: DSIs that offer services linked to a specific sector.

Building block DSIs are given priority over sector-specific DSIs since they need to be in place from the outset to underpin the other services.

DSIs are composed of two distinct layers:

Core Service Platforms are the central hubs which enable trans-European connectivity. This part of a DSI is managed, implemented and operated by the Commission. In this case funding is mostly done in the form of procurement;

Generic Services are the link between national infrastructures to the core service platforms. This part of a DSI is managed, implemented and operated by the Member States. In this case funding is mostly done in the form of grants.

Why do we need building block DSIs?

The flow of data across borders and sectors is essential to the free movement of people, goods, services and capital in the EU. While much has been achieved in the last decade, digital data exchange still ‘stops at the border’ or 'stays confined within sectors'. This is why the European Commission is promoting the roll-out of these building block DSIs.

What is the ultimate goal?

The ultimate goal is to offer digital services beyond national borders and sectors.

As the building blocks are based on standards, every software vendor or service provider will be able to develop a service on top of them. The expected end result of the process is the emergence of a European interoperability ecosystem where information systems are able to quickly offer and consume services across national borders, and sectors. Once the building blocks are used in the Member States, they will become crucial components in the delivery of digital services.

The following building blocks are made available:

eID - helps public administrations and private online service providers to easily extend the use of their online services to citizens from other EU Member States;

eSignature - helps public administrations and businesses to accelerate the creation and verification of electronic signatures;

eDelivery - helps public administrations to exchange electronic data and documents with other public administrations, businesses and citizens, in an interoperable, secure, reliable and trusted way;

eInvoicing - helps public administrations implement electronic invoicing in compliance with the eInvoicing Directive of the European Parliament and the Council; and

Automated Translation - helps European and national public administrations exchange information across language barriers in the EU.

https://joinup.ec.europa.eu/community/cef/og_page/catalogue-building-blocks#eID

https://joinup.ec.europa.eu/community/cef/og_page/catalogue-building-blocks#eSignature

https://joinup.ec.europa.eu/community/cef/og_page/catalogue-building-blocks#eDelivery

https://joinup.ec.europa.eu/community/cef/og_page/catalogue-building-blocks#eInvoicing

https://joinup.ec.europa.eu/community/cef/og_page/catalogue-building-blocks#AT



What is included in each building block package?

These solutions are either offered as software or central services. Furthermore, every building block DSI includes support and training for adopters. The building blocks can therefore be combined with each other and integrated with sector-specific applications.

For information on each of them, please refer to the online catalogue of building blocks available on Joinup.

CEF eID Building Block 2.2

The CEF eID building block helps public administrations and private online service providers to easily extend the use of their online services to citizens from other EU Member States. It allows cross-border authentication, in a secure, reliable and trusted way, by making national electronic identification systems interoperable.

Once this building block is deployed in a Member State, the mutual recognition of national eIDs becomes possible between participating Member States, in line with the eIDAS (electronic Identification and Signature) legal framework and with the privacy requirements of all the participating countries. Mutual recognition of national eIDs allows citizens of one Member State to access online services provided by public and private organisations from other participating EU Member States, using their own national eID.

Our solution

Following the successful completion of the STORK pilot programme (as described in section 4.1 — STORK beginnings), CEF has taken on the role to 'productise' and support roll-out of eID connectivity to other Member States. This has included the development of open-source software components, documentation, training and support. Member States can leverage their electronic ID systems to provide access to the services of other Member States with confidence in the high levels of assurance provided by secure means of authentication linked to qualified identities.

Software &

SpecificationsCentral service

Maintenance

Training

Support

Stakeholder

Management

Architecture

The CEF building block package

or / and

https://joinup.ec.europa.eu/community/cef/og_page/catalogue-building-blocks



The solution includes the following components and auxiliary services:

For more information about this software, please refer to the CEF eID page.

Software &

Specifications

Central

service

Tools for setting up a demo

environment for testing purposes

eID Integration package for Member

States to become STORK-enabled

i1st eIDAS-compliant release foreseen

for September 2015

Maintenance

Training

Support

Stakeholder

Management

Architecture

https://joinup.ec.europa.eu/software/cefeid/home



3. The need for, and challenges of, an eID solution

Electronic identification (eID) and electronic Trust Services (eTS) are key enablers for secure cross-border electronic transactions and central building blocks of the Digital Single Market.

The Regulation (EU) N°910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation) adopted by the co-legislators on 23 July 2014 is a milestone to provide a predictable regulatory environment to enable secure and seamless electronic interactions between businesses, citizens and public authorities. The eIDAS Regulation, which is based on the Commission Communication (COM(2012)238 final of 4 June 2012), will increase the effectiveness of public and private online services, eBusiness and electronic commerce in the EU.

eID and eTS - namely electronic signatures, electronic seals, time stamp, electronic delivery service and website authentication - are inseparable by essence when analysing the requirements needed to ensure legal certainty, trust and security in electronic transactions.

In this regard, the eIDAS Regulation:

ensures that people and businesses can use their own national electronic identification schemes (eIDs) to access public services in other EU countries where eIDs are available.

creates a European internal market for eTS by ensuring that they will work across borders and have the same legal status as traditional paper based processes. Only by providing certainty on the legal validity of all these services will businesses and citizens use these digital interactions as their natural way of interaction.

Why is there a need for a cross-border eID 3.1

solution?

More than twenty European countries currently have eID systems in place. These systems protect electronic services mostly pertaining to the public sector, but in some cases also covering commercial applications. They all have varying security mechanisms for identification and authentication, and are based on different philosophies which lack cross-border recognition and validation, thereby fragmenting the Single Market.

In this context, and aligned with the efforts to strengthen the digital single market, the trans-European availability of widespread and secure access to the internet and digital services is essential if Europe is to reap the full benefits of this technological revolution.

Therefore there is a need for a cross-border eID solution that enables the interoperability between the different national eID solutions, and that:

allows secure cross-border access to the internet and digital services,

protects against the risk of identity theft and misuse of personal information, and

provides legal validity of transactions.

http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2012:0238:FIN:EN:PDF



What are the challenges for such a cross-border 3.2eID solution?

The cross-border eID solution should enable the interoperability between the different national eID solutions at different levels: legal, organisational, semantic and technical.

Legal interoperability

The national eID solutions have been developed following the national legislation. When information is exchanged cross-border, the legal validity of the authentication process and the information exchanged must be maintained across borders and data protection legislation in both originating and receiving countries must be respected.

Organisational interoperability

Once the national eID solutions have been interconnected in order to ensure service continuity the organisational relationship between the different Member States must be clarified and the necessary operational management related process detailed (e.g. change management, release management).

Semantic interoperability

The electronic identification information exchanged in a cross-border scenario must be transmitted in meaningful way to and from external sources to ensure that the precise meaning of exchanged information is understood and preserved throughout exchanges between parties. The national eID solutions have developed the message format and its meaning independently and therefore there is a need to ensure the mapping between the different national solutions.

Technical interoperability

When interconnecting the different national eID solutions, it should be technically possible to link the different eID information systems. This includes aspects such as interface specifications, interconnection services, data integration services, data presentation and exchange, etc.

What are the benefits of using the CEF eID 3.3

solution?

The CEF eID solution ensures compliance with the eIDAS Regulation. This regulation ensures legal interoperability by providing a clear regulatory framework. The Regulation (EU) N°910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS Regulation) strengthens the EU Single Market by boosting trust and convenience in secure and seamless cross-border electronic transactions:

Mutual recognition of e-identification means

Electronic trust services

Electronic documents

Key principles of eID are:

Mandatory cross-border recognition only to access public services

Free of charge for public services

Acceptance relies on defined levels of assurance

http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R0910&from=EN

http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R0910&from=EN



CEF eID solution is based on a mature eID solution (for more information see 4.1 STORK beginnings) tested in a cross-border scenario. This solution ensures semantic and technical interoperability, including the technical and operational security requirements coming from the eIDAS Implementing acts.

The CEF eID solution is accompanied by a set of auxiliary (e.g. subject matter expert support, 24/7 Help Desk), and falls under the CEF IT Governance.

Who can benefit from CEF eID?

EvolutionPiloting

Legal interoperability

Organisational interoperability

Semantic interoperability

Technical interoperability

eIDAS Regulation

CEF

Public administration

•Cost savings

•Compliance (legal and policy)

•Increased assurance

•Financial support

Service Provider

•Cost savings

•Compliance


Citizen

•Ease of use

•Cost saving




If you are a public administration that would like to set up and/or operate this cross-border eID solution, you would achieve:

Cost savings as the CEF eID solution provides a sample implementation of the cross-border eID solution and support during integration testing;

Compliance with the eIDAS Regulation

Increased assurance for the provided solution as the CEF eID solution meets the technical, operational security requirements set up by the eIDAS implementing acts.

If you are a service provider that would like to enable the cross-border eID solution you would achieve:

Cost savings as the cross-border eID solution would be in place;

Compliance with the eIDAS Regulation

Increased assurance for the provided solution as the CEF eID solution meets the technical, operational security requirements set up by the eIDAS implementing acts.

Finally citizens will be able to access cross-border services, in a secure way, using their national eID.



4. The CEF eID integration package — the big picture

STORK beginnings 4.1

Cross-border eID interoperability is a complex and multi-disciplinary issue covering legal, operational, semantical and technical aspects. To meet this challenge the European Commission initiated and co-funded an eID Large Scale Pilot under the Competitiveness and Innovations Framework Programme, ICT Policy Support Programme (CIP, ICT-PSP). This initiative resulted in STORK – which stands for Se-cure identiTy acrOss boRders linKed [2009 AUS]

STORK was a Large Scale Pilot aiming at solving the issues of cross-border interoperability of eID. The basic assumption was to build a modular technological infrastructure on top of national eID infrastructures.

Two models are used by countries involved with STORK:

proxy

middleware

The decision of which model to follow depends on the country. It may be based on weighing a number of considerations, including:

liability

scalability

data protection

legal requirements

end-to-end security

The application of the proxy and middleware models is described in section 4 — The CEF eID integration package — the big picture in this document.

During the pilots the technical infrastructure was developed and deployed to prove that the technology is feasible and sustainable to meet the needs of legacy eID systems and those of the future.

As a result of the STORK pilots:

In 6 Member States a framework has been developed for an interoperable service allowing foreign citizens (using their eID credentials) to notify all relevant entities of an address change. This was achieved without modifying current procedures in each Member State.

12 Member States have integrated STORK with the European Commission Authentication Service (ECAS). This integration allowed citizens from those Member States to use their national eIDs to access electronic services of the European Commission.

5 Member States are currently using the STORK solution in their eDelivery applications, allowing citizens from other Member States to access the service with their own eID credentials.



In 5 Member States foreign students can access online administrative and academic services offered by European Universities with their eID.

10 Member States allow foreign citizens to register for social security with their eID credentials.

Figure 1: STORK evolution

e-SENS and CEF 4.2

e-SENS (Electronic Simple European Networked Services) is a large-scale project with the aim of consolidating, improving, and extending technical solutions based around the building block DSIs to foster digital interaction with public administrations across the EU.

e-SENS will facilitate cross-border processes within the EU by:

making it easier for companies to set up business electronically;

enabling electronic procurement procedures for businesses;

creating seamless access to EU legal systems;

making it easier to use healthcare services abroad in cases of emergency.

e-SENS is piloting the use of building blocks including eID to develop the digital infrastructure for improving the quality of public services in the EU.

CEF incorporates improvements resulting from the pilots, and packages the solution with documentation, training and support, before making it available for deployment by Member States.

For more information on how e-SENS and CEF work together, please refer to https://joinup.ec.europa.eu/community/cef/news/e-sens-and-connecting-europe-facility-how-do-they-work-together.

https://joinup.ec.europa.eu/community/cef/news/e-sens-and-connecting-europe-facility-how-do-they-work-together

https://joinup.ec.europa.eu/community/cef/news/e-sens-and-connecting-europe-facility-how-do-they-work-together



CEF eID integration package – high level 4.3description

The CEF eID Building Block is based on the results of the CIP (Competitiveness and Innovation Programme) project known as STORK.

Under the umbrella of the CEF eID Building block a set of actions were launched to establish a solid technical and organisational infrastructure, which are generic by design and suitable for re-use in many different contexts, providing an initial set of facilities and then extending them gradually. The solution provided by the CEF eID Building Block is fully in line with the eIDAS regulation and has at its core the eIDAS technical specifications.

CEF eID solution is an open source sample implementation of the eIDAS technical specifications which is based around the concept of the eIDAS-Node to enable Member States to connect their own eID infrastructure to Service Providers in other Member States, and to connect a national Service Provider to the eID infrastructures of other Member States.

An eIDAS-Node, as defined by IDABC1, is an application component that:

provides standardised common interfaces therefore hides national complexities from other countries

elevates the national circle of trust to European level

guarantees scalability (as any change in a Member State will only affect its own node).

An eIDAS-Node can assume two different roles depending on the origin of a received request. It can be an:

eIDAS-Node Connector: The eIDAS-Node assumes this role when it is located in the Service Provider’s Member State. In a scenario with a Service Provider asking for authentication, the eIDAS-Node Connector receives the authentication request from the Service Provider and forwards it to the eIDAS-Node of the citizen’s country.

eIDAS-Node Proxy-Service: The eIDAS-Node assumes this role when it is located in the citizen’s Member State. The eIDAS-Node Proxy-Service receives authentication requests from an eIDAS-Node of another MS (their eIDAS-Node Connector). The eIDAS-Node Proxy-Service also has an interface with the national eID infrastructure and triggers the identification and authentication for a citizen at an identity and/or attribute provider.

In one cross-border transaction, an eIDAS-Node will only assume the role of Connector or Service depending on the direction of the transaction.

1 Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens



Except in the case of 'Middleware countries', each Member State has its own eIDAS-Node located in its own environment. Middleware countries do not have an eIDAS-Node and chose for a Middleware solution to connect to other Member States’ eID infrastructures.

The Middleware of these countries consists of three parts:

MS Specific Middleware –This is usually a piece of software running on the user’s PC or a Java applet running in the user’s browser that handles the smart card communication.

eIDAS-Node Middleware Service– Handles the actual authentication process and the communication with applications of a Service Provider. This can be integrated into an eIDAS-Node as a Middleware Service plugin in a non-Middleware country or it can be situated in the Service Provider's domain in a Middleware country.

eIDAS Connector running in the Middleware country - Requests a cross-border authentication to a non-Middleware country.

Middleware country environments can be accessed through eIDAS-Nodes located in the other Member States. More specifically, each of the other countries’ eIDAS-Nodes contains an eIDAS Middleware Service plugin. This plugin is responsible for the communication between the eIDAS-Node and the required Middleware.

The diagram below illustrates the main components in an eIDAS solution. It shows:

Two Member States, MS A and MS B both of which are 'proxy countries', i.e. they do not operate their own Middleware.

A user (citizen).

A Service Provider (SP) (public administrations and private online service providers).

The eIDAS-Node in the Member State of the target Service Provider.

The eIDAS-Node in the Member State of the user. Conceptually, each eIDAS-Node consists of:

o four interfaces (see section 4.5 — Interfaces).

o a Connector (formerly known as an S-PEPS).

o a Proxy Service (formerly known as a C-PEPS).

o one or more MS middleware service plugins (optional) for communication with middleware countries (formerly known as VIDP).

The National electronic Identity Provider of the user's Member State.

The Attributes Provider of the user's Member State.



Figure 2: The main components in an eIDAS implementation

The four main interfaces of an eIDAS-Node are:

1. Service Provider interface

2. Interfaces with other national eIDAS-Nodes

3. Interface to the user

4. National eID Interface

Use case scenarios 4.4

The eIDAS solution has been developed to accommodate a variety of national/international schemes to maximise interoperability. The following sections contain scenarios of flows in certain use cases.

4.4.1 User from a proxy country accessing a service in

another proxy country

The figure below shows the scenario of a user whose country is a proxy country, accessing a service in another proxy country.

Service Provider

National eID

eIDAS-Node

Proxy-Service

ConnectorConnector

Proxy-Service

eIDAS-Node

MS A MS B

Middleware Service plugin


Attributes Provider

122

34



Figure 3: User from a proxy country accessing a service in another proxy country

For this scenario the process is as follows:

1. The user in MS A requests access to a Service Provider in MS B, both proxy countries.

2. The Service Provider in MS B sends the request to its own eIDAS-Node (Connector).

3. On receipt of the request, the eIDAS-Node Connector asks the user for their country of origin (TLS protocol).

4. When the country of origin is selected by the user, the SAML Request is forwarded by the eIDAS-Node Connector to the eIDAS-Node Proxy-Service of the user's Member State.

5. The user authenticates using their electronic identity. Once authenticated, this identity is forwarded to the eIDAS-Node (eIDAS-Node Proxy-Service). Depending on the implementation there may be two additional steps within step 5:

o for the user to select the attributes to be provided (therefore giving consent)

o for the user to agree the values of the attributes to be given.

6. The eIDAS-Node Proxy-Service sends a SAML Assertion to the requesting eIDAS-Node Connector, which forwards the response to the Service Provider.

7. The Service Provider grants access to the user.

Interaction with the user only happens in stages 1, 3, 5 and 7. The remainder of the process is automated and invisible to the user.

The Identity Provider and the Attribute Provider would be in MS A.

Service Provider

1

23

4

5

5

6

6

7

National eID

eIDAS-Node

Proxy-Service

ConnectorConnector

Proxy-Service

eIDAS-Node

MS A MS B



4.4.2 User from a Middleware country accessing a service in a proxy country

The figure below shows the scenario of a user whose country is a Middleware-country, accessing a service in a proxy country.

Figure 4: User from a Middleware country accessing a service in a proxy country

Note: For a proxy country to authenticate to a middleware country, the proxy country must have integrated the middleware country's Middleware Service plugin in its eIDAS-Node.


1. The user in MS A requests access to a Service Provider in MS B (a proxy country).

2. The Service Provider sends a request to the eIDAS-Node (Connector) in its own country.

3. On receipt of the request, the eIDAS-Node Connector asks the user for their country of origin (using TLS protocol).

4. When the country of origin is selected by the user, the request is forwarded by the eIDAS-Node Middleware Service plugin to the MS Specific Middleware of the user's Member State (SAML Request).

5. The user authenticates using their national electronic identity and the Middleware infrastructure in his/her country. Depending on the implementation there may be two additional steps within step 5:

o for the user to select the attributes to be provided (therefore giving consent)

Service Provider

MS Specific Middleware

1

23

4

5

5

6

6

7

National eID

Connector

MS A Middleware Service plugin

eIDAS-Node

MS A MS B



o for the user to agree the values of the attributes to be given.

6. Once authenticated, the MS Specific Middleware sends a response back to the eIDAS-Node Middleware Client, which passes the response to the eIDAS-Node Connector (SAML Assertion). The eIDAS-Node then sends the electronic identity information to the Service Provider.


Interaction with the user only happens in stages 1, 3, 5 and 7. The remainder of the process is automated and invisible to the citizen.


Note that the Middleware Service can be running in the domain of the Service Provider. However, the authentication process remains the same.

4.4.3 User from a proxy country accessing a service in a Middleware country

The figure below shows the scenario of a user whose country is a proxy country, accessing a service located in a Middleware country.

Figure 5: User from a proxy country accessing a service in a Middleware country


1. The user in MS A (a proxy country) requests access to a Service Provider in MS B (a Middleware country).

2. The Service Provider sends a request to the MS Specific Middleware in its country.

Service Provider


1

23

4

5

5

6

6

7

National eID

MS A MS B

Proxy-Service

MS B Middleware Service plugin

eIDAS-Node



3. On receipt of the request, the MS Specific Middleware asks the user for their country of origin (using TLS protocol).

4. When the user selects their country of origin, the request is forwarded by the MS Specific Middleware to the eIDAS-Node Middleware Service plugin of the user's Member State (MS A)

5. The user authenticates using their national electronic identity. Once authenticated, this identity is forwarded to the Member State’s eIDAS-Node (eIDAS-Node Proxy-Service).

6. The eIDAS-Node passes the eID information to the requesting Middleware Service plugin, which forwards the response to the MS Specific Middleware in MS B which passes it on to the Service Provider.


Interaction with the user only happens in stages 1, 3, 5 and 7. The remainder of the process is automated and invisible to the user.


4.4.4 User in a Middleware country accessing a service in another Middleware country

As the two Middleware countries authenticate via their own MS Specific Middleware, the eIDAS-Node does not play a role, therefore this scenario is out of scope of this document.

Interfaces 4.5

To ensure interoperability between eID infrastructures in different Member States, a number of interfaces have been defined to facilitate the integration between parties in the eID environment.



Figure 6: Defined interfaces

The architecture of each eIDAS-Node provides interfaces to integrate with the following:

1. Service Providers in the Member State where the eIDAS-Node is deployed: – A Member State’s eIDAS-Node has an interface to communicate with multiple Service Providers in that Member State. Through this interface, the Service Provider sends authentication requests to the eIDAS-Node and receives the authentication responses. Note: This interface is MS specific, it can be customised to suit the requirements of the Service Provider.

2. Other eIDAS-Nodes in Member States using the proxy-based infrastructure – An eIDAS-Node has an interface for communication with eIDAS-Nodes in other Member States. This results in the cross-border interoperability of the eID solution. When communicating through this interface, one eIDAS-Node will have the role of eIDAS-Node Proxy-Service and the other one the role of eIDAS-Node Connector. These respectively request and provide identity information to the other eIDAS-Node; and Member State Specific Middleware in non-proxy countries –this interface connects to the Middleware Service plugin of the eIDAS-Node. Multiple Middleware interfaces are possible as long as the Middleware countries provide their specific Middleware Service plugins for integration into the eIDAS-Node.

3. Users requesting access to the Service Provider – This interface is used for the communication between the eIDAS-Node and the user’s proxy via their browser. It is used when requesting the user to select their country of origin.

Service Provider

National eID

eIDAS-Node

Proxy-Service

ConnectorConnector

Proxy-Service

eIDAS-Node

MS A MS B



Attributes Provider

122

34



4. National eID and Attributes Provider – This MS specific interface is used to connect the eIDAS-Node in the user's MS to their National eID (Identity Provider) and Attribute Provider.

Standards for exchanging authentication data 4.6

between Member States

Communication between eIDAS-Nodes and between an eIDAS-Node and an MS Specific Middleware component uses Security Assertion Markup Language (SAML) for authentication information (both requests and responses). Communication between a Service Provider and Identity Providers can be MS specific as shown in the diagram below and the following table.

Figure 7: Data flows — proxy country to proxy country

Service Provider

1

23

4

5

5

6a

6b

7

National eID

eIDAS-Node

Proxy-Service

ConnectorConnector

Proxy-Service

eIDAS-Node

MS A MS B



Table 1: Data flows — proxy country to proxy country

Data flow Connection Messaging protocol

1,7 User / Service Provider Typically HTTPS

2,6b Service Provider / eIDAS-Node SAML Request/SAML Response (containing a SAML assertion).

3 eIDAS-Node / user TLS

5 eIDAS-Node / National eID MS specific

4 eIDAS-Node / eIDAS-Node SAML Request

6a eIDAS-Node / eIDAS-Node SAML Response containing a SAML Assertion (assurance that a certain person has authenticated successfully at the identity provider).

The figure below and the following table show the data flows and protocols used when a user in a Middleware country is accessing a service in a proxy country.

Figure 8: eIDAS-Node data flows — Middleware country to proxy country

Service Provider


1

23

4

5

5

6

6

7

National eID

Connector

MS A Middleware Service plugin

eIDAS-Node

MS A MS B



Table 2: Data flows — Middleware country to proxy country

Data flow Connection Messaging protocol

1,7 User / Service Provider Typically HTTPS

2,6b Service Provider / eIDAS-Node SAML Request / SAML Response

3 eIDAS-Node / user TLS

5 eIDAS-Node / National eID MS specific

4 eIDAS-Node / MS Specific Middleware

SAML Request

6a MS Specific Middleware / eIDAS-Node

SAML Response containing a SAML Assertion (assurance that a certain person has authenticated successfully at the identity provider).

4.6.1 Features of SAML

SAML provides the following features:

Single Sign-On: SAML has standardised protocols for the exchange of authentication information independent of the DNS domains.

Federated identity: SAML enables the exchange of user information across security domains between partners.

Support for web services and other industry standards: SAML is flexible enough to allow SAML messages in other frameworks, so that the messages don’t need to be strongly based on a SAML protocol.

All SAML related functionality is encapsulated in one component of the eIDAS-Node.

4.6.2 Messaging standards

The following table describes the industry-standard protocols that are used within an eID implementation.



Table 3: Messaging standards

Interface Messaging standard Binding

Interface between eIDAS-Nodes

SAML 2.0 HTTP Post/Redirect Binding

e-IDAS-Node – eIDAS Middleware Service

SAML 2.0 HTTP Post/Redirect Binding

Interface between citizen's browser and eIDAS-Node Connector / eIDAS-Node Proxy-Service

TLS 1.2 (if supported by the citizen's browser. TLS 1.1 MAY be used if usage of TLS 1.2 is not possible)

HTTP Post/Redirect Binding

A SAML binding is a mapping of a SAML protocol message onto standard messaging formats and/or communications protocols.

HTTP Redirect Binding: SAML protocol messages are often carried directly in the URL query string of an HTTP GET request.

Longer messages (e.g., those containing signed SAML assertions) should be transmitted via other bindings such as the HTTP POST Binding.

Confidentiality and integrity 4.7

Since the information exchanged during the authentication process is confidential, the eID infrastructure is expected to ensure confidentiality of the person identification data. Next to the confidentiality of this data, authenticity of the person identification data and authenticity of the data sending components is also required. These requirements are met using public key cryptography.

Confidentiality is provided by means of TLS protocol providing the interface between the user's browser and the eIDAS-Node.

To meet the authenticity requirement, SAML requests/assertions are always digitally signed by every sending component. The SAML messages are signed with an XML signature, which is an XML-based syntax for digital signatures. The digital signatures themselves are created by producing a hash of the message after which this is encrypted. The use of signatures ensures that messages have not been tampered with so that it can be reliably assumed that the message was sent by a specific known sender and was not altered during transmission.

Encryption is a means of mitigating 'man-in-the-browser' attacks. The encryption mechanism is based on a Public Key Infrastructure (PKI) solution. Knowing the public key of the sender, other components receiving the signed SAML messages can verify the authenticity and the origin of the message. The signature is included in the SAML Metadata of the message. When verifying a signature, the receiver extracts the signature of the metadata and runs the signature verification algorithm. This algorithm can then, using the public key of the sender and the same hash function as the sender, indicate whether the message is intact and sent by the right component.



Since Service Providers grant access based on the identity information received from the users, it is important that this information is correct and coming from the right source. Therefore, every component in this identification process should sign its SAML messages to guarantee authenticity. Since an asymmetric encryption scheme is used, the public keys can be stored in a way that they are protected against manipulation. The private keys should however be stored in a secure way to prevent unwanted information leakage.



5. Solution architecture overview

The table below shows the notation that is used in the following architecture diagrams.

Table 4: Architecture notation

Building Block Description

Application component active in the scenario.

Application component non-active in the scenario.

Interface.

Runtime physical object

The table below describes the actions shown in the following diagrams.

Table 5: Diagram action notation

Action Description

1 User requests access to a Service Provider in another MS.

2 Service Provider sends a Service Provider MS-specific request to the eIDAS-Node Connector.

3 User selects their country of origin (eIDAS-Node Proxy-Service country list managed at SP).

3b User select its country of origin (eIDAS-Node Proxy-Service country list managed at eIDAS-Node).

4 Request is forwarded to the eIDAS-Node in the user’s MS (eIDAS-Node Proxy-Service role).

5 The eIDAS-Node forwards the request to the Identity and Attribute Providers, using national protocols.

6 User authenticates using its national electronic identity. User gives consent for attributes and values.

7 Identity and attributes are forwarded to the eIDAS-Node, which translates them in STORK format.

8 SAML response is assembled and sent back to the requesting eIDAS-Node.

9 The eIDAS-Node sends the SAML response back to the Service Provider.

10 Service provider grants access to the user based on the user’s national ID.



The following diagrams show the internal structure of an eIDAS-Node in various forms and illustrate component activity under the various use case scenarios as seen previously.

Figure 9: Internal architecture view — eIDAS-Node to eIDAS-Node with integrated Middleware Service plugins for Middleware countries

Sending MS (User Member State)Receiving MS (Service Provider Member State)

eIDAS Node

CORE

eIDAS Connector(S-PEPS)

MS-Specific Interface

1

10

6

National eID driver

MS specific

eIDAS Service<<abstract>>

eIDAS Proxy Service

(C-PEPS)<<concrete>>

eIDAS MW Service

(AT plugin) <<concrete>>

eIDAS MW Service

(DE plugin)<<concrete>>

Service Provider

CORE

Identity Provider Attribute Provider

eIDAS Node

CORE


MS specific


eIDAS Proxy Service


eIDAS MW Service


eIDAS MW Service


2

3

3b

9

SPMS-

specific Request

SPMS-

specific Request

Citizen

4

8

SAML Request

SAML Response



5 7



Figure 10: Internal architecture view — Middleware country to proxy country

Figure 11: Internal architecture view — eIDAS-Node to eIDAS node – Middleware Service plugin not integrated


eIDAS Node

CORE


1

10

National eID driver

MS specific


eIDAS Proxy Service


eIDAS MW Service


eIDAS MW Service


Service Provider

CORE

2

3

3b

9

SPMS-

specific Request

SPMS-

specific Request

Citizen

Middleware

5

4

6


eIDAS Node

CORE



1

10

6

National eID driver

MS specific


eIDAS Proxy Service


Service Provider

CORE

Identity Provider Attribute Provider

eIDAS Node

CORE


MS specific


eIDAS Proxy Service


2

3

3b

9

SPMS-

specific Request

SPMS-

specific Request

Citizen

4

8

SAML Request

SAML Response



5 7

eIDAS MW Service (VIDP MS A

Adapter

MS B Adapter

eIDAS MW Service (VIDP) MS A

Adapter

MS B Adapter



6. Getting started

In order to help you to gain hands-on experience of setting up an eIDAS-Node of your own, the CEF eID team has prepared a downloadable demo configuration available on Joinup at https://joinup.ec.europa.eu/software/cefeid/release/all.

The PEPS Installation, Configuration and Integration Quick Start Guide included in the package describes how to quickly install a Service Provider, eIDAS-Node Connector and eIDAS-Node Proxy-Service, an Identity Provider and an Attribute Provider. The package provides preconfigured eIDAS-Node modules for running on each of the supported application servers.

The package also provides an example configuration in which each supported server represents one country interacting in STORK. For the purpose of this demo, fictitious countries are used (CA, CB, CC, CD, CF) and the Middleware integrated plugins are by default disabled.

https://joinup.ec.europa.eu/software/cefeid/release/all



7. Support

To guarantee a consistent and reliable support function for the different stakeholders of the eID solution (e.g. users, Service Providers, Member States), a support structure will be put in place to offer the relevant type of support. The following sections detail how each stakeholder group is able to get support.

End-user support 7.1

When an end-user (e.g. citizen) encounters problems when trying to authenticate and use the services of a Service Provider, the user should contact the support function of the Service Provider. It is the responsibility of each Service Provider to set up such a support function for users in need of eID support in their application.

Service Provider support 7.2

Service Providers themselves can be in need of support regarding the eID infrastructure. This can happen in several situations, of which some examples are:

The Service Provider cannot resolve/answer the issue or question raised by a user.

The Service Provider encounters trouble when integrating with the eID infrastructure.

The Service Provider encounters trouble using the eID infrastructure.

It is the responsibility of each Member State to set up a support structure for their own country. In this context, the Member State appoints a local eID representative and country representative to offer support to Service Providers.

Service Providers should always contact the local representative when support is needed. In case this representative is not able to solve/answer the issue, he will get support from the country representative.

Member State support 7.3

To support new or already integrated Member States with the use of the eID infrastructure, functional mailboxes are provided by DIGIT CEF eID. These mailboxes are a contact point for:

Additional information about the eID infrastructure

Feedback on the services provided by the CEF eID building block DSI team

Technical support questions

For generic CEF related comments and queries use:

[email protected]

For specific eID related comments and queries use:

[email protected] specific eID

Introduction to the Connecting Europe Facility eID ... · ... DIGIT Unit B1 Introduction to the...

Documents

Transcript of Introduction to the Connecting Europe Facility eID ... · ... DIGIT Unit B1 Introduction to the...