A User's Guide to SigningHub Web

1. In case of an enterprise user, the Signing dialog will not appear in the following :

• “Hide signature dialog at the time of signing“ is checked in your role, and
• You have selected Hand Signature Method as Text or Upload having the signature Image in your My Settings> Signatures> Signature Appearance, and
• You have only a single signing capacity

2. The individual user signing capacities will appear as per the configured capacities under service plan.

3. 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.

4. Signing Servers that appear on signing dialog 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 upon level of assurance set by the document owner on signature field.
5. 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 dialog.
6. Signing Server can be ADSS, eID Easy or CSC for Server Side Signing and  ADSS Go>Sign or T1C for Client Side Signing.
7. The eID Easy Signing Server will only appear if the level of assurance of the signature field is set to Qualified Electronic Signatures (QES).
8. 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 otherName values of Subject Alternative Name (SAN) extension specified for certificates.
• This will slow down the signing process as SigningHub parsing the certificate to extract the otherName value.

1. 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 Authorisation Code

2. 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.
3. 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 NOW button, no additional authorisation will be required for signing.
4. 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.
5. In case the Level of Assurance of a "Signature" field is set to "Simple Electronic Signature", then only Document Signing Authentication will work. 

1. 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

2. The OTP length is based on your subscribed service plan. SigningHub currently supports 4, 6, and 9 digits OTP. 
3. The OTP retry and expiry times are based on your subscribed service plan.

1. The availability of Time based One Time Password as a document signing authentication method is subject to your subscribed service plan.
2. 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.
3. 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.

1. Before locally signing the document using T1C, the system will prompt the user for their consent to continue the signing process.

1. For RAS, enabled signing capacities Authorisation via Mobile App will appear as the only authentication method and cannot be changed.  
2. SigningHub support signing authentication via both; public and private authentication profiles.

1. To setup One Time Password as the only option at signing time, you can select 'No Authentication' under authentication method and One Time Password under secondary authentication method.

1. 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 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.

1. 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.
2. Workflow history and workflow evidence report logs following information for email/ password authentication to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and User Email.

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and User Email.

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name.

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name.

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and optionally User Email if user email address integrated with Office 365 mailbox. 

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and User Email.

1. 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 Mobile credentials at the time of signing having a different email address and vice versa.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name and User Email.

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name and User Email.

1. 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 Bank ID credentials at the time of signing having a different email address and vice versa.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and Unique Identifier.

1. 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 itsme credentials at the time of signing having a different email address and vice versa.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name.

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and User Email.

1. 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.
2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and User Email.

1. 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.

2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and User Email.

1. 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.

2. Workflow history and workflow evidence report logs following information to keep history of how the user authenticated at signing time.  i.e. Authentication Profile Name, User Name and User Email.

1. You cannot add your signatures on a document, if you don't have a SigningHub account.
2. The signature appearances are managed from your personal settings, see details.
3. To use the Remote Authorised Signing (RAS) feature:

• Your mobile device must be running the SigningHub native app (i.e. iOS or Android), and
• Your mobile must be registered in your SigningHub web and SigningHub native app should be logged in with the same ID through which SigningHub web is logged in.
• This feature is subject to your signing profile configurations and assigned role in the enterprise.

4. ​If you delete a pending document from your documents list without signing, it is considered as declined.
5. The signing capacity with which a document is signed can be seen:

• Inside the Activity details of the signer, and
• Inside the Workflow History of the document, and
• Inside the Workflow Evidence Report of the document

6. 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.
7. Font color will not be applicable in Signature Appearance while perform signature on any PDF/A document with "CMYK" color space ​​in order to ensure PDF/A compliance.
8. SigningHub produces the "XAdES-Baseline-LTA" ETSI compliant signatures for XML document but for backward compatibility with ADSS Server version 6.9 or lesser SigningHub will produce the XAdES Extended signature on base of key "ES-X-L" added in web.config file.
9. When signing an XML file, the different Commitment Type Indications can be selected that are:

• Proof of origin indicates that the signer recognizes to have created, approved, and sent the signed data object.
• Proof of receipt indicates that the signer recognizes to have received the content of the signed data object.
• Proof of delivery indicates that the TSP providing that indication has delivered a signed data object in a local store accessible to the recipient of the signed data object.
• Proof of sender indicates that the entity providing that indication has sent the signed data object (but not necessarily created it).
• Proof of approval indicates that the signer has approved the content of the signed data object.
• Proof of creation indicates that the signer has created the signed data object (but not necessarily approved, nor sent it).

10. 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.
11. 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. 
12. OTP authentication will not work in cases of RAS, Server-side Signing using CSC and Local side signing.
13. Signatures quota consumed on signing when perform digital signatures (PKI signatures) performed using all level of assurance except Simple Electronic Signature (eSignature) if "SIMPLE_ELECTRONIC_SIGNATURES" module enabled  in the license.
14. Simple Electronic Signatures quota consumed on signing when perform electronic signature (Non-PKI signatures) using level of assurance Simple Electronic Signature (eSignature) if "SIMPLE_ELECTRONIC_SIGNATURES" module enabled  in the license.
15. If "SIMPLE_ELECTRONIC_SIGNATURES" module disabled in the license than system will work as of today and signatures quota (PKI or Non-PKI signatures) consumed when performed signing using all level of assurance.
16. You cannot perform signature without adding an attachment if a mandatory attachment field has been assigned to you. This validation will not work in case of signing the  XML or Word file.
17. If the recipient tries to close the document package without performing all of their required actions, a warning will be displayed, as shown in the figure below:
    
    

18. In 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. 
    
    

19. In 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.
20. In the "Sign" dialog, the user's default location will be shown, as configured in the user's personal settings. In case of an unregistered user:

• if the auto-detect location checkbox is checked, and the GeoIP connector has been configured, the system will pick the location and time zone using the GeoIP connector.
• If either the auto-detect location checkbox is unchecked, the GeoIP connector has not been configured, or the GeoIP connector is faulty or not functional, the system will use the location and time zone of the document owner.

21. Based on the type of users, the following mentioned signature appearances will be available:

• In case of an enterprise user, all the signature appearances allowed in the user role.
• In case of an individual user, all the signature appearances allowed in the user's service plan.
• In case of an unregistered user:
• If the document owner is an enterprise user, all the signature appearances allowed in the document owner's user role.
• If the document owner is an individual user, all the signature appearances allowed in the document owner's service plan.

22. In case of  Simple Electronic Signature (SES) signature stamp, against the "Signed by" attribute:

• the system will show the name of the user as configured in user's profile in their personal settings.
• in case of an unregistered user, the system will show the name of the unregistered user as saved in the document owner's contacts. 

23. In case of  Electronic Seal (eSeal), the user will now be able to select the allowed signature appearance design, signing capacity, contact information and location.
24. 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.
25. Signature Policy is not supported with eID Easy signing. 
26. 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:
    
    

27. 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.