Unterschriften-Verwaltung — E-Signatur (A-2)
Bezug: A-2, R4, R9, OP-SIGN-1 · Status: Provider-Abstraktion + Niveau-Matrix gebaut (Slice 4,
0.4.0); konkreter Anbieter (DocuSign/PandaDoc-HTTP-Adapter) bleibt offen (OP-SIGN-1 Rest).
Entscheidung (A-2)
Unterschriften werden über einen Standard-E-Signatur-Dienst (DocuSign oder PandaDoc) eingeholt — kein Eigenbau (G-1). Medidentas spricht den Provider über eine Provider-Abstraktion an, sodass der Anbieter austauschbar bleibt und ein zweiter Provider (Fallback / Niveau-spezifisch) ergänzt werden kann.
eIDAS-Niveau je Dokumenttyp (zentral!)
Elektronische Signaturen haben unterschiedliche Rechtswirkung — das Niveau muss zum Dokumenttyp passen (RISK-2):
| Niveau | eIDAS | Wann | Beispiel-Dokumenttyp |
|---|---|---|---|
| SES | einfache Signatur | geringe Formanforderung | Einwilligung, Kenntnisnahme |
| AES | fortgeschritten (Identität gebunden, Änderung erkennbar) | erhöhte Beweiskraft | Standard-Verträge, Vollmachten |
| QES | qualifiziert (= eigenhändige Unterschrift, Zertifikat) | Schriftform gesetzlich gefordert | formgebundene Verträge |
CH: Schweiz nutzt ZertES (nicht eIDAS); QES-Äquivalent ist die qualifizierte ZertES-Signatur. Niveau ist je Dokumenttyp begründet festzulegen (Compliance-Tracker §3).
Anbietervergleich (OP-SIGN-1 — Entscheidungsgrundlage)
| Kriterium | DocuSign | PandaDoc |
|---|---|---|
| Marktreife / Verbreitung | sehr hoch | hoch |
| eIDAS QES/AES | ja (über Partner/CSP) | ja (über Partner) |
| EU-Datenresidenz | verfügbar (Region wählen) | verfügbar |
| Datenexport US | US-Konzern → Transfer prüfen (DPF/SCC) | US-Konzern → Transfer prüfen |
| Dokument-Erstellung/Templates | stark | sehr stark (CPQ/Proposals) |
| API / Webhooks | reif, breit | reif |
| Kosten | höher | tendenziell günstiger |
Empfehlung (vorläufig): Auswahl an den Pflicht-Niveaus und der Datenresidenz festmachen — wenn QES für formgebundene Verträge nötig ist, den Anbieter mit passender CSP-Anbindung und EU-Residenz wählen. Entscheidung in OP-SIGN-1 mit Begründung dokumentieren.
Provider-Abstraktion
Einheitliche Operationen der Abstraktion: envelopeErstellen(dokument, unterzeichner, niveau) ·
statusAbfragen(id) · webhookVerarbeiten(event) · signiertesDokumentAbrufen(id).
Sequenz: Unterschrift einholen
Nicht-funktional
- Idempotenz/Reconciliation: Webhook verpasst? → periodischer Status-Abgleich (RISK-6).
- Nachweis (G-4): Signatur-Zertifikat/Audit-Trail des Providers zusammen mit dem Dokument archivieren.
Umgesetzt (Slice 4, 0.4.0)
- Provider-Abstraktion
SignaturProvider(server/src/signatur/provider.ts):anfordern+status;FakeSignatur(signatur/fake.ts) für Tests/Staging. Provider-Wahl viaSIGNATUR_PROVIDER(MVP:fake). - Niveau-Matrix (
domain/signatur-niveau.ts, begründet, admin-editierbar gedacht): Vollmacht → QES, Vertrag/Auftrag → AES, Mandat/Einwilligung → SES, Default → AES. - Signatur-Dienst (
api/signatur-service.ts): anfordern (Niveau aus Matrix) · idempotenter Status-Abgleich (RISK-6) · bei Abschluss Rückablage der signierten Fassung nach NextCloud (R9) + Dokument-Statusunterschrieben(R3) + Onboarding-Itemgeprüft(R2) — „eine Wahrheit" (G-2). - D1-Tabelle
signatur_vorgang(Migration v3), Felder R4-F01..08. REST:POST /api/dokumente/:id/signatur,GET /api/mandanten/:id/signaturen,POST /api/signaturen/:id/abgleich. Ohne Provider/NextCloud →503.
Offene Punkte
- OP-SIGN-1 (Rest): konkreter Anbieter (DocuSign vs. PandaDoc) + HTTP-Adapter (Envelope-Flow, Webhooks statt Pull-Abgleich) + Datenresidenz/AVV (US-Transfer) + QES-CSP-Anbindung. Abstraktion + Niveau-Matrix stehen; der Adapter ist die Verfeinerung.