Eine EUDI Wallet Relying Party zu werden ist der Teil von eIDAS 2.0, der bei den Entwicklungsteams landet, und gleichzeitig der Teil mit der geringsten Aufmerksamkeit. Bis zum 24. Dezember 2026 muss jeder Mitgliedstaat eine konforme europäische Brieftasche für digitale Identität für Bürger und Einwohner bereitstellen. Die Frist ist nach der Verordnung (EU) 2024/1183 verbindlich, die Durchführungsrechtsakte sind veröffentlicht, und grenzüberschreitende Interoperabilitätstests zwischen Mitgliedstaaten haben bereits stattgefunden.
Die meiste Berichterstattung dreht sich um die Wallet selbst: was sie speichert, wie Bürger sie nutzen, wie tragfähig die Datenschutzarchitektur ist. Das ergänzende Problem bekommt deutlich weniger Aufmerksamkeit, obwohl dort die eigentliche Entwicklungsarbeit liegt. Eine Wallet ist nur nützlich, wenn Organisationen sie annehmen können.
Sie anzunehmen bedeutet Integrationsarbeit, Registrierung bei einer nationalen Behörde und in vielen Fällen den Umbau von Identitätsprozessen, die nie für ein attributbasiertes Modell gebaut wurden. Dieser Artikel setzt unseren Leitfaden zur eIDAS-2.0-Umsetzung, der den regulatorischen Rahmen und die organisatorischen Pflichten behandelt hat. Hier bleiben wir bei der technischen
Was eine EUDI Wallet Relying Party ist und warum das zählt
Drei Arten von Akteuren lassen das Ökosystem funktionieren, und die Unterscheidung zählt, weil sich die Pflichten deutlich unterscheiden.
Wer in einem regulierten Sektor Identitätsprüfung betreibt, landet in der dritten Kategorie. Aus dieser Position ist dieser Artikel geschrieben.
Die technischen Standards, die eine EUDI Wallet Relying Party unterstützen muss
Wallet-Nachweise anzunehmen bedeutet, einen bestimmten Stack umzusetzen. Es gibt Überschneidungen mit bestehender OAuth- und OpenID-Connect-Arbeit, doch es ist keine Obermenge davon.
Fern und Nahfeld sind zwei verschiedene Projekte
Teams kalkulieren häufig ein Projekt und entdecken zwei. Ein Online-Onboarding und eine Prüfung am Schalter teilen die Nachweisformate und die Vertrauensinfrastruktur, aber fast nichts von der Transportschicht oder der Nutzerführung. Sind beide Kanäle im Umfang, brauchen sie getrennte Schätzungen, getrennte Testpläne und getrenntes Rückfallverhalten. Das ARF und der Durchführungsrechtsakt zu Protokollen und Schnittstellen behandeln sie als getrennt, weshalb ein Plan, der das Nahfeld in eine späte Phase legt, leichter zu verteidigen ist als einer, der es als kostenlose Zugabe annimmt.
Was selektive Offenlegung für eine EUDI Wallet Relying Party ändert
Selektive Offenlegung erlaubt es einem Inhaber, ein Attribut zu beweisen, ohne den Rest des Nachweises herauszugeben. Der Mechanismus verdient Genauigkeit, weil er oft unscharf beschrieben wird. SD-JWT und mdoc erlauben die Offenlegung einzelner Datenelemente, während die übrigen verborgen bleiben und die Signatur des Ausstellers gültig bleibt. Zu beweisen, dass jemand über 18 ist, ohne das Geburtsdatum zu zeigen, funktioniert, weil der Nachweis selbst diskrete Elemente wie age over 18, trägt, ausgestellt von der Behörde. Die Wallet legt dieses Element offen und behält das Datum zurück
Wo die Änderung in Ihren Systemen ankommt
Datenmodell. Datensätze rund um Dokumentart, Dokumentnummer und Scan müssen attributbasierte Nachweise aufnehmen. Der Prüfdatensatz wird eine Menge bewiesener Angaben mit Aussteller und Zeitstempel.
KYC und AML Wallet-Nachweise haben unter eIDAS 2.0 rechtliche Gültigkeit, dennoch müssen Compliance-Teams selbst feststellen, dass Attributsattestierungen ihre Sorgfaltspflichten erfüllen. In Banken dauert diese Prüfung länger als die Entwicklungsarbeit, weshalb sie parallel beginnen sollte und nicht danach.
Nutzerführung. Eine Vorlage ist kein Upload. Der Inhaber öffnet die Wallet, wählt einen Nachweis, prüft die angefragten Attribute und stimmt zu. Die Bildschirme davor und danach brauchen ein neues Design, und der Text muss erklären, warum weniger Felder verlangt werden als früher.
Fehlerpfade. Teilweise Vorlagen, verweigerte Zustimmung, abgelaufene Nachweise und nicht verfügbare Wallets brauchen definiertes Verhalten. In der Übergangszeit zählt das mehr als der glückliche Pfad, denn der glückliche Pfad ist der seltenere Fall.
Registrierung als EUDI Wallet Relying Party bei der nationalen Behörde
Die Registrierung ist der Schritt, den Teams beim Zuschnitt der Arbeit vergessen. Bevor sie Vorlagen anfragen darf, muss sich eine Relying Party bei ihrer nationalen Aufsichtsbehörde registrieren, sich als juristische Person ausweisen, angeben, welche Attribute sie anfragen wird, und die Zwecke benennen. Es gibt einen eigenen Durchführungsrechtsakt zur Relying-Party-Registrierung, das Verfahren ist also auf EU-Ebene definiert, auch wo die nationale Umsetzung noch hinterherhängt.
Daraus folgen zwei Dinge. Erstens ist das eine Voraussetzung und keine Formalität, denn die Vertrauensinfrastruktur prüft die Registrierung während des Vorlageablaufs. Zweitens sind Ende-zu-Ende-Tests erst möglich, wenn die Registrierung besteht, was sie auf den kritischen Pfad setzt und nicht in die Spalte Verwaltungsaufwand. Organisationen, die in mehreren Mitgliedstaaten tätig sind, müssen sich möglicherweise in jedem registrieren, und die nationalen Verfahren sind noch nicht überall gleich spezifiziert.
Eine ehrliche Einschätzung der Bereitschaft der Mitgliedstaaten
Eine unabhängige Bewertung vom April 2026 hat den Fortschritt zur Verfügbarkeitsfrist im Dezember 2026 untersucht. Drei Mitgliedstaaten wirkten nahezu sicher, mit vollem Funktionsumfang anzukommen, fünf sehr wahrscheinlich, acht wahrscheinlich mit Vorbehalten, und elf standen unter unterschiedlich hohem Risiko.
Ein Plan, der 27 voll funktionsfähige Wallets am ersten Tag annimmt, übersteht den Kontakt mit der Wirklichkeit nicht. Manche werden vollständig sein, andere mit reduziertem Funktionsumfang starten, und einige kommen zu spät. Für eine Relying Party spricht das dafür, den Rückfallpfad zuerst zu bauen und die Wallet-Annahme als zusätzlichen Kanal statt als Ersatz zu behandeln.
Portugal gehört zu den besser vorbereiteten Staaten, unter anderem weil die bestehende Infrastruktur ausgereift ist. Die Middleware des portugiesischen Bürgerausweises, die wir gebaut haben, ist bei der gesamten Bevölkerung im Einsatz, und diese Kontinuität macht den nationalen Zeitplan verlässlicher als die meisten. Unsere Notizen LisbonID 2026 zeigen, wo die europäische Debatte zu Jahresbeginn stand, und unsere Arbeit zur digitalen Identität in Cabo Verde zeigt dieselbe Architektur außerhalb der EU.
Checkliste für die EUDI Wallet Relying Party Integration
Fünf Fragen, in der Reihenfolge, in der sie sich lohnen.
Was eID Box in diesem Zusammenhang leistet
eID Box ist unsere Middleware für digitale Identität. Sie integriert Smartcard-Authentifizierung in Unternehmensanwendungen und ist im portugiesischen nationalen Ausweissystem im Einsatz, das die gesamte Bevölkerung nutzt. Der Übergang zu eIDAS 2.0 ist das nächste Kapitel derselben Arbeit, kein Bruch damit.
Für Organisationen mitten in der Integration bewerten wir die bestehenden Identitätsprozesse und benennen, was sich ändern muss, bauen oder integrieren die Komponenten zur Prüfung von Wallet-Vorlagen, begleiten die Registrierung bei der zuständigen nationalen Behörde und entwerfen die Rückfallpfade für Nutzer, deren nationale Wallet noch nicht bereit ist. Zwanzig Jahre Bau dieser Art von Infrastruktur für den portugiesischen öffentlichen Sektor und für Unternehmenskunden sind das, was wir mitbringen.


