NOOTS und EUDI Wallet: Digitale Nachweise als Softwareprojekt

Bürgerinnen und Bürger müssen dem Staat häufig Informationen nachweisen, die an anderer Stelle bereits vorliegen. Im Rahmen von Deutschland, was geht? möchten wir einen anderen Ablauf erproben: vorhandene Daten zuerst berücksichtigen, nur Fehlendes erfragen und Entscheidungen nachvollziehbar machen. Jana hat unsere Teilnahme am von SPRIND und BMDS getragenen Prototypenprogramm öffentlich angekündigt.

Ein Prototypvorhaben, keine produktive Verwaltungsinfrastruktur

Der angekündigte Ansatz sieht NOOTS für den Datenabruf und die EUDI Wallet für digitale Nachweise als mögliche Bausteine vor. Das ist eine Entwicklungsrichtung, kein Nachweis einer bereits produktiven Anbindung. Welche Schnittstellen zugänglich sind, welche Teile sich real testen lassen und welche rechtlichen Voraussetzungen gelten, muss im jeweiligen Verfahren geklärt werden. Eine technische Möglichkeit schafft keine Befugnis zum Registerzugriff.

Datenabruf und Wallet erfüllen unterschiedliche Aufgaben

NOOTS und EUDI Wallet sind nicht austauschbar. Die Idee hinter NOOTS ist hier der Abruf vorhandener Nachweise; die Wallet betrifft unter anderem das Vorlegen digitaler Identitätsdaten oder Attribute durch Nutzer. Die Anwendung muss darüber hinaus den fachlichen Kontext, erforderliche Angaben und die Regeln des Verfahrens abbilden. Ein gültiger Nachweis ist noch keine vollständige fachliche Entscheidung.

Was eine EUDI-Integration für die Anwendung bedeutet

Das offizielle deutsche Ecosystem Knowledge Center unterscheidet unter anderem Person Identification Data (PID) und Electronic Attestations of Attributes (EAA). Organisationen können je nach Rolle Nachweise ausstellen oder als Relying Party prüfen. Deshalb beginnt die Integration mit einem konkreten Anwendungsfall: Welche Information wird benötigt, von wem darf sie stammen und welche Aktion darf daraus folgen?

Die interessanten Fragen liegen zwischen den Bausteinen

• Welche Daten sind erforderlich, und welche dürfen gerade nicht erhoben oder protokolliert werden?
• Wie behandelt die Anwendung fehlende, veraltete oder widersprüchliche Informationen?
• Welche Vertrauensgrundlagen und Gültigkeitsprüfungen gelten für den konkreten Nachweis?
• Wie lassen sich Herkunft, fachliche Regel und Ergebnis erklären, ohne sensible Inhalte unnötig offenzulegen?
• Wann muss ein Mensch prüfen, korrigieren oder entscheiden?

Nachvollziehbare Entscheidungen brauchen explizite Regeln

Identifizierung, Prüfung eines Nachweises und die Entscheidung über einen Anspruch sind unterschiedliche Schritte. Ein Sprachmodell darf diese Trennung nicht verwischen. Wenn KI in einer Anwendung unterstützt, muss klar sein, ob sie erklärt, Daten vorbereitet oder eine begrenzte Aktion anfragt. Die technische und fachliche Berechtigung dieser Aktion bleibt Aufgabe des Systems und der zuständigen Verantwortlichen.

Offen entwickeln heißt auch Grenzen zeigen

Janas Ankündigung verbindet das Vorhaben mit dem Anspruch, Fortschritte und Schwierigkeiten öffentlich zu teilen. Daran möchten wir die weiteren Beiträge ausrichten: konkrete Integrationsschritte, offene Annahmen und nachvollziehbare Tests statt einer vorweggenommenen Erfolgsgeschichte. Eine Sandbox-Erprobung ist nicht mit Produktivbetrieb oder Zertifizierung gleichzusetzen. Dieser Beitrag beschreibt Motivation und Entwurfsfragen, keinen abgeschlossenen Integrationsbericht.

Technische Orientierung

Für die konkrete Umsetzung sind der aktuelle deutsche Developer Guide und das europäische Architecture and Reference Framework wichtige Ausgangspunkte. Protokollprofile und Rollout-Stände entwickeln sich weiter; eine Integration muss ihre tatsächlich verwendeten Versionen und Prüfungen benennen.