D.06 Blueprint For Solution

CEF EID BUILDING BLOCK FOR BANKING AND
EDUCATIONAL DOMAINS
Blueprint for solution (incl. sector-specific attributes)

Deliverable
October 2018
This study was carried out for the European Commission by Everis.
Internal identification
Framework Contract SLG.AVT.DI0744501 (STIS IV Lot 3)
COM/DIGIT.D3/2017/SC000881
DISCLAIMER
By the European Commission, Directorate General for Informatics.
The information and views set out in this publication are those of the author(s) and do not
necessarily reflect the official opinion of the Commission. The Commission does not guarantee
the accuracy of the data included in this study. Neither the Commission nor any person acting on
the Commission’s behalf may be held responsible for the use which may be made of the
information contained therein.
© European Union, 2018. All rights reserved. Certain parts are licensed under conditions to the EU. Reproduction is authorized provided
the source is acknowledged.
2/69
Table of Contents
1 Introduction .......................................................................................................................... 7
1.1 Context ............................................................................................................................. 7

1.2 Objectives ......................................................................................................................... 8
1.3 Structure of this document ................................................................................................ 9
1.4 Relation to other deliverables of the study ..................................................................... 10
2 eID beyond eIDAS .............................................................................................................. 11
2.1 eID Building Block: A solution for cross-border identification ......................................... 11

2.2 The UUM&DS project ..................................................................................................... 11
2.3 Banking and educational needs ..................................................................................... 12
2.3.1 National level ........................................................................................................... 12

2.3.2 Cross-border ............................................................................................................ 12
3 Understanding eID Interoperability .................................................................................. 14
3.1 eIDAS Technical Specifications...................................................................................... 15
3.1.3 Interoperability Architecture ..................................................................................... 15

3.1.4 SAML Attribute Profile ............................................................................................. 16
3.1.5 Message Format...................................................................................................... 17
3.1.6 Crypto Requirements............................................................................................... 18
4 Gap Analysis to accommodate sector-specific needs ................................................... 19
4.1 Non-notified Identity Providers ....................................................................................... 19
4.1.1 Non-acceptance of non-notified Identity Providers ................................................. 20

4.1.2 Acceptance of non-notified Identity Providers ......................................................... 22
4.1.3 Multiple cross-border authentication services ......................................................... 24
4.1.4 One node for all Identity Providers .......................................................................... 26
4.1.5 Technical Specifications constraints ....................................................................... 27
4.1.6 Levels of Assurance ................................................................................................ 29
4.2 Sector-specific attributes ................................................................................................ 31
4.2.1 Educational and Banking Attributes ........................................................................ 32

4.2.2 Cross-sector attributes ............................................................................................ 33
4.2.3 Quality of attributes .................................................................................................. 34
4.3 National IT infrastructure considerations ........................................................................ 35
4.3.1 Attribute Providers ................................................................................................... 35

4.3.2 Service Providers .................................................................................................... 37
4.4 Summary of the impact on eIDAS Technical Specifications .......................................... 38

4.5 Expert recommendations ................................................................................................ 38
5 Supporting adoption at national level .............................................................................. 41
5.1 Out-of-the-box eIDAS ..................................................................................................... 41

5.2 Overcoming challenges at national level ........................................................................ 42
5.2.3 Additional components ............................................................................................ 45
3/69
5.3 National eID landscapes ................................................................................................. 47
5.3.4 Integration scenarios ............................................................................................... 54
5.4 Implementation steps ..................................................................................................... 65

5.5 Adoption remarks ........................................................................................................... 66
6 Afterword ............................................................................................................................ 67
7 Bibliography ....................................................................................................................... 68
Annex I: Acronyms .................................................................................................................... 69
4/69
List of Figures
Figure 1: Notified vs non-notified IdPs ........................................................................................ 21

Figure 2: Acceptance of non-notified IdPs by Service Providers ................................................ 23
Figure 3: Routing implications for non-merged nodes ................................................................ 24
Figure 4: Use of merged nodes for all types of Identity Providers and domains ........................ 26
Figure 5: Technical constraints imposed by eIDAS Regulation .................................................. 28
Figure 6: Non-comparable Levels of Assurance between notified and non-notified IdPs .......... 30
Figure 7: Examples of Attribute Provider types in the analysed domains ................................... 36
Figure 8: AS IS dataflow .............................................................................................................. 42
Figure 9: TO BE dataflow ............................................................................................................ 44
Figure 10: SP Adaptor ................................................................................................................. 46
Figure 11: AP Adaptor ................................................................................................................. 46
Figure 12: National infrastructure conceptual view ..................................................................... 47
Figure 13: Member States’ infrastructure landscapes................................................................. 48
Figure 14: MS Type 1 .................................................................................................................. 49
Figure 15: MS Type 2 .................................................................................................................. 50
Figure 16: MS Type 3 .................................................................................................................. 51
Figure 17: MS Type 4 .................................................................................................................. 52
Figure 18: MS Type 5 .................................................................................................................. 52
Figure 19: MS Type 6 .................................................................................................................. 53
Figure 20: Most probable MS landscapes ................................................................................... 54
Figure 21: Service Provider integration for MS Type 1 ............................................................... 55
Figure 22: Attribute Provider integration for MS Type 1 .............................................................. 57
5/69
List of Tables
Table 1: Document structure ......................................................................................................... 9

Table 2: Comparison of SP integration scenarios for MS type 1 ................................................ 56
Table 3: Comparison of AP integration scenarios for MS type 1 ................................................ 57
Table 8: Acronyms ...................................................................................................................... 69
6/69
1 INTRODUCTION
1.1 CONTEXT
EU Regulation no. 910/2014 on electronic identification and trust services for electronic
transactions in the internal market (known as ‘eIDAS Regulation’) was adopted by the EU co-
legislators on 23 July 2014. This Regulation aims at fostering cross-border interoperability of
national electronic identification schemes (eIDs) in order to facilitate the access by citizens and
businesses to public services in the different Member States where such access is enabled
through eID authentication.
To support Member States in the implementation of the eIDAS Regulation, the European
Commission is providing the CEF eID Building Block, a set of services (including software,
documentation, training and support) which help public administrations and private Service
Providers extend the use of their online services to citizens from other European countries. In that
sense, many Member States are using the reference implementation of the eIDAS Technical
Specifications, provided by CEF eID, to deploy their eIDAS interoperability nodes.
The CEF eID Building Block has been also used by the project funded by DG TAXUD on Unified
User Management and Digital Signatures (UUM&DS) in the field of customs. This project aimed
at creating a uniform system for the authentication and authorisation management and verification
of EU Customs Economic Operators’ users and EU Customs’ officials to access EU Customs IT
Services, while supporting different authentication schemes. The relationships between CEF eID
and UUM&DS are discussed in detail in section 2.2 of this document.
In order to avoid fragmentation in the cross-border exchange of identification and authentication

information and access to online services through the emergence of parallel networks in different
domains, the European Commission has requested everis to analyse in-depth the limitations of
the current CEF eID Building Block and to propose adaptations required of it in order to expand
its usability by a wider range of sectors, including the private sector.
This document is structured in three parts. The first part describes the eID Building Block and its
initial goal —namely to facilitate the cross-border access of online public services in the EU— as
well as the limitations of this system in view of the varying needs and specificities of different
economic sectors or domains. Two sectors (education and banking) were taken as pilots and
analysed in-depth in the research phase leading up to this document to identify a sample of
additional needs.
The second part focuses on the eIDAS Technical Specifications that underpin the functioning of
the CEF eID and discusses the changes that should be considered for implementation to increase
the usability of this Building Block by the private sector, considering the identified domain-specific
needs. A gap analysis is carried out in order to single out the different challenges and propose
solutions to tackle them. At the time of writing this document the last version of the eIDAS
Technical Specifications available was the version 1.1. This is the version that has been taken
into account to undertake the analysis. However, it should be noted that the technical subgroup
7/69
of the eIDAS Cooperation Network 1 responsible for updating the eIDAS Technical Specifications
is currently working on an updated version that may already address some of the challenges
identified in this document.
The third part of the document analyses common IT landscapes in Member States and
formulates, on the basis of those, recommendations for integration with the proposed extended
eIDAS network. The selection of IT landscapes was made on the basis of expert assumptions by
everis’ research team and of feedback provided by the European Commission. As part of the
stakeholder engagement activities of the project, everis’ team presented a draft of this document
to eID experts from Member States who are members of the technical subgroup of the eIDAS
Cooperation Network. Though these outreach activities valuable input was collected that served
to fine-tune and/or reinforce some of the research conclusions.
This document targets a technical audience that is already familiar with the CEF eID Building
Block. On the one hand, it is addressed at DG DIGIT officials working on the eID Building Block,
as well as at the members of the eIDAS technical subgroup. On the other hand, the document
targets IT architects in the Member States involved in the integration with eIDAS.
1.2 OBJECTIVES
The overall objective of this document is to support a further development and usability of the
eIDAS ecosystem by enabling cross-border interoperability in the context of electronic
identification when providing and consuming both public and private online services.
More specifically, this general objective can be broken down into the following sub-objectives:
- First, to identify the limitations of the CEF eID Building Block and the eIDAS Network
as it is, in view of the needs of different domains and of the private sector
- Second, to advance recommendations to the eIDAS technical subgroup on the
changes that should be implemented to the eIDAS Technical Specifications in order to
accommodate these needs and expand the usability of the Network
- Thirdly, to provide Member States with guidelines on how to organise the eIDAS actors
at the national level
The authors of this document have worked under two main principles for the analysis that follows:
1) An extended eID Building Block solution should imply the least possible impact on IT
national infrastructures
2) The eIDAS-Nodes are intended to be used only for cross-border authentication
The scope of this deliverable is to document the outcome of the work performed under phase 3
of the project: Blueprint.
1
For more information about this Cooperation Network see:
https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Cooperation+Network+Resources
8/69
1.3 STRUCTURE OF THIS DOCUMENT
The table below describes the structure of the document:
Chapter Content
Introduction This chapter explains the context, objectives and structure of the
document and the relation of this report with other deliverables of the
project.
eID beyond eIDAS This chapter includes a brief explanation of how the eID Building Block
and the eIDAS Network were originally conceived as a general-purpose
identification and authentication mechanism, and how bringing the
different domains to the eIDAS ecosystem implies new considerations.
Understanding eID This chapter offers a summary of the four artefacts or documents that
Interoperability make up the eIDAS Technical Specifications, i.e. eIDAS Interoperability
Architecture, eIDAS SAML Attribute Profile, eIDAS Message Format and
eIDAS - Crypto Requirements for the eIDAS Interoperability Framework.
Gap Analysis to Based on the analysis done in the banking and educational domains (and
accommodate the UUMDS project), the most relevant challenges faced by the eIDAS
sector-specific Technical Specifications are described, assessed and accompanied by a
needs proposed solution and a series of recommendations. Three types of
challenges have been identified: (i) Derived from the co-existence of non-
notified Identity Providers, (ii) Derived from domain-specific attributes,
and (iii) Related to national IT infrastructure considerations (out of the
scope of the eIDAS Technical Specifications).
Additionally, this chapter includes a summary of the impact of these
challenges on eIDAS Technical Specifications and advances a set of
expert recommendations.
Supporting This chapter provides an outlook beyond the eIDAS Network scope,
adoption at namely looking at scenarios for integration of the proposed solution at the
national level Member State level. The proposed recommendations—albeit technical —
are expressed in the form of high-level supporting information that targets
architects in the Member States involved in decision making regarding
eID and eIDAS.
Annex I List of acronyms used in the document.
Bibliography Bibliography.
Table 1: Document structure
9/69
1.4 RELATION TO OTHER DELIVERABLES OF THE STUDY
Two of the main inputs for the work reflected in this document are the deliverables produced in
the previous phase of the project: the design phase (D04 Architectural Solution Document
(eBanking) with recommendations and D05 Architectural Solution Document (eStudent) with
recommendations). These two deliverables describe a possible framework for the exchange of
personal data in an electronic format in the banking and educational domains using the CEF eID
Building Block, which allows for cross-border access to online services using eID.
These documents include for each domain: (i) the main conclusions from the interviews
conducted with key stakeholders to understand in-depth the domain and the relevant
requirements, (ii) a detailed description of the use cases identified, (iii) a thorough identification
of functional and non-functional requirements, (iv) the identification of the architecture principles
and constraints applicable, and (v) a detailed description of the architecture artefacts used to
describe the proposed solution.
These two documents are to be understood as domain-coupled technical resources that do not
intend to impose a solution. They intend to serve as a reference (or inspiration) for profiles in the
Member States that are in the position to take architectural and organisational decisions at the
national level to help the country benefit from the use of eIDAS in the banking and/or educational
domains.
Likewise, within the scope of the current phase of the project, the deliverable D07—User stories
for eBanking and eStudent—has been produced. This deliverable describes in a visual way the
steps that a user needs to take and the applicable processes in order to access a particular
service in each domain: a student mobility service within the educational domain and customer
on-boarding services within the banking domain. The aim of the user story is to showcase the
benefits that eIDAS and an extension of eIDAS would bring to the analysed domains by
highlighting the steps and processes that would be streamlined and/or removed thanks to the use
of cross-border electronic identification.
10/69
2 EID BEYOND EIDAS
2.1 EID BUILDING BLOCK: A SOLUTION FOR CROSS-BORDER

