«NAMIRIAL GmbH Legal Office: Seilerstätte 16, 1010 Wien, Austria Main Office: Haider Straße 23, 4025 Ansfelden | Phone: +43-7229-88060 | ...»
Remote e-Signing via the Web
Send and Sign Documents Online. Anywhere.
Anytime. On Any Device.
Legal Office: Seilerstätte 16, 1010 Wien, Austria
Main Office: Haider Straße 23, 4025 Ansfelden | Phone: +43-7229-88060 | www.xyzmo.com
Fiscalnumber 09 258/9720 | VAT-ID: ATU70125036
Maximising the value of digital transformation is important in most industries—and critical
for survival against competition for some. Organizations that sell virtual rather than physical products, especially, have a cost base that is largely focused on development, marketing and distribution as well as servicing which makes such organizations highly sensitive to digital transformation. For these, there needs to be a concerted focus on automating core activities to boost self-service and “straight through” transaction processing.
With online e-signing it's easy to get documents signed on their own devices without having to meet the recipient in-person. Simply send documents links out for signature to other people, get instant visibility into your document status, access completed documents, and much more. Whether you or your recipients are in the office, at home, or on the go, online e-signing works every time from every device.
If you send documents out for signature, the recipient gets an email with a link to your document and can sign on a smartphone, tablet, or any web/HTML5-enabled device without the need to download anything. You can have multiple signers and get them to sign in the order you need. E-signatures don't just let you reach customers on the devices they most commonly use; they also let you create compliance and comfortable engagement. E-signature solutions allow you to build in markers (tags) and metadata about documents that can help consumers understand what they are signing and what fields they have to fill out. To eliminate human error, electronic documents can also include auto-check tools that identify common mistakes in time. All these functions together add up to a better quality of the contracts and customer experience.
This white paper will help you to understand what a remote online e-signing solution needs to provide. With an emphasis on why the last mile to the signer needs to be closely managed and what this includes, it will help you to select the most appropriate methodologies for authenticating a remote signer. Then we will discuss the most fitting use for each signing technology—biometric, HTML5, or certificate-based signing—and why this is, depending on the actual use case. There you will see that e-signing is about more than simply signing digital documents—it’s about optimizing the whole process. Finally, we also illustrate the end-to-end business process that a real-customer (The Phone House) has implemented.
Page | 2 Table of Contents Abstract
1 Typical Functionalities
1.1 Definition of the transaction (signing-envelope)
1.1 Complete the transaction (signing)
2 Managing the Last Mile
1.3 Creating transactions with multiple documents
1.4 Routing / Workflow
1.5 Defining document ceremony per recipient
1.6 Reminders and alerts
3 Authentication Methods
1.8 Email authentication
1.9 Recipients required to enter an access code
1.10 Leveraging trusted authentication models that you already have in place........... 8 1.11 Using social networking IDs such as Facebook login
1.12 Sending an SMS with a one-time password
1.13 Authentication with national identity cards or passports
1.14 Authentication and signing with third-party digital certificates
4 E-Signing Technologies
1.15 HTML5 signatures
1.15.2 Type-2-Sign (Typing the name)
1.15.3 Draw-2-Sign (Drawing the name with a finger, mouse, or stylus)............... 12 1.16 Certificate-based personal signatures
1.17 Forensically identifiable signatures (biometric signatures)
1.17.1 Capturing devices for biometric signatures
1.17.2 Using a smartphone as a signature pad
5 Platform Aspects
6.1 The Phone House Netherlands
Page | 3 Typical Functionalities To efficiently process document based transactions with remote recipients via internet,
online signing solutions typically consist of the following three basic functionalities:
• Definition of the transaction (Set up a signing-envelope)
• Complete the transaction (complete the contract and signing)
Each task has certain typical steps, as outlined below. Additionally the system has to offer administration features to manage the users and templates, and adaptable branding if required.
Definition of the transaction (signing-envelope)
Actions performed by the sender:
1.1 Complete the transaction (signing)
Actions performed by one or more recipients:
• Signers receive an email with a link to the document.
• They click the link.
• There is typically no need to download or sign up for anything.
• They may have to further authenticate themselves, when required by the sender.
• They can review and print the document or complete form fields and add attachments.
• Whenever they are ready, they execute a signature field using a stylus by hand (“Draw to sign” – on their smartphone or tablet), or they "Click to sign" or "Type to sign" from any web-enabled device including PCs with just mouse and keyboard.
The possibilities and requirements of the most important actions in this step of the signing
process is described in detail in the following sections:
Page | 4
• User (signer) authentication (see section 3)
• Signature execution (see section 4).
1.2 Reporting Efficient reporting should help the sender to pay attention on those transactions, which still require actions to successfully finish them. Such transactions are documented and recorded in order to prove them anytime it is necessary. Therefore a simple overview is
Additionally, you also can send the same documents to a large number of (a bulk of) recipients. Once you send the envelope, a separate envelope for each recipient is created. This is especially useful if e.g. a large group of people need to sign the same document. A typical example is a policy document that all employees must sign.
Page | 6
1.7 Dashboards Dashboard views are important to give a quick overview about the status of your envelopes. Good dashboards not only provide an overview, but also allow a fast search through and editing of the areas that require your attention.
Page | 7
1.8 Email authentication This scenario is typically suited to HTML5 signatures for B2B scenarios and non-businesscritical documents for which you want to make signing as easy as possible. You simply send the link to the inbox of the recipient; no further authentication is necessary. In case of a dispute, you can prove with the audit trail that you sent the document to a specific email address, and often you have the IP-address of the computer and geolocation as well, if the recipient did not explicitly block it.
All of the following authentication methods start with this scenario and add additional authentication steps on top. Although arguably not quite as robust as a full biometric signature, each additional step below adds a little bit more evidential weight in case of dispute, making them good enough for many use cases. Strict methods authenticating the receiver without any doubt also allow implementation of the advanced electronic signature.
You even may go further and require the use of qualified electronic signatures (QES), however resulting in a limited number of potential users. An overview is given in the following sections.
1.9 Recipients required to enter an access code In addition to the above, you can present the recipient with a security request page and require entry of a code to access the documents for viewing and signing. After the access code has been entered correctly, the recipient is led through the normal signing process.
The access code is not sent in the same email that includes the link, as this would make it totally unsecure. Typically, the code is not even sent by email at all, but instead is communicated via another channel such as by phone. To have a code that works for a longer time, you can choose to have the access code agreed upon between the parties in a separate process.
The value of this is in case of a dispute: The sender can prove that the signer must have had access to the access code in order to sign the document.
1.10 Leveraging trusted authentication models that you already have in place Some businesses have customer portals or other software already in place and the user is identified by such systems. Let’s assume the user is within a banking application where he/she manages all his/her transactions. If the user has to sign a document and has already been properly authenticated, then there may be no need for further authentication. But the proof of authentication has to be included in the audit trail in any case.
Another scenario is one in which the recipient already uses a secure authentication method (e.g., a token) for other purposes and this infrastructure is repurposed to authenticate him/her for document signing. As above, the authentication process must be included in the audit trail of the signed document to provide evidence.
1.11 Using social networking IDs such as Facebook login With this scenario, popular social networking sites are used for authentication. Most of them provide services to allow third-party applications to authenticate users. The quality of this authentication depends very much on the quality of the social network profile that is used for authentication. In addition, the quality and amount of the data that you receive about the Page | 8 user from the social network for the audit trail has to be considered as this can be restricted to very basic information types.
1.12 Sending an SMS with a one-time password This authentication method capitalizes on the fact that mobile devices provide, worldwide, a very good means of identification for their owners. Many people carry mobile phones throughout the day and have them within reach at all times. The mobile telephone number is a strong identifier for the owner. This is why many banking and other applications already use this method for online transactions.
Additional security can be added if the one-time password is time-limited, e.g., if the recipient has to enter it within the next 5 minutes.
Another consideration is whether the one-time password should be valid only for one signature or for the entire process.
In addition, it’s recommended to include a unique identifier for the transaction in the SMS sent to the recipient together with the one-time password. This unique identifier should also be displayed in the security dialogue where the recipient has to enter the password, to allow him/her to prove that the password is for this transaction alone and not for another.
All of these messages must form part of a proper audit trail for the purpose of being able to prove everything that has been exchanged in the case of a dispute.
It’s worth considering how the sender should be able to handle and define the one-time
password settings. There are three main options to select from here:
1. The recipient can enter his/her mobile phone number himself. Clearly this is convenient for both the sender and the recipient, but it invites potential misuse by the recipient.
2. The sender defines in advance which mobile number has to be used and the recipient cannot change that. This scenario is very common as it adds considerable security to the process.
3. Finally there are scenarios where both parties—recipient and sender (e.g., a sales employee)—should have no chance to define (change) the mobile number for the recipients and often do not even see them. In this scenario, the sender can only select the recipient from a list of names. The mobile numbers are stored in a central place and cannot be adjusted by the sender. This can even be taken a step further with an upstream process in which the recipient agrees, for example when visiting the branch, in writing that in the future, a one-time password sent to his predefined mobile number can be used as an equivalent to his signature.
Certain countries assign the same legal value to a proper implementation of this method— or special, country-specific versions of it in conjunction with certificate-based signatures (see Section4.2)—as a handwritten wet-ink signature, an example being “Handysignatur” in Austria.
Page | 9
1.13 Authentication with national identity cards or passports Many countries supply their citizens with electronic identity (eID) cards that provide the machine-readable travel document functionality specified by the International Civil Aviation Organization (ICAO). In Europe, most ID cards are based on the European Citizen Card (ECC) specification and not only print the cardholder’s personal data (e.g., name, date and place of birth, nationality) on the face of the card, but also store the data in the integrated chip. Cardholders can use this eID function to carry out legally recognized transactions with public authorities and private companies via the internet.
Germany's new identity card (nPA), for instance, achieves access control of the personal data stored on the card through a Password-Authenticated Connection Establishment (PACE) protocol and Extended Access Control (EAC). The PACE protocol performs user authentication using a Personal Identification Number (PIN) and establishes a secure connection between the ID card and the card reader to protect the communication across the contactless interface. The cardholder gives his/her consent for card access by entering the PIN.