The Electronic Signature Guide covers topics regarding the configuration of digital signature types. It covers the perspective of the sender. For information about the perspective of the signer please see the Signer Guide.
eSignAnyWhere supports different kinds of signatures and these will not only affect how the signer signs the document, it also affects the legal aspect of the signature. We recommend that you verify with your legal consultant, which would be the best signature for your specific use case. Within the European Union a clear regulation is available under the eIDAS 910/2014 regulation. Nevertheless, there are still some national limitations affecting the electronic signature and its possibilities, therefore a validation is recommended.
Within the European Union you can categorize the signatures into two categories, defined by the EU regulation 910/2014 eIDAS (electronic IDentification, Authentication and trust Services) regulation:
- Advanced Electronic Signature (AES)
- provides unique identifying information, that links to its signatory
- signatory has sole control of the data used to create the electronic signature
- must ensure that the signature is invalid after changes of the document (e.g. PAdES [PDF Advanced Electronic Signature] in PDF)
- Qualified Electronic Signature (QES)
- is a signature, created via a qualified electronic signature device (e.g. SmartCard or Remote Certificate of a TSP)
- equivalent to written legal form
- no reputable by signatory
- requires an identification of the signer, which can be executed by a LRA (Local Registration Authority) or its sales partners
It also defines the terminology for natural persons as “electronic signature” and for legal persons (e.g. companies) as electronic seal.
Signature Types in eSignAnyWhere
|Click to Sign||depending on a second factor or use case||no||Is a simple signature, where the signer has to click on the signature to sign the field. In combination with an additional element (under sole control of the signer) it is a AES. We recommend to use the authentication (e.g. SMS-OTP) to ensure it. Please verify the use case to ensure that the authentication methods are under sole control of the signer.|
|Draw to Sign||depending on a second factor or use case||no||Is a simple signature, where the signer can record a signature (e.g. via mouse, finger) to sign the field in form of a picture (no biometric data). In combination with an additional element (under sole control of the signer) it is a AES. We recommend to use the authentication (e.g. SMS-OTP) to ensure it. Please verify the use case to ensure that the authentication methods are under sole control of the signer.|
|Type to Sign||depending on a second factor or use case||no||Is a simple signature, where the signer can type his signature, which is used as picture for the signature. In combination with an additional element (under sole control of the signer) it is a AES. We recommend to use the authentication (e.g. SMS-OTP) to ensure it. Please verify the use case to ensure that the authentication methods are under sole control of the signer.|
|Biometric Signature||Yes||No||The biometric signature records & (asymetrically) encrypts in real time the data points of the handwritten signature. The encrypted signature will be stored & bind to the PDF document to be validated. So the biometric data is the element under sole control of the signer, so no additonal authentication is required (except the use case requires it). Please note that the biometric signature is not recorded directly via Browser, it typically requires a specific hardware (Signature Pad, Tablet PC with Pen, Convertible with Pen) to ensure a high quality of the biometric signature, so it is mostly used for Point-Of-Sale use cases. Please contact your Namirial Sales Consultant for more information.|
|SMS-OTP Signature||Yes||No||The SMS-OTP (One-Time-Password) signature is similar to the Click to Sign signature, where the signer clicks on the signature field and confirms via SMS OTP (a numeric number sent to the signers phone) to sign the field. The phone is under sole control of the signer.|
|Local Certificate||Depending on Local Certificate||Depending on Local Certificate||This signature allows to access via the SIGNificant Device Driver (download is available via Signing Interface) local devices (e.g. Smart Cards, USB Token, Windows Cert Store). The signature level (AES, QES) depends on the used device.|
|Digital Remote Certificate||Yes||Depending on Certificate||This signature allows to access remote certificates (stored in a CA/TC) to sign the document. The credentials are under control of the signer. Depending on the certificate it is either an AES or QES.|
|Disposable Certificate||QES||QES||This signature uses a disposable certificate via the Namirial TSP. The disposable is a QES, which is only valid for a short time and allows a simpler usage for the signers (via confirming the T&C with Namirial TSP and the QES via SMS OTP or Namirial OTP App).|
|Custom Signature Types||Depending on the configuration of the custom signature||Depending on the configuration of the custom signature||On demand we can integrate for you custom signature types (customer TSP integrations, use case depending signature types).|
All envelopes write a detailed audit trail (except if disabled), which is documenting the signing process and its actions and events (such as the authentication of the signer). The audit trail gets signed digitally by eSignAnyWhere.
eSignAnyWhere supports different kinds of signatures, most of them are designed for a specific use case to ensure a good user experience and acceptance.
In general you can define a
- Remote scenario, where the signer is using his own devices (e.g. Smartphone or PC)
- Point-of-Sale (PoS) scenario, where the signer can use the device available at the PoS
Remote scenario is using the signer’s device for the signature, typically at home or at the office. Therefore, a recommended signature type is “Click to Sign“, because it shows a good user experience and acceptance. In combination with a SMS-OTP (one time password) for the authentication, it is considered as an AES. Other authentication methods (PIN, OAuth2 or SAML) might also have a good user experience.
Alternatively, you can choose the SMS-OTP signature option. However, please be aware that it requires a SMS-OTP for each signature field, which may require extra effort from the signer when dealing with multiple signature fields (if batch signing is not activated, with the batch signing it is possible to sign multiple signature fields at once please see Batch Signing Dialog. It is important to note that SMS-OTP is an optional feature and not the default setting of eSignAnyWhere.
For a QES the best option is a disposable certificate, because the signer has to accept the Namirial TSP terms and conditions for the disposable certificate (personal certificate for the signer). The signing is performed by clicking on the signature field and confirming with SMS-OTP or Namirial OTP App.
The PoS scenario is typically used in combination with API integrations and extended use cases. At the point of sale there is typically a hardware for signing, such as a Signature Pad, Tablet (e.g. iPad) or a PC with touch screen and pen. In that case for AES a biometric signature is a natural way of signing. You also can use the signers devices by transforming it to a “remote” scenario and the signer uses his own device at the point of sale.
QES is supported via Disposable Certificate e.g. with the SIGNificant Kiosk in combination with a Signature Pad (e.g. the Namirial NT10011).
Evidence and Validation of Signed PDF/A Documents
The PDF document is a powerful document standard (ISO 32000) and PAdES (PDF Advanced Electronic Signature) ensures secure documents and signatures. The evidence is stored on the one hand directly in the PDF document and in a corresponding process documentation (audit trail).
If you open a signed PDF document with a PDF Reader (e.g. Adobe Reader), you can verify embedded data, such as:
- Digital certificates show the signatory or the document issuer
- protects document integrity and make changes visible
- display signing graph and document history
- trusted time-stamps (optional)
- geo-location (optional)
- information on the validity of the signature certificate on signing time (OCSP / CRL)
- EUTL – European Trust List for EIdAS for Trust Service Providers
- encrypted biometric signature data embedded in the document
- Adobe Reader – Adobe Approved Trusted List (AATL)
In addition to the evidence in the signed document a corresponding sealed process documentation (audit trail) is written:
- envelope with hashed of document
- send notifications and recipient addresses
- authentication (PIN, SMS-OTP, etc.)
- reader’s IP addresses
- reader’s location
- date & time of actions
- actions on the document/envelope: page open & view, confirmations, form field edits, signatures and many more
The following sample shows the structure of the audit trail xml:
Values for Type:
Values for Status
Values for Modification:
Values for AuthenticationMethod:
Values for Type
How to define the signature of the recipient (Saw-Viewer)
This tutorial guides you through the process of defining the signature of the recipient. First, the configuration of the definition and assignment has to be made. There you can select the recipient, write a label, select if the signature field is required and if batch signature is allowed.
Definition & Assignment configurations
|Recipient||Selection of which recipient has to sign the field|
|Label||The label of the signature field (displayed)|
|Required||Define if the recipient has to sign the signature field or if it is optional. If a signature field is required it is highlighted with a red border.|
|batch signing||If you use this, the recipient is allowed to sign more than one signature field at once. Therefore, you have to select a first signature field and select the “Batch Signature” option.|
On the next figure you see where you can find the settings:
After this configuration you can decide with which signature type the recipient should sign the envelope.
You have to select at least one type. You can select more, if you want to give the recipient the option to choose a specific type. You can also define a preselect type (favorite, click on star-icon). Please note, that not all types are available for all customers.
HTML 5 signature types
Click2Sign, Draw2Sign, Type2Sign
For these three signature types you do not have to configure anything. Just place the signature field on the document, select one to more of these types and send the envelope.
As you can see on the last figure, we selected all three signature types, therefore the recipient can choose between these types. With the star-icon on the right sight next to the types you can select the preferred signature types which will be highlighted for the recipient.
For the biometric signature you can decide between the following three options:
- withinField: the recorded signature must be within the signature field
- onPage: the recorded signature must be on page (can be written outside of the signature field)
- intersectsWithField: the recorded signature must be partly within the signature field (default)
Generally there are two ways to set the phone number. You can either type the number in the SMS-OTP signature field or the recipient type in the number when he/she receives the envelope. First figure shows the first way (sender defines the number), the second one shows if the recipient defines the phone number.
Note: If you place a signature field but you do not enter a phone number you will get a notification like it is shown in the next screenshot:
With the local certificate the recipient can use a locally on his device installed certificate for signing. For the digital remote the recipient uses a remote certificate for signing.
For the local certificate you can find the settings here:
With those settings you can validate the recipient and certificate holder name and the certificate root CA verification with EUTL.
After you configured those settings you just have to select a local certificate. Next screenshot shows the selection:
Digital remote certificate
If the user has a long lived certificate you can use the Digital Remote Signature option. It is similar to the disposable certificate, but you must not provide so much information, as the user is already registered. It is not required to define the User Id or Device Id, then the signer must enter the data himself.
In the designer you must select the Digital Remote Signature for the signature type.
Before you can send a disposable certificate you have to fill in some dates. First, in your organization settings and then if you send the envelope. The next figure shows you the configurations which has to be done before sending the envelope.
There are three checkboxes available:
- Use lean disposable (Has to be enabled, except there is a clear reason against it)
Note: There are differences in the validation rules between "classic" disposable and "lean disposable".
- Show disclaimer before certificate request (to ensure that certificates are issued only with consent of the holder; but might be substituted with other process constraints which address the legal requirement)
- Send disposable disclaimer document emails (might be required in fulfillment of obligations of the LRA contract, unless other delivery methods ensure delivery of the certificate request form)
To use the disposable certificate you just click the settings for the recipient to edit her/his information for the certificate. You need the following information:
- Document type
- Identity card
- Driver license
- Document number
- Document issued on
- Document issued by
- Document expiry date
- Identification Issuing Country
- Identification type
- Tax Code
- National unique number
- Identity card
- Driving license
- Identification Number
- Mobile phone
- Country of residence
If you validate the dates and the recipient name does not match the holder name for the disposable certificate you will get a warning. The following screenshot shows you the warning:
If you click on the “compare” field the next window appears where you can update the name either to the holder name or to the recipient name:
In the designer you have to select the signature field type as “Disposable Certificate”.
The signer will receive its email as usual and when the signer wants to sign a disposable certificate signature field he will get a one-time-password via SMS. The counter on the disposable certificate starts by signing the first signature.
If “Show disclaimer before certificate request” is enabled in Settings->Organization->Disposable Certificate the signer first receives the disclaimer before the SMS-OTP.
When the document is finished you can validate, for example, the qualified electronic signature in Adobe Reader.
You can also send a disposable signature via api. To do this, you first have to upload a document and then add the signature and the disposable certificate data. Note: You have to add the disposable certificate data in the section “recipient”.
After these configurations you can send the envelope with a disposable certificate signature.
With eSignAnyWhere version 3.2 the automatic remote signatures (automatic remote eSeal) are integrated. So you can setup, as user manager, automatic remote signature profiles for automatic signature.
If you create a workflow, a new type “Add Automatic” recipient is available. The automatic remote signature / eSealing is applied automatically to the document, if it is the automatic recipient turn. The workflow continues automatically with the next recipient after the automatic recipient.
- Automatic Remote Signatures / eSealing are an optional eSignAnyWhere feature
- User Managers can configure the automatic remote signature / eSealing profiles in the Organization settings page, when they have enabled the user option “Allow Automatic eSealing”
- Power use can use the automatic remote signature / eSealing profiles, if they have the user option “Allow Automatic eSealing” enabled
1) Automatic Remote Signature Profiles
The profiles for automatic remote signatures are managed via the organization’s settings page (so only by user managers). For creating an automatic remote signature profile you need a description (e.g. name), the username and the password.
Attention: if a power user wants to use the automatic remote signatures, the user must have enabled the user right “” (see “Settings” > “Users”).
2) User Settings
User must have enabled the option “Allow automatic eSealing” to use the automatic remote signatures / eSealing within a workflow.
3) Creating a workflow with automatic remote signatures
In the eSAW UI you can add an automatic signer / eSealing via button in the recipient list “Add Automatic”. Then the profile must be selected for the automatic signature / eSealing. Attention: the power user must have the right “Allow automatic eSealing” enabled (see “Settings” > “Users”).
Note: This feature is not available with basic subscription, so please contact your Namirial sales.
After the configuration of the generic signing plugin in the organization settings you can now use the signature in the envelope. First configure the setting for the recipient. Please see the next figure.
After the configuration you can select the signature plugin as a signature type in the designer. Please see the next figure:
|AATL||Adobe Approved Trust-List|
|Biometric Signature||A recording of x/y coordinates, pressure and time of a handwritten signature.|
|CRL||Certificate Revoke List|
|Digital Signature||An electronic signature based on asymmetric cryptographic algorithms.|
|Electronic Signature||An electronic signature can be from a simple level (SES) to a very high level of signature (QES).|
|EUTL||European Union Trust-List|
|Portable Document Format|
|PKCS||Public Key Cryptography Standards, e.g. PKCS#7 a high level signature format.|
|PKI||Public Key Infrastructure|
|OCSP||Online Certificate Status Protocol|
|QES||Qualified Electronic Signature|
|OTP||One Time Password|
|TSP||Trust Service Provider|
|QTSP||Qualified Trust Service Provider|
The information provided on this page is continually revised and adapted to changes in legislation or case law, technology. Hints for clarification, updating and supplementing are always welcome via e-mail. The information on this page does not constitute legal advice. In particular, they can not replace any individual legal advice that takes into account the specifics of the individual case.