IDENTIFICATION
The eID Building Block was essentially conceived to facilitate the cross-border access to public
and private services made available online by citizens and businesses. Indeed, the underpinning
Regulation (eIDAS Regulation) and its implementing acts state that by 29 September 2018 all
online public services requiring electronic identification must, under certain conditions, be able to
accept the notified eID schemes of other EU countries. Additionally, the eIDAS Regulation also
requests Member States to encourage the private sector to voluntarily use these notified eID
schemes when needed for accessing online services or making electronic transactions. ‘Notified
eID schemes’ is understood as the electronic identification means used at national level that have
been reported and documented by Member States to the European Commission, following a
specific procedure, and which are publicly available at a list published in the Official Journal of
the European Union. It should be noted that Member States are not legally obligated to notify their
eID scheme(s). However, this procedure is necessary if they want to guarantee the recognition of
their eID scheme by other Member States, as notification ensures that eID schemes connected
to the eIDAS Network satisfy the quality and security conditions set out by the eIDAS Regulation.
To sum up, the eIDAS Regulation establishes the mandatory mutual recognition of eID means by
EU public entities when offering access to their online services, provided that the following
conditions are met2:
i) the particular electronic identification means has been notified to the European
Commission following the established procedure
ii) the assurance level of the electronic identification means is equal to ‘substantial’ or
‘high’
iii) the assurance level of the electronic identification means is equal or higher than the
assurance level of the national identification means accepted by the online service.
2.2 THE UUM&DS PROJECT
The Unified User Management and Digital Signatures (UUM&DS) [1] was a project launched in
2012 under the leadership of DG TAXUD. This project aimed at creating a uniform system for the
authentication and authorisation management and verification of EU Customs Economic
Operators’ users and EU Customs’ officials to access EU Customs IT Services, which could
support different authentication schemes.
The UUM&DS project started well before the eIDAS Regulation was approved and it was
developed on the basis of its own sectorial legal framework —the Union Customs Code. However,
although the eIDAS Network was not yet in place at that time (and it is not fully operational at the
time of writing), the project considered relying on the future network of eIDAS nodes to integrate
the national authentication infrastructures with the UUM&DS system.
2
See Article 6 of the eIDAS Regulation.
11/69
The project showed that together with a minimum personal dataset required to authenticate a
user, a set of domain-specific attributes (in that case in the area of customs) were needed to grant
access to that user to a particular application. This realisation is aligned with the approach
adopted in the eIDAS Interoperability Framework, which foresees extending the eIDAS minimum
dataset and enriching it with sector-specific attributes for a better usability of the eID Building
Block by a wider range of stakeholders, making it more attractive to the private sector in particular.
2.3 BANKING AND EDUCATIONAL NEEDS
Under the framework of this project, two sectors have been analysed in-depth in order to gather
additional insights on domain-specific requirements that should be factored into the eID Building
Block in order to make its usability more meaningful and relevant for a wide range of sectors. The
two sectors that have been examined are the Educational domain (in particular the tertiary
education level) and the Banking domain. The domain-specific attributes identified that would be
valuable for these sectors should not be understood as prescriptive requirements to be
exchanged through the eIDAS Network. They should rather serve to highlight the importance of
enabling the exchange of domain-specific attributes for the provision of certain online services.
The methodology used can hopefully also serve as an inspiration on how to select similar types
of attributes in new domains.
2.3.1 National level
In the framework of our study, HEIs and banks from several Member States in the EEA were
interviewed with a two-fold purpose: (i) to get a better understanding of the current usage of
electronic identification in the educational and banking domains, and (ii) to collect input about
their needs for granting access to their online services to students and customers, respectively.
HEIs provide a wide range of online services to their students: from online access to learning
materials and online libraries, access to academic records, online enrolment services, access to
free Wi-Fi, access to campus and cafeteria, etc. Several of these services have been analysed
and considered as part of this study.
Banks also offer online access to most of their services to their customers. However, in contrast
with HEIs, banks work in a highly risky and heavily regulated environment. Additionally, banks
spend a lot of effort to protect the confidentiality and the integrity of their services. This study
focuses on a particular use case within the banking domain, namely online customer on-boarding,
through which a natural (or a legal) person becomes the customer of a bank.
2.3.2 Cross-border
HEIs provide a number of online services for students of other HEIs from other countries. The
most popular services are free Wi-Fi, mobility of students in the framework of the Erasmus+
program, online courses and access to online libraries, and participation in collaborative academic
research.
12/69
In order to do this, HEIs have built federation networks with federated Identity Provider services
to authenticate students from other HEIs (i.e. the most popular of such networks is eduGAIN3).
HEIs have also developed a set of web services to foster the cross-border exchange of data as
part of EU-supported projects such as EWP, EMREX and the European Student Card. In these
projects HEIs, have agreed on a set of policies and standards to ensure the interoperability of
datasets exchanged.
Banks also provide cross-border online services. However, heavy regulation in the banking
domain, on the one hand, and on the other hand the lack of a legal obligation under the eIDAS
Regulation for the mutual recognition of cross-border identification means applied to the private
sector hinder the ability of banks to provide cross-border online customer on-boarding services
widely.
3
https://edugain.org/
13/69
3 UNDERSTANDING EID INTEROPERABILITY
The eIDAS ecosystem encompasses several actors, including Identity Providers, Service
Providers, Attribute Providers, Node operators, as well as components (the eIDAS nodes).
However, the ‘eIDAS network’ only refers to a set of eIDAS Nodes implemented and operated at
the MS level.
The eIDAS network provides authentication services to SPs and allows the exchange of personal
attributes for natural persons and legal entities in a safe manner. The specific set of personal
attributes is defined in the Annex of the eIDAS Interoperability Framework implementing act4. This
basic set of personal identification data is also referred to as the ‘eIDAS Minimum Dataset’ (eIDAS
MDS), and it uniquely represents a natural person or a legal entity. This basic set of attributes
(i.e. Family Name, First Name, Gender, Birth date, etc. for a natural person; and Tax Reference
Number, Economic Operator Registration and Identification number, etc. for a legal person) are
meant to be enough for public administrations to uniquely identify a natural or legal person and
therefore to provide an authorised access to a particular online service (e.g. online tax application,
business registration, etc.).
When a user from another Member State requests access to an online service, the Service
Provider sends the authentication request (with the list of required attributes) to the eIDAS node
of the Service Provider's MS (receiving MS), either directly or through an authentication gateway
or proxy. This node creates and sends the corresponding eIDAS request to another eIDAS node
in the user's country (sending MS). The eIDAS node in the user's country re-directs the
authentication request to the corresponding Identity Provider. The Identity Provider authenticates
the user and returns their identification data in accordance with the eIDAS MDS. All these
attributes are returned to the Service Provider in the receiving MS through the eIDAS network.
The SP then grants authorised access to the online service to that user.
The exchange of messages between eIDAS nodes is performed via web browser, and the use of
TLS and SAML 2.0 protocols has been agreed to ensure the cryptographic protection of these
exchanges. The eIDAS Technical Specifications define the format of these messages, including
the personal and technical attributes.
The eIDAS Technical Specifications define and describe the communications exclusively
between the eIDAS nodes. MSs remain fully responsible for the integration of all other relevant
systems/actors at the national level with the eIDAS ecosystem (Service Providers, Identity
Providers, Attribute Providers, etc.). This means that the messages exchanged outside the eIDAS
nodes (for instance, between Service Providers and eIDAS nodes, or between eIDAS nodes and
Identity Providers) do not necessarily have to use the eIDAS SAML 2.0 protocol.
4
Commission implementing Regulation (EU) 2015/1501 of 8 September 2015 on the interoperability framework pursuant to Article 12(8)
of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for
electronic transactions in the internal market, L235/1, available at:
https://ec.europa.eu/futurium/en/system/files/ged/celex_32015r1501_en_txt.pdf
14/69
3.1 EIDAS TECHNICAL SPECIFICATIONS
The eIDAS Network implementation follows the principles defined in the different layers of the
European Interoperability Framework. Both the eIDAS Regulation and the eIDAS interoperability
framework ensure the legal interoperability layer, while the eIDAS Technical Specifications
support the operational, semantic and technical interoperability layers. Hence, the eIDAS
Technical Specifications are the most salient element that ensure cross-border interoperability.
The eIDAS Technical Specifications consist of four separate documents that specify the main
interoperability aspects of the eIDAS network:
 eIDAS Interoperability Architecture
 eIDAS SAML Attribute Profile
 eIDAS Message Format
 eIDAS - Crypto Requirements for the eIDAS Interoperability Framework
The eIDAS Technical Specifications ensure interoperability in spite of the wide variety of MS eID
schemes: “Interoperability between different eID-schemes is achieved via defining the technical
interfaces between eIDAS-Connectors and eIDAS-Services, collectively eIDAS-Nodes.” [eIDAS
Interoperability Architecture].
The following sections briefly summarise the main ideas and concepts included in the documents
that have just been referred to.
3.1.3 Interoperability Architecture
The current version 1.0 of eIDAS Interoperability Architecture document was created in November
2015. This document is aimed at defining the eIDAS network architecture.
The first chapter of the document provides a description of the main architecture requirements
(i.e. confidentiality, integrity, secure identification and authorisation, robustness) that should be
fulfilled to archive interoperability. It also includes definitions of terms that are used in other
documents (e.g., sending MS, receiving MS, eIDAS node, Middleware, etc.).
The following chapters, 2 and 3, describe the different components of the eIDAS network, the
interfaces between them, and the protocols that must be used. For example:
- An eIDAS node embodies two roles: the eIDAS Connector and the eIDAS Service
- The eIDAS Connector provides an interface to a Relying Party in the receiving MS to
request an authentication of a user
- The eIDAS Service has an interface with the national eID scheme(s) in the sending
MS
These chapters also provide a description of two possible operational scenarios: Proxy-based
and Middleware-based. The proxy-based scenario (eIDAS-Proxy-Service) means that the
sending MS operates the eIDAS service, whereas in the middleware scenario (eIDAS-
Middleware-Service) the sending MS provides a piece of software that is installed and operated
by the receiving MS.
15/69
The interface between the eIDAS Connector and eIDAS Service shall use SAML (Security
Assertion Markup Language) and TLS (Transport Layer Security) for all communications. The
interfaces between the eIDAS node and the Relying Party, and between the eIDAS node and the
eID schemes are out of scope of the eIDAS Technical Specifications.
All eIDAS nodes shall support HTTP Redirect binding and http POST binding for transmitting
SAML request messages. However, using HTTP redirect binding is recommended to reduce
latency if the authentication request size is small enough. The response messages shall be
transmitted with usage of http POST binding.
Before SAML request processing, the eIDAS Service shall verify the signature certificate of the
eIDAS Connector Service. The response must likewise be signed by the eIDAS Service and the
signature certificate should be verified by the eIDAS Connector. Cryptographic requirements are
defined in eIDAS —Crypto Requirements for the eIDAS Interoperability Framework document.
Additionally, SAML Assertion may be signed. These measures enable ensuring authenticity and
data exchange security.
Chapter 4 defines the capability of the eIDAS Connector to provide a user interface to allow the
user to select the MS where they wish to authenticate in the event that the MS was not pre-
selected in the request from the relying party.
Chapters 5,6,7,8 describe the process flow for person authentication, the principles for certificates
and metadata exchange, as well as the operational and security requirements. All of these provide
an uninterrupted chain of responsibility for cross-border exchange of personal identification data.
3.1.4 SAML Attribute Profile
The last version of the eIDAS SAML Attribute Profile document was created on October 2016.
The document mainly describes the mandatory and optional attributes of natural and legal
persons. This list of attributes is known as the ‘eIDAS Minimum Dataset’ (eIDAS MDS).
The document provides guidance on how to use Uniform Resource Identifiers (URIs) for naming
personal attributes to control namespace and ensure that there are no misinterpretations and
communication failures. Consistent attribute naming delivers personal data of users in a way that
can be mutually understood between eIDAS nodes.
The first part of the document contains the attribute schemes for natural persons and provides a
description of their attributes, including values, data types, and mapping of these attributes with
other vocabularies (eIDAS MDS and ISA Core Vocabulary). The second part of the document
contains the same information for legal persons. Both parts provide examples of XML snippets
for all attributes. However, it is noted that ISA Core Vocabulary does not provide structured data
types to create SAML messages for legal persons.
16/69
It also describes how to handle the unique identifier of a person considering that “the Unique
Identifier presented for a particular person may change over time, e.g. where the user’s digital
identity is replaced or repaired”5.
Regarding sector-specific attributes, the document foresees their possible inclusion in the
Member State’s eIDAS Node metadata. Developing separate XML scheme(s) to describe the
type and usage of such attributes is proposed.
At the end of the document there is a description of the approach to implement a representation
scenario (i.e. where a person represents or acts on behalf of another person). Representational
attributes must not be explicitly requested in the eIDAS authentication request. The eIDAS
Service may, however, return a representational attribute set if such a representation exists. In
this case, the prefix “Representative” shall be added to the attribute’s name element.
3.1.5 Message Format
The last version of eIDAS SAML Message Format at the time of writing is 1.1. The document aims
to provide a description of the message format to be exchanged between eIDAS Nodes. The
SAML 2.0 has been agreed by the eIDAS technical subgroup as the format to use for message
exchange.
From the SAML protocol point of view, the eIDAS Service is a SAML Identity Provider and the
eIDAS Connector is a SAML Service Provider. The description of the message format includes
information about the business and technical attributes that are mandatory and those that are
optional.
The document starts with the SAML Metadata description for the eIDAS Connector and the eIDAS
Service. It then provides attribute definitions of specific message format elements. The eIDAS
Service must support all mandatory attributes and should support the optional attributes defined
in the eIDAS Minimum Dataset. Attributes beyond the eIDAS Minimum Dataset may be supported
and may require a bilateral agreement between the eIDAS-Connector and the eIDAS-Service.
Chapter 6 of the document includes examples of following messages:
 eIDAS Connector SAML-Metadata

 eIDAS Service SAML Metadata
 SAML Authentication Request
 SAML Authentication Response
