# InkSign (handwritten signatures)

# Introduction

InkSign, or handwritten signatures, can be used as a signing method in combination with Signicat's portfolio of methods for identifying the end-user. InkSign can also be used without an ID method.

InkSign is suited for in-store scenarios. With the addition of identity document uploading, the method provides a universal solution for identifying users. The end-user can provide a photo of their identity paper by either uploading a picture from their mobile device or by taking a picture with a web cam.

You can find technical details on the InkSign process below.

# Create an InkSign request

You can use InkSign in addition to a strong ID method or as a standalone signature. When used alone, no other ID method will be used to authenticate the user signing the document. The user must then be authenticated outside of the signature process.

Signicat can enable InkSign at service level or at method level.

When set at method level, InkSign can be enabled for some methods and disabled for others. For example, it is possible to combine SMS OTP with handwritten signature, while MitID will be without. When enabled at the service level, it is set in Signicat's configuration and this will then overrule the method-level setting.

InkSign can be combined with the upload of an ID paper. Signicat can configure the service to require either the front side or both front and rear sides of the ID paper. The ID paper must then be uploaded before the user is asked for a handwritten signature.


The following examples for the creation of an InkSign request apply to our DocumentService API, unless otherwise noted.

# Data type: Method

# Description

The Method data type contains a method that can be used to sign the document. The method name must match the method definitions on the service.

# Fields

Name Data type Description
method String Optional. The method name. If no method name is specified, handwritten must be true.
handwritten Boolean Optional. Set to true if a handwritten signature (InkSign) is required.

# Example requests

# DocumentService API
<soap:Envelope xmlns:soap="" xmlns="">
        <method handwritten="true"/>
        <method handwritten="true">sms-otp</method>
        <method handwritten="false">nbid-js</method>

In this example we have three choices:

  • InkSign only - no other ID method is requested
  • A method called sms-otp will be followed by request for a handwritten signature
  • Only the method nbid-js. No handwritten signature
