Signature validation process

If a signature is generated with an authenticator, the typical signature validation process is as follows:

  1. The user selects the signature application on the assigned authenticator.

  2. The user enters the required transaction details. The authenticators can be programmed to accept up to eight transaction data fields such as:

    • Transaction amount
    • Transaction ID
    • Destination account number
  3. The authenticator generates a signature and displays it on its screen. The user enters this signature into the transaction and submits the transaction.

If signature generation is done via OneSpan Authentication Server (virtual signature generation), the typical signature validation process is as follows:

  1. The user initiates the transaction as usual via a client program, e.g. a money transfer transaction via an online banking application. The client program then requests an electronic signature from the user to sign the transaction.
  2. At the same time, the client program submits the required transaction details to OneSpan Authentication Server to request a virtual signature.
  3. OneSpan Authentication Server generates a virtual signature based on the transaction details supplied.
  4. OneSpan Authentication Server delivers the virtual signature to the user via email, voice, SMS, or any supported combination thereof (depending on how Message Delivery Component (MDC) is configured).
  5. The user receives the virtual signature and enters it into the transaction as requested by the client program.

Once the transaction is signed, it can then be sent to OneSpan Authentication Server for validation. The signature validation process from this point onwards is identical for transactions signed by either normal electronic signatures (generated via an authenticator) or virtual signatures (generated via OneSpan Authentication Server).

Signature validation with Secure Channel and authenticators

Signatures can also be validated using the Secure Channel feature with authenticators that comply with this feature. Signature validation with Secure Channel is used to validate transactions such as online banking, but is also used to add devices, activate authenticator licenses and authenticator instances in a multi-device licensing and multi-device activation scenario (see Authenticator licensing and activation).

  1. The user logs in to the client application and enters the required transaction details.
  2. The user scans either a QR code or a color QR code, which are provided by the client application.
  3. The authenticator displays the transaction signature and the user enters it in the client application to complete the transaction.

Real-time signature validation

Real-time signature validation is generally used to provide security for transactions that require quick responses. It is typically used by online banking applications.

With real-time signature validation, a user creates a transaction. The transaction normally requires a signature, so the user enters the relevant details into the user's authenticator. The authenticator generates a signature and the user enters this into the website, which then submits the transaction.

The transaction details and the signature are verified by OneSpan Authentication Server. A status message is returned to the web page that the user is currently visiting. The user knows within the time it takes to process a normal transaction whether or not the submitted transaction has been verified.

Deferred signature validation

Deferred signature validation is signature validation that is not performed in real-time. In typical cases that use this type of validation, a user submits a transaction online with the signature generated by the authenticator. The transaction is queued for verification and the user receives a respective message. Afterward a batch job picks up the queued transaction and verifies it against the policies and details of the authenticator. The user may not know until minutes or hours later that the transaction has been signed and verified.

It is important in this case for the user to keep a record of the time the transaction was submitted, as this may become important if the transaction is challenged.