Docusign eSignature types, Part III

This is the final part of my blog series on the different types of eSignature that can be used with Docusign and the implications of using them. In Part I, I explained the different signature types, and in Part II I provided a code example of eIDAS-compliant advanced electronic signature. In this post, I’ll show a code example using the identity verification service, IDNow.

Qualified Electronic Signatures (QES)

Qualified electronic signatures use a Qualified Trust Service Provider (QTSP), which is an entity authorized by a government to: 

• verify the identity of the signer, either face-to-face or through a video chat, with a valid identification document 

• validate the identity of the signer at the time of signature through signer-held or cloud-based certificates  

Docusign works with an extensive list of trust service providers, broken down by country, that are available to meet your requirements.

Provisioning QES Signatures for your account

To have the QES Signatures feature added to your developer account, contact Customer Service. To have it added to your production account, contact Sales.

Sending an envelope with a QES

There are a few API objects and attributes that you need to ensure are in your call when creating an envelope with qualified electronic signatures:

• recipientSignatureProviders: The parent object required to define the electronic signature parameters.

• signatureProviderName: The name of the electronic signature provider for the signer to use. For details, see the current provider list or list the types available on your account by using the AccountSignatureProviders::List method.

There are other objects and attributes that can be added to the call. For a full list, please view our API reference. For this example, I’ll be using IDNow, which is an identity verification service that uses the signer’s webcam and microphone to verify the identity of the signer. The signer uses a form of identification along with speaking to a representative to have this information verified. In the example below, I’m using an automated system for the test, which is why the name has the string “: X-MANUALTEST-HAPPYPATH” added to it. It’s very important to include this with the name for the test.

Code example

 {
  "emailSubject": "Please sign the attached document",
  "status": "sent",
  "documents": [
       {
			"documentId": "1",
			"name": "TestDocument.docx",
			"fileExtension": "docx",
			"documentBase64": "documentBase64String"
       }
   ],
   "recipients": {
       "signers": [
           {
               "email": "email@email.com",
               "name": "Tester: X-MANUALTEST-HAPPYPATH",
               "recipientId": "1",                    
               "recipientSignatureProviders": [
                   {
                       "signatureProviderName": "docusign_eu_qualified_idnow_tsp"
                   }
               ],
               "tabs": {
                   "signHereTabs": [
                       {
                           "xPosition": "25",
                           "yPosition": "50",
                           "documentId": "1",
                           "pageNumber": "1"                                
                       }
                   ]
               }
           }
       ]
   }
 }

If you would like to obtain this code for one of the Docusign SDKs, you can use our JSON to SDK tool to transform the call into C#, Java, Node.js, PHP, Python, Ruby, or VB.NET.

Additional resources

• Docusign eSignature types, part 1

• Docusign eSignature types, part II

• Standards-based Signatures

• How Digital Signatures Work

• JSON to SDK Tool