Document Simple Forensic API

This solution allows us to create and manage Simple Electronic Signatures (SES) with a forensic layer. With respect to a normal SES, by adding the proprietary and patented methodology that creates a forensic layer (following the standard ISO/IEC 27037:2012), WT offers a signature with a higher probatory value, positioning it between a SES and an AES. On top of that, in this signing process, one can verify the identity of the signer by sending an OTP via SMS, adding more probative value.

The typical use case for this solution is a company that wants contracts to be signed electronically using a SES but needs more probative value in case of litigation but does not want to provide an AES. The company must create this type of signature using the endpoint [operation/createSignature] and specify the parameter isForensic = true (that is the default value) in the body, in addition to the remaining required parameters.

The following diagram shows, at a certain level of abstraction, how the signature interaction takes place once WT is integrated within the company's process.

The previous diagram not only shows the way the user and the company interact between each other once WT has been integrated but also shows some of the WT internal processes (for transparency sake).

  1. A user/signer wants to sign a document.

  2. The company creates a signature using the endpoint createSignature with property isForensic = true.

  3. WT initialises the signature entity that will represent the interaction during the whole process.

  4. WT will return to the caller the created signature object containing the forwarding URL (F-URL) to which the company will redirect the singer.

  5. The company's Web Server responds to the HTTP request sent by the user in step 1 with an HTTP Redirection to F-URL.

  6. The signer’s browser visits the F-URL to WT.

  7. WT will request the corresponding signature interaction for the effective URL (E-URL) where the page with the PDF will be served.

  8. WT initialises a dedicated isolated secured container from which the signing environment will be served, and that will contain the tools for creating the forensic layer.

  9. The E-URL is returned to WT.

  10. WT will respond to the signer’s request in step 6 with an HTTP Redirection to E-URL.

  11. The signer's browser visits the E-URL served from the isolated secured container where the signature will effectively take place.

  12. The secured container responds with the page containing the PDF to be signed.

  13. The signer will interact with the page by viewing the PDF, fill-in fields and drawing the signature (depending on the configuration), and finally will press the button that will conclude this interaction.

  14. If configured, the secured container will present the signer an OTP verification page, and in parallel will send the SMS with OTP to the specified cell number.

  15. The signer enters the OTP received via SMS.

  16. The secured container sends the OTP to WT for validation.

  17. WT validates the OTP and sends the result to the secured container.

  18. The secured container will respond to the signer with an outcome page.

  19. The container concludes the signing session.

  20. The container updates the signature interaction with all the data needed to build the forensic layer, besides the signature specific data.

  21. If configured, the outcome page may redirect the signer to a company outcome page.

  22. The company will respond with its outcome page.

  23. Asynchronously, WT will perform the finalisation of the interaction by applying the signatures to the PDF and by creating the Forensic Audit Trail that will accompany the signature.