Webpage Forensic API

This solution offers an alternative to the "Document" ones that allows a company to create interactions to apply click-to-sign electronic signatures. In this case the company may want to sign a contract or policy, but in this case they won’t be within a PDF document but inside a web page.

Integrating this solution requires a little bit more effort since the signature interaction takes place inside a web page that must be rendered by the company before being presented to the signer.

Let's take into account the following initial scenario:

This diagram shows a fairly common use case where a user interacts with a server-side rendered web page.

  1. The user opens a URL pointing to a web page of the company;

  2. The web page is then rendered at the server and served to the user;

  3. At this point the user interacts with the web page (e.g. fills a form) and finally submits an action to the server at the company;

  4. The server sends back a response to the user regarding the submitted action.

However, assume that the company wants to present on that web page a contract that needs to be signed with at least a Simple Electronic Signature (SES). The Webpage Forensic API allows the company to produce an SES with forensic probative value using proprietary and patented methodology that creates a forensic layer following the standard ISO/IEC 27037:2012, all of this without disrupting the company’s user experience. Therefore, for the signer, it would be like nothing changed, but the company will have a strong signature that could be used irrefutably to prove that the interaction took place in case of litigation. The following diagram shows, at a certain level of abstraction, how the interaction takes place once WT is integrated within the company's process.

  1. The user opens a URL pointing to a web page of the company.

  2. The company's web server, instead of responding right away, will create a new interaction using the WT endpoint createInteraction with the property variation set to full (the default value). The interaction object will contain a pre-rendered HTML page (the very same page that the company would have sent directly to the user) along with the URL where the company intends to handle the user's action (O-URL).

    The user's action must be sent to the WT gateway before reaching its final destination. Therefore, the company needs to specify O-URL as a parameter while creating a new interaction. For the same reason, the company must replace O-URL within the pre-rendered HTML with the placeholder <%= e_url %>.

    For instance, if the user's action is the submission of a form and O-URL is http://company_webserver.com/submit the company has to:

    • Replace <form action="http://company_webserver.com/submit" method="post"> with <form action="<%= e_url %>" method="post"> inside the pre-rendered HTML the company will provide to WT,

    • Specify http://company_webserver.com/submit as the parameter O-URL and full as the parameter variation. More details on these parameters can be found in the create interaction [operation/createInteraction] section.

  3. WT initialises the new interaction object. This object will represent the interaction that should take place between the user and the company's Web Server.

  4. The WT gateway will return such an interaction object to the caller. The returned object contains the ID of the newly created interaction and the forwarding URL (F-URL) to which the company's Web Server must redirect the user.

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

  6. The user's browser reaches the F-URL endpoint in the WT gateway. This endpoint does not contain the actual page.

  7. The WT gateway requests the corresponding interaction for the effective URL (E-URL) where the page will be served.

  8. Under the hood, the previous step will indicate to our system to initialise an isolated, secured container to serve the effective page. The container will immediately start a forensic acquisition session.

  9. The E-URL is returned to the WT gateway.

  10. The WT gateway will respond to the user's request in step 6 with an HTTP redirection to E-URL.

  11. The user's browser visits the E-URL served from the secured container.

  12. The secured container responds with the page. Note: This page is built using the pre-rendered HTML, replacing the placeholder using a URL served from the secured container.

  13. The user interacts with the page (e.g., fills out a form) and finally submits an action (e.g., submits the form).

  14. This submission will go directly to the secured container, and an HTTP redirection (of the submitted action) to O-URL will be sent back to the user's browser.

  15. The secured container will conclude the acquisition session started in step 8.

  16. The corresponding interaction will be updated accordingly, reflecting the acquisition status and all the gathered data.

  17. Due to the redirection in step 14, the user's browser will resubmit the action to O-URL, served by the company.

  18. The company's Web Server sends a proper response to the user.

This extended process proposed by WT is an expansion of the normal interaction that would have taken place between the user and the company. Note that those are steps 1, 12, 17, and 18 of the previous diagram.