New APIs for the eIDAS-Ecosystem

Detlef Hühnlein, Ulrike Korte, Andreas Kühne, Andrea Röck


OASIS and ETSI have developed Application Programming Interfaces (API) for the generation, validation and long-term preservation of signatures, seals, time-stamps and evidence records, which provide the foundation for the development of a comprehensive “eIDAS-API”.

The eIDAS-Regulation, which has been fully applicable since July 2016, opened numerous new possibilities for the trustworthy digitalization of business processes in industry and administration. To put these opportunities into practice, the standardisation committees OASIS DSS-X and ETSI ESI have developed standards for the generation, validation, and long-term preservation of signatures, seals, time-stamps and evidence records. This blog post provides a compact overview of the recently created APIs and provides an outlook on possible future developments.

Introduction

Regulation (EU) No 910/2014 of the European Parliament and 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, which is commonly known as the “eIDAS Regulation”, aims at increasing the trust and efficiency of electronic transactions in Europe. This regulation has added numerous new trust services and aspects of electronic identification (eID) to the existing European framework for electronic signatures and time-stamps. In addition to the remote signature mentioned in recital (52), services for the validation and long-term preservation of signatures and seals have been included in Articles 33, 34 and 40 of the eIDAS-Regulation. In order to facilitate the practical use of these new trust services in an interoperable way and to provide a solid foundation for a prosperous and sustainable eIDAS-Ecosystem, the standardization committees responsible for electronic signature technologies at OASIS (Digital Signature Services eXtended, DSS-X) and ETSI (Electronic Signatures and Infrastructures, ESI) have recently adopted API-standards for for the creation, validation, and long-term preservation of signatures, seals, timestamps and evidence records.

This post provides a compact overview of the recently standardised programming interfaces and outlines possible future developments.

The new API standards Overview

As depicted in the figure below, the new API-standards provide programming interfaces for key services within the eIDAS-Ecosystem. Signatures and seals can be created via the Signature Generation & Sealing Service (SigS), verified via the Validation Service (ValS) and finally preserved for long periods of time with the Preservation Service (PresS). The application systems use the web service-based APIs developed by ETSI ESI and OASIS DSS-X. While the interfaces for the creation (ETSI TS 119 432) and validation of electronic signatures and seals (ETSI TS 119 442) are based upon the new version 2.0 des OASIS DSS-X Core, only the basic schema files created by OASIS (“Base” and “Metadata”) have been imported and extended for the definition of the interface of the Preservation Service (ETSI TS 119 512). In addition to the technical interface specifications considered in more detailed below, ETSI TS 119 431 (part 1 and part 2), ETSI TS 119 441 and ETSI TS 119 511 specify corresponding policy and security requirements, which form the basis for the conformity assessment of related (qualified) trust services in accordance with the eIDAS-Regulation.

 

Figure 1: The new signature APIs at a glance

 

OASIS DSS-X Core 2.0

As part of a Technical Committee (TC), specialising in “signature services”, a “Core” specification was created by the international standardization organization OASIS in 2007. This standard defines the basic functionality for the creation (SignRequest /-Response) and validation (VerifyRequest /-Response) of CMS- and XMLDSig-compliant signatures. Due to the wide range of requirements from the various application areas of signatures and time-stamps, the core specification has been extended by a series of so-called “profiles”, e.g. for use with code signing, entity seals or processing XAdES- and CAdES-compliant artifacts. In the following years further profiles were developed, e.g. for detailed signature verification reports and for signature creation devices not located within the server instance.

Based on this previous work, the challenges of a new “API-Ecosystem” were addressed in the OASIS Digital Signature Services eXtended (DSS-X) TC with version 2.0 of the Core, which also seperates the semantics of the interface from the concrete implementation using a specific syntax. In addition to the XML syntax adopted from version 1, JSON, which is often used in modern web applications, is now also supported. Additional syntaxes could be defined, if required. For example, an ASN.1 based syntax would be conceivable to enable a particularly compact format for mobile and embedded applications with the “Packed Encoding Rules” (PER). To ensure the highest possible visibility and acceptance of the standard, the DSS-X Technical Committee, in collaboration with the OASIS Infrastructure team, has started to provide the interface on the „SwaggerHub“ collaboration platform. For this purpose, the JSON schema is extended by a series of meta-information to comply with the OpenAPI specification.

