[EPIC] EUDI Wallet - EAA Ausstellung mit FIT-Connect

Warum

Die durchgängige Kette – von der Attributerzeugung im Fachverfahren bis zur Ablage im Wallet des Bürgers – schafft:

• Rechtssicherheit gemäß eIDAS 2.0 durch standardisierte EAAs
• Prozessbeschleunigung für Behörden und Unternehmen durch Wegfall manueller Nachweis‑ und Prüfprozesse
• Nutzerfreundlichkeit für Bürger:innen, weil Nachweise direkt im Wallet verfügbar sind
• Interoperabilität über FIT‑Connect SDKs, die Implementierungskosten und Integrationsrisiken minimieren

Ziel

Als Fit‑Connect möchte ich Fachverfahren dabei unterstützen, Electronic Attestations of Attributes (EAAs) automatisiert auszustellen, sie per Destination‑API einem Online‑Dienst(oder einem anderen Frontend) bereitzustellen und dort so einzubinden, dass Bürgerinnen und Bürger die EAAs nahtlos in ihr EUDI‑Wallet übertragen können, damit Verwaltungsleistungen medienbruchfrei digital abgeschlossen werden können.

Links, Hinweise, Bemerkungen

• Konzepte: https://git.fitko.de/fit-connect/betrieb/-/blob/concept/eudi-wallet/docs/concepts/3097_eudi_wallet/30_concept.md
• Prozessdiagramme (technischer Ablauf): https://git.fitko.de/fit-connect/betrieb/-/tree/concept/eudi-wallet/assets/concepts/3097_eudi_wallet

User Journey (RV-9):

1. Start & Identifikation: Der Antragsteller startet den Online‑Antrag und meldet sich mit der EUDI-Wallet an. Notwendige öffentliche Schlüssel der Wallet wird an den OD übermittelt.
2. Antragseinreichung: Der Antragstellern füllt das Formular aus und sendet den Antrag ab
3. Weiterleitung an Zustelldienst: Der OD übergibt Antrag und  die Schlüssel von der Wallet an den Zustelldienst, welcher das Fachverfahren (FV) informiert; das FV holt den Antrag ab.
4. Sachbearbeitung: Sachbearbeitende prüfen den Antrag im FV, erstellen den Bescheid und legen die digitale Zustellung für die Wallet fest.
5. Nachweis‑Erstellung: Das Fachverfahren erstellt und verschlüsselt den signierten Nachweis (EAA) mit Hilfe der Schlüssel des Wallets.
6. Versand des Bescheids: Das FV sendet den Bescheid und das EAA über den ZSD zurück an den Online-Dienst (wahrscheinlich zwei Replies)
7. Abruf initiieren: Sobald der User im Online-Dienst sich anmeldet wird der entsprechende QR-Code generiert und dem User angezeigt. Der Nutzer scannt den QR-Code mit seiner Wallet ein und fordert damit den EAA an.
8. Abholung EAA vom ZSD: Online-Dienst holt im ZSD die zweite Submission ab
9. Übermittlung an die Wallet: Der OD liefert den Nachweis an die Wallet des Bürgers, wo er entschlüsselt und gespeichert wird.
10. Abschluss: Der digitale Nachweis liegt nun im Wallet des Bürgers vor und kann nach Bedarf genutzt werden.

Varianten:

1. Onlinedienst für die Generierung des QR-Codes und Abruf des EAAs könnte durch ein eigenes Frontend (mit eigener FIT-Connect destination) ersetzt werden
2. EAA und Bescheid werden in einer statt in zwei Repies abgelegt
3. Generierung des EAAs im FV könnte auch an einen speziellen Service ausgelagert werden, die zum Beispiel in einem komunalen RZ betrieben werden.
4. Alle Aktivitäten könnten auch in Kombination mit der Authentifizierung / ZBP der BundID durchgeführt werden
5. Abruf des EAAs direkt als "Notification an die Wallet" - deffered Endpoints

