# Der digitale Ausweis (EUDI-Wallet)

## Executive Summary

Die Einführung der European Digital Identity Wallet (EUDI-Wallet) markiert eine Zäsur in der Geschichte der europäischen Verwaltung und der digitalen Bürgerrechte. Was als Modernisierungsprojekt zur Vereinfachung bürokratischer Prozesse und zur Förderung des digitalen Binnenmarktes verkauft wird, birgt bei näherer Betrachtung das Potenzial für eine fundamentale Verschiebung der Machtverhältnisse zwischen Staat, Konzernen und Individuum. Dieser Bericht, verfasst im Auftrag der Partei "Digitale Politik Revolution" (DPR) , unterzieht das Vorhaben einer tiefgreifenden Analyse, die weit über die oberflächlichen Versprechen von Bequemlichkeit hinausgeht.

Wir befinden uns im Jahr 2026. Die ursprünglichen Zeitpläne der Europäischen Kommission sind Makulatur, die Realität ist geprägt von technischer Fragmentierung, verfassungsrechtlichen Bedenken und einem erbitterten Kampf um Standards. Während die Bundesregierung und die EU-Kommission die EUDI-Wallet als "Game Changer" für die digitale Souveränität anpreisen, warnen Kryptographen, Verfassungsrechtler und die Zivilgesellschaft vor einem Überwachungsinstrument, das den "gläsernen Bürger" Realität werden lassen könnte.

Die Analyse basiert auf den unverhandelbaren Grundsätzen der DPR: **Self-Sovereign Identity (SSI) ** , **radikale Transparenz durch Open Source **und **Datenschutz durch Technik (Privacy ****by ****Design) ** . Wir beleuchten die Diskrepanz zwischen dem propagierten Ziel der Datensparsamkeit und der architektonischen Realität der eIDAS 2.0-Verordnung, die durch die Einführung eindeutiger Personenkennzeichen (Unique Identifiers) die verfassungsrechtlichen Errungenschaften der letzten Jahrzehnte bedroht. Gleichzeitig untersuchen wir die Rolle der US-Hyperscaler Apple und Google, die über ihre Betriebssysteme die Hoheit über die digitale Identität der Europäer beanspruchen, und bewerten die deutschen Bemühungen – insbesondere den SPRIND-Innovationswettbewerb – im Hinblick auf echte digitale Unabhängigkeit.

## Historische Genese und politische Motivation: Von eIDAS 1.0 zum Wallet-Paradigma

### Das Scheitern der ersten Generation (eIDAS 1.0)

Um die Notwendigkeit und die Risiken der EUDI-Wallet zu verstehen, ist ein Blick auf die Vorgängerregelung unerlässlich. Die ursprüngliche eIDAS-Verordnung von 2014 zielte darauf ab, gegenseitig anerkannte elektronische Identifizierungssysteme (eID) in Europa zu schaffen. Das Ergebnis war ernüchternd. Die Verbreitung der notifizierten eID-Systeme blieb minimal; die Nutzung war kompliziert, erforderte oft spezielle Lesegeräte (wie beim deutschen Personalausweis nPA vor der AusweisApp2 auf Smartphones) und fand im privaten Sektor kaum Akzeptanz. Nur ein Bruchteil der EU-Bürger konnte seine nationale eID grenzüberschreitend nutzen. Dieses Scheitern führte zu der Erkenntnis, dass eine reine "Ausweis-Virtualisierung" nicht ausreicht. Es brauchte einen Paradigmenwechsel hin zur "Wallet" – einer Brieftasche auf dem Smartphone, die nicht nur die Identität, sondern auch Attribute (Führerschein, Zeugnisse) und Signaturen bündelt.

### Der politische Imperativ: eIDAS 2.0 und die “Digitale Dekade”

Mit der eIDAS 2.0-Verordnung (Regulation (EU) 2024/1183) wurde dieser Wechsel gesetzlich verankert. Das erklärte Ziel der EU-Kommission ist es, bis 2030 mindestens 80 % der Bürger mit einer digitalen ID auszustatten. Die politische Motivation ist zweigeteilt: Einerseits soll der digitale Binnenmarkt durch den Abbau von Reibungsverlusten bei Identifizierungen gestärkt werden. Andererseits soll die "digitale Souveränität" Europas gegenüber den dominierenden US-Plattformen gesichert werden, die mit "Sign in with Apple" oder "Google Identity" faktisch zu den globalen Identitäts-Providern geworden sind.

Die DPR unterstützt das Ziel der Unabhängigkeit von US-Konzernen ausdrücklich. Wir kritisieren jedoch, dass der gewählte Weg der eIDAS 2.0 Gefahr läuft, die Abhängigkeit von Konzernen durch eine Abhängigkeit von einem übergriffigen Staatsapparat zu ersetzen, anstatt den Bürger durch dezentrale SSI-Konzepte wirklich zu ermächtigen.

### Der Zeitplan: Ein Stolpern in die Zukunft

