DS06 — eIDAS fundamentals: simple, advanced, qualified eS

Trigger S3

An external contracting party (placeholder PARTNER-1) demands a "DocuSign signature" for a project/purchase contract. E1 clarifies: Which level does the contract really require — and what does "advanced" mean exactly?

The three levels

Simple electronic signature (eS)

eIDAS Art. 3 Nr. 10: "Data in electronic form which is attached to other data in electronic form or logically associated with them and which authenticates the signatory."

This is the broadest category — a scanned image of the signature, a typed name above the email, a click on "Accept". The GitCover text-form chain from Part I (signature doc + events + Facsimile reference) is a simple eS with good evidentiary value — because it documents the chain of evidence without gaps.

Evidentiary force: Freely assessable as evidence (§ 286 ZPO); no statutory presumption. The value lies in the chain, not in any single feature.

Advanced electronic signature (FES/ADES)

eIDAS Art. 3 Nr. 11: "Advanced electronic signatures" must: (a) be uniquely attributed to the signatory, (b) allow any change to the data after signing to be detected, (c) be linked to the signatory in such a way that it is under the signatory's control, (d) allow any subsequent change to the accompanying data to be detected.

Technically, this is usually implemented with AdES (Advanced Electronic Signature, PAdES for PDF, XAdES for XML, CAdES for generic data): a cryptographic method (RSA/ECDSA) over a hash of the document, bound to a certificate. DocuSign generates such signatures (with its own certification stack); so do in-house tools (e.g., PDF crypto software).

Evidentiary force: eIDAS Art. 25 (2) — the FES is equivalent to a simple handwritten signature where the provision does not require a specific form (§ 126 Abs. 3 BGB).

Qualified electronic signature (QES)

eIDAS Art. 3 Nr. 12, Art. 25 Abs. 2: FES with a qualified certificate from a qualified trust service provider listed on the EU Trust List. § 126a BGB: The QES is equivalent to the written form.

The QES is the only level that automatically replaces the statutory written form. It requires identity verification to a high standard (video identification, eID), hardware tokens, or comparable integrations — always external, via Trust List providers.

Evidentiary force: Formal presumption of authenticity and integrity (§ 371a ZPO, 2. Alt.). No Git-native path — only docking (Part II).

Comparison table

What "advanced" means concretely

The four FES criteria in GitCover translation:

The crypto binding (the actual PAdES part) comes in DS08 — there, the Facsimile graphic is positioned in a PDF layer and provided with a signature plate (certificate, hash, timestamp).

Where the text-form chain remains

The same applies to FES procedures: the signature doc and the event chain from Part I remain. They document the process in the repo; the signed PDF (FES output) is an additional artifact. The chain is extended, not replaced:

Textform-Kette (Teil I)
   Quell-Dokument + Signatur-Doc + Events + Facsimile-Verweis
        │  erweitert um
        ▼
FES-Verfahren (Teil II)
   FES-Dienst ──► signiertes PDF (PAdES) ──► Envelope-Report
        │                                  │
        └── physisch im Container-Paket ───┘

Summary

• eS = broad category; the GitCover text-form chain is a simple eS with good evidentiary force (chain).
• FES/ADES requires crypto binding + certificate; the four criteria are mapped in GitCover artifacts.
• QES replaces written form; only achievable externally (Trust List).
• Next article (DS07): the Facsimile procedure — the positioned graphic in the PDF layer.

---

Created: 260913 | Part II, article DS06 | Series: digital-signage