Stories

1. technischer Durchstich in .NET
   • Login
   • Generierung QR Code
   • Anfrage an das FV über den ZSD über eigene Submission
   • Mockup Bereitstellung des EAAs über eine Reply
   • Abruf der Reply (deferred credential - oder einfacher)
   • Laden der Reply in die Wallet (idealerweise mit allen vier Wallets)
2. Login mit der EUDI Wallet [OD]
3. Übermittlung der Antragsdaten mit den EUDI Wallet Informationen an das FV [OD]
4. Empfang des Antrags, Generierung der EAA und zurücksenden [FV]
   1. als Reply an Sender
   2. (als Submission an andere destination) - spätere Weiterentwicklung
5. Abruf des EAAs [OD]
6. Generierung und Anzeige des QR Codes und Bereitstellung des Endpunktes zum Herunterladen des EAAs [OD]
7. Optimierung E2E Test-Cases und des Online Musterdienstes

Akzeptanzkriterien

1. Login mit der EUDI Wallet
2. Übermittlung der EUDI spezifischen Felder in den Metadaten (keys, Auth, EAA, EAA soll an eine andere Destination und nicht an den OD gesendet werden)
3. Fachdatensatz zur Beantragung und Bereitstellung der Nachweise - oder über Metadaten?
4. QR Code Generierung
5. Generierung der EUDI-Wallet konformen Nachweise inkl. Verschlüsselung (ggf. Entschlüsselung für die Wallet) der Nachweise mit dem public key der Wallet
6. Versand des EAAs
7. Implementierung des deffered Endpoints für die Wallet
8. Empfang des EAAs
9. Szenario ist im Online Musterdienst implementiert
   • Anzeige QR-Code
   • Wallet Endpunkt EAA Download
   • zwei Varianten (Empfang als Reply, Empfang als Submission)
10. Doku ist erstellt
11. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen

offene Fragen

1. EUDI Wallet
   1. RV-05: wird dieses technisch unterstützt (Key-Pair Value beim Antrag erstellen und Nachweis erst nach ein paar Wochen abholen) - ja
   2. RV-06: sinnvoller Timeout beim Abholen der bereits erstellten Antrags - deffered Endpoint ist im Konzept und auch in einem
   3. Verschlüsseln mit dem public Key des Wallets - ja bereits im Standard
2. intern
   1. paralleler Login BundID und Wallet - wird nachgelagert behandelt (sollten eigentlich nur zusätzliche Zusatzschritte sein)
   2. EAA Vermittler in den Onlinedienst integrieren - ja, kann aber auch überall andern betrieben werden (Reply mit EAA dann an andere Destination, wäre in den Metadaten zu berücksichtigen)
   3. muss der Benutzer sich noch beim Abruf der Wallet am Online-Dienst nochmal anmelden? / Infos an FV weiterleiten über die Authentifizierung mit der Wallet (Identification Report) - wahrscheinlich müsste die Wallet Anmeldung auch ans FV durchgereicht werden - ja (Identification Report in dem Kontext auch zurückstellen)
   4. Login und Bescheidzustellung über BundID auch optional anbieten - zurückgestellt
   5. wird EAA als eigene Reply/Submission versendet, oder mit in anderen Daten verpackt (zwei Submissions) EAA als Anhang und Metadaten? - wir starten mit dem Ansatz, dass eine Submission für den Antrag und eine für den Abruf des EAAs rausschicken - der EAA soll nur als Reply zurückgehen (vorsehen, dass es aber mit Prozessunterstützung an eine andere destination als neue submission rausgehen könnte)
   6. deferred Endpoint in den Prozess integrieren (bereits bei der Antragsstellung?) - ja, aber nicht für den ersten PoC
3. Nachgelagert
   1. EAA Issuer als nachgelagerter Service
   2. Zentraler EAA Vermittler von uns betrieben
   3. Synchroner ZSD