Digital Ink Signatures - Concepts and Technologies


Leszynski Group, Inc

September, 2004

Applies to
   Microsoft Windows XP Tablet PC Edition 2005

Summary: Design and implement Tablet PC applications that efficiently utilize digital ink signatures for identity validation. (18 printed pages)


Introduction to Digital Ink Signatures
Capturing E-Signatures
E-Signature Legislation
E-Signatures and the Law
E-Signature Software

Introduction to Digital Ink Signatures


The Tablet PC is the premier tool for digital forms-based data collection processes. In addition to providing the means to collect, validate, and store data, digital forms often must support some degree of authentication. One of the oldest methods of authentication is pen-based signatures—from the feather quill pen of old to the digital stylus of today, people have been using written signatures to indicate their intentions or approval for thousands of years.

This paper discusses concepts and practices related to pen-based signatures on the Tablet PC. The collection, preservation, and protection of electronic signatures created with a digital pen in Tablet PC applications is a new frontier. As such, the body of code, components, and case law for this topic area is not extensive, and this paper does not present a single or even suggested approach to the subject. Instead, the goal of this paper is to provide solution architects, systems and business analysts, software designers, and technical team leaders with a foundation upon which to build as they design and implement Tablet PC applications where pen-based signatures provide useful functionality.


The vocabulary of electronic signatures can be a bit confusing. The term "digital signatures" can be used interchangeably to refer to digital certificates administered by trusted third parties ("certificate authorities"), and similar technologies, as well as digital ink signatures created on the Tablet PC. For the purposes of this paper, we will use the term "e-signature" when referring to a digitized signature created with a stylus and digital ink on a Tablet PC computer. For more information about digital certificates see Cryptography in the MSDN Library.


As long as there have been writing instruments, people have been "making their mark," gradually improving that mark from a symbol scratched on a cave wall to the highly-individualistic signature of a celebrity. People sign documents by hand to signify one or more of the following:

  • I intend to do something. In this case, the signature bonds the signer to an expected action, such as a marriage license, or to an expected non-action, as in the case of a non-disclosure agreement.
  • I was here. A signature may be used as evidence that you arrived somewhere or you acknowledge some process, such as the sign-in sheet in the lobby of a secured building or the sign-out sheet for borrowing equipment from the test lab.
  • I am who I say I am. In this case, the signature is used for security purposes to verify your identity and prevent impersonation, as in the case of a bank check.

Handwritten signatures entered the digital realm fairly recently, and for most of us the introduction to e-signatures came sometime in the 1990s when we first signed a portable e-terminal for the receipt of a package or when making a credit card purchase at a large store. In some specialized workflows, external digitizers have been attached to personal computers for almost a decade to make possible the collection of medium-fidelity handwritten electronic signatures.

The introduction of the Tablet PC, however, brought the discussion of e-signatures into sharp focus, because tablets are driving the rapid proliferation of digital forms, and with these forms comes the need for signature collection, for any or all of the three reasons listed above.


An e-signature collected on a Tablet PC is a collection of Stroke objects that are captured in a fully digital, vectorized format by a custom component or pen-enabled form:

Figure 1. Composition of an e-signature on a Tablet PC

How the Stroke objects that constitute a signature should be collected, stored, and authenticated are topic areas that are not discussed in the Tablet PC Platform SDK or other Microsoft software documentation. This paper provides some initial context for your own research and discussion around these tasks.

The four core discussion and policy areas you should consider with respect to e-signatures are:

  • Collection—can your e-signatures be collected with a simple InkPicture control, or with a component that you've built to match your business needs, or with a third-party product?
  • Protection—how can the expropriation and misuse of the e-signature's Strokes be prevented?
  • Storage—how and where should the e-signature's Strokes be saved, if at all?
  • Validation—how can your application perform signature recognition (validation) of the collected Strokes?

In the following sections, we address these areas and provide some suggestions based on our own solution-development experiences.

Capturing E-Signatures

Application Design Considerations

A software developer who is considering adding e-signature capabilities to an application should first define the business requirements, risks, and benefits of doing so. High-visibility and high-value workflows will most likely be the first ones in your organization to be targeted for Tablet PC-centered digital forms, and automating these key workflows provides the opportunity and responsibility to define some standards and practices for your own e-signature collection initiatives.

Here are some areas to explore when planning for e-signatures in software applications:

  • Is there a legal reason for collecting an e-signature? There are specific government-issued laws, regulations, and policies that require a signature in order for a process or transaction to be valid. Digitizing such a process requires you to collect an e-signature, and to do so in accordance with the guidelines prescribed by the legislating body.
  • Is there a business reason for collecting an e-signature? In the absence of a statutory reason for signature collection, there may be internal mandates (corporate rules) or external guidelines (industry regulations) that mandate signature collection for a specific process. Any such signature-collection guidelines enforced on physical paper must be equally enforced on digital paper. At a minimum, business processes that involve financial transactions, carry legal liability, or are related to personal privacy are strong candidates for e-signatures.
  • Can an e-signature replace or improve other forms of authentication? Some paper-based workflows use non-signature authentication models that do not convert smoothly to a digital format. In such a case, the use of an e-signature may provide an appropriate replacement. For example, a maintenance process that we are moving to Tablet PCs for the U.S. Air Force currently requires that certain personnel physically stamp a task assignment form when the task is completed, using a familiar rubber stamp customized with the user's signature. The replacement for the rubber stamp in the digital version of this process is an ink component built using the Tablet PC SDK.
  • Is another form of authentication superior to an e-signature? The corollary to the previous rubber stamp example are workflows that currently involve a handwritten signature but may benefit from non-signature authentication when made digital. For example, sealing a paper document in an envelope and then signing across the seal with a pen or wax is an age-old way of ensuring that a document has not been tampered with during transit. Electronic variants of such document delivery processes (e-mail, for example) are more efficiently served by an authentication processes that utilizes digital certificates rather than e-signatures.
  • What is the downside risk or cost of not signing? The requirements for signing an e-record increase in tandem with the risk and/or cost of fraud involving that record. For example, many business documents that were kept under lock and key in paper form are now being posted to intranet portals for broader access by workgroups and project teams. Such documents were hard to alter when in paper form, because the perpetrator needed to have the file cabinet key, the original pen or a matching ink color, some available writing space in the document, and the handwriting style of the original author. In digital form, however, such documents are more easily modified and may require the addition of digital signing and locking mechanisms in order to verify authenticity.

You should anticipate that the ease of collection and storage of e-signatures will cause them to be added to business processes that were previously signature-free.

E-Signature Collection

Once you have determined that your application requires an e-signature, you need to create the software architecture for signature collection. The simplest architecture includes using off-the-shelf applications that support ink to provide signature collection, such as Microsoft Office 2003 (OneNote® or Word) or Windows Journal. Bechtel National, for example, implemented a solution for collecting contract signatures from mobile workers by printing contracts to the Journal file format (.jnt) and collecting the signature in Journal itself. For more information about the Bechtel implementation, see the case study at

For custom-built applications, there are three primary technologies you can use: the InkPicture control, your own custom control, or a third-party component.

InkPicture Control

The InkPicture control is provided by the Tablet PC Platform SDK. InkPicture allows you to:

  • Easily collect and display digital ink strokes.
  • Programmatically control the color, width, pressure sensitivity, and other visual aspects of the strokes' metadata.
  • Programmatically erase or otherwise manipulate the strokes.
  • Display a custom background image ("watermark") in the control.

You can use the InkPicture control in your Windows Forms applications to collect e-signatures. Because the ink collected in an InkPicture control is exposed to the application and could result in unauthorized modification or duplication, you may want to write code in your application to make the e-signature secure. An example of how to do this can be found in e-Signature Protection, later in this paper.

InkPicture in InfoPath

Microsoft InfoPath™ is a form-development platform rapidly gaining popularity on the Tablet PC. Although the best Tablet PC-specific features will not appear until its next version, InfoPath is a viable solution for many form-fill applications, and includes the InkPicture control capable of collecting e-signatures.

Once the e-signature is collected, it is useful to understand what InfoPath does with the digital ink. To answer that, let's peek under the hood—InfoPath stores and transmits the contents of filled forms as XML. To fit into this format, InkPicture fields are serialized as a Base64 stream containing the full-fidelity digital ink, embedded in the metadata of a GIF image. These ink strokes are not easily extractable by client-side script, but they would be easily extracted by any would-be hackers that intercept the form data on its way to the server.

So, for the moment, if you intend to use InkPicture fields to collect e-signatures in InfoPath applications—regardless of whether for authentication or for auditing—the path to the server endpoint must be secured. For Web services and SharePoint portals, this means HTTP over SSL. For direct-to-database connections, steps must be taken to enable security over the underlying connection (set "Integrated Security='SSPI'" for the SQL Server OLE DB provider, for example). For custom, disconnected solutions that batch the form data on the Tablet PC for later transmission, the use of EFS directories, or some similarly encrypted repository, must be enforced.

Custom Component

If you find the built-in capabilities of the InkPicture control too limiting or its data model too open, you can build your own, custom e-signature control to meet your application's needs. By using either managed (.NET) or COM (ActiveX) architectures, you can create an e-signature control to drop into your Windows Forms, Web pages, or Microsoft InfoPath forms. Through custom properties, methods, and/or events, your control can expose functionality that is specific to your application or industry.

At the core of your custom control, you must provide a mechanism for collecting ink, using either the InkPicture control or the lower-level InkCollector class (both are found in the Microsoft.Ink assembly).

In addition to reusability, the value in creating a custom component for e-signature collection is that you can flavor the control to match your business needs. For example, your e-signature component may include code to:

  • Attach relevant metadata to the signature using the ExtendedProperties of ink strokes. Useful metadata attached to a signature object could include timestamps and user identity. For the techniques to use for this task, see Using CustomStrokes, Renderer, and ExtendedProperties to Manipulate Ink and Tablet PC Development Notes: Using a Timestamp on Strokes.
  • Safely store the signature into an encrypted file or database record.
  • Protect the e-signature from access through the Windows Clipboard or other application spoofing. For more information about keeping an e-signature secure, see e-Signature Protection.
  • Provide signature verification services to validate that the signature is genuine. This task involves advanced recognition not provided in the Tablet PC SDK and is beyond the scope of this paper.

Third-Party Tools

Prior to the advent of the Tablet PC, independent software companies provided tools to support the collection of e-signatures, but these tools collected pixels (video display points), limiting the ability of the toolset to collect the types of rich data available in the ink Stroke object model. As these software companies extend or rebuild their tools to take full advantage of the Tablet PC architecture, the capabilities of their tools will rise dramatically.

In addition to providing client-side tools, software companies must empower developers on the server-side of the development process. On the server, the following software needs arise:

  • Collection—solution developers need software tools, such as Web services, for securely transporting e-signatures from applications to servers where they are verified and/or stored.
  • Storage—ink signature data streams are not small, and are composed of Stroke data that can be extracted and repurposed, perhaps in nefarious ways like e-forgery, so software vendors must provide tools for compression, encryption, and storage of e-signature data.
  • Authentication—the outstanding text recognition capabilities of the Tablet PC operating system do not extend to signature recognition; software vendors must build tools to support the comparison of a collected e-signature against a reference e-signature. For more information about signature recognition, see e-Signature Recognition, later in this paper.

A discussion of some software vendors providing e-signature tools is found in e-Signature Software, later in this paper.

e-Signature Protection

As your application collects e-signature strokes, you must take care to prevent the expropriation of the signature by malicious users or code. Digital variants of paper signature-protection best practices (the digital equivalent of shredding your old credit card receipts) must be put in place in your applications.

As a simple example, any component placed in your application that supports the collection of e-signatures should not be exposed to the Windows Clipboard. It is inappropriate to allow someone to open a signed digital form, select another person's signature, and copy it to another application or file (or to paste in a signature from another application or file); this is signature hijacking. A simple way to prevent this is to 'flatten' the displayed signature to a graphic element once the signature is complete, and to store the original strokes in an inaccessible portion of the application.

The InkPicture control does not offer this capability inherently, but the following C# code demonstrates just how easy this is:

// User is done signing -- lock down the control.
inkPicture1.InkEnabled = false;

inkPicture1.DefaultDrawingAttributes.Color = Color.DarkGray;

// Save the ink strokes' image (and its relative position).
Rectangle bbox = inkPicture1.Ink.GetBoundingBox(); // used below
byte[] gifbits = inkPicture1.Ink.Save(

// Privacy: discard the user's ink strokes!
inkPicture1.Ink = new Ink(); // can't be null...

// Render a static representation of the signature, in its place.
using (System.IO.MemoryStream buffer = new System.IO.MemoryStream(gifbits))
using (Image sourceimage = Image.FromStream(buffer))
   inkPicture1.Image = new Bitmap(inkPicture1.Width,inkPicture1.Height);
   using (Graphics g = Graphics.FromImage(inkPicture1.Image))
      Point[] points = { bbox.Location, new Point(bbox.Size) };
      inkPicture1.Renderer.InkSpaceToPixel(g, ref points);


E-Signature Storage and Transmission

A user's signature reflects his or her identity. Digital ink, as well as any biometric parameters distilled from that stream, can potentially be stolen, copied, and replayed by a malicious attacker wishing to steal the signer's identity.

E-signatures are somewhat unlike fingerprints, retinal patterns, and smartcards, in that they exist in a well-defined binary format. If handled improperly or insecurely, they can be easily obtained by malicious individuals. In this sense, an e-signature is more like a conventional password than a true biometric—unfortunately, unlike a conventional password, it is not so easy for a user to change on a regular basis!

The rapid evolution of the Internet has led to acceptance of network protocols that transmit passwords in the clear (or in some easily reverse-engineered encoding). This is unfortunate, and POP3 and FTP—the protocols most widely used to read e-mail messages and maintain Web sites—are both notorious offenders in this respect. Even many modern protocols, such as the Terminal Services RDP protocol and the FrontPage Web Server Extensions, lack an adequate challenge/response authentication mechanism. E-signatures must not be handled so carelessly.

Further, it's important not to limit our consideration to network mediums—Tablet PCs provide highly mobile, and often disconnected, mediums for forms with e-signatures. They can be stolen (or perhaps lost, and later recovered) by malicious parties. Thus, it follows that whether talking about batching e-signatures on the local hard drive, or transmitting them across a network, both mediums must be considered untrustworthy and potentially hostile.

Probably the best and easiest step that can be taken to securely store and transmit e-signatures is to use encryption everywhere. Always communicate over server-authenticated SSL connections (think HTTPS instead of HTTP for your Web services), and always enforce the use of Encrypting File System (EFS) on tablets to protect directories holding sensitive data on the client platform. The signature itself can be encrypted and locked after collection and before storage in order to make it secure; for an example of this, see the case study for Global Digital Health at

In other cases, the best way to avoid leaking the biometrics of an e-signature is to never store or transmit it at all; if an application collects an e-signature for visual verification or printing, the best solution is to simply throw away the digital ink as soon as possible and keep a "screenshot" of the signature, as demonstrated earlier. This is tantamount to faxing a signed document, only a low-resolution bitmap image of the e-signature is transmitted, which provides enough information to create the required audit trail but not enough for an attacker to steal the signer's identity. Of course, in "flattening" the signature and removing the ink, any relevant intrinsic data (such as individual strokes) and metadata (such as timestamps) in the signature are lost, and thus the audit value of the e-signature is proportionally reduced.

e-Signature Recognition

In some workflows, simply collecting an e-signature is not useful without the ability to authenticate the validity of the signature, and therefore the signer. Public toolsets for e-signature recognition remain limited, so you may end up exploring the creation of your own validation infrastructure. This topic provides a high-level overview of biometric e-signature recognition on the Tablet PC, specifically for purposes of user-authentication and transaction auditing, along with a brief introduction to some of the computational geometry algorithms and analyses used to attack this problem.

The Tablet PC platform employs an electromagnetic digitizer to capture a user's pen strokes in a high-fidelity digital format—a type of vector-graphic format. The collection of strokes comprises a sequence of points in Cartesian space, plus zero or more channels of additional data (pressure, pen angle, and so on). The memory model for digital Ink comprises a sequence of Stroke objects. Each Stroke object, in turn, is a sequence of packets—X and Y coordinates along with other channel data (typically X, Y, and pressure in the current generation of Tablet PC hardware).

The (x, y) resolution recorded depends on the capabilities of the Tablet PC hardware. Internally, the coordinates are stored at whatever resolution the hardware produces. The actual resolution of the digitizer hardware is also stored, and used to enable transformation to other resolutions. The APIs of the Tablet PC SDK all transform the Ink into a 2,540 dots per inch (dpi) coordinate space before returning it to the caller. Internally, however, the hardware's resolution is used, which varies by make and model. Currently, coordinate data is recorded by the leading digitizers at approximately 2,540 dpi resolution, but the stream is passed through a low-pass filter function to reduce jitter in the stylus movement, effectively lowering the actual resolution.

The current generation of Tablet PC digitizer hardware returns eight bits of pressure information; however, a few digitizers do not supply pressure data at all (or else supply a different resolution or pressure). E-signature code should query the capabilities of the digitizer hardware to determine its support of pen pressure, and adjust accordingly.

In the future, Tablet PC hardware can be expected to offer more channels of pen data (angle, orientation, and so on), richer coordinate information, and perhaps 16-bits or even 32-bits of pressure data. With respect to e-signatures, more data is better when it comes to designing software for signature recognition. However, challenges will remain if your solution must support not only current-generation hardware platforms but also those that lack the ability to provide key information such as pressure or pen angle.

Biometric signature recognition is largely a computational geometry problem. In a nutshell, the problem is to analyze the sequence of strokes (each stroke's stream of pressure-data and point-data) and to evaluate it against one or more known ink samples of a user's signature.

In practice, the problem is quite difficult and a little fuzzy—no person is capable of reproducing his or her exact signature the same way each time with utter perfection. The resolution of the Tablet PC digitizer is extremely high, so it is not reasonable to expect and require an exact match; therefore, e-signature recognition algorithms must allow some variance, or "tolerance." This variance must be carefully tailored to the needs and risks of the application being developed (more on this later).

E-signature recognition includes the broader, more general computational geometry problem of shape-recognition. Table 1 contrasts these two problem spaces (signature recognition and shape recognition) in the following two ways: the ordering of strokes is well known, and less attention needs to be paid to rotational and scalar invariance.

Table 1: Shape vs. Signature Recognition

  Shape Recognition Signature Recognition
Rotational invariance more important less important
Scalar invariance more important less important
Stroke ordering unknown known

Although the accuracy and reliability of e-signature recognition applications is (typically) more important than that of most shape-recognition applications, the fundamental problem is actually simpler: the ordering of the strokes is well known, and less effort must be expended to consider rotated, inverted, or stretched ink signatures. Think of it this way: a triangle is still a triangle, even if it's stretched horizontally, rotated 90°, and drawn in three separate pen strokes, so an application that was triangle-literate would need to account for this fact. In contrast, the consistency of the way a person signs his or her name means that applications collecting e-signatures probably do not need to be able to recognize a user's signature written sideways or stretched (see Figure 2). The burden is on the application developer to present the users with reasonably consistent user interfaces for the e-signature fields, including constant size, orientation, and aspect ratio; when this is done, and users sign with a reproducible number of pen strokes, many recognition challenges are reduced.

Figure 2. A stretched triangle is still a triangle but a stretched signature is not the same.

We can make an analogy to the implementation of handwriting recognition. Users of the Tablet PC have been surprised to learn how well the Japanese Kanji handwriting recognizers work, even when compared to US English or other languages with simpler, Western alphabets. Although the Kanji alphabet looks far more complex, writers of Kanji on the printed page are trained to pen each character with a well-defined sequence of brush strokes. Writers of US English write in a wider variety of scripts and styles (print, cursive, block letters, and so on). The result is that the Tablet PC is often able to recognize a Kanji character before the user is even finished writing it, while users of Western-language tablets are more often required to correct the recognizer's inaccurate assumptions. E-signature recognition is more similar to Kanji handwriting recognition than to English recognition, in that the user's sequence of signature strokes is consistent and well-rehearsed.

Geometric Approaches

What information should you analyze in order to evaluate a user's e-signature? Given a raw stream of X and Y coordinates, along with pen-pressure, there are many possibilities. The design and implementation of signature-recognition engines is a bit of a black art, but most involve some combination of the following geometric analyses:

  1. Velocity profile (pen velocity over time).
  2. Pressure profile (pen pressure over time).
  3. Angular momentum profile (net curvature of the individual strokes, plus a finer-grained analysis of cusps, inflections, and other derivatives).
  4. Arc/line segmentation pattern (analysis of the strokes' composite geometry, decomposed into an approximation of arc-segments and line-segments).

A robust e-signature recognition engine will likely include all of these four factors, perhaps beginning with a qualitative analysis of the strokes' composite geometry (representative sequence of arc and line segments) as a quick yes, no, or maybe check, followed by a more quantitative analysis of pressure, linear, and angular momentum profiles.

A complete treatment of such analyses is beyond the scope of this paper, but Figure 3 illustrates what this data looks like. You can see the richness of geometric data inherent in a typical user's e-signature, and if you study the chart closely, you can see that the data correlates nicely to the pen strokes, even to the naked eye (hint: the drop-offs in pressure mark the boundaries between strokes). However, you can also see that there is a lot of "noise" to be dealt with. Applying appropriate heuristics to distinguish noise from actual, intentional marks and curves is the delicate fine art of e-signature recognition. Just how delicate of an art is a function of the intentions of the target application.

Figure 3. Ink Signature Geometric Data.

Consider the Application

There are two fundamental error-paths in e-signature-recognition algorithms: false-negatives and false-positives. False negatives occur with a user (let's call her Alice) attempts to sign her e-signature, but it is not properly recognized. False positives occur when another user (Bob) attempts to forge Alice's signature, and is successful.

Clearly, for applications using e-signature recognition for authentication and access-control purposes, the latter possibility is far more worrisome. Consider as an example logging on to Windows with an e-signature. In the former case (false negatives), Alice can try simply try again until she's successful. In the latter case (false positives), Bob can log on to Windows as if he were Alice.

Depending on the details of your recognition engine's implementation, and the strictness of your application's security requirements, it may prove very difficult to eliminate (or sufficiently reduce) the possibility of false-positives without also incurring an unreasonable number of false-negatives, adversely affecting usability. There are ways to work around this constraining problem. For the authentication scenario described above, one simple but effective way to simultaneously increase the level of security and decrease the frustration of false-negatives is to require the user to tap in a short (say, 4-digit) numeric PIN code, in addition to the e-signature. With the addition of a second biometric, the tolerance requirements on the recognition engine can be greatly relaxed –Bob will have to know Alice's PIN and execute a reasonable forgery of her signature in order to steal her identity. This is similar to the common use of a PIN with smart card authentication systems to guard against smart card misuse after loss or theft.

Authentication, however, is not the only use case for e-signature recognition. Many applications require a user's signature for auditing purposes—the digital ink will be saved in a database record, to be retrieved later only if needed. As an example, consider a point-of-sale application which collects the buyer's e-signature when a credit card is used or a check is written for a purchase. It may not be feasible to validate the user's signature in real time—computer networks can be still be slow or troublesome backbones—but the bank and credit card company still require the signature to be on file in case the transaction is later disputed. At the time of dispute, the fidelity of the e-signature's strokes, coupled with a recognition engine, provides a powerful audit trail.

Going a step further, you can imagine that banks may wish to passively monitor their users' signatures for signs of fraud, by raising a red flag on an account if a signature is recorded that does not correlate well to the user's previous or stored baseline e-signatures on file. Most credit card companies already monitor several other data points and patterns of account usage today for this very purpose, but without capable e-signature recognition they're limited to monitoring crude and superficial transaction data elements (such as sudden variations in a purchaser's geographic location). In this type of data analysis, this application scenario is the exact opposite of authentication, where false positives in e-signature recognition are actually preferred over false negatives, in order not to unintentionally flag too many honest customers.

Clearly, no single approach to biometric signature recognition is appropriate for all applications. Over time, the market will mature to provide a variety of geometric techniques, which can be applied keeping the exact nature of the application in mind.

E-Signature Legislation

Many state and local governments are moving to the use of electronic records (e-records), and are creating policies and legislation to support these efforts. This topic discusses three examples that impact e-signatures.

First, the federal government paved the way in 2000 by passing the Electronic Signatures in Global and National Commerce Act, generally referred to as the Federal E-Sign Law, which was designed to endorse electronic contracting and improve commerce by granting electronic signatures the same legal status as traditional handwritten paper signatures. The act was technology agnostic and did not provide technical specifications or mention tablet computing, thus the law goes beyond e-signature to include all manner of digital signatures and electronic signing.

Next, the first e-signature pioneer on the state level—the State of New York—passed the Electronic Signatures and Records Act ("ESRA") in 2001, in order "to facilitate e-Commerce and e-Government in New York State by giving electronic signatures and records the same force and effect as signatures and records produced by non-electronic means."1 ESRA provides e-record and e-signature guidelines for use by state agencies and local governments in the areas of authenticity, integrity, security, and confidentiality. You can expect your local government to enact similar legislation in the near future, and if you author software for use by a government or a company that interacts with a government, you should review such legislation to determine how it impacts your software applications.

Finally, the United Nations weighed-in on the subject in 2001 with the Model Law on Electronic Signatures with Guide to Enactment. Notable for developers are the following provisions in this statute that provide a framework for use in creating policies for your own e-signatures:

"3. An electronic signature is considered to be reliable [...] if:

(a) The signature creation data are, within the context in which they are used, linked to the signatory and to no other person;

(b) The signature creation data were, at the time of signing, under the control of the signatory and of no other person;

(c) Any alteration to the electronic signature, made after the time of signing, is detectable; and

(d) Where a purpose of the legal requirement for a signature is to provide assurance as to the integrity of the information to which it relates, any alteration made to that information after the time of signing is detectable."

E-Signatures and the Law

In the absence of a watershed court decision affirming or limiting e-signatures, businesses and software developers in litigation-prone industries and workflows can be expected to look at this topic with healthy caution. The exercise of caution in application development can be done in at least two ways:

  • The collection of additional and unique personal information along with the e-signature, such as a biometric or PIN as discussed earlier in this paper.
  • The exclusion of e-signatures from workflows where tangible property changes hands.

As an example of the second list item, the legislators who created the New York State e-signature act chose to minimize the risk of legal challenges to the act by specifically excluding support for e-signatures in a few areas where they expected the thorniest disputes to arise, namely on documents related to: (a) disposition of person or property like wills, trusts, powers of attorney, and health care proxies, and (b) the conferring of title to real property or money through instruments like deeds, checks, and notes.

Courts have consistently upheld, in e-commerce disputes, the enforceability of electronic agreements obtained by means of "click-through" agreements in which a consumer accepts a license or contract with a mouse click on a Web page. Also, the Federal E-Sign Law derived from the Uniform Electronic Transactions Act ("UETA") of 1999—a model law for states—the provision that an e-signature may be challenged on the same legal grounds and with the same standing as a traditional written signature. As a result, challenges to e-signatures flow along the same lines as challenges to paper-based signatures: Is the signature authentic and its document unaltered?

E-Signature Software

Because it is a relatively new platform, we found no commercial off-the-shelf e-signature software written from the ground-up for the Tablet PC. However, several software vendors have extended their e-signature product offerings to be compatible with a Tablet PC. Three of them are mentioned briefly here.

ApproveIt, by Silanis Technology Inc.

ApproveIt is an electronic approval management solution that generates and manages the use of electronic signatures in a wide variety of electronic business documents, forms, and data. ApproveIt automatically places electronic signatures into documents in a manner consistent with the requirements of legally binding signatures to ensure the validity of signed documents. This product combines the cryptographic functions of an x.509.v3 standard digital certificate with the image of a person's e-signature to use to authenticate data. Using a hashing algorithm, it permanently links the e-signature to the exact contents of the signed document. Each time the document is opened, the e-signature automatically verifies and detects whether data has been changed since the document was first signed. If a change is detected, the previously applied e-signature is invalidated. The product works in Acrobat PDF, Adobe Capture, Microsoft Word and Excel, and PureEdge InternetForms, but is not available as a component for application development.

Figure 4. ApproveIt

SigPlus, by Topaz Systems Inc.

Topaz Systems has built a solid e-signature component. It ships as a Microsoft ActiveX control with a managed wrapper and has a rich object model, with methods like GetNumberOfStrokes, properties like EncryptionMode, and events like PenUp. You can lock the signature, save it as a signature file or an image file, and choose from multiple encryption and compression settings. Sample source code is posted on their Web site.

While this component does not inherently expose its object model to InfoPath version 1.1, we were able to hack around the limitation in the InfoPath JavaScript.

In less than five minutes, we were also able to reference the tool and create a usable managed Visual Studio application that collected a signature and locked the application's fields upon completion:

Figure 5. SigPlus component in a Windows form.

SignDoc and SignSecure, by SoftPro

SignDoc is an extension for document-centric applications, including Microsoft Word, Adobe Acrobat, Lotus Notes, and InfoPath. It adds e-signature collection to a document to provide security and consistency. The user's signature and the contents of the document are bound together by a unique hash code that protects the integrity of the document (contents and signature) against unauthorized alterations. Documents produced with SignDoc contain an invisible, encrypted data set of signature characteristics; this data set documents a proof of intent and the identity of the signer, is connected to the document, and can't be extracted.

Figure 6. The SignDoc extension.

SoftPro also produces SignSecure, a biometric alternative to passwords and PINs that allows an ink signature to be used to log on to a Tablet PC. SignSecure replaces the Windows Security dialog—the familiar screen requiring the CTRL + ALT + DELETE sequence—with a signature dialog. Each computer user enrolls with SignSecure and then creates reference signatures for use by SignSecure during the login process. These reference signatures are stored on the Tablet PC or downloaded to the PC from SignBase, a SoftPro product that provides a shared database of reference signatures. Local reference signatures are encrypted and securely stored, and communication between the SignBase server and the Tablet PC is also encrypted. A tolerance can be set in SignSecure to determine the degree to which a signature may vary from the reference signatures and still be accepted.


The scope of this paper has been broad rather than deep, serving as a primer for issues from the collection, protection, preservation, and recognition of e-signatures, to the various application scenarios and bodies of law that apply to e-signature recognition for purposes of verifying intent, auditing transactions, and even user identification. Because e-signature collection is a new domain, the body of knowledge is evolving and will provide fodder for many future, related papers.

It is clear that the Tablet PC, as a hardware platform, is a quantum leap forward from paper and from the familiar small, grainy, stylus-based signature collection devices that have been deployed over the prior decade by banks, retail stores, and the package delivery industry. Rather than capturing a course-grained "bitmap" image of an e-signature, the software and hardware on the Tablet PC platform are capable of recording, storing, analyzing, protecting, and transmitting a very high resolution, pressure-sensitive, vector graphic representation of users' signatures, leveraging the richness of digital ink.

Because the fidelity of e-signatures that are recorded on the Tablet PC platform is high enough to be used for biometric-authentication purposes, this power comes with a responsibility: information stored on personal computers is prone to unauthorized duplication, theft, or tampering, leaving software applications and their developers with the burden of taking measures to prevent such acts. In this paper, we've highlighted some ways to mitigate or eliminate these risks.

The challenges do not belong to application developers alone, however—legal professionals in organizations deploying e-signature applications on the Tablet PC must become conversant in the issues and approaches. Clearly, e-signature technology on the Tablet PC platform is a far more capable, flexible, and viable solution than any other similarly-purposed system in place today—from document scan/fax services, to the completely unauditable "click-through" authorization schemes found on Web sites. And fortunately, state, federal, and international legislators have begun to pave the way for more accurate definition of, and broader support for, e-signature technology.

1 Electronic Signature and Records Act (ESRA) Guidelines, revision September 2002