The Sovereign Stack: Weißbuch

Ein Vorschlag an die GD CONNECT (Generaldirektion Kommunikationsnetze, Inhalte und Technologien)

Einführung digitaler Grundelemente: standardisierte, interoperable und skalierbare Tools für eine schnellere, kostengünstigere und bessere digitale Wirtschaft.

Version: 1.0 Entwurf Datum: Februar 2026 Kontakt: richard@buckden.io

Zusammenfassung

Die digitale Fragmentierung kostet Europa jährlich 400 Milliarden Euro, wobei 40 % der IT-Budgets für Integrationskosten aufgewendet werden, während die Bürger durchschnittlich 100 Passwörter für inkompatible Systeme verwalten müssen, die nicht miteinander kommunizieren. Die digitale Identitätsbörse der EU wird im Dezember 2026 eingeführt, aber ohne die zugrunde liegende Fragmentierung unserer digitalen Infrastruktur anzugehen, werden wir einem bereits zersplitterten Ökosystem lediglich eine weitere Ebene hinzufügen. Der Sovereign Stack schlägt eine radikale Vereinfachung vor: die Einrichtung gemeinsamer digitaler Primitive, standardisierter, interoperabler Bausteine für Identität, Daten, APIs und Dienste, die es Europa ermöglichen, einmalig zu entwickeln und überall einzusetzen, wodurch digitale Verschwendung in digitalen Wohlstand umgewandelt wird.

Dieses Whitepaper skizziert die Gründe, den technischen Rahmen, das Governance-Modell und ein konkretes Pilotprogramm: den Aufbau des Sovereign Stack durch die Verbesserung eines realen lokalen Dienstes in Zusammenarbeit mit einer lokalen Behörde, einem Partner aus der Privatwirtschaft und einer akademischen Einrichtung, wobei FrankMail, ein souveräner E-Mail-Dienst für Bürger, als erste Folgeanwendung dient.

Inhalt

1. WARUM: Begründung und Grundsätze
2. WAS: Der technologische Rahmen
3. WIE: Governance, Finanzierung und Zertifizierung
4. WO: Das Pilotprojekt
5. Anhänge

1. WARUM: Begründung und Grundsätze

1.1 Von der Jugend zum Erwachsenenalter

Europa und die größere Gemeinschaft von Nationen, die offene Werte teilen, haben dazu beigetragen, die Welt von den Anfängen der digitalen Revolution in ihre Jugend zu führen. Von der Paketvermittlung (Davies, Großbritannien) über Smartcards (Moreno, Frankreich), das World Wide Web (Berners-Lee, CERN), Linux (Torvalds, Finnland) und GSM-Mobilfunkstandards (ETSI, Frankreich) bis hin zu MP3 (Fraunhofer, Deutschland) und die kontinuierliche Weiterentwicklung von JavaScript durch ECMA (Genf) hat Europa grundlegende Technologien bereitgestellt, die Millionen von Menschen miteinander verbunden, Informationen zugänglicher denn je gemacht und dabei neue Märkte geschaffen haben.

Doch Jugend ist nicht gleichbedeutend mit Erwachsensein. Die digitale Wirtschaft ist punktuell gewachsen, wobei sich die Kapazitäten auf zu wenige Orte konzentrieren und es keinen gemeinsamen Rahmen für die Interoperabilität ihrer Kernkomponenten gibt. Dieser Mangel an Koordination, der durch Fragmentierung und sich ständig ändernde Standards noch verstärkt wird, führt zu Verschwendung, verlangsamt Innovationen und hindert uns daran, das volle Effizienz- und Wachstumspotenzial der Technologie auszuschöpfen.

Für Bürger und Unternehmen sind die Auswirkungen offensichtlich:

• Der Albtraum der Passwörter mit endlosen Anmeldungen und Zurücksetzungen untergräbt die Sicherheit und Produktivität.
• Der ständige Strom von Spam-E-Mails verschwendet Zeit und Ressourcen, trotz jahrzehntelanger Gegenmaßnahmen.
• Die Frustration über inkompatible Plattformen zwingt die Menschen dazu, mit Systemen zu jonglieren, die eigentlich einfach zusammenarbeiten sollten.

Für Entwickler und Anbieter sind die Herausforderungen ebenso real:

• Wechselkosten machen jede Migration oder Integration unverhältnismäßig komplex.
• Wechselnde Frameworks sorgen für ständige Unruhe und zwingen zu kostspieligen Neuprogrammierungen anstelle von nachhaltigen Innovationen.
• Fragmentierte Fähigkeiten und zu viele digitale Dialekte führen zu inkompatiblen Stacks und verstreutem Fachwissen.

Das Ergebnis sind geringere Qualität, reduzierte Effizienz und höhere Kosten auf breiter Front.

1.2 Chancen

1. Verschwendung und Doppelarbeit vermeiden – Interoperable Standards ersetzen wiederholte Anmeldungen, APIs und Formate und beseitigen so Ineffizienzen an der Wurzel.
2. Qualität und Ausfallsicherheit verbessern – Vereinfachte Stacks und gemeinsame Kompetenzen reduzieren Fehler, Ausfallzeiten und fragmentierte Benutzererfahrungen.
3. Talente wieder auf Innovation ausrichten – Entwickler von Wechselkosten und Framework-Fluktuation befreien, damit sie entwickeln können, statt nur zu patchen.
4. KI als alltäglichen Assistenten skalieren – Offene KI-Konnektoren unterstützen Codierung, Analyse und Dienste und machen fortschrittliche Funktionen zur Routine.
5. Steigern Sie die Wettbewerbsfähigkeit – Senken Sie die Hürden für KMUs und reduzieren Sie die Integrationskosten, während Sie etablierte Unternehmen unter gesundem Druck halten.
6. Optimieren Sie Regierungs- und Unternehmensdienstleistungen – Interoperabilität vom ersten Tag an senkt Kosten, reduziert Doppelarbeit und beschleunigt die Bereitstellung.

1.3 Fünf Leitprinzipien

1. Souveränität der Bürger – Benutzer sind Eigentümer ihrer Identität und Daten. Keine Bindung, keine Überwachung, kein Verkauf von Aufmerksamkeit.
2. Interoperabilität als Standard – Dienste, Daten und Identitäten funktionieren über Anbieter, Sektoren und Grenzen hinweg; keine benutzerdefinierte Integration erforderlich.
3. KI-fähige Architektur – Maschinenlesbare Spezifikationen, standardisierte Muster und umfassende Testabdeckung ermöglichen eine schnelle KI-gestützte Entwicklung.
4. Offene Standards, offener Wettbewerb – Transparente Technologie auf Augenhöhe, die Hindernisse für KMU abbaut und gleichzeitig etablierte Unternehmen unter gesundem Druck hält.
5. Einmal erstellen, überall einsetzen – Gemeinsame digitale Grundelemente für Identität, Daten, APIs und Dienste. Jedes Projekt beginnt auf einer funktionierenden Grundlage und nicht bei Null.

1.4 Warum jetzt

Die Argumente für The Sovereign Stack sind nicht abstrakt, sondern wirtschaftlich, dringlich und messbar.

Die meisten Komponenten existieren bereits in offener Form. Die Herausforderung liegt in der Integration, nicht in der Erfindung. Ohne Koordination steigen die Kosten der Fragmentierung jedoch exponentiell, da immer mehr Bürger online gehen und immer mehr Dienste digitalisiert werden.

Die Fakten:

• 20–40 % der IT-Budgets werden für technische Schulden und Nacharbeiten aufgewendet, Projekte werden durch inkompatible Frameworks, doppelte APIs und unterschiedliche Fähigkeiten verlangsamt (Gartner, 2022).
• **40–50 % des technischen Aufwands entfallen auf Integration und Nacharbeiten*anstatt auf die Schaffung neuer Werte (McKinsey, 2020).
• Die weltweiten IT-Ausgaben werden bis 2025 5 Billionen US-Dollar übersteigen, was bedeutet, dass jährlich Hunderte von Milliarden Euro durch Doppelarbeit verschwendet werden (IDC, 2023).
• Jährliche Verluste in Höhe von 55 Milliarden Euro durch Cyberkriminalität, die größtenteils mit fragmentierten Identitäts- und Zugangssystemen zusammenhängen (Europäische Kommission, 2020).
• 150 bis 200 US-Dollar pro Mitarbeiter und Jahr werden allein für die Passwortverwaltung verschwendet (Ponemon Institute, 2021).
• 40 % der Verzögerungen bei der digitalen Transformation sind auf Herausforderungen im Bereich Identität und Authentifizierung zurückzuführen (UK Cabinet Office, 2022).
• 400 Milliarden Euro jährliche Opportunitätskosten entstehen, wenn Europa es nicht schafft, die digitale Adoption und Souveränität zu skalieren (EU Digital Compass, 2021).

Die Situation ist vergleichbar mit einem Verkehrssystem ohne gemeinsame Regeln. Heutzutage ähneln digitale Dienste Straßen mit unterschiedlichen Breiten, Beschilderungen und Verkehrsregeln: Sie funktionieren lokal, versagen jedoch in großem Maßstab. Gemeinsame „Autobahnregeln“, offene, standardisierte und interoperable Bausteine, ermöglichen es allen, schneller, sicherer und kostengünstiger zu fahren.

Wir zahlen einen hohen Preis für Ineffizienz. Bürger sehen sich mit Reibungsverlusten konfrontiert, Unternehmen verschwenden Ressourcen und Regierungen verlieren an Effizienz. Die Technologie und die Werkzeuge sind bereits vorhanden; was fehlt, sind gemeinsame Grundlagen und Koordination. Der Sovereign Stack bietet diesen Rahmen.

1.5 Das Problem-Treiber-Framework

Warum jede Schicht eine Intervention im Sovereign Stack erfordert

Identität und Zugang

• Problem: Über 100 Passwörter pro Bürger, 55 Milliarden Euro jährliche Verluste durch Cyberkriminalität, 40 % Verzögerungen bei der digitalen Transformation. Föderierte Identität, kontrolliert von 3–4 Technologiegiganten, die Pseudomonopole schaffen
• Warum standardisieren: Das Oligopol der Identitätsanbieter aufbrechen, echten Wettbewerb ermöglichen, verhindern, dass ein einzelner Anbieter zum Tor für alle Dienste wird
• Lösung: Obligatorische Interoperabilität zwischen ALLEN Identitätsanbietern, einschließlich staatlicher und privater Optionen (OAuth 2.0 + OIDC)

Datenaustausch

• Problem: Daten sind in Silos eingeschlossen, keine standardmäßige Sicherheit auf Zeilenebene, Verstöße legen unnötigerweise ganze Datensätze offen, Anbieterabhängigkeit durch proprietäre Formate
• Warum standardisieren: Granulare Datenhoheit ermöglichen, bei der jeder Datensatz weiß, wer darauf zugreifen kann. Sicherheit in die Datenschicht integrieren, nicht nur in den Perimeter. Datenportabilität als Recht gewährleisten
• Lösung: Standardisierte Identitätsbindung auf Zeilenebene, standardmäßig verschlüsselte Speicherung, Zero-Trust-Datenarchitektur, obligatorische Export-/Importfunktionen

Verarbeitung/Anwendung

• Problem: 40–50 % des technischen Aufwands entfallen auf Integration/Nachbearbeitung, alle 2–3 Jahre neue Frameworks, fragmentierte Fähigkeiten über inkompatible Stacks hinweg
• Warum standardisieren: Nicht den Code selbst, sondern die Entwicklungsinfrastruktur: Anforderungsformate, Testumgebungen, Dokumentationsstandards
• Lösung: Standardisierte Entwicklungstoolchain, gemeinsame Testframeworks, KI-lesbare Spezifikationen, einheitliche Dokumentationsstandards

API/Integration

• Problem: Jeder Dienst erfindet Verbindungsmethoden neu, Wechselkosten sind unerschwinglich, unzählige benutzerdefinierte Adapter, monatelange Integrationsarbeit
• Warum standardisieren*: Reduzierung der Integrationszeit von Monaten auf Stunden, Ermöglichung von Service-Substitution, Senkung der Barrieren für die Teilnahme von KMU
• Lösung: Obligatorische OpenAPI-Spezifikationen, Standard-Fehlercodes, Versionsregeln, gemeinsame Authentifizierungsmuster

Laufzeit/Betriebssystem

• Problem: Anbieterabhängigkeit auf Infrastrukturebene, Bedenken hinsichtlich der Souveränität, unvorhersehbare Kosten, Unmöglichkeit der Migration von Workloads
• Warum standardisieren: Gewährleistung der Portabilität von Workloads, Verhinderung von Infrastrukturmonopolen, Aufrechterhaltung der digitalen Souveränität
• Lösung: Containerstandards, offene Hardwareoptionen (RISC-V), standardisierte Bereitstellungsmuster

2. WAS: Das Technologie-Framework

2.1 Digitaler Renovierungszyklus

Erwartete Lebensdauer und Änderungsgeschwindigkeit für digitale Infrastruktur-Schichten

Genauso wie Gebäude Komponenten mit unterschiedlichen Austauschzyklen haben (Fundamente halten Generationen, während Küchen alle zehn Jahre renoviert werden), erfordert die digitale Infrastruktur einen differenzierten Ansatz für das Änderungsmanagement. Dieses Modell unterscheidet vier verschiedene Lebenszyklen:

Fundament (50+ Jahre): Protokollstandards und mathematische Konstrukte

• Abstrakte Spezifikationen und Algorithmen, die unabhängig von der Implementierung existieren
• Beispiele: TCP/IP-Protokoll, HTTP-Standard, RSA-Verschlüsselung, UTF-8-Kodierung
• Hierbei handelt es sich um Ideen und Vereinbarungen, die in Dokumenten festgehalten sind, nicht um Software, die ausgeführt wird
• Änderungen erfordern einen globalen Konsens, da grundlegende Änderungen das Internet zerstören würden

Infrastruktur (15–25 Jahre): Plattformimplementierungen und Betriebssysteme

• Konkrete Softwareplattformen, die grundlegende Standards implementieren
• Beispiele: Linux-Kernel, Windows Server, PostgreSQL, Node.js-Laufzeitumgebung
• Hierbei handelt es sich um tatsächliche Software, die Sicherheitspatches, Updates und schließlich einen Austausch erfordert
• Veränderungen erfordern eine koordinierte Migrationsplanung, jedoch keine allgemeine Übereinstimmung

Funktional (7–10 Jahre): Frameworks und Geschäftslogik

• Tools und Muster für die effiziente Erstellung von Anwendungen
• Beispiele: React-Framework, Spring Boot, Microservice-Architekturen
• Gleichgewicht zwischen Stabilität für bestehende Systeme und Weiterentwicklung für neue Funktionen
• Veränderungen werden durch die Produktivität der Entwickler und die Anforderungen an die Wartbarkeit vorangetrieben

Oberfläche (3–5 Jahre): Schnittstellen und Erfahrungen

• Was Benutzer sehen und mit dem sie direkt interagieren
• Beispiele: Mobile Apps, Webschnittstellen, API-Versionen
• Schnelle Iteration basierend auf Nutzer-Feedback und sich ändernden Erwartungen
• Veränderung getrieben durch Nutzeranforderungen, Barrierefreiheitsanforderungen und Gerätefunktionen

Diese Trennung ermöglicht eine angemessene Governance und Investitionsstrategien pro Ebene, wodurch sowohl vorzeitige Veralterung als auch teure technische Schulden vermieden werden. Die wichtigste Erkenntnis: Grundlagen sind Spezifikationen, die Sie implementieren; Infrastruktur ist Software, die Sie ausführen.

2.2 Referenzarchitektur

Der Sovereign Stack ist in Schichten strukturiert, die die grundlegenden Bausteine digitaler Systeme darstellen. Jede Schicht hat eine klare Rolle, wobei offene Standards Interoperabilität, Qualität und Skalierbarkeit gewährleisten. Übergreifende Ebenen unterstützen die Produktivität, Beobachtbarkeit und das Vertrauen der Entwickler. Diese Schichtenarchitektur verhindert Doppelarbeit, stärkt den Wettbewerb und bildet die Grundlage für Innovationen.

2.3 Zusammenfassende Schichttabelle

2.4 Detaillierte Beschreibungen der Ebenen

2.4.1 Erfahrungsebene

2.4.2 Anwendungs-/Geschäftsebene

2.4.3 Integrations-/API-Ebene

2.4.4 Daten: Abfrage und Austausch

2.4.5 KI-Ebene

