Like the annual return of the swallows to San Juan Capistrano, the topic of digital and other electronic forms of signatures mysteriously recurs like clockwork each year. Adobe, the makers of popular graphics and other software, including the common PDF-based family of Acrobat products, recently flew in with its own entry to the field: eSignatures beta, currently available for free HERE. However, eSignatures’s current limitations, process flow and designed functionality are likely to limit eSignature’s utility and usefulness – at least initially – to a fairly small audience with specific needs.
The vast majority of contracts in corporate contract settings today are still generally “signed” in a relatively conventional manner – either by overnighting originals that are then returned for countersigning, or by signing an execution version and then scanning to PDF for emailing to the other party, who then prints the partially executed PDF, signs and scans the now fully executed contract back to PDF for return to the other party. Given how central PDFs are to this second common method of document execution it seems natural for Adobe to officially step into the picture.
While Adobe Acrobat Reader 9.x already allows rudimentary “signing”, which Adobe states “assure[s] the sender that the PDF reached its intended recipient,” Adobe’s eSignatures takes a different tack that is effectively a step ahead on one hand and a step back on the other, at least under a general understanding of what a “digital signature” is – namely, a process that verifies one’s identity in a reproducible, reliable fashion using a means that prevents or at least discourages non-repudiation, typically through a form of encrypted certificate, whether self-certifying or issued by some central authority. (See Digital Signature Guidelines Tutorial).
Under this rubric, however, Adobe’s eSignatures does not qualify as a traditional “digital signature”. Rather eSignatures focuses on “document authentication” with a means of electronic signature – not on verification of the actual “signers” beyond tying a putative signer to a specified email address. (Compare Digital Signatures with Electronic Signature; see generally, Digital Evidence and Electronic Signature Law Review). Indeed, further, in its definition of “’Electronic Signature’ or ‘Electronically Signed’,” Adobe provides that:
“[f]or purposes of this Agreement, an Electronic Signature shall not include an electronic signature that employs any type of asymmetric cryptography or third party electronic signature certification (‘Digital Signatures’ or ‘Digitally Signed’).”
Adobe has not verified the identity of any signatory *** each signatory or party to a document is responsible for verifying the identity of each other….
if you receive a document or a request to electronically sign a document and you are not the intended signatory, you should not electronically sign the document.
At first glance, then, this seemingly Grand Canyon-wide gap between a verified signature and eSignature’s practice is troubling. However, upon reflection, the lack of individual party verification is less worrying than it appears – at least in corporate scenarios. After all, how many of us have reviewed, negotiated, signed and closed contracts without ever seeing, meeting or verifying – beyond confirming that a given phone number connects to party A’s attorney or email address B communicates effectively with same – the other party to a commercial services or purchase/sales contract in non-financing, non-property transfer context?
(a) the document has been electronically signed by a person purporting to represent each party, and (b) no changes have been made to the document since the time of such electronic signature.
(emphasis added). In essence then, what eSignatures provides is an unverified, but valid electronic signing to a verified document – verified in the sense that Adobe, through eSignatures, acts as an escrow agent holding your uploaded PDF document (and eSignature in beta only accepts PDFs) and then releasing it once fully signed by the designated parties.
With this background in place, in Part 2 I’ll cover eSignatures potential and run down the beta’s surprising shortcomings that Adobe must address if eSignatures is to become a commonly used tool.