1 of 16

Add your signature

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.

Add your Signature

.
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.
1. SigningHub will prompt you to (if it is configured for you).
2. 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.
3. Signing servers are based on service plan configurations, and will display the signing server for server-side and client-side signing both.
4. Select one of the signing servers to perform the signature.
5. 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.
6. 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.
7. 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.
8. 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.
9. Click on the SIGN NOW button to proceed with signing.
10. 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.
11. 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.
12. 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.
13. 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.
14. Based on your Signature Settings, the authentication method may change.
15. 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.
1. The document is now signed, and your signature will be displayed in the same area of your document as per the selected signature appearance.
2. The document status will be changed from "Pending" to "Signed".
3. The system will notify the respective document owner about your signing through an email.
4. 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.
5. 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.
6. 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.
7. 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:
- 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.

Client-side (Local) Signing using T1C or ADSS (Go>Sign Desktop)

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.

Local Signing through the Microsoft Edge browser

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.

Server Side Signing using eID, ADSS or CSC

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
LinkedIn
Google
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.

No Authentication

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.

One Time Password

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.

Time-based One-Time Password

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.

SigningHub ID

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.

Salesforce

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.

Microsoft Active Directory

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.

Microsoft ADFS

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.

Microsoft Office 365

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.

Microsoft Azure Active Directory

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.

Freja eID

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.

Google

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.

OAuth2

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.

OIDC

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.

Remote Authorisation Signing (RAS)

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:
1. Your mobile device must be running the SigningHub native app (i.e. iOS or Android), and
2. 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.
3. 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:
1. Inside the Activity details of the signer, and
2. Inside the Workflow History of the document, and
3. 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:
1. Proof of origin indicates that the signer recognizes to have created, approved, and sent the signed data object.
2. Proof of receipt indicates that the signer recognizes to have received the content of the signed data object.
3. 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.
4. Proof of sender indicates that the entity providing that indication has sent the signed data object (but not necessarily created it).
5. Proof of approval indicates that the signer has approved the content of the signed data object.
6. 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:
1. 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.
2. 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:
1. In the case of an enterprise user, all the signature appearances are allowed in the user role.
2. In the case of an individual user, all the signature appearances are allowed in the user's service plan.
3. 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:
1. the system will show the name of the user as configured in the user's profile in their personal settings.
2. 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:
In the case of CSC Signing:
1. 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.
2. If the package has multiple documents, the locking functionality will only lock the document being signed, and not the whole package.
3. The document-locking functionality also works in the case of Bulk Signing.

XML signing

Introduction

SigningHub allows its users to sign documents in XML format and supports ETSI XAdES signature in Enveloped mode. XAdES stands for “XML Advanced Electronic Signatures” and is a set of standards published by ETSI to support European requirements for qualified electronic signatures. SigningHub supports these ETSI XAdES signatures formats:

XAdES Baseline Signatures (ETSI EN 319 132-1):

XAdES-B-LTA (Signature providing Long Term Availability and Integrity of Validation Data): In case of XAdES-B-LTA; XAdES-B-B, XAdES-B-T and XAdES-B-LT are being created first. XAdES-B-LTA is created by adding ArchiveTimeStamp in above mentioned signatures.

Enveloped: The XML signature is embedded within the original XML file.
To perform XAdES Extended signature for XML document, following key needs to be added in web.config of Web and API: <add key="XADES_SIGNATURE_TYPE" value="" /> For the tag with "XADES_SIGNATURE_TYPE" key, set the value "ES-X-L", SigningHub will perform a XAdES Extended signature for backward compatibility with ADSS Server version 6.9 or lesser. If it's not present, then SigningHub will work as of today and perform the "XAdES-Baseline-LTA" ETSI compliant signatures.

How it works?

Configure a signing profile as a prerequisite, in ADSS.
Configure a verification profile, in ADSS.
To perform XML signing, you must configure a connector, in SigningHub Admin.
Configure a signing profile, in SigningHub Admin.
Configure a verification profile, in SigningHub Admin.
Add the signing profile and verification profile to the service plan
Create a workflow with an XML document, upload an XSLT style sheet, and share the workflow
Once you've shared the workflow, log in to your SigningHub Web account and sign the document.

Configure a Singing Profile in ADSS

For XML signing a signing profile is configured in ADSS Signing Service.

To configure the signing profile for XML signature follow these steps:

In the "Select Signature Type" section, check "PKCS#1" and copy the Profile ID because it would be used in SigningHub Admin. Then click the "Next" button.
In the "Advanced Settings" tab, keep all check boxes unselected and click the "Save" button.

Configure a Verification Profile in ADSS

For XML signature verification, a verification profile is configured in ADSS Verification Service.

To configure verification profile for XML signature follow these steps:

Copy the Profile ID because it would be used in SigningHub Admin.
SigningHub creates the PKCS#1 signature for using signing service and further XAdES Signature enhancement is done via verification service.
1. By default, SigningHub produces XAdES-B-LTA signature. For XAdES Baseline Signatures, in the "Signature Settings" tab, make the following changes:
2. SigningHub will perform a XAdES Extended signature for backward compatibility with ADSS Server version 6.9 or lesser. For XAdES Extended Signatures, in the "Signature Settings" tab, make the following changes:

Configure a Connector in SigningHub Admin

To see in detail, how to create an ADSS Server Connector in SigningHub, click here.

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "ADSS Server" as the "Provider".

In the "Details" section, fill in the required fields.

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Paste the earlier copied Profile ID, while creating a Signing Profile in the ADSS, in the highlighted field below:

Configure a Verification Profile in SigningHub Admin

Make the following configurations to a verification profile in SigningHub Admin:

Paste the earlier copied Profile ID, while creating a Verification Profile in the ADSS, in the highlighted field below:

Add Signing Profile and Verification Profile to a Service Plan

Make the following configurations to a service plan in SigningHub Admin:

Select and add the earlier configured Signing Profile and Verification Profile, in a service plan in SigningHub Admin, as shown below:

SigningHub API Configurations

Make the following configurations to SigningHub API:

Get the authentication token of a user using SigningHub API.
Add a document package from SigningHub API.
Upload the document via stream/base with document extension .xml. Set the "x-convert-document" to false. To upload an XSLT Style sheet to transform an XML document into an HTML formatted PDF document on SigningHub viewer, the following API will be executed against the same document ID and name, as uploaded in the above step.
Add Collaborator(s) as per requirement.
Add Digital Signature Field. For XML Signing only one (Digital Signature) can be added for a collaborator per document. A field would be added on the last page on the bottom right corner.
Share the workflow.

Where an XSLT Style sheet has been applied to an XML document, upon opening the document on SigningHub Web, by default, the document will appear in the HTML-formatted view.
To switch between the plain XML view and the HTML-formatted view, the user can click the "Toggle" button available in the kebab menu in the document viewer screen.
The "Toggle" button will only appear when a XSLT Style sheet has been applied to the XML document.

SigningHub Web Signing

To sign the document, follow the below-mentioned steps:

Open SigningHub Web and open the XML document through the document listing. click on the signature field and then click "SIGN".
In case of signing an XML document, optionally you may also specify "Commitment Type Indication". SigningHub populates the pre-defined value of this field from your Personal Signing Details. When specified they will become a permanent part of your XML signature.
When signing an XML file, the different Commitment Type Indications that can be selected 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).
After signing the document, you can view "Signature Verification" for details.

Only one signature can be performed per document in XML format.
XML signing can be performed via single or bulk sign API.
XML signing is supported via all signing servers except for CSC Server.
Native Apps and Mobile Web do not support XML signing through the document viewer.
An XSLT Style sheet can not be applied to an already signed XML document.

Word document signing

Introduction