2.4.6 Laufzeit- und Betriebssystemebene

2.4.7 Identitäts- und Zugriffsebene

Siehe Anhang: Digitale Identitätssysteme für detaillierte Informationen zum Implementierungsrahmen.

2.4.8 DRM- und Lizenzierungsebene

2.4.9 Übergreifende Ebenen

2.5 Sovereign Stack Core-Sprachfamilien

1. Skripting (DevEx / Automatisierung) – JavaScript (ES6) mit JSONata für Datenskripting
2. Erfahrung (Präsentation und Interaktion) – JavaScript (ES6), HTML, CSS, Webkomponenten, PWAs
3. Anwendungs-/Geschäftslogik – JavaScript (ES6) über Node.js
4. Dokumentation und Wissen (Markdown-first) – Markdown, JSON Schema, OpenAPI

Ausnahmen: Wenn leistungskritische, domänenspezifische oder Legacy-Interoperabilität erforderlich ist. Alle Ausnahmen sollten über Open API + UQL offengelegt werden und die Mindestanforderungen an Beobachtbarkeit und Sicherheit erfüllen.

Praktische Hinweise zur Umsetzung, einschließlich Muster für die Zustandsverwaltung, Protokollierungsstandards und Dokumentationsanforderungen, finden Sie im Anhang: Empfehlungen zur Technologieimplementierung.

3. VORGEHENSWEISE: Governance, Finanzierung und Zertifizierung

3.1 Governance und PPP-Modell

Die Initiative sollte als öffentlich-private Partnerschaft unter der Leitung der GD CONNECT und unter starker Beteiligung von KMU, Universitäten und Industrieverbänden vorangetrieben werden. Ein gemeinsamer Ausschuss sollte Prioritäten festlegen, leichtgewichtige Konformitätsprofile definieren und sowohl den öffentlichen Nutzen als auch private Innovationen sicherstellen.

3.2 Zertifizierung

Die Zertifizierung sollte einem mehrstufigen Modell folgen:

• Selbstzertifizierung für risikoarme Dienste über ein einfaches Open-Source-Testsystem, das jeder ausführen kann
• Geprüfte Zertifizierung für kritische Infrastrukturen, um Vertrauen und Widerstandsfähigkeit zu gewährleisten

3.3 Finanzierungsmodell

Geschätztes Budget: Bis zu 1 Mio. GBP für das erste Pilotprojekt

Modell: 50:50-Partnerschaft zwischen dem öffentlichen und dem privaten Sektor

Diskutierte Finanzierungsquellen:

• DG CONNECT (Programm „Digitales Europa”)
• Britische Regierung (DSIT, GDS)
• Beiträge der Partner (Sach- und Geldleistungen)

3.4 Lizenzierung für Artefakte

• Whitepaper und nicht-codierte Inhalte: CC BY 4.0 (Kopieren, Anpassen, kommerzielle Nutzung mit Namensnennung)
• Code-Beispiele und Prototyp-Implementierungen: Standardmäßig MIT für maximale Zulässigkeit; Apache-2.0 für Komponenten, bei denen Partner eine ausdrückliche Patentgewährung bevorzugen

3.5 Veröffentlichung und Repository

Öffentliches Repository (z. B. github.com/Buckden/vb-sovereignstack) mit Spezifikationen, Code und Testartefakten; Issues für Community-Feedback und Selbstzertifizierungs-Testergebnisse.

4. WO: Das Pilotprojekt

4.1 Was macht einen idealen Pilotstandort aus?

Der Sovereign Stack ist so konzipiert, dass er in jeder Region funktioniert, die zur Zusammenarbeit zwischen dem öffentlichen, privaten und akademischen Sektor bereit ist. Der ideale Pilotstandort verfügt über:

1. Smart-City-Ambitionen – Eine Erfolgsbilanz oder das Bestreben nach digitaler Innovation und bürgerorientierten Dienstleistungen
2. Skalierbarer, aber überschaubarer Umfang – Groß genug für aussagekräftige Daten, klein genug für ein kontrolliertes Pilotprojekt
3. Starke lokale Partnerschaften – Bestehende Beziehungen zwischen lokalen Behörden, Arbeitgebern und akademischen Einrichtungen
4. Strategische Sichtbarkeit – Ein Profil, das die Aufmerksamkeit der nationalen Regierung und der EU-Institutionen auf sich zieht
5. Politische Ausrichtung – Lokale und nationale Regierungen, die bereit sind, digitale Führungsstärke zu demonstrieren
6. Unmittelbarer Nutzen für die Gemeinschaft – Einwohner und lokale Unternehmen profitieren von offenen Daten und neuen digitalen Dienstleistungen

4.2 Der Pilotansatz

Das Pilotprojekt hat zwei Ziele: den Aufbau des Sovereign Stack und den Nachweis seiner Funktionsfähigkeit durch die Verbesserung eines realen lokalen Dienstes.

Aufbau des Stacks

Die wiederverwendbaren digitalen Grundelemente, die jedem Sovereign Stack-Dienst zugrunde liegen. Entscheidend ist, dass der Stack AI-fähig ist und über standardisierte, maschinenlesbare Spezifikationen, konsistente Muster und eine umfassende Testabdeckung verfügt, sodass die AI-gestützte Entwicklung und das Testen vom ersten Tag an schnelle und qualitativ hochwertige Ergebnisse liefern können.

• Identität und Zugriff: OAuth 2.0 + OIDC-Verbund, FIDO2/WebAuthn-Passwortlose Authentifizierung
• API-Schicht: OpenAPI + GraphQL, standardisierte Muster, KI-auswertbare Schemata
• Datenschicht: Sicherheit auf Zeilenebene, standardmäßig verschlüsselt, benutzergesteuert
• Beobachtbarkeit: OpenTelemetry-Instrumentierung, Winston-Protokollierung
• Dokumentation: JSDoc + Markdown, durchgehend KI-lesbare Spezifikationen
• Testen: Umfassende automatisierte Testsuiten, die eine KI-gestützte Qualitätssicherung ermöglichen

Verbesserung eines lokalen Dienstes

Der Stack ist nur dann wertvoll, wenn er ein echtes Problem löst. Im Rahmen des Pilotprojekts wird ein bestehender lokaler Dienst, der nach Meinung der federführenden Behörde und des Unternehmenspartners einer Aktualisierung bedarf, auf dem Sovereign Stack neu aufgebaut oder verbessert.

Der konkrete Dienst wird während der Mobilisierung mit den Partnern vereinbart. Es sollte sich um einen Dienst handeln, den die Bürger bereits nutzen und der derzeit noch Mängel aufweist: langsam, veraltet, schlecht integriert oder ohne Benutzerkontrolle. Durch die Modernisierung eines Dienstes, den die Menschen kennen, demonstrieren wir den Wert des Stacks auf eine Weise, die sofort greifbar ist.

Was als Nächstes kommt: FrankMail

Sobald sich der Stack im Pilotdienst bewährt hat, wird er zur Grundlage für weitere The Sovereign Stack-Dienste, beginnend mit FrankMail, einer souveränen E-Mail-Plattform, auf der die Benutzer kontrollieren können, wer sie erreichen kann. Ausführliche Informationen finden Sie auf der FrankMail-Seite.

4.3 Rollen der Partner

Für das Pilotprojekt werden drei Arten von Partnern benötigt: eine ambitionierte lokale Behörde, ein Unternehmen aus dem privaten Sektor und eine akademische Einrichtung. Jeder bringt eine andere Perspektive mit: Erbringung öffentlicher Dienstleistungen, wirtschaftliche Tragfähigkeit und unabhängige Bewertung.

Eine vollständige Beschreibung der Partnerrollen, der zu erbringenden Leistungen, des Zeitplans und der Erfolgskennzahlen finden Sie auf der Pilot-Seite.

Anhänge

Anhang A: Referenzen zu wirtschaftlichen Belegen

1. McKinsey & Company (2020) – „Developer Velocity Index“: Schätzungsweise 40–50 % des technischen Aufwands entfallen auf Integration, Wartung und Nachbesserungen statt auf die Schaffung neuer Werte.
2. Gartner (2022) – „Top Priorities for CIOs“: Es wird darauf hingewiesen, dass 20–40 % der IT-Budgets in großen Unternehmen durch technische Schulden und damit verbundene Ineffizienzen absorbiert werden.
3. IDC (2023) – Worldwide IT Spending Guide: Prognose, dass die weltweiten IT-Ausgaben bis 2025 5 Billionen US-Dollar übersteigen werden, wobei 30–35 % auf Integrations- und Duplikationsprobleme zurückzuführen sind.
4. Ponemon Institute (2021) – „Password Practices Report”: Schätzung, dass die durchschnittlichen Kosten für die Passwortverwaltung 150–200 US-Dollar pro Mitarbeiter und Jahr betragen.
5. Europäische Kommission (2020) – EU-Strategie für Cybersicherheit: Jährliche Verluste durch Cyberkriminalität in Höhe von 55 Milliarden Euro, die größtenteils auf Schwachstellen bei der Identitäts- und Authentifizierungsprüfung zurückzuführen sind.
6. Britisches Kabinettsamt (2022) – „Digital Identity Update“: stellte fest, dass 40 % der Verzögerungen bei der digitalen Transformation der Regierung mit Hindernissen im Bereich Identität/Authentifizierung zusammenhängen.
7. Europäische Kommission (2021) – Digital Compass 2030: warnte vor jährlichen Opportunitätskosten in Höhe von 400 Milliarden Euro, wenn Europa die Einführung offener digitaler Technologien und die digitale Souveränität nicht beschleunigt.
8. ECMA International – JavaScript ist in der ECMA-262 ECMAScript Language Specification definiert, wobei ES6 (ECMAScript 2015) die grundlegende Version für moderne Implementierungen darstellt.

Anhang B: Europäische digitale Grundlagen

Europas Führungsrolle bei grundlegenden digitalen Technologien von den 1960er Jahren bis heute:

Anhang C: Rahmenwerk für digitale Identitätssysteme

Moderne digitale Identitätssysteme lassen sich anhand von vier miteinander verbundenen Ebenen verstehen, die die Kernfunktionalität für Benutzer bereitstellen.

Unterstützte Funktionen

Digitale Identitätssysteme ermöglichen vier Hauptfunktionen:

1. Authentifizierung und Autorisierung: Nachweis der Identität und Zugriff auf Dienste
2. Digitale Signatur: Erstellung rechtsverbindlicher elektronischer Signaturen
3. Identitätsprüfung mit überprüfbaren Berechtigungsnachweisen: Nachweis bestimmter Attribute ohne übermäßige Weitergabe von Daten
4. Dokumentenspeicherung: Sichere Aufbewahrung und Vorlage offizieller Dokumente

Struktur und Haftungsrahmen

Die Governance-Struktur bestimmt Vertrauen und Verantwortlichkeit. Wer Berechtigungsnachweise ausstellt, wer deren Gültigkeit bestätigt und wer die Haftung übernimmt, wenn etwas schiefgeht, bildet das entscheidende Vertrauensdreieck.

Die eIDAS-Verordnung der EU legt eine klare gesetzliche Haftung fest: Die Mitgliedstaaten haften für Authentifizierungsfehler, während qualifizierte Vertrauensdienstleister eine Pflichtversicherung abschließen müssen. Das Vereinigte Königreich verfolgt ein fragmentierteres Modell der vertraglichen Haftung, bei dem die Verantwortung je nach Sektor und Vereinbarung variiert.

Zweistufiges Aussteller-Modell

Stufe 1 (Root Identity) legt die grundlegende digitale Identität fest: das primäre Schlüsselpaar und den zentralen Identitätsnachweis, der besagt: „Dieser kryptografische Schlüssel gehört zu dieser verifizierten Person.“ In der Regel kontrollieren von der Regierung benannte Anbieter diese Stufe.

Ebene 2 (Attribute) sieht vor, dass verschiedene autoritative Quellen dieser Root-Identität Referenzen hinzufügen: Universitäten fügen Abschlüsse hinzu, Verkehrsbehörden Führerscheine, Arbeitgeber bestätigen den Beschäftigungsstatus.

Diese Trennung ist entscheidend: Sie haben eine verifizierte Identität, aber viele zugehörige Attribute.

Technische Umsetzung

Der zugrunde liegende Technologie-Stack, von FIDO2/WebAuthn für die passwortlose Authentifizierung über PKI für digitale Signaturen bis hin zu W3C Verifiable Credentials für die selektive Offenlegung, bleibt über alle Systeme hinweg weitgehend konsistent. Die wesentlichen Unterschiede liegen in den architektonischen Entscheidungen: zentralisierte versus wallet-basierte Speicherung, Föderationsprotokolle und die Frage, ob neue Technologien wie Zero-Knowledge-Proofs für die datenschutzkonforme Verifizierung eingesetzt werden sollen.

EU-Digital Identity Wallet (EUDIW)

Ein Wallet-basiertes System, das alle EU-Mitgliedstaaten verpflichtet, bis Dezember 2026 interoperable digitale Identitäten mit gesetzlicher Haftung und garantierter grenzüberschreitender Akzeptanz auszugeben.

Wichtige Termine:

• Dezember 2026: Mindestens ein Wallet in jedem Mitgliedstaat verfügbar
• Dezember 2027: Obligatorische Akzeptanz durch bestimmte vertrauende Parteien des privaten Sektors

Digitale Identität im Vereinigten Königreich

Ein marktorientierter Ansatz, der GOV.UK One Login für öffentliche Dienste mit zertifizierten privaten Anbietern kombiniert, die außerhalb von eIDAS mit sektorspezifischen Regeln und kommerziellen Haftungsmodellen operieren.

Wesentlicher Unterschied: Die EU schreibt ein interoperables System mit Rechtskraft in 27 Ländern vor, während das Vereinigte Königreich auf die Marktakzeptanz mit freiwilliger Akzeptanz und unterschiedlichen Standards je nach Sektor setzt.

Anhang D: Empfehlungen zur Technologieimplementierung

Zustandsverwaltung

Implementieren Sie Zustandsmaschinen mit einfachen JavaScript-Objekten für einfache Fälle mit weniger als fünf Zuständen und linearen Übergängen und reservieren Sie XState für komplexe Szenarien mit verschachtelten Zuständen, asynchronen Operationen oder Schutzbedingungen.

Verwenden Sie ein Singleton-Service-Muster, das nach Funktionsbereichen (Authentifizierung, Datenverwaltung, Benutzeroberfläche) verteilt ist, und stellen Sie sicher, dass jeder Bereich eine einzige global zugängliche Instanz unterhält, um eine Fragmentierung der Zustände zu verhindern.

Speichern Sie nur geschäftskritische Zustände in der Datenbank, während Sie kurzlebige UI-Zustände im Speicher behalten, um sowohl die Leistung als auch die Systemkohärenz zu optimieren.

Protokollierungsinfrastruktur

Verwenden Sie Winston als Standard-Protokollierungsframework für alle Node.js-Dienste, konfiguriert mit strukturierter JSON-Ausgabe für die maschinelle Analyse und menschenlesbarer Formatierung für die Entwicklung.

Implementieren Sie Korrelations-IDs über Servicegrenzen hinweg, um eine durchgängige Nachverfolgung von Anfragen zu ermöglichen.

Legen Sie die Protokollierungsstufen dynamisch pro Umgebung fest: ausführlich für die Entwicklung, Info für die Staging-Umgebung, Warnung für die Produktion, mit der Möglichkeit, die Stufen für die Fehlersuche vorübergehend ohne Bereitstellung anzuheben.

Dokumentationsstandards

Verlangen Sie JSDoc-Kommentare für alle öffentlichen APIs und komplexen internen Funktionen, um die automatische Generierung von API-Dokumentationen und IDE-Intelligenz zu ermöglichen.

Kombinieren Sie JSDoc mit Markdown-Dateien für Architekturentscheidungen, Einrichtungsanleitungen und Betriebshandbücher.

Behalten Sie einen dokumentationsorientierten Ansatz bei, bei dem APIs vor der Implementierung dokumentiert werden, um Vertragsklarheit zu gewährleisten und Integrationsprobleme zu reduzieren.

Mitmachen

The Sovereign Stack sucht drei Arten von Partnern: lokale Behörden, Unternehmenspartner und akademische Einrichtungen, um das erste Pilotprojekt durchzuführen. Eine vollständige Beschreibung der Partnerrollen finden Sie auf der Pilotseite.

Kontakt: richard@buckden.io Website: thesovereignstack.eu

The Sovereign Stack: digitale Abfälle in digitale Souveränität verwandeln.