# Sign API

	    "clientReference": null,
	    "tasks": [
	            "dialog": null,
	            "id": "taskid-1",
	            "profile": null,
	            "language": null,
	            "daysToLive": 1,
	            "configuration": null,
	            "documents": [
	                    "id": "doc-1",
	                    "description": "Sign this",
	                    "action": "SIGN",
	                    "source": "SESSION",
	                    "documentRef": "{{documentref}}",
	                    "signTextEntry": null,
	                    "sendResultToArchive": false
	            "signatureMethods": [
	                           "name": "dummy-auth",
	                            "handwritten": true,
	                            "type": "AUTHENTICATION_BASED"
	            "authentication": null,
	            "onTaskPostpone": null,
	            "onTaskComplete": null,
	            "onTaskReject": null,
	            "notifications": null
	    "notifications": null,
	    "daysUntilDeletion": 1

# Active Session Signing

Sometimes the user is required to authenticate before signing. The request will then have an authentication element with the ID methods available for authentication. If a handwritten signature is required, then the corresponding method element in authentication-based-signature must have a handwritten attribute.

Below is an example of a CreateRequest where the user can authenticate with either SMS OTP or SBID. If the user chooses SMS OTP, they must also provide a handwritten signature when signing the document. The SBID method do not require any extra handwritten signature.

<soap:Envelope xmlns:soap="" xmlns="">
        <method handwritten="true">sms-otp</method>
        <method handwritten="false">sbid</method>

# Third-party (native) signing

Currently we do not support the combination of third-party (native) signatures and handwritten signatures.

# Handwritten signature user experience

The following example screenshots illustrate different scenarios:

# 1. Multiple signing methods, including handwritten only


# 2. Signing with handwritten only


# 3. Signing with ID method, ID paper upload and handwritten signature





# InkSign in LTV-SDO

Starting with LTV-SDO (Long Term Validation Signed Data Object) schema version 2.1, we added support for storing a handwritten signature (InkSign) as an element in the LTV-SDO.

The following is an example of what this looks like:

    <ltv:VisualRepresentation MimeType="image/png">[BASE64 ENCODED IMAGE GOES HERE]</ltv:VisualRepresentation>
    <ltv:ClaimedName>Ginny Weasley</ltv:ClaimedName>
                <ltv:FrontSide MimeType="image/jpeg">[BASE64 ENCODED IMAGE GOES HERE]</ltv:FrontSide>
                <ltv:RearSide MimeType="image/jpeg">[BASE64 ENCODED IMAGE GOES HERE]</ltv:RearSide>

# InkSign only

The following changes take place in the LTV-SDO when the document is signed only with handwritten signature, without authentication:

Lines in red are removed, lines in green are added. The other lines are unchanged.

Expand/ collapse LTV-SDO diff example

-<ltv:LtvSdo xmlns:ltv="" xmlns:ds="" xmlns:xades="" Id="root">

+<ltv:LtvSdo xmlns:ltv="" xmlns:ds="" xmlns:xades="" Id="root">



<ltv:SignerDisplayName>Ginny Weasly</ltv:SignerDisplayName>


- <ltv:SignerNationalId>10109001290</ltv:SignerNationalId>

- <ltv:SignerNationality>NO</ltv:SignerNationality>

- <ltv:SignerNationalIdType>PID</ltv:SignerNationalIdType>




<ltv:DocumentTitle>Letter of intent</ltv:DocumentTitle>

<ltv:DocumentDigest alg="">FeJ0sdSTtGXIstHNvqq1Bw8A63mJPNEWqnBhoJLx00Y=>



- <ltv:SignatureTypeFriendlyName>Signicat Sign</ltv:SignatureTypeFriendlyName>

+ <ltv:SignatureTypeFriendlyName>InkSign</ltv:SignatureTypeFriendlyName>

<ltv:SignatureFormatFriendlyName>XML Signature</ltv:SignatureFormatFriendlyName>




- <ltv:SignaturePolicyIdentifier>urn:signicat:signaturepolicy:authbased-ltv:signicat:2.0</ltv:SignaturePolicyIdentifier>

+ <ltv:SignaturePolicyIdentifier>urn:signicat:signaturepolicy:handwritten-ltv:signicat:2.1</ltv:SignaturePolicyIdentifier>

- <ltv:Authentication>

- <ltv:SAMLResponse Format="urn:signicat:format:saml-1.1" MimeType="application/x-saml+xml" Version="1.0">.....</ltv:SAMLResponse>

- <ltv:AuthenticationFriendlyName>BANKID</ltv:AuthenticationFriendlyName>

- </ltv:Authentication>




# SignerUniqueId

Since there is no authentication, we do not have any unique identification of the end-user. We need to have an ID that is unique within the InkSign method, and that is different between signers. With these requirements we choose to use the HTTP session ID from the Java Servlet (JSESSIONID).

The JSESSIONID is unique between browser sessions. Two end-users signing on the same browser on the same device, will get different JSESSIONIDs. This also means that the same person will get different JSESSIONIDs when signing two different signing orders.

The JSESSIONID is likely not guaranteed to be unique, but it is good enough for our use case.

The JSESSIONID is not secret to the end-user, browser or server. It is very important, however, that the JSESSIONID is kept secret to everyone else. Before the JSESSIONID is used in the LTV-SDO, we will use a secure hash algorithm (SHA-256) to keep it secret and then Base64-encode the hash.

# Handwritten signatures in PAdES

The information contained in the HandwrittenSignature element of an LTV-SDO can be displayed in a PAdES document generated by Signicat. This can be done in two different ways, either inserted into a PAdES template or in a separate signature page.

# The PAdES template

Naturally, all the values contained in the LTV-SDO can be extracted using normal XPath expressions. However, this make little sense for anything besides HandwrittenSignature/ClaimedName.

For the other values, a new function type has been added: INK. This function can be used in dynamic expressions in the same way that the IMG function is used, i.e. by prepending it to the normal expression.

The IMG function accepts an expression that will resolve into a string that will be used as a key to retrieve a value from the configuration file at Signicat's end. The INK function, on the other hand, accepts one of a predefined set of strings that maps to the value of an element contained in the HandwrittenSignature element.

An example is as follows:


Using this dynamic expression in a PAdES template will result in the captured HandwrittenSignature/VisualRepresentation image being inserted in place of the form field.

The predefined set of strings is as follows:

String value Maps to element
idpaper-front HandwrittenSignature/HandwrittenSignatureQualifyingProperties/IdPaper/VisualRepresentation/FrontSide
idpaper-rear HandwrittenSignature/HandwrittenSignatureQualifyingProperties/IdPaper/VisualRepresentation/RearSide
signature HandwrittenSignature/VisualRepresentation

# The signature page

A standardised signature page can be generated and inserted into the final PAdES.

The page can be inserted before or after the original document. It will look like the example below and will show the signature, name and date – this is the same as what you would expect when signing documents in the physical world.


# PAdES Template (with handwritten signature and front + rear side of identity paper):

You can find an example of a PAdES template with handwritten signature and front + rear side of an identity paper here:

Download PAdES template

Last updated: 11/07/2022 14:07 UTC