Add your signature
Last updated
Last updated
© Ascertia Limited 2024
Signatures are cryptographic codes embedded into the document, to prove the identity of the actual signer of a document and whether or not the document has changed since signing. In SigningHub, each user signs with their own PKI signing key so that each signature uniquely identifies the signing entity. To perform signatures having AES, QES or AATL as the level of assurance applied to the signature field, you must have a SigningHub account.
Click the "Go to field" button, the cursor will start blinking the signature field assigned to you.
Single-click and select the "Sign" option or double-click the Signature field.
SigningHub will prompt you to agree to the legal notice (if it is configured for you).
The Signing servers dialogue box window will appear and display multiple signing servers which can be selected, based on the level of assurance set by the document owner on that signature field and the level of assurance that is configured in your role.
Signing servers are based on service plan configurations, and will display the signing server for server-side and client-side signing both.
Select one of the signing servers to perform the signature.
Select a visible signature type (i.e., Text, Hand-Drawn, Image) that you wish to use in your signature. In case of uploading a signature image, the white colour in the image background will be auto-converted to transparent.
For Text-based signature type, the name of the recipient will be auto-filled and cannot be changed if it's restricted from enterprise roles signature appearance settings.
Select a desired Signing Capacity for your signature (if it is configured for you to sign in different positions in your organisation). The options available in the "Signing Capacity" drop-down list are those that are allowed in your enterprise user role. All signing capacities will group together based on the level of assurance.
Choose a desired appearance for your signature. The options being populated in the "Signature Appearance Design" field are the allowed appearances to your enterprise user role. You can also see this list in your personal Signature Appearance. The signature appearance will be auto-filled and cannot be changed if it's restricted from enterprise roles signature settings to use a specific appearance for the selected Signing Server.
Click on the SIGN NOW button to proceed with signing.
Upon clicking the SIGN NOW button, either no dialogue box window appears (if No Authentication is set for the selected signing capacity), or a dialogue window appears depending upon the authentications that are configured for the selected signing capacity under enterprise roles>signing servers>authentications.
In case the user has selected the eID Easy Signing Server:
Upon clicking the "SIGN" button, the eId widget will appear. It will show signing methods based on the country configured in the user's personal settings. Select a signing method to proceed with.
Based on the selected signing method, complete the authorization process. Once the authorization is complete the document will be signed.
After the authorization is complete, the eID Easy API uses a webhook to send the signing certificate details to SigningHub which is used to fetch the "Signed by" information. The webhook URL, "[Web_URL]/eid-easy/certificate-detail/webhook", is configured against the "Custom CAdES digest webhook" property in the eID Easy.
In case of signing of XML document, optionally you may also specify "Commitment Type Indication". SigningHub populates values of this field in editable mode from your Personal Signing Details. When specified they will become a permanent part of your XML signature.
In case of an invisible signature, there will be no appearance preferences on the "Sign" dialogue box. Just click the "SIGN" button to proceed to the authentication method.
Based on your Signature Settings, the authentication method may change.
Optionally, you may also specify "Signing Reason", "Contact Information" and "Location". SigningHub populates values of these fields in editable mode from your Personal Signing Details. When specified they will become a permanent part of your PDF signature.
Click the "OK" button, if there is an authentication, a dialogue box window appears. In case of 'No Authentication', no further dialog window appears, once you click on the SIGN NOW button.
The document is now signed, and your signature will be displayed in the same area of your document as per the selected signature appearance.
The document status will be changed from "Pending" to "Signed".
The system will notify the respective document owner about your signing through an email.
An intimation email will also be sent from the document owner to the next configured recipient (if any), with the request to respond to the document workflow accordingly. The recipient can then follow the document link from the email to collaborate in the workflow.
If CSP Provisioning is allowed in your service plan, then your certificate will be automatically registered in the CSP Service against your (user) ID which was created at the time of login.
If Remote Authorized Signing (RAS) is allowed in your role, then your certificate will be auto-registered in the SAM service against your (user) ID which was created at the time of login.
If CSP Provisioning is allowed in your service plan and Remote Authorised Signing (RAS) is allowed in your role, then your certificate will be auto-registered in the SAM and CSP services against your (user) ID which was created at the time of login.
In case authentication via OTP is required, the user can have the option to choose to receive OTP via Text Message or Email depending on the service plan. Once OTP is received, enter it in the text field. In case OTP is not received you may select the option to resend it. You can also choose another method for OTP by selecting 'Switch Method'.
In case authentication via Time-based One-Time Password is required, the user will be able to sign the document after they have entered the Time-based One-Time Password. Whenever the recipient tries to sign this document they will be prompted to enter the Time-based One-Time Password from the authenticator app configured on their mobile device. In case the recipient has not configured two-factor authentication (2FA), upon trying to sign a document that requires Time time-based One-Time Password, an email will be sent to their email address to configure two-factor authentication (2FA). The document will be signed only upon providing the correct Time-based One-Time Password.
Click the "Ok" button.
In case the "Automatically proceed with workflow upon completion of mandatory actions by signer" option is turned off in your enterprise user role, then the "Close" button will be displayed to conclude the signing process.
In the case of an enterprise user, the Signing dialogue box will not appear in the following:
“Hide signature dialogue box at the time of signing“ is checked in your role, and
You have selected Hand Signature Method as Text or Upload having the signature Image in your My Settings> Signatures> Signature Appearance, and
You have only a single signing capacity
The individual user signing capacities will appear as per the configured capacities under the service plan.
If the ''Only display the logos of the authentication and signing profiles' checkbox is checked in SigningHub Admin and a logo has not been configured for a signing profile in the connector, the system will display the logo, in the signing servers dialog box while signing.
Signing Servers that appear on the signing dialogue box are subject to your service plan and user's role settings. It shows both types of servers including Server-Side Signing and Client-Side Signing, based on the level of assurance set by the document owner on the signature field.
In case the Level of Assurance of a "Signature" field is set to "Simple Electronic Signature", then Signing Servers will not appear on the signing dialogue box.
Signing Server can be ADSS, eID Easy or CSC for Server Side Signing and ADSS Go>Sign or T1C for Client Side Signing.
The eID Easy Signing Server will only appear if the level of assurance of the signature field is set to Qualified Electronic Signatures (QES).
If you select ADSS Go>Sign or CSC Signing Server and the system configurator has enabled RUT validation, then signing allows the National Identity IDs with a certificate to be filtered and checked.
SigningHub will validate the National ID specified in the My Settings of the user against the other values of the Subject Alternative Name (SAN) extension specified for certificates.
This will slow down the signing process as SigningHub parses the certificate to extract the otherName value.
If you have selected CSC Signing Server to perform signature and "Authorisation Code" is selected as the "Auth Type" in CSC Connector, then on clicking the SIGN NOW button you will be shown an additional authorisation option, depending upon the authorisation settings configured in your CSC Server:
Implicit
Explicit (One Time Password (OTP)/PIN Number)
OAuth Authorization Code
In case "Client Credentials" has been selected as the "Auth Type" in the CSC Connector, an unregistered user will not be able to perform signatures using the CSC Signing Server since CSC_ID cannot be added for an unregistered user.
If "Client Credentials" is selected as the "Auth Type" in the CSC Connector and a valid CSC User ID has been configured for the user, then on clicking the Sign button, no additional authorization will be required for signing.
There could be a possibility that both the options of OTP and PIN Number are configured as a signing time authentication by your CSC Server.
In case the Level of Assurance of a "Signature" field is set to "Simple Electronic Signature", then only Document Signing Authentication will work.
The OTP method will be as per the configured OTP method in the document owner's service plan.
"(Email)", in case only "Email OTP" is configured in the service plan
"(SMS)", in case only "SMS OTP" is configured in the service plan
"(SMS and Email)", in case both "Email OTP" and "SMS OTP" are configured in the service plan
The OTP length is based on your subscribed service plan. SigningHub currently supports 4, 6, and 9 digits OTP.
The OTP retry and expiry times are based on your subscribed service plan.
The availability of Time-based One-Time Password as a document signing authentication method is subject to your subscribed service plan.
If the user does not have two-factor authentication (2FA) configured, they will be sent an email to set up and to provide a Time-based One-Time Password. If the user has already configured two-factor authentication (2FA) they will be prompted to provide the Time-based One-Time Password from the authenticator app configured on their mobile device.
To configure the two-factor authentication (2FA) the user will need to install an authenticator app (Google Authenticator, Microsoft Authenticator, etc.) on their mobile device. The email sent to the user to configure two-factor authentication (2FA) will contain:
QR Code
Manual Key
Recovery Codes
To set up, the user can either scan the "QR Code" or manually input the "Manual Key" in the Authenticator app. Once the registration is successful, the user can provide the automatically generated Time-based One-Time Password from the Authenticator app to SigningHub in order to proceed. The list of recovery codes included in the configuration email can be used in place of a Time-based One-Time Password, once each recovery code, is to regain access to your SigningHub account, in case you lose access to your mobile device. It is advised to save the recovery codes in a safe place. The user can, however, regenerate a new list of the recovery codes from the Manage Two Factor Authentication (2FA) option. In case an enterprise user loses access to your mobile device and recovery codes, or has used all of the recovery codes, you can ask your enterprise admin to reset the two-factor authentication (2FA) against your account.
When a signing server is configured in your Signature Settings for locally held keys and you select that signing server, the signing certificate residing in your local keystore or inside the crypto device (token/smartcard) will be used. In other words, the signing activity is performed locally on your machine. For this, ensure the Go>Sign Desktop app is installed and running on your system as a back-end utility. However, if Trust1Connector (T1C) is configured as a signing server to perform local signing, then make sure the T1C app is installed on your local machine and the related HSM is attached to it while signing. Also, you should have full rights to the Trust1Connector service running on your machine. SigningHub will prompt you if any of the above-mentioned prerequisites are missing. At the time of local signing, your browser will interact with Go>Sign Desktop or T1C app to complete your signing process. The app is capable of accessing your keys and certificates via MSCAPI and PKCS#11 on the Windows platform. When you click the signature field to sign a document, the signing server dialogue box will appear. Select the signing server that you have configured to perform client-side signing and click the NEXT button:
If your signing key is inside a crypto device, attach the device and specify your device pin.
If your signing certificate is inside your local key store and protection has been enabled for it, then select the required certificate from the list and provide your certificate password.
Click the "SIGN NOW" button. The document is signed.
Before locally signing the document using T1C, the system will prompt the user for their consent to continue the signing process.
If you are using the Microsoft Edge browser for local signing, then you need to perform an additional configuration on your machine to run Go>Sign Desktop, i.e.:
Close the Microsoft Edge browser if already launched.
Launch the command prompt by using "Run as administrator".
Run this command: CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Launch the Microsoft Edge browser and run your application again to test Go>Sign Desktop.
When a signing server is configured in your Signature Settings for server-held keys and you select that signing server, the signing certificate residing on the server will be used. In other words, the signing activity is performed on the server but not on your machine. Signing Servers that appear on the signing dialogue box are subject to your service plan and user's role settings. It shows both types of servers for Server Side Signing including eID, ADSS and CSC, based on the level of assurance set by the document owner on the signature field.
Based on the Authentication Method set under your enterprise role, SigningHub supports multiple types of authentication methods for server-side signing, which are as follows:
No Authentication
SigningHub ID
Salesforce
Microsoft Active Directory
Microsoft ADFS
Microsoft Office 365
Microsoft Azure Active Directory
Freja eID
OAuth2
OIDC
Authorisation via Mobile App
To use Remote Authorisation Signing (RAS) as an authentication method, you must use signing capacity having QES (Qualified Electronic Signature) as a level of assurance that is configured under your enterprise roles > signing servers.
For RAS, enabled signing capacities Authorisation via Mobile App will appear as the only authentication method and cannot be changed.
SigningHub supports signing authentication via both; public and private authentication profiles.
You can additionally set up the Secondary Authentication Method, at signing time. The following three options can only be set:
No Authentication
One Time Password
Time-based One-Time Password
To set up One Time Password as the only option at signing time, you can select 'No Authentication' under the authentication method and One Time Password under the secondary authentication method.
In this type of server-side signing authentication, SigningHub will use the same authentication method through which you have logged into your SigningHub account, without requiring any password.
When you click the signature field to sign a document:
Click the "Sign Now" button. The document is signed without requiring any password or OTP.
SigningHub allows two-factor authentication for the server-side signing. In this case, an OTP (one-time password) is sent to your (signer) email address and/or the configured mobile number through an SMS, depending on what's configured in the user's service plan. This OTP is used in addition to the account password to sign a document. However, the OTP feature and its length are subject to your subscribed service plan, so the SMS service is chargeable accordingly. SigningHub currently supports 4, 6, and 9 digits OTP.
When you click the signature field to sign a document:
Click the "Sign" button. An OTP will be sent to your configured mobile number.
Specify the OTP in the next appearing screen.
Click the "OK" button. The document is signed.
The following rules will be followed for the OTP via SMS authentication:
When the recipient is a registered user and attempts to sign a signature field, the system will follow the OTP authentication settings (including mobile number) as configured by the document owner via the "Set Access Security" dialogue box.
In case the OTP authentication is not configured by the document owner, the system will follow the OTP authentication settings configured in the Enterprise Role while using the mobile number specified on the user's "My Settings" page.
In case OTP authentication is not configured in the Enterprise Role or Service Plan, then the OTP process will not initiate.
When the recipient is a guest user and attempts to sign a signature field, the system will follow the OTP authentication settings (including the mobile number) as configured by the document owner via the "Set Access Security" dialogue box.
In addition, even if the OTP authentication is configured in the Enterprise role, the OTP process will still not initiate.
SigningHub allows two-factor authentication for the server-side signing. In this case, whenever the recipient tries to sign this document they will be prompted to enter the Time-based One-Time Password from the authenticator app configured on their mobile device. In case the recipient has not configured two-factor authentication (2FA), upon trying to sign a document that requires Time based One Time Password, an email will be sent to their email address to configure two-factor authentication (2FA). The document will be signed only upon providing the correct Time-based One-Time Password.
When you click the signature field to sign a document:
Click the "Sign" button. ( In case you do not have two-factor authentication configured, an email will be sent to their email address to configure two-factor authentication)
Specify the Time-based One-Time Password from the configured authenticator app, in the next appearing screen.
Click the "Ok" button. The document is signed.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button, and specify your SigningHub account password in the next appearing screen.
Click the "Ok" button. The document is signed.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using any third-party authentication at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information for email/ password authentication to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and User Email.
In this type of authentication, when you click the signature field to sign a document:
Click the "SIGN NOW" button, and then click the NEXT" button.
The Salesforce popup will appear. Specify your Salesforce credentials (ID and password). The document is signed. Please note, that if you are already logged into SigningHub through your Salesforce account, then this step will be skipped.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your Salesforce credentials at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and User Email.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
Specify your user ID (registered in Active Directory) and domain password. The document is signed.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your Active Directory credentials at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
Specify your ADFS credentials (user ID and domain password). The document is signed.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your Microsoft ADFS credentials at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
The Microsoft Office 365 popup will appear. Specify your Office 365 credentials (ID and password). The document is signed. Please note, that if you are already logged into SigningHub through your Office 365 credentials, then this step will be skipped.
The document will be signed.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and optionally User Email if the user email address is integrated with the Office 365 mailbox.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your Microsoft Office 365 credentials at the time of signing having a different email address and vice versa.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
The Microsoft Azure Directory popup will appear. Specify your Azure Directory credentials (Email and password). The document is signed. Please note, that if you are already logged into SigningHub through your Azure Active Directory credentials, then this step will be skipped.
The document will be signed.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your Microsoft Azure Active Directory credentials at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and User Email.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button. A signing request will be sent to your mobile device running the Freja eID app.
Approve it from the Freja eID app. The document is signed.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your Freja eID credentials at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name and User Email.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
The LinkedIn popup will appear. Specify your LinkedIn credentials (ID and password). The document is signed. Please note, that if you are already logged into SigningHub through your LinkedIn account, then this step will be skipped.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your LinkedIn credentials at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and User Email.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
The Google popup will appear. Specify your Google credentials (ID and password). The document is signed. Please note, that if you are already logged into SigningHub through your Google account, then this step will be skipped.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your Google credentials at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and User Email.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
An authentication popup for configured third-party server will appear(e.g. Azure, LinkedIn, Google or any other authentication server that supports OAuth2 protocol). Specify your credentials (ID and password). The document is signed. Please note, if you are already logged into SigningHub through the same third-party account, then this step will be skipped.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your IDP credentials (OAuth2 supported protocol) at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and User Email.
In this type of authentication, when you click the signature field to sign a document:
Click the "Sign" button.
An authentication popup for configured third-party servers will appear(e.g. Azure, LinkedIn, Google or any other authentication server that supports OIDC protocol). Specify your credentials (ID and password). The document is signed. Please note, that if you are already logged into SigningHub through the same third-party account, then this step will be skipped.
User has the flexibility to use different email addresses while authenticating at logging and signing time. In case you have logged in through email/password authentication (i.e. SigningHub ID), you can authenticate using your IDP credentials (OIDC supported protocol) at the time of signing having a different email address and vice versa.
Workflow history and workflow evidence report logs following information to keep the history of how the user authenticated at signing time. i.e. Authentication Profile Name, User Name and User Email.
In this type of authentication, when your mobile device is registered and you select a signing capacity having QES as a level of assurance to sign a document:
Click the "Go to field" button and then click on the "Sign" button. An authentication request will be sent to your registered mobile device for remote authorisation. In case you want to withdraw the remote authorisation request, click on the "Cancel Request" button.
Run the SigningHub app (Android or iOS) on your mobile device and log in with the same account credentials through which you have logged in from the SigningHub web.
A popup will appear on your mobile device to authorise your signature through touchID or PIN. Upon authorisation, the document is signed.
You cannot add your signatures on a document if you don't have a SigningHub account.
The signature appearances are managed from your personal settings.
To use the Remote Authorised Signing (RAS) feature:
Your mobile device must be running the SigningHub native app (i.e. iOS or Android), and
Your mobile must be registered in your SigningHub web and SigningHub native app should be logged in with the same ID through which SigningHub web is logged in.
This feature is subject to your signing profile configurations and assigned role in the enterprise.
If you delete a pending document from your documents list without signing, it is considered declined.
The signing capacity with which a document is signed can be seen:
Inside the Activity details of the signer, and
Inside the Workflow History of the document, and
Inside the Workflow Evidence Report of the document
An invisible signature doesn't have any visible appearance on a document. However, it entails all other verifiable characteristics of e-signing i.e., Time Stamping, Certificate Chain, Certificate Status, etc.
Font colour will not be applicable in Signature Appearance while performing signature on any PDF/A document with "CMYK" colour space in order to ensure PDF/A compliance.
SigningHub produces the "XAdES-Baseline-LTA" ETSI-compliant signatures for XML documents but for backward compatibility with ADSS Server, version 6.9 or less SigningHub will produce the XAdES Extended signature on base of key "ES-X-L" added in web.config file.
When signing an XML file, the different Commitment Type Indications can be selected that are:
Proof of origin indicates that the signer recognizes to have created, approved, and sent the signed data object.
Proof of receipt indicates that the signer recognizes to have received the content of the signed data object.
Proof of delivery indicates that the TSP providing that indication has delivered a signed data object in a local store accessible to the recipient of the signed data object.
Proof of sender indicates that the entity providing that indication has sent the signed data object (but not necessarily created it).
Proof of approval indicates that the signer has approved the content of the signed data object.
Proof of creation indicates that the signer has created the signed data object (but not necessarily approved, nor sent it).
Whenever a pending document is signed, the signatures quota of the respective document owner's account is consumed, and hence their available count is decreased by one.
Fill in the field's data accordingly and click the "Next" button to move to the next field for data entry. Continue till you reach the last field assigned to you. SigningHub will display the total and traversed counts of your assigned fields accordingly.
OTP authentication will not work in cases of RAS, Server-side Signing using CSC and Local side signing.
Signatures quota consumed on signing when performing digital signatures (PKI signatures) performed using all levels of assurance except Simple Electronic Signature (eSignature) if the "SIMPLE_ELECTRONIC_SIGNATURES" module is enabled in the license.
Simple Electronic Signatures quota consumed on signing when performing electronic signature (Non-PKI signatures) using level of assurance Simple Electronic Signature (eSignature) if "SIMPLE_ELECTRONIC_SIGNATURES" module enabled in the license.
If the "SIMPLE_ELECTRONIC_SIGNATURES" module is disabled in the license then the system will work as of today and the signatures quota (PKI or Non-PKI signatures) consumed when performing signing using all levels of assurance.
You cannot perform a signature without adding an attachment if a mandatory attachment field has been assigned to you. This validation will not work in the case of signing the XML or Word file.
If the recipient tries to close the document package without performing all of their required actions, a warning will be displayed.
In the case of Simple Electronic Signature (SES), an enterprise user will only be able to use Signature Appearance Design, if the "Allow users to use the signature appearance for Simple Electronic Signatures" check box is enabled in the Configure Signature Appearance, against the user's role.
In the case of Simple Electronic Signature (SES), for an individual user, the Signature Appearance Design drop-down is available but by default, no signature appearance is selected. In order to use the signature appearance the user can select any allowed signature appearance from the drop-down.
In the "Sign" dialogue box, the user's default location will be shown, as configured in the user's personal settings. In the case of an unregistered user:
if the auto-detect location checkbox is checked, and the GeoIP connector has been configured, the system will pick the location and time zone using the GeoIP connector.
If either the auto-detect location checkbox is unchecked, the GeoIP connector has not been configured, or the GeoIP connector is faulty or not functional, the system will use the location and time zone of the document owner.
Based on the type of users, the following mentioned signature appearances will be available:
In the case of an enterprise user, all the signature appearances are allowed in the user role.
In the case of an individual user, all the signature appearances are allowed in the user's service plan.
In the case of an unregistered user:
If the document owner is an enterprise user, all the signature appearances are allowed in the document owner's user role.
If the document owner is an individual user, all the signature appearances are allowed in the document owner's service plan.
In case of a Simple Electronic Signature (SES) signature stamp, against the "Signed by" attribute:
the system will show the name of the user as configured in the user's profile in their personal settings.
in case of an unregistered user, the system will show the name of the unregistered user as saved in the document owner's contacts.
In the case of Electronic Seal (eSeal), the user will now be able to select the allowed signature appearance design, signing capacity, contact information and location.
After sharing the document, when it is the turn of the electronic seal recipient for signing, the electronic seal is automatically signed using the configured settings, without any user interaction.
The signature Policy is not supported with eID Easy signing.
The following OTP preference will be followed while signing, in case of configuration of field-level OTP, Document Signing OTP Authentication, and Secondary Authentication against the Signing Server:
| Field-level OTP is configured | Document Signing OTP Authentication OTP is configured | Secondary Authentication against the Signing Server is configured | OTP preference |
|---|---|---|---|
No | No | No | - |
Yes | Yes | Yes | Field-level OTP |
Yes | No | No | Field-level OTP |
Yes | Yes | No | Field-level OTP |
Yes | No | Yes | Field-level OTP |
No | Yes | No | Document Signing OTP Authentication |
No | Yes | Yes | Document Signing OTP Authentication |
No | No | Yes | Secondary Authentication against the Signing Server |
In the case of CSC Signing:
Whenever a user clicks on the "Sign Now" button, to sign the document, the document will be locked. While the document is locked, other recipients can not process the document. The document will automatically unlock in the case:
The signature has been successfully applied.
A period of 5 minutes has passed since the document was locked. (If you refresh or kill the browser window after clicking on the "Sign Now" button, the document will unlock after 5 minutes has passed since the document was locked.)
Any exception has occurred from SigningHub or the CSC Server.
Any cancel action has been performed after clicking the "Sign Now" button.
If the package has multiple documents, the locking functionality will only lock the document being signed, and not the whole package.
The document-locking functionality also works in the case of Bulk Signing.
