Die Annahme einer EUDI-Wallet-Presentation ist eine Vertrauensentscheidung, und diese Entscheidung fällt in Ihrem Integrationscode. Dieser Artikel richtet sich an Relying Parties: also an Kommunen und Dienstanbieter, die Wallet-Presentations akzeptieren werden, nicht an die Teams, die Wallets entwickeln. Er enthält die Fragen, die wir beantwortet haben möchten, bevor die Wallet für echte Nutzerinnen und Nutzer freigeschaltet wird - als Prüfcheckliste, nicht als fertiges Design.
Wissen, gegen welche Spezifikation Sie bauen
Die technische Grundlage ist das Architecture and Reference Framework (ARF). Es ist in einem öffentlichen GitHub-Repository veröffentlicht und wird unter der Common Union Toolbox weiterentwickelt. Laut Repository ist die jeweils neueste verbindliche Version das aktuellste getaggte Release. Ein Branch oder die Zusammenfassung in einem Blogbeitrag ist nicht verbindlich.
Die Rechtsgrundlage ist die Verordnung (EU) Nr. 910/2014 in der Fassung der Verordnung (EU) 2024/1183, zusammen mit den zugehörigen Durchführungsverordnungen der Kommission. Das ARF verweist in den Abschnitten Introduction und References auf die gepflegte Liste dieser Rechtsakte.
Die ersten Fragen sind daher organisatorischer Natur, aber sie sind wichtig:
- Gegen welches ARF-Release haben Ihr Lieferant oder Integrator gebaut?
- Wer auf Ihrer Seite verfolgt neue getaggte Releases und Durchführungsverordnungen, und wie gelangen Änderungen in Ihr Backlog?
- Nennt Ihr Vertrag mit dem Identitätsanbieter eine konkrete Version oder nur "eIDAS-2.0-konform"?
Fragen zur Assertion
Die Wallet übergibt Ihrem Dienst eine Presentation. Bevor daraus eine Session werden kann, müssen Sie wissen, was Sie tatsächlich verifiziert haben.
- Wer hat sie ausgestellt? Ihr Dienst sollte Presentations nur von Ausstellern akzeptieren, denen Sie bewusst vertrauen, und nur für die Attributtypen, die Sie bewusst zulassen. "Jede gültige Signatur" ist keine Policy. Halten Sie die Akzeptanzliste schriftlich fest, benennen Sie eine verantwortliche Person und legen Sie fest, wie Einträge hinzugefügt und entfernt werden.
- Ist sie an diese Transaktion gebunden? Eine Presentation, die gegen Ihren Login-Endpunkt wiederholt (Replay) werden kann, ist ein gestohlenes Credential in Wartestellung. Klären Sie mit Ihrem Anbieter, wie eine Presentation an Ihre Session gebunden wird, und testen Sie, dass eine alte Presentation abgelehnt wird.
- Was passiert, wenn die Verifikation fehlschlägt oder nicht verfügbar ist? Entscheiden Sie, ob Sie fail closed arbeiten. Prüfen Sie, dass Fehlerbehandlung und Lastsituationen Nutzer nicht in einen schwächeren Fallback-Pfad umleiten.
- Was protokollieren Sie? Sie brauchen genug, um einen Vorfall untersuchen zu können, ohne jene personenbezogenen Daten zu speichern, die die Wallet bewusst minimal halten soll.
Zum ersten Punkt: Die Akzeptanzpolicy für Aussteller und Attribute ist die Maßnahme, die wir empfehlen. Sie ist keine Anforderung, die aus dem ARF zitiert wird.
Fragen zu Attributen
Die Kommission beschreibt die Wallet so, dass Nutzer nur die notwendigen Angaben offenlegen, etwa Alter oder Staatsangehörigkeit, und andere personenbezogene Daten zurückhalten. Das setzt die Erwartung, die Ihre Integration als Relying Party erfüllen muss.
Wenn Ihr Dienst wissen muss, dass jemand ein bestimmtes Alter überschritten hat, fragen Sie genau das ab, nicht das Geburtsdatum. Wenn Sie eine Einwohnerin oder einen Einwohner Ihrer Kommune benötigen, fragen Sie das Attribut ab, das dies belegt, nicht die vollständige Adresse. Jedes zusätzliche Attribut, das Sie anfordern, vergrößert die Datenmenge, die Sie schützen und in Ihrer eigenen Datenschutzfolgenabschätzung rechtfertigen müssen.
Fragen Sie dann, was das Attribut tatsächlich belegt. Ein Attribut eines staatlichen Ausstellers und eines eines privaten Ausstellers können in derselben Wallet liegen und in Ihrem Code gleich aussehen. Ordnen Sie jedes Attribut der Entscheidung zu, die es stützt. Eine Bibliotheksausweisnummer sollte keinen Zugang zur Steuererklärung gewähren.
Eine einzelne Zeile der Akzeptanzpolicy könnte so aussehen. Die Werte veranschaulichen das Format und sind keine Empfehlung:
| Aussteller | Attribut | Entscheidung der Relying Party | Verantwortlich | Prüfintervall |
|---|---|---|---|---|
| Aussteller nationaler Ausweise (Beispiel) | Alter über 18 | Zugang zum altersbeschränkten Dienst erlauben; kein Geburtsdatum speichern | Service Owner | Alle sechs Monate |
Wenn Sie nicht alle fünf Spalten eines Eintrags ausfüllen können, gehört er noch nicht auf die Liste.
Zur Nutzung im organisatorischen Kontext: Die Pilotprojekte testen organisatorische digitale Identitäten als Anwendungsfall, nämlich den Nachweis, dass jemand rechtmäßig eine Organisation vertritt. Wenn Sie Unternehmen bedienen, entscheiden Sie jetzt, wie Sie eine für ein Unternehmen handelnde Person behandeln und wie Sie erfahren, wann deren Vertretungsbefugnis endet.
Fragen zu Signaturabläufen
Das Unterzeichnen von Verträgen ist eines der Pilotszenarien. Behandeln Sie es daher als eigenen Assurance-Fall, getrennt vom Login.
- Von welchen Diensten hängt Ihr Signatur- oder Siegelablauf ab, und wer betreibt sie?
- Was speichern Sie als Nachweis einer Signatur, und wie lange?
- Wenn eine Signatur in zwei Jahren angefochten wird: Können Sie zeigen, was damals vorgelegt und verifiziert wurde?
Gehen Sie nicht davon aus, dass ein erfolgreicher Login eine gültige Signaturkette impliziert. Es sind getrennte Prüfungen mit unterschiedlichen Fehlermodi. Ihre Rechts- und Sicherheitsteams sollten sich darauf verständigen, was als zulässiger Nachweis gilt, bevor der erste Vertrag unterzeichnet wird.
Integration testen - und noch einmal testen
Der Prototyp der Wallet der Kommission enthält Code-Bibliotheken und eine Beispielanwendung, und die Referenzimplementierung ist Open Source. Das ARF-Repository verweist auf eine Conformance-Website. Nutzen Sie diese Ressourcen zum Testen, nicht als Produktionsabhängigkeit, die Sie nie geprüft haben.
An den Large-Scale-Piloten sind mehr als 350 Organisationen aus 26 Mitgliedstaaten, Norwegen, Island und der Ukraine beteiligt; sie decken Bereiche wie Behördendienste, Banken und Zahlungsverkehr ab. Ihre eigenen Endpunkte, Fallback-Pfade und das Session-Handling müssen trotzdem eigens getestet werden.
Behandeln Sie die Integration wie neuen Authentifizierungscode. Das heißt: ein Threat Model, Abuse-Case-Tests gegen Replay, fehlerhafte Presentations und unerwartete Aussteller sowie ein Penetrationstest des fertigen Ablaufs vor dem Launch. Was auch immer der Wallet-Anbieter getestet hat: Ihr Relying-Party-Dienst braucht eine eigene Prüfung.
Wo Sie anfangen
- Legen Sie Ihr Ziel fest: Dokumentieren Sie das ARF-Release und die Durchführungsverordnungen, gegen die Ihre Integration gebaut ist, und benennen Sie jemanden, der Änderungen beobachtet.
- Schreiben Sie eine Akzeptanzpolicy: Führen Sie die Aussteller und Attributtypen auf, denen Sie vertrauen, dazu die jeweils gestützte Entscheidung, die verantwortliche Person und das Prüfintervall.
- Reduzieren Sie Ihre Attributabfragen auf das Minimum, das der jeweilige Dienst benötigt, und halten Sie das Ergebnis in Ihrer eigenen Datenschutzfolgenabschätzung fest.
- Erstellen Sie einen Testplan auf Basis der Referenzimplementierung und der Conformance-Ressourcen, einschließlich Fällen zu Replay, falschem Aussteller, Fehlermodi und Fallback-Pfaden.
- Trennen Sie Login und Signatur: Entscheiden Sie, welche Nachweise Sie jeweils aufbewahren und wer sie freigibt.
- Lassen Sie vor dem Go-live eine unabhängige Prüfung durchführen. Wenn Sie Unterstützung bei der Abgrenzung wünschen, sprechen Sie mit unserem Beratungsteam.
