Back to List

How to Add Electronic and Digital Signatures to a Universal Application (UWP) with iText

Paul Madary Paul Madary  |  
Aug 14, 2018
When paying for gas at the pump, checking out at Walmart, or electronically signing a contract to purchase real estate, have you ever thought about what technically goes into that electronic signature?  If not, then this is your lucky day! I recently had to implement this functionality in a UWP application, and I am going to share with you what I learned along the way.
Disclaimer: I’m a developer and not a lawyer so please don’t interpret this blog post as legal advice.

What does it take to make electronic signatures legally binding?

In the United States, the main law governing electronic signatures is the Electronic Signatures in Global and National Commerce (ESIGN) act of 2000. There is also the Uniform Electronic Transactions Act (UETA), which has been adopted by 47 states. Those laws require the following criteria to be met to make an electronic signature legally binding:
  • Intent to sign
  • Consent to do business electronically
    • Received UETA Consumer Consent Disclosures
    • Affirmatively agreed to use electronic records for the transaction
    • Has not withdrawn such consent
  • Association of signature with the record
    • System used to capture the transaction must keep an associated record that reflects the process by which the signature was created or generate a textual or graphic statement (which is added to the signed record) proving that it was executed with an electronic signature.
  • Record retention
    • Electronic signature records be capable of retention and accurate reproduction for reference by all parties or persons entitled to retain the contract or record.
  • Opt-out clause
  • Signed copy of fully executed agreement

Electronic signatures and digital there a difference?

In a word, YES! Although the terms are often used interchangeably, there is a difference between an electronic and digital signature.

Electronic Signature

It is the equivalent of a hand-written signature. It can be a client typing their name in a text box, checking an “I accept” checkbox, or some other process that records a person’s agreement to be bound by a contract. In the past, contracts would need to be printed out, signed, and stored. This could take days/weeks; but, with electronic signatures, it can be completed in minutes. 

Digital Signature

It is more like having a notary public stamp a document assuring that the signatures are valid and that the document hasn’t been tampered with. Simply put, the electronic signature captures the person’s intent to enter into the agreement, and the digital signature is used to secure the data and verify the authenticity of the signed document.

Tell me more about a digital signature!

Digital signatures are typically used in Adobe PDF documents by individuals and organizations to prove who verified the document on a specific date/time and that the document hasn’t been modified since being signed.
Based on the requirements and work flow associated with signing a contract, there can be one or more signatures on a single PDF document. The actual digital signature is a section of non-visible, hashed & encrypted metadata embedded in the document using a certificate. In addition to the actual digital signature, an optional visible representation of the signature can also be included in the PDF document. The visible portion of the signature can include an image of the signature and/or a description of the signing certificate.
signature example

digital signature properties

What type of certificate do I need?

Depending on your needs, there are varying certificate options available:

Self-signed Certificate

They’re free to create and work to sign PDF documents. They’re great for testing, but they are the least secure option. If they are ever compromised, they can’t be revoked – which could potentially invalidate all contracts signed with the certificate.

Client Certificate

For about $10 per year, a certificate authority (CA) such as DigiCert, GlobalSign, etc. can issue a certificate used for signing PDF documents. The upsides of this solution are that they’re cheap, the certificate is issued by a trusted CA, and it can be revoked if it ever gets compromised. The downsides of this option are that client certificates aren’t included in Adobe’s Approved Trust List (AATL) so the PDF document would display a default warning in Adobe, and (since client certificates have fewer security requirements compared to AATL certificates) they are less secure.

AATL Certificate

This is the most secure option, but because of the added security and certification requirements imposed by Adobe, it can cost thousands of dollars per year (pricing is typically based on the number of signatures needed). For our project, costs for this solution were estimated between $4,000 - $13,000 per year. It requires 2-factor authentication via a hardware key per device, a Hardware Security Device (HSM), or a cloud-based solution. Some AATL solutions offer a new certificate per signature which would facilitate a unique certificate per signer.
Note: If you need to sign a document directly in Adobe, MS Word, or other similar application, the AATL certificate is the only solution available. Finally, this is the only option that will show up as a valid & trusted signature in Adobe by default.
aatl certificate