The profiles, recently created by ETSI and currently at OASIS, enable the specific characteristics of the AdES signature formats in combination with local and remote eIDAS-compliant signature createn devices via the DSS-X interface. The additional attributes of the signatures (e.g., the embedded certificate status information, time-stamps or evidence records) allow a wide applicability of this format. Since the initial standardisation, the associated interface extensions for the XAdES and CAdES formats are defined by the “AdES-Profile”. As part of version 2.0, the AdES-Profile is currently updated to support the latest developments related to the AdES formats. In particular, the PAdES format based on the PDF specification is also supported in accordance with ETSI EN 319 142-1. With this PAdES format multiple signatures in a workflow and the visual representation of an electronic signature in a PDF document can be realised.

For use within the eIDAS environment, the support of so-called “policies” by the DSS-X specification proves to be valuable. This allows the caller to submit a “policy” to the service, required for the desired action. The addressed server instance decides whether it can meet the required quality level or whether the request must be rejected. If the request is processed, the applied “policy” can be transferred to the caller within the response structure. This ensures that a consensus has been reached on the minimum quality level to be applied.

ETSI TS 119 432

ETSI TS 119 432 based on version 2.0 of the OASIS DSS-X Core or in case of JSON also on the preparatory work of the Adobe-led “Cloud Signature Consortium” specifies interfaces for the remote signatures enabled by the eIDAS-Regulation. Here, in accordance with the standard EN 419 241 (part 1 and part 2) developed by CEN, a differentiation is made between the “Server Signing Application” (SSA) and the “Signature Creation Application” (SCA), each offering corresponding web service interfaces. The SSA contains an HSM-based “Signature Activation Module” (SAM) that triggers, after strong authentication of the signer in the “Signature Activation Protocol” (SAP) using the “Signer Interaction Component”, the creation of a raw digital signature in a low-level format, such as RSA according to PKCS # 1 or ECDSA for example. On the other hand, SCA ensures the preparation of the extended AdES signature format according to ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) or ETSI EN 319 142 (PAdES).

 

Figure 2: Remote signing system according to ETSI TS 119 432

 

ETSI TS 119 442

ETSI TS 119 442 defines three different programming interfaces, one for each type of service offering signature validation (validation via VerifyRequest / VerifyResponse), signature augmentation (augmentation via AugmentRequest / AugmentResponse), or offering both services combined. The first version of this document deals with the validation and enhancement of AdES signatures that comply with the current ETSI standards, such as: ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) and ETSI EN 319 142 (PAdES) and the previous AdES specifications. Especially relevant are in particular the “Baseline Profiles” ETSI TS 103 171, ETSI TS 103 172 and ETSI TS 103 173 mentioned in the “Commission Implementing Decision” (EU) 2015/1506 and the underlying AdES specifications ETSI TS 101 733, ETSI TS 102 778 and ETSI TS 101 903.

Future versions of this document may also cover the validation of time-stamps, evidence records, or signatures in ASiC containers.

ETSI TS 119 442 is based as much as possible on version 2.0 of the OASIS DSS-X Core. At the time of the finalisation of ETSI TS 119 442, the final version of the new OASIS DSS-X Core had not yet been published and therefore ETSI TS 119 442 needed to be based upon a draft version of the OASIS document. In cases where the depth of the OASIS draft did not seem sufficient to provide the desired functionality of the programming interface, new elements were defined.

Similar to version 2.0 of the OASIS DSS-X Core, each element of the programming interface is first described generally before characterising corresponding syntaxes for XML and JSON.

The defined validation interface allows, in addition to the signature, to send only the hash of the corresponding document instead of the signed document. This functionality can be very useful if the signed document is either very large, or if it must be avoided to send it completely to the Validation Service because of privacy or confidentiality reasons. Since a signature augmentation may require a new hash of the signed document, this option is not provided for the signature augmentation protocol.