SigningHub allows its users to sign Word documents (having the .docx format) containing a signature line. The documents are allowed to retain their original format and are not converted to .pdf. This requires the configuration of a signing profile and a verification profile in ADSS. Configuration of a connector, a signing profile, a verification profile, and a service plan in SigningHub Admin. Once the configurations have been made, create a workflow with a Word document, and share the workflow. After sharing the workflow, sign the document via either SigningHub API or SigningHub Web.

XAdES-X-L (XAdES-X with Long-term Validation Data)

XAdES-X-L, short for "XAdES-X with Long-term Validation Data," is an advanced electronic signature format supported by SigningHub. This signature format aligns with ETSI standards, specifically tailored to meet European requirements for qualified electronic signatures. XAdES-X-L extends the capabilities of XAdES-X signatures by incorporating Long-term Validation Data. This ensures the long-term integrity and availability of validation data associated with the signature.

How it works?

Configure a signing profile as a prerequisite, in ADSS.
Configure a verification profile, in ADSS.
Configure a connector, in SigningHub Admin.
Configure a signing profile, in SigningHub Admin.
Configure a verification profile, in SigningHub Admin.
Add the signing profile and verification profile to the service plan.
Create a workflow with a Word document, and share the workflow.
Once you've shared the workflow, sign the document via either SigningHub API or SigningHub Web.

Configure a Singing Profile in ADSS

For Word document signing a signing profile is configured in ADSS Signing Service.

To configure a signing profile for signing a Word document, follow these steps:

In the "Select Signature Type" section, check "PKCS#1" and copy the Profile ID because it would be used in SigningHub Admin. Then click the "Next" button.
In the "Advanced Settings" tab, enable the "Hash Signing Settings", and click the "Save" button.

Configure a Verification Profile in ADSS

For signature verification, a verification profile is configured in ADSS Verification Service.

To configure a verification profile, follow these steps:

Copy the Profile ID because it would be used in SigningHub Admin.
SigningHub creates the PKCS#1 signature for using the signing service. In the "Signature Settings" tab, make the following changes:

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "ADSS Server" as the "Provider".
In the "Details" section, fill in the required fields.

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Paste the earlier copied Profile ID, while creating a Signing Profile in the ADSS, in the highlighted field below:

The hashing algorithm for the signing profile in SingingHub, should be the same as the hashing algorithm selected while creating a signing profile in ADSS.

Configure a Verification Profile in SigningHub Admin

Make the following configurations to a verification profile in SigningHub Admin:

Paste the earlier copied Profile ID, while creating a Verification Profile in the ADSS, in the highlighted field below:

Add Signing Profile and Verification Profile to a Service Plan

Make the following configurations to a service plan in SigningHub Admin:

Select and add the earlier configured Signing Profile and Verification Profile, in a service plan in SigningHub Admin, as shown below:

SigningHub API Configurations

Make the following configurations to SigningHub API:

Get the authentication token of a user using SigningHub API.
Add a document package from SigningHub API.
Upload the document via stream/base with document extension .docx. Set the "x-convert-document" to false.
Share the workflow.

The Word document being uploaded must have the signature line(s) along with the email addresses of the signer(s).

Signing via SigningHub API

To sign the document via SigningHub API:

Sign the workflow.
In case of bulk signing, use the below API.

Signing via SigningHub Web

To sign the document via SigningHub Web, follow the below-mentioned steps:

Open SigningHub Web and open the Word document through the document listing. Click on the signature field and then click "Sign".
After signing the document, you can view "Signature Verification" for details.

The Word document can also be signed via bulk sign, on SigningHub Web.

Electronic seal signing

Introduction

SigningHub allows you to add electronic seals in a workflow. Electronic Seal (eSeal), Advanced Electronic Seal (AdESeal), and Qualified Electronic Seal (QESeal) are the levels of assurance available for an electronic seal. Adding electronic seals will consume signatures quota of your (document owner's) account. Adding an electronic seal is subject to your SigningHub license, service plan configuration and the assigned enterprise user role.

How it works?

Enable the "Electronic Seals" module in your SigningHub license.
Allow the electronic seals module against the role of administrator, in SigningHub Admin.
To perform electronic seal signing, you must configure a connector, in SigningHub Admin.
Configure an electronic seal profile, in SigningHub Admin.
Configure an electronic seal against your service plan, in SigningHub Admin.
Configure the electronic seal against an enterprise user role, in SigningHub Web.
Create an electronic seal for your enterprise, in SigningHub Web.
Once an electronic seal has been created for your enterprise, you can add this electronic seal to a workflow.
Add an electronic seal field to your document.
Signing of an electronic seal.

Enable "Electronic Seals" in your SigningHub License

The Electronic Seals feature is available through the license, if the "ELECTRONIC_SEALS" module is enabled in the license. When "ELECTRONIC_SEALS" module is enabled, it will consume the quota of "Signatures". Contact the SigningHub support and request them to enable this module in your license.

Configure the Role of Administrator in SigninHub Admin

Make the following configurations against the administrator role.

From the Details screen, allow the "Electronic Seal Profiles" module for this role.

By default, the "Electronic Seal Profiles" module is unchecked. In order to use Electronic Seal Profiles, this module has to be manually allowed against a role.

Configure a Connector in SigningHub Admin

Configure a connector, as shown below, for ADSS Electronic Seal or CSC Electronic Seal, respectively.

ADSS Electronic Seal Connector

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "ADSS Server" as the "Provider".
In the "Details" section, fill in the required fields.

CSC Electronic Seal Connector

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "CSC Electronic Seal" as the "Provider".
In the "Details" section, fill in the required fields.

Currently, "Client Credentials" is the only option available for the Auth Type in the CSC Electronic Seal connector.

Configure an Electronic Seal Profile in SigningHub Admin

Configure an electronic seal profile, as shown below, for ADSS Electronic Seal or CSC Electronic Seal, respectively.

ADSS Electronic Seal Profile

Make the following configurations to an electronic seal profile in SigningHub Admin:

Select the ADSS Server connector created earlier, and fill in the required fields:

CSC Electronic Seal Profile

Make the following configurations to an electronic seal profile in SigningHub Admin:

Select the CSC Connector created earlier, and fill in the required fields:

Configure an Electronic Seal against your Service Plan in SigningHub Admin

Configure an electronic seal against your service plan, as shown below, for ADSS Electronic Seal or CSC Electronic Seal, respectively.

ADSS Electronic Seal Signing Server

Make the following configurations to a service plan in SigningHub Admin:

From the "Basic Information" section, select and add the "Electronic Seals" feature to service plan.
From the "Signatures" section, add the electronic seal signing server.

CSC Electronic Seal Signing Server

Make the following configurations to a service plan in SigningHub Admin:

From the "Basic Information" section, select and add the "Electronic Seals" feature to service plan.
From the "Signatures" section, add the electronic seal signing server.

The Electronic Seals feature is only available for "Enterprise" service plan type.

Configure the Electronic Seal against an Enterprise Role in SigningHub Web

Make the following configurations against an enterprise role:

From the "Enterprise Configuration", allow the "Electronic Seals" against this user role.

Create an Electronic Seal in SigningHub Web

Configure an electronic seal, as shown below, for ADSS Electronic Seal or CSC Electronic Seal, respectively.

ADSS Electronic Seal

Make the following configurations to an electronic seal in SigningHub Web:

From the "Basic Information" section, select the signing server, and fill in the required fields.

CSC Electronic Seal

Make the following configurations to an electronic seal in SigningHub Web:

From the "Basic Information" section, select the signing server, and fill in the required fields.

The electronic seal feature works with all CSC-based TSPs that support the OAuth 2.0 Client Credentials flow (authType=oauth2client), and credentials having Explicit authMode protection via only a PIN.

Add an Electronic Seal to a Workflow in SigningHub Web

After you have added all the documents in a workflow package, follow the below-mentioned steps to add an electronic seal:

Click "Add an electronic seal".
From the "Select Electronic Seal" drop down, select the electronic seal that you want to add. Only the electronic seals available for use, based on the document owner's user role, will be displayed in this drop down.

Add an Electronic Seal field to a Workflow in SigningHub Web

Follow the below-mentioned steps to add an electronic seal field in a workflow:

Select the document from the information panel's 'Pages' tab, on which an electronic seal is required.
Select the electronic seal from the information panel's 'Recipeints' tab, for whom you want to add an electronic seal field.
Click the "Electronic Seal" field, and drop it on the document.

Electronic Seal Signing in SigningHub Web

After sharing the document, when it is the turn of the electronic seal to be applied, the electronic seal is automatically signed using the configured settings. An electronic seal is signed without any user interaction. An on-screen notification is sent to the document owner when an electronic seal is signed. If for any reason the electronic seal signing fails, the system sends an email to the electronic seal owner and the electronic seal will have to be signed manually.

To check the electronic seal signature verification details:

Click on the electronic seal signatures.
Click verification in the information panel.

Electronic seal signing logs are maintained under "User Activity Logs", "Workflow History", and "Workflow Evidence Report".

eID Easy signing

Introduction

SigningHub supports performing server-side signing with eID Easy. eID Easy provides a simple API for Qualified Electronic Signature methods as well as for strong customer authentication for Remote Signing Service Providers that do not support the CSC interface.

How it works?

To perform eID Easy signing, you must configure an eID Easy connector, in SigningHub Admin.
Configure the connector in a signing profile, in SigningHub Admin.
Configure a signing profile using the connector, in SigningHub Admin.
Add Signing Server to your enterprise user role that you want to use for eID Easy signing.
Allow the Qualified Electronic Signature (QES) level of assurance against the user role.
Open a document having a Qualified Electronic Signature field and sign the document using the eID Easy Signing Server.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "eID Easy" as the "Provider".

In the "Details" section, fill in the required fields.

Configure a Signing Profile in SigningHub Admin

To see in detail, how to create a signing profile in SigningHub, click here. Make the following configurations to a signing profile in SigningHub Admin:

Select the eID Easy Connector created earlier, in the highlighted field below:

Add Signing Profile to a Service Plan in SigningHub Admin

Make the following configurations to a service plan in SigningHub Admin:

In the "Signature" section of the service plan, select and add the earlier configured signing profile, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signing Server Preferences" tab, add the signing server.

Allow the QES Level of Assurance against a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Document Settings" tab, add the Qualified Electronic Signature (QES) level of assurance.

eID Easy Signing

To perform eID Easy signatures, follow the below-mentioned steps:

From the document listing, open a the document having a Qualified Electronic Signature field that you want to sign.
Click on the signature field and click "Sign".
Select 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]/v4/custom-cades-digest-webhook", is configured against the "Custom CAdES digest webhook" property in the eID Easy.
After signing the document, you can view "Signature Verification".

