EUDI Wallet eIDAS2 Architektur

Ich möchte mein konstruktives Feedback zum OpenCode Repo und der EUDI Wallet eIDAS2 Architektur einfliessen lassen:

Der Weg zum öffentlichen und transparenten Konsultationsprozesses für ein Wallet Konzept stimmt.

Folgendes ist mir aufgefallen:

In der aktuellen Architekturversion ist Option B mit Varianten dargestellt, die Informationen was Option A ist war fehlen in Readme.md · main · BMI / eIDAS2 · GitLab
Das ist durchaus auch nachträglich relevant um Entscheidungen nachzuvollziehen.

Video Artefakte wie https://gitlab.opencode.de/bmi/eidas2/-/commit/fd45a48bea8d46a175ca0838e707cc61715c7160#71f9f5159cd78659ed40f737efb6694f66f4a0c9 erhöhen das Vertrauen und machen vor allem die Vorgehensweise gut nachvollziehbar. :+1: Leider ist der Inhalt in weiten Teilen akustisch nicht verständlich; Inhalte der Whiteboards werden nicht gezeigt. Auch wenn dies letztlich von 20231023_EUdi-Wallet_Workshop_Business_and_Issuance_Models_Outcomes_v1.0.pdf kompensiert wird, wäre es fantastisch, wenn zukünftige Medien optimiert sind. :hugs:

Ein paar Artefakte fehlen im kopierten Git Repo, Beispiel: „modules_overview.png“ did not exist on „main“ in Files · main · BMI / eIDAS2 · GitLab

Last but not least ist das GitLab nur eine Kopie einer anderen Instanz und wird somit bislang noch nicht im Sinne eines Git zur transparenten Versionierung genutzt…

Die unter Readme.md · main · BMI / eIDAS2 · GitLab aufgeführte Zeitschiene liegt in der Vergangenheit und reicht nur bis zum 30.11.2023.

Bitte die Meilensteine - selbst wenn diese noch nicht terminiert sein sollten - in der Tabelle auflisten und minimal mit Q1/2024, Q/2024 usw. auflisten und natürlich bekannte Termine frühzeitig dort aktualisieren.

Es handelt sich um ein Git basiertes Repository und dementsprechend sollte es auch genutzt als Single Source of Truth werden.

Wenn Informationen von dort ausgeleitet werden, beispielsweise auf die Website des BMI oder Sprin-D, dann sollten die Informationen orginär immer zuerst innerhalb des Repos aktualisiert und dann von dort verteilt werden.

So ist gewährleistet, dass alle Beteiligten mit identischen Informationen versorgt sind.

Mein Fehler: Option A ist im Zusammenhang mit Abbildung 3 erwähnt, und wurde verworfen, da diese Lösung potenzielle Datenschutzprobleme nach sich zieht, indem sie dem PID-Anbieter erlaubt, den Ort der Präsentation der PID zu beobachten. Das stellt ein Risiko in punkto Privatsphäre der Benutzer dar, da Anbieter potentiell verfolgen können, bei welchen Diensten oder Organisationen ein Benutzer seine Identität nachweist.

Was auch immer das sein mag - Security by obscurity oder Bug oder schlicht vergessen…

Der Prozess ist nicht transparent, sondern es werden lediglich nachgelagert getroffene Entscheidungen minimal zugänglich gemacht.

Das eudi doc architecture reference framework wird auf GitHub geführt (ziehe ich persönlich dem eventuellen Vendor Login sogar vor) während der „Architecture Proposal for the German eIDAS Implementation“ unter architecture-proposal.md · main · BMI / EUdi-Wallet / eIDAS 2.0 Architecture Concept · GitLab geführt wird.

Die entscheidenden Fragen hierbei:

  1. Warum nicht EINE Single Source of Truth?
  2. Wo ist das Konsultationsteam mit seinen Mitgliedern und die Organisationen dahinter transparent und leicht zugänglich?

Was ist zu tun?
Wenn das BMI / SPRIND weiterhin GitLab nutzen und somit bereits zusatzliche Aufwände und somit Kosten im Abgleich des eudi doc architecture reference framework entstehen, dann müssen BMI / SPRIND und alle 3rd Parties gewährleisten, dass der GitLab basierte Prozess dieselben Funktionen wie GitHub nutzt. Stand 12. März 2024 - 15:42 sind wir weit davon entfernt.

Vielmehr repräsentiert das GitLab unter Federführung von BMI / SPRIND nur einen Timestamp basierten Snapshot.

Eine basisdemokratische Partizipation wird somit verhindert. Das kostet Zeit und Geld, denn die Mitwirkung der Öffentlichkeit ist begrenzt.

Feedback ist sowohl zeitlich - auf die wenigen Konsulationsverfahren begrenzt und es entsteht der berechtigte Eindruck, dass dies ganz bewusst geschieht. Das Warum ist an dieser Stelle nicht ausschlaggebend. Vielmehr mangelt es weiterhin an einer sektorübergreifenden Digitalisierungsstrategie, die durch dieses Vorgehend verhindert wird. Damit werden öffentliche Mittel nicht effizient eingesetzt und es besteht ein nennenswertes Risiko dass die Projektziele unzureichend oder zeitverzögert erreicht werden.

Beim BSI PersoSim Workshop beim BSI in Bonn habe ich meine Forderung für ein webbasierten Verfahren mit einer Single Source of Truth und maschinenlesbaren Informationen wiederholt.

Die Teilnehmer des BSI PersoSim Workshop haben das als berechtigten Wunsch quittiert, es fühlt sich aber weiterhin niemand zuständig genau das zu ermöglichen.
Dabei ist es möglich und mit dem eudi doc architecture reference framework ist nachvollziehbar wie das gelingen kann.

Alle Organisationen - geführt von BSI, BMI, BfDI - sollten hier an einem gemeinsamen Strang ziehen um diesen digitalen Weg zu ermöglichen.

In einer Initiative mit der gematik haben wir mit prototypischer Vorgehensweise einen MVP realisiert und mit https://gemspec.gematik.de/ bereits begonnen genau das möglich zu machen.

Warum digitalisieren wir nicht sektorübergreifend?
Das BSI hat exakt denselben Bedarf die Informationen die aktuell in zig PDFs schlummern maschinenlesbar zu machen.

Die Sourcen des erweiterten Markdown sind hier: