Servicestandard-Bericht

Selbstaudit des Teams über die Anwendung des Servicestandards, herausgegeben vom Bundesministerium des Innern und für Heimat

BundesIdent erfüllt in 15 von 19 Punkten den Servicestandard. Zwei Punkte wurden teilweise erfüllt, während zwei weitere nicht zutreffend waren.

Status: erfüllt

Zusammenfassung:

• Ab Projektstart: regelmäßige Einbindung der Nutzenden und Mitarbeitenden aus der Verwaltung in den Gestaltungs- und Entwicklungsprozess
• Methoden: u. a. qualitative Tiefeninterviews, quantitative Online-Umfragen, Pop-Up-Research, A/B Tests, produktintegrierte Feedback-Umfrage, Analyse von Supportanfragen und App-Reviews, Fokusgruppe, Sekundäranalyse, Analytics sowie Konzept- und Usability-Tests in verschiedenen Stadien der Produktentwicklung
• Im gesamten Prozess wurden insgesamt 97 (potenzielle) Nutzer:innen durch Interviews und Usability-Tests sowie 2313 Personen über Online-Umfragen und -Formulare einbezogen

Begründung:

Die Online-Ausweisfunktion hat großes Potenzial, zeitsparend und effizient den Verwaltungskontakt für Bürger:innen zu minimieren. Bisher wurde die Online-Ausweisfunktion jedoch kaum genutzt. Die Synthese aus Sekundäranalyse und Primärforschung zeigte, dass es Hindernisse beim initialen Aufsetzen gibt, die geringe Anzahl an Anwendungsfällen und inkonsistente Nutzerführung über die gesamte User-Journey hinweg die Nutzerakzeptanz gering hält.

Daher beschloss das Team, die vielfältigen Vorarbeiten in einer designorientierten Synthese zusammenzuführen, Forschungslücken durch ergänzende qualitative und quantitative Analysen zu schließen, die identifizierten Hürden und Anwendungsfälle klar zu beschreiben und aus Nutzersicht zu priorisieren. Danach folgten die iterative Entwicklung erster Lösungskonzepte und deren Umsetzung. Die Analysephase gliederte sich wie folgt:

• Phase 1: Kontext erfassen und Problem verstehen
• Phase 2: Ideation mit Nutzer:innen und Stakeholdern (u. a. mit BSI, BMI, BVA)
• Phase 3: Priorisierung und Entwicklung Proof-of-Concept.

1. Kontext erfassen und Problem verstehen
   Zunächst wurde eine umfangreiche Recherche zu Haltung, Wahrnehmung und Gewohnheiten der Bürger:innen rund um die eID-Funktion des Personalausweises durchgeführt. Grundlage für die Auswahl der Interviewteilnehmenden bildeten die Nutzertypen des eGovernment Monitor. Mithilfe von Sekundäranalyse und qualitativen Tiefeninterviews wurden Hürden, aber auch Motivationsfaktoren identifiziert. In einer Online-Befragung wurden zusätzlich 1315 Teilnehmende befragt. So konnten die Nutzergruppen identifiziert und anhand der eID-Nutzungshäufigkeit, -einstellung und -motivation beschrieben werden.

2. Ideation mit Nutzer:innen und Stakeholdern
   Problemfelder wurden mithilfe der Recherche identifiziert und Lösungskonzepte, Prototypen und jede Stufe der Entwicklung eines Minimal Viable Product (MVP) durch Feedback von Nutzer:innen getestet. Die ersten Anforderungen wurden mit 20 Tiefeninterviews mit vorhandenen und potentiellen Nutzer:innen, sechs Interviews mit Bürgerbüros und Verwaltungen, einem Besuch im Bürgerbüro, Interviews mit Expert:innen relevanter Organisationen sowie einer Fokusgruppe zum Thema Kommunikation erhoben. Das MVP sowie dazugehörige Produktentscheidungen wurden mit weiteren 71 Nutzer:innen in Usability-Tests sowie durch Pop-Up-Research getestet.

3. Priorisierung und Entwicklung Proof-of-Concept
   Für die Nutzung der eID müssen Voraussetzungen erfüllt sein, wie das Vorliegen eines eID-fähigen Personalausweises, eines NFC-fähigen Smartphones und einer gesetzten PIN. Ziel des stetigen Kontakts mit Nutzer:innen war es, die Bedienbarkeit von BundesIdent im Beta-Stadium optimal an die Bedürfnisse, Kenntnisse und Fähigkeiten der Zielgruppe anzupassen und insbesondere die Ersteinrichtung zu unterstützen. Die erhobenen Anforderungen für das Produkt enthielten Anforderungen, die zwingend benötigt wurden, sowie Wünsche, die über das unbedingt Notwendige hinausgingen. Die erhobenen Anforderungen an das Produkt wurden priorisiert und in die notwendigen Basisfunktionen umgesetzt. Über diese Mindestanforderungen hinausgehende Funktionen wurden aggregiert, synthetisiert und in Form von Prototypen in späteren Nutzendentests evaluiert. Die Schritte der Weiterentwicklung wurden durch das reale Nutzungsverhalten informiert und entsprechend datengetrieben priorisiert.

Status: erfüllt

Zusammenfassung:

• Gestaltung durch Designer:innen als Expert:innen für gängige Bedienmuster
• Erarbeitung von Serviceprinzipien, z. B. „Einfache Entscheidungsfragen anbieten für eine stringente Führung der Nutzer:innen“
• Vereinfachung des User-Flows unter Berücksichtigung geltender Regulatorik
• Kommunikation der Nutzungsvoraussetzungen im Online-Service „Grundsteuererklärung für Privateigentum“ sowie in BundesIdent
• Regelmäßige Usability-Tests mit der Zielgruppe

Begründung:
Einfache und intuitive Nutzung ist eines der obersten Ziele für alle Produkte des DigitalService. Die Servicekomponenten wurden von Designer:innen entworfen sowie regelmäßigen Usability-Tests (siehe Prinzip 1) unterzogen, auch in den Produktiterationen nach dem Go-Live des Piloten. Die Designer:innen sind ausgebildet und sensibilisiert dafür, Dienste zu entwickeln, die für alle Bürger:innen nutzbar sind und sich an konventionellen Bedienmustern orientieren. Gleichzeitig ist das deutsche eID-Ökosystem stark reguliert, sodass zahlreiche technische sowie die Benutzeroberfläche betreffende Anforderungen bestehen. Die Einhaltung der Richtlinien war ebenso entscheidend wie eine Vereinfachung des User-Flows an so vielen Stellen wie möglich. So konnte beispielsweise das doppelte Scannen des Ausweises in dem User-Flow von BundesIdent durch einen einmaligen Scan ersetzt werden (Service Map).

Bereits vor dem Start der Identifizierung wurden Nutzer:innen informiert, dass die App heruntergeladen werden muss. Wesentliche Voraussetzungen wurden bei Erstnutzer:innen abgefragt: das Vorliegen einer Ausweis-PIN oder eines PIN-Briefs. Fehlermeldungen wurden zu aussagekräftigen Hinweisen iteriert.

Für die Erarbeitung von Serviceprinzipien wurden erfolgreiche User-Flows zur Identifizierung in der Privatwirtschaft sowie in internationalen Verwaltungsbeispielen betrachtet. Ein Beispielprinzip ist das Anbieten mehrerer einfacher Entscheidungsfragen für eine stringente Führung der Nutzer:innen statt einer Informationsüberlastung durch das Anzeigen zahlreicher Handlungsoptionen.

Das Team war über mehrere Kanäle für Feedback zu erreichen: über eine Kontakt-E-Mail für Support, eine integrierte Feedback-Umfrage sowie Bewertungsabgaben im App-Store und Kommentarfunktionen sowie Pull Requests auf GitHub. Eine Alternative zur digitalen Identifizierung und Einrichtung ist stets die analoge Nutzung der Services, z. B. durch eine Vorstellung im Bürgeramt.

Das Erreichen einer einfachen und intuitiven Nutzung war stets das oberste Ziel von BundesIdent. Im Rahmen der Möglichkeiten, die während einer Pilotierung zur Verfügung stehen, wurde dieses Ziel erreicht – eine durchgängig einfache und intuitive Nutzung wie für den eigentlichen Roll-out geplant, konnte jedoch nicht vollständig erreicht werden. Die erzielten Erkenntnisse wurden veröffentlicht.

Status: teilweise erfüllt

Zusammenfassung:

• Einfache, bürgernahe Sprache war ein Ziel bei der Entwicklung von BundesIdent
• Berücksichtigung wichtiger Aspekte der Barrierefreiheit, z. B. Farbkontraste und adäquate sowie leicht zugängliche Inhalte
• App verfügbar auf Deutsch und Englisch
• Technisch nicht optimal umgesetzte Aspekte sollten in der Weiterentwicklung berücksichtigt werden
• Erste Evaluation und Beratung des Piloten durch externe Expert:innen
• Kein vollständiger offizieller Test gemäß BITV 2.0
• Erklärung zur Barrierefreiheit in der App sowie Aufforderung an Nutzende, Feedback zu geben

Begründung:
Eine breitflächige Zugänglichkeit und insbesondere Barrierefreiheit hat im DigitalService einen hohen Stellenwert, sodass im Team immer wieder intensiv zu diesem Thema diskutiert wurde, externe Expertise dazugeholt und erste Maßnahmen umgesetzt wurden. Obwohl das Produkt noch in einem Testbetrieb war, wollte das Team die Barrierefreiheit bestmöglich gewährleisten sowie vorhandene Defizite des Piloten transparent machen.

Dazu wurde zum einen eine Selbstbewertung auf Basis des aktuellen Entwurfs der Barrierefreien-Informationstechnik-Verordnung (BITV 2.0) für mobile Apps sowie auf Basis der Web Content Accessibility Guidelines (WCAG) für das Web-Widget durchgeführt. Hierbei wurden zahlreiche Maßnahmen zur Barrierefreiheit, Bürgernähe und Genderneutralität umgesetzt. Darüber hinaus hat das Team eine Schnellcheck-Bewertung des externen Anbieters TWIN CUBES GmbH für die App durchführen lassen. Die Ergebnisse des Schnellchecks wurden bestmöglich, aber nicht vollumfänglich umgesetzt. Eine umfangreiche externe Auditierung der Servicekomponente war geplant und wurde nur im Rahmen der Pilotierung noch nicht umgesetzt.

