eSignature requests are orchestrated in the DekkoSecure platform file sharing interface. These requests can be sent to one or multiple existing or new users, and approval markup requirements can be specified (ie name, date, signature) per-user. Users that receive an eSignature request are notified via email and must log in to satisfy the request, meaning they are authenticated and authorised before signing can take place.

Documents supported for eSignature request are PDF and DOCX (Microsoft Word file). There are no file size limits for request files.

The signing interface is designed to facilitate fast eSignature workflows by making approval request requirements easy to locate and input. Required fields such as name, date and signature can be auto-filled.

The DekkoSecure web application captures events that are associated with eSignature requests. In a typical approval workflow, this will be when a document was uploaded, shared, downloaded, marked up, and approved:

Audit is viewable per-file, and can also be retrieved as a Hub admin or Tenancy admin.

Documents that are sent for approval requests or are approved can also be shared with other parallel users for distributed visibility and control.

In addition to parallel sharing, files with pending or current eSignature requests can be placed in shared folders to group them with supporting or other relevant documents. There are no file size or type limitations for files in the same folder.

Approval files are encrypted by the DekkoSecure web application and then uploaded to the DekkoSecure cloud. All elements added to signed documents (text, watermarks, signature, etc.) are also encrypted. The only users who can access the data (file and markup) are the file owner, approver, and any others given sharing access. This means that DekkoSecure, as the service provider, can never see what is being shared or discussed between users. Alternative services that offer standard encryption ("in transit" and "at rest") hold the key to the data, so they can access it or accidentally leak it. This scenario is the opposite of Zero Knowledge.

The encryption key generation and exchange process that takes place when users register and sign a document is completely transparent to users. The DekkoSecure web application handles all security events automatically, meaning users can never make a mistake in securing their account or data. Services that offer encryption with "bring your own key", enterprise certificates, or file-level passwords are highly error-prone because the security of a sharing process relies on a human, either the end-user or an administrator. By removing this human reliance, DekkoSecure becomes even more secure beyond just the encryption itself.

There are 3 options for creating a signature

3. From an image:

After a document is uploaded to DekkoSecure and approved, its unique identity signature is securely stored (called a 'hash'). This value cannot be used to access the document and does not represent the document's content; it is simply a series of numbers and letters.

If you upload a document with a matching stored value, this means that there is or was a document in the system with matching content. Positive matches will report pertinent details about the file such as its owner and, if applicable, user(s) who have signed it. Don't worry about specifying a hash - the checker automatically does this for you.

If you upload a document that returns a negative result, this means that it has never existed in the DekkoSecure platform or, if it did, it has been altered after the point that it was removed (downloaded).