Finally, Appendix A provides a definition of the Metadata Aggregator message that aims to
provide a consolidated list of the different metadata locations across Member States.
5
eIDAS SAML Attribute Profile, eIDAS Technical Sub-group, 28 October 2016, available at:
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+Profile?preview=/46992719/47190132/eIDAS%20SAML%20Attribute%2
0Profile%20v1.1_2.pdf
17/69
3.1.6 Crypto Requirements
The version in use at the time of writing is 1.0 and it was created in November 2016. The
document contains the specifications of cryptographic requirements for the protection of
communication between eIDAS nodes (i.e., eIDAS-Services and eIDAS-Connectors). The
communication is performed via the user’s browser and the security of the communication is
ensured on both content layer and transport layer.
To secure the communication on transport layer, TLS 1.2 must be used if it is supported by the
user’s browser. Alternatively, TLS 1.1 may be used. Using a previous version of TLS is not
allowed. The document also provides a list of recommended and accepted ciphers for the TLS
handshake and specifies that the eIDAS nodes must use qualified TLS certificates.
The second part of document provides the security requirements for SAML messages and gives
information about the ciphers that must be used for content encryption. SAML uses XML
Encryption and XML Signatures based on authentication via X.509 certificates.
Regarding XML encryption and signature, SHA-2 hash function must be supported. The hybrid
crypto system is used. The content must be encrypted via symmetric cryptography using a
randomly generated symmetric session key for each transmission. A static public key of the
receiver (X.509 certificate) must be used to encrypt the session key. Therefore, X.509 certificates
are used for protecting SAML messages. However, for encryption and signature, different
certificates containing different keys shall be used.
18/69
4 GAP ANALYSIS TO ACCOMMODATE SECTOR-
SPECIFIC NEEDS
The fact that the eIDAS Regulation does not stipulate legal obligations for the private sector poses
some challenges when trying to accommodate private sector specificities to the eIDAS Technical
Specifications. This section develops the most relevant challenges that have been identified so
far in this regard. These are classified into three groups: the challenges linked to the use of non-
notified Identity Providers, the challenges related to the need for sector-specific attributes, and
the challenges posed by the myriad of national IT landscapes. Each challenge includes a short
description, an analysis of the current version of the eIDAS Technical Specifications from the
perspective of the challenge, everis’ expert assessment based on the analysis made, a proposed
solution, and recommendations on how to overcome the issue.
The following list summarises the challenges that are analysed below in this document:
- Related to the use of non-notified Identity Providers:

o Non-acceptance of non-notified Identity Providers
o Acceptance of non-notified Identity Providers
o Multiple cross-border authentication services
o One node for all IdPs (merged)
o Technical specifications constraints regarding eIDAS MDS
o Levels of Assurance (LoA)
- Related to the need for sector-specific attributes:
o Domain-specific attributes
o Cross-sectorial attributes
o Quality of attributes
- Related to MS infrastructure (out of the scope of eIDAS Technical Specifications)
o Attribute Providers
o Service Providers
The principle of minimum impact on the existing eIDAS Technical Specifications and on the eIDAS
Network has been applied for each proposed solution and recommendation.
4.1 NON-NOTIFIED IDENTITY PROVIDERS
As mentioned above, non-notified Identity Providers 6 are already used for cross-border user
authentication in some specific domains, such as in customs and taxation. This phenomenon
could potentially lead to a proliferation of cross-border networks authenticating users in different
domains in parallel to the eIDAS network. While this is not per se a bad option, it would be more
efficient to connect these Identity Providers to the eIDAS network, so that they could benefit from
the interoperability framework and the technical infrastructure implementing eIDAS. In fact, it may
be the case that some non-notified Identity Providers are already connected to the eIDAS
network. This may occur when the connection of the eIDAS node to the Identity Provider is not
done directly, but through an authentication gateway.
6
In the document, ‘non-notified Identity Provider’ is to be understood as an Identity Provider that is not part of a notified eID scheme.
Conversely, a ‘notified Identity Provider’ is to be understood as an Identity Provider that is part of a notified eID scheme.
19/69
From the networks’ standpoint, there are four main possible scenarios for the intersection of
cross-border federated networks that are described below. One of these networks is the eIDAS
network. Other networks could be implemented in parallel to the eIDAS network in the scope of
specific business domains and regulations. These networks could also use SAML for
communication between nodes.
1. The Receiving MS has one node (Connector) that intervenes in two (or more) networks
and the Sending MS has one node (Service) that provides authentication services for
these two (or more) networks. In this scenario all notified and non-notified Identity
Providers are connected to one node and are accessible for Service Providers in the
Receiving MS through that node. The challenges described in sections 4.1.1, 4.1.2, 4.1.4-
4.1.6 are applicable to this scenario.
2. The Receiving MS has two (or more) nodes (Connectors) that take part in two (or more)
networks, while the Sending MS has one node (Service) that provides authentication
services for these two (or more) networks. The eIDAS Technical Specifications allow the
Sending MS to have as many Connectors as the MS needs. Consequently, the non-
eIDAS nodes of the Receiving MS could be included in the eIDAS network without any
modification of the eIDAS Technical Specifications. As in the previous scenario, the
challenges described in sections 4.1.1, 4.1.2, 4.1.4-4.1.6 are applicable to this scenario.
3. The Receiving MS has one node (Connector) that takes part in two (or more) networks,
while the Sending MS has two or more separate nodes (Services) for these networks. In
such scenario, both notified and non-notified Identity Providers are usually connected
with different nodes. The challenges described in sections 4.1.1 - 4.1.3, 4.1.5, 4.1.6 are
applicable to this scenario.
4. Lastly, the Receiving MS has two (or more) nodes (Connectors) that take part in two (or
more) networks, while the Sending MS has two or more nodes (Services) for these
networks. As mentioned above, the nodes of Receiving MS could be included in the
eIDAS network without any modification of the eIDAS Technical Specifications. The
challenges described in sections 4.1.1 - 4.1.3, 4.1.5, 4.1.6 are applicable to this scenario.
4.1.1 Non-acceptance of non-notified Identity Providers
Description of the challenge

Member States and/or Service Providers may decide not to accept non-notified Identity Providers
as there is no legal obligation for them to do so. In this case, the authentication request is expected
to be processed only by notified Identity Providers, and should not be routed to non-notified
Identity Providers that could be connected to the eIDAS network. The implication of this decision
at the business level is that these Member States and/or Service Providers would be limiting the
access to their online services to citizens and businesses that use authentication means issued
by notified Identity Providers only. On the technical level, it implies that the receiving MS would
need to tag authentication requests to indicate that only notified Identity Providers are accepted.
20/69
Figure 1: Notified vs non-notified IdPs
Analysis of the Technical Specifications regarding this challenge

The current version of the eIDAS Technical Specifications does not have a mechanism to
distinguish between notified and non-notified Identity Providers.7 Moreover, the eIDAS Technical
Specifications only support interoperability between notified Identity Providers, and the
authentication response does not contain any information about the type of Identity Provider which
provides the identification data of the user.
Assessment
The eIDAS network should enable distinguishing between requests sent to non-notified Identity
Providers and requests sent to notified eID schemes. A way to go about this could be to include
a new attribute(s) to the authentication request that would provide information about acceptance
or non-acceptance of non-notified Identity Providers. The authentication response could also
contain information about the type of Identity Provider that would authenticate a particular user.
Overcoming the challenge

A possible solution could be to add a new attribute (e.g. nonNotifiedIdP) in the two generated
messages: the authentication request and the authentication response. The following snippet of
XML shows an example for the definition of such an attribute:
<xs:attribute name="nonNotifiedIdP" type="boolean" use="optional"/>
In the authentication request, the value of this attribute could be "false" to indicate that only
notified Identity Providers are accepted to authenticate users. In the authentication response,
nonNotifiedIdP="true" would mean that the identification data has been provided by a non-
7
As mentioned in the introduction, this document has been produced taking into account the last version of the eIDAS Technical
Specifications available at the time of writing (i.e. v.1.1). However, based on the information shared with everis by eID experts from the
Member States, the distinction between and the acceptance of both notified and non-notified Identity Providers is already foreseen in the
upcoming updated version of the Technical Specifications.
21/69
notified Identity Provider, while nonNotifiedIdP="false" would mean that identification data
has been provided by a notified Identity Provider.
Additionally, a new validation step could be included in the authentication response for the
attribute ‘nonNotifiedIdP’ to ensure that the response matches the actual request. In case of
a mismatch (i.e., the authentication request should have been processed by a notified Identity
Provider, but the authentication response is provided by a non-notified Identity Provider), the
authentication could be aborted with an error message stating “Identity Provider type mismatch”.
It should be noted that these changes to the Technical Specifications have an interdependency
with the next challenge described in section 4.1.2 “Acceptance of non-notified Identity Providers”.
To reflect the proposed changes, updating the following documents is recommended:
- “eIDAS – Interoperability Architecture” (section 4, 5)

- “eIDAS SAML Message Format” (section 2.4.1, 2.4.2, a new attribute definition should be
added in section 3, examples of messages in section 6).
Recommendation
In order to minimise changes and ensure backwards compatibility, the absence of the
nonNotifiedIdP attribute in the authentication request could be allowed and interpreted by
default as “only notified Identity Providers are accepted”. In the authentication response, the
absence of this attribute would mean that the user has been authenticated by a notified Identity
Provider.
4.1.2 Acceptance of non-notified Identity Providers

In this scenario both notified and non-notified Identity Providers are accepted. According to the
eIDAS Regulation, the mutual acceptance of notified eID schemes remains mandatory for public
services. Additionally, Member States and/or Service Providers may decide to also accept non-
notified Identity Providers for granting access to certain services. As a result, some authentication
requests could be routed to both notified and non-notified Identity Providers, and all other
authentication requests would be routed to notified Identity Providers only.
22/69
Figure 2: Acceptance of non-notified IdPs by Service Providers

The challenge is the same as the previous one. The current version of the eIDAS Technical
Specifications does not distinguish between types of Identity Providers (i.e. notified and non-
notified).8
Assessment
The eIDAS network should distinguish between authentication requests sent to non-notified
Identity Providers and requests sent to notified Identity Providers. However, it is possible that a
particular service accepts both types of Identity Providers, as mentioned above. The challenge in
this case relates to the hierarchical LoA defined in the eIDAS Regulation for notified Identity
Providers (i.e. high, substantial and low), versus the lack of a definition of LoA for non-notified
Identity Providers. More information about this particular challenge can be found in a section 4.1.7
below.

The proposed solution is similar to the previous one. The attribute defined in the previous section
could be added in the authentication request to indicate that non-notified Identity Providers are
accepted (e.g.nonNotifiedIdP="true"). In this case, the validation step to confirm that the
requested type of Identity Provider matches the one provided in the response could be skipped
because both notified and non-notified Identity Providers would be accepted.
Updating the following documents in order to reflect this change is advised:

- “eIDAS – Interoperability Architecture” (section 4, 5)
- “eIDAS SAML Message Format” (section 2.4.1, 2.4.2, new attribute definition should be
added in section 3 and 5, examples of messages in section 6).
8
See footnote n.7.
23/69
Recommendation
The recommendation is the same as in the previous case. In order to minimise changes and
ensure backwards compatibility, the absence of the nonNotifiedIdP attribute in the
authentication request could be interpreted as meaning that “only notified Identity Providers are
accepted”.
4.1.3 Multiple cross-border authentication services

Cross-border federations of identities could be deployed within the scope of specific business
domains or regulations in parallel to the eIDAS network. These federations could reuse the
technologies and protocols implemented in eIDAS. In some countries, these federations could
use non-notified Identity Providers, while in other countries they could use notified eID schemes.
This implies that the Identity Provider of a notified eID scheme could potentially belong to multiple
networks simultaneously. This scenario underpins a situation where some MS may decide to
connect all networks using a single node, while others may opt for separate nodes specific for
each network. This section analyses the challenge where the Sending MS has more than one
node for several networks (see section 4.1.4 for more details about the merged node option). The
following figure shows a situation where in addition to the eIDAS network a parallel network
provides similar cross-border authentication services in a given MS.
Figure 3: Routing implications for non-merged nodes

A node in a Receiving MS that lies at the intersection of several networks must have the capability
of issuing requests to all Identity Providers connected to it. This implies that it must have a way
to select the proper target network or, in other words, the right node in the Sending MS. This is
not currently foreseen in the eIDAS Technical Specifications, which do not envisage that a
Sending MS could operate several eIDAS Service nodes. There can only be one eIDAS Service
(either a Proxy service or a Middleware service).
24/69
The reverse scenario is not problematic because a Receiving MS can operate multiple eIDAS
Connectors based on the current version of the eIDAS Technical Specifications. An inclusion of
new eIDAS Connectors is feasible and would not require any changes to the Technical
Specifications.
Assessment
The proposed solution consists of amending the eIDAS Technical Specifications in order to allow
a Sending MS to operate several Service nodes. For instance, one eIDAS Service node could be
used to connect notified Identity Providers to the eIDAS network, and another one to connect non-
notified Identity Providers. To give another example, one eIDAS Service node could be used for
the public domain with notified Identity Providers, another node for the customs and taxation
domain, and another one for the health domain, etc.
In order to do this, a routing system defining how to send authentication requests to the relevant
eIDAS Service node is needed. This routing should enable the eIDAS Connector of the Receiving
MS to re-direct to the right eIDAS Service node in the selected Sending MS. For this to happen,
the eIDAS Connector could analyse the content of the request and route it to the node capable
of fulfilling the request. Existing attributes could be used or new attributes could be added to the
authentication request to route it to the corresponding node. Besides that, the information about
types of Identity Providers connected to the eIDAS Service nodes should be available to the
eIDAS Connector (in the same way as it is made available regarding the level of LoA or type of
dataset).