Eine einfache, bürgernahe Sprache war ein Kernelement in der Entwicklung eines nutzungsfreundlichen eID-Clients. Darauf wurde im Laufe der Weiterentwicklung großen Wert gelegt und immer wieder mit der Zielgruppe und mithilfe einer Expertin für UX-Writing getestet, ob die Formulierungen im Identifizierungsdienst verständlich waren. In der Gestaltung wurden weitere Punkte berücksichtigt, beispielsweise hat das Team Farbkontraste auf ausreichende Barrierefreiheit angepasst, Textgrößenanpassungen durch Nutzende korrekt im User-Interface abgebildet und die Verwendung einer externen Tastatur und beispielsweise auch Screen-Reader-Funktionalität unterstützt. Weiterhin hat sich das Team an die gängigen Vorgaben zu Mindestgrößen von Bedienelementen gehalten. Die App war auf Deutsch und Englisch verfügbar.

Nicht alle technischen Aspekte konnten in der App im Rahmen der Pilotierung ausreichend berücksichtigt werden. Dies umfasst beispielsweise das Fehlen eines Dark-Modes oder des Querformats in der App. Zudem fehlten Erläuterungen in Leichter Sprache und Gebärdensprache.

Die weiteren Schritte zur Umsetzung waren geplant. In der App haben wir eine „Erklärung zur Barrierefreiheit“ veröffentlicht, in der auch eine E-Mail mit Aufforderung zum Feedback bereitgestellt wurde. Nutzer:innen konnten per E-Mail oder in den Umfragen zur Zufriedenheit Feedback geben, das in der Weiterentwicklung des Dienstes berücksichtigt wurde.

Das eID-System ist aufgrund der vielen technischen und organisatorischen Anforderungen nur sehr eingeschränkt barrierefrei und inklusiv. Beispielsweise ist das Vorliegen bestimmter Ausweisdokumente erforderlich, wobei ca. 10 Millionen Menschen in Deutschland diese nicht besitzen. Nicht alle Bürger:innen sind digital affin und besitzen ein NFC-fähiges Smartphone oder ein passendes Kartenlesegerät. Menschen mit motorischen Einschränkungen haben große Probleme beim Scanning-Vorgang des Ausweises, oder können diesen gar nicht erst selbständig durchführen. Hierzu hatte uns eine querschnittsgelähmte Person im Support kontaktiert. Im Sinne einer inklusiven Bereitstellung einer digitalen Identität sind diese Barrieren unbedingt zu adressieren und minimieren.

Status: nicht zutreffend

Zusammenfassung:

• Bei der Identifizierung mit Online-Ausweisfunktion ist das Once-Only-Prinzip nicht zutreffend

Begründung:
Wenn eine Identifizierung mit der Online-Ausweisfunktion für einen Service erforderlich ist, ist basierend auf rechtlichen Grundlagen das explizite Auslesen bestimmter Daten auf hohem Sicherheitsniveau erforderlich, die eben nicht durch bereits vorab eingeholte Daten ersetzt werden können.

Ein Serviceanbieter, wie z. B. der Online-Service „Grundsteuererklärung für Privateigentum“, hat ein Zertifikat des Bundesverwaltungsamtes erhalten, welches die Datenpunkte festschreibt, die der Serviceanbieter basierend auf der jeweiligen rechtlichen Grundlage auslesen darf. Für die Grundsteuererklärung muss der Service beispielsweise die Adresse der einreichenden Person sicherstellen und ist so durch das Zertifikat berechtigt, den Namen und die Adresse auszulesen.

Eine Abfrage aus bestehenden Registern ist für eine erforderliche Identifizierung nicht zutreffend.

Status: erfüllt

Zusammenfassung:

• Datensparsame Entwicklung hatte oberste Priorität insbesondere auch bei Tracking und Umfragemaßnahmen
• Keine Verarbeitung personenbezogener Daten beim Identifizierungsvorgang
• Beratung durch externen Datenschutzbeauftragten
• Veröffentlichung des Codes zur öffentlichen Überprüfung
• Austausch mit dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit sowie dem Bundesinstitut für Sicherheit in der Informationstechnik zur Validierung des Vorgehens

Begründung:
Um den Anforderungen der Datenschutz-Grundverordnung (DSGVO) und des Bundesdatenschutzgesetzes (BDSG) gerecht zu werden, hat sich das Team explizit dafür entschieden, so datensparsam wie möglich vorzugehen.

Basierend auf dem standardisierten Auslesevorgang der Ausweisdaten gemäß den technischen Richtlinien des Bundesinstituts für Sicherheit in der Informationstechnik (BSI) wurden beim Auslesevorgang der Ausweisdaten durch die BundesIdent App keine personenbezogenen Daten verarbeitet. Wir hielten uns bei der Entwicklung an die Richtlinien und bauten auf bestehenden, zertifizierten Komponenten für den eID-Kernel auf. Die Identifizierungsdaten erhält lediglich der Serviceanbieter direkt – in unserem Fall der BundesIdent Testservice: ein Online-Service zur Abgabe der Grundsteuererklärung („Grundsteuererklärung für Privateigentum“). Hierzu waren wir stets im Austausch mit dem BSI. Zur Überprüfbarkeit wurde zudem der Code stets veröffentlicht.

