Wenn Sie die WRPAC-Pflicht bisher allein durch die Brille des Gesetzestextes verfolgt haben, haben Sie nur die Hälfte der Spezifikation gelesen. Die Durchführungsverordnung sagt Ihnen, dass Sie sich registrieren müssen. Sie sagt Ihnen nicht, wie ein Wallet Ihre Registrierung im Moment einer Transaktion erkennt. Diese zweite Hälfte lebt im Architecture and Reference Framework (ARF), und am 21. Mai 2026 rückte sie einen bedeutenden Schritt näher an die Klärung: ARF-Version 2.9.0 markierte Topic X – Relying Party Registration als Final.
Für eine Relying Party, die eine EUDI-Wallet-Integration plant, ist dies das folgenreichste ARF-Release seit Monaten. Hier ist, was sich tatsächlich geändert hat und warum es für Ihre WRPAC-Strategie wichtig ist.
Was das ARF ist – und warum „Final" ein bedeutsames Wort ist
Das ARF ist der lebendige technische Begleiter der Europäischen Kommission zur eIDAS-2.0-Verordnung. Wo die Rechtsakte Pflichten festlegen, drückt das ARF sie als High-Level Requirements (HLRs) aus – nummerierte, testbare Aussagen, gegen die Implementierer (Wallet-Anbieter, Aussteller und Verifier) entwickeln. Jeder Funktionsbereich ist als „Topic" organisiert, und Topics durchlaufen Entwurfs- und Diskussionsstadien, bevor sie für Final erklärt werden.
Ein Topic, das in den Status Final wechselt, friert es nicht für immer ein – das ARF wird weiterhin überarbeitet –, aber es signalisiert, dass die Arbeitsgruppe den Bereich als stabil genug betrachtet, um dagegen zu implementieren, ohne zu erwarten, dass sich der Boden unter Ihnen verschiebt. Dass Topic X zur Relying-Party-Registrierung diesen Status erreicht, bedeutet, dass Registrierungsdatenmodell und Authentifizierungsmechanik nun ein bewusstes Ziel sind – kein bewegliches.
Genau diese Sicherheit braucht eine Relying Party, bevor sie Entwicklungszeit investiert. Es ist der Unterschied, den wir in Produktions-WRPAC vs. Sandbox-Zertifikat gezogen haben: gegen eine stabile Spezifikation zu bauen versus gegen einen Entwurf, den Sie neu bauen müssen.
Topic X in einfachen Worten: drei Dinge, die Sie deklarieren müssen
Die Relying-Party-Registrierung, wie sie in 2.9.0 finalisiert wurde, formalisiert die Kette, die von wer Sie sind zu was ein Wallet Sie fragen lässt verläuft. Drei Kategorien von High-Level-Anforderungen verankern sie:
-
Authentifizierung der Relying Party. Das Wallet – und der Nutzer dahinter – muss kryptografisch verifizieren können, dass die Partei, die Attribute anfordert, dieselbe Partei ist, die sich registriert hat. Das ist die Rolle, die ein Wallet-Relying-Party Access Certificate (WRPAC) in der Praxis spielt: Es bindet Ihre registrierte Identität an die Schlüssel, die Ihre Präsentationsanfragen signieren.
-
Kontakt- und Identifikationsdaten. Der Registrierungseintrag muss überprüfbare Informationen über die juristische Person hinter der Relying Party tragen – die Daten, die ein nationales Register vorhält und die ein Wallet dem Nutzer anzeigen kann, damit er weiß, wer fragt.
-
Beabsichtigte Verwendung (die angeforderten Attribute). Eine Relying Party deklariert zum Zeitpunkt der Registrierung, welche Attribute sie anzufordern beabsichtigt und zu welchem Zweck. Ein Wallet kann dann eine Live-Anfrage gegen diesen deklarierten Umfang prüfen. Fordern Sie mehr an, als Sie registriert haben, kann ein konformes Wallet ablehnen.
Diesen dritten Punkt unterschätzen die meisten Teams. Registrierung ist kein einmaliges bürokratisches Tor – sie definiert einen Scope-Rahmen, der jede Transaktion einschränkt, die Sie je durchführen werden. Für einen Altersverifikations-Anwendungsfall ist das befreiend: Eine Relying Party, die sich nur für ein Altersnachweis-Attribut registriert, ist sichtbar und nachweislich außerstande, ein Geburtsdatum oder eine vollständige Identität anzufordern – genau die Datenminimierungs-Story, die Regulierer hören wollen. Wir haben dasselbe Prinzip aus Datenschutzsicht in DSGVO-Konformität: Wie eIDAS die Datenerhebung minimiert untersucht.
Wie Topic X mit WRPAC und WRPRC zusammenhängt
Das ARF unterscheidet zwei Zertifikatstypen, die auf der Registrierung aufsetzen, und Topic X in 2.9.0 ist das verbindende Gewebe zwischen ihnen:
- WRPAC – Wallet-Relying-Party Access Certificate. Authentifiziert die Relying Party gegenüber dem Wallet, wenn sie eine Zugriffsanfrage (Präsentationsanfrage) stellt. Dies ist das Zertifikat, das den meisten Händlern und Verifiern wichtig ist.
- WRPRC – Wallet-Relying-Party Registration Certificate. Bescheinigt die Registrierung selbst – die Berechtigungen und den im nationalen Register erfassten Umfang der beabsichtigten Verwendung.
Topic X ist das, was diese beiden kohärent macht: Es definiert die bei der Registrierung erfassten Daten (den Inhalt des WRPRC) und die Authentifizierungsanforderungen, die das Zugriffszertifikat (WRPAC) erfüllen muss. Wenn Sie unseren vollständigen Leitfaden zur Relying-Party-Registrierung gelesen haben, ist Topic X der Ausdruck dieses Prozesses auf HLR-Ebene.
Die rechtliche Hälfte: Durchführungsverordnung 2025/848
Das ARF steht nicht allein. Die Rechtsgrundlage für die Relying-Party-Registrierung ist die Durchführungsverordnung (EU) 2025/848 der Kommission, erlassen nach Artikel 5b(11) der eIDAS-Verordnung. Zwei Daten sind wichtig:
- Sie trat Mitte 2025 in Kraft (kurz nach der Annahme am 6. Mai 2025).
- Ihre materiellen Pflichten gelten ab dem 24. Dezember 2026.
Dieses zweite Datum sollten Sie sich rot anstreichen. Wie wir in der WRPAC-Statusübersicht der EU-27 dokumentiert haben, betreibt derzeit kein Mitgliedstaat einen öffentlich überprüfbaren Produktions-WRPAC-Pfad, und der EU-weite Trusted-List-Endpunkt im eIDAS Dashboard ist noch nicht veröffentlicht. Das ist kein Versagen – der Geltungsbeginn ist schlicht noch nicht erreicht. Dass ARF 2.9.0 Topic X vor dem Geltungsbeginn der gesetzlichen Pflicht finalisiert, ist das System in der richtigen Reihenfolge: erst die Spezifikation stabilisieren, dann die Register öffnen.
Ein Hinweis zu dem, was wir noch nicht bestätigen können. Der genaue Satz an Informationen, den eine Relying Party nach Anhang I der 2025/848 einreichen muss – und ob die Diskussion vom März 2026 rund um den Registrierungsakt (angestoßen von Branchenverbänden wie Bitkom, die argumentieren, technische Details gehörten in Standards und nicht in Gesetzestexte) diesen Satz noch umformen wird –, bleibt in Bewegung. Behandeln Sie die Feldliste in Anhang I als strukturell stabil, prüfen Sie aber die Einzelheiten gegen den offiziellen Text, bevor Sie ein Registrierungsformular bauen.
Was das für Ihre Roadmap bedeutet
Die praktische Erkenntnis ist eine der Reihenfolge. Dass Topic X final ist, lässt Sie jetzt echte Arbeit leisten – vor dem Geltungsbeginn am 24. Dezember 2026:
| Was Sie jetzt tun können | Worauf Sie warten sollten |
|---|---|
| Ihren Verifier gegen das Topic-X-Authentifizierungsmodell entwerfen | Einen Produktions-WRPAC-Antrag einreichen (Register nicht offen) |
| Ihren Umfang der beabsichtigten Verwendung entscheiden und dokumentieren (welche Attribute, welcher Zweck) | Sich an eine bestimmte nationale CA-Kette binden (noch nicht veröffentlicht) |
| Signierungsabläufe für Präsentationsanfragen in der Sandbox bauen und testen | Ein aktuelles Zertifikat als Produktions-WRPAC behandeln |
| Ihren Anwendungsfall auf den minimalen Attributsatz abbilden | Annahmen zu Anhang-I-Feldern festkodieren, bevor der Text final ist |
Für eine Relying Party, deren Anwendungsfall speziell die Altersverifikation ist, ist die Reihenfolge sogar noch sauberer, denn die EU-Referenzimplementierung zur Altersverifikation übt die Verifier-Seite dieser Anforderungen bereits in einer Testumgebung – siehe unseren kommenden Begleitbeitrag zur Validierung des Altersnachweises gegen die EU Trusted List sowie zum DC-API-/OpenID4VP-Anfrageablauf, den eine registrierte Relying Party für solche Anfragen nutzt.
Das Fazit
ARF 2.9.0 hat die WRPAC-Frist nicht geändert – sie bleibt der 24. Dezember 2026 nach Durchführungsverordnung 2025/848. Was sich geändert hat, ist Ihre Sicherheit: Das Registrierungsdatenmodell und die Authentifizierungsmechanik unterhalb von WRPAC sind nun ein finales Topic. Sie können dagegen entwickeln, ohne zu erwarten, dass sie sich noch verschieben.
Die Relying Parties, die am ersten Tag bereit sein werden, sind nicht jene, die auf die Öffnung der Register warten. Es sind jene, die heute bereits ihren Umfang der beabsichtigten Verwendung entschieden, ihren Anfrage-Signierungsablauf gegen das stabile Topic-X-Modell gebaut und ihn durchgängig getestet haben. ARF 2.9.0 ist das grüne Licht, eine davon zu sein.
Dieser Beitrag spiegelt das ARF in der Version 2.9.0 (21. Mai 2026) und die regulatorische Lage von Juni 2026 wider. Beide befinden sich in einem aktiven 2026er-Takt – prüfen Sie Daten und Anhang-Einzelheiten gegen das offizielle ARF-Repository und EUR-Lex, bevor Sie sich darauf verlassen.
Diesen Artikel teilen
Helfen Sie anderen, mehr über eIDAS-Verifizierung zu erfahren