Trust and Internet Identity Meeting Europe
2013 - 2020: Workshops and Unconference

TIIME 2015 Session 13: eSignatures

Convener: Pietu Pohjalainen

Abstract: Current EU legislation recognizes eSignatures and advanced eSignatures. The advanced eSignatures are in practice hard to use. In the 'normal' eSignature field, there's quite a lot of variation in what does it mean technically and organisationally.

Tags: eSignature, eIDAS


I'm having a project on gaining deeper understanding of what are the technical possibilities with online eSignature operators.

Interpreting EU-regulation on eSignatures is confusing.

An advanced electronic signature is one that fulfils the following four points:

  1. Is uniquely linked to the signatory
  2. Capable to identifying the signatory      
  3. Is created using means that the signatory has under his sole control
  4. Is able to detect any changes to the signed data

We discussed about the current usage problem patterns in using electronic signatures in practice. There is a number of eSignature operators, who operate in varied manners; especially the point #3 is a problematic for gaining an “advanced electronic signature” status for an outsourced operator.

The main problem seems to be the confusion in the field between all of the different “shades of grey”; the legislation distinguishes between three shades of grey:

  1. the normal electronic signature,
  2. The advanced electronic signature,
  3. The qualified electronic signature.

However, in each of these categories, there’s many ways of doing the signature, and we discussed that it would be beneficial to have more thorough understanding of the differences.

This would help utilizing organizations to choose between the trade-offs given by the technical features of different solutions and the cost required to deploy the solution.

The regular electronic signature can at its simplest form be just a postfix in an email, like:

“br, Pietu”, or an embedded .jpg file.

Obviously, it is not overly reliable way to identify the signatory, and is prone to falsification claims. It is clear that some kind of “regular” signature, that is backed up by a 2-factor authenticated session is more reliable. However, currently we don’t have very good understanding of distinguishing between the different ways of providing these signatures as a service.

In today’s web world, the connection between e.g. one’s smart card for doing advanced or qualified signatures was discussed to be “a mess”. In Finland, the government standard solution is to have specific software installed in every desktop, which clearly is not saleable to the web age. In Estonia, the government is supporting the development of web browser plugins, which gives citizens the technical means to do advances signatures, but the plugin mechanism still requires installations and historically has been proven to be a source of security problems. WebCrypto API is a way to expose the PKI certificate’s private key for cryptographic operations, but according to discussants, it seemed to be more targeted for performing DRM controls rather than digital signatures.

Manne presented a recent Nordic eID status document, which also discusses electronic signatures. One main points is that the currently written legislation is erroneously regarded as the minimum security level, while is should be considered as the highest level; in general there is no requirements (unless specifically noted) to request qualified signatures in digital operations.

a1: In Nordic eID Survey – 2015 (study initiated by the Nordic Council of Ministers) states:

"Unfortunately, many EU Member States have turned this principle inside out by stating that QES is the only mechanism that can replace a handwritten signature. The effect is in too many cases a preservation of the paper process, blocking alternative approaches that would be sufficiently secure (from a risk management viewpoint) and more user-friendly and efficient. While a handwritten signature is the only practical mechanism for proving consent on paper, many approaches can be used to prove a digital consent, and the choice of mechanism should be guided by a convenience and risk analysis rather than by blindly specifying a particular technological solution. This “QES only” approach can be viewed as contrary to the intention of eIDAS and the eSignature directive, which explicitly state that QES is a maximum level. There is no hindrance in eIDAS from accepting other forms of electronic signatures as long as the mechanism(s) used fulfil the purpose of the signature in the process. One may argue that AdES/AdESQC/QES should only be used when:

  1. There is a legal requirement for using the specific mechanism; as described above such requirements are too often posed by EU Member State laws and regulations without due justification of the real need.
  1. A risk analysis (typically by the owner of a digital service) yields a requirement for use of the mechanism, typically the need to collect a strong “proof”.
  1. The mechanism is right for the service by being suitable and user-friendly as a component of the process; this angle at AdESs is unfortunately rarely seen.

It is fair to say that the legal approach of always requiring QES may have a sound explanation in the legal systems of some of the Member States, e.g. there may be specific requirements (form factors) regarding what constitutes a legally valid document/agreement and/or what is acceptable as evidence in court. Thus, one sometimes sees the term “legally valid signature” used as an equivalent of QES; however this is clearly misleading since other electronic signatures surely carry legal value at least in those Member States that are not strict on QES requirements."

Peter (Peter Alterman, Ph.D Chief Operating Officer - SAFE-BioPharma Association ( presented us with the current, traditional knowledge of how to do e.g. PDF signature using standard Adobe technologies.

In the past, these required desktop installations, but it turned out that nowadays there seems to be also solutions that allow securely signing PDF documents through uploading the cloud.

There was an explanation of how the process goes so that although the signatory’s private key resides in the cloud, it is still under his sole control.

Thus, it was argued to be a qualified electronic signature, as the private key never leaves the HSM device in the cloud, and thus the signatory is the only one who can sign the document with his PIN code.


It might be good to have a group of people working on this issue and work on the risk assessment and make the risk assessment easy for the relying party to choose between the technical qualities of the signature and the associated cost.

The main problem seems to be that people - relying parties - are not aware of all the technical complexities and legal consequences of choosing one solution over another.

The insurance should come from relying party.

Can we have a cheaper, less advanced ways? - The risk assessment is a key to it.