Das Vorliegen personenbezogener Daten wurde im Bezug auf Tracking und Umfragemaßnahmen sowie im Support geprüft. Die Hinweise zum Umgang mit personenbezogenen Daten im Kunden-Support waren in der Datenschutzerklärung zu finden. Es wurden nur für die gezielte Weiterentwicklung unmittelbar notwendige Daten erhoben. Deshalb entschieden wir uns gegen ein nutzerbasiertes Tracking, sodass nicht das Nutzerverhalten einzelner Personen, sondern lediglich beispielsweise aggregierte Klickzahlen sichtbar waren. Hierzu waren wir mit dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) im Gespräch zur Herstellung der Transparenz. Die Erkenntnisse aus Tests mit Nutzer:innen wurden stets anonymisiert verschriftlicht und aggregiert. In Umfragen gingen wir ähnlich vor, analysierten lediglich Rückmeldungen ohne Personenbezug. Bei diesen Maßnahmen wurde stets der externe Datenschutzbeauftragte des DigitalService Björn Stecher einbezogen.

Status: teilweise erfüllt

Zusammenfassung:

• Kommunikation der Vorteile von BundesIdent gegenüber anderen Identifizierungsoptionen auf der Auswahlseite
• Abfrage der Voraussetzung, dass eine PIN bzw. ein PIN-Brief zur Nutzung vorliegen muss, bevor die Nutzer:in den User-Flow mit BundesIdent beginnt
• Bürgernahe Formulierungen, die regelmäßig mit Zielgruppe getestet wurden
• Einbindung in das Entwicklungsportal der FITKO war in Vorbereitung
• Alternativen zur Identifizierung waren in der Grundsteuerklärung gegeben

Begründung:
Grundsätzlich ist die potenzielle Nutzerbasis hoch: 2020 besaßen über 60 Millionen Deutsche einen Ausweis mit Online-Ausweisfunktion, ca. 30 Millionen haben diese aktiviert. Dennoch liegt die tatsächliche Nutzung laut Studie des eGovernment Monitor bei nur 8-10 Prozent. Deshalb war die Kommunikation der Vorteile der Online-Ausweisfunktion wichtig: Erstnutzer:innen wurden durch Erklärungen an die Online-Ausweisfunktion herangeführt. In der „Grundsteuerklärung für Privateigentum“ wurde die Identifikation mit dem Ausweis hervorgehoben und insbesondere die Schnelligkeit des Prozesses für die Nutzer:innen betont, welche die Online-Ausweisfunktion bereits kennen. Für Erstnutzer:innen wurde schwerpunktmäßig ein Einrichtungs-Flow in der App erarbeitet, der die Nutzer:innen gezielt führt.

Vor dem Start in den Identifizierungs-Flow wurden die wesentlichen Voraussetzung abgefragt: das Vorliegen einer Ausweis-PIN bzw. dem PIN-Brief zur Einrichtung. So wurden die Nutzer:innen auf den Prozess vorbereitet und nicht mit Potenzial zum Scheitern in den User-Flow geschickt. Um einer möglichen Frustration weiterhin vorzubeugen, war alternativ eine Identifizierung mit dem ELSTER-Zertifikat oder durch Bestellung eines Freischaltcodes per Post möglich.

Die Durchführung regelmäßiger Nutzertests ermöglichte eine kontinuierliche Verbesserungen des gesamten User-Flows und wurde unter Berücksichtigung des aggregierten Nutzerfeedbacks angepasst. Dies bezog sowohl die Beschreibungstexte, Illustrationen, als auch die Benennung der Servicekomponente ein.

BundesIdent ist als Identifizierungskomponente nur innerhalb eines konkreten Diensteanbieters für Nutzer:innen sinnvoll. Deshalb stand eine eigenständige Auffindbarkeit des Services nicht im Zentrum des Piloten. Ausschließlich zur Erleichterung des Kundensupports wurde eine FAQ-Seite öffentlich bereitgestellt. Die Einbindung in das Entwicklungsportal der FITKO war vorbereitet.

Status: erfüllt

Zusammenfassung:

• Sammlung von UX-Hürden und Ideen im Bezug auf mögliche Ansatzpunkte zur Änderung der technischen eID-Richtlinien sowie der Personalausweisverordnung
• Veröffentlichung der UX-Hürden und Ideen

Begründung:
Die Nutzung des deutschen eID-Systems ist durch die technischen Richtlinien des BSI definiert. Somit war die Umsetzung der technischen Richtlinien auch handlungsleitend in der Produktentwicklung von BundesIdent. Durch die praktische Produktentwicklung und das reale Nutzerfeedback haben wir erste Ideen für Ansatzpunkte zur Minderung von UX-Hürden identifiziert, die zur Verbesserung des Nutzungserlebnisses beitragen könnten (Liste von UX-Hürden und Ideen als PDF zum Download). Es ist zu prüfen, welche davon umgesetzt werden sollten und entsprechend Anpassungen in den technischen Richtlinien sowie der Personalausweisverordnung erforderlich machen.

