Document Advanced API

This solution allows us to create and manage Advanced Electronic Signatures (AES). The canonical use case for this solution is a company that wants contracts to be signed electronically and needs the signature to be AES (i.e., it needs recognition of the signer, PAdES signatures applied to the document, and legally compliant archiving of the signed documents + the audit trail of the signature).

To create an AES, first we need to create the AES provider. The AES provider is the subject that will dispense the signatures. For instance, we could have the following scenario:

A Company uses our API to create signature interactions between a Provider and a Signer. Note that the Company and the Provider could be the same subject. Before creating an AES signature interaction, the company must register at least one provider (it could be the company itself) using the API aesProviders. Once the provider has been registered, the company may create signatures between that provider and signers using the API aesSignatures.

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 and the provider has been registered.

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 for a certain provider.

  2. The company creates a signature for the provider createAesSignature, as can be seen for the AES signature creation, the provider is part of the endpoint.

  3. WT initializes 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 redirect toF-URL .

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

  7. WT responds to the signer with another redirect, this time to the SPID authentication page.

  8. The signer will then proceed to authenticate in SPID.

  9. SPID will redirect the signer again to the F-URL, but this time there is a SPID authentication token.

  10. The signer’s browser will visit the F-URL with the SPID token set.

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

  12. The E-URL is returned to WT.

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

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

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

  16. 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.

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

  18. The container concludes the signing session.

  19. If configured, the outcome page, already rendered in the signer’s browser, may redirect the signer to a company’s page.

  20. The company responds with its outcome page.

  21. Asynchronously, WT will perform the finalization of the interaction by applying the PAdES signatures to the PDF and by creating the Audit Trail that will accompany the signature.