Authenticating Signers

To download the full code sample see our Code Share site.

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.

General Authentication refers to tools built into OneSpan Sign that enable you to verify the identity of the recipient through SMS, Email, or a custom Question and Answer format.

Knowledge-Based Authentication (KBA) relies on a third-party KBA provider to perform the authentication. That provider is LexisNexis. .

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

KBA authentication can be used in conjunction with any one of the General authentication methods above.

To enable Knowledge-Based Authentication, please contact our Support Team.

SMS Phone Number Validation

When using SMS authentication, the OneSpan Sign evaluates the phone number provided in the request payload to determine how it should be interpreted and validated. Understanding this behavior helps ensure that phone numbers are correctly processed and that authentication messages are delivered successfully.

If a phone number contains exactly 10 digits with no leading + sign,  OneSpan Sign automatically assumes that the signer is located in North America. In this case, the country code 1 is appended to the number before it is stored or returned in the response payload.

For example:

5551234567 becomes 15551234567

This behavior applies only when the number is 10 digits and does not include an explicit country code.

Some countries also use 10‑digit phone numbers by default. If the signer is located outside North America but their number still consists of 10 digits, you must include a leading + in the request payload. This ensures the system does not incorrectly assume the number belongs to the North American numbering plan.

For example:

+5551234567

Using General Authentication

The code below illustrates how to edit the signer block for each general authentication method. If you need a comparison with basic document-object creation, or if this is your first time creating a package with the Java SDK, see this Creating a Transaction.

.withSigner(
    newSignerWithEmail("first.signer@email.com")
        .withFirstName("First")
        .withLastName("Signer")
        .challengedWithQuestions(
            ChallengeBuilder.firstQuestion("What's your favorite sport?")
                .answer("soccer")
                .secondQuestion("What music instrument do you play?")
                .answer("drums")
        )
)
.withSigner(
    newSignerWithEmail("second.signer@example.com")
        .withFirstName("Second")
        .withLastName("Signer")
        .withSmsSentTo("1234567890")
)

Manually sending an SMS code

A new SMS code is generated and sent each time a signer clicks the email link. If for any reason you need to manually send a new SMS code, you can do so by using PackageService and passing the PackageId and Signer objects as parameters. The following code will do this:

eslClient.getPackageService().sendSmsToSigner(
    packageId,
    retrievedPackage.getSigner(email1)
);

Using KBA

You can also authenticate a signer with KBA. You can also edit the signer block to implement KBA. The following code will do this:

.withSigner(newSignerWithEmail(email1)
                        .withFirstName(FIRST_NAME)
                        .withLastName(LAST_NAME)
                        .challengedWithKnowledgeBasedAuthentication(newSignerInformationForLexisNexis()
                                .withFirstName(FIRST_NAME)
                                .withLastName(LAST_NAME)
                                .withFlatOrApartmentNumber(FLAT_OR_APARTMENT_NUMBER)
                                .withHouseName(HOUSE_NAME)
                                .withHouseNumber(HOUSE_NUMBER)
                                .withCity(CITY)
                                .withZip(ZIP)
                                .withState(STATE)
                                .withSocialSecurityNumber(SOCIAL_SECURITY_NUMBER)
                                .withDateOfBirth(DATE_OF_BIRTH)))

Results

After running your code, if a transaction is sent with signer authentication enabled, your signers will be required to validate their identity using the method specified in the transaction.

With Knowledge Based Authentication, the signer's identity is verified by asking them a series of questions about their personal credit report.

To download the full code sample see our Code Share site.

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.

General Authentication refers to tools built into OneSpan Sign that enable you to verify the identity of the recipient through SMS, Email, or a custom Question and Answer format.

Knowledge-Based Authentication (KBA) relies on a third-party KBA provider to perform the authentication. That provider is LexisNexis. .

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

KBA authentication can be used in conjunction with any one of the General authentication methods above.

To enable Knowledge-Based Authentication, please contact our Support Team.

Phone Number Preprocessing and E.164 Formatting Guidelines

In addition to the SMS Phone Number validation described above, OneSpan Sign also uses a preprocessing workflow that sanitizes and standardizes all inputs into the internationally recognized E.164 format. This ensures that numbers are stored and returned in a consistent structure across all APIs.

E.164 is the global standard for international telephone numbering as defined by the International Telecommunication Union (ITU). It defines how numbers should be structured so they can be recognized and routed anywhere in the world. An E.164 phone number includes:

• A maximum of 15 digits

• Digits only (0–9)

• No spaces, hyphens, parentheses, or other separators

• A leading + to indicate an international number

OneSpan recommends that you submit phone numbers directly in E.164 format. However, our system also accepts several alternative user‑entered formats and standardizes them automatically. This means that we accept various formatted inputs and convert them to the correct E.164 structure during preprocessing.

For example, we accept inputs such as:

(+32) 0470123456

Even though this example includes parentheses and a leading zero after the country code, our preprocessing removes the non-digit characters and the leading zero, and returns it in E.164 format:

+32470123456

The use of a leading zero is accepted by most European countries, but may not be accepted by all. The use of a leading zero is not accepted for North American numbers.

The Get Package API will always return the phone number in this standardized format.

+ [Country Code] [National Destination Code] [Subscriber Number]

Here are some examples of E.164 numbers:

Using General Authentication

The code below illustrates how to edit the signer block for each general authentication method. If you need a comparison with basic document-object creation, or if this is your first time creating a package with the Java SDK, see this Creating a Transaction.

.WithSigner(
    SignerBuilder.NewSignerWithEmail("first.signer@example.com")
        .WithFirstName("First")
        .WithLastName("Signer")
        .ChallengedWithQuestions(
            ChallengeBuilder.FirstQuestion("What's your favorite sport?")
                .Answer("golf")
                .SecondQuestion("What music instrument do you play?")
                .Answer("drums")
        )
)
.WithSigner(
    SignerBuilder.NewSignerWithEmail("second.signer@example.com")
        .WithFirstName("Second")
        .WithLastName("Signer")
        .WithSMSSentTo("1234567890")
)

Manually sending an SMS code

A new SMS code is generated and sent each time a signer clicks the email link. If for any reason you need to manually send a new SMS code, you can do so by using PackageService and passing the PackageId and Signer objects as parameters. The following code will do this:

eslClient.PackageService.SendSmsToSigner(
    packageId,
    retrievedPackage.GetSigner(email1)
);

Using KBA

You can also authenticate a signer with KBA. You can also edit the signer block to implement KBA. The following code will do this:

.WithSigner(
    SignerBuilder.NewSignerWithEmail(email1)
        .WithFirstName(FIRST_NAME)
        .WithLastName(LAST_NAME)
        .WithCustomId(signerId)
        .ChallengedWithKnowledgeBasedAuthentication(
            SignerInformationForLexisNexisBuilder.NewSignerInformationForLexisNexis()
                .WithFirstName(FIRST_NAME)
                .WithLastName(LAST_NAME)
                .WithFlatOrApartmentNumber(FLAT_OR_APARTMENT_NUMBER)
                .WithHouseName(HOUSE_NAME)
                .WithHouseNumber(HOUSE_NUMBER)
                .WithCity(CITY)
                .WithState(STATE)
                .WithZip(ZIP)
                .WithSocialSecurityNumber(SOCIAL_SECURITY_NUMBER)
                .WithDateOfBirth(DATE_OF_BIRTH)
                .Build()
        )
)
 .WithDateOfBirth(DATE_OF_BIRTH)
                                        .Build()))

Results

After running your code, if a transaction is sent with signer authentication enabled, your signers will be required to validate their identity using the method specified in the transaction.

With Knowledge Based Authentication, the signer's identity is verified by asking them a series of questions about their personal credit report.

SMS Phone Number Validation

When using SMS authentication, the OneSpan Sign evaluates the phone number provided in the request payload to determine how it should be interpreted and validated. Understanding this behavior helps ensure that phone numbers are correctly processed and that authentication messages are delivered successfully.

If a phone number contains exactly 10 digits with no leading + sign, OneSpan Sign automatically assumes that the signer is located in North America. In this case, the country code 1 is appended to the number before it is stored or returned in the response payload.

For example:

5551234567 becomes 15551234567

This behavior applies only when the number is 10 digits and does not include an explicit country code.

Some countries also use 10‑digit phone numbers by default. If the signer is located outside North America but their number still consists of 10 digits, you must include a leading + in the request payload. This ensures the system does not incorrectly assume the number belongs to the North American numbering plan.

For example:

+5551234567

To download the full code sample see our Code Share site.

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.

General Authentication refers to tools built into OneSpan Sign that enable you to verify the identity of the recipient through SMS, Email, or a custom Question and Answer format.

Knowledge-Based Authentication (KBA) relies on a third-party KBA provider to perform the authentication. That provider is LexisNexis. .

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

KBA authentication can be used in conjunction with any one of the General authentication methods above.

To enable Knowledge-Based Authentication, please contact our Support Team.

Phone Number Preprocessing and E.164 Formatting Guidelines

In addition to the SMS Phone Number validation described above, OneSpan Sign also uses a preprocessing workflow that sanitizes and standardizes all inputs into the internationally recognized E.164 format. This ensures that numbers are stored and returned in a consistent structure across all APIs.

E.164 is the global standard for international telephone numbering as defined by the International Telecommunication Union (ITU). It defines how numbers should be structured so they can be recognized and routed anywhere in the world. An E.164 phone number includes:

• A maximum of 15 digits

• Digits only (0–9)

• No spaces, hyphens, parentheses, or other separators

• A leading + to indicate an international number

OneSpan recommends that you submit phone numbers directly in E.164 format. However, our system also accepts several alternative user‑entered formats and standardizes them automatically. This means that we accept various formatted inputs and convert them to the correct E.164 structure during preprocessing.

For example, we accept inputs such as:

(+32) 0470123456

Even though this example includes parentheses and a leading zero after the country code, our preprocessing removes the non-digit characters and the leading zero, and returns it in E.164 format:

+32470123456

The use of a leading zero is accepted by most European countries, but may not be accepted by all. The use of a leading zero is not accepted for North American numbers.

The Get Package API will always return the phone number in this standardized format.

+ [Country Code] [National Destination Code] [Subscriber Number]

Here are some examples of E.164 numbers:

Using General Authentication

The code below shows you how to create a Role Object for each signer authentication method. If you need a comparison with basic document-object creation, or if this is your first time creating a package with the Apex SDK, see this guide.

 ESignLiveAPIObjects.Role role = new ESignLiveAPIObjects.Role(); 

ESignLiveAPIObjects.AuthChallenge firstChallenge = new ESignLiveAPIObjects.AuthChallenge(
    firstQuestionAnswer, 
    false, 
    firstQuestion
); // Question & Answer

ESignLiveAPIObjects.AuthChallenge secondChallenge = new ESignLiveAPIObjects.AuthChallenge(
    secondQuestionAnswer, 
    false, 
    secondQuestion
); // Question & Answer

ESignLiveAPIObjects.AuthChallenge smsAuthentication = new ESignLiveAPIObjects.AuthChallenge(
    null, 
    false, 
    phoneNumber
); // SMS

Manually sending an SMS code

A new SMS code is generated and sent each time a signer clicks the email link. If for any reason you need to manually send a new SMS code, you can do so using the following function encapsulated in the Code Share:

 public void sendSmsToSigner(String packageId, String roleId) 

Using KBA

You can also authenticate a signer with KBA. You can use the two encapsulated functions below to create a role, and add it to an existing transaction. The two functions are used separately for Equifax USA and Equifax CA:

public void createRoleWithKBA_EquifaxUSA(
    String packageId,
    String roleId,
    String firstName,
    String lastName,
    String email,
    String streetAddress,
    String city,
    String zip,
    String state,
    Integer timeAtAddress,
    String driversLicenseNumber,
    String dateOfBirth,
    String socialSecurityNumber,
    String homePhoneNumber
)

public void createRoleWithKBA_EquifaxCA(
    String packageId,
    String roleId,
    String firstName,
    String lastName,
    String email,
    String streetAddress,
    String city,
    String zip,
    String state,
    Integer timeAtAddress,
    String driversLicenseNumber,
    String dateOfBirth,
    String socialSecurityNumber,
    String homePhoneNumber
)

Results

After running your code, if a transaction is sent with signer authentication enabled, your signers will be required to validate their identity using the method specified in the transaction.

With Knowledge Based Authentication, the signer's identity is verified by asking them a series of questions about their personal credit report.