Diese Ideen für mögliche Anpassungsbedarfe wurden an das BSI sowie BMI übergeben.

Status: erfüllt

Zusammenfassung:

• Anwendung und Adaption agiler Methoden, z. B. Scrum-Framework und iterative Produktentwicklung
• Anwendung von Design-Thinking-Methoden
• Interdisziplinäres Team, das Projekt- und Produktentscheidungen gemeinsam trifft

Begründung:
Zur Umsetzung des Projektvorhabens hat das Team des DigitalService mit etablierten agilen Methoden gearbeitet. Das bedeutete auch: Es gab kein Lastenheft oder vorgegebene Lösungen, sondern es wurden die am höchsten priorisierten Probleme der Nutzer:innen bearbeitet, sodass ein Prototyp für Lösungsideen getestet und dieser iterativ weiterentwickelt werden konnte.

So entstand in fünfmonatiger Entwicklung mit Hilfe von Design-Thinking-Methoden, basierend auf den ausführlichen Recherchevorarbeiten der Discovery-Phase, sowie einer agilen Vorgehensweise (z. B. Iterationen basierend auf neuen Erkenntnissen) ein MVP, das im DevOps Modell kontinuierlich weiterentwickelt wurde.

Basierend auf dem Scrum-Framework gab es kurze Entwicklungszyklen von zwei Wochen mit Standups, Plannings, Refinements, Reviews und Retros. Auch die Stakeholder:innen waren zu den regelmäßigen Nutzertests und Produkt-Reviews eingeladen.

Das Team bündelte sämtliche Verantwortlichkeiten zur Produktentwicklung, sodass keine langwierigen Abstimmungen über Entwicklungsphasen erforderlich waren. Vertreten waren die Rollen: Projektleitung, Designer:innen, Kommunikationsexpertin, Support Agent, Produktmanager:innen, Growth Manager, Entwickler:innen für App, Backend und Web-Interface.

Diese interdisziplinäre Zusammenarbeit ermöglicht die schnelle, iterative Entwicklung mit Nutzerzentrierung. Produktanpassungen wurden schnellstmöglich live genommen. Änderungen an Diensten und Web-Interface wurden mittels Continuous Deployment direkt nach erfolgreichen Tests, gegebenenfalls mehrmals täglich, in das Produktivsystem übernommen. Dei der App wurden neue Versionen meist monatlich gepusht.

Das Team hat regelmäßige Retrospektiven sehr ernst genommen und konnte daraus ableiten, was beibehalten werden sollte und wie die interne Zusammenarbeit besser funktionieren kann. Mitarbeitende aus den Bereichen Produktmanagement, Design und Software-Entwicklung waren an jedem Schritt der Entwicklung beteiligt und konnten ihre Sichtweisen und Ideen einbringen. Die Entscheidungen des Teams wurden für die Projektpartner:innen transparent gespiegelt, ebenso wie die Meinungen und Wünsche der Projektpartner:innen im Team geteilt wurden.

Zu dem Produkt gab es eine offene Kommunikation mit Landesministerien und Services der Länder sowie anderen Behörden, da sie die Anbieter der Dienste sind, in denen Bürger:innen sich identifizieren müssen.

Status: nicht zutreffend

Begründung:
Eine Einbindung in Bundes- und Länderportale anzustreben, hatte aufgrund des frühzeitigen Beta-Stadiums des Produkts noch keinen Mehrwert gestiftet und wurde deshalb noch nicht begonnen.

Status: erfüllt

Zusammenfassung:

• DigitalService Team interdisziplinär aus Produktmanger:innen, Designer:innen und Entwickler:innen sowie Growth Manager, Research- und Kommunikationsexpertin zusammengesetzt
• Einbeziehung von Fachexpertise und reger Austausch im Ökosystem (neben Ministerialvertreter:innen aus BMI, BMDV, BK, BMJ und BMF auch u. a. BSI, BVA, FITKO, privatwirtschaftlichen und zivilgesellschaftlichen Akteur:innen)
• Regelmäßige und transparente Abstimmungen mit Stakeholder:innen

Begründung:
BundesIdent (Beta) wurde innerhalb des interministeriellen Vorhabens GovLabDE Digitale Identitäten umgesetzt. Aufgrund dieses Set-ups des Projekts war der regelmäßige ressortübergreifende Austausch institutionalisiert.

Das interne Team des DigitalService vereinte unterschiedliche Disziplinen: Produktmanagement, Design und Software-Entwicklung sowie Growth Management, User Research und Kommunikation. Die erfolgreiche Nutzbarmachung vielfältiger Expertisen, auch über die internen Kenntnisse hinaus, ist zentral für die erfolgreiche Produktentwicklung bei einer derart komplexen Thematik.

Die offene und kollegiale Zusammenarbeit im Ökosystem der digitalen Identitäten und des eID-Systems war entscheidend: der regelmäßige Austausch mit dem BMI, dem BSI und den zahlreichen anderen Beteiligten wie dem Bundesverwaltungsamt (BVA), der Föderalen IT-Kooperation (FITKO), der Governikus GmbH und der Bundesdruckerei Gruppe. Aber auch mit Vertrauenspartnern der Wirtschaft, Zivilgesellschaft sowie internationalen Playern haben wir uns vernetzt, z. B. Adesso, der ukrainischen App Diia, ID Austria und der internationalen Digital Identity Working Group des GovTech Singapore.

Zu dem Produkt gab es eine offene Kommunikation mit Landesministerien und Services der Länder sowie anderen Behörden, da sie die Anbieter der Dienste sind, in denen Bürger:innen sich identifizieren müssen.

Status: erfüllt

Zusammenfassung:

• Aufsetzen auf bereits beauftragte und entwickelte Komponenten des Bundes
• Planung der gemeinsamen Weiterentwicklung mit BMI, BSI und Governikus

Begründung:
Das BMI verantwortet die Basiskomponente zur Identifizierung inkl. der bestehenden Produkte wie z. B. AusweisApp2 (AA2) und BundID. BundesIdent wurde basierend auf dem AA2 SDK (Software Development Kit) von Governikus entwickelt und hat hier also ohne Enwicklungsabhängigkeit auf den Open-Source-Code aufgebaut. Ein kleines Team konnte so unabhängig schnell etwas entwickeln, da finanzielle Mittel und der Zugang zu relevantem Wissen vorhanden waren. Zudem wurde auf bestehende öffentliche Produkte wie dem eID-Service aufgebaut, der vom BMI bei der Bundesdruckerei Gruppe angeboten wird. Der rege Austausch zu den bestehenden Partnern inklusive dem BSI war dabei wertstiftend.

Im weiteren Projektverlauf war eine Einbindung von BundesIdent in die BundID geplant, um so eine Integration der Identifizierungskomponenten zu gewährleisten.

Status: erfüllt

Zusammenfassung:

• Arbeit mit offenen Standards in Anwendungsentwicklung und Betrieb
• Keine proprietären Formate eingesetzt

Begründung:
Das Team hat von Beginn an auf Offenheit gesetzt und immer das Credo verfolgt, entsprechend der verfügbaren Ressourcen möglichst offen zu arbeiten – in jeglicher Hinsicht. Die Teammitglieder haben immer bewusste Entscheidungen zugunsten offener Standards getroffen, nicht zuletzt, um möglichst effizient Software entwickeln zu können.

In der Anwendungsentwicklung wurde mit Web-Standards (iFrame, HTML, CSS, JavaScript) gearbeitet, die interne Kommunikation zwischen Diensten fand ausschließlich über offene Protokolle und Datenformate wie REST, HTTP(s) und JSON statt. Proprietäre Formate kamen nicht zum Einsatz.

Im Betrieb wurde mit einer Infrastruktur gearbeitet, die auf offenen Standards wie Kubernetes und OpenStack basiert und die, soweit möglich, über den de facto Standard Terraform (HCL) konfiguriert wurde.

Status: vollständig erfüllt

Zusammenfassung:

• Veröffentlichung und Open-Source-Lizenzierung aller Eigenentwicklungen
• Quellcode verfügbar unter
  https://github.com/digitalservicebund/useid-app-android
  https://github.com/digitalservicebund/useid-app-ios
  https://github.com/digitalservicebund/useid-backend-service
  https://github.com/digitalservicebund/useid-eservice-sdk
  https://github.com/digitalservicebund/useid-eservice-example
• MIT-lizensiert
• Multiparadigmatische Entwicklung mit Objektorientierung als Standard
• Dokumentation vor allem durch „sprechende Namen“ und umfangreiche Test-Suite

Begründung:
Das Team hatte von Beginn an die Veröffentlichung des Quellcodes aller Eigenentwicklungen geplant und kurz nach dem ersten Live-Gang umgesetzt. Die vom Team selbst entwickelten Komponenten von BundesIdent wurden unter der freizügigen Open-Source-Lizenz „MIT“ bereitgestellt. Das bedeutet, dass diese Komponenten für alle kostenlos und ohne Einschränkungen nutzbar und modifizierbar sind.

Das Projekt stützt sich zudem stark auf von der Community entwickelte Open-Source-Bibliotheken wie z. B. Spring Boot, die quelloffen verfügbar sind.

Der Code wurde vorwiegend objektorientiert konzipiert und entwickelt und gründlich mit Unit-, Integrationstests abgedeckt, wobei punktuell auch Paradigmen verwendet wurden, die auf die jeweiligen Sprachen und Bibliotheken besser passen (z. B. Entwicklung eines exemplarischen Services in Typescript oder die Bereitstellung eines Javascript-SDKs für die Widget-Einbindung).

Die Dokumentation wurde umgesetzt mit:

• sprechenden Namen
• stellenweisen Methoden-, Klassen- und Codekommentaren, falls sie zum Verständnis der Abläufe notwendig sind;
• einer umfangreiche Test-Suite, aus der das erwartete Verhalten hervorgeht;
• Dokumentation der Architektur
• Festhalten von Entscheidungen in einem Architecture Decision Record.

Status: erfüllt

Zusammenfassung:

• Nachnutzung von e-Card-Framework, AA2 SDK, iFrame
• Einsatz von Open-Source-Bibliotheken
• Cloud-Nutzung

Begründung:
Das Projekt hat auf bestehende Frameworks aufgebaut. In 2022 wurde die App basierend auf dem e-Card Framework entwickelt. Im Mai 2023 wurde der Wechsel zum AA2 SDK (Software Development Kit) mithilfe des zur Verfügung gestellten Wrappers vollzogen. Auch das Web-Widget wurde als bewährte iFrame-Komponente bereitgestellt.

Dadurch konnte sich das Team voll und ganz auf die eigene Anwendungsdomäne konzentrieren und seine Ressourcen effizient und wirtschaftlich einsetzen. Wo immer möglich wurden für Funktionalitäten, die nicht projektspezifisch sind, Open-Source-Bibliotheken eingesetzt, um den Umfang der Eigenentwicklung zu beschränken.

Dieses Prinzip wurde auch auf den Betrieb angewendet, wo möglichst standardisierte Verfahren eingesetzt wurden und die Dienste eines Cloud-Anbieters in Anspruch genommen wurden, um die eigenen Aufwände in diesem Bereich niedrig zu halten.

Status: erfüllt

Zusammenfassung:

• Verschiedene Dokumente erstellt, u. a. Sicherheitskonzept inkl. Betrieb, Hosting, Software-Architektur
• Vertragliche Regelungen mit technischem Dienstleister, u. a. bzgl. Sicherheitsvorfällen
• externe Prüfung durch einen Sicherheitsexperten sowie externer Penetrationstest
• Regelmäßige interne Bedrohungsanalyse
• Automatisiertes Monitoring und Alerts
• Durchführung von Lasttests vor Live-Gang und während des Betriebes zur Überprüfung der Zuverlässigkeit
• Kontinuierliche automatische Überwachung von Systemeigenschaften und -verhalten mit sofortiger Benachrichtigung
• Kontinuierliche, automatische Prüfung verwendeter Software-Pakete auf bekannte Sicherheitslücken

Begründung:
Zu Beginn des Projekts wurde ein Sicherheitskonzept aufgesetzt, das in Bezug auf Betrieb und Hosting u. a. die beteiligten Parteien, Rollen und Rechte, eine Schutzbedarfsanalyse, mögliche Schadensfälle, den Umgang mit Sicherheitsvorfällen und die Software-Architektur beinhaltete.

Auch vertraglich wurden Eventualitäten mit dem technischen Dienstleister geregelt, beispielsweise was bei einem Ausfall oder einem Sicherheitsvorfall zu passieren hatte und welche Vertragspartei für welchen Schritt verantwortlich war.

Ein offizieller BSI-Grundschutzcheck wurde nicht durchgeführt. Stattdessen wurde der Dienst von externen Sicherheitsexperten geprüft, ein Gutachten erstellt sowie ein externer Penetrationstest durchgeführt.

Intern wurden regelmäßige Bedrohungsanalysen durchgeführt. Aus den Analysen wurden entsprechende Maßnahmen abgeleitet und umgesetzt.

Status: erfüllt

Zusammenfassung:

• Entwicklung einer Identifizierungslösung soll hohem Anspruch an Interoperabilität gerecht werden
• Übermittlung der Identifikationsdaten entsprechend vom BSI standardisierten Schnittstellen und Abläufen im Rahmen des eID-Systems
• Integration des Web-Widgets in einem ersten Pilotservice mit Möglichkeit zur Weiterentwicklung basierend auf standardisierten Webtechnologien

Begründung:
Bei der Entwicklung von BundesIdent als Basiskomponente für Identifizierung war die leichte Integrationsmöglichkeit für Diensteanbieter zentral. Dies bezog sich auf den eID-Client, aber insbesondere auf die Servicekomponenten des Web-Widgets.

Das eID-System ist stark standardisiert, sodass wir BundesIdent entsprechend der Standards des BSI umgesetzt haben. Unsere Schnittstellen für die eID-Identifikation wurden gemäß den technischen Vorgaben des BSI zum eID-Client spezifiziert und öffentlich dokumentiert:

• github.com/digitalservicebund/useid-app-android
• github.com/digitalservicebund/useid-app-ios
• github.com/digitalservicebund/useid-backend-service

Für die Pilotierung haben wir als integrierter eID-Client entsprechend der Richtlinie ein eigenes Schema und nicht das allgemeine eID-Schema verwendet.

Insbesondere das Web-Widget war als Komponente gedacht, die leicht für Diensteanbieter integrierbar sein sollte und so einen einheitlichen Start in den Identifizierungsprozess für Nutzer:innen über Services hinweg gewährleisten sollte. Das Widget wurde als iFrame eingebunden, sodass es möglichst wenig Nutzungshürden gab.

Bei einer Weiterentwicklung des Piloten hätten wir die Integrationskomponente für eine stärkere Interoperabilität in weiteren Programmiersprachen sowie entsprechend den Anforderungen der integrierenden Services zur Verfügung gestellt. Dazu hatten wir bereits eine Abstraktionsebene hinzugefügt.

Status: erfüllt

Zusammenfassung:

• Bibliotheken kontinuierlich evaluiert

Begründung:
Da das Team sich noch in der Pilotierungsphase befand und der Dienst erst neu entwickelt wurde, wurden die verwendeten Technologien jeweils basierend auf unserem Anspruch auf hohe Sicherheit, ständige Verfügbarkeit und Interoperabilität ausgewählt, beispielsweise Docker/Kubernetes, Kotlin und Spring. Entsprechend der Evaluation wurde ein Wechsel von Spring Boot WebFlux auf Spring Boot WebMVC vorgenommen sowie vom Open eCard Framework auf das AA2 SDK. Die Architecture Decision Records sind auf GitHub öffentlich dokumentiert.

Status: erfüllt

Zusammenfassung:

• Analyse aus Supportanfragen und App-Reviews sowie produktintegrierter Feedback-Umfrage
• Abfrage der Nutzbarkeit für neue Iterationen in regelmäßigen Usability-Tests
• Implementierung von Tracking, mit dessen Hilfe Basisdaten ermittelt wurden, die Rückschlüsse auf Usability und Nutzerzufriedenheit zuließen
• Analyse von > 1000 Support-Anfragen, App-Reviews sowie > 1500 Rückmeldungen der produktintegrierten Feedback-Umfrage
• Erkenntnisse wurden aggregiert veröffentlicht

Begründung:
Entscheidungen, Erkenntnisse sowie Ergebnisse wurden offen geteilt. Deshalb hat das Team über Erkenntnisse aus der mehrmonatigen Recherche sowie zu Erkenntnissen aus dem Testbetrieb öffentlich berichtet. Detaillierte Daten sind nur intern verfügbar. Die aggregierten Ergebnisse sind veröffentlicht (Umfrageergebnisse als PDF zum Download).

Um die Nutzerzufriedenheit bzw. die Bedienbarkeit des Produkts zu überprüfen, wurden zum einen regelmäßig qualitative Interviews mit Nutzer:innen durchgeführt, zum anderen wurde im Produkt selbst ein erstes Basis-Tracking implementiert, um Daten wie Klickzahlen zu erheben und A/B-Tests durchzuführen. Außerdem konnte auch aus dem Support-Aufkommen und den verschiedenen Anfragen der Nutzer:innen abgeleitet werden, ob sie zufrieden mit der Nutzung von BundesIdent waren bzw. wo welche Verbesserungspotenziale liegen. Die Zufriedenheit zu BundesIdent wurde im Online-Dienst „Grundsteuererklärung für Privateigentum“ erfragt sowie über die App-Review.

All diese Datenpunkte haben wir quantitativ wie qualitativ ausgewertet und so ein Bild über die größten Punkte der (Un-)Zufriedenheit der Nutzer:innen erhalten. Der Support und auch das Monitoring der Tracking-Daten wurden vom Team selbst betreut, sodass das Feedback, die Fragen der Nutzer:innen und Erkenntnisse aus dem Tracking immer ohne Umwege im Team ankamen und in die Produktentwicklung einfließen konnten.

Status: erfüllt

Zusammenfassung:

• Weiterentwicklung des Dienstes auf Basis von Tracking-Daten, A/B-Tests, Usability-Tests, Analyse aus Support-Anfragen und App-Reviews sowie produktintegrierter Feedback-Umfrage
• Analyse gängiger Usability-Standards von Lösungen im Bereich digitale Identitäten
• Laufende Einbeziehung von Nutzerbedürfnissen in Produktentscheidungen

Begründung:
Das Produkt wurde mithilfe der Auswertung verschiedener Datenquellen weiterentwickelt. Dazu gehörten stetige Tracking-Daten, 27 Usability-Tests nach Go-Live des MVP, Feedback aus mehr als 1000 Support-Anfragen und Erkenntnissen aus den > 1.500 Rückmeldungen der produktintegrierten Feedback-Umfrage sowie den A/B-Tests. Hieraus ergab sich für uns ein Bild über die größten sowie kleinere Hürden. Erstere wurden mit höherer Priorität iteriert. Mithilfe der genannten Datenquellen konnten wir nach implementierten Änderungen analysieren, ob unsere angenommenen Verbesserungen erreicht wurden, oder ob weitere Iterationen notwendig sind.

Die Bedürfnisse und Herausforderungen der Zielgruppe wurden so in Produktentscheidungen einbezogen und im Team abgewägt. Auch die Priorisierung der Themen während der Weiterentwicklung wurde basierend auf Erkenntnissen über Bedarfe der Nutzer:innen vorgenommen.

Zudem haben wir stetig die Erkenntnisse aus der Recherche zu internationalen, insbesondere europäischen, Lösungen für eine staatliche digitale Identität einfließen lassen. Diese sowie Lösungen der deutschen Privatwirtschaft gaben ein gutes Bild über übliche Usability-Standards, die Nutzer:innen auch bei der Nutzung von BundesIdent erwarten konnten.