The signature Policy is not supported with eID Easy 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).
Bulk signing is not supported with the eID Easy Server.
The signing logs are maintained under "User Activity Logs", "Workflow History", and "Workflow Evidence Report".

CSC signing

Introduction

The Cloud Signature Consortium (CSC) is a standard protocol for cloud-based digital signatures that supports web and mobile applications and complies with the most demanding electronic signature regulations in the world. The goal is to provide a common technical specification that will make solutions interoperable and suitable for uniform adoption in the global market, and to meet the highest level requirements of the European Union’s regulation on Identification and Trust Services (eIDAS). SigningHub supports the Cloud Signature Consortium (CSC) API protocol, this enables customers to leverage Remote Signing Service Providers (RSSP) for signing documents. Support for CSC within SigningHub now means customers can not only use SigningHub with Ascertia ADSS Signing Server but also independently with a CSC compliant RSSP.

SigningHub supports Cloud Signature Consortium (CSC) signing via the following two flows:

CSC Signing - Client Credentials Flow
CSC Signing - Authorisation Code Flow

CSC Signing - Client Credentials Flow

How it works?
Configure a Connector in SigningHub Admin
Configure a Signing Profile in SigningHub Admin
Add Signing Profile to a Service Plan in SigningHub Admin
Add Signing Server to a User Role in SigningHub Web
Specify the CSC User ID against your profile in SigningHub Web
CSC Signing

How it works?

To perform CSC signing, you must configure a CSC connector, in SigningHub Admin.
Configure a signing profile using the connector, in SigningHub Admin.
Configure the signing profile to the service plan, in SigningHub Admin.
Add Signing Server to your enterprise user role that you want to use for CSC signing.
Specify your CSC User ID against your profile.
Sign the document using the CSC Signing Server via SigningHub Web or API.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "CSC" as the "Provider".
In the "Details" section, choose "Client Credentials" as the "Auth Type".

A call back URL has to be registered with the CSC (Cloud Signature Consortium) signing server. The URL where the user will be redirected after the authorisation process has completed. Here is the format of call back URL: "{DEPLOYMENT_WEB_URL}/CSC/OAuth/CallBack" For example if your SigningHub site is "https://web.signinghub.com" then the Callback URL for SigningHub will be "https://web.signinghub.com/CSC/OAuth/CallBack".

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Select the CSC Connector created earlier, in the highlighted field below:

Add Signing Profile to a Service Plan in SigningHub Admin

Make the following configurations to the service plan in SigningHub Admin:

In the "Signature" section of the service plan, select and add the earlier configured signing profile, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signing Server Preferences" tab, add the signing server.

Specify the CSC User ID against your profile in SigningHub Web

Make the following configurations to your profile in SigningHub Web:

In your "Profile Information" tab, specify the "Cloud Signature Consortium (CSC) User ID".

CSC Signing

Sign the document using the CSC Signing Server via SigningHub Web or API.

Signing via SigningHub Web

To perform CSC signatures via SigningHub Web, follow the below-mentioned steps:

From the document listing, open a document having the signature field that you want to sign.
Double-click on the signature field and select the CSC Signing Server.
Click the "Sign" button and based on your CSC Signing Server configurations, provide the authorization details for Explicit (PIN/OTP/Both), Implicit or OAuth 2.0 authorization. Once the authorization is complete the document will be signed.

The signing logs are maintained under "User Activity Logs", "Workflow History", and "Workflow Evidence Report".
In 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 recipient can not process the document. The document will automatically unlock in 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 a period of 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 case of Bulk Signing.

Signing via API

To perform CSC signatures via API, follow the below-mentioned steps:

Use the "Authenticate" API of SigningHub to get the authentication token of the user who is performing the signatures.
The signature application (SigningHub) uses the "Get RSSP Information" API to get the RSSP (Remote Signing Service Provider) information that is needed to perform CSC Signing.
The signature application (SigningHub) uses the "info" API of the CSC server which returns the information about the RSSP (Remote Signing Service Provider) and the list of API methods it has implemented. This method shall be implemented by any RSSP conforming to this specification.
The signature application (SigningHub) gets the access token using the "oauth2/token" API with "client_credentials" as grant_type using the RSSP client credentials (client ID and conditionally a client secret).
The signature application (SigningHub) gets the list of credentials associated with a user identifier using the "credentials/list" RSSP API or if the RUT filtration is required call the "Get Filtered Credential List" API of SigningHub. A user may have one or multiple credentials hosted by a single remote signing service provider.
The signature application (SigningHub) gets the information on a signing credential, its associated certificate, and a description of the supported authorization mechanism using the "credentials/info" API of the CSC server.
If the "authorization_required" parameter is true, in response to the "Get RSSP Information" API, the "Get Account Token" API shall be used to get the account_token which will be used to hit the "oauth2/authorize" endpoint.
Use the "Get Document Hash" API of SigningHub to get the hash of the document.
Signature application (SigningHub) can use any one of the following APIs of the CSC server for authorization of credential ID, based on the response of the "credentials/info" API of the CSC server:
1. "credentials/sendOTP" API to start the online OTP mechanism associated with a credential ID for Explicit (OTP) authorization.
2. "credentials/authorize" API to authorize access to the credential ID for signing for Explicit (OTP/PIN) or Implicit authorization. The SAD received in response shall be used in the "signatures/signHash" API request.
3. "oauth2/authorize" API to initiate an OAuth 2.0 authorization flow for the OAuth 2.0 authorization. The authorization is returned in the form of an authorization code, which the signature application shall then use to obtain the SAD with "credential" as scope. To get the SAD, use the "oauth2/token" API with "authorization_code" as the grant_type. The SAD received in response shall be used in the "signatures/signHash" API request.
The signature application (SigningHub) calculates the remote digital signature of one or multiple hash values provided in input using the "signatures/signHash" API of the CSC server. This method requires credential authorization in the form of Signature Activation Data (SAD).
Use the "Embed Signature" API of SigningHub to embed signatures in the document.
The signature application (SigningHub) uses one of the following APIs of the CSC server for revoking access tokens, as per the requirement:
1. "auth/revoke" API to revoke the service access token or refresh token.
2. "oauth2/revoke" API to revoke an OAuth 2.0 access token or refresh token.

CSC Signing - Authorisation Code Flow

How it works?
Configure a Connector in SigningHub Admin
Configure a Signing Profile in SigningHub Admin
Add Signing Profile to a Service Plan in SigningHub Admin
Add Signing Server to a User Role in SigningHub Web
CSC Signing

How it works?

To perform CSC signatures, you must configure a CSC connector, in SigningHub Admin.
Configure a signing profile using the connector, in SigningHub Admin.
Configure the signing profile to the service plan, in SigningHub Admin.
Add Signing Server to your enterprise user role that you want to use for CSC signing.
Sign the document using the CSC Signing Server via SigningHub Web or API.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "CSC" as the "Provider".
In the "Details" section, choose "Authorization Code" as the "Auth Type".

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Select the CSC Connector created earlier, in the highlighted field below:

Add Signing Profile to a Service Plan in SigningHub Admin

Make the following configurations to the service plan in SigningHub Admin:

In the "Signature" section of the service plan, select and add the earlier configured signing profile, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Admin:

Against your user role, in the "Singing Server Preferences" tab, add the signing server.

CSC Signing

Sign the document using the CSC Signing Server via SigningHub Web or API.

Signing via SigningHub Web

To perform CSC signatures via SigningHub Web, follow the below-mentioned steps:

From the document listing, open a the document having the signature field that you want to sign.
Click on the signature field, select the CSC Signing Server.
Input the CSC user credentials, provided by the CSC Signing Server.
Click the "Sign" button and based on your CSC Signing Server configurations, provide the authorization details for Explicit (PIN/OTP/Both), Implicit or OAuth 2.0 authorization. Once the authorization is complete the document will be signed.

The signing logs are maintained under "User Activity Logs", "Workflow History", and "Workflow Evidence Report".
In 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 recipient can not process the document. The document will automatically unlock in 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" button, the document will unlock after a period of 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 case of Bulk Signing.

Signing via API

To perform CSC signatures via API, follow the below-mentioned steps:

Use the "Authenticate" API of SigningHub to get the authentication token of the user who is performing the signatures.
The signature application (SigningHub) uses the "Get RSSP Information" API to get the RSSP (Remote Signing Service Provider) information that is needed to perform CSC Signing.
The signature application (SigningHub) uses the "info" API of the CSC server which returns the information about the RSSP (Remote Signing Service Provider) and the list of API methods it has implemented. This method shall be implemented by any RSSP conforming to this specification.
If the "authorization_required" parameter is true, in response to the "Get RSSP Information" API, the "Get Account Token" API shall be used to get the account_token which will be used to hit the "oauth2/authorize" endpoint.
The signature application (SigningHub) requests authorization for the user to access the RSSP resources using the "oauth2/authorize" API of the CSC server. The authorization is returned in the form of an authorization code, which the signature application shall then use to obtain an access token with "service" as scope. To get the access token the signature application (SigningHub) uses the "oauth2/token" API with "authorization_code" as the grant_type. If the "authentication_required" parameter is true, in response to the "Get RSSP Information" API, call the "Get Access Token | SAD" SigningHub API to get the Bearer/SAD token.
The signature application (SigningHub) gets the list of credentials associated with a user identifier using the "credentials/list" RSSP API or if the RUT filtration is required call the "Get Filtered Credential List" API of SigningHub. A user may have one or multiple credentials hosted by a single remote signing service provider.
The signature application (SigningHub) gets the information on a signing credential, its associated certificate, and a description of the supported authorization mechanism using the "credentials/info" API of the CSC server.
Use the "Get Document Hash" API of SigningHub to get the hash of the document.
The signature application (SigningHub) can use any one of the following APIs of the CSC server for authorization of credential ID, based on the response of the "credentials/info" API of the CSC server:
1. "credentials/sendOTP" API to start the online OTP mechanism associated with a credential ID for Explicit (OTP) authorization.
2. "credentials/authorize" API to authorize access to the credential ID for signing for Explicit (OTP/PIN) or Implicit authorization. The SAD received in response shall be used in the "signatures/signHash" API request.
3. "oauth2/authorize" API to initiate an OAuth 2.0 authorization flow for the OAuth 2.0 authorization. The authorization is returned in the form of an authorization code, which the signature application shall then use to obtain the SAD with "credential" as scope. To get the SAD, use the "oauth2/token" API with "authorization_code" as the grant_type. The SAD received in response shall be used in the "signatures/signHash" API request.
The signature application (SigningHub) calculates the remote digital signature of one or multiple hash values provided in input using the "signatures/signHash" API of the CSC server. This method requires credential authorization in the form of Signature Activation Data (SAD).
Use the "Embed Signature" API of SigningHub to embed signatures in the document.
The signature application (SigningHub) uses one of the following APIs of the CSC server for revoking access tokens, as per the requirement:
1. "auth/revoke" API to revoke the service access token or refresh token.
2. "oauth2/revoke" API to revoke an OAuth 2.0 access token or refresh token.

Remote Authorisation Signing (RAS)

Introduction

SigningHub provides Remote Authorised Signing (RAS) feature, to allow you to authorise a remote signature (done on server) using your registered mobile device(s), running any of the SigningHub native apps (i.e. Android or iOS). The device will have its user authentication built-in (touchID or PIN), so in a way you can also get two-factor authentication. The feature is available on those Android devices that support fingerprints verification, while in case of iOS devices, it can work with both touch ID or passcode verification. For RAS Signing configurations are required in the ADSS Server, SigningHub Admin, and SigningHub Web. Remote Authorisation Signing (RAS) supports the "Advanced Electronic Signature (AES)", "Qualified Electronic Signature (QES)", and "High Trust Advanced Signature (AATL)" levels of assurance. The availability of Remote Authorised Signing (RAS) feature is subject to your subscribed service plan and assigned role.

How it works?

Configure a SAM profile, in ADSS.
Configure a RAS profile, in ADSS.
Configure a signing profile, in ADSS.
Configure a certification profile, in ADSS.
Configure a connector, in SigningHub Admin.
Configure a signing profile, in SigningHub Admin.
Configure a certification profile, in SigningHub Admin.
Configure a verification profile, in SigningHub Admin.
Add the signing profile to a service plan, in SigningHub Admin.
Add the verification profile to a service plan, in SigningHub Admin.
Add Signing Server to your user role, in SigningHub Web.
Allow the configured level of assurance against the user role, in SigningHub Web.
Sign the document via SigningHub Web.

