webSignatureOffice Hosting on Premise - Service Description (English)

Last updated 14/08/2024 - Version 1.0

Description of services


(1) Standard software


The webSignatureOffice application is provided as a standard software version without any customisations as a Docker image. The features are defined in the contract.

(2) Type and scope of services

The webSignatureOffice application is provided to the client with full functionality. The application is operated entirely by the client.

The software enables the client to capture handwritten and certificate-based advanced and qualified electronic signatures and embed them in PDF/A-compliant documents. The biometric data of the handwritten signatures captured by webSignatureOffice are encrypted using secure hybrid encryption (RSA encryption in combination with AES) and linked to the document checksum – and thus to the document to be signed.

When using StepOver signature pads, this encryption and linking is done directly in the signature pad itself. When using the Android and iOS StepOver apps, it is done on the respective end device and when using the HTML signer, it is done on the webSignatureOffice server.

(3) Functions

Biometric-based signatures

For electronic signatures based on handwriting, the biometric data of the handwriting is used as an identifier of the signatories. It is captured by a signature capture device, encrypted with a notarial key, inseparably linked to the document and inserted into it.

The data can be captured:

  • via browser (tablet, smart device, StepOver signature pad*) (advanced and qualified electronic signature)

  • using native apps/applications (iOS, Android, eSignatureOffice) (only advanced electronic signature)

*the use of signature pads requires the local ‘StepOver Pad Connector’ (a programme that runs on Windows/MacOS/Linux, which addresses the signature pad via USB and makes it accessible to the website in the web browser via a local socket).

 

Click signatures

A click signature is a certificate-based signature (advanced or qualified) that is provided merely by clicking and, if necessary, entering a password (not handwritten).

 

Available two-factor authentications:

  • SMS one-time token

  • document or envelope password

The two-factor authentications can be used for both handwritten and certificate-based signatures.

 

Audit Trails

Audit trails are created for each document and can be downloaded. The audit trails contain the following information:

  • upload time; shows when and by which user the document was uploaded

  • sent; shows to which email addresses or mobile phone numbers the signature request was sent

  • opened; shows when which user opened the document (each opening time is recorded)

  • Download; shows when which user downloaded the document (each download is recorded)

  • Upload; shows when which user uploaded a file (each upload is recorded)

  • Document protection; if a two-factor authentication was set up for accessing the document (document password or SMS token entry), this is also logged

  • Signature type; indicates how a signature field has been signed. Signature pad, QR code scan, directly on the screen, click signature with user certificate

  • Form field value; indicates which user has filled in which form fields and how (e.g. user XY has ticked the ‘Additional option 1’ checkbox)

  • Signature time (UTC) / location (GPS coordinates)

  • Tenant ID / server name; indicates which webSignatureOffice server the corresponding document comes from

 

Envelope

Combines several documents to be signed in a signature request. Here, the order as well as a download condition of the documents can be defined.

 

Signer order

Optionally, an order of the signers can be specified.

 

Signature groups

Signature groups are used exclusively when webSignatureOffice is used integratively via the server-side API. They are used to distinguish between signatories (e.g. requesters and guest signatories) when used with only one technical user.

 

Qualified electronic signature (QES according to eIDAS)

The electronic signature with the highest security standard that meets the requirements of the eIDAS regulation.

 

Filling in PDF form fields

The form fields must be part of the PDF. Form fields can only be edited up to the first signature.

 

Email customising

Email templates can be customised.

 

Capturing signatures via QR code

A QR code is generated, which can be scanned with a smartphone/tablet. You are taken directly to the document and can then sign it on the mobile device.

 

Signatories without prior registration

webSignatureOffice offers the possibility to sign documents without having to register. These are then so-called guest signers. The document link is sent to the guest signer by email or SMS, who can access the document to be signed directly without registration or login and sign it.

 

Call-back API

A callback URL can be stored as a server setting. A request is sent to this URL when certain actions are performed. These include uploading a document, signing a signature field, changing the status of a document, or signing all fields of a user. The callback URL can also be set for specific documents when using the TyrService.

 

iFrame Post Message

If the viewer is embedded as an iFrame, notifications are sent to the surrounding website when certain actions are performed. It is then possible to react to these dynamically. Notifications are sent when all of a user's signatures have been executed, all of the document's signatures have been executed, or the viewer has been exited.

 

Optional and required

webSignatureOffice allows you to define optional and mandatory signature fields. Optional fields can be skipped at will and do not necessarily have to be signed to complete the process.

 

Offline

documents can be synchronised in the apps, so that they can be selected from a list, displayed and signed later and, if necessary, without an online connection. After signing, a new online connection must be established so that the signed documents from the app can be synchronised with the server.

 

Apps

  • iOS

  • Android

  • App integration using libraries

Libraries for iOS and Android enable the integration of the native StepOver apps into your own apps.

(4) System architecture

For integration purposes, webSignatureOffice provides a server-side API (so-called Tyrservice = XML-RPC interface and JSON-RPC), which can be used to upload documents, generate signature requests, and download and delete signed documents.

Optionally, user accounts can also be managed via this API (create, delete, etc.).

WebSignatureOffice is a horizontally scalable web server solution consisting of a frontend web server (Frigg) and a backend server (Braga), which can be located in a DMZ and is responsible for rendering the documents, applying signatures and data management.

In addition, a database server is required (MariaDB). Documents are stored either in a file share or in the database.

(5) Minimum server requirements

System requirements for frontend and backend servers:

Hardware

  • at least quad-core 2.5 GHz and 16 GB RAM

  • 100 GB hard drive

Software

  • Windows or Unix systems

  • MariaDB 10.5 or higher

  • Docker Engine Version 20.10 or higher

  • Docker Compose Version 1.19 or higher

(6) Additional software components

  • Pad Connector – A locally installed driver that enables communication between the browser and the StepOver signature pad.

  • Print2Cloud – Printer driver to convert selected file formats into PDF/a

  • aSignatureOffice – Android app for capturing biometric signature data

  • iSignatureOffice – iOS app for capturing biometric signature data

(7) Provision of test systems


Test servers can be used for various purposes, depending on the required configuration.

For functional tests, for the testing of extensions, new functions and for the integration, as well as for the testing of updates / new versions in the course of a release by the client, a tenant can be provided on a webSignatureOffice test server operated on the business premises of StepOver GmbH.

The server may be operated as VM-Ware on hardware used for other purposes and is not representative of the infrastructure planned for the productive phase in terms of performance. These test servers are not suitable for carrying out representative load tests.