Configuring Recipient Authentication

• Creating a Transaction

• Adding Documents to a Transaction

• Adding Recipients to a Transaction

• Configuring Recipient Authentication

• Adding Fields to a Document

• Managing Transaction Reminders

Configuring Recipient Authentication

To add an extra layer of security to your online transactions, OneSpan Sign offers robust and flexible recipient-authentication options. Specifically, you can select various ways of verifying the identity of the recipient of an invitation to a transaction before they are permitted to access the transaction's documents.

The rest of this section describes how to configure the following types of authentication:

• General Authentication

• KBA Authentication

By default, the authentication process is optional. However, it is possible to require an Authentication Method for all recipients of all transactions created in your account. To arrange this, please contact our Support Team.

General Authentication

The term General Authentication designates tools built into OneSpan Sign for verifying a recipient's identity. A recipient's identity can also be verified using the third-party authentication tools described in the section KBA Authentication.

Prerequisites

• If you want to assign an SMS, Q&A, or SSO method to a recipient, that authentication method must be enabled for your account. You can arrange this by contacting our Support Team.

• If you want to assign a Document Verification Only or Document Verification with Facial Comparison method to a recipient, that authentication method must be enabled for your account. You can arrange this by contacting your Account Representative.

Action

To specify a General authentication method for a transaction recipient:

1. Locate the Recipients section of the Transaction page.

2. Click Add Recipient, or locate an existing recipient whose authentication method you'd like to change.

3. Ensure that the selected Type is General.

4. Select one of the following authentication methods, and then follow any prompts that appear:

   • None: This is the default authentication type. The recipient's identity is verified by their secure name and password when they log in to their email account.

   • SMS: The recipient's identity is verified by a secure SMS code sent to their cellphone. The recipient must enter that code to open the transaction.

     For SMS codes, please note the following:

     • An SMS code can be used only once.

     • By default, SMS codes expire 5 minutes after being sent. However, SMS codes can be configured to expire after times that range from 1 to 10 minutes. To change the expiry time for your SMS codes, please contact our Support Team.

     • By default, a user may attempt to enter an SMS code a maximum of 3 times. However, this can be changed to allow up to 5 attempts. If a user does not successfully enter their SMS code within the maximum number of attempts, they will be blocked from further attempts until the current SMS code expires.

     • A valid SMS code has between 4 and 10 numbers.

     • The SMS message received by signers will be set to “Your SMS verification code is: <passcode>”. The SMS portion of the message can be customized per account by contacting our Support Team. The replacement string must be between 1 and 30 characters.

     • The SMS message cannot contain phone numbers or links. Only letters, numbers, spaces, dashes, underscores and ampersands can be used. In addition, the following characters cannot be used: \ / { } : $

   • Q&A: The recipient's identity is verified using a secure question & answer defined by the sender. At least one question & answer is required. Once the recipient launches the Signer Experience, they will be prompted to answer these questions.

   • SSO: The recipient's identity is verified through an Identity Provider (IdP). For more , see Single Sign-On Authentication.

     SSO authentication cannot be configured via connectors or mobile applications.

   • Document Verification Only: Validates the recipient's driver’s license, passport, or national identity card.

   • Document Verification with Facial Comparison: Examines one of those identity documents, and compares the recipient's photo on that document with the recipient's selfie.

     If you selected either of the above Document Verification methods, you will be prompted to enter the recipient's mobile phone number. If you don't do so, and if the recipient starts the transaction on their computer, the recipient will be prompted to provide their phone number before they start the verification process.

     ID Verification is the generic name for the methods Document Verification Only and Document Verification with Facial Comparison.

     • If using document verification, or document verification with facial comparison, note that a recipient cannot proceed to the verification process without first providing consent to the processing of their personal data. Clicking Next to continue with the verification implies that your recipient consents to the collection of their personal data. You can configure your workflow so that a explicit consent must be given via a checkbox.

     • Customers can decide: (1) if they want to enable Document Verification Only and/or Document Verification with Facial Comparison; (2) if they want ID Verification to be used when a recipient tries to access signed documents.

     • Starting with OneSpan Sign 11.44, ID Verification and KBA Authentication can both be assigned to a recipient. To access the relevant transaction, the recipient must pass both authentication methods.

     • ID Verification is currently supported in all OneSpan Sign supported languages except Arabic. If Arabic is selected during transaction creation, the ID Verification experience will default to English. We are planning to support Arabic in the future.

     • Once a transaction with ID Verification is complete, robust vendor-independent Audit Trails store all authentication and e-signature actions in a unified Evidence Summary document. The Evidence Summary does not contain images of the recipient’s ID document or face.

     • ID Verfication for OneSpan Sign is available only in the following environments: US1, US2 , CA and EU. It is not available in the US FedRAMP or AU environments.

     • ID Verification is not supported when Reassigning Recipients.

     • ID Verification is not supported within iFrames.

     • ID Verification will work only if all the recipients in a transaction have different email addresses.

     • The following ID Verification features are planned for future releases: (1) support for Bulk Sending; (2) support for customized workflows; (3) the ability to combine ID Verification for a recipient with the Q&A, SMS and SSO authentication methods.

5. Click Save. A green dot next to the Authentication option indicates that an authentication method has been set.

By default, a signer is locked out of signing if they fail multiple authentication attempts. However, such signers can be automatically unlocked once they're locked out. If you want to arrange this, please contact our Support Team.

Video Tutorial

KBA Authentication

Knowledge-Based Authentication (KBA) relies on the third-party KBA provider LexisNexis to verify a recipient's identity.

KBA questions are generated dynamically, based on information in a recipient's personal credit report.

KBA authentication can be used with any of the General authentication methods described above.

Prerequisites

• LexisNexis has been enabled on your account. To arrange this, please contact our Support Team.

Action

To specify a KBA authentication method for a transaction recipient:

1. On the Recipients section of the Drafts tab of the Transaction page, hover your mouse over the row of the recipient.

2. Ensure that the, selected Type is KBA.

3. For KBA Provider, select LexisNexis.

   If you want to disable KBA authentication, select None.

4. Enter information about the recipient (fields marked with an asterisk are required).

5. Click Save. A green dot next to the Authentication option indicates that an authentication method has been configured.

Note the following:

• If a signer fails to authenticate using LexisNexis KBA, the sender will need to create a new transaction if they want to re-attempt KBA authentication.