Signature verification process

Electronic signatures are verified by OneSpan Authentication Server using a number of steps in the following sequence:

  1. Identify the client component
  2. Identify the policy
  3. Look up and verify the user account
  4. Validate the signature
  5. Finalization

Identify the client component

OneSpan Authentication Server identifies the application that initiated the request. A client component record must exist for the signature verification application and location from which it connects to the server. The client component type is set as a parameter by the application. The location is the source IP address of the SOAP request.

A client component with an IP address range (IPv4 CIDR notation) as component location will be used to handle requests from any client within that IP address range. If two (or more) matching client components with overlapping IP address ranges are found, the client component with the smaller IP address range (more specific) takes precedence and will be used to serve the request.

Identify the policy

OneSpan Authentication Server identifies the policy to use in the signature authentication from the client component record and verifies the validity of the policy.

Look up and verify the user account

OneSpan Authentication Server verifies the user account for the following:

  • Ensure that the user ID and domain have been defined.
  • Perform the Windows group check if required.
  • Verify whether a user account exists.
  • Verify whether the user account is disabled or locked if it already exists.

    If the user account is locked, OneSpan Authentication Server verifies whether a user auto-unlock attempt is possible (see User account auto-unlock).

Dynamic User Registration (DUR) is NOT possible during signature verification. If the user account does not exist, then the check will fail.

Validate the signature

A search is performed for an authenticator that is assigned to the user account and fulfills the signature policy limits. If more than one authenticator is found, the list is filtered using the authenticator serial number. That serial number will be passed to the signature process as a parameter.

When you design a web page that should allow transactions to be signed, ensure that users with multiple authenticators can enter a serial number to identify which authenticator is being used.

When the correct authenticator is identified, the authenticator type is verified. The authenticator type must be either SG (signature) or MM (multi-mode) to allow signatures. The signature is then verified and a response is produced.

Finalization

After the successful signature validation, the data store is updated. A response is generated. The audit data is updated with the transactions that took place and the result of those transactions.

If the Web application requests a confirmation code and the authenticator is capable of generating one, then OneSpan Authentication Server will generate a confirmation code and the application will display it to the user. The user generates a confirmation code on the authenticator and verifies that it is the same as the one on the screen.

Confirmation code generation is passed as a parameter in the authentication request. There are two options:

  • Optional. Return a confirmation code only if the authenticator is confirmation code–capable
  • Required. The authenticator must be confirmation code–capable or the request will fail.