Configure a SAM Profile in ADSS

For remote signing a SAM profile is configured in ADSS SAM Service.

To configure a SAM profile for remote signing, follow these steps:

Copy the SAM Profile ID because it would be used in the upcoming steps.
In the "User Signature Key Pair Settings" section, select "SCAL2" option against the "Sole Control Assurance Level". Then click the "Save" button.

Configure a RAS Profile in ADSS

For remote signing a RAS profile is configured in ADSS RAS Service.

To configure a RAS profile for remote signing, follow these steps:

Copy the RAS Profile ID because it would be used in the upcoming steps.
In the "SAM Service Settings" section, enter the SAM Profile ID, copied earlier, and provide the required details.
In the "Credentials Authorisation Settings" section, check the "Implicit" option. Then click the "Save" button.

Configure a Signing Profile in ADSS

For remote signing a signing profile is configured in ADSS Signing Service.

To configure a signing profile for remote signing, follow these steps:

Copy the Signing Profile ID because it would be used in the upcoming steps.
In the "Select Signature Type" section, check "PKCS#1". Then click the "Next" button.

In the "Advanced Settings" tab, check the "Enable remote signing" checkbox, enter the RAS Profile ID, copied earlier, and provide the required details. Then click the "Save" button.

Configure a Certification Profile in ADSS

For remote signing a certification profile is configured in ADSS Certification Service.

To configure a certification profile for remote signing, follow these steps:

Copy the Certification Profile ID because it would be used in the upcoming steps.
In the "RAS Service Settings" section, check the "Enable key pair generation through RAS Service" checkbox, enter the RAS Profile ID, copied earlier, and provide the required details. Then click the "Save" button.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "ADSS Server" as the "Provider".

In the "Details" section, provide the "RAS Address" and fill in the required fields.

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

In the "Signing Method" section, check the "Enable Remote Authorisation" checkbox.
Enter the Signing Profile ID, copied earlier, in the highlighted field.

Configure a Certification Profile in SigningHub Admin

Make the following configurations to a certification profile in SigningHub Admin:

Select "Qualified Electronic Signature (QES)" as the "Level of Assurance".
Select "Remote Authorisation" as the "Key Protection Option".
Select the configured ADSS connector for certification purposes as the "Certification Authority Server".
Enter the Certification Profile ID, copied earlier, as the "Certification Service Profile ID". Then click "Save".

Remote Authorisation Signing (RAS) supports the "Advanced Electronic Signature (AES)", "Qualified Electronic Signature (QES)", and "High Trust Advanced Signature (AATL)" levels of assurance.

Configure a Verification Profile in SigningHub Admin

Make the following configurations to a verification profile in SigningHub Admin:

Select the configured ADSS connector for verification purposes as the "Signature Verification Server".
Enter the Certification Profile ID, copied earlier, as the "Verification Service Profile ID". Then click "Save".

Add Signing Profile to a Service Plan in SigningHub Admin

Make the following configurations to a service plan in SigningHub Admin:

Select and add the signing profile, configured earlier, in a service plan in SigningHub Admin.
Select the level of assurance which was selected in the certification profile, configured earlier. (For the purposes of this use case, the level of assurance is Qualified Electronic Signature (QES)).
In the "Signing Capacities" field, select the certification profile, configured earlier.

Add Verification Profile to a Service Plan in SigningHub Admin

Make the following configurations to a service plan in SigningHub Admin:

Select and add the verification profile, configured earlier, in a service plan in SigningHub Admin, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signing Server Preferences" tab, add the signing server, configured earlier.
In the "Server" section, select the signing profile, configured earlier, as the "Signing Server".

Allow the Configured Level of Assurance against a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Document Settings" tab, add the configured level of assurance. (For the purposes of this use case, the level of assurance is Qualified Electronic Signature (QES)).

RAS Signing via SigningHub Web

To sign the document via SigningHub Web, follow the below-mentioned steps:

Open SigningHub Web and open a document the document you want to sign. The level of assurance of the signature field must be the same as configured earlier. (For the purposes of this use case, the level of assurance is Qualified Electronic Signature (QES)).
Click on the "Signature" field, select the "Signing Capacity", configured earlier, 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 SigningHub app (Android or iOS) on your mobile device and log in using the credentials which you have used on SigningHub Web. Click on "Remote Authorisation" to view the authorisation requests.
If your device is not authorised for RAS Signing, follow the below-mentioned configurations for device registration:
- To select the configured RAS profile against a client, in ADSS Client Manager:
  - In the "RAS Service Settings" section against a client, select the configured RAS profile.
- Log into the SigningHub app using the credentials against which you want to register the device. Click on "Remote Authorisation" and your device will be registered after biometric or PIN verification
A pop-up will appear on your mobile device to authorise your signature through touchID or PIN. Upon authorisation, the document is signed.
After signing the document, click the three dots menu and select "Signature Verification" to view "Signature Verification" details. The signatures are verified through the ADSS verification service.

Remote Authorised Signing can be authorised through both SigninHub Native Apps as well as Go>Sign Desktop App.
Once the user has made the required configurations in ADSS Server and SigningHub, when the user logs into SigningHub Web, the user will be automatically registered in the SAM Service. The user can view their authorised devices by clicking the "User Devices" button, and their certificates by clicking the "User Keys" button. Once a user is registered in SAM Service, the "Remote Authorisation User ID" will be added in the user's "Personal Information" in Enterprise Settings>Users.
To configure user authentication settings for Go>Sign Mobile App Registration, in ADSS RAS Service:
- In the "User Authentication Settings for Go>Sign Mobile App Registration" section, select the user authentication method at the time of registration, as required.
To configure push notification settings, in ADSS RAS Service:
- In the "Push Notification Settings (FCM)" section, configure the settings for push notifications, as required.

Signing using Policy OID

Introduction
How it works?
Place the Policy Document in SigningHub Directory
Modify the Web.config file in SigningHub Directory
Place the Policy Document in ADSS Server Directory
Modify the policy.properties file in ADSS Server Directory
Configure a Go>Sign Profile in ADSS
Configure a Connector in SigningHub Admin
Configure a Signing Profile in SigningHub Admin
Add Signing Profile to a Service Plan
Add Signing Server to a User Role in SigningHub Web
Signing via SigningHub Web

Introduction

SigningHub supports all kinds of server side and local side signing using the Policy OID. When a user signs a document using SigningHub, the system applies a signature policy OID to ensure that the signature adheres to the predefined rules. This includes requirements such as cryptographic algorithms, key lengths, time-stamping, and other security measures specified by the policy. For recipients of signed documents, the signature policy OID serves as a reference point during verification. It allows them to confirm that the signature meets the necessary standards for validity and compliance. For this usecase, we are going to perform local side signing with ADSS using Policy OID.

How it works?

Place the Policy Document, in SigningHub Directory.
Modify the Web.config file, in SigningHub directory.
Place the Policy Document, in ADSS Server Directory.
Modify the policy.properties file, in ADSS Server directory.
Configure a Go>Sign signing profile as a prerequisite, in ADSS.
Configure a connector, in SigningHub Admin.
Configure a signing profile, in SigningHub Admin.
Add the signing profile to the service plan.
Add signing server to your enterprise user role.
Sign the document via SigningHub Web.

Place the Policy Document in SigningHub Directory

The policy document PDF needs to be placed, in the SigningHub deployment directory, at the following path:

[SigningHub Deployment Directory]\default\signaturepolicydocuments

Modify the Web.config file in SigningHub Directory

To apply the policy OID while signing, the Web.config file needs to be modified, in the SigningHub Directory.

Make the following modifications to the web.config file:

Provide the values of the "SignaturePolicyOID", "SignaturePolicyURI", "SignaturePolicyName" tags. Then save the changes and close the "Web.config" file. The "SignaturePolicyName" should be the same as the name of the policy document placed in the SigningHub deployment directory.