If a document contains more than one signature, the APIs allow to select a specific subset of these signatures for validation and / or extension. In addition, it can also be specified in a request how many details should be returned in the response. This can range from a very simple response up to a comprehensive and signed signature valication report according to ETSI TS 119 102-2, as required in Article 33 (1) lit. b) of the eIDAS-Regulation.

ETSI TS 119 512

As a basis for the development of the technical specifications in the field of preservation services, a special report ETSI SR 019 510 was first created in ETSI ESI. On this basis, the development of the actual protocol standard ETSI TS 119 512 and the associated “Policy and Security Requirements” ETSI TS 119 511 took place.

As shown in the figure below, a Preservation Service according to ETSI TS 119 512 provides a “Preservation API”. This API may for example be used to send the preservation objects, intended for long-term preservation to the Preservation Service. A Preservation Service may on the other hand use external Time Stamping Authorities in accordance with ETSI EN 319 422, Signing & Sealing Services (SigS) or Validation Services (ValS) in order to obtain missing certificates and certificate revocation information necessary for signature validation. Alternatively, the Preservation Service may itself compile the necessary certificates and obtain certificate status information from the appropriate Certificate Status Authority.

There are three main types of Preservation Services, depending on the question whether they are operating: (a) “with a long-term storage” (WST), (b) “with a temporary storage” (WTS) or (c) “without storage” (WOS). In case of WST, the Preservation Service may use an internal or external storage under its control. Such a Preservation Service with storage is very similar to a “TR-ESOR-Middleware” according to the BSI Guideline TR-03125. The “Preservation-API” according to ETSI TS 119 512 is currently being integrated into the “TR-ESOR-Middleware”.

 

Figure 3: System with Preservation Service

 

The preservation standards ETSI TS 119 511 and ETSI TS 119 512 developed by ETSI allow to use different Preservation Schemes, which can be implemented in so-called Preservation Profiles.

The Preservation Profiles may on the other hand pursue the following objectives:

  • PDS (“Preservation of digital signatures”) – as proof of existence and for the preservation of the status of the digital signatures,
  • PGD (“Preservation of general data”) – as proof of the existence of general data that may either be signed or unsigned, and
  • AUG (“Augmentation”) – for the preservation of the conclusiveness of evidence, which has been produced by another preservation service, over long periods of time.

The preservation strategies specified in ETSI TS 119 512 use either Evidence Records according to RFC 4998 or RFC 6283, the Archive Time Stamps specified for CAdES and XAdES or the Document Time-Stamps specified for PAdES.

Depending on the storage model (WST, WTS, WOS), the various operations must (M) or may optionally (O) be converted by a Preservation Service according to ETSI TS 119 512, as shown below:

 

Operation Speichermodell Beschreibung der Funktion
WST WTS WOS
Retrieve
Info
M M M Provides information about the profiles supported by the preservation service
PreservePO M M M Transfer of data objects (“preservation object”, PO)
RetrievePO M M / Retrieval of data objects (reference and evidence data)
DeletePO M / / Delete data objects
UpdatePOC O[1] / / Extension of a storage container by a new version
Retrieve
Trace
O O O Retrieval of log data
Validate
Evidence
O O O Validation of evidence data
Search O O / Search for a specific data object

Table: Operations of the Preservation-API

 

Similar to the other API specifications, ETSI TS 119 512 first specifies the general semantics of an operation, before it specifies the concrete syntax for XML and JSON.

Towards the “eIDAS-API” and interoperability for the eIDAS-Ecosystem

Based on the programming interfaces developed by OASIS and ETSI, it is only a comparatively small step towards a comprehensive “eIDAS-API”, by which all services of the eIDAS-Ecosystem can be addressed via common, web service interface based on XML / SOAP or JSON / REST. For this purpose, only an appropriate authentication and authorization mechanism must be provided for the respective technology characteristics. While mechanisms based on Web Service Security are the obvious choice for SOAP, the use of OAuth according to RFC 6749 or, more generally, the use of HTTP/1.1 based authentication mechanisms according RFC 7235 is a natural choice for REST.

The “eIDAS-API” may not only include the functions described here for the generation, validation and preservation of signatures, seals, time-stamps and evidence records, but may also integrate the other services of the eIDAS-Ecosystem in an appropriate way. This may not only include the electronic identification (eID) and the efficient enrolment for (qualified) certificates based on this, but also the trustworthy transmission and registered electronic delivery of documents and emails, for example. In order to enable the seamless and simultaneous use of smartcards and HSM-based signature creation devices, one may use the “Local and Remote Signature Profile”, which has recently been outlined and which is currently standardised in OASIS DSS-X. First steps towards the practical implementation of the envisioned “eIDAS-API” have recently been taken with the launch of the FutureTrust pilots portal and the constitution of the go.eIDAS Working Group “API-Interoperability”. Join us there to make the dream of an interoperable eIDAS-Ecosystem come true!


[1] This function assumes that the used container format supports versioning.

Welcome to the Future of Trust

Even before the Regulation (EU) No. 910/2014 on electronic identification (eID) and trusted services for electronic transactions in the internal market (eIDAS) became fully applicable on 1st of July 2016, a pan-European team of experts led by the Ruhr University Bochum and ecsec GmbH had joined forces in the EU-funded FutureTrust project to facilitate the provision and use of eID and trust services. In more than three years of intensive research and development, the FutureTrust project has produced numerous remarkable innovations, which are now being made available to the general public and outlined in the present blog post.

 

Overview of the FutureTrust System Architecture

Overview of the FutureTrust System Architecture

As shown in the above figure, the FutureTrust project addresses large parts of the eIDAS-Ecosystem and integrates various FutureTrust Services and FutureTrust Pilot Applications as well as the “Global Trust List”, which provides information related to trust service providers across the European Member States and beyond.

There are the following basic FutureTrust Service

  • Pan-European eID-Broker (eID-Broker, eID),
  • Signature Generation & Sealing Service (SigS),
  • Validation Service (ValS),
  • Preservation Service (PresS),

and the following FutureTrust Pilot Applications

  • a Portuguese service for electronic SEPA eMandates (eMandate),
  • an Austrian service for electronic invoices (eInvoice),
  • a Georgian service for electronic Apostilles (eApostille) and
  • the German eIDAS-Portal, which allows to enrol for certificates after an eID-based identification.

Background, Motivation and Problems – as well as solutions provided by FutureTrust!

As shown in the figure below, there are currently[1] around 200 Qualified Trust Service Providers (QTSP) in Europe issuing qualified certificates for electronic signatures, as well as around 100 providers of qualified time stamps.

 

Trust Service Providers

Hence, the eIDAS-Ecosystem is, with respect to these basic trust services, which already existed before the eIDAS-Regulation entered into force, fairly well developed. Similarly, there also exist a significant number of European providers of qualified certificates for issuing electronic seals (93) or website authentication (41). The development of the market seems to be on the right track here. On the other hand, there are very few providers of qualified validation (13), preservation (10 or 11) or electronic registered delivery service (15) so far. Furthermore the very promising option for issuing qualified certificates based on electronic identification (see Art. 24 (1) (b) of the eIDAS-Regulation) – especially in combination with remote signatures – does not yet seem to be practically implemented and available in the market.

Expecting this foreseeable development, the FutureTrust project has built upon experiences and previous work from pertinent projects (e.g. STORK, STORK 2.0, FutureID, e-SENS, SD-DSS, Open eCard, OpenPEPPOL and SkIDentity) in order to close the existing gaps as far as possible by adressing the following problems (P1-P6) and provide tailormade solutions (->):

  • No Open Source Validation Service -> The FutureTrust Validation Service (ValS)
  • No standardised Preservation Service -> The FutureTrust Preservation Service (PresS)
  • No eID-based certificate enrolment -> The eIDAS-Portal of the German Universities
  • No universal signature and seal creation service -> The FutureTrust Signature Generation & Sealing Service (SigS)
  • Cross-border and non-European transactions are challenging -> The pan-European eID-Broker
  • Demand for fundamental research in the area of security, trust and reliability

P1. No Open Source Validation Service -> The FutureTrust Validation Service (ValS)

Many currently available components for validating electronic signatures and seals are

  • limited to specific document and signature formats (e.g. the freely available Adobe Reader only supports the validation of electronic signatures and seals in the PAdES format according to ETSI EN 319 142),
  • have been shown to be vulnerable and / or
  • are proprietary components, for which the sources are not publicly available

and hence the trustworthiness of a specific validation result is very difficult to assess.

Furthermore, as shown in the figure above, there are currently very few qualified validation service for qualified electronic signatures or seals available in Europe.

Against this background, the FutureTrust project has developed a comprehensive Validation Service (ValS), which supports advanced electronic signatures and seals (AdES) as well as related signature objects including X.509 certificates or Evidence Records based on configurable “Signature Validation Policies” and returns the validation result in a machine-readable XML or JSON based validation report (cf. ETSI TS 119 102-2 and OASIS DSS v1.0 Comprehensive Multi-Signature Verification Report Profile).

Format

Standard

Description

CAdES

ETSI EN 319 122

ASN.1-based digital signature based on the “Cryptographic Message Syntax

XAdES

ETSI EN 319 132

XML-based digital signature based on the “XML Digital signature

PAdES

ETSI EN 319 142

PDF document with embedded CAdES signature

JWS

RFC 7515

JSON-based digital signature for web applications, in the future also JAdES

X.509

X.509

Allows to check the status and trustworthiness of an X.509 certificate (see also RFC 5280) based on a suitable Trusted List.

ERS

RFC 4998

Evidence Records, which allow to produce efficient proofs of existence.

More details with respect to the FutureTrust Validation Service (ValS), which will soon be provided as Open Source, will be provided in a forthcoming blog post.

P2. No standardised Preservation Service -> The FutureTrust Preservation Service (PresS)

The well-known fact that signed objects lose their evidential value, if cryptographic algorithms become weak, induces major challenges for applications, which require maintaining the integrity and authenticity of signed data for long periods of time – or even for eternity. While the Technical Guideline BSI TR-03125 (TR-ESOR) had specified components for the preservation of evidence before the advent of FutureTrust, the corresponding ETSI standards for preservation services, such as ETSI TS 119 511 and ETSI TS 119 512 only appeared recently.

Against this background, selected experts from the FutureTrust team have been actively involved in the preservation-related standardisation work within OASIS DSS-X and ETSI ESI such that FutureTrust project has been able to provide a reference implementation of selected preservation schemes from the new preservation standards.

More details with respect to the FutureTrust Preservation Service (PresS) will be provided in a forthcoming blog post.

P3. No eID-based certificate enrolment -> The eIDAS-Portal of the German Universities

Before a qualified trust service provider can issue a qualified certificate to a natural or legal person, it is obliged (see Art. 24 (1) of the eIDAS-Regulation) to verify the identity and, if applicable, any specific attributes of the certificate subject. Furthermore, there are similar requirements for non-qualified certificates, which are issued within the Public-Key Infrastructure of the German Research Network (Deutsches Forschungsnetz, DFN-PKI), which is audited against ETSI EN 319 411-1, and which can be used for electronic signatures, email encryption, authentication or website authentication. In addition to the classical way to perform the identity verification while the subject is physically present (Art. 24 (1) a)), the eIDAS-Regulation also allows to perform the identification remotely using appropriate electronic identification (eID) means (Art. 24 (1) b)), by using qualified signatures or seals (Art. 24 (1) c)) or other identification methods recognised at national level (Art. 24 (1) d)), if they provide equivalent assurance. While the growing number of notified eID schemes and the availability of the pan-European eID-Broker infrastructures strongly suggest to use eID means for the identity verification during certificate enrolment, this option does not seem to be available in practice yet. Against this background, the FutureTrust project has designed and implemented a smart eID-based system for certificate enrolment, which allows to combine University-specific credentials with eID-based identity verification in order to end up with a completely electronic process for certificate enrolment within the DFN-PKI.