Der ursprüngliche Zeitplan sah vor, dass alle EU-Mitgliedstaaten bis Ende 2026 eine EUDI-Wallet anbieten müssen. Die Realität Anfang 2026 zeigt jedoch massive Verzögerungen. Experten gehen davon aus, dass eine flächendeckende, voll funktionsfähige Verfügbarkeit bis zum Stichtag unwahrscheinlich ist. Während Länder wie die Niederlande Verzögerungen signalisieren, bereitet sich die EU auf einen "gestaffelten Rollout" vor, bei dem Funktionen nach und nach freigeschaltet werden. Deutschland plant den offiziellen Start der staatlichen Wallet für Anfang 2027 , was den Druck auf die technische Umsetzung erhöht und das Risiko von "Schnellschüssen" zu Lasten der Sicherheit vergrößert. Für EWR-Staaten und Beitrittskandidaten wurde die Frist bereits auf 2027 verlängert.

## Die Architektur der Kontrolle: Das ARF und die technische Realität

Das Herzstück der EUDI-Wallet ist das "Architecture and Reference Framework" (ARF) . Dieses Dokument definiert die technischen Standards, Protokolle und Sicherheitsanforderungen. Die Analyse der Versionen 1.4, 1.5 und des aktuellen Entwurfs 1.6 offenbart den Kernkonflikt zwischen Überwachbarkeit und Privatsphäre.

### Das Gespenst der eindeutigen Kennung (Unique Persistent Identifier)

Der wohl kritischste Punkt der gesamten Architektur ist die Forderung nach einer eindeutigen, dauerhaften Kennung (Unique Persistent Identifier) . Die eIDAS-Verordnung verlangt, dass Bürger grenzüberschreitend eindeutig identifiziert werden können. Dies erfordert technisch eine Kennziffer, die einer Person lebenslang zugeordnet ist.

### Verfassungsrechtliche Unvereinbarkeit in Deutschland

Für Deutschland stellt dies ein massives verfassungsrechtliches Problem dar. Das Bundesverfassungsgericht hat im Volkszählungsurteil von 1983 unmissverständlich klargestellt, dass ein einheitliches Personenkennzeichen, das eine Registrierung und Katalogisierung des Menschen in seiner gesamten Persönlichkeit ermöglicht, mit dem Grundgesetz unvereinbar ist (Verstoß gegen die Menschenwürde und das Recht auf informationelle Selbstbestimmung) .

Eine solche Kennziffer würde es ermöglichen, Daten aus unterschiedlichsten Lebensbereichen – Gesundheit, Finanzen, Mobilität, Verwaltung – über Datenbankgrenzen hinweg zu verknüpfen. Wenn dieselbe Kennung bei der Eröffnung eines Bankkontos, bei der Anmietung eines Autos und beim Einlösen eines E-Rezepts verwendet wird, entsteht ein umfassendes Profil des Bürgers. Zivilgesellschaftliche Organisationen und der Chaos Computer Club (CCC) warnen vor diesem "Over-Identification"-Szenario und der Gefahr, dass Big Tech und staatliche Stellen diese Kennung als universellen Tracking-Cookie missbrauchen.

### Die DPR-Forderung: Sektorale Pseudonyme

Die DPR fordert eine strikte Umsetzung von "Unlinkability" (Unverkettbarkeit) . Anstelle einer globalen Kennung muss die Wallet für jeden Sektor (oder sogar für jede Transaktion) ein unterschiedliches, kryptographisch abgeleitetes Pseudonym generieren.

- Die Bank erhält Pseudonym A.
- Das Krankenhaus erhält Pseudonym B.
- Die Universität erhält Pseudonym C. Diese Pseudonyme dürfen mathematisch nicht miteinander verknüpfbar sein ("Unlinkable") , außer durch eine richterlich angeordnete Entschlüsselung in schweren Verdachtsfällen. Das aktuelle ARF sieht zwar Mechanismen für Pseudonyme vor, Kritiker bemängeln jedoch, dass die Basis-Identität (PID) oft immer noch eine statische Kennung enthält, die das Tracking ermöglicht.

### Der Kampf der Standards: mDoc vs. W3C Verifiable Credentials

Hinter den Kulissen tobt ein Richtungsstreit über das Datenformat der Nachweise.

### mDoc (ISO 18013-5)

Dieser Standard stammt aus der Welt der physischen Ausweisdokumente und Führerscheine. Er wird von etablierten Playern wie Staatsdruckereien und Hardware-Herstellern favorisiert.

- **Vorteile: **Hohe Akzeptanz für "Offline"-Szenarien (z.B. Polizeikontrolle am Straßenrand ohne Internet) , gute Integration in bestehende Hardware-Security-Module.
- **Nachteile & Kritik: **Der Standard ist komplex, teilweise proprietär und schwerfällig für reine Online-Use-Cases. Kritiker bemängeln, dass mDoc standardmäßig nicht genügend Schutz vor Tracking bietet ("Proximity Flow" kann Metadaten leaken) und nicht "Web-Native" ist.