If there are only two nodes that separately manage notified and non-notified Identity Providers, it
is possible to reuse, for example, the nonNotifiedIdP attribute defined in section 4.1.1. In this
case, the receiving eIDAS node could read the nonNotifiedIdP from the authentication
request and route the request to the corresponding node. Furthermore, a new NodeType attribute
could be added to the description of EndpointType in order to make the information about the
eIDAS Service node type available to the eIDAS Connector (Appendix A of eIDAS Message
Format specification). The following snippets are provided as examples:
<xs:simpleType name=" NodeType">

<xs:restriction base="xs:string">
<xs:enumeration value="notified"/>
<xs:enumeration value="non-notified"/>
</xs:restriction>
</xs:simpleType>
However, if several nodes were connected to the eIDAS network, the attribute
nonNotifiedIdP would no longer be enough. Another element that would allow determining
the target node in the Sending MS would need to be added in the request. For example, the
element EintityID from Endpoint attribute of Metadata Location (it is the unique identifier of
the Node in the selected MS) could be added to the authentication request. In this case, the
receiving eIDAS node could get EintityID in the authentication request, find the corresponding
node in the Metadata Service List and route the request to that node. The open issue would then
be who and how would set up the MsEndpointType attribute in the authentication request. This
point is however out of scope of the eIDAS Technical Specifications. In line with the previous
25/69
example, the following XML snippet presents a proposed change in the MsEndpointType
definition:
<xs:complexType name=" MsEndpointType">
<xs:attribute name="EndpointType" type="xs:anyURI" use="required"/>
<xs:attribute name="EintityID" type="xs:anyURI" use="required"/>
<xs:attribute name="NodeType " type="xs:NodeTypeType" use="required"/>
</xs:complexType>
Recommendation
The existence of several eIDAS Service nodes with the purpose of managing different Identity
Providers in one MS can result in an unjustified higher complexity of the eIDAS network. Also, the
user would be limited to select an Identity Provider from a domain defined in the authentication
request. A number of negative side effects allow us to conclude that keeping one eIDAS Service
node as it is now is advisable. An example of a negative effect in the event of more than one
eIDAS Service node is that it would not be possible to send an authentication request to both
notified and non-notified Identity Providers simultaneously.
In the event that it is not possible to merge existing nodes in a MS, using a facade pattern to hide
existing nodes from the eIDAS network is advisable. The routing rules in the facade could be
based on the content of the requests in question. For example, if the request contains attributes
that are to be provided by a specific Identity Provider(s), this request should be routed to the node
to which these Identity Provider(s) are connected.
4.1.4 One node for all Identity Providers (merged)

An MS may also have only one node (one logical instance of the eIDAS Service) for managing
requests for all Identity Providers (notified and non-notified, domain-specific, etc.), as shown in
the figure below.
Figure 4: Use of merged nodes for all types of Identity Providers and domains
26/69
The eIDAS Technical Specifications foresee one logical instance of the eIDAS node (more
precisely, the eIDAS Service) for the sending MS. Besides, the interfaces between the eIDAS
node and Identity Providers are out of scope of the eIDAS Technical Specifications. It is up to the
sending MS to decide how to connect with the Identity Providers.
Assessment
All notified and non-notified Identity Providers are connected to one node. The user can use his
or her authentication means issued by any national Identity Provider connected to the node in
order to access services in the Receiving MS.
This challenge does not require any change to the eIDAS Technical Specifications. Except for the
ones that are recommended in sections 4.1.1, 4.1.2 and 4.1.5 for the integration of non-notified
Identity Providers to the eIDAS network. Moreover, the non-notified Identity Providers could
provide domain attributes beyond the eIDAS MDS. The recommendations on how to add domain-
specific attributes to the eIDAS SAML Attribute Profile are provided in section 4.2, taking the
banking and educational domains as examples.

N/A
Recommendation
We recommend having one authentication service (i.e., one eIDAS Service) per MS that could be
used for different specific business domains. This approach will support the simplicity of the
eIDAS network and the national IT infrastructure. However, verifying the possibility of using the
eIDAS Service to these business domains is recommended. The possibility of merging the nodes
at the technical level does not imply that the interoperability on the legal, organisational and
semantic levels has already been achieved.
4.1.5 Technical Specifications constraints – MDS

The eIDAS Regulation is not applicable to non-notified Identity Providers. This means that non-
notified Identity Providers are not obliged to provide the eIDAS MDS (eIDAS Minimum Dataset).
However, from a technical perspective, the eIDAS network does not allow transferring
authentication requests and responses when this set of attributes is incomplete. Therefore, the
MDS needs to be provided in any exchange done through eIDAS, even if (some of) the fields are
filled with inaccurate information or dummy values.
27/69
Figure 5: Technical constraints imposed by eIDAS Regulation

In order to rely on the requests and responses to and from any type of Identity Provider sent or
received via the eIDAS network, the messages exchanged should contain the following
mandatory attributes defined in the eIDAS SAML Attribute Profile:
 For Natural Persons
o Unique Identifier
o Current Family Name(s)
o Current First Name(s)
o Date of Birth
 For Legal Persons

o Unique Identifier
o Legal Name
Assessment
The Annex of the eIDAS Interoperability Framework Implementing Act9 contains the
“requirements concerning the minimum set of person identification data uniquely representing a
natural or a legal person, referred to in Article 11”. Since the eIDAS network implements the
eIDAS Regulation and its implementing acts, it is therefore expected that the authentication
requests and responses contain all mandatory attributes previously defined.

It is assumed that non-notified Identity Providers may not be able to provide all the requested
attributes in the MDS. A possible solution to make up for this is that the sending MS deletes the
attributes that cannot be provided by the Identity Provider from the authentication request before
9
https://ec.europa.eu/futurium/en/system/files/ged/celex_32015r1501_en_txt.pdf
28/69
forwarding it to the Identity Provider. For a successful user’s authentication, the sending MS would
then need to enter pre-agreed fictional values (i.e. dummy data 10) for these attributes not
completed by the IdP.
This option would not require any change to the eIDAS Technical Specifications since the
interfaces with Identity Providers are out of their scope. This is in line with the principle of minimum
impact on eIDAS Technical Specifications followed throughout this document.
Another option could be to add a new element11 to the eIDAS attribute schemes that indicates
that the subsequent value is fictional. This option would imply a change to section 2.2.2 of the
eIDAS SAML Attribute Profile document.12
Recommendation
For each mandatory attribute, fictional values (dummy data) should be defined that could be
treated as ‘fake’ values by non-notified Identity Providers.
4.1.6 Levels of Assurance (LoA)

The eIDAS Regulation defines three assurance levels (LoA) that are based ‘on the degree of
confidence that electronic identification means provide’ and ‘which depends on the level of
resistance against reproduction’.
Moreover, the Regulation defines a hierarchy of LoA. This means that an authentication response
with higher assurance level than what was required in the authentication request is accepted,
while a response with a lower assurance level than what is requested is aborted.
The LoA hierarchy established by the eIDAS Regulation is not applicable to non-notified Identity
Providers.13 It is therefore not possible to ensure that the level of assurance of a non-notified
Identity Provider is compatible with the level of assurance of another non-notified Identity
Provider, or even with that of a notified Identity Provider.
10
For example, if a non-notified Identity Provider cannot provide the birth date of a person, a fictional value to fill the requested attribute
could be ‘01/01/0001’ (DateTime.MinValue in C#) or -1000000000-01-01T00:00Z (public static final Instant MIN constant in Java).
11
For example: <xsd:attribute name="FictionalValue" type="xsd:boolean">. If a fictional value is provided, the FictionalValue attribute
must be set to “true” to indicate a fictional variant of the attribute value. This FictionalValue attribute is an optional field and set to “false”
by default.
12
Some experts of the eIDAS technical group expressed some concerns regarding the inclusion of fake values to replace fields of the MDS
in the case of private sector service providers. They were rather in favour of lifting eIDAS technical requirements applicable to public sector
providers.
13
As mentioned in footnote n.7, this document was elaborated on the basis of the version 1.1. of the eIDAS Technical Specifications, which
was the most updated version available at the time of writing. Based on information shared with everis by eID experts from the Member
States, in the upcoming version of the eIDAS Technical Specifications the LoA applicable to non-notified Identity Providers will be defined.
As opposed to the LoA for notified eID schemes, which follows a hierarchical approach, the LoA for non-notified IdPs will follow an exact
matching approach between the authentication request and the response given.
29/69
Figure 6: Non-comparable Levels of Assurance between notified and non-notified IdPs

The eIDAS Interoperability Architecture specifies that “if the requested (or higher) Level of
Assurance cannot be fulfilled by the eIDAS-Service, the Request MUST be rejected”. In addition,
“the Connector MUST verify that the Level of Assurance indicated in the Assertion matches or
exceeds the requested Level of Assurance”.
LoA attribute in the request LoA attribute in the response Notified IdP (eIDAS
Regulation)
Low Low Accepted
Low Substantial Accepted
Low High Accepted
Substantial Low Error
Substantial Substantial Accepted
Substantial High Accepted
High Low Error
High Substantial Error
High High Accepted
Assessment
Non-notified Identity Providers most probably do not follow the definition of LoA established by
the eIDAS Regulation. The assurance levels of non-notified Identity Providers are therefore not
comparable. This is why the provision of any level of assurance other than the level indicated in
the request for user authentication is not accepted. The following table shows the differences in
the workflow for notified and non-notified Identity Providers regarding the values of the LoA
attribute in the request/response:
30/69
LoA attribute in the LoA attribute in the Notified IdP (eIDAS Non-notified IdP
request response Regulation) (Constraint)
Low Low Accepted Accepted
Low Substantial Accepted Error
Low High Accepted Error
Substantial Low Error Error
Substantial Substantial Accepted Accepted
Substantial High Accepted Error
High Low Error Error
High Substantial Error Error
High High Accepted Accepted

A first possible option is to only allow LoA = High for non-notified Identity Providers (last three
rows in the table). In this case there is no difference between the workflows for notified and non-
notified Identity Providers.
A second possible option is to give additional responsibility on the MS side to ensure that the non-
notified Identity Providers would provide the LoA that is requested. If this is not the case,
authentication should be aborted.
Both options do not require any change to the eIDAS Technical Specifications. Interfaces between
the eIDAS node and Identity Providers and implementation of Identity Providers are the
responsibility of MSs.
Recommendation
There is no good solution for this challenge considering the non-comparable LoA of non-notified
Identity Providers, which is a constraint. Nonetheless, the second option seems preferable to the
first one because it provides more flexibility. However, this challenge remains open.
It should be noted that the recommendation above focuses only on technical aspects. It does not
address the issues pertaining to the lack of legal certainty and liability that may derive from the
use of non-notified Identity Providers for cross-border authentication requests.
4.2 SECTOR-SPECIFIC ATTRIBUTES
HEIs and banks set the same requirements for user authentication as public administrations:
confidentiality, integrity, secure identification and authorisation, robustness, etc.
The major difference with respect to the public sector lies in the authorisation attributes. While
public organisations require personal attributes of the user from the eIDAS MDS, HEIs and banks
mainly require domain-specific attributes for providing authorised access to specific services
online. For instance, in order to provide free access to Wi-Fi a HEI needs to know if the user is
an active student, while the last name and the first name of the student are not mandatory.
However, in order to enrol a student in a mobility service, a HEI needs personal data from the
31/69
eIDAS MDS, in addition to other educational attributes such as the university code and the student
number.
4.2.1 Educational and Banking Attributes
In the scope of this study, the most popular online services offered by HEIs were analysed with
the aim of defining a set of student personal data that allows informing decisions about a student’s
credentials in the authentication process. Based on the HEIs interviews’ outcomes and the
analysis of projects in the educational domain, the following educational attributes in conjunction
with the eIDAS dataset are used to grant access to online services in the educational domain:
 Student Identifier
 Email address
 Citizenship
 Group affiliation
 Preferred Language
 Mobile Number
 Degree
 Expiration date
 HEI Identifier
 Name of HEI
 Alternative Name of HEI Identifier.
The situation in the banking domain is similar to the one described in the educational domain.
Currently, financial institutions that already offer custom implementations of the online on-
boarding process make use of national eID schemes. As in the educational domain, banks also
require domain-specific attributes beyond the eIDAS MDS. These attributes are mainly
determined by international legislation (e.g. BASEL and AML 14). Based on the interviews
conducted during the design phase of this project these are:
 Politically Exposed Person (PEP)

 Source of funds
 Tax residence
 Social Security Number
 Country of nationality
 Email address
 Occupation (profession)
Our analysis focused on the on-boarding process for natural persons. However, it should be noted
that, in general, the on-boarding process is also applicable to legal persons. For legal persons,
however, the process is more complex than the one for natural persons, mostly because
additional information is required from heterogeneous sources.
14
Capital Requirements Directive and Fourth Anti-Money Laundering Directive, respectively.
32/69
According to the main aim of the eIDAS Regulation, the eIDAS network can be used to transfer
personal data cross-border, including domain-specific attributes.
Assessment
Section 2.7 on the Sector Specific Attributes of the eIDAS SAML Attribute Profile lists the general
principles for development of additional attribute schemes for domain-specific attributes. These
attributes should be included in the eIDAS Node Metadata. According to the eIDAS Technical
Specifications (section 2.7 “Sector Specific Attributes” of the eIDAS SAML Attribute Profile) the
eIDAS SAML Attribute Profile should be updated with a new domain-specific attributes’ schemes.

In order to add these attributes to the eIDAS SAML Attribute Profile, they should be defined in
some name space (e.g., "http://eidas.europa.eu/attributes/education" for the educational domain
and "http://eidas.europa.eu/attributes/ebanking" for the banking domain). The eIDAS Service
SAML Metadata and the authentication request/response messages must be changed in
accordance with the newly defined attributes.
A sample of attribute schemes for both domains, including the new attributes in the messages,
are provided in the project’s deliverables “D.05 Architectural Solution Document (eStudent) with
recommendations” and “D.06 Architectural Solution Document (eBanking) with
recommendations”.
Our recommendation
Adding new attributes in the authentication requests will not create an obligation for HEIs or banks
to use eID authentication for all their services or to develop new services complying with eIDAS.
The aim is, on the one hand, to bring cross-border authentication and e-learning services together
in order to enhance educational services available in the educational domain and make them
available to a wider audience, and to encourage the “private” sector to use and reap the benefits
of the eIDAS network in the banking domain, on the other. Additionally, this would support
simplification in the development of new services in both domains and increase the usage of the
eIDAS network.
4.2.2 Cross-sector attributes

Attributes with the same or similar meaning exist in more than one domain. For example, the
email address or the country of nationality exist both in the educational and the banking domains.
Despite their similarity, the semantic meaning of these attributes is different in the two domains.
The email address in the student domain is an email service provided by a HEI. While this email
is used as communication address, it also serves to prove that the person is a student or a
member of the scientific staff, because the HEI provides the email service only to its students
and staff. In the banking domain, however, the email address is simply a contact address enabling
communication between the bank and the customer.
33/69
If the client is a student, he/she could indeed provide his student email as a contact email for
communicating with the bank. When the student graduates, however, he/she would need to
change the email address provided to the bank. Consequently, the lifecycle of these attributes is
different. The student email remains unchanged for the whole duration of the academic life, while
the email provided to a bank may change over time.

This challenge is not a technical one. It is on a semantic and organisational level. The eIDAS
SAML Attribute Profile supports semantic interoperability of information exchanges in the eIDAS
network and provides five general principles for the development of domain-specific attribute
schemes.
Assessment
In spite of the apparent conflict with the principle of data minimisation and the need to avoid
duplication of attribute types, the definition of domain attributes does not contradict these guiding
principles. In the authors’ understanding, domains are disjoint: an attribute cannot belong to two
different domains simultaneously, even if they may have had a similar meaning or the same value
at some point in time. This implies that different domains could interpret the same values in
different ways and that a different lifecycle for a same attribute could be expected depending on
the domain.

N/A.
Our recommendation
The distinction and separation between domains should be supported in order to prevent
misinterpretation risks and to ensure semantic and operational interoperability.
4.2.3 Quality of attributes

It can be assumed that Attribute Providers could provide data with different data quality levels.
Authentication and authorisation processes are particularly sensitive to the obsolescence or low
quality of personal identification data.

The eIDAS Regulation does not envisage any data quality indicator for the personal data
contained in the minimum dataset which is transferred in the authentication response. Such an
indicator is not needed as the data sent through eIDAS is considered to be of the highest quality.
The quality of the data provided by the Identity Provider is ensured by the Member State through
the notification procedure of the Identity Provider connection to the eIDAS network. However, it
should be noted that the eIDAS Technical Specifications include a set of validations regarding the
format of the attributes and their presence (mandatory or optional) in the authentication response.
Assessment
Data quality control entails complex data processing. The following are the most common six
dimensions relating to data quality: accuracy, completeness, uniqueness, timeliness (often
34/69
referred to as data update), validity, and consistency. Each dimension may encompass several
data quality rules and quality indicators to be created in order to measure quality.
Due to the complexity of the logic required to manage and control the quality of data, creating
common data quality rules/indicators that would be applicable to all attributes across domains for
all Attribute Providers is not feasible.
However, considering that Attribute Providers use personal data in their business processes and
the quality of these data is sufficient for the services they provide, it can be assumed that such
data quality is also sufficient for Service Providers. This assumption would ease the situation
where an organisation plays both roles: as Service Provider and as Attribute Provider. For
example, a HEI is a Service Provider for its students when they use the services it offers. At the
same time, the HEI is an Attribute Provider for another HEI when its students consume services
provided by other HEIs. Based on this assumption, there could be mutual trust between HEIs
regarding data quality. Data is considered appropriate to grant access to the online services
provided by other HEIs to the students of one particular HEI if this HEI provides similar online
services to its students.

It is the responsibility of Attribute Providers to provide personal data with an appropriate quality
level. In some domains (e.g. banking, custom, taxation) it is the responsibility of Member States
to determine the competent authorities that can play an Attribute Provider role if there are
regulatory requirements to comply with.
Our recommendation
For now, there is no need to add new elements regarding data quality control to the eIDAS
Technical Specifications. Requirements for the domain data are derived from requirements to the
actual online domain services. If we assume that a MS has an Attribute Provider that provides
domain-specific data to national domain Service Providers, the quality of the data provided should
meet the requirements of the domain services. It then follows that the data quality of that Attribute
Provider should be considered as appropriate or sufficient to grant access to online services in
other MSs in that domain.
4.3 NATIONAL IT INFRASTRUCTURE CONSIDERATIONS (OUT OF

THE SCOPE OF THE EIDAS TECHNICAL SPECIFICATIONS)
4.3.1 Attribute Providers

In the framework of this study four types of domain Attribute Providers have been defined. The
classification presented below is based on the organisational structure and types of datasets that
an Attribute Provider is able to provide:
- Centralised and complete domain Attribute Providers are able to supply the complete
set of domain attributes for all persons and/or legal entities in a given MS. The Ministry
35/69
of Education is an example of such an Attribute Provider in the educational domain,
provided that it has the academic records of all students in that MS.
- Distributed and complete domain Attribute Providers are able to supply the complete
set of domain attributes, but not for all persons and/or legal entities in a given MS. A HEI
is good example of this type of attribute provider in the educational domain because one
HEI is not able to provide the data for all students in a given MS. However, through the
aggregation or federation of HEIs in an MS, it would be possible to provide data for all
students in that country.
- Centralised and fragmented domain Attribute Providers are able to supply a sub-set of
domain attributes for all persons and/or legal entities in a given MS. The Tax Authority is
an example of such an Attribute Provider in the banking domain. It usually keeps the Tax
Residence, Social Security Number, and Country of Nationality (among others) for all
citizens in that MS. However, the information about a person being Politically Exposed
may not be found in the Tax Authority’s databases. The PEP status of citizens in MS is
provided by a different organisation.
- Decentralised and fragmented domain Attribute Providers are able to supply a sub set
of domain attributes, but not for all persons and/or legal entities in an MS. The Regional
Administrations (e.g., municipalities) are examples of such Attribute Providers in the
banking domain. They keep actual information about Email, Social Security Number, and
Country of Nationality for all persons who live in a region.
The following figure shows some examples of identified Attribute Providers.
Figure 7: Examples of Attribute Provider types in the analysed domains
36/69
It should be noted that international data providers also exist. These are centralised and usually
provide a subset (fragment) of domain attributes. However, such sets of data could be enhanced
and these international data providers could become centralised and complete domain Attribute
Providers. The European Student Card platform is an example of an international centralised
Attribute Provider.
Analysis of the Tech specs regarding this challenge

The connection with Attribute Providers is a prerogative of Member States and, consequently, it
is out of scope of the eIDAS Technical Specifications. Therefore, no changes to the eIDAS
Technical Specifications would be needed.
Assessment
Taking into account the large number of domains and Attribute Providers, it is obvious that some
kind of adaptor is needed between the eIDAS node and the Attribute Providers to deliver the
authentication request to the appropriate Attribute Provider(s) and compile information from
different Attribute Providers consolidated in one response. However, it should be noted again that
this change is out of the scope of the eIDAS Technical Specifications.

More detail about possible solutions to this challenge is provided in section 5.2.
4.3.2 Service Providers

A Service Provider may not require the eIDAS MDS to grant access to online services to a user.
It may require only domain-specific attributes. For example, a HEI only requests the student status
to grant access to the Wi-Fi network. Moreover, other Service Providers may prefer not to receive
and handle the eIDAS MDS in the authentication response in view of the data protection
requirements.
Analysis of the Tech specs regarding this challenge

The connection with Service Providers is a prerogative of Member States and, consequently, it is
out of scope for the eIDAS Technical Specifications. However, the eIDAS Connector will generate
the error ‘Incomplete attribute set’ if the authentication request does not contain all mandatory
attributes in the MDS.
Assessment
Some kind of adaptor is needed between Service Providers and the eIDAS node to enrich
authentication requests with mandatory attributes and delete non-requested attributes from the
response. This adaptor could also provide a domain-specific interface and facilitate the
connection of domain Service Providers to the eIDAS network. However, it should be again noted
that this change is out of scope for the eIDAS Technical Specifications.

More details about a possible solution to this challenge are provided in section 5.2.
37/69
4.4 SUMMARY OF THE IMPACT ON EIDAS TECHNICAL
SPECIFICATIONS
The following table provides an overview of the changes to the eIDAS Technical Specifications
that would be needed in order to overcome the challenges described above.
SAML
IOP Arch Message Crypto
Profile
Non-notified schemes
Non-acceptance of non-notified
M M
Identity Providers
Acceptance of non-notified M M
Identity Providers
Multiple nodes for different IdP M M
One node for all IdP (merged)
Technical specifications
O
constraints - MDS
Levels of Assurance (LoA)
Sector specific attributes
Educational Attributes M O
Banking Attributes M O
Cross-sector attributes
Quality of attributes
Related to MS infrastructure (out of the scope of the eIDAS Technical Specifications)
Attribute Providers
Service Providers
M = Mandatory change
O = Optional change (but recommended)
Adding sector-specific attributes would not require changes to the message format, but changes
in the examples of the messages provided in the “Message Format” document could be
considered. In particular, adding new examples is recommended (request, response, and
metadata) to reflect how domain-specific attributes could look like.
4.5 EXPERT RECOMMENDATIONS
The following points summarise our expert recommendations derived from the challenges and
solutions for the eIDAS Technical Specifications described above. It should be noted that these
recommendations were presented and discussed with the members of the eIDAS technical
subgroup during a stakeholder engagement event organised in October 2018. They are
presented below in the order that they were ranked by the experts:
1. Domain attributes are provided by domain Attribute Providers. It should be the

responsibility of Member States to define the public or private entities that would perform
the role of Attribute Providers in a particular domain.
38/69
2. One eIDAS Service should be maintained per Member State (as is now in the eIDAS
Technical Specifications)
3. The eIDAS SAML Attribute Profile should be enhanced with domain-specific attributes to
facilitate the usage of the eIDAS network in domains other than the public sector. 15
4. The authentication request should be capable of distinguishing between non-notified
Identity Providers and notified Identity Providers. One possible solution is to add a new
attribute in the request to ease this distinction (e.g.nonNotifiedIdP). The
authentication response should also be capable of indicating whether it was originated
by a non-notified Identity Provider or by a notified Identity Provider. One possible solution
is to add a new attribute in the response to ease this distinction (e.g
nonNotifiedIdP).
5. Non-notified Identity Providers should be connected to the eIDAS network.
6. Domains should be considered as being disjoint. One attribute cannot be approached as
belonging to two different domains simultaneously. In spite of having had potentially the
same value at some point in time in the concerned domains, the interpretation and
meaning of this value may not be the same or could have changed over time.
7. Fictional values (dummy data) could be defined for mandatory attributes of the eIDAS
MDS. These should be interpreted as ‘fake’ values of SAML Attributes when the
authentication response comes from a non-notified Identity Provider.16
In spite of the recommendations above, the following challenges can still significantly limit the
usage of non-notified Identity Providers:
 The receiving MS may not accept non-notified Identity Providers in spite of the fact that
the sending MS only has non-notified Identity Providers.
 Another open issue for non-notified Identity Providers concerns the non-comparable
Level of Assurance (LoA). The co-existence of notified and non-notified Identity Providers
in one MS with non-comparable LoA restricts the ability of the user to select its preferred
Identity Provider. For instance, the fact that both a notified and a non-notified Identity
Provider provide a ‘high’ LoA does not mean that the user may select any of them to
access a given service. If the authentication request calls for a ’substantial’ LoA, the non-
notified Identity Provider cannot be used for the user authentication, as there is no exact
matching in the LoA provided in the response. In contrast, if the authentication request
calls for a ’high’ LoA, both a notified and a non-notified Identity Provider could be used to
authenticate the user.
 Different sets of attributes are provided by non-notified Identity Providers. The use of
fictional values for mandatory attributes of the eIDAS MDS to complete missing data in
responses provided by non-notified Identity Providers increases complexity as it requires
content analysis to distinguish fictional values from real values.
In the near future, all Member States will operate one or more notified Identity Providers. All EU
citizens and businesses will have the possibility of getting authentication means issued by notified
Identity Providers.
15
Some experts of the eIDAS technical subgroup further noted that prior to enhancing the eIDAS SAML Attribute Profile, it should be
determined which authority will be competent for the governance and decision-making regarding the domain-specific attributes.
16
Some experts expressed their concerns with regard to this recommendation. According to them, lifting the technical requirements
established for notified eID schemes regarding the MDS when dealing with private service providers would be a more appropriate design
option.
39/69
Taking into account the requirements laid down in the eIDAS Regulation and the challenges
described above, MSs should assess the impact of the inclusion of non-notified Identity Providers,
in view of a further evolution of the eIDAS ecosystem.
In our view, two ways could be proposed to address the open issue of non-notified Identity
Providers:
1. To execute the notification procedure for the non-notified Identity Providers and
‘transform’ them into notified Identity Providers, or
2. To connect non-notified Identity Providers to the eIDAS network as domain Attribute
Providers for cross-border authentication, while maintaining their role as Identity
Providers for national Service Providers.
In their role as Identity Providers, non-notified Identity Providers would continue to offer
authentication services for national Service Providers.
As domain Attribute Providers for the eIDAS network, non-notified Identity Providers
would be responsible for implementing a web API to fetch the requested specific
personal data from relevant databases. More information about the possibilities for
connecting domain Attribute Providers to the eIDAS network can be found in section 5.
It should be noted that this scenario is only possible provided that the MS has at least
one notified Identity Provider.
40/69
5 SUPPORTING ADOPTION AT NATIONAL LEVEL
Considering the wide range of national digital infrastructure landscapes at the level of Member
States, the challenge is to define an approach to connect the proposed new domain Service
Providers (SPs) and Attribute Providers (APs) to the eIDAS network. This chapter discusses some
of the most common patterns to connect SPs and APs to the eIDAS network.
This section does not aim to provide an exhaustive analysis of all the different types of MS
Digital Infrastructure that might exist in the EU. However, it does describe the most
common types of digital infrastructures.
An analysis is made of the benefits and drawbacks of different scenarios for AP and SP
integration. The main objective is to provide support in the identification of configurations
described in section 5.3, in order to determine the scope of the changes needed to both public
and private sectors, and to choose the most appropriate approach based on the specific
circumstances of each Member State.
This section is designed to support professionals working on the architecture governance and
systems development of the eIDAS ecosystem (i.e. Attribute Providers, Identity Providers,
Service Providers, etc.) at the Member State level. It also supports the decision-making process
for the further development and improvement of the public and private sector national digital
infrastructure.
5.1 OUT-OF-THE-BOX EIDAS
The eIDAS ecosystem encompasses the following players: eIDAS-Node implementers and
operators, Single Points of Contact, Identity Providers, Attribute Providers, Public and Private
Service Providers, and EU citizens. The different eIDAS players participating in the electronic
identification for public SPs are presented in the simplified schemes below.
When a user from another Member State requests access to an online service from a Service
Provider, the Service Provider (connected either directly to an eIDAS Connector or via a national
IdP/authentication gateway) sends the authentication request (with a list of required attributes) to
the eIDAS network. The request is routed from the eIDAS node (i.e. eIDAS Connector) of the
Service Provider's MS to the eIDAS node (i.e. eIDAS Service) in the user's country. The eIDAS
Service in the user's country re-directs the authentication request to the corresponding Identity
Provider. The Identity Provider authenticates the user and returns their identification data. The
eIDAS network returns all these attributes to the Service Provider through the eIDAS network.
The dataflow is as follows:
41/69
Figure 8: AS IS dataflow
5.2 OVERCOMING CHALLENGES AT NATIONAL LEVEL: SERVICE

PROVIDER AND ATTRIBUTE PROVIDER ADAPTORS
As explained in the deliverables produced in the design phase of the project,17 two extra modules
are proposed in order to facilitate the integration of the private sector to the eIDAS network. These
are the Service Provider Adaptor and the Attribute Provider Adaptor (hereinafter SP Adaptor and
AP Adaptor, respectively).
On the one hand, a Service Provider Adaptor aims to address the challenge described in section
4.3.2 and simplify the connection between Service Providers and the eIDAS network, both
organisationally and technically. The main objective of this proposed software-based module is
to adapt the message from Service Provider applications to a format that is suitable for the eIDAS
Connector service maintained by the MS Node operator [2]. The following list contains the basic
features of this module:
 Able to handle parallel requests from Service Providers and route them to the eIDAS
network
 Providing a simplified interface if necessary
On the other hand, an Attribute Provider Adaptor is proposed to overcome the challenges
described in section 4.3.1 regarding the large number and typologies of Attribute Providers in
Member States. These challenges are further discussed below.
17
D04 - Architectural Solution Document (eBanking) and D05 - Architectural Solution Document (eStudent).
42/69
It is not reasonable to think that one single organisation could provide all attributes for all domains
in a Member State. Not only because of the decentralisation of domain infrastructures in the
private sector, but also taking into account the variety of possible domains considered (e.g.,
transport, banking, education, health, energy, custom and taxation, etc.). It is doubtful that one
organisation could simultaneously store the fiscal number of a person and his/her membership to
a particular research group, to mention but one example. Therefore, if a Service Provider requests
educational attributes, this request should be routed only to relevant educational Attribute
Providers and not to any Attribute Provider. This is the reason why a content routing functionality
(based on the list of attributes included in the request) is mandatory for the effectiveness of the
APs in the eIDAS network.18
In the event that one Attribute Provider is able to provide only a part of the requested attributes in
the list sent by the Service Provider, and another Attribute Provider is able to provide the second
part of the attributes, for example, the request should be split into two parallel requests and sent
to both Attribute Providers. Their responses should be then aggregated into one response with
the consolidated dataset. The Service Provider needs to receive both attributes as one
consolidated response from the eIDAS network. In addition, the domain-specific logic may also
require a user interface in some cases (e.g., if a user has studied in two HEIs he/she should select
which HEI should provide his/her personal data in the authentication response).
These challenges call for the implementation of a module with routing and aggregation
functionalities that is able to connect the eIDAS node to domain Attribute Providers taking into
account domain-specific requirements. This module is called the AP Adaptor. The following list
contains the basic features that this module should include:
- Content routing based on the list of attributes included in the SP request

- Aggregation functionality: one incoming request should be split into two or more requests
with a different list of attributes. The resulting response should be aggregated into one
response with a consolidated dataset
- Handling parallel requests: one incoming request should create many parallel requests
to Attribute Providers based on the same list of attributes
- Support different protocols to connect to Attribute Providers
The following figure shows the data flow including the two proposed adaptors: A user wants to
have access to the service of an SP and the user creates a request (1). SP Application redirects
the user to the SP Adaptor with the list of required personal attributes in the request (2). The SP
Adaptor verifies the request, adds attributes which are mandatory for the eIDAS network (e.g.,
LoA, unique identifier, last and first names, etc.) and creates the authentication request (3) and
forwards it to the eIDAS node of the receiving MS. The eIDAS node of the receiving MS sends a
SAML authentication request (4) to the eIDAS node of the sending MS. The eIDAS node of the
sending MS redirects the user to the Identity Provider (5). The Identity Provider prompts the user
to authenticate him or herself (6). The user provides his/her credentials (7). The Identity Provider
provides the eIDAS MDS in the response (8). The eIDAS node19 sends the list of domain attributes
and the user’s identification data to the AP Adaptor in the request (9). The AP Adaptor receives
18
This proposal has been welcomed by several experts of the eIDAS technical subgroup.
19
Depending on the MS Infrastructure. It could be eIDAS node itself, the Identity Provider or even an Attribute Provider.
43/69
this message, and forwards it to the relevant Attribute Providers in the particular domain (10). If
there are two or more Attribute Providers, the requests (10) are sent in parallel. The Attribute
Providers fetch the requested domain-specific attributes by matching the provided identity data
with their databases, and provide values for the requested attributes in the response (11) to the
AP Adaptor. The AP Adaptor aggregates the responses of Attribute Providers and sends the
consolidated message (12) as response to the request (9). The eIDAS node of the sending MS
delivers the data to the MS Node of the receiving MS in the SAML authentication response (13).
The eIDAS node of the receiving MS sends the message (14) to the SP Adaptor. The SP Adaptor
provides the data in a convenient message format to the SP Application (15). The SP Application
grants the user access to the service (16).
Figure 9: TO BE dataflow
This proposal implies that the eIDAS SAML Attribute Profile will be enriched in the authentication
request and respond with the domain-specific attributes. The solution does not imply any other
changes to the eIDAS network.
The diagram above considers the following assumptions:
 The user is successfully authenticated by the Identity Provider.

 The user’s eIDAS MDS have been filled in within the eIDAS Network (either by the
Attribute Provider and/or by the Identity Provider).
 The eIDAS response message has to be filled in with sector-specific attributes according
to the eIDAS Interoperability Architecture.
 The AP Adaptor is requested to provide the domain-specific attributes (either by the
Identity Provider or by the eIDAS node itself, depending on the national implementation).
 As input data, the AP Adaptor receives the eIDAS MDS attributes including the user’s
Unique identifier, First name, Last name, Birth date.
44/69
 The AP publishes an interface (API) where the personal data search criteria should be
entered. The Unique identifier may be used as a criterion for an exact search.
Alternatively, the attributes First name, Last name, Birth date, and others can enable
fuzzy matching of the personal data with high probability of identifying the user.
 The Identity Provider and the Attribute Provider belong to the same Member State.
A key assumption is that the Identity Provider supplies sufficient identity data of the user to the
Attribute Provider in order to enable a successful search of the user’s data in AP databases. The
Identity Provider only provides the personal data of the user after the user’s successful
authentication.
It should be noted that if a Unique Identifier of a user, issued by an Identity Provider, is stored in
a domain database, the exact search by Unique Identifier can improve the performance of the
operation. However, our study has shown that keeping Unique Identifiers in domain databases is
not a common practice because this would imply implementing matching algorithms to link
personal data from an Identity Provider with personal data stored in a database.
It is also assumed that the combination of some of these eIDAS MDS search criteria (e.g. Current
Family Name, Current First Name[s], Date of Birth, Place of Birth and Gender) enable a natural
person to be uniquely linked to a domain-specific database. Nonetheless, it should be noted that
the fact that the search does not use a primary key may lead to some link inconsistencies (e.g.,
due to data quality issues or because optional data has not been included, the search result may
refer to a different person).
The description of the proposed AP Adaptor does not contain any reference to a specific domain.
Moreover, content routing and aggregation functionalities of the AP Adaptor are supposed to
make use of matching algorithms to link personal data. This would allow this solution to be applied
in most domains.
5.2.3 Additional components
A domain-specific logic may be needed to improve the usability and increase the efficiency of the
proposed solution and facilitate the connection to the eIDAS network.
A Member State may already have deployed applications that have been playing the adaptor or
gateway role for Service and Attribute Providers in order to connect them to the eIDAS network.
In this case, the MS does not need to implement the proposed SP Adaptors and AP Adaptor to
avoid functional redundancy. Nevertheless, these adaptors or gateways should have the content
routing and aggregation functionalities proposed for the Adaptors. These functionalities are critical
to connect domain APs to the eIDAS network in an efficient way and avoid overloading the
system.
SP Adaptor
The SP Adaptor as a software may have specialised modules with domain-specific interfaces that
can offer domain authentication services. Such a structure of the SP Adaptor is presented in the
following figures as an example of the two domains analysed in this project:
45/69
Figure 10: SP Adaptor
The SP Adaptor has a “common services” module that performs protocol and message
transformation and offers a verification functionality. This would be common for all domains.
However, a domain-specific functionality could be implemented on top of these common services.
These could include, for instance, a specific set of authentication services for HEIs or a uniform
authentication service for the bank on-boarding process across Europe.
Nonetheless, it is the responsibility of Member States and their Service Providers to identify the
needed domain-specific functionalities and to define an appropriate schemes for the
implementation of the SP Adaptor.
AP Adaptor
The AP Adaptor can be considered, from the eIDAS network perspective, as a federated Attribute
Provider. The deployment of the AP Adaptor may vary depending on the situation of the Member
State, in the same way as the SP Adaptor. However, the AP Adaptor makes it possible to build
hierarchical “networks of APs” with different domain logic (detailed information about possible
configuration of “networks of APs” is provided in D05 Architectural Solution Document (eStudent)
with recommendations document created in previous phase of the project, the design phase). In
any case, the user’s identification data from the eIDAS minimum dataset and the list of domain
attributes would be available in the inbound requests for the AP Adaptor.
Figure 11: AP Adaptor
The domain-specific functionality offered by the AP Adaptor provides additional opportunities for
the eIDAS ecosystem. Such a logic can be implemented before and after forwarding the request
to the relevant Attribute Provider(s). For example, the AP Adaptor could display a selection of
Attribute Provider(s) through a user interface before sending the request. Such a functionality
would allow limiting the propagation of unnecessary requests.
46/69
Also, the AP Adaptor could display a user interface for data selection after receiving the data from
Attribute Providers, should these Attribute Providers return different values for the same set of
attributes. Such a functionality would increase the usability of the solution. However, this would
ultimately depend on the particular domain and its applicable regulation. For instance, in the
banking domain Attribute Providers should already be pre-defined by each MS, taking into
account strict regulation in this area.
5.3 NATIONAL EID LANDSCAPES
The eIDAS Interoperability Architecture defines two possible roles for Member States within the
eIDAS ecosystem: Receiving MS and Sending MS. The MS plays a Receiving role when the
Service Provider of that MS requests user authentication and receives identification data from the
eIDAS network. The MS plays a Sending role when the eID scheme of that MS authenticates the
user and sends identification data to the Receiving MS.
Therefore, each Member State plays both roles. The following figure provides a conceptual view
on the national infrastructure of a Member State showing both roles.
Figure 12: National infrastructure conceptual view
The figure above presents the eIDAS infrastructure for one Member State. Other Member States
have a ‘mirror’ infrastructure. Each Member State has to implement an eIDAS Connector, either
a centralised node or several decentralised nodes, in addition to an eIDAS Service, which can
either be Proxy- or Middleware-based. Each Member State may have plenty of Service Providers
and Attribute Providers connected, as well as one or more Identity Providers which are either
already connected or will be connected to the eIDAS network. It should be noted that this
integration schemes of the Service Provider, Identity Provider and Attribute Provider is only
conceptual. The eIDAS Technical Specifications do not specify how these actors of the eIDAS
ecosystem should be connected to the eIDAS network.
47/69
The diversity of Member States’ landscapes is also closely linked to the actual situation regarding
national eID solutions. In some mature MS, Service Providers had already connected with
national Identity Providers before the eIDAS Regulation was adopted. In this case, the national
Identity Provider could implement an additional Proxy module20 to forward authentication requests
to the eIDAS network for users from other Member States in order to simplify and facilitate the
connection of the Service Provider to the eIDAS network. The Proxy module could also provide a
user interface allowing the user to select his/her national Identity Provider to be used for the
authentication procedure. The figure below provides a very simplified overview of possible digital
infrastructure landscapes in the EU. This selection of national IT landscapes has been
compounded by everis’ research team based on expert assumptions from previous projects and
on feedback provided by the European Commission. This list should not be considered either as
exhaustive or as fully representative, as some Member States are still developing their eID
infrastructure, while others may present some variations of these simplified types.
Figure 13: Member States’ infrastructure landscapes
The eIDAS Technical Specifications allow Member States to choose a Proxy- or a Middleware-
based solution for their eID scheme(s). In the case of Middleware, the MS does not operate the
eIDAS Service itself, but provides a software (Middleware) to the other Member States for them
to operate.
Therefore, it is possible that the eIDAS Service is not present in some MS infrastructure
landscapes. In such cases, this eIDAS Service occurs as the eIDAS Middleware Service
component in other MSs. The Middleware scenario is not described in the figure above because
the integration of domain Attribute Providers and Service Providers does not explicitly depend on
the integration scenario for the eID scheme(s) selected by a particular Member State.
20
In this document, the Proxy Module is understood as an application that is assumed to exist in Member States IT infrastructure to route
both national and cross-border authentication requests.
48/69
However, it should be noted that the Middleware scenario is unlikely to be feasible for MS type 6
(see a detailed description of MS types below), where the eIDAS Service is tightly coupled with
another component of the eIDAS ecosystem. ‘Tightly coupling’ means that components (modules)
are highly dependent on one another, and can be considered as one single application.
Functionality and exposed services provided by that type of coupled application cannot be split
into stand-alone modules.
The paragraphs that follow describe the six types of MS as regards their IT infrastructure that
have been identified:
MS Type 1
This type of solution architecture appears frequently in Member States where one single
organisation is responsible for the implementation and operation of the national eID scheme(s).
Figure 14: MS Type 1
There is one application that contains a tightly coupled Identity Provider, an Attribute Provider and
Proxy modules.
All authentication requests for citizens of this Member State are processed by this application and
they come either from the eIDAS network over the eIDAS Service or from public Service Providers
of the MS. The Proxy module provides a user interface that enables citizens of other Member
States accessing public Service Providers in that Member State to forward the authentication
request to the eIDAS network via the eIDAS Connector. The Attribute Provider module provides
the eIDAS MDS and may store data which goes beyond this minimum dataset. The authentication
response includes all personal data requested by the given Service Provider.
MS Type 2
In this case, there is one organisation managing personal data and another organisation providing
electronic identification service to citizens and businesses.
49/69
There is one Identity Provider and one Attribute Provider. Authentication requests come first to
the Identity Provider, either from the local Service Provider or from the eIDAS Service. The Identity
Provider has a Proxy module that forwards the authentication request from the local Service
Provider to the eIDAS network via the eIDAS Connector for users that want to use the
authentication means issued in other MSs.
The authentication response may not contain all the requested attributes. In this case either the
Service Provider or the eIDAS Service send a secondary request to the Attribute Provider to
enrich the authentication response with the missing data.
MS Type 3
There are several tightly coupled Identity Providers and Attribute Providers that process
authentication requests from Service Providers and the eIDAS network. Each Identity Provider is
coupled with its corresponding Attribute Provider.
The Proxy module provides a selection of Identity Providers through a user interface for
authentication requests either from a local Service Provider or from the eIDAS Service. It also
forwards authentication requests from citizens of other Member States accessing local Service
Providers to the eIDAS network via the eIDAS Connector.
50/69
These Member States usually have a very decentralised structure where tasks of electronic
identification of citizens are entrusted to the regional level.
Another possibility is that Member States have designated several private Identity Providers to
be in charge of the national eID scheme(s). From the Service Provider and eIDAS node
perspective, MS type 3 resembles MS Type 1 because the Proxy module would hide the
complexity of the eID scheme(s).
MS Type 4
There are several Identity Providers and one Attribute Provider in this configuration. The selection
of national Identity Providers is carried out by the Proxy module that is embedded into the Service
Provider application. After a successful user authentication, the Identity Provider sends the
request to the Attribute Provider.
The eIDAS Service orchestrates the requests to Identity Providers and Attribute Providers for
cross-border authentication requests. It forwards authentication requests from the eIDAS network
to Identity Providers and it then sends an additional request to the relevant Attribute Provider to
enrich the response with personal data.
51/69
These Member States usually have a centralised repository of businesses’ and citizens’ data and
they delegate the tasks of electronic identification of citizens to other organisations.
MS Type 5
There is an application that contains both Identity Provider and Attribute Provider modules which
provides all requested data in the form of an aggregated response from Service Providers and
the eIDAS Service.
However, the Proxy module provides a user interface to enable the selection of the national
Identity Provider or another Member State (where the user may have authentication means issued
by the local Identity Provider). The Proxy module is embedded into the Service Provider
application. The requests to the eIDAS network are routed by the Service Provider to the eIDAS
Connector.
52/69
MS Type 6
This configuration with multiple Attribute Providers can be found in Member States with a
decentralised register or several centralised registers. In the latter case, each of the registers
provides a subset of attributes (e.g., one Attribute Provider provides attributes for natural persons,
while another one provides data for legal entities).
The Service Provider sends the authentication request to the Proxy module that is coupled with
the eIDAS Connector. The Proxy module provides a user selection interface that enables the user
to select the national Identity Provider or another Member State (where the user may have
authentication means issued by the local Identity Provider). For national users, the Service
Provider could create one or more additional requests to Attribute Providers to retrieve data
beyond the eIDAS minimum dataset.
In this scenario, the Identity Provider is coupled with the eIDAS Service. After a successful user
authentication, the Identity Provider could send additional requests to the Attribute Providers to
retrieve requested personal data if needed.
53/69
5.3.4 Integration scenarios
Based on the analysis carried out during this project, the outcome of other relevant EU projects
(mentioned at the beginning of this document), the input received from the European Commission
and the current information available for MSs regarding eID maturity levels21, we can conclude
that the most probable MS Types are 1, 2 and 3.22
Figure 20: Most probable MS landscapes
The following sub-sections describe how the proposed solution architecture could be adopted in
the selected MS types including:
- Possible integration scenarios to connect domain Service Providers and domain Attribute
Providers to the eIDAS network. These possible scenarios are indicated by numbers 1,
2, 3 in the figures below.
- A discussion of the advantages and disadvantages of each scenario is presented.
It should be noted that in the analysis of possible scenarios for the integration of domain Service
Providers and Attribute Providers, the assumption has been made that the eIDAS network is not
intended for identifying national users, but rather for cross-border authentication. This is the
reason why the integration between the eIDAS Connector and the eIDAS Service is not
considered within the same Member State, although it would be technically possible.
MS Type 1
Connection of domain SP to the eIDAS network

As described above, this type of MSs have one entity that brings together Identity Provider,
Attribute Provider and Proxy functionality roles. The Proxy module enables forwarding
authentication requests for users from other Member States through the eIDAS network. The
figure below shows the possible integration scenarios to connect domain Service Providers to the
eIDAS network for this MS type.
21
https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Country+Overview+-+eID
22
As part of the stakeholder engagement activities carried out by the research team during the final phase of the project, the selection of
IT landscapes was presented to the members of the technical subgroup of the eIDAS Cooperation Network, composed of Member States’
representatives. Based on the feedback collected, it could be that MS Type 2 is not that common, as in the majority of Member States that
provided their input the Service Provider does not forward the request directly to the Attribute Provider. On the other hand, MS Types 1
and 3, presenting tightly coupled Identity Providers and Attribute Providers, and the Proxy module as a standalone application (in the case
of MS Type 3) could be indeed the most common. Some experts also confirmed the existence of MS Type 4 with small variations.
54/69
Figure 21: Service Provider integration for MS Type 1
The domain Service Provider could either connect to the national Identity Provider that includes
the Proxy module (scenario 1), or directly to the eIDAS node (scenario 2). In scenario 1 the Identity
Provider can identify national users and the Proxy module enables to route authentication
requests of users from other Member States to the eIDAS network. In scenario 2, the eIDAS
Connector only routes authentication requests to the eIDAS network. Scenario 2 does not cover
authentication requests for national users.
The following table provides a comparison of both scenarios. Scenario 1 is illustrated in the
figure above with the number (1), and scenario 2 is illustrated with the number (2). A legend is
provided below to indicate the meaning of the colours used:
The scenario is aligned with the statement
The scenario is not aligned with the statement
Statement Scenario 1 Scenario 2 Comments

The scenario is consistent with Scenario 1 implies a unified
the existing approach for the integration approach for all
integration of public SPs with public and private SPs.
the eIDAS network Scenario 2 does not align with
existing practice of the MS
The domain SP uses or plans Scenario 1 fulfils the
to use national Identity requirement to maintain
Provider for authentication of authentication of national
all its users users. Scenario 2 does not
foresee the integration with
national IdP.
No additional costs expected In scenario 1 the national
to be charged for forwarding Identity Provider may charge
55/69
authentication requests to the private Service Providers for
eIDAS network via the national each re-direction of the request
Identity Provider. to the eIDAS network.
The solution supports national Scenario 1 supports both
authentication and cross- national and cross-border
border authentication authentication.
In Scenario 2 the integration
with the eIDAS Connector
covers only cross-border
authentication though the
eIDAS network. Additional
integration with national or
local Identity Provider would be
needed to authenticate national
users.
Changes in Identity Providers Technical failure of national
(or their technical failure) will Identity Providers will have an
impact on the requests to impact on the requests to the
other MSs eIDAS network in scenario 1.
Scenario 2 does not send
requests to the eIDAS network
via national Identity
Provider(s).
Adherence to single In scenario 1, in addition to
responsibility principle performing national
identification, the Identity
Provider is also responsible for
forwarding authentication
Table 2: Comparison of SP integration scenarios for MS type 1
Scenario 1 covers both national and cross-border authentication. This scenario may entail costs
for private Service Providers, who may have to pay the national Identity Provider for forwarding
the authentication request to the eIDAS network. Tightly coupled modules of the national Identity
Provider in one application may also lead to future performance, scalability and change
management issues for national eID scheme(s).
Scenario 2 only covers authentication of users from other Member States23. This scenario is not
in line with the practice potentially followed by Public Service Providers for integration with the
eIDAS network.
23
Domain Service Providers could already be connected to local or national Identity Providers to authenticate national users.
56/69
Connection of domain AP to the eIDAS network
The domain AP could either be connected to the national eID scheme(s) (scenario 1), or to the
eIDAS Service (scenario 2). The following figure shows two possible scenarios for MS type 1 to
connect APs to the eIDAS network.
Figure 22: Attribute Provider integration for MS Type 1
The following table provides a comparison of both scenarios:
Statement Scenario 1 Scenario 2 Comment

National SPs can use the In scenario 1 the integration
authentication service to scheme could be reused for
retrieve domain-specific national SPs to provide domain-
attributes for national users specific attributes. In scenario 2
and users from other Member a new piece of software would
States be needed to connect national
SPs to domain APs.
Adherence to the single In scenario 1, in addition to
responsibility principle being responsible for user
authentication, the Identity
Provider is also responsible for
the routing and enrichment of
the response with domain
attributes. In general, this is not
the responsibility of the Identity
Provider.
Table 3: Comparison of AP integration scenarios for MS type 1
57/69
The major weakness of scenario 1 is that tightly-coupled modules in one application may drive
future performance, scalability and change management issues for national eID scheme(s).
Scenario 2 only covers cross-border authentication requests from the eIDAS network.
MS Type 2
Connection of domain SP with the eIDAS network

In MS type 2 public Service Providers and the eIDAS node orchestrate two requests to enable
the authentication. The request is first sent to the Identity Provider, which returns a Unique
Identifier for the user and then a separate request is created for the Attribute Provider to retrieve
personal user data. Connection of new SPs may be done either using the existing pattern for
public SPs (Scenario 1 with two separate requests), or connecting directly to the eIDAS node
(Scenario 2).

integration of public SPs to the public and private SPs.
eIDAS network Scenario 2 does not align with
existing practice in MS.
58/69
The domain SP uses or plans In scenario 1 the SP may use
to use national Identity one authentication service for
Providers for authentication of authentication of both national
all its users and foreign users. Scenario 2
does not imply the integration
with national IdP
Additional fees may be In scenario 1 the national
charged for forwarding the Identity Provider may charge
authentication requests to the private Service Providers for
eIDAS network via the national each re-direction of the request
Identity Provider to the eIDAS network private
Service Providers
border authentication authentication.
authentication through the
users.
Changes in Identity Providers Technical failure of national
(or their technical failure) will Identity Providers will have
impact on the requests to impact on the requests to the
other MSs eIDAS network in scenario 1.
Scenario 2 does not send
via the national Identity
Provider
Adherence of single In scenario 1 the Identity
responsibility principle Provider provides routing
functionality in addition to user
identification.
for private Service Providers, who may have to pay the national Identity Provider for forwarding
the authentication request to the eIDAS network. The implementation of the SP Adaptor is
recommended in order to provide a facade for the authentication service and to hide the
orchestration.
59/69
Scenario 2 only covers authentication of users from other Member States 24. This scenario is not
in line with the practice potentially followed by Public Service Providers for the integration with the
eIDAS network.

The Figure below shows the possible options for MS Type 2 to connect APs to the eIDAS network.
The domain Attribute Provider could either be connected via the existing Attribute Provider
(scenario 1), or directly to the eIDAS Service (scenario 2).
Scenario 1 implements the following workflow: if the existing Attribute Provider does not have the
requested domain-specific attributes, it creates a request to the new domain Attribute Provider to
retrieve the data needed.
In scenario 2, the same logic is implemented by the eIDAS Service: if the authentication request
consists of domain-specific attributes, the eIDAS Service creates additional requests to domain
Attribute Provider(s), after successful user authentication.
24
Domain Service Providers could already be connected with local or national Identity Providers to authenticate national users.
60/69
The existing AP is planned to In scenario 1, the existing AP
be used as a proxy for all becomes a federated AP for
domain Aps the eIDAS network and
provides all data sets in all
domains.
All SPs will connect using the In scenario 1, the integration of
current pattern with two the Attribute Provider domain
separate requests through the existing AP could
be used to enrich national
authentication requests with
domain attributes. Scenario 2
authentication requests.
Adherence to the single In scenario 1, the Attribute
responsibility principle Provider provides routing and
aggregation functionality in
addition to fetching the user’s
data.
Scenario 1 means that the existing Attribute Provider becomes a federated Attribute Provider for
the eIDAS network and provides all set of data in all domains.
MS Type 3
Connection of domain SP to the eIDAS network

MS type 3 is MS type 1 including the implementation of several tightly coupled Identity Providers
and Attribute Adaptors that are hidden by the Proxy module. This provides the selection interface
for Identity Providers and forwards authentication requests to the eIDAS network. The connection
of new SPs may be done either using the existing pattern for public SP (scenario 1) or connecting
directly to the eIDAS node (scenario 2).
61/69

integration of public SPs to the public and private SPs.
eIDAS network Scenario 2 does not align with
existing practice of the MS
The SP plans to use national In scenario 1, the SP may use
Identity Providers for one authentication service for
authentication of all (or part of) authentication of both national
its users and foreign users. Scenario 2
authentication.
Additional cost may be In scenario 1, private Service
charged for forwarding the Providers may be charged for
authentication requests to the each re-direction of the request
eIDAS network to the eIDAS network
border authentication authentications.
62/69
authentication through the
users.
Changes in Identity Providers In both scenarios, the technical
(or their technical failure) will failure of national Identity
impact on the requests to Providers will have no impact
other MSs on the requests to the eIDAS
network
Adherence to the single In scenario 1 the Proxy module
responsibility principle is responsible for routing the
authentication requests to the
eIDAS network in addition to
ensuring the national
identification.
In scenario 2 the eIDAS
Connector is responsible for
routing the requests to the
eIDAS network.
for private Service Providers, who may have to pay the Proxy Module operator for forwarding the
authentication request to the eIDAS network.
Scenario 2 only covers authentication of users from other Member States 25. This scenario is not
in line with the practice potentially followed by Public Service Providers for integration with the
eIDAS network.

The following figure shows the possible scenarios for MS type 3 to connect APs to the eIDAS
network. Domain APs could be connected to the national eID schemes (scenario 1 that is similar
to scenario 1 for previous MS Type 2), to the eIDAS Service (scenario 2), or to a Proxy module
(scenario 3).
25
Domain Service Providers could already be connected with local or national Identity Providers to authenticate national users.
63/69
Statement Scenario Scenario 2 Scenario 3 Comments

1
Repeated functionality In scenario 1, all Identity
has to be Providers should develop
implemented in and implement some
several applications routing and aggregation
functionalities
The solution supports Scenarios 1 and 3 support
national both national and cross-
authentication and border authentication.
cross-border In Scenario 2, the
authentication integration covers only
cross-border authentication
through the eIDAS
network. Additional
local Identity Provider
would be needed to
authenticate national
users.
Scenario 1 implies a multiple integration of Identity Providers.
64/69
Scenario 3 implies the Proxy Module to implement the content routing and aggregation
functionality similar to the AP Adaptor functionality.
5.4 IMPLEMENTATION STEPS
An adaptation of the eIDAS network is a prerequisite for the implementation of cross-border

exchange of domain-specific attributes. As a matter of fact, an updated version of the services
offered by the CEF eID Building Block would need to be published. This means that a new eIDAS
node integration package with the sample implementation of the eIDAS Profile, compatible with
the domain-specific attributes and with updated testing tools, would need be developed by the
European Commission.
The CEF eID Building Block services will then ensure semantic and technical interoperability for
Member State organisations involved in both the implementation of the eIDAS ecosystem and
private domains.
In order to implement the proposed solution architecture, Member States could take the following
steps:
1. Define the APs which are able to provide the domain attributes defined in the new eIDAS
Profile. Specifically, in highly regulated domains like banking, Member States should
define the competent authorities that can act as APs on an exclusive basis.
2. Define potential SPs that could use these domain attributes for the development and
provision of trusted online services.
3. Identify high-level integration scenarios for APs and SPs using the patterns provided in
section 3 (defining (i) a conceptual model of the AP’s network and (ii) deployment options
for both SP and AP adaptors).
4. Define a set of templates for AP’s APIs (communication protocols, data format, data
verification rules, etc.) based on the definition of attributes provided by CEF eID Building
Block.
5. Develop the requirements for the SP Adaptor and the AP Adaptor (or software that would
play such roles) based on the decisions taken in steps 3 and 4.
6. Develop the requirements for updating the eIDAS node instance in order to be compliant
with the new eIDAS Technical Specifications.
7. Verify consistency of the developed solution architecture (repeat steps 1-6)
8. Develop the implementation plan aimed at deploying AP Adaptor(s), AP APIs, SP
Adaptor(s) and changes to the MS’s eIDAS node instance.
9. Follow the plan developed in the previous step.
65/69
5.5 ADOPTION REMARKS
Member States are free to use this proposed solution architecture (framework) and to
support any subset of domain attributes.
This document establishes a framework for using of the CEF eID Building Block while facilitating
the implementation of specific domain online services. However, it neither creates an obligation
for Service Providers to use eID authentication for all their services, nor does it develop new
services complying with this framework. SPs will therefore remain free to define their services, as
well as how these should be developed in a particular situation.
On the other hand, domain attributes should be provided by Attribute Providers in the Member
States. This framework does not create an obligation for Member States to provide an exhaustive
list of domain attributes. Member States can support any subset of domain attributes and define
their own implementation roadmap. However, it should be noted that the amount of domain
attributes supported by a Member State can limit the number of available cross-border and local
online services integrated with eID for the citizens in a given Member State. If some attributes are
requested for accessing some services and the MS does not provide these attributes to the eIDAS
network, the SP may not give access to these services to a user from that Member State.
Member States are free to use this framework for the integration of domain Service Providers and
Attribute Providers with the eIDAS network, or not.
66/69
6 AFTERWORD
This document was produced at a moment in which Member States were concentrating their
efforts on complying with eIDAS Regulation obligation regarding the mutual recognition of notified
eID schemes for granting access to services offered by public service providers. Actually, at the
time of issuing this document only nine Member States had either pre-notified or notified their eID
schemes.26 The research team did not therefore have a complete picture of the variety of eID
landscapes existing at national level and it had to make some expert assumptions about them.
While some of these landscapes were presented and discussed with some Member States’
representatives of the eIDAS technical subgroup, more research is needed to discern the most
common Member State types.
It should also be noted that while this document was produced, the eIDAS technical subgroup
was working on an updated version of the eIDAS Technical Specifications that was not yet
available at the time writing. This revised version may therefore already address some of the
issues that are identified as challenges in this document.
Finally, this document may have over-simplified some challenges regarding the exchange of
domain-specific attributes through the eIDAS network. This is due to two main grounds. First, it
should be recalled that the research team made some generalisations on the basis of two
analysed domains (Education and Banking). Additional domains with particular challenges could
be explored in future research. Secondly, some identified challenges were deliberately not
addressed in this document for the sake of avoiding too much complexity at an early stage of
development of the eIDAS network. An example of such unexplored challenges is related to the
quality of domain attributes and the varying degrees of trust that might be requested by service
providers for each domain attribute in the authentication request depending on the particular
service provided. Another topic that remains open at the time of writing is who would be competent
authorities that would agree on the minimum attributes per domain that should be added to eIDAS
SAML Attribute Profile for cross-border exchange.
26
CEF Digital (2018), “Overview of pre-notified and notified eID schemes under eIDAS”, available at:
https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+pre-notified+and+notified+eID+schemes+under+eIDAS [Last
accessed on 9 October 2018].
67/69
7 BIBLIOGRAPHY
[1] DG TAXUD, “UUM&DS System Architecture Document (UUM&DS-SAD),” 2017.
[2] EC, “https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+does+it+work+-

+eIDAS+solution,” [Online]. [Accessed March 2018].
[3] EC, “COMMISSION IMPLEMENTING DECISION (EU) 2015/296,” Official Journal of the
European Union, 2015.
[4] EP, “REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL,” Official Journal of the European Union, 2014.
[5] EC, “https://ec.europa.eu/digital-single-market/en/e-identification,” [Online]. [Accessed

2018].
[6] EC, “https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eID,” [Online]. [Accessed

March 2018].
[7] EC, “https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+Profile,” [Online].

[Accessed March 2018].
[8] EC, “https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Country+Overview+-+eID,”

[Online]. [Accessed March 2018].
[9] E. Commission, “Principles and guidance on eID interoperability for online platforms,”
[Online]. Available: https://ec.europa.eu/futurium/en/eidas-observatory/revised-draft-
principles-and-guidance-eid-interoperability-online-platforms. [Accessed Dec 2017].
[10] “https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/All+eID+services,” EC. [Online].
68/69
ANNEX I: ACRONYMS
Acronym Description
AP Attribute Provider
API Application Program Interface
BB Building Block
CEF Connecting Europe Facility
eID Electronic identification
eIDAS Electronic identification and trust services for electronic transactions
in the internal market
EIRA European Interoperability Reference Architecture
EC European Commission
EP European Parliament
EU European Union
ID Identifier
IdP Identity Provider
HEI Higher Education Institution
MDS eIDAS Minimum Data Set
MS Member State of EU
SAML Security Assertion Markup Language
SIS Student Information System
TLS Transport Layer Security
Table 8: Acronyms
69/69

D.06 Blueprint For Solution

Uploaded by

Copyright:

Available Formats

D.06 Blueprint For Solution

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D.06 Blueprint For Solution

Uploaded by

Copyright:

Available Formats

CEF EID BUILDING BLOCK FOR BANKING AND