Place the Policy Document in ADSS Server Directory

The policy document PDF needs to be placed in the ADSS deployment directory, as the ADSS Server is being used for verification, at the following path:

[ADSS Deployment Directory]\service\policy

Modify the policy.properties file in ADSS Server Directory

To apply the policy OID while signing, the policy.properties file needs to be modified in the ADSS Server Directory.

Make the following modifications to the policy.properties file:

Add the "Policy IDs" and their "Directory Paths" in the policy.properties file. Then save the changes and close the "policy.properties" file. Add this information using the mentioned format ( Signature Policy ID = Location of the Signature Policy Document). A sample of the format has been highlighted below:

Configure a Go>Sign Profile in ADSS

For local signing, a Go>Sign profile is configured in Go>Sign Service. (In case of server side, a signing profile will need to be configured)

Make the following configurations to a Go>Sign profile:

From the "General" section, copy the Go>Sign Profile ID because it would be used in SigningHub Admin.
In the "Keystore Settings" section, check the "OS native API (MS CAPI & Mac Keychain)" option, as we want to use the certificates installed on your local machine.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "ADSS Server" as the "Provider".

In the "Details" section, fill in the required fields.

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Paste the earlier copied Go>Sign Profile ID, while creating a Go>Sign Profile in the ADSS, in the highlighted field below:

Add Signing Profile to a Service Plan

Make the following configurations to a service plan in SigningHub Admin:

Select and add the earlier configured Signing Profile, in a service plan in SigningHub Admin, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signing Server Preferences" tab, add the signing server

Signing via SigningHub Web

To sign the document via SigningHub Web, follow the below-mentioned steps:

Open SigningHub Web and open a document having a signature field that you want to sign.
Double-click on the signature field and select the Signing Server.
Then click on the signature field and then click "Sign".
After signing the document, you can view the "Verification Certificate".
The signatures can also be verified through the ADSS verification service's transaction logs which will reflect the "Signature Policy ID" and the "Signature Policy URI".

SigningHub supports all kinds of server side and local side signing using the Policy OID.

Local-side signing using T1C Server

Introduction

SigningHub supports performing local side signing with Trust1Connector (T1C). For this, SigningHub needs to be registered with the T1C platform and a T1C connector needs to be created in SigningHub to allow SigningHub to connect with the T1C app. The T1C app has to be installed on your local machine and the related HSM is attached to it while signing. Also, you should have full rights on the Trust1Connector service running on your machine. SigningHub will prompt you if any of the above-mentioned prerequisites is missing. T1C provides a solution to read the hardware tokens with minimum footprint and installations. It can interact with the hardware tokens by using javascript APIs which are implemented in SigningHub for local signing. TC1 can be used as an alternative to the Go>Sign Desktop for local signing. SigningHub supports the T1C SDK v3.8.6.

How it works?

Configure a connector, in SigningHub Admin.
Configure a signing profile, in SigningHub Admin.
Add the signing profile to the service plan.
Add the signing server to your enterprise user role.
Sign the document via SigningHub Web.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "T1C" as the "Provider".

In the "Details" section, fill in the required fields.

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Select the T1C Connector created earlier, in the highlighted field below:

Add Signing Profile to a Service Plan in SigningHub Admin

Make the following configurations to a service plan in SigningHub Admin:

In the "Signature" section of the service plan, select and add the earlier configured signing profile, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signing Server Preferences" tab, add the signing server.

Signing using T1C Server

To perform T1C signatures, follow the below-mentioned steps:

From the document listing, open a the document having a Signature field that you want to sign.
Double click on the signature field, select the T1C Signing Server.
Upon selecting the T1C Signing Server, the user consent dialog will appear. It will appear once for each user session. Click on the "Yes" button to proceed.
Click on the "Sign" button.
The system will prompt the user to input the token PIN to authorise the signing process.
After signing the document, you can view "Signature Verification".

If the T1C utility is not running on the user's system, SigningHub will show the below dialog.
- If the T1C utility is installed on the user's system, run the utility and click on "Try Again".
- If the T1C utility is not installed on the user's system, install the utility by clicking on the "click here" link and then click on "Try Again".
Bulk signing is also supported with the T1C Signing Server.
The signing logs are maintained under "User Activity Logs", "Workflow History", and "Workflow Evidence Report".
T1C supports PDF and XML document signing.

Local-side signing using ADSS Server

Introduction

SigningHub supports local signing through the Go>Sign Desktop app. The Go>Sign Desktop app has to be installed and should be running on your machine. The certificates that you want to perform signatures with should either be installed on your local machine, or be stored in the HSM token attached to your machine, based on the configurations of your Go>Sign profile. SigningHub supports the latest version of the Go>Sign Desktop app.

How it works?

Configure a Go>Sign signing profile as a prerequisite, in ADSS.
Configure a connector, in SigningHub Admin.
Configure a signing profile, in SigningHub Admin.
Add the signing profile to the service plan.
Add signing server to your enterprise user role.
Sign the document via SigningHub Web.

Configure a Go>Sign Profile in ADSS

For local signing, a Go>Sign profile is configured in Go>Sign Service.

Make the following configurations to a Go>Sign profile:

From the "General" section, copy the Go>Sign Profile ID because it would be used in SigningHub Admin.
In the "Keystore Settings" section:
1. If you want to sign documents using the certificates installed on your local machine, check the "OS native API (MS CAPI & Mac Keychain)" option.
2. If you want to sign documents using the certificates from your HSM token, check the "PKCS#11" option. Copy and paste the sample "Device Name" and the "Library Name" in their respective fields, and click the "Add" button.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "ADSS Server" as the "Provider".
In the "Details" section, fill in the required fields.

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Paste the earlier copied Go>Sign Profile ID, while creating a Go>Sign Profile in the ADSS, in the highlighted field below:

Add Signing Profile to a Service Plan

Make the following configurations to a service plan in SigningHub Admin:

Select and add the earlier configured Signing Profile, in a service plan in SigningHub Admin, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signing Server Preferences" tab, add the signing server.

Go>Sign Signing via SigningHub Web

To sign the document via SigningHub Web, follow the below-mentioned steps:

Open SigningHub Web and open a document having a signature field that you want to sign.
Double-click on the signature field and select the Go>Sign Signing Server. Upon selecting the signing server, the system will fetch all the certificates from your local machine or the HSM token attached, based on the configurations of your Go>Sign profile.
Then click on the signature field and then click "Sign".
After signing the document, you can view the"Signature Verification" details. The signatures are verified through the ADSS verification service.

Go>Sign signing supports PDF and XML document signing.

Signing based on National ID validation

Introduction

SigningHub supports local signing through unique RUT values that are exclusively assigned to each user. The users who wish to use the RUT based Go>Sign signing, need to modify the web.config files. The Go>Sign Desktop app has to be installed and should be running on your machine. Your RUT-based certificates that you want to perform signatures with, having the Subject Alternative Name value, must also be installed on your local machine. SigningHub supports the latest version of the Go>Sign Desktop app.

How it works?

Configure a Go>Sign signing profile as a prerequisite, in ADSS.
Modify the Web.config file, in SigningHub directory.
Configure a connector, in SigningHub Admin.
Configure a signing profile, in SigningHub Admin.
Add the signing profile to the service plan.
Add signing server to your enterprise user role.
Add the National ID to your Profile.
Sign the document via SigningHub Web.

Configure a Go>Sign Profile in ADSS

For local signing with RUT, a Go>sign profile is configured in Go>Sign Service.

Make the following configurations to a Go>Sign profile:

From the "General" section, copy the Go>Sign Profile ID because it would be used in SigningHub Admin.
In the "Keystore Settings" section, check "OS native API (MS CAPI & Mac Keychain)".