### W3C Verifiable Credentials (VC) & OpenID4VC

Dieser Ansatz stammt aus der Web-Community und der SSI-Bewegung. Er setzt auf JSON-basierte Formate und offene Web-Protokolle.

- **Vorteile: **Dezentral, flexibel, ideal für Online-Transaktionen, unterstützt moderne kryptographische Verfahren wie Zero-Knowledge Proofs (ZKP) nativ besser.
- **DPR-Position: **Wir präferieren offene Web-Standards. Die Entscheidung, OpenID4VC in das ARF aufzunehmen, ist ein Teilerfolg, doch die Implementierung darf nicht durch restriktive Profile "verkrüppelt" werden.

### Kryptographie der Zukunft: Zero-Knowledge Proofs & BBS+

Das Versprechen der "Selektiven Offenlegung" (Selective Disclosure) – z.B. der Nachweis der Volljährigkeit ohne Preisgabe des Geburtsdatums – ist nur die halbe Miete. Wenn bei diesem Nachweis eine klassische digitale Signatur (z.B. RSA oder ECDSA) des Staates übermittelt wird, ist diese Signatur eindeutig und kann zum Tracking genutzt werden.

Hier kommen **BBS+ Signaturen **und **Zero-Knowledge Proofs (ZKP) **ins Spiel. Diese Verfahren ermöglichen es, mathematisch zu beweisen, dass eine Aussage wahr ist (z.B. "Alter > 18") , ohne die zugrundeliegende Signatur im Klartext zu zeigen. Dadurch wird die Transaktion unverkettbar.

- **Status: **Kryptographen haben in Feedback-Runden zur ARF-Version 1.4 dringend die Implementierung von BBS+ (Anonymous Credentials) gefordert, da das ursprüngliche Design massive Privatsphäre-Lücken aufwies.
- **ARF 1.6: **Neuere Versionen des ARF und die Diskussionen im GitHub-Repository zeigen, dass diese Kritik gehört wurde, die Umsetzung aber komplex ist und möglicherweise erst in späteren Phasen ("Wave 2") verpflichtend wird. Für die DPR ist dies inakzeptabel: Privacy by Design muss im Kern (Core) ab Tag 1 verankert sein.

**Tabelle 1: Technologischer Vergleich der Standards **

| Merkmal | ISO 18013-5 (mDoc) | W3C Verifiable Credentials (SD-JWT / JSON-LD) | AnonCreds (BBS+ / ZKP) |
| --- | --- | --- | --- |
| * ***Ursprung **** | Führerschein-Behörden / ISO | Web Community / W3C | Kryptographie-Forschung / Hyperledger |
| * ***Offline-Fähigkeit **** | Sehr gut (Optimiert für NFC/BLE) | Möglich, aber komplexer | Möglich |
| * ***Privacy ( ****Unlinkability ****) * *** | Mittel (Gefahr des Trackings durch Seriennummern) | Mittel (SD-JWT kann linkable sein) | Hoch (Mathematisch garantierte Unverkettbarkeit) |
| * ***Selektive Offenlegung **** | Ja (auf Feldebene) | Ja (auf Feldebene) | Ja (auf Prädikatsebene, z.B. "älter als 18") |
| * ***DPR-Bewertung **** | Kritisch (Legacy-Last) | Akzeptabel (Übergangslösung) | **Favorisiert (Zielbild) ** |

## Der Zwang durch die Hintertür: Freiwilligkeit vs. Lebensrealität

Offiziell ist die Nutzung der EUDI-Wallet für Bürger freiwillig. Art. 5a der eIDAS-Verordnung betont, dass niemand benachteiligt werden darf, der die Wallet nicht nutzt. Doch die Analyse der DPR zeigt, dass diese Freiwilligkeit in der Praxis zur Illusion werden könnte.

### Die Annahmepflicht (Mandatory Acceptance)

Der entscheidende Hebel ist die Annahmepflicht für Unternehmen in kritischen Sektoren. Bis Ende 2027 müssen folgende Bereiche die Wallet akzeptieren:

- **Banken & Finanzdienstleister: **Für die Identifizierung (KYC) und die starke Kundenauthentifizierung (SCA) .
- **Telekommunikation: **Für den Abschluss von Handyverträgen (Prepaid-Registrierung) .
- **Verkehr: **Öffentlicher Nahverkehr, Flugreisen, Mietwagen.
- **Große Online-Plattformen (VLOPs) : **Amazon, Google, Facebook, Twitter (X) müssen die Wallet als Login-Option anbieten (Art. 5f) .
- **Energie & Gesundheit: **Stromanbieter und Krankenkassen.

### Das Szenario der Ausgrenzung

Wenn ein Bankkonto per EUDI-Wallet in 30 Sekunden per Klick eröffnet werden kann, während der analoge Weg (PostIdent in der Filiale) Tage dauert, Gebühren kostet oder Personalabbau in Filialen zur Unmöglichkeit wird, entsteht ein faktischer Zwang (Nudging) . Wer die Wallet verweigert, zahlt mit Zeit und Geld. Die DPR warnt vor einer "Zwei-Klassen-Gesellschaft" der digitalen Teilhabe. Wir fordern ein gesetzlich verankertes Recht auf analoge Alternativen, die diskriminierungsfrei und ohne Zusatzkosten zugänglich sein müssen.

### BundID und die Staats-App

In Deutschland wird die Wallet eng mit der BundID verknüpft, dem zentralen Konto für Verwaltungsleistungen. Wenn Kindergeld, BaföG oder die Kfz-Anmeldung nur noch effizient über die Wallet abgewickelt werden, wird der Bürger in das System gedrängt. Die Verknüpfung der Steuer-ID als faktisches Personenkennzeichen im Hintergrund der BundID verschärft die Problematik der Profilbildung.

## Open Source und Transparenz: Der Lackmustest für Vertrauen

Für die DPR ist klar: Eine Software, die als digitaler Ausweis dient, ist kritische Infrastruktur. Sie darf keine "Black Box" sein. Vertrauen entsteht nur durch Transparenz.

### Die SPRIND “Funke” Challenge: Ein Leuchtturm mit Schatten

Der Innovationswettbewerb der Bundesagentur für Sprunginnovationen (SPRIND) war ein lobenswerter Ansatz, um die Entwicklung der Wallet nicht nur großen Konzernen zu überlassen, sondern innovative Lösungen zu fördern. Über drei Stufen (Stages) konkurrierten Teams um die besten Prototypen.

- **Die Gewinner: **Teams wie **"Heidi" ** (Human Centric EID) , **"Animo" **und **"Lissi" ** (aus dem neosfer/Main Incubator Umfeld) setzten sich durch.
- **Open Source Verpflichtung: **Ein zentraler Erfolg war die Verpflichtung für Teams im "Funded Track", ihre Ergebnisse als Open Source zu veröffentlichen. Dies ermöglichte der Community erstmals Einblicke in den Code.

### Die Google-Kontroverse

Ein Skandal, der die Ambivalenz des Projekts zeigt, war die Teilnahme von Google LLC an der Challenge. Dass ein US-Datenkonzern, dessen Geschäftsmodell auf der Monetarisierung von Nutzerdaten basiert, mit deutschen Steuergeldern an einem Prototypen für den staatlichen Ausweis arbeitet, sorgte für Entsetzen beim Chaos Computer Club und Datenschutzexperten. Zwar argumentierte SPRIND mit Technologieneutralität, doch für die DPR ist dies ein sicherheitspolitischer Offenbarungseid. Es unterstreicht die Abhängigkeit Europas: Wir versuchen, uns von Big Tech zu emanzipieren, indem wir sie bezahlen, unsere Tools zu bauen.

### Die Realität der Code-Repositories

Unsere Überprüfung der verfügbaren Repositories auf OpenCoDE und GitHub (Stand 2026) zeigt Licht und Schatten :

- **Frontend-Fokus: **Viele verfügbare Codes betreffen die Benutzeroberfläche (UI) und Referenz-Implementierungen der App.
- **Backend-Lücken: **Kritische Infrastruktur-Komponenten (Issuance, Revocation Services) sind oft nur als Architektur-Dokumentation vorhanden oder fehlen als ausführbarer Code. Die "Business Logic" der staatlichen PID-Provider bleibt oft im Dunkeln.
- **Lizenzierung: **Die Nutzung der EUPL oder Apache 2.0 Lizenzen ist positiv. Doch wir brauchen **Reproducible ****Builds ** (verifizierbare Kompilate) , damit Bürger sicherstellen können, dass die App im Google Play Store tatsächlich aus dem geprüften Quellcode stammt und keine Hintertüren enthält. Bisher ist dies nicht flächendeckend garantiert.

## Das Duopol und die Hardware-Souveränität

Die Software der Wallet ist nur so sicher wie die Hardware, auf der sie läuft. Hier offenbart sich das europäische Dilemma: Wir haben keine eigene mobile Hardware-Plattform. Wir sind Gast auf den Geräten von Apple und Google.

### Der Kampf um das “Secure Element”

Um das höchste Sicherheitsniveau (LoA High) zu erreichen, muss die Wallet kryptographische Schlüssel in einem speziellen Hardware-Chip speichern (Secure Element / Secure Enclave) .

- **Die Blockade: **Lange Zeit verweigerte Apple Dritten den vollen Zugriff auf den NFC-Chip und das Secure Element, um seine eigene "Apple Wallet" zu privilegieren.
- **Digital ****Markets ****Act (DMA) : **Die EU hat über den DMA versucht, diese Öffnung zu erzwingen. Doch die technische Umsetzung ist zäh. Apple verlangt Gebühren oder setzt technische Hürden.
- **Das Risiko: **Wenn die EUDI-Wallet auf APIs angewiesen ist, die Google oder Apple kontrollieren (z.B. Google Play Integrity API) , können diese Konzerne diktieren, auf welchen Geräten der Ausweis funktioniert. "Gerootete" Geräte oder alternative Betriebssysteme (wie GrapheneOS) , die oft von datenschutzbewussten Nutzern verwendet werden, könnten ausgesperrt werden.

### Die “Wallet Economy” der Banken

Die Sparkassen-Finanzgruppe und andere Banken versuchen, die EUDI-Wallet in ihre eigenen Apps zu integrieren, um die Kundenbeziehung nicht an Apple Pay / Google Wallet zu verlieren. Dies ist strategisch verständlich, birgt aber die Gefahr der Fragmentierung. Die DPR fordert, dass die staatliche Identität eine neutrale Infrastruktur bleibt und nicht zum Marketing-Tool für Banken wird.

## Self-Sovereign Identity (SSI) : Der Gegenentwurf der DPR

Die DPR sieht in **Self-Sovereign Identity (SSI) **nicht nur eine Technologie, sondern eine Bürgerrechtsbewegung. Das aktuelle EUDI-Wallet-Design ist ein Hybrid, der SSI-Elemente nutzt, aber zentralistische Kontrollmechanismen beibehält.

### Nutzerzentrierung vs. Staatszentrierung

- **Klassisches Modell: **Der Staat führt ein Register. Jede Prüfung fragt das Register ab. Der Staat weiß alles.
- **SSI Modell ****: **Der Nutzer hat die Daten auf seinem Gerät (Wallet) . Er zeigt sie vor (Peer-to-Peer) . Der Staat (Issuer) ist bei der Prüfung (Verification) nicht involviert.
- **EUDI-Realität: **Die ARF verlangt Mechanismen zur Validierung von Zertifikaten (Revocation Checks via OCSP) , die dazu führen könnten, dass der Staat (oder der Wallet-Provider) in Echtzeit sieht, wann und wo der Ausweis genutzt wird. Dies ist das Gegenteil von SSI.

### Dezentrale Identifikatoren (DIDs)

Echte SSI nutzt DIDs, die keine zentrale Registrierungsstelle benötigen. Die EUDI-Wallet setzt jedoch stark auf X.509 Zertifikate (QES) , die eine hierarchische Struktur (PKI) erfordern. Dies zementiert Machtstrukturen, anstatt sie zu demokratisieren. Die DPR fordert die volle Unterstützung der W3C DID-Spezifikation, um eine Unabhängigkeit von staatlichen Root-CAs zu ermöglichen, wo dies sinnvoll ist (z.B. bei privaten Attributen) .

## Blick in die Zukunft: KI-Agenten und das Internet der Dinge (IoT)

Die Diskussion um die Wallet konzentriert sich oft auf den Menschen. Doch die nächste Welle der Digitalisierung betrifft Autonome Agenten.

### Identität für KI-Systeme

In Zukunft werden KI-Assistenten für uns Verträge abschließen. "Buche mir einen Flug und bezahle ihn." Dafür benötigt der KI-Agent eine abgeleitete Identität und ein Mandat.

- **Das Problem: **Das aktuelle Rechtssystem kennt keine "E-Person". KI hat keine Rechtsfähigkeit.
- **Die Lösung (DPR-Vision) : **Die Wallet muss "Delegation" unterstützen. Ich stelle meinem KI-Agenten ein kryptographisches Mandat (Verifiable Presentation) aus: "Dieser Schlüssel darf in meinem Namen bis zu 500€ ausgeben."
- **Status: **Das ARF 1.6 beginnt, diese Konzepte zu betrachten, aber die rechtliche Grundlage fehlt. Die DPR fordert eine Klärung der Haftung: Wenn mein Agent Unsinn baut, wer haftet? Das Mandat muss technisch so beschränkt sein, dass der Schaden begrenzt bleibt.

### Maschinen-Identitäten

Auch IoT-Geräte (das vernetzte Auto, die Drohne) benötigen Wallets, um sich zu authentifizieren (z.B. an der Ladesäule) . Die EUDI-Wallet-Infrastruktur sollte so offen sein, dass sie auch für Maschinen-Identitäten genutzt werden kann, um ein einheitliches Vertrauens-Ökosystem in Europa zu schaffen, statt parallele Silos für IoT aufzubauen.

## Fazit und Forderungskatalog der DPR

Die EUDI-Wallet steht am Scheideweg. Sie kann das Werkzeug sein, das uns von der Passwort-Hölle befreit und echte digitale Souveränität ermöglicht. Oder sie wird zur perfekten Überwachungsmaschine, die jeden unserer Schritte protokolliert und verknüpft.

Die aktuelle Richtung – geprägt von Zeitdruck, Überwachungswünschen der Sicherheitsbehörden und Lobbyismus der alten Industrien – weist in die falsche Richtung. Doch noch ist der Code nicht final geschrieben.

**Die Partei "Digitale Politik Revolution" stellt folgende 7 Kernforderungen: **

- **Verfassungsfestigkeit garantieren: **Sofortiger Stopp aller Bestrebungen, eine sektorübergreifende Personenkennziffer einzuführen. Implementierung von strikt getrennten, sektoralen Pseudonymen in der PID.
- **Privacy ****by ****Design ohne Kompromisse: **Verpflichtende Nutzung von **BBS+ Signaturen und Zero-Knowledge Proofs **ab Version 1.0, um Unlinkability technisch zu erzwingen.
- **Vollständige Transparenz: **Offenlegung des **gesamten Quellcodes ** (Client & Server) unter freien Lizenzen. Einführung von verifizierbaren Reproducible Builds.
- **Kein Identitäts-Monopol: **Förderung eines Wettbewerbs zertifizierter Open-Source-Wallets. Keine Privilegierung einer "Staats-App".
- **Recht auf Analoges Leben: **Gesetzliches Verbot der Benachteiligung von Nicht-Nutzern. Bargeld und physische Ausweise müssen uneingeschränkt akzeptiert bleiben.
- **Trennungsgebot: **Technische und organisatorische Trennung von Aussteller (Issuer) und Prüfer (Verifier) . Verbot von Echtzeit-OCSP-Abfragen durch staatliche Stellen.
- **Souveränität vor Hardware-Monopolen: **Zwang für Apple und Google, den diskriminierungsfreien Zugriff auf Secure Elements für europäische Wallets zu gewähren (unter Androhung von DMA-Sanktionen) .

Wir rufen alle Bürger, Entwickler und Datenschützer auf, sich in den Konsultationsprozess einzumischen. **Code ****is ****Law **– sorgen wir dafür, dass es ein gerechtes Gesetz wird.

## Datenquellen & Referenzen

Zur Transparenz und wissenschaftlichen Nachvollziehbarkeit sind im Text folgende Quellen verarbeitet:

- [European Digital Identity (EUDI) Regulation | Shaping Europe’s digital future] (https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation)
- [Report on the Architecture of the EUDI-Wallet | 22.11.2024 – Verbraucherzentrale Bundesverband] (https://www.vzbv.de/sites/default/files/2025-02/vzbv-Gutachten%20zur%20Architektur%20der%20EUDI-Wallet.pdf)
- [eIDAS 2.0 – Eine neue Ära der digitalen Identität in der EU – Capco] (https://www.capco.com/intelligence/capco-intelligence/eidas-2-0-eine-neue-aera-der-digitalen-identitaet-in-der-eu)
- [Digital Identity: Europe’s new wallet will change the financial world – neosfer] (https://neosfer.de/en/digital-identity/)
- [The European Digital Identity Wallet – Robert Bosch Stiftung] (https://www.bosch-stiftung.de/sites/default/files/publications/pdf/2024-10/European-Digital-Identity-Wallet-Brief.pdf)
- [Will the EUDI Wallet be ready in 2026? Experts say probably not | Biometric Update] (https://www.biometricupdate.com/202512/will-the-eudi-wallet-be-ready-in-2026-experts-say-probably-not)
- [FAQ – EUDI-Wallets / eIDAS 2 – openCode.de] (https://bmi.usercontent.opencode.de/eudi-wallet/eidas2/faq/)
- [EUDI Wallets – Only One Year to Launch – Signicat] (https://www.signicat.com/blog/eudi-wallets-only-one-year-to-launch)
- [Concerns raised over EU Digital ID Wallet’s impact on privacy and discrimination – CADE] (https://cadeproject.org/updates/concerns-raised-over-eu-digital-id-wallets-impact-on-privacy-and-discrimination/)
- [EUDI Wallet: A wallet full of loopholes – netzpolitik.org] (https://netzpolitik.org/2024/eudi-wallet-a-wallet-full-of-loopholes/)
- [eIDAS 2.0: DIGITAL IDENTITY SERVICES IN THE PLATFORM ECONOMY – cerre] (https://cerre.eu/wp-content/uploads/2022/10/CERRE _Digital-Identity _Issue-Paper _FINAL-2.pdf)
- [A Unique Identification Number for Every European Citizen] (https://verfassungsblog.de/digital-id-eu/)
- [EU’s Digital Identity Systems – Reality Check and Techniques for Better Privacy – 38C3] (https://events.ccc.de/congress/2024/hub/en/event/eu-s-digital-identity-systems-reality-check-and-techniques-for-better-privacy/)
- [Keine Aushöhlung digitaler Rechte in der EU! – CCC] (https://www.ccc.de/de/updates/2025/europaische-zivilgesellschaft-warnt-vor-aushohlung-digitaler-rechte)
- [Digital Identities: Getting to Know the Verifiable Digital Credential Ecosystem | NIST] (https://www.nist.gov/blogs/cybersecurity-insights/digital-identities-getting-know-verifiable-digital-credential-0)
- [The EUDI wallet has privacy issues : r/europrivacy – Reddit] (https://www.reddit.com/r/europrivacy/comments/1qwi1sr/the _eudi _wallet _has _privacy _issues/)
- [Launchpad Testing – EU Digital Identity Wallet – – European Commission] (https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/930453034/Launchpad+Testing)
- [Verifiable Credential Formats in the EUDI Wallet – W3C VC DM and ISO 18013-5 mDL/mDoc] (https://docs.igrant.io/concepts/eudi-wallet-verifiable-credential-formats/)
- [Security and Privacy – EU Digital Identity Wallet – – European Commission] (https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/712508927/Security+and+Privacy)
- [EUDI Wallets: Balancing privacy with usability. – IDnow] (https://www.idnow.io/blog/eudi-wallets-privacy-usability/)
- [Cryptographers warn about EUDI Wallet privacy | Biometric Update] (https://www.biometricupdate.com/202412/cryptographers-warn-about-eudi-wallet-privacy)
- [Cryptographers’ Feedback on the EU Digital Identity’s ARF – Hasso-Plattner-Institut] (https://hpi.de/oldsite/fileadmin/user _upload/fachgebiete/lehmann/Publications/cryptographers-feedback.pdf)
- [Cryptographers’ Feedback on the EU Digital Identity’s ARF #211 – GitHub] (https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/211)
- [EUDI-Wallet and eIDAS 2.0 – Verimi] (https://verimi.de/en/blog/eudi-wallets-eidas-2-0-what-it-is-and-what-it-means-for-companies/)
- [Alles sicher, alles drin? Wieso es beim europäischen “Ausweis to go” jetzt spannend wird] (https://rsw.beck.de/aktuell/daily/meldung/detail/eudi-wallet-europa-digital-ausweis-einfuehrung-pflichten-unternehmen)
- [digitale Identitäten und Vertrauensdienste (eIDAS/EUDI-​Wallet) – Bundesverband Öffentlicher Banken Deutschlands] (https://www.voeb.de/unsere-positionen/digitale-identitaeten)
- [BMDS testet EUDI-Wallet im Zusammenspiel mit BundID – Verwaltungsleistungen künftig digital, sicher und bundesweit nutzbar] (https://bmds.bund.de/aktuelles/aktuelle-meldungen/detail/bmds-testet-eudi-wallet-im-zusammenspiel-mit-bund-id)
- [Handlungsleitfaden zur Anbindung der EUDI-Wallet – BSI] (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ElekAusweise/Handlungsleitfaden _EUDI-Wallet.pdf? __blob=publicationFile&v=2)
- [EUDI WALLET Prototypes – SPRIND] (https://www.sprind.org/taten/challenges/eudi-wallet-prototypes)
- [European Digital Identity – GitHub] (https://github.com/eu-digital-identity-wallet)
- [EUDI Wallet Reference Implementation – GitHub] (https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md)
- [German National EUDI Wallet: Architecture Documentation] (https://bmi.usercontent.opencode.de/eudi-wallet/wallet-development-documentation-public/v0.0.1/)
- [Banks as natural EUDI Wallet providers: Sparkasse’s game-changing move | Namirial.com] (https://www.namirial.com/en/blog/inspiration/banks-eudiw-providers-sparkasse-move/)
- [Status Management – Blueprint for the EUDI Wallet Ecosystem in …] (https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/content/ecosystem-architecture/PID/status-management/)
- [From AI in Wallets to Wallet for AI Agents | by Thierry Thevenet | Medium] (https://medium.com/@thierry.thevenet/from-ai-in-wallets-to-wallet-for-ai-agents-9f51f16f83d4)
- [ (PDF) Legal Personality of Artificial Intelligence – ResearchGate] (https://www.researchgate.net/publication/385225532 _Legal _Personality _of _Artificial _Intelligence)
- [The EU is right to refuse legal personality for Artificial Intelligence – Euractiv] (https://www.euractiv.com/opinion/the-eu-is-right-to-refuse-legal-personality-for-artificial-intelligence/)

## Frag Logos

0/250Deine Nachricht an den Chatbot ') ; $ ('#lu-ai-chat-history') .scrollTop ($ ('#lu-ai-chat-history') [0] .scrollHeight) ; if (sender === 'bot' && !isRestoring) { if ($ ('#lu-ai-chat-tts-toggle') .hasClass ('active') ) { let cleanText = text.replace (/] *>?/gm, '') .replace (/\*/g, '') ; artyom.say (cleanText) ; } } } // --- INIT & LOAD HISTORY --- var historyData = loadChatFromStorage () ; if (historyData) { // Verlauf vorhanden: Erst Begrüßung rendern $ ('#lu-ai-chat-history') .append ('' + defaultGreeting + ' ') ; // Daten übernehmen fullConversation = historyData; // Dann die gespeicherten Nachrichten anhängen historyData.forEach (function (item) { appendMessage (item.html, (item.role === 'user' ? 'user' : 'bot') , true) ; chatHistory.push ({ role: (item.role === 'user' ? 'user' : 'model') , parts: [{ text: item.text }] }) ; }) ; } else { // Kein Verlauf: Nur Begrüßung rendern $ ('#lu-ai-chat-history') .append ('' + defaultGreeting + ' ') ; } // --- SEND LOGIC --- function sendMessage () { if (isRecording) { clearTimeout (silenceTimer) ; UserDictation.stop () ; isRecording = false; $ ('#lu-ai-chat-mic-btn') .removeClass ('recording') ; } if ($ ('#lu-ai-chat-send-btn') .prop ('disabled') ) return; var message = $ ('#lu-ai-chat-user-input') .val () .trim () ; if (message === '') return; appendMessage (message, 'user', false) ; chatHistory.push ({ role: "user", parts: [{ text: message }] }) ; fullConversation.push ({ role: "user", text: message, html: message }) ; saveChatToStorage () ; $ ('#lu-ai-chat-user-input') .val ('') ; updateCharCount () ; toggleChatState (true) ; var loadingBubbleId = 'lu-ai-loading-bubble-' + Date.now () ; var loadingHtml = ' '; $ ('#lu-ai-chat-history') .append ('' + loadingHtml + ' ') ; $ ('#lu-ai-chat-history') .scrollTop ($ ('#lu-ai-chat-history') [0] .scrollHeight) ; var historyJson = JSON.stringify (chatHistory) ; $.ajax ({ url: 'https://www.dpr-deutschland.de/wp-admin/admin-ajax.php', type: 'POST', data: { action: 'lu _ai _chat _request', message: message, history: historyJson, security: luAiNonce, context _id: contextPostId, custom _context: luAiContext, markdown _url: luAiMarkdownUrl }, success: function (response) { toggleChatState (false) ; var $loadingBubble = $ ('#' + loadingBubbleId) ; if (response.success) { var botResponseHtml = response.data; $loadingBubble.remove () ; appendMessage (botResponseHtml, 'bot', false) ; var cleanBotText = botResponseHtml .replace (/  
/gi, "\n") .replace (/] +>/g, '') ; chatHistory.push ({ role: "model", parts: [{ text: cleanBotText }] }) ; fullConversation.push ({ role: "model", text: cleanBotText, html: botResponseHtml }) ; saveChatToStorage () ; } else { appendMessage ("Fehler: " + response.data, 'bot') ; } }, error: function () { toggleChatState (false) ; appendMessage ("Verbindungsfehler aufgetreten.", 'bot') ; } }) ; } $ ('#lu-ai-chat-send-btn') .click (sendMessage) ; $ ('#lu-ai-chat-tts-toggle') .click (function () { $ (this) .toggleClass ('active') ; var isActive = $ (this) .hasClass ('active') ; $ (this) .attr ('aria-pressed', isActive) ; var icon = $ (this) .find ('i') ; if ($ (this) .hasClass ('active') ) { icon.removeClass ('fa-volume-mute') .addClass ('fa-volume-up') ; if (typeof artyom !== 'undefined') { artyom.say ("Sprachausgabe aktiviert") ; } } else { icon.removeClass ('fa-volume-up') .addClass ('fa-volume-mute') ; if (typeof artyom !== 'undefined') { artyom.shutUp () ; } } }) ; $ ('#lu-ai-chat-user-input') .keypress (function (e) { if (e.which == 13) { if (!$ ('#lu-ai-chat-user-input') .prop ('disabled') ) { sendMessage () ; } } }) ; }) ;

**Wichtiger Hinweis & Haftungsausschluss (Disclaimer) : **Der KI-Assistent „Logos“ ist eine automatisierte Anwendung auf Basis künstlicher Intelligenz und dient ausschließlich Informations- und Unterhaltungszwecken. Die generierten Antworten werden ohne menschliche Kontrolle erstellt und können systembedingt faktisch unrichtig, unvollständig oder veraltet sein („Halluzinationen“) ; eine Gewähr für die Richtigkeit, Vollständigkeit oder Verlässlichkeit der Inhalte wird daher nicht übernommen. Die Nutzung der bereitgestellten Informationen erfolgt auf eigenes Risiko und ersetzt keine professionelle Beratung, etwa in politischen Angelegenheiten. Wir empfehlen dringend, kritische Informationen vor einer Verwendung stets eigenständig zu verifizieren. Die Haftung des Betreibers für Schäden aus der Nutzung ist auf Vorsatz und grobe Fahrlässigkeit beschränkt; hiervon ausgenommen ist die Haftung für Schäden aus der Verletzung des Lebens, des Körpers oder der Gesundheit sowie für die Verletzung wesentlicher Vertragspflichten (Kardinalpflichten) . Änderungen, Einschränkungen oder Ausfälle des Dienstes sind jederzeit vorbehalten.