Blueprint for solution (incl. sector-specific attributes)

Framework Contract SLG.AVT.DI0744501 (STIS IV Lot 3)

By the European Commission, Directorate General for Informatics.

1.1 Context ............................................................................................................................. 7

2.1 eID Building Block: A solution for cross-border identification ......................................... 11

2.3.1 National level ........................................................................................................... 12

3.1 eIDAS Technical Specifications...................................................................................... 15

3.1.3 Interoperability Architecture ..................................................................................... 15

4.1 Non-notified Identity Providers ....................................................................................... 19

4.1.1 Non-acceptance of non-notified Identity Providers ................................................. 20

4.2 Sector-specific attributes ................................................................................................ 31

4.2.1 Educational and Banking Attributes ........................................................................ 32

4.3 National IT infrastructure considerations ........................................................................ 35

4.3.1 Attribute Providers ................................................................................................... 35

4.4 Summary of the impact on eIDAS Technical Specifications .......................................... 38

5.1 Out-of-the-box eIDAS ..................................................................................................... 41

5.3.4 Integration scenarios ............................................................................................... 54

5.4 Implementation steps ..................................................................................................... 65

Figure 1: Notified vs non-notified IdPs ........................................................................................ 21

Table 1: Document structure ......................................................................................................... 9

In order to avoid fragmentation in the cross-border exchange of identification and authentication

