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 Signatures…Is There a Difference?
In a word, YES! Although the terms are often used interchangeably, there is a difference between an electronic and digital 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.
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.
What Type of Certificate Do I Need?
Depending on your needs, there are varying certificate options available:
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.
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.
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.
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,
- A client comes into the business and signs an agreement for a year of service.
- 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.
- 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.
- 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.
- 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.
Can I See Some Code?
- 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:
- Add a check to make sure the client has made at least some sort of signature before clicking the “Yes, I Agree” button:
- And finally capture the image:
- 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:
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:
- iText-digitalsignatures20130304.pdf available at https://iTextPDF.com