So, I’ve heard of another topic called Long Term Validation (LTV). What is it?

Say you need to store the signed contract for years or decades but are concerned that the signature may become invalid if the certificate expires, is revoked, or (worse yet) the CA goes out of business. Any of these scenarios, which are external to the signed document, put the validity of the contract in jeopardy. This is where Long Term Validation comes in. LTV adds an extra section to the digital signature that includes a timestamp from a trusted Timestamp Authority and the status of the certificate at the time of signing. By adding an LTV section, everything needed to verify the certificate and signature which were valid at the time the contract was signed is self-contained within the PDF document and have no external dependencies that may change over time.

Let’s get into the details starting with the workflow….

In our specific case,
  1. A client comes into the business and signs an agreement for a year of service. 
  2. We use a tablet device running a custom UWP application to first populate the agreement with the specific terms of the contract for the client (name, price, service plan, etc.). Then we display the filled-in PDF document on the screen for the client to review. 
  3. Once the client reviews the document, they are given the option to either print the agreement and hand-sign it manually or electronically sign the document on the tablet. 
  4. If they choose to electronically sign the document, a “Capture Signature” screen is displayed where the client can sign their name and choose whether they want a copy of the signed contract emailed to them and/or have a physical copy of the contract printed. 
  5. When they click the “Yes, I Agree” button, the PDF contract is digitally signed, a copy of the contract is saved in the database with additional details related to the document, and then the contract is emailed and/or printed based on what the client selected when signing the contract.
long term validation signature

Can I see some code?

You bet!
  • On the UI, I used an InkCanvas control to capture the client’s signature: <InkCanvas x:Name="signatureInkCanvas" Height="125" Width="750" />
  • In the code, the InkCanvas gets initialized in the constructor:
inkcanvas code
  • Add a check to make sure the client has made at least some sort of signature before clicking the “Yes, I Agree” button:
inkpresenter code
  • And finally capture the image:
client signature button code
ink canvas bitmap
ink canvas byte array code
  • In the SaveClientSignature method, that’s where the digital signature magic happens. First, we fill in the PDF document with the name, price, service plan, etc., and then flatten and save the PDF to a file [not shown]. After we have the flattened PDF, we apply the signature using the SignDocumentDigitalSignature method below:
sign document digital signature code
key vault client code
signature code

And there you have it: an electronically and digitally signed document.

Where to Learn More

What makes an electronic signature legally binding: Differences between electronic and digital signatures: Whitepaper from iText on digitally signing documents:


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Spring 2019 Kentico User Group
Apr 17, 2019
Location: Waukesha County Technical College - Pewaukee Campus - 800 Main Street, Pewaukee, Wisconsin 53072 - Building: Q, Room: Q361
Blog Article
How to Overcome the 5 Common Barriers to Manufacturing Innovation
Mitch WeckopMitch Weckop  |  
Apr 04, 2019
Manufacturing companies have an opportunity ahead of them – thanks in large part to information technology advances. These advances are increasing the rate of product innovation, improving cost and quality, enabling planned and predictive maintenance, and launching new business platforms...
Blog Article
Developing on a Raspberry Pi using Gulpjs
Eric DitterEric Ditter  |  
Jan 15, 2019
Developing on one machine and running on another is a tedious process, but sometimes you need to when a library has different features for ARM vs x64 (and then there are always the Windows vs Linux issues). This was the issue I had when I was working on a Raspberry Pi project using Python...
Blog Article
CQS, SimpleInjector, and the Power of Decorators
Dan LorenzDan Lorenz  |  
Jan 08, 2019
Over the years of developing with n-tier style, I was wondering if there was anything else out there. The biggest problem with n-tier for me is that the interfaces and classes tend to get super large. When that happens, you start breaking SOLID principals and unit testing becomes much more...
Blog Article
Async, Await, and ConfigureAwait – Oh My!
Dan LorenzDan Lorenz  |  
Dec 11, 2018
In .NET Framework 4.5, async/await keywords were added to the language to make async programming easier to work with. In order to maximize device resources and not block UI, you should really try to use asynchronous programming wherever you can. While async/await has made this much easier than...