The table below describes the structure of the document:

Annex I List of acronyms used in the document.

Table 1: Document structure

2.1 EID BUILDING BLOCK: A SOLUTION FOR CROSS-BORDER

2.2 THE UUM&DS PROJECT

2.3 BANKING AND EDUCATIONAL NEEDS

2.3.1 National level

3.1.3 Interoperability Architecture

3.1.4 SAML Attribute Profile

3.1.5 Message Format

Chapter 6 of the document includes examples of following messages:

 eIDAS Connector SAML-Metadata

- Related to the use of non-notified Identity Providers:

4.1 NON-NOTIFIED IDENTITY PROVIDERS

4.1.1 Non-acceptance of non-notified Identity Providers

Description of the challenge

Analysis of the Technical Specifications regarding this challenge

Overcoming the challenge

<xs:attribute name="nonNotifiedIdP" type="boolean" use="optional"/>

To reflect the proposed changes, updating the following documents is recommended:

- “eIDAS – Interoperability Architecture” (section 4, 5)

4.1.2 Acceptance of non-notified Identity Providers

Description of the challenge

Analysis of the Technical Specifications regarding this challenge

Overcoming the challenge

Updating the following documents in order to reflect this change is advised:

4.1.3 Multiple cross-border authentication services

Description of the challenge

Figure 3: Routing implications for non-merged nodes

Analysis of the Technical Specifications regarding this challenge

Overcoming the challenge

<xs:simpleType name=" NodeType">

4.1.4 One node for all Identity Providers (merged)

Description of the challenge

Overcoming the challenge

4.1.5 Technical Specifications constraints – MDS

Description of the challenge