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.

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.