# Architecture

### Description

The example system, presented in the diagrams, consist of two main domains: the Customer Domain and the Provider Domain. Diagrams illustrate the process by which a customer uses a business application to seal the document using services provided by **SIGNIUS** in multiple different setups. 

#### Components

* Driving/Business Application - a business application used by the customer to initiate the process of sealing documents. 
* Network folder - a path to directory where document sealing exchange is being performed. 
* **SIGNIUS Sealing Client** - client application of the sealing solution in the system, responsible for communication with the **SIGNIUS Sealing Server** (and in case of smartcard setup, also responsible for communication with card/card reader) and processing data necessary for sealing documents. 
* **SIGNIUS Sealing Server** - server application of the sealing solution in the system, responsible for communication with QSCD, QTSP and database server. 
* QSCD (Qualified Seal/Signature Creation Device) - a qualified signature creation device that ensures process security. 
* Remote QTSP (Qualified Trust Service Provider) - a remote trust service provider service that provides a qualified timestamp and validation. 
* Database server - SQL server holding process configuration. 

#### Security and communication

Communication between the **SIGNIUS Sealing Client** and the **SIGNIUS Sealing Server** and between the **SIGNIUS Sealing Server** and the QSCD/QTSP is secured using HTTPS, which ensures the confidentiality and integrity of transmitted data. The use of the HTTPS protocol and trusted components such as QTSP and QSCD guarantees a high level of security in the process of document verification and sealing. 

The system is a comprehensive solution for generating and verifying digital seals, integrating the customer's business applications with advanced cryptographic services provided by **SIGNIUS** and external partners.

### 🏛️ Hosted Setup

<figure><img src="/files/YeFalH4i1NdmR5XnxkyL" alt=""><figcaption></figcaption></figure>

#### Flow

* The customer's business application transmits data to the **SIGNIUS Sealing Server** via REST API.&#x20;
* **SIGNIUS Sealing Server** returns a document hash (DocHash) in case of single documents and in case of batches of documents returns documents package with already embedded signature/seal into them via REST API.&#x20;

### 🏛️ Hybrid Setup

<figure><img src="/files/hTuE5g0rcPbmF5BPMEkV" alt=""><figcaption></figcaption></figure>

#### Flow

* The customer's business application transmits data to the **SIGNIUS Sealing Client** via REST API or using preconfigured filesystem directory (whether it is network or local folder).&#x20;
* **SIGNIUS Sealing Client** requests document sealing with integrated **SIGNIUS Sealing Server** using REST API.&#x20;
* **SIGNIUS Sealing Server** assembles signature/seal and raw document into a document with embedded signature/seal (sealed document).&#x20;
* **SIGNIUS Sealing Server** returns to **SIGNIUS Sealing Client** with already embedded signature/seal into document using REST API.&#x20;
* **SIGNIUS Sealing Client** provides sealed document to customer's business application using exchange method which began the whole process (FILESYSTEM or REST).

### 🏛️ On-premise Setup

<figure><img src="/files/LFtQH4tyfzaLVBwdjFgj" alt=""><figcaption></figcaption></figure>

#### Flow

* **On-Premise** setup combines all possible flows of both **Hosted** and **Hybrid** setups but entirely within the customer domain. With correct configuration of the environment there is almost no need for any connection to move outside the bounds of organization's network which creates highly secure system.

### 🏛️ Smartcard Setup

<figure><img src="/files/I1uoCDi6E295wBClhbaL" alt=""><figcaption></figcaption></figure>

This version of **Smartcard** setup has the same set of functions as **Hybrid** but it is a bit harder to configure and when using Smartcard instead of HSM for encryption it provides lower speed and level of protection/security.&#x20;

#### Flow

* Like in **Hybrid** setup, request for sealing document is initiated by customer's driving application and is passed to **SIGNIUS Sealing Client**
* **SIGNIUS Sealing Client** instead of passing request to **SIGNIUS Sealing Server**, uses certificate located on smartcard (available on the machine with **SIGNIUS Sealing Client** via card reader) to assemble signature/seal (from this certificate) and raw document into a document with embedded signature/seal (sealed document)
* \***SIGNIUS Sealing Client** can additionally send sealed document to **SIGNIUS Sealing Server** to add timestamp - depends on process configuration
* finally returns sealed document using exchange method which began the whole process.&#x20;

<figure><img src="/files/6hR1WLy5cRIGYVchU4rX" alt=""><figcaption></figcaption></figure>

#### Flow

* This version of **Smartcard** setup has the same set of functions as **On-Premise** but it can also use Smartcard in addition to or instead of HSM for encryption in selected processes.&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.signius.eu/manuals/signius-sealing-server-and-client/architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.