E-Signing

Get started
Step 1
Step 2
Step 3
​E-Signing APIs
Overview
Signed document formats
E-Signing validator
Web Service functions
Insert sign order
Manage sign orders
Get sign order info
Signed documents
Error response
User experience
Functions
Authentication-based signing
Multi-document signing
Notification call back
eIDs
BankID (NO)
BankID (SE)
BankID on mobile (NO)
Buypass
MitID (DK)
Mobiilivarmenne (FI)
Mobile-ID
Nets One time code
Nets Passport Reader
Smart-ID
Verimi
Finnish Bank ID
Test Users
Service access
KeyUtil
Operational information
Release notes
Error codes
Web Service error codes
User flow error codes
Terms and expressions
Contact us

Multi-document signing

​Document signing in one flow with only one interaction with the user's eID.

Overview

The E-Signing service offers the possibility for a user to sign a set of documents in the same user flow. The customer adds the set of documents in the same sign order. This can for example be documents that are a part of a larger document package. If using the eID's signing features (except for BankID NO), each document must be read and completely signed one by one and with an interaction with the eID for each document. By utilizing the authentication-based signing feature in E-Signing, users may sign a set of documents in the same flow.

Both text and PDF documents are supported using the multi-document signing feature in addition to the PDF form functionality.

Note: BankID NO is the exception to the statement about eIDs above. Read more about BankID multi-document signing feature.

User flow

A user may sign a set of document in one flow. She will be presented with a list of all documents ready for signing and must open, read and accept all of them. After all have been read, the user will do an authentication with her selected eID and the E-Signing service will create a signature on all documents. The signed documents can be downloaded as a SDO or PAdES as for other signed documents.

Note: If the user cancels anywhere in the flow, she must read and accept all documents when she restarts the signing. The only exception is that if the user completed a PDF form and continued she will not be requested to fill out the form once more.

Below follows an example of a user flow with three documents. The first document is a PDF, the second document is a PDF form that the user must complete before accepting the content and the third is a text document. The flow shows extract from the standalone and the pop-up UI. The embedded UI is slightly different, but the flow is the same.

Multi-docsign_pop-up1_1.png

1. The user selects the eID she wants to identify with. In this example the user selects Finnish Bank IDs. This is an optional page and only the eIDs specified or configured on the customer configuration will be shown to the user.

2. The user is presented with all documents she will sign, and she must open them one by one.

3. The user reads the first document and accepts it.

Multi-docsign_pop-up1_2.png

4. The user is directed back to the list of documents. The first document is now marked as read.

5. The second document in this example is a PDF form. The user must complete the form before continuing to read through and accept the document.

6. The user reads through and accepts the document.

Multi-docsign_pop-up1_3.png

7. The user is directed back to the list of documents. Only document three remains to be accepted.

8. The user reads and accepts the third document.

9. The user is directed back to the list of documents. All documents have now been read and the user can sign all documents.

Multi-docsign_pop-up1_4.png

10. The user chose Finnish Bank IDs in the first step and must now select her bank. She selects Nordea.

11. The user identifies with the Nordea login client. In the background, the E-Signing service uses the information about the authenticated user to generate a short-term certificate that is used to sign the documents.

Implementation considerations

When implementing this functionality, please be aware of the following:

  • The Signer(s) must be defined with the <Nets> element in the AcceptedPKIs element in the sign order or if not using the AcceptedPKIs element, the customer configuration must be set up with one or more authentication-based eIDs.  
  • All signing processes must be added to the same step. See the XML example below.
  • If the Signer is set with <Nets> and the signer belongs to several signing processes in the same step, the default will be to display the documents with this multi-document signing functionality. The functionality may be turned off by appending the multisign=false parameter to the signing URL.
  • If the user cancels the signing, she must start the entire signing flow and open, read and accept all documents once more.

XML examples

Defining Signers

The signer should be defined with the <Nets> element in the AcceptedPKIs element. 

<Signers>
	<Signer>
		<EndUserSigner>
			<LocalSignerReference>user1</LocalSignerReference>
			<Name>Test User</Name>
			<AcceptedPKIs>
				<Nets>
				</Nets>
			</AcceptedPKIs>
		</EndUserSigner>
	</Signer>
</Signers>

Defining Steps and SigningProcesses

All the documents the specified signer will sign in the same user flow must be defined in the same step. In the example below, the user will be presented with doc1, doc2 and doc3. As the doc4 document is in the second step, it will not be available for signing together with the other documents. This document will be ready to sign after the first three have been signed. 

<Steps>
	<Step>
		<StepNumber>1</StepNumber>
		<SigningProcess>
			<LocalDocumentReference>doc1</LocalDocumentReference>
			<LocalSignerReference>user1</LocalSignerReference>
		</SigningProcess>
		<SigningProcess>
			<LocalDocumentReference>doc2</LocalDocumentReference>
			<LocalSignerReference>user1</LocalSignerReference>
		</SigningProcess>
		<SigningProcess>
			<LocalDocumentReference>doc3</LocalDocumentReference>
			<LocalSignerReference>user1</LocalSignerReference>
		</SigningProcess>
	</Step>
	<Step>
		<StepNumber>2</StepNumber>
		<SigningProcess>
			<LocalDocumentReference>doc4</LocalDocumentReference>
			<LocalSignerReference>user1</LocalSignerReference>
		</SigningProcess>
	</Step>
</Steps>

 

GetSigningProcesses results

The signing URL may be requested by using the GetSigningProcesses request. This will return all active signing processes for this user. In this case, there are three active signing processes. Any of these signing URLs may be used and all will direct the user to the document list. 

<SigningProcessResults>
	<SigningProcessResult>
		<SigningProcessId>123456</SigningProcessId>
		<Status>Active</Status>
		<LocalWebContextRef>Default</LocalWebContextRef>
		<LocalSignerReference>user1</LocalSignerReference>
		<DocumentDetails>
			<DocumentStatus>Active</DocumentStatus>
			<LocalDocumentReference>doc1</LocalDocumentReference>
			...
			<DocType>PDF</DocType>
		</DocumentDetails>
		<SignURL>https://www.sign-preprod1.nets.eu/sign/index.html?sref=1A2B</SignURL>
	</SigningProcessResult>
	<SigningProcessResult>
		<SigningProcessId>123457</SigningProcessId>
		<Status>Active</Status>
		<LocalWebContextRef>Default</LocalWebContextRef>
		<LocalSignerReference>user1</LocalSignerReference>
		<DocumentDetails>
			<DocumentStatus>Active</DocumentStatus>
			<LocalDocumentReference>doc2</LocalDocumentReference>
			...
			<DocType>PDF</DocType>
		</DocumentDetails>
		<SignURL>https://www.sign-preprod1.nets.eu/sign/index.html?sref=3C4D</SignURL>
	</SigningProcessResult>
	<SigningProcessResult>
		<SigningProcessId>123458</SigningProcessId>
		<Status>Active</Status>
		<LocalWebContextRef>Default</LocalWebContextRef>
		<LocalSignerReference>user1</LocalSignerReference>
		<DocumentDetails>
			<DocumentStatus>Active</DocumentStatus>
			<LocalDocumentReference>doc3</LocalDocumentReference>
			...
			<DocType>TEXT</DocType>
		</DocumentDetails>
		<SignURL>https://www.sign-preprod1.nets.eu/sign/index.html?sref=5E6F</SignURL>
	</SigningProcessResult>
</SigningProcessResults>