Deutsch
English
What is relevant for the evaluation of a digital signature solution? The user interface? The ease of use? Or individual functions?
For IT decision-makers and those responsible for security, it is particularly important to consider the hidden risks of electronic signatures – and therefore the architecture model of the individual solution: Is a document processed in plain text on the server side or is it processed locally in the customer’s controlled environment? This is precisely where Zero Document Knowledge (ZDK for short) comes in.
What “zero document knowledge” means in a digital signature solution
Zero Document Knowledge is an architectural principle in which no server-side processing or storage of document content in plain text is envisaged.
Instead, local document processing takes centre stage. The document remains in the customer’s possession, the architecture model does not provide for the transfer of readable content to the cloud and server access is not technically required. This means that the document content remains within the customer’s controlled environment.
Zero-document knowledge workflow: technical functionality
A zero-document-knowledge workflow for digital signatures is based on client-side encryption. This means that the document is processed locally and a cryptographic hash – a kind of digital fingerprint of the document – rather than the document itself is transmitted to the server for the signature process. This allows the provider to complete the signature process without receiving the document content in plain text.
In simple terms, the process works like this:
- The document is processed locally in the customer’s controlled environment.
- The Certifaction client calculates a cryptographic hash of the document and only sends this to the API.
- The signature process works via hash and cryptography mechanisms.
- The architecture model does not provide for server-side access to document content – not even by admins or operators.
- The signature remains verifiable, the process remains traceable.
Client-side vs. server-side processing in direct comparison
For architecture discussions in the context of “digital signatures“, a clear comparison of the two models “server-side” and “customer-side” is helpful:
| Architectural question | Server-side processing | Client-side model (ZDK) |
|---|---|---|
| Place of processing | On servers of the provider | Locally in the customer’s environment |
| Plain text transmission to the cloud | Possible or planned | Not planned |
| Visibility of the content | Potentially possible | Not provided for in the architecture model. |
| Access by admins/operators | Depending on the operating model | Not provided for in the architecture model |
| Signature process | Can include server-side document processing | Works without server-side plain text access |
This distinction is essential for security reviews. This is because two solutions can have a similar effect on the user, but differ significantly in terms of the security model.
Why server-side plain text access is not technically required for a legally valid signature
Secure digital signatures are generated with legal validity even if the document processing takes place locally in the customer’s controlled environment and the provider cannot access the document content.
The key point is the technical separation between the signature process and the document content. In a zero document knowledge model, the complete document is not processed in readable plain text, but the signature process is enabled via hash and cryptography mechanisms. This means that server-side access to the content of the document is not technically required to execute a signature.
At the same time, the categorisation from a compliance and governance perspective remains clear: auditability and signature levels are retained. The signature is verifiable and the process can be traced, even if document content is not read out in plain text on the server side.
What evaluation questions can be derived for security and IT teams?
This checklist is particularly relevant for the technical evaluation in the area of security and IT:
| Test field | Key question |
|---|---|
| Processing location | Local or server-side? |
| Plain text transmission | Intended or not? |
| Access chain | Who could see content? |
| Architectural model | Is server-side access technically necessary? |
| Audit capability | Do the signature and process remain traceable? |
Significance for the selection of a digital signature solution
When selecting a digital signature solution, architecture, data flow and access points should be prioritised over pure feature lists or the nature of the interfaces. This is especially true if the solution is to be integrated into existing IAM and security environments.
The categorisation of a white label solution is also relevant at this point. For technical decision-makers, white labelling is not primarily a branding issue, but a possible deployment model that must be considered in integration discussions. If a signature solution is embedded as a white label component in an existing customer portal, a specialist application or an internal platform, the technical categorisation becomes even more important. Then it is not just about user guidance or visual integration, but also about the question of how the security model of the signature solution fits into the existing architecture.
In such scenarios in particular, a transparent answer must be given as to where documents are processed, which systems are integrated into the data flow and whether additional server-side access points are created. Even in a white label scenario, the central evaluation question therefore remains unchanged: Is document processing carried out locally in the customer’s controlled environment or is the complete document transferred to the server and read out there?
Conclusion: Architecture before surface
Zero Document Knowledge reveals what actually characterises a digital signature solution: its architecture model. When documents are processed locally, server-side access is not provided and the signature process does not require plain text processing, a security model is created that clearly distinguishes itself from standard solutions.
For IT decision-makers and those responsible for security, this is a reliable criterion for security reviews, vendor selection and architecture evaluation.
Would you like to delve deeper into the topic of “secure digital signatures”? Use our Privacy-First Whitepaper!
