European electronic identity and trust services
EU-identity, authentication, signature and trust services
A short youtube introduction (2014). As identity, authentication, signature and trust services
are rolled out as part of the Connecting Europe Facility (CEF), relevant information can be found at the
CEF wiki and at eIDAS Observatory.
EU legislation and political setting
All EU legislation is available from the EU Official Journal. Since 1 July 2013 the electronic edition of the OJ (e-OJ) is authentic and
produces legal effects, pursuant to Regulation 216/2013. The e-OJ bears an advanced electronic signature to ensure its authenticity, integrity and in-alterability. This electronic signature
can be verified using CheckLex.
An overview of key legislation in the field of identity and related trust services (both eIDAS and Schengen related) can be found here.
Political setting - DSM - the Digital Single Market
The EC Treaty puts freedom of establishment and freedom of provision of service forward. More particularly, the Services Directive (implemented by the end of 2009 – including remote aspects)
promotes an EU where operating governmental or business functions is facilitated by the use of ICT.
eGovernment is instrumental in supporting the single market, and the Council Conclusions on eGovernment (20 Nov. 2003, 14671/03) underline the
importance of interoperability as a political priority.
While there was an e-signature directive, there was no e-identity directive, because identity is considered by the Treaty as a Member State matter.
Widely diverging approaches have been adopted across the member states for National e-Identity (NeID), and as a consequence the current NeID’s are not
interoperable. Many organisations have today an identity solution in place, which is in the best case a stable foundation. However it will be requiring
technical evolution to cope with the requirements of the single market. Legal interoperability and certainty was created by the EU 1999/93 eSignature Directive,
replaced by EU 910/2014. Technical interoperability was established via STORK, STORK2 and eSENS.
Also, the EC supported other LSP (Large Scale Pilot) projects, often reliant upon electronic identity and signatures:
In 2012, the proposed regulation for electronic Trust Services (COM 2012 238) proposed a framework including notified identities.
In 2013, e-SENS (“Electronic Simple European Networked Services” )was launched as a new LSP within the ICT Policy Support Programme (ICT PSP),
under the Competitiveness and Innovation Framework Programme (CIP).
e-SENS developed an infrastructure for interoperable public services in Europe.
- SPOCS (Simple Procedures On-line for Cross- Border Services) uses the STORK solution for the cross border use of natural persons eID.
It also builds on document transport concepts, and used the Virtual Company Dossier (VCD) concept of PEPPOL for document containers and has generalized it into a container format for eDocuments (OCD) to package company information for transmission to Points of Single Contact in other countries.
- e-CODEX (e-Justice Communication via On-line Data Exchange) improves on deliverables from SPOCS and the other pilots in order to fulfil to improve the cross-border access of citizens and businesses to legal means in Europe as well as to improve the interoperability between legal authorities within the EU.
- epSOS (European patient Smart Open Services) addresses a service infrastructure that demonstrates cross-border interoperability between electronic health record systems in Europe.
- PEPPOL (Pan-European Public Procurement On-line) has developed and implemented technology standards for EU governmental public electronic procurement.
CEF eID community and cooperation network
CEF overview of cooperation network and documents
In 2014, EU 910/2014 was accepted by Parliament and Council as the eIDAS regulation, entering into force in 2016. Under eIDAS, a Member State:
In December 2016, Spain was the first country to complete CEF eID Conformity Testing.
In February 2017, Germany was the first country to notify the EC they intended to offer eID cross-border services compliant to eIDAS.
- may opt to notify the Commission about its eID scheme
- has to recognise eID's notified by the other Member States (regardless whether it notified or did not notify its own eID scheme)
EU Citizens' perspective
EU-wide identity and authentication has traditionally been addressed by the Member States. Some countries have a central national register of citizens and issue
an ID-card, which in some countries contains electronic functionality. Such an electronic ID-card may include an electronic signature function.
Some countries prefer to use the driving license as ID, complemented by a card for those that don't drive. An identity card typically serves the purpose of
allowing the holder to demonstrate his/her identity, and it usually also acts as a travel document. As a travel document, it is not as widely accepted
as a passport.
The security of travel documents and passports issued by Member State is defined in Council Regulation 2252/2004 on the specifications on the standards for security features and
biometrics in passports and travel documents issued by Member States. It has been amended by Commission Decision 18 June 2006.
The PRADO website (Public Register of Authentication Documents On-line) from the European Consillium gives a good overview.
FADO (FAlsified Documents Online) is similar but not in the public domain.
In 1999, Directive EC/1999/93 introduced electronic signatures but did not make explicit specification on the signatory since identity was the competence of the Member States rather
than of the Commission.
The e-Signature Directive introduced legal equivalence between traditional and electronic signatures of natural persons, on the condition that certain
requirements were met (advanced electronic signature/qualified certificate/secure signature creation device).
CEN TC 224 defined technical standards for the ECC (European Citizen Card - CEN TS 15480) but its uptake was limited.
In 2009 under the Services Directive, a Decision set out measures to facilitate the use of electronic procedures through the ‘points of single contact’.
To enhance cross-border use of electronic signatures this included the obligation for Member States to establish and publish their Trusted List of supervised/accredited certification
service providers issuing qualified certificates to the public. However they can include also other certification service providers.
To facilitate access to the trusted lists of all Member States, the EC publishes the 'list of trusted lists (LOTL)' with links to the national 'trusted lists'.
IAS study for a successor to the e-Signature Directive
The European Commission launched the Identification, Authentication and Signature (IAS) feasibility study in 2011. The project was executed by a Consortium in which I took part.
Deliverables and background information are available on the IAS project website.
The official deliverable is available since September 2013 on the digital agenda website.
In parallel to the IAS study, many projects further advanced IAS, including STORK/STORK2, DSS and PEPPOL.
Proposal for a successor to the e-Signature Directive
In 2012 a new approach was formalised in the Commission's proposal EC COM 2012 238, which included two main pillars: identity/authentication and signatures/related services.
While a European Citizen Card sounds promising from a technical perspective, the diverging approaches of the Member States led to a voluntary notification scheme in the proposal.
eIDAS Regulation on electronic IDentity, Authentication, Signatures and related trust services
In the context of the Digital Agenda, the proposal was further adapted and in August 2014, the eIDAS regulation
was published in the OJ. It is referred to as "Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC". It can be found in the OJ L 257 of 28 Aug 2014.
The regulation significantly expanded the scope of its predecessor, by introducing a formal pillar that addresses electronic identity/authentication.
Furthermore electronic signatures for legal persons (e-seals) were introduced, and a range of trust services well beyond electronic signature.
The 'list of trusted lists (LOTL)', as per the technical format defined in ETSI TS 102 231(replaced by ETSI TS 119 612 in 2013) is continued. It can be observed that
while the objective of the trusted lists is supporting eSignature validation policies, they provide a degree of information on the signatory's identity.
eIDAS as influencer
eIDAS plays a role in a.o.
In April 2014, the eIDAS token specification
was published by the German and French IT security agencies BSI and ANSSI, supported by European industry partners.
It allows the development of token-based solutions for electronic identification, authentication and signatures that are directly interoperable, without
the need of translation via proxies. Example implementations are the German ID card or the German Residence Permit.
- PSD2 (EU 2015/2366) - RTS on SCA - Commission Delegated Regulation 2018/389
- AML5 (EU 2018/843) - finally adopted on 14/5/2018 by EP
- Company law - proposal to amend Directive (EU) 2017/1132 adopted 25/04/2018
- Fighting fake news - COM (2018) 236 final adopted 26/04/2018
- Regulation on Single Digital Gateway (EU 2018/1724) - cross-border Only-Once
- Company law - proposal to amend EU 2017/1132 adopte by EC 25/4/2018 regarding the use of digital tools and processes in company law
- GDPR compliance - data minimisation - use of trusted attributes, credentials and entitlements
- Audiovisual Media Service Directive - protection of minors on-line - age verification, parent consent
- Tackling online disinformation/fake news - COM(2018) 236 adopted 26/4/2018
The EC launched a roadmap for the future of eIDAS.
Public consultation, resulting in feedback.
Electronic Identity and Authentication - STORK/STORK2/eSENS
The aim of the STORK (Secure idenTity acrOss boRders linKed) project is to establish a European eID Interoperability Platform to facilitate citizens'e-relations across borders, relying on their national eID.
It should be seen against a background where many Member States have an established NeID solution, which are however not necessarily interoperable or technically compatible. STORK ran from 2008 until 2011.
It included six pilots:
The aim of STORK2 is to further enable the Digital Single Market, facilitate cross border eGovernment applications and reduce administrative burdens for companies and individuals wishing to perform services
across borders. It ran from 2012 to 2015. After STORK2, the eSENS project continued the elaboration and deployment of eIDAS building blocks.
- Cross-border Authentication for electronic services
- Student Mobility
- Change of Address
- ECAS Integration
STORK and STORK 2
STORK aimed at demonstrating the possibility of an EU-wide interoperable e-identity and access mechanism. As such, STORK is the common ground for other EU pilots,
such as PEPPOL (e-procurement).
STORK was a 3 year project to develop and test common specifications for secure interoperability and mutual recognition of NeID between participating countries.
Given the different solutions chosen by the MS when implementing their NeIDs, this is indeed a challenge.
STORK proposed to combine trusted ‘proxy servers’ with ‘client and server middleware’, making use of current de-facto standard protocols such as SAML.
Integration of STORK solutions with existing IAM platforms demonstrated benefits for multiple categories, namely users, application owners and IT departments.
STORK 2 is the successor to STORK, further elaborating the original ideas into pilots addressing:
- Simplification and convenience for End users, with a unified approach allowing to applications
- Non-pre-registered users from within a Member State may authenticate to STORKified applications
- Enablement of an additional highly secure authentication mechanism, resulting in increased trust
- Automatically further enlarged end user bases by increasing the number of users that will transparently gain access without the need for explicitly registering;
- Decreased total cost of ownership for the organisation or government agency
- eLearning & Academic Qualifications
- Public Services for Business
STORK defined an interoperability architecture that can be instantiated in two different ways: a centralised implementation with PEPS (Pan-European Proxy Servers), and a decentralised implementation
with Middleware. A majority of countries selected the PEPS implementation, while Germany and Austria opted for the MW model.
In the PEPS model, a user connects to a cross-border Service Provider (SP), which forwards the authentication query to a PEPS (since the user is registered in another country than
the SP's country). However, Germany and Austria established a model where middleware, which has to reside on the citizen
platform takes care of this forwarding. This created a common model with four architectural elements:
Middleware may also be implemented on the server-side (then it's called SPWare), and marshalled to the citizen's platform at execution time. By implementing middleware on a PEPS-server, a V-IdP
(virtual IdP) is created.
- a NIP (National Identity Provider), implemented in each Member State, provides identity and authentication information about its citizen and other persons registered within his domain
- an SP (Service Provider) delivers services to an end-user such as a citizen
- a PEPS (Pan-European Proxy Server) is implemented in each Member State that desires so, and forwards authentication queries coming from an SP when the SP has to authenticate a non-local end-user
- MW (MiddleWare) that executes on the citizen's platform. In the STORK architecture, MW talks directly to the SP, without any central server
Successor to the STORK architecture
Under the CEF program, the eIDAS node software
was created and published as Open Source, specified as a
eIDAS node profile, consisting of:
The eIDAS node must contain a connector, which is mandatory for mutual recognition. The connector provides access for local users towards notified eID schemes.
The eIDAS node may optionally contain a proxy server, which provides access to the Member State's own eID services in case those were notified.
- eIDAS Interoperability Architecture
- Crypto Requirements for the eIDAS Interoperability Framework
- eIDAS Message Format
- eIDAS SAML Attribute Profile
From STORK/STORK2 to eSENS (Electronic Simple European Networked Services)
The eSENS project is the continuation of the LSPs, and a.o. provides a migration path from STORK to eIDAS.
It's coordinated by the Ministry of Justice NRW, Germany. At the University of Pireus there's a wiki about the implementation.
CIR 2015/1501 was created as the technical specification for eIDAS interoperability. Within eSens an eIDAS profile has been defined, and a sample implementation of an
eIDAS node was created as a CEF building block.
The goal was to ensure cross border recognition and e-identification validation that meets the requirements set for
The 'eIDAS-Network' consists of eIDAS-Nodes, which can either request (via an eIDAS-Connector) or provide (via an eIDAS-Service)
a cross-border authentication. In the case of the eIDAS-Service Node, this may be operated in two different ways:
Furthermore, eSENS created an adaptor to achieve interoperability of existing STORK/eSENS infrastructure with eIDAS nodes.
This enables countries with STORK 2.0 infrastructure currently linked to eID services to connect to the eIDAS network.
The connector consists of a regular eIDAS node and a plugin that is able to convert in both ways the authentication requests/responses from
eIDAS format to STORK 2.0 format. The plugin also handles mappings of attributes between the STORK 2.0 SAML profile and the eIDAS node SAML profile.
eIDAS Technical Specification
In September 2015, version 0.9 of the specifications for the eIDAS node was published on
The specification has been developed through member state collaboration in a technical sub-committee of the eIDAS Expert Group.
The role of the Commission was to facilitate and support this process and to provide a sample implementation of the technical
specifications which member states are free to adopt as an "off the shelf" implementation should they wish to do so.
- eIDAS-Proxy-Service: an eIDAS-Service operated by the Sending Member State and providing personal identification data
- eIDAS-Middleware-Service: an eIDAS-Service running Middleware provided by the Sending Member State, operated by the Receiving Member State and providing personal identification data.
Electronic identity in practice
To appreciate the challenges of electronic identity, one can e.g. compare the following situations:
Practical implementations are based upon SAML v2 'Holder of Key' Profile.
Relevant information can be found at:
The ESPOCS project builds upon STORK and PEPPOL.
The state of notification of Member States and the status of eIDAS-Node implementation is available at the CEF wiki.
An eIDAS test and simulation tool was launched in 2018.
The SSI eIDAS bridge provides eIDAS functionality to SSI.
- The Austrian NeID provides IASCS: Identification, Authentication, Signature, Encryption and Secure Storage (digital safebox)
- The Belgian NeID provides IAS: Identification, Authentication and Signature (so no encryption, no storage)
- The United Kingdom provides no identity cards
- The Netherlands historically prefer to use their driving license as an identity document, but do also issue identity cards
While the political and organisational challenges surrounding eIDAS and STORK are impressive, there is also a long list of influencers from various angles.
To mention just a few:
- ECC – the European Citizen Card, developed by CEN TC 224 WG 15, published as CEN TS 15480, multipart standard (Physical card interface, Logical Card Interface,
Interoperability and Middleware (aligned on ISO 24727), and Card Profiles and issuance
- CEN ISSS - MMUSST (Multi-application MUlti-issuer citizen card Scheme STandardisation)
- ISO/IEC 24727 - a set of programming interfaces for interactions between integrated circuit cards (ICCs) and external applications to
include generic services for multi-sector use, conform to ISO/IEC 7816-4
- SAML v2: the XML-based standard for exchanging authentication and authorization data between an identity provider (producer of assertions) and a service provider
- the WS-Security 1.1 OASIS standard, made up of:
- WS-Security Core Specification 1.1
- Username Token Profile 1.1
- X.509 Token Profile 1.1
- SAML Token profile 1.1
- Kerberos Token Profile 1.1
- Rights Expression Language (REL) Token Profile 1.1
- SOAP with Attachments (SWA) Profile 1.1
- Microsoft's legacy InfoCard (Windows Cardspace) - the Microsoft .NET Framework component to uniquely authenticate Windows Vista users as required by the
Identity Metasystem. This evolved towards the “claims” paradigm (fundamentally based on the patents acquired from Stephen Brands).
- SAP - collaboration between SAP and solution providers of federated identity management such as PING Identity. Introduction of SAP's NetWeaver
Identity Manager, with migration underway towards SAML v2 protocols
These standards are defined by the European Standards Organisations (ESO), CEN, CENELEC and ETSI. Each ESO has its specialisation, resulting from its history.
ETSI is focused on telecommunication standards, while CEN is more focused on devices and smart cards.
ETSI's Technical Committee ESI
Its activities on electronic signatures are coordinated by Technical Committee (TC) Electronic Signatures and Infrastructures (ESI).
The ESI TC ongoing and
past activities are available, together with the drafts.
In 2013, EU e-signature standardisation mandate m460 was given from the EC to CEN and ETSI to establish a rationalised framework for electronic signature
ETSI's ESI deals with electronic signatures (signature format, certificates, CSPs, trusted list) and ancillary services (Registered email, Time-Stamping,
Long-term document preservation). This includes signature creation and verification based on advanced electronic signatures such as CAdES
(CMS Advanced Electronic Signatures), XAdES (XML Advanced Electronic Signatures), PAdES (PDF Advanced Electronic Signatures), and ASiC (Associated Signature Container).
ESI also deals with cryptographic suites, trust service providers supporting e-signatures (e.g. certification authorities, time-stamping authorities), trust application providers (e.g. Registered Emails (REM) providers,
Information preservation providers), and Trust-service Status List (TSL).
TSL is defined to enhance the confidence of parties relying on certificates or other services related to electronic signatures since they have access to information
that will allow them to know whether a given Trust Service Provider was operating under the approval of any recognized scheme at the time of providing their services and of any dependent transaction that took place.
Information for TSPs and CABs can be found at the ESI TSP page
Under m460, various ETSI Special Task Forces (STF) were established.
An overview is provided in ETSI TR 119 000. Furthermore, ETSI defines URIs in different fields, including for Trusted Lists. ETSI also makes a signature conformance checker available.
- STF425 covers the rationalised framework for electronic signature services in
line with the standardisation mandate m460
- STF-457 covers all coordination aspects
- STF-458 covers:
- Signature creation and validation: This includes standards for procedures for signature creation and validation, advanced electronic signature formats (CAdES, XAdES, PAdES and ASiC), advanced electronic signatures in mobile environments, and signature policies.
- Trust Service Providers (TSP) supporting electronic signatures: This includes standards for policy requirements for TSP issuing certificates (qualified, general public key, TLS/SSL) TSP issuing time-stamps, certificate and time-stamp formats, and TSP conformity assessment.
- STF-459 covers:
- Registered Electronic Delivery
- Testing interoperability and conformance
The European Committee for Standardisation CEN collaborates with ETSI in m460. Within CEN, various TC's cover
different topics. Particularly, within TC 224 (Personal identification and related personal devices with secure element, systems, operations and privacy
in a multi sectorial environment), Work Groups adress following topics:
The status of CEN standards can be retrieved on their standards website.
- WG 6 User interface
- WG 11 Transport applications
- WG 15 European citizen card
- WG 16 Application Interface for smart cards used as Secure Signature Creation Devices
- WG 17 Protection Profiles in the context of SSCD
- WG 18 Biometrics
ETSI and CEN naming convention for electronic signature standards
Standard names are structured as DD L19 xxx-z, where 19 indicates the series of standardisation documents related to eSignatures.
DD indicates the deliverable type in the standardisation process (SR, TS, TR and EN).
L when set to 4: identifies a CEN deliverable.
When set to 0, 1, 2, or 3: identifies an ETSI deliverable and the type of deliverable in the standardisation process:
IDABC's European Electronic Signature Standardisation Initiative (EESSI) can be considered as one of the predecessors of the formal ETSI TC ESI. It is finished now.
Also, the EU eSignature standards website (an initiative of DG CNECT - ESO) provides a good introduction to the topic.
- 019 for ETSI published Special Reports (SR)
- 119 for ETSI published Technical Specification (TS) and Technical Report (TR)
- 219 for ETSI published Standard (ES) and ETSI Guide (EG)
- 319 for ETSI published European Norm (EN)
- 419 for CEN published Technical Specification (TS) or European Norm (EN)
Electronic Identity and Authentication - ePassports
Third Country Nationals visiting Europe
Access to Europe for Third Country Nationals (TCNs) may require a valid passport and visa.
Most if not all countries issue passports as per the ICAO standards.
Many passports support electronic identification and authentication of the bearer.
However, they do not offer electronic signature capability.
In 2006, the EU established the Schengen zone to manage TCNs travel to Europe.
Access is regulated according to the Schengen Border Code (SBC).
Europe established the Schengen Information System (SIS) and Visa Information System (VIS) for the purpose of enforcing the SBC.
The Smart Borders initiative from DG HOME aims to faciliate TCNs entry and exit to the Schengen zone. I participated in the
technical study in 2014, leading
up to the 2015 pilot. Also available are the study's executive summary and
the cost study.
TCNs that desire to reside in Europe for a longer period may apply for a residence permit. A uniform European format for residence permits was defined in 2002.
Such a residence permit may include electronic signature capability.
In 2008 the requirement was added to use a photograph and two fingerprints taken flat and digitally captured.
The interoperability of ePassports (an implementation of electronic machine readable travel documents) is facilitated through the International Civil Aviation Authority (ICAO),
particularly their set of ICAO 9303 documents.
Generations of ePassports
Currently their are three generations of ePassports:
- First generation (2004) with Facial Image and BAC (symmetrical). Introduced by EU Council’s December 2004 Regulation 2252/2004.
Since August 2006, all EU MSs have used this technology and issued passports accordingly.
- Second generation (2009), triggered by the EU request in 2006 to include Fingerprint biometric data.
Extended Access Control (EAC), was introduced to protect this data. EAC restricts access to fingerprints and iris to authorized parties only and adds
functionality to verify the authenticity of the chip (chip authentication) and the reading device (terminal authentication).
EAC is based on an asymmetric protocol and uses stronger encryption than BAC.
- Third generation (since December 2014), introducing Supplemental Access Control (SAC), which aims to overcome the limitations of BAC.
It was observed that the randomness of the BAC keys (which are dependent on the MRZ) no longer sustains modern threats. SAC is based on the PACE v2 protocol, and makes use of DH and ECC.
Regulatory and related
- Information assurance and crypto products
- PRADO website (Public Register of Authentication Documents On-line)
- FADO website FADO (False and Authentic Documents Online) is similar to PRADO but not in the public domain
- SOG-IS Senior Officials Group Information Systems Security - Protection Profiles for Smart Cards, SCDs, tachograph, JavaCard, SIM
Identity, trust and interoperability
LOTL - List of Trusted Lists
Trust anchors and trust lists emerged from IETF work, including
SIS, VIS, EuroDac
- DG HOME - Schengen, visa, ...
- DG HOME/JRC - Schengen Masterlist
- EU - SIS - Schengen Information System
- EU - VIS - Visa Information System - created under DG HOME regulation,operated by eu-Lisa
- EU - EuroDac - immigration and asylum seekers (supervised by a.o. EDPS)
EC LSPs (Large Scale Pilots)
- e-Sens - the continuation of the LSPs - also for eID
- STORK 2 - strictly speaking not a LSP but a 3-year EU Co-funded Project
- STORK - Secure idenTity acrOss boRders linked
- EU LSP - epSOS
- EU LSP - Peppol - eProcurement
- EU LSP - SPOCS - Simple Procedures Online for Cross- Border Services
- EU LSP - eCodex - improve the cross-border access of citizens and businesses to legal means in Europe
- Horizon 2020 FutureTrust project
- IAS project
- Gini-SA - Global Identity Networking of Individuals - Support Action
- Openecard - by ecsec - see also their Skidentity service
- client side implementation of the eCard-API-Framework (BSI TR-03112) and related international standards such as ISO/IEC 24727
- the eCard-API-Framework defines 4 layers (Terminal-Layer, Service-Access-Layer, Identity-Layer and Application-Layer)
- functionality is specified in XML-structures
- PRIME - FP6 project on Privacy enhancing identity management
- PrimeLife - FP7 continuation of PRIME
- FP7 - FutureID - 2012-2015
- ABC4Trust 2010-2014
- Tas3 - Trusted Architecture for Securely Shared Services - 2008-2011
- Modinis - 2005-2007
- FIDIS - FP6 NOE (Network of Excellence) - Future of Identity in Information Society - 2004-2009
CEF Building Blocks and related Components
eID - Identity
Dashboard and Toolbox March 2021
Digital Signature Server capability has originally been started by DG ENTR, and later integrated in Joinup and CEF.
DSS (Digital Signature Services) is an open-source software library for electronic signature creation and validation. DSS supports the creation and verification of interoperable and secure electronic signatures in line with European legislation. In particular, DSS aims to follow the eIDAS Regulation and related standards closely .
DSS can be re-used in an IT solution for electronic signatures to ensure that signatures are created and verified in line with European legislation and standards. DSS allows re-use in a variety of different ways: in an applet, in a stand-alone application or in a server application. DSS can also be used as a reference implementation for IT solutions which do not directly re-use it.
Information can be found at CEF DSS,
Joinup and source code at github.
- EU Joinup - DSS - Digital Signature Server
- EU Joinup - DSS - software and documentation
- DSS demo from ARHS
- Pilot for Internationalisation of Trust Services - DSS demo and TL extension
- Pilot aims to illustrate how the mutual recognition between the EU and a 3rd country of the QTSP and the QTSs they provide could be implemented under Article 14 of eIDAS.
The pilot simulates a test LOTL that points to the trusted lists referred in the current LOTL and also points to a test 3rd country trusted list as a result of the mutual recognition
- EU Joinup - TLM - Trust List Manager - The TLManager allows the creation and maintenance of TLs in accordance with Commission Decision 2009/767/EC, as amended by Decision 2010/425/EU
- Github TLM- Trust List Manager Robert Bielecki
eArchiving technical specifications describe in detail the interoperable and open formats for packaging data and metadata
for transfer to archival repositories (E-ARK SIP), for the preservation over extended periods (E-ARK AIP) and
the reuse of archived content (E-ARK DIP).
The most common principles and requirements are presented separately within the E-ARK Common Specification for Information Packages.
Further details about eArchiving specifications are available at http://www.dilcis.eu.
- DTCE - Digital Trust and Compliance Europe
Country overview (subjective and incomplete)
See also local files:
- AT - Digital Austria
- AT - Digital Austria - reference site - pointer to e.g. Portalverbund (authentication/authorisation)
- AT - IdentityBlog Portalverbund - Rainer Hoerbe
- AT - DigitalCity.Wien
- AT - Staatsdruckerei - traditional personalausweis, passport, driving licence etc
- AT - MIA - government documents app (id, driving license, etc) - from Staatsdruckerei
- AT - Austrian Burgerkarte (smartcard/mobile phone) - 'virtueller Ausweis' from A-SIT, voluntary use
- AT - Austrian Rundfunk und Telekom Regulierungs GMBH
- AT - Austrian Rundfunk und Telekom Regulierungs GMBH
- AT - Austrian regulator/TL
- AT - Reinhart Posch
- AT IAIK - Austrian Burgerkarte in OpenSource
- AT - MOA - MOA ID (modul identification), SP (signaturprufung) and SS (serversignatur)
- AT - PDF-AS - XML technology for pdf signing
- AT - MOCCA - modular opensource citizen card
- AT - origin of MOCCA
- AT - Zustelldienst - registered e-delivery
- AT - A-SIT - Herbert Leitold et al
- AT - A-SIT - confirmation (corresponds to product certification of e.g. QSCD) and evaluation (corresponds
on conformity assessment of TSP as CAB)
- AT - A-TRUST - handy signature, eTresor, Signaturbox, ...
- Handy signature:
- intended to be remote signature, independent from telco
- always combination of PC with browser and mobile phone
- end user has keypair stored in A-TRUST hsm
- mobile is used as authenticator against hsm
- Generation 1: end user visits service provider, gets redirected to A-TRUST server that sends SMS TAN, user enters TAN in browser, TAN gets
forwarded to A-TRUST, who generates a SAML logon token, signed with the user's private key from the hsm, and token gets forwarded to service provider
- Generation 2: end user has additional keypair stored in app on mobile, SMS TAN is replaced by challenge/response between app and A-TRUST server
- AT - Stuzza - operates e-identification service for all Austrian banks
See also local files:
- BE - eid.belgium.be
- BE - sign.belgium.be
- BE - mysocialsecurity.be
- BE - Rijksregister - EID - March 20, 2004, Belgian council of Ministers decided for national roll-out
- BE - FEDICT - projects - EID - free toolkits (GUI/visualisation/PKCS#11 and authentication proxy)
- BE - youth site - "voor jongeren"
- BE - certificate status check/CRL - repository.eid.belgium.be
- BE - certs.eid.belgium.be
- BE - ocsp.eid.belgium.be
- BE - ldap.eid.belgium.be port 389 base dc=eid, dc=belgium, dc=be
- BE - CSAM - identity verification for FS and Insurance
- Digital keys. Authentication via: eID, ITSME, userid/password+SMS, userid/password.
- Access of access managers - from Social Security - Rijksdienst voor Sociale Zekerheid - www.socialsecurity.be
- WV (Wettelijk Vertegenwoordiger) persoon die een wettelijke functie uitoefent binnen de onderneming en als zodanig gekend is in de Kruispuntbank van ondernemingen (KBO)
kan zelf Hoofdtoegangsbeheerder zijn, of iemand aanduiden.
- Hoofdtoegangsbeheerder kan lokale toegangsbeheerder aanduiden, die op zijn beurt gebruikers kan authoriseren
- Mandates. Het Self Service Mandatensysteem (SSM) is een elektronische toepassing van de publieke sector die de
volmachtgever en volmachthouder de mogelijkheid geeft om met behulp van de eID en pincode (of Token) een mandaat aan
te maken of stop te zetten.
- Social security mandates - for employers only, after registration on socialsecurity.be
- Fiscal mandates (FODfin) - TaxOnWeb, InterVAT etc
- Healthcare mandates
- Flemish mandates
- BE - IAMapps - rolemanagement
- Overview of allocated roles
- BE - Identifin - identity verification for FS and Insurance
- BE - Identifin - test
- BE - ITSME, Belgian Mobile ID
- Launched May 2017, Belgian government recognised 2018, notified jointly with FAS as ITSME/FAS and classified as eIDAS 'high' in 2019
- BMID operates the authentication procedure and passes the National Register number via the Federal Authentication Service
(FAS) to BOSA. The FAS creates the Minimum Data Set of person identification data based on this authentication
- Used by 2 million Belgians in 2020
- As from 2020 using LuxTrust as identity provider, onboarding with eID, bank card, passport, driving license
- BE - FAS IdP
- BE - FAS eIDAS node
- BE - Connective.eu
- BE - Digitaal Aangetekend
- BE - www.godot.be
- BE - Microsoft's EID site
- BE - EID-shop (Certipost and Zetes)
- BE - D-Loket (Certipost and D-soft)
- BE - Signer.be - the eID company
- BE - ID for horses (no joke)
- BE - ID for donkeys (no joke either)
- BE/VL - Vlaamse Overheid Certificaten Beheer
Czechia’s national eID scheme allows Czech citizens to digitally prove their identity online and access eGovernment and private sector services
in two ways. As of July 2018, they can use eID cards, or alternatively with a combination of username, password, and one-time codes received on their mobile
phone via SMS. The Czech scheme has been notified with a LOA of High.
The ePA (Elektronischer Personalausweis) was initiated by the Federal Cabinet on July 23, 2008, and introduced by the BMI (Bundesministerium des Innern) in 2010.
The ePA introduced the eCard-API (BSI TR-03112) for interfacing.
It was the first European eID with contactless chip, and with mutual authentication card/terminal.
It featured cryptographic privacy enhanced protocols (BSI TR3110).
The government funded security kits containg a free eID client (AusweisApp) for computers, and a free (or discounted) card reader.
The AusweisApp was to support all major platforms, interfaces and smart cards as per the eCard API framework.
As a consequence of some limitations of the AusweisApp in practice, alternatives were developed.
These include proprietary eID clients (cf. by Ageto and bos) as well as the Open Source Open eCard App. This was
certified according to BSI TR-03124 in 2019 as the world's first Open Source eID kernel. It is used e.g. by the German Post as PostIdent.
Other eGovernment components include:
- eTax: ELSTER: Elektronische Steuererklarung
- Electronic Remuneration statement: ELENA: Elektronischer Entgeltnachweis
- eDA: Electronischer Dienstausweis
- eGK: Electronischer Gesundheitskarte
- ePass: Elektronische Reisepass
There is also:
- DE - Open eCard app - the open source underlying SkiDentity
- The BSI certified the world's first Open Source eID kernel based on the Open eCard, according to BSI TR-03124 in 2019
- Teil 1 der Technische Richtlinie BSI TR-03124 spezifiziert die Client-Software für die Online Authentisierung basierend auf Extended Access Control Version 2 (EAC2) zwischen Dienstanbietern und eID-Karten wie dem neuen Personalausweis oder dem elektronischen Aufenthaltstitel.
Die Server-Seite wird durch die BSI TR-03130 spezifiziert
- Teil 2: Conformance Test Specification spezifiziert Konformitätstests für eID-Clients gemäß BSI TR-03124-1
- DE - SkiDentity - Detlef and Tina Huehnlein's cloud-based identity service
- offers a cloud-based identity, cryptographically secured and derived from an electronic identity document (eID)
- can e.g. be created by an electronic identification procedure with the German eID (Personalausweis)
- and then transmitted to any smartphone at the user's request
- to be used afterwards for pseudonymous authentication or mobile identification
- DE - Authade - replace the cardreader by the mobile phone
- DE - Bundesdruckerei
- DE - Bundesdruckerei - Sign-me
- DE - Verimi - DIPP Gmbh - Consortium Deutsche Bank, Deutsche Telekom, Axel Springer, Daimler, Lufthansa, ...
- DE - YES
- Sparkassen und Volks- und Raiffeisenbanken - summer 2019
- ist Europas erstes Identity Scheme für Banken und deren Kunden und bietet digitale Identifizierung und Online-Vertragsabschlüsse auf Basis der EU-Richtlinien Payment Services Directive 2 (PSD2) und eIDAS-Verordnung über elektronische Identifizierung und Vertrauensdienste an
- DE - TC Trustcenter GMBH (acquired by Symantec)
- DE - Rohde and Schwarz - HSMs for eID servers
- DE - EasyPass - ABC gates
- GR - EETT Supervisory Authority
- GR - Harica
- funded by Academic Network (GUnet), a non-profit civil company
- members are all the Higher Education and Academic Institutions of Greece
- this GUnet service, referred to as the Hellenic Academic and Research Institutions Certification Authority (HARICA),
is operated by the IT Center of Aristotle University of Thessaloniki and acts as a QTSP
Italy’s Carta di Identità elettronica (CIE) allows Italian citizens to prove their identity online and access services.
It has been notified with a LOA of High.
The CIE is available for both Italian citizens and official residents. It's an RFID card.
On a computer authentication is with card-reader and PIN, on a NFC-enabled device, the card must be presented and the PIN entered.
eIDAS notification: first for business (not for citizens)
The Netherlands’ 'Trust Framework for Electronic Identification' is a set of standards, agreements and provisions for authorised access to digital services.
It has a citizen domain Idensys and a business domain eHerkenning.
In September 2019, eHerkenning became the first ever notified scheme for legal persons under eIDAS.
It has been notified at LOAs Substantial and High.
Representatives of business or public services that received a specific authorisation use it to access online services on behalf of their organisation
and manage their transactions with the government. They can use a login token, previously acquired from a number of accredited service providers.
Tokens can take the form of a name/password, texting, phone, one time password, or certificate.
The scheme is a public-private partnership between the Ministry of the Interior and a series of accredited suppliers in charge of mean issuance,
authentication provision, authorisation registration and eRecognition brokering:
The domain for citizens, known as Idensys, is not part of the notification.
- Accredited suppliers verify the identity of the organisation's employee and issue log-in resources.
- Authentication providers authenticate the persons that want to log-in to a service using eHerkenning.
- Authorisation registers record and maintain the list of authorisations and privileges of each users,
acting under the instructions of a legal representative of the organisation.
- eRecognition brokers are responsible for the interface between the eHerkenning network and the service providers.
- NL - RVIG - Rijksdienst voor Identiteitsgegevens
- NL - RVIG/BRP - Basis Registratie Personen -
Het burgerservicenummer (BSN) is een uniek persoonsnummer voor iedereen die ingeschreven staat in de Basisregistratie Personen (BRP)
- 'Free the BSN'
- NL - RVIG/SSI - self-sovereign-identity
- NL - Logius - MinBZK
- NL - Logius - PKIOverheid
- root is stamcertificaat ‘Staat der Nederlanden Root CA’, waarvoor de Nederlandse overheid verantwoordelijk is
- 2 types of certificates: personal (USB token) and service (SSL)
- 5 TSPs: Cleverbase, Digidentity, ESG, KPN and QuoVadis
- NL - MinEZ - PEPS
Two stelsels (frameworks): eherkenning (legal persons) & idensys (citizens)
Stelsel eherkenning (legal persons)
Stelsel idensys (citizens)
- NL - Idensys - PPP identity framework (legacy name: eID Stelsel.nl), governance: Ministry of Interior, Ministry of Royal Relations and Economic Affairs, execution: Logius
- NL public sector - DigiD.nl- userid and password, sms, app
- NL public sector - Mijn.DigiD.nl
- NL public sector - Burgerpin - DigiD (NAV)
- NL public sector - DigiD's open source roots - also available via www.osor.eu
- NL - iDIN - identification by Dutch banks
- NL - BVN - source of iDIN (Betaalvereniging Nederland)
- NL private sector - Connectis - identity service provider
- NL private sector - Digidentity.nl - private sector IdP
- NL academisch - IRMA card - 'I Reveal My Attributes' - an initiative from Radbout, Surfnet, TNO, PÏ.lab
- NL - OpenidPlus
- NL - Surf.nl - Higher Education/Research (surfnet, surfmarket, surfsara, surfshare)
Transactiemonitoring - fraude herkenning
- TMNL.nl - financial transaction monitoring
- PO - ePuap Electronic Platform of Public Administration Services,
- includes Profil Zaufany (Trusted Profile), which enables electronic filing with legal effect without the need to use a qualified signature and SAML-based single sign-on mechanism, which enables the same ePUAP account to log on to websites of service providers
- followed by ePUPA2
- PO - ePuap login page
- SE - Swedish eIDAS implementation
- SE - Swedish eID card
- SE - Bankid - Established in 2003, approximately 6.5 million users in 2015. BankID is an advanced signature and a signature made with a BankID is legally binding.
Available on smart card, soft certificate as well as mobile phone.
The customer’s identification is guaranteed by the bank issuing the BankID. Includes Danske Bank, ICA Banken, Ikano Bank, Länsförsäkringar Bank, Nordea, SEB, Skandiabanken, Sparbanken Syd, Sparbanken Öresund, Svenska Handelsbanken, Swedbank and Ålandsbanken
- SE - ZealID
- As a licensed Account Information Service Provider under PSD2 we ask the user to authenticate to a trusted account and share their data with us.
A ministerial department, leads on immigration and passports, drugs policy, crime policy, counter-terrorism, and policing
A ministerial department supporting the Prime Minister
- UK - tScheme - including profiles for
- Base Approval Profile - tSd 0111
- Approval Profile for Registration Services - tSd0042
- Approval Profile for a Certification Authority [[QC: issuing Qualified Certificates]] - tSd 0102
- Approval Profile for Signing Key Pair Management - tSd 0103
- Approval Profile for Certificate Generation - tSd 0104
- Approval Profile for Certificate Dissemination - tSd 0105
- Approval Profile for Certificate Status Management - tSd 0106
- Approval Profile for Certificate Status Validation - tSd 0107
- Profile for Identity Registration (tSd0108)
- Profile for Credential Validation (tSd0109)
- Profile for Attribute Registration (tSd0110)
- Profile for an Identity Provider (tSd0112)
- Profile for Credential Management (tSd0113)
Signature and validation
Trusted Repositories - Archiving