# Execute a document signature process

# Alias

`SignerProcessExecution`

# Description

Executes a document signature process created previously.

Important

If the document signature process was created without some or any parameters (i.e., without specifying the `signer.parameters` property or one of its optional subordinate properties in the "`process`" of the request), the document's signature is performed as explained in Behavior When All or Some of the Signature Definition Parameters Are Missing of the obtain the hash of a document in accordance with a signature definition operation.

# Request

The execution of the signature process of a document is ordered by sending a redirect response to the browser with which the user requested the signature. The URL to which the browser is redirected must be extracted from the JSON representation of the signature process to be executed. This representation is found in the body of the response received when the operation for creating the signature process is executed. Specifically, the redirect URL is extracted from the `url` field of the only element currently contained in the `tasks.pending` array of a recently created signature process (an element whose `type` is always `UserBrowserTask`).

`HTTP/1.1 302 Found`
`Location: <userbrowser_task_url>`

## Parameters

Name | Type | Usage | Description
`user_browser_task_url` | header | Required | URL the user's browser must access to execute the signature process on a document. The application will have obtained this URL in the response received from TRIDENT (eSignSP) when the document signature process was created.

## Authorization

During the execution of the signature process, TRIDENT authenticates the user and obtains their authorization via OAuth 2.0 on two occasions:

- Firstly, so the document signature service can query the user's signing identities to select one.

- Secondly, so that the document signature service can request that the document be signed with the selected signing identity.

A typical authentication and authorization configuration of the TRIDENT server would provide a user experience as follows:

- The first authentication can be skipped via SSO if the user already has a session open in TRIDENT (the user may have logged in to start a session in the application). Furthermore, the authorization may be implicit in the authentication.

- The second authentication may be skipped via SSO when a signing identity in a mobile device is used (if the user has a session open in TRIDENT) because the Mobile ID application already requires that the user enters their PIN before generating the signature. However, the second authentication cannot be skipped when a server signing identity is being used. In either of these two cases (mobile or server signing identity), the subsequent authorization may be implicit in the authentication.

In general, as well as authenticating the user and obtaining their authorization for querying the signing identities and signing the document, the user is also asked to acknowledge that they have read the document before signing. When a signing identity on the server is used, obtaining this acknowledgment can be omitted if this is specified when the signature process is created (the `views.document_agreement.skip_server_id` parameter). This typically occurs when the client application obtains the acknowledgment by its own means prior to requesting document signing from TRIDENT.

# Response

If the signature process is executed successfully, the client application receives an `HTTP-GET` message from the browser at the callback URL specified when the process was created. Specifically, in the URL entered in the `finished_callback_url` field of the request body (`process` part) via which the signature process was created.

`GET <finish_callback_url_path>?status=finished&signer_process_id=<signer_process_id>`
`Host: <finish_callback_url_host>`

Where `<signer_process_id>` is the identifier of the signature process, `<finish_callback_url_host><finish_callback_url_path>` is the callback URL specified in the `finish_callback_url` field of the request used to create the signature process and status is a parameter that indicates the result of this process by one of the following values:

- `finished`: The process finished and the document was successfully signed.

- `failed`: The process finished, but the document was not signed because an error occurred.

- `canceled`: The process finished because its execution was canceled. As a result, the document was not signed.