More details with respect to this novel certificate enrolment system, which is referred to as the “eIDAS-Portal” of the German Universities, which are participating in FutureTrust, will be subject of a forthcoming blog post.

P4. No universal signature creation service -> The FutureTrust Signature Generation & Sealing Service (SigS)

Even if certificates are already issued, this does not mean that these certificates can easily be used to create signatures or seals in web applications. A universal service for using arbitrary smart card- or remote signature-based certificates of different providers does not seem to exist so far. Through the development of the ChipGateway-protocol by ecsec GmbH and LuxTrust S.A. and the extension and adaptation of the protocol and architecture to support the special features of the German eID card, as well as the latest standards developed by OASIS DSS-X and ETSI ESI, the FutureTrust project has provided a solid corner stone for the envisioned universal signature creation service.

More details with respect to the FutureTrust Signature Generation & Sealing Service (SigS) as well as the related standards produced by OASIS and ETSI will subject of a forthcoming blog post.

P5. Cross-border and non-European transactions are challenging -> The pan-European eID-Broker

Chapter II of the eIDAS-Regulation, which deals with eID systems, aims at creating a standardised interoperability framework with well-defined processes, security levels, minimum requirements and interfaces, but does not intend to harmonise the respective national eID systems. In doing so, the EU Member States can notify their national eID scheme, such that the corresponding eID means will be recognised across Europe for a certain level of assurance, after a careful assessment (“peer review”) has been conducted and the formal notification procedure has concluded with a publication in the Official Journal of the European Union (see 2019/C 150/06 for example). For the technical implementation of the eID interoperability framework, so-called „eIDAS-Nodes“ are provided, which take care about cross-border processes between the application services and the identification services. So far, the envisioned „eIDAS-Nodes“ are not completely available in production yet and the focus of the “eIDAS-Cooperation Network” is limited to EU Member States and countries in the European Economic Area.

Against this background, the FutureTrust project has built upon previous work from pertinent projects, such as FutureID and SkIDentity in order to develop a smart pan-European eID-Broker, which is protected by the European patents EP2439900 and EP2919145, supports a plenty of standards as well as notified eID means from Germany, Estonia, Luxembourg, Belgium and Portugal and is subject of a forthcoming blog post.

While cross-border identification within Europe is often not easy in practice, the electronic processing of transactions with non-European partners poses additional challenges related to data protection specifics in case of transferring personal data to third countries (cf. GDPR, chapter 5) and missing international agreements for mutual recognition of trust services according to Article 14 of the eIDAS-Regulation. Unfortunately, there is no global legislation comparable to the eIDAS-Regulation, which made it necessary in FutureTrust to conduct fundamental research in the area of legal, organisational and technical aspects, which are reflected in relevant academic publications and the prototype of a “Global Trust List” (gTSL). The gTSL is an Open Source component for the trusted management of trust lists according to ETSI TS 119 612, which can be deployed with the other FutureTrust services or as standalone service and which will be subject of a forthcoming blog post.

P6. Fundamental research demand in the area of security, trust and trustworthiness

Conducting security research regularly points out new security problems and vulnerabilities, and with respect to the central concepts of “Trust” and “Trustworthiness”, there does not even seem to be well-founded and generally accepted definitions – not to talk about globally accepted graded minimum requirements. Therefore, it was necessary to scientifically discuss and analyse these fundamental aspects of „Trust“ and „Trustworthiness“ within the FutureTrust project, before formal models were developed, which describe comprehensive “Trust Models”, which finally formed the basis for the objective comparison of trustworthiness of various identification and trust services.

Summary, Acknowledgement and Outlook

The present blog post provided a compact overview of the main problems addressed and solved within the FutureTrust project, which started on 1st of June 2016 and has received funding by the European Commission within the EU Framework Programme for Research and Innovation (Horizon 2020) under the Grant Agreement No. 700542.

As explained throughout this article, the FutureTrust project has conducted fundamental research with respect to the foundations of trust and trustworthiness, has actively supported the standardization process in relevant areas, and has developed numerous services, which ease the use of eID and electronic signature technology in real world applications by addressing the problems outlined above.

The practical applicability of the concepts and software components has been demonstrated in several pilot applications, such as a Portuguese service for electronic SEPA eMandates, an Austrian service for electronic invoices (eInvoice), a Georgian service for electronic Apostilles (eApostille) and last but not least the German eIDAS-Portal, which allows to enrol for certificates after an eID-based identification.

The FutureTrust Services and the FutureTrust Applications are now being made available to the general public step by step and interested parties are encouraged to get in touch with the FutureTrust experts to talk about tailormade solutions and individual needs.

[1] Comparing the current figures (July 2019) with the figures from a recent German article, which has appeared in DuD 2019/04, shows that the number of qualified trust service providers is slightly growing.

Sightseeing the “eIDAS-Ecosystem”

The “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”, which is commonly known as the “eIDAS Regulation”, is expected to boost trust and efficiency for electronic transactions across Europe and beyond. In this post, we briefly recall what the eIDAS-Regulation is about, invite you to follow us and climb up to a “virtual viewpoint” from which the major parts and services of the “eIDAS-Ecosystem” and their interrelationship become visible, so that you can explore the currently available trust services using the interactive eIDAS-Map and see the overall potential and your individual benefits introduced by this regulation.

The “eIDAS-Ecosystem” at a glance

As shown in the figure, the “eIDAS-Ecosystem” is populated by “Users”, which use some kind of “eIDAS-based Transaction Services”. These Transaction Services in turn may use a variety of “eIDAS Services”, for which the trust is maintained by the “eIDAS Trust System”.

The “eIDAS Trust System”, which deserves a specific treatment in a forthcoming post because of its sophisticated structure, provides the trustworthy foundation for the entire “eIDAS-Ecosystem” by an appropriate combination of measures including accreditation, conformity assessment, supervision and incident handling.

While the realm of “eIDAS-based Transaction Services” is also sufficiently rich to be subject of additional posts, we will introduce and explain the set of “eIDAS Services” in the following, as these services provide the functional core of the “eIDAS-Ecosystem”.

The “eIDAS Services” comprise the “eID-Service” for electronic identification regulated by Chapter II and a variety of “Trust Services” according to Article 3 (16) and regulated by Chapter III of the eIDAS-Regulation. These services in particular comprise

  • the “Signature Generation & Sealing Service” (SigS),
  • the “Validation Service” (ValS),
  • the “Preservation Service” (PresS),
  • the “Electronic Delivery Service” (EDS) and the already widely implemented classical trust services, such as
  • the “Time Stamp Authority” (TSA) and last but not least
  • the “Certification Authority” (CA).

eID-Service

The “eID-Service” provides services for the secure electronic identification and authentication of Users and legal persons. The employed means and services for electronic identification and authentication comprise electronic identification schemes, which have been notified according to Article 9 as well as other schemes. As specified in Article 8 of the eIDAS-Regulation and the related implementing act CIR (EU) 2015/1502, the trustworthiness of an electronic identification scheme and the identification means deployed within, is reflected in its level of assurance. The specified assurance levels range from “low” over “substantial” to “high”. Notified eID schemes which provide at least a substantial level of assurance will be mutually recognized in cross-border transactions according to Article 6 of the eIDAS-Regulation.

Certification Authority (CA)

A Certification Authority (CA) generates electronic certificates and issues them to Users or other entities, commonly called the Subject of a certificate. This may happen directly, via the “eIDAS-based Transaction Service” or the “Signature & Seal Generation Service” (SigS). The SigS interacts with the CA-system, performs an appropriate identification of the Subject and validates the provided identity attributes, which are combined with a public key and are signed by the CA to create the certificate.

Time Stamping Authority (TSA)

Proving the existence of a given set of digital data at a given time is a fundamental requirement in many electronic transactions, which involve electronic signatures, aspects of digital rights management, electronic contracts or require accountability for example. For this purpose, a Time Stamping Authority (TSA) receives the data, which need to be time stamped, or a hash thereof, and returns a time stamp token, which is signed by the TSA.

Signature Generation & Sealing Service (SigS)

The Signature Generation & Sealing Service (SigS) allows to generate (qualified) electronic signatures according to Section 4 and (qualified) electronic seals according to Section 5 of the eIDAS-Regulation in technical formats such as CAdES, XAdES and PAdES for example.

Validation Service (ValS)

The (qualified) electronic signatures and seals generated with the SigS above can be validated with the Validation Service (ValS). The ValS uses the certificates contained in the Trusted Lists according to Article 22 of the eIDAS-Regulation, the corresponding implementing act CID (EU) 2015/1506 and ETSI TS 119 162(v2.1.1) as trust anchors and performs a signature validation according to EN 319 102-1 using an appropriate validation policy.

Preservation Service (PresS)

The long term retention of signed documents requires a form of safekeeping that ensures the legibility and conclusiveness regardless of the storage medium. In order to ensure the legal validity of electronic signatures and electronic seals over long periods of time one needs to apply appropriate preservation techniques as outlined in ETSI SR 019 510.

The preservation techniques realised by a Preservation Service (PresS) according to Article 34 may involve Evidence Records according to RFC 4998 or RFC 6283 or the continuous augmentation of signatures using archive time stamps according to CAdES or XAdES for example.

Electronic Delivery Service (EDS)

In a paper-based world, the only way to know that a letter indeed has reached the addressee is to send it by registered mail. This is a service offered by the mail service providers. The sender writes down his/her statements on a sheet and puts it into a closed envelope, which is marked with the coordinates of the addressee and sends it by mail. The accountability, confidentiality and integrity of the letter are primarily assured by the author, while the mail service providers primarily warrant availability and correct delivery.

According to Article 44 of the eIDAS-Regulation “qualified electronic registered delivery services shall meet the following requirements:

  • they are provided by one or more qualified trust service provider(s);
  • they ensure with a high level of confidence the identification of the sender;
  • they ensure the identification of the addressee before the delivery of the data;
  • the sending and receiving of data is secured by an advanced electronic signature or an advanced electronic seal of a qualified trust service provider in such a manner as to preclude the possibility of the data being changed undetectably;
  • any change of the data needed for the purpose of sending or receiving the data is clearly indicated to the sender and addressee of the data;
  • the date and time of sending, receiving and any change of data are indicated by a qualified electronic time stamp.”

Given these requirements it is obvious that the EDS needs to utilise a variety of other eIDAS Services such as the eID-Service, the SigS, the TSA, the ValS and the certificate status information provided by the CA.

Exploring the overall potential of eIDAS using the interactive eIDAS-Map

The EDS is a nice example that several basic “eIDAS Services” may be combined to form more comprehensive “eIDAS Services” or “eIDAS-based Transaction Services”, which address application-specific needs. A key aspect of the eIDAS-Regulation is that it harmonises the requirements for electronic identification and trust services across Europe and defines the EU-wide legal effect of notified electronic identification means (cf. Article 6), electronic signatures (cf. Article 25), electronic seals (cf. Article 35), time stamps (cf. Article 41), electronic delivery services (cf. Article 43) and last but not least electronic documents (cf. Article 46).

This means that providers and consumers of services may choose among the large number of qualified trust service providers, which are currently active in the European market as exposed by the interactive eIDAS-TSP-Map released today. This map provides an up-to-date overview of the currently existing trust service providers and trust services across Europe.

The individual benefits of the eIDAS-Regulation – What’s in for you?

What kind of benefits the eIDAS-Regulation provides for you depends on your specific role within the “eIDAS-Ecosystem”. The benefit for providers of “eIDAS Services” is that they now can provide and sell their services across Europe, which gives rise to interesting new market opportunities. The benefit for Users is that they may now use a variety of trust services, with well-defined trustworthiness and legal effect. The probably biggest potential benefit of the eIDAS-Regulation however exists for the emerging “eIDAS-based Transaction Services”, which will be subject of a forthcoming post.

Acknowledgement

We gratefully acknowledge that this post is based on contents developed in the FutureTrust project, which has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 700542.