Modify the Web.config File in SigningHub Directory

To enforce the users to use the RUT values for signing, the Web.config file needs to be modified in the SigningHub Directory.

Make the following modifications to the web.config file:

Change the value of "ValidateRUT" tag to "True". Then save the changes and close the "Web.config" file.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "ADSS Server" as the "Provider".

In the "Details" section, fill in the required fields.

Configure a Signing Profile in SigningHub Admin

Make the following configurations to a signing profile in SigningHub Admin:

Paste the earlier copied Go>Sign Profile ID, while creating a Go>Sign Profile in the ADSS, in the highlighted field below:

Add Signing Profile to a Service Plan

Make the following configurations to a service plan in SigningHub Admin:

Select and add the earlier configured Signing Profile, in a service plan in SigningHub Admin, as shown below:

Allow Users to Add National ID

Make the following configurations to global settings in SigningHub Admin:

Check the "Allow Users to Add National ID" checkbox to allow the users to add their National ID to their profiles, as shown below:

Add Signing Server to a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signing Server Preferences" tab, add the signing server.

Add National ID to your Profile

Make the following configurations to your profile in SigningHub Web:

Copy the National ID, which is defined as the value of "Subject Alternative Name" from your certificate, and paste it in the "National ID" field, as shown below:

The National ID can also be provided at the time of new user registration.

Go>Sign Signing via SigningHub Web

To sign the document via SigningHub Web, follow the below-mentioned steps:

Open SigningHub Web and open a document having a signature field that you want to sign.
Double-click on the signature field and select the Go>Sign Signing Server. Upon selecting the signing server, the system will fetch all the certificates which have the same "Subject Alternative Name" value as the National ID, specified in your profile. If a National ID has not been provided or an invalid National ID has been provided, the system will not let the user sign the documents using the ADSS or CSC Signing Servers, given that the "ValidateRUT" tag in the web.config file has been set to "True".
Then click "Sign".
After signing the document, you can view "Signature Verification" details. The signatures are verified through the ADSS verification service.

Go>Sign signing supports PDF and XML document signing.
The National ID will be validated for both ADSS (as a local signing server) and CSC Signing Servers, if the "ValidateRUT" tag in the web.config file has been set to "True".

Signing via signature pad

Introduction

SigningHub allows users to sign via a signature pad. It involves integrating a specialized device that electronically captures handwritten signatures. This integration is seamless within the SigningHub platform, ensuring a straightforward process for users. Once integrated, users need to make the necessary configurations and connect the signature pad to their computer or tablet, typically via USB or Bluetooth to perform the signatures. While the user writes their signature on the pad using a stylus or pen-like tool, the signature's unique characteristics (such as shape, pressure, and speed) are recorded digitally. SigningHub then applies this captured signature to the document, ensuring it remains secure and legally binding.

How it works?

Configure a connector, in SigningHub Admin.
Add the connector to the service plan.
Configure the signature pad in the user role.
Set the signature pad as the default method.
Sign the document via signature pad.

Configure a Connector in SigningHub Admin

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "Signature Pad" as the "Provider".

In the "Details" section, fill in the required fields.

Add Connector to a Service Plan in SigningHub Admin

Make the following configurations to a service plan in SigningHub Admin:

In the "Signature" section of the service plan, enable the "Enable the Signature Pad to capture hand signature images while signing" option and add the earlier configured connector, as shown below:

Configure Signature Pad in a User Role in SigningHub Web

Make the following configurations to a user role in SigningHub Web:

Against your user role, in the "Signature Appearance" tab, enable the Signature Pad option.

Signature Pad can be used to perform hand signatures and initials, only on Desktop Web.

Set Signature Pad as the Default Method in SigningHub Web

Make the following configurations to 'My Settings' in SigningHub Web:

Against your 'Settings', in the "Signature Preferences" tab, set Signature Pad as the default hand signature method for Web Browsers.

Signature Pad can only be used to perform hand signatures, in-person hand signatures, and initials, only on Desktop Web.
If Signature Pad has been configured as the default initials method and the user tries to sign using native apps or mobile web, the user will not be able to perform initials and will be prompted to update the default initials method in the user's settings.

Signing via Signature Pad

To perform signatures via a Signature Pad, follow the below-mentioned steps:

From the document listing, open a document having a signature field that you want to sign.
Double-click on the signature field, and select a Signing Server for performing signatures.
Upon selecting a signing server, the browser will show a pop-up to connect the Signature Pad device. Click on the "Connect" button to connect the signature pad.
Once the signature pad has been connected, the user can perform signatures on the signature pad, and the signatures will be visible on the "SIGN" dialogue box in SigningHub.
- Clear: If the 'Clear' button is pressed, either on the SIGN dialogue box or on the signature pad, the signature pad will clear up, allowing you to retry your signatures.
- Cancel: If the 'Cancel' button is pressed, either on the SIGN dialogue box or on the signature pad, the SIGN dialogue box will close without the signatures being performed.
- OK: If the 'OK' button is pressed, either on the SIGN dialogue box or on the signature pad, the signatures will be applied to the document and the SIGN dialogue box will close.

The "Remember the captured signature for use throughout this document" option allows the user to use the captured signatures to sign all of the other assigned signature fields as well. If this option is unchecked, the user will have to perform signatures, using the signature pad, for each assigned field.
Even if the "Remember the captured signature for use throughout this document" option is enabled, the captured signatures stay in the memory as long as the user is on the document viewer screen and the session has not expired.
The signing logs are maintained under "User Activity Logs", "Workflow History", and "Workflow Evidence Report".
The Wacom STU Tablets that are supported for performing signatures are STU-430 and STU-500.
Signing via a signature pad is allowed for both enterprise and individual users, based on the configurations of their service plan.
SigningHub integrates the Wacom SDK and validates the Wacom license directly through the Wacom server, without any communication with the Wacom License Management Server. If a user does not renew their license within the grace period provided by Wacom, access to the Wacom integration within SigningHub will be disabled until the license is renewed.
For using Wacom STU tablets, all the browsers that implement WebHID should be supported. Thus, at the moment it is supported as a feature on:
- Chromium
- Google Chrome
- Microsoft Edge
- Opera

(Firefox and Safari have refused to implement this feature on the basis of security reasons, so it won't be supported.)

Signing behavior w.r.t signature appearance

Signing Behavior w.r.t Signature Appearance

The section details the signing behavior of the system with respect to whether the signature appearance and the logo have been configured against a signing server. Breakdown has been given on the basis of the two subscription types; Enterprise subscription, and Individual subscription.

Enterprise Subscription
Individual Subscription

Enterprise subscription

Signing Behavior w.r.t Signature Appearance

The signing behaviour of the system with respect to whether the signature appearance and the logo have been configured against a signing server, in the SigningHub Web, is as below:

Simple Electronic Signatures (Signature and In-Person Signatures)

Signature Appearance is configured against the signing server

Signature Logo is configured against the signing server

System Behaviour for the Sign Dialog

System Behaviour for the Applied Signature

PKI Signatures (Signature and In-Person Signatures)

Signature Appearance is configured against the signing server

Signature Logo is configured against the signing server

System Behavior for the Sign Dialog

System Behavior for the Applied Signature

Bulk Signing Behavior w.r.t Signature Appearance

The bulk signing behavior of the system with respect to whether the signature appearance and the logo have been configured against a signing server, in the SigningHub Web, is as below:

Simple Electronic Signatures (Signature and In-Person Signatures)

PKI Signatures (Signature and In-Person Signatures)

Simple Electronic Signatures (Signature and In-Person Signatures) & PKI Signatures (Signature and In-Person Signatures)

Individual subscription

Signing Behavior w.r.t Signature Appearance

The signing behavior of the system with respect to whether the signature appearance and the logo have been configured against a signing server, in the SigningHub Admin, is as below:

Simple Electronic Signatures (Signature and In-Person Signatures)

Signature Appearance is configured against the signing server

Signature Logo is configured against the signing server

System Behavior for the Sign Dialog

System Behavior for the Applied Signature

PKI Signatures (Signature and In-Person Signatures)

Signature Appearance is configured against the signing server

Signature Logo is configured against the signing server

System Behavior for the Sign Dialog

System Behavior for the Applied Signature

Bulk Signing Behaviour w.r.t Signature Appearance

The bulk signing behavior of the system with respect to whether the signature appearance and the logo have been configured against a signing server, in the SigningHub Admin, is as below:

Simple Electronic Signatures (Signature and In-Person Signatures)

Signature Appearance is configured against the signing server

Signature Logo is configured against the signing server

System Behavior for the Sign Dialog

System Behavior for the Applied Signature

PKI Signatures (Signature and In-Person Signatures)

Simple Electronic Signatures (Signature and In-Person Signatures) & PKI Signatures (Signature and In-Person Signatures)

In case of In-Person signatures, the appearance set against the ADSS signing server will be followed.
In case of signatures, the appearance set against the respective selected signing server will be followed.

OTP authentication

Introduction

OTP stands for "One-Time Password," and TOTP stands for "Time-based One-Time Password." Both are authentication methods that provide an additional layer of security beyond traditional passwords. In essence, OTPs, including TOTPs, are dynamic and time-sensitive, providing an effective means of securing digital accounts and transactions. When the documents are shared on the web with other users, it's important to upscale the security levels to prevent fraudulent attempts and bad actors from compromising your document security. SigningHub provides you with an option to configure One Time Password (OTP) and Time-based One Time Password (TOTP) for login authentication, document opening authentication, and document signing authentication.

How it works?

Configure the SMS and Email connectors, in SigningHub Admin
Configure OTP and TOTP against your service plan, in SigningHub Admin
Authentication via One Time Password (OTP) and Time-based One-Time Password (TOTP)
Login Authentication
Document Access Authentication
Document Signing Authentication
- Signing Server-level Authentication
- Recipient Permission-level Authentication
- Field-level Authentication
- OTP preference

Configuring Connectors in SigningHub Admin

Configure the "SMS Gateway" connector to be used for sending SMS OTPs, and the "Email Gateway" connector to be used for sending Email OTPs.

Configure an SMS Connector

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "Twilio" as the "Provider".

In the "Details" section, fill in the required fields.

Configure an Email Connector

Make the following configurations to a connector in SigningHub Admin:

In the "Basic Information" section, choose "SMTP Server" as the "Provider".

In the "Details" section, fill in the required fields.

Service Plan Configuration in SigningHub Admin

Make the following configurations against the service plan.

From the Settings screen, check the "Enable One Time Password (OTP)" and the "Enable Time based One Time Password (TOTP)" checkboxes, as required.

Authentication via One Time Password (OTP) and Time based One Time Password (TOTP)

One Time Password (OTP) and Time based One Time Password (TOTP) can be used for login authentication, document access authentication, and document signing authentication.

Configuration:

Make the following configurations to the user role settings SigningHub Web:

In "Basic Information" tab, against your user role, choose either "One-Time Password" or "Time-based One-Time Password" as the "Secondary factor authentication".

Once the enterprise administrator enforces Time based One Time Password as a secondary authentication method on to a role, and a user under that role does not have two factor authentication (2FA) configured at the time of login, 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, 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 enterprise user loses access to your mobile device and recovery codes, or have used all of the recovery codes, you can ask your enterprise admin to reset the two factor authentication (2FA) against your account.

Authentication:

Once a secondary authentication method has been configured for login, the user will be prompted for secondary authentication upon login, after primary authentication.

Document Access Authentication

Configuration:

Make the following configurations to a workflow in SigningHub Web:

From the "Set Access Security" dialog, enable the "Access Authentication", and from the following options choose either "One-Time Password" or "Time-based One-Time Password".

The OTP method under "OTP Authentication" will be the same 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
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, 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 enterprise user loses access to your mobile device and recovery codes, or have used all of the recovery codes, you can ask your enterprise admin to reset the two factor authentication (2FA) against your account.

Authentication:

Once a document access authentication has been configured for a workflow, the user will be prompted for authentication upon opening the document.

Document Signing Authentication

Document signing authentication can be classified into three different categories; Signing Server-level Authentication, Recipient Permission-level Authentication, and Field-level Authentication.

Signing Server-level Authentication

Configuration:

Make the following configurations to the user role settings SigningHub Web:

In the "Authentications" section, choose either "One-Time Password" or "Time-based One-Time Password" as the "Secondary Authentication Method".

Once the enterprise administrator enforces Time based One Time Password as a secondary authentication method for a signing server against a role, and a user under that role does not have two factor authentication (2FA) configured at the time of signing with that signing server, 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, 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 enterprise user loses access to your mobile device and recovery codes, or have used all of the recovery codes, you can ask your enterprise admin to reset the two factor authentication (2FA) against your account.

Authentication:

Once a secondary authentication method has been configured against a signing server, the user will be prompted for authentication at the time of signing.

Recipient Permission-level Authentication

Configuration:

Make the following configurations to a workflow in SigningHub Web:

From the "Set Access Security" dialog, check the "Document Signing OTP Authentication", and from the following options choose either "One-Time Password" or "Time-based One-Time Password".

The following rules will be followed for initiating the OTP process:
- The system will initiate when the recipients attempt to sign a signature field, and will not initiate OTP process when recipient attempts to mark an Initials field.
- Even if Document Signing OTP Authentication is configured, OTP process will fail to initiate in case the signer is performing Bulk Sign.
- 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 document owner via "Set Access Security" dialog.
  - 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 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 document owner via "Set Access Security" dialog.
  - In addition, even if the OTP authentication is configured in the Enterprise role, OTP process will still not initiate.
The OTP method for "Document Signing OTP Authentication" will be the same 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
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, 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 enterprise user loses access to your mobile device and recovery codes, or have used all of the recovery codes, you can ask your enterprise admin to reset the two factor authentication (2FA) against your account.

Authentication:

Once a recipient permission-level signing authentication has been configured for a workflow, the user will be prompted for authentication at the time of signing.

Field-level Authentication

Configuration:

Make the following configurations to a signature/in-person signature field in SigningHub Web:

From the Signature/In-Person field dialog, enable "Authenticate signer via OTP" and from the following options choose either "One-Time Password (SMS and Email)" or "Time-based One-Time Password".

The "Authenticate signer via OTP" option is not available:
- For a signature field:
  - If recipient is a group signer or a placeholder.
  - If One Time Password (OTP) and Time based One Time Password options are disabled in the service plan.
  - In case of an Individual workflow type.
- For an in-person Signature field:
  - If One Time Password (OTP) and Time based One Time Password options are disabled in the service plan.
  - In case of an Individual workflow type.
If there is an unprocessed signature/in-person signature field with the "Authenticate signer via OTP" option configured, the user will not able to "Bulk Sign" and "Bulk Sign and Share" the document.
The OTP method for "Authenticate signer via OTP" will be the same 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
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, 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 enterprise user loses access to your mobile device and recovery codes, or have used all of the recovery codes, you can ask your enterprise admin to reset the two factor authentication (2FA) against your account.
In case a recipient is changed and the "Authenticate signer via OTP" option was configured, the system will require the mobile number of the new recipient.

Authentication:

Once a field-level authentication authentication has been configured, the user will be prompted for authentication at the time of signing.

OTP Preference

The following OTP preference will be followed while signing, in case of configuration of Signing Server-level Authentication, Recipient Permission-level Authentication, and Field-level Authentication.

Add your signature