This page summarizes the impact the introduction of PDF Advanced Electronic Signatures (PAdES) support in BankID will have on merchant implementations as well as on end users. The objective of this overview is to give merchants a summary of what they need to prepare for, in order to adapt their merchant application to create PAdES envelopes. This overview is targeted at merchants who integrate using BankID server. PAdES support for merchants that integrate through BankID’s Open ID Connect platform will be introduced in a subsequent release. Note that implementation details at the coding-level are beyond the scope of this description.

There are two primary drivers for introducing PAdES support in BankID. First, the introduction of PAdES brings with it tools for BankID merchants enabling them improve the user experience for electronic signing, the most important being (1) the option of including a visual signature representation in the document and (2) an option for the end user to download and verify the validity of the document. Second, support for PAdES is required by law for providers that offer trust services to the public sector in the European Union and Norway. The requirement was incorporated into Norwegian law as of June 2018.

The needs analysis has shown that merchants may be roughly divided into two groups, when it comes to signing. The first “advanced” group wants BankID to provide a set of basic tools that enable them to create and maintain PAdES envelopes where most of the logic to achieve this will be implemented in the merchant’s own application. The second group on the other hand, prefers that BankID provides a more turnkey solution by way of a comprehensive set of tools so that less logic must be built within the merchant’s own application. The introduction of PAdES in BankID caters to both of these groups of merchants.

The introduction of PAdES implies providing support for PDF envelopes according to the ISO32000-2 standard, of which PAdES (further specified in ETSI’s EN 319 142-1) is a subset. Adding such support is non-trivial as seen from BankID, because the current BankID signing solution is parallel in nature, whereas PAdES signing has a sequential nature. PAdES support is introduced as an additional signing envelope format in parallel with the existing (legacy) envelope format, SEID SDO. The mentioned standard defines a number of profiles. In this release, BankID will introduce support for the Baseline Basic (B-B) profile.

BankID server must be upgraded

The functionality required to create PAdES-compliant document envelopes will not become automatically available via existing merchant implementations. To support such creation, merchants need to install a new version of BankID server from the this release (named “København”) and adapt their merchant application accordingly, see following sections.

Please note that only the BankID 2.1 server (requiring the use of the client proxy component) will be updated to support the PAdES functionality added in this release. BankID does not plan to add such support in the 2.0 server. However, in the previous release named “Kiev”, both servers were updated with rudimentary support for creating PAdES envelopes. Please note, however, that the previous release does have functional limitations in terms of PAdES envelope creation. Furthermore, merchants that prefer to remain on the previous release, are required to build much of the signing logic into their own applications, whereas those using the København release can rely on the BankID solution to provide much of this logic.

Please note that BankID server and the BankID infrastructure will offer concurrent support for the creation of legacy envelopes (SEID SDOs) and PAdES envelopes. At some point, support for the creation of legacy envelopes will be phased out.

Merchants must adapt their implementation

The release brings with it new functionality that the merchant may choose to use.

Merchants should assess the implications of sequential signing

As mentioned, the current BankID signing solution is parallel in nature, whereas PAdES signing has a sequential nature. In signing scenarios where more than one signatory (as seen from the merchant) is part in the signing operation, the signature of the second signatory will be appended to the document as an incremental update after the previous, and so forth. The merchant should assess what such a (new) signing pattern implies for its implementation.

Note: It is not possible to mix serial and parallell signing in the same scenario.

Envelope type may specified

In the signing process, the merchant may choose to either create PAdES or legacy (SEID SDO) envelopes. By default, the solution will create SEID SDO envelopes.

Turnkey solution vs. self assembler mode

Merchants may choose between two approaches when implementing support for PAdES.

We expect the majority of merchants to adopt the turnkey solution. In this case, the BankID infrastructure provides most of the needed functionality. The merchant and the end-user will receive a full PDF with all signatures and visual signature representations. In the self assembler mode, however, the BankID infrastructure simply provides certificates, signatures and ocsp-responses which are PAdES-compatible. It will then be up to the merchant to build the PDF-envelope and add visual signature representations in their own application.

The merchant will be able to choose between turnkey and self assemble mode at the start of the transaction in the BankIDServer APIs. In both cases, the merchant will have to process a new callback from the ClientProxy.

Visual signature representations may be added (turnkey solution)

In the event that the merchant has selected to create a PAdES envelope, a visual signature representation will be added to the document. Placement of the signature can be controlled through parameters (x/y-coordinates and page number). Should the merchant wish to place the signature(s) on a separate page, such a page must be added to the document by the merchant. We recommend that the merchant add test cases to verify correct signature placement. An option to suppress the visual signature will be available. The content of the visual representation itself is fixed.

PDF documents must comply with the PDF/A-2 level B specification

As with previous releases, the merchant must ensure that the documents to be signed comply with the PDF/A-2 Level B specification. Until now, the reason for this requirement is to ensure that documents sent in by the merchant do not contain potentially malicious content. Moreover, with this release, there is another reason to ensure such compliance. With the introduction of PAdES support, the end user may validate the electronic signatures within PDF documents. Such validation is expected to fail, should the documents sent in by the merchant not comply with the correct conformance level as defined in the PDF standard.

As with previous releases, merchants should ensure that PDF documents conform to the PDF/UA specification in addition to the PDF/A-2b format, in order to provide a basis for proper support for Universal Accessibility when displaying PDF documents.

Please note that the BankID Web-client does not validate any signatures that may already be present in documents to be signed.

End user impact

The introduction of PAdES support is expected to affect end users in a few areas.

First, the BankID Web-client will be adapted in two ways:

Provided that the merchant has selected to add a visual signature to the document, the end user will be able to view the visual signature as it is added to the document;
Provided that the merchant has set the option showConfirmation to true, the end user has the option to download the signed document(s) to her/his device. In the event that multiple documents were signed, a bundle of documents will be downloaded.

Second, when the end user opens a document containing PAdES signature(s) in a standards compliant PDF reader (e.g. Adobe Acrobat Reader), she/he may check the validity of the signatures and certificates used to sign the document. Please note that depending on device configuration, in many cases the PDF document will by default open in a browser plugin. Many of these plugins currently do not support signature validation.

Browser not supported