Skip to main content

Components

SDK Components​

The main SDK component is the SignatureEngine - a COM component responsible for enrolling and verifying signatures. The SignatureEngine does not store any data but processes signatures, as well as updating a template for each person to record their signing characteristics. It is the responsibility of the calling application to supply the user's template with each signature being verified and to store the updated version afterward.

Summary of features​

The main features of the SDK's SignatureEngine component include the following:

Accepted signature formats​

A single template can handle either dynamic signatures supplied in FSS format or static signatures supplied as scanned graphical images. In most implementations, it is expected that only one type will be used, but when both types are handled the SignatureEngine checks that the two sets of data are of the same signature.

The SignatureEngine will also accept FSS data which is embedded steganographically in a graphical image.

Creating a template​

When a new person's signature is to be verified, the calling system must first create a new template that will record their signing behavior. There are a number of configuration options that must be set at this stage and which cannot be subsequently changed. These control the way in which the enrollment process is handled and subsequently updated.

Verifying a signature​

Once the template has been created, signatures can be verified. This is done using the VerifySignature method. The method must be supplied with the user's template and the signature.

After the signature has been processed, the following is returned to the calling application:

  • A score of between 0 (inconsistent signature) and 1 (consistent signature). Note that for the first signature no comparison is possible and the score is meaningless.
  • A flag indicating the type of verification that was used i.e. dynamic or static.
  • A flag indicating the nature of the comparison that was used to arrive at the score e.g. whether the signatures differed in their geometry, timing, pressure variability etc.
  • A summary of the status of the template, e.g enrolling, enrolled, updated etc.
  • The updated template which should be saved for the next verification for the user.

Enrolling a template​

A user's template becomes fully enrolled when the required number of consistent signatures have been verified. By default, the number needed is 6 but different values can be set when the template is created. If when the required number has been received one of the signatures is significantly inconsistent with the others then it is rejected and the enrollment process will continue. Some inconsistent signers may need to verify more than the nominal enrollment number of signatures to become fully enrolled.

During enrollment, the verification score for each signature is determined using the conventional DSV or SSV engines depending on the data type. These use 1:1 comparisons which are assessed using average variability characteristics. Once enrollment has been completed each signature being verified is compared against the range of characteristics measured in the enrollment set, which generally reduces the false acceptance error rate significantly.

After enrollment has been completed the reference data set can be periodically updated to track the drift of a user's signing behavior with time. The minimum elapsed period between updates is set when the template is created.