Kavra Siegel live — qualifizierte eIDAS-Zeitstempel über SIGNIUS und IDnow

Am 29. Mai 2026 hat Kavra Siegel den ersten qualifizierten eIDAS-Zeitstempel produziert. Über die SIGNIUS-API, mit IDnow Trust Services AB (Schweden, auf der EU Trusted List) als Backend-QTSP. Drei Tage später ist die Integration über vier Produkt-Schichten in PR durchgelaufen: Compliance-Zertifikate im Cockpit, AI-Act-FRIA-Dokumente, NIS2-Incident-Reports, Policy-Approvals. Vom Erstgespräch zur Live-Integration waren es zehn Tage.

Dieser Post dokumentiert die Schritte, die Debug-Reise und was das für unsere Position zum EU AI Act bedeutet.

Warum qualifizierte Zeitstempel?

Ein qualifizierter elektronischer Zeitstempel nach eIDAS Verordnung (EU) 910/2014 Artikel 42 ist nicht einfach ein Datumsstempel. Er ist ein Beweismittel mit gesetzlicher Vermutung der Richtigkeit, in allen 27 EU-Mitgliedstaaten ohne Sachverständigen-Gutachten vor Gericht verwendbar. Er wird von einem Qualifizierten Trust Service Provider (QTSP) ausgestellt, der von einer nationalen Aufsichtsbehörde geprüft und auf der EU Trusted List geführt wird.

Für Workflow Provenance — den Ansatz, dass nicht einzelne KI-Outputs, sondern ganze Workflows kryptografisch verankerbar sein müssen — ist das genau der Anker, den es braucht: nicht-bestreitbar, gerichtsfest, europaweit anerkannt. Ohne qualifizierten Anker bleibt eine Provenance-Aussage eine Selbstauskunft. Mit qualifiziertem Anker wird sie ein Beweis.

Bis zum 29. Mai war Kavra Siegel ein technisch sauber gebautes Mock-System. Die Architektur stand, die Endpoints stempelten, das Trust-Portal erzeugte PDFs — aber jeder Stempel trug intern den Hinweis „Mock“. Mit dem SIGNIUS-Live-Switch wird aus „Mock“ ein echter Status: Granted mit qcStatements im TSA-Zertifikat.

Die Timeline — zehn Tage

Die Debug-Reise — 401, 400, 403, 200

Der Smoke-Test gegen die SIGNIUS-API war eine Lektion in Doku-vs-Realität-Diskrepanzen. Der erste curl-Versuch endete mit 401 Unauthorized. Der zweite mit 400 Bad Request. Der dritte mit 403 Forbidden. Erst der vierte war 200 OK. Drei Themen mussten überbrückt werden:

1. Authentifizierung: Basic Auth statt API-KEY-Header

Die offizielle Doku auf docs.signius.eu und die Swagger-JSON-Spezifikation dokumentieren einen API-KEY-Header als Authentifizierungs-Mechanismus. In der Praxis wird dieser Header vom Server vollständig ignoriert. Der Server antwortet konsistent mit WWW-Authenticate: Basic realm="ESYSCO.SEALSERVER" — verlangt also HTTP Basic Auth.

2. Content-Type: application/timestamp-query, nicht octet-stream

Die Doku gibt application/octet-stream als Content-Type vor und beschreibt den Body als „raw hash bytes“. Der Server akzeptiert ihn nicht. RFC 3161 definiert application/timestamp-query als korrekten MIME-Type — und genau den verlangt der Server auch.

3. Der entscheidende Knackpunkt: certReq=true

Selbst mit korrekter Authentifizierung und korrektem MIME-Type kam 403 Forbidden zurück. Die Lösung fand sich erst durch eine zusätzliche Anleitung von SIGNIUS: das certReq-Flag in der TimeStampReq muss auf true gesetzt sein — bei openssl ts -query das -cert-Flag. Ohne dieses Signal lehnt der Server die Anfrage ab. Plausible Begründung: die SIGNIUS-Policy verlangt, dass der Client explizit signalisiert, das TSA-Zertifikat in der Response anzufordern.

Was hinter SIGNIUS steckt: IDnow

Aus der DER-kodierten Response lässt sich der eigentliche QTSP herausschneiden — und das ist nicht SIGNIUS selbst. SIGNIUS ist die API-Frontend-Schicht. Im Token-Subject steht: O=IDnow Trust Services AB, organizationIdentifier=SE5594699489, CN=IDnow TS Timestamp 01. Der eigentliche eIDAS-qualifizierte Trust Service Provider ist IDnow Trust Services AB, ein etablierter schwedischer QTSP auf der EU Trusted List.

Der Audit-Pfad ist sauber: Kavra Siegel → SIGNIUS-API → IDnow QTSA → eIDAS-qualifiziert. Für unsere Kunden und für jede Aufsichtsbehörde ist das transparent überprüfbar.

Was jetzt live ist

Vier Produkt-Schichten ziehen qualifizierte Stempel über den kavra-siegel-Service:

• Trust-Portal-Compliance-Zertifikate — jedes generierte Kanzlei-Cockpit-Trust-PDF trägt einen qualifizierten Zeitstempel im Footer (Token-ID + TSA-Issuer + Issued-At) und einen QR-Code, der die Verifikations-Seite mit Token-Parameter aufruft.
• AI Act FRIA-Dokumente — bei Abschluss einer Folgenabschätzung wird der finalisierte Inhalt qualifiziert gestempelt. Annex-IV-Dokumentationspflichten erhalten damit einen unbestreitbaren Zeitanker.
• System-Klassifizierungen nach AI Act Art. 6 — wenn ein KI-System final in eine Risiko-Klasse eingestuft wird, fixiert der Stempel den Zustand zum Zeitpunkt der Entscheidung.
• NIS2-Incident-Reports — die 24-Stunden-Frühwarnung und der 72-Stunden-Detailbericht erhalten je einen separaten qualifizierten Stempel mit kanonisch serialisiertem Inhalt. Für die NIS2-Meldepflicht entsteht damit ein gerichtsfester Submission-Zeitpunkt.
• Policy-Approvals — beim Statusübergang einer Sicherheits-Richtlinie auf „approved“ wird der inhaltliche Stand qualifiziert gestempelt. Idempotent: Re-Saves einer bereits approved-Policy erzeugen keinen neuen Stempel.

Alle Hooks sind non-blocking: wenn die TSA mal nicht erreichbar ist, läuft der jeweilige Endpoint weiter und ein Backfill-Service holt fehlende Stempel später nach.

Was das für den EU AI Act bedeutet

Artikel 50 der KI-Verordnung verlangt ab August 2026, dass KI-generierte Inhalte maschinen-erkennbar markiert werden. Die EU-Kommissions-Leitlinien (Stand April 2026) fokussieren auf Einzel-Asset-Markierung — C2PA Content Credentials, SynthID-Watermarks. Für isolierte Outputs ist das ausreichend. Für agentische Workflows — in denen ein Mensch einen Auftrag erteilt und ein Agent dutzende Artefakte produziert — ist Einzel-Asset-Markierung strukturell unvollständig.

Workflow Provenance schließt diese Lücke: eine verifizierte menschliche Autorisierung initiiert einen strukturierten Workflow, alle Outputs tragen eine kryptografisch verkettete Provenienz zu einem gemeinsamen Workflow-Anker — und dieser Anker ist mit einem qualifizierten eIDAS-Zeitstempel versiegelt. Was bis Mai theoretische Position war, ist seit 1. Juni ein produktiv eingesetzter Pfad. Das Whitepaper aus unserer Konsultations-Einreichung dokumentiert die vollständige Position.

Was als Nächstes kommt

• HTTP 402 / x402-Endpoint für autonome AI-Agents — Code-Pfad ist vorbereitet, Production-Audit und Wallet-Provider-Entscheidung (Turnkey vs. Base RPC) stehen aus.
• MCP-Server-Integration — Discovery via .well-known/mcp.json ist live, Sample-Repo unter mscharfetter/kavra-siegel-mcp-example. Listings in MCP-Verzeichnissen folgen.
• Multi-TSP-Backup — A-Trust, D-Trust, GlobalSign als Resilienz-Layer. Architektur-konform über TspAdapter-Pattern.
• C2PA Manifest-Export Q4 2026, W3C PROV-Export Q1 2027.

Für Steuerkanzleien und compliance-pflichtige KMU bedeutet das: ab heute ist jedes Compliance-Zertifikat aus dem Kanzlei-Cockpit eIDAS-qualifiziert versiegelt — ohne dass die Kanzlei sich um TSP-Verträge, Schlüssel-Management oder Zertifikats-Validierung kümmern muss. Der Stempel kommt automatisch.