I am trying to identify if there are any standards (accepted by the EU) regarding client-side digitally signing the form-data before it is submitted.

So the constraints are:

  • know standard
  • accepted by the EU
  • client-side (we need proof of origin not tamper-proofing)
  • javascript based and/or browser plugin based (any language)
  • can work with web-forms related content (k/v pairs of data)
  • the output of the process should be machine readable (ex.: form-urlenc, JSON, bson, msgpack)
  • the output format should not have ambiguity issues (meaning not bloody XML*, maybe not form-urlenc either)

My read-up on the subject so far

XMLDSIG is bad since XML can be canonicalized a zillion different ways making the signature not valid or worse an attached XSD or XSLT (or even CSS) can alter the visible rendering (depending on visualisation tool) of the data content meaning it can alter its meaning exposing users to possible scams.

PAdES is already being used in our public administration and our project scope might cover having to build PDF files with embedded forms and digital signature.

PGP/GPG or S/MIME could be a valid contender for the role but idk if they're officially recognized or standardize by EU laws. On the other hand both of these carry their signatures appended to the data.


I'm doing research for a government project (in Romania) trying to implement digital signatures over simple web-forms.

I know Estonia, Belgium, France and Germany already have similar systems in place for electronic identity cards and hardware digital signature of documents as well as some frameworks/tools they use (ex.: hwcrypto.js).

But I'd like to understand their full process, for example do they digitally sign entire documents or just some raw data in a machine readable format (as described above).

Do they require electronic ID cards or can it be used with a certificate file you have on disk.


2 Answers 2


Digital signature in EU is ruled by REGULATION No 910/2014 on electronic identification and trust services. It is directly applicable in all territories without transposition

You will not found any reference to standards about format or technology, but acomplishment will require:

  • X509 digital certificates issued by a qualified trust service provider. Must be present in EU trusted list(TSL)
  • XAdES, CAdES, PAdES or ASiCs format for interoperability between public administrations

Digital certificates in browser

Certificates are issued to users in software files or cryptographics tokens (ID card). This is the biggest obstacle. Due to Java restrictions on browsers, you can not use the OS native Key Store (check this and this)

There are some alternatives

AdES format

This is not a derived requirement of regulation 910/2014, but eGoverment use to have additional legislation for interoperability. This is not mandatory on private business

ETSI XAdES, CAdES and PAdES are not suitable for web environments. Known libraries like forge or pkijs do not support it. XAdES is based on XMLDsig (you have defined it...) and CAdES/PAdES use ASN.1 binary encoding.

Unfortunately JWS(JsonWebSignature) still does not have a standard AdES of ETSI.

On web & mobile devices is used a technique called 'three steps signature' to avoid move the complex digital signature libraries to the device.

  1. Prepare hash to sign on server using user's public certificate and the data to sign (a document or the form data)

  2. Sign hash on client side

  3. Complete the signature format on server

Only the second step is performed on client side. The SD-DSS european framework (opensource) provides to administrations a complete digital signature framework, including support to TSL, signature and verification

  • the Estonian DDOC / BDOC files are AdES and they seem to be using XMLDSIG -- but I've seen content in their files that also helps specify which canonicalization algorithm was used and since they have their own document reader/write they probably disabled XSLT/CSS or have very specific XSLT/CSS designed for their purposes. Oct 13, 2016 at 9:32
  • Thank you very much for the answer. The native messaging solution used by the Estonian -- how does it work? Send a native message containing form-data, have a local application listen to messages, digitally sign received messages and respond with the signature? Oct 13, 2016 at 9:44
  • I was taking a look at opensource project a while ago. Basically the flow you have written is right. They have a local driver to connect to the cryptographic token. But it is not universal, only some card models are supported. In the other way the spanish solution uses Windows/linux native keystore, and connects to the local application using an integrated http server.
    – pedrofb
    Oct 13, 2016 at 11:02
  • I do not know how Estonians solve the problem, but I am sure using XAdES or XMLDsig from javascript will be a headache. All solutions I have seen use a local application with support for Java/C# libraries or a three steps signature server
    – pedrofb
    Oct 13, 2016 at 11:09
  • they have a customm AdES format called bdoc which is a zip containing a standalone signature in XMLDSIG format + another file (the raw data I think) + a manifest. And they have their own reader/writer software. So I'm assuming the XMLDSIG part is handled in the reader/writer software suite (likely in Java or C#) and it just responds with the signed XML data to chrome/js (which passes it along unmodified). Oct 13, 2016 at 11:49

You can perform:

  • S/MIME signing and verification,
  • PDF signing and verification,

In Javascript using PKIjs, here is an S/MIME example.

You can do XAdES signatures in Javascript using XAdESjs.

The larger issue is accessing a smart card from within the browser, today the only way that can practically be done is via a plug-in like the one provided by the Estonian national ID project, you would need to do work to wrap that in a WebCrypto style interface to use the above libraries.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .