ARF 2.9.0 finaliseert de Relying Party-registratie (Topic X): wat er verandert voor WRPAC

Als u de WRPAC-verplichting tot nu toe alleen door de bril van de wettekst heeft gevolgd, heeft u slechts de helft van de specificatie gelezen. De uitvoeringsverordening vertelt u dat u zich moet registreren. Ze vertelt u niet hoe een wallet uw registratie herkent op het moment van een transactie. Die tweede helft leeft in het Architecture and Reference Framework (ARF), en op 21 mei 2026 kwam die een belangrijke stap dichter bij afronding: ARF-versie 2.9.0 markeerde Topic X — Relying Party Registration als Final.

Voor een relying party die een EUDI Wallet-integratie plant, is dit de meest ingrijpende ARF-release in maanden. Dit is wat er daadwerkelijk is veranderd en waarom het van belang is voor uw WRPAC-strategie.

Wat het ARF is, en waarom "Final" een betekenisvol woord is

Het ARF is de levende technische begeleider van de Europese Commissie bij de eIDAS 2.0-verordening. Waar de wetgevingshandelingen verplichtingen vastleggen, drukt het ARF ze uit als High-Level Requirements (HLR's) — genummerde, toetsbare uitspraken waartegen implementeerders (wallet-aanbieders, uitgevers en verifiers) bouwen. Elk functioneel gebied is georganiseerd als een "Topic", en Topics doorlopen concept- en discussiestadia voordat ze Final worden verklaard.

Dat een Topic naar Final gaat, bevriest het niet voor altijd — het ARF wordt nog steeds herzien — maar het signaleert dat de werkgroep het gebied stabiel genoeg acht om ertegen te implementeren zonder te verwachten dat de grond onder u verschuift. Dat Topic X, dat de Relying Party-registratie behandelt, deze status bereikt, betekent dat het registratiedatamodel en de authenticatiemechaniek nu een bewust doel zijn, geen bewegend doel.

Dat is precies de zekerheid die een relying party nodig heeft voordat ze engineeringtijd investeert. Het is het verschil dat we trokken in Productie-WRPAC versus sandboxcertificaat: bouwen tegen een stabiele specificatie versus bouwen tegen een concept dat u opnieuw moet bouwen.

Topic X in gewone taal: drie dingen die u moet verklaren

Relying Party-registratie, zoals gefinaliseerd in 2.9.0, formaliseert de keten die loopt van wie u bent naar wat een wallet u laat opvragen. Drie categorieën high-level requirements verankeren dit:

1. Authenticatie van de relying party. De wallet — en de gebruiker erachter — moet cryptografisch kunnen verifiëren dat de partij die attributen opvraagt, dezelfde partij is die zich heeft geregistreerd. Dit is de rol die een Wallet-Relying Party Access Certificate (WRPAC) in de praktijk speelt: het bindt uw geregistreerde identiteit aan de sleutels die uw presentatieverzoeken ondertekenen.

2. Contact- en identificatiegegevens. Het registratiedossier moet verifieerbare informatie bevatten over de rechtspersoon achter de relying party — de gegevens die een nationaal register bijhoudt en die een wallet aan de gebruiker kan tonen, zodat deze weet wie er vraagt.

3. Beoogd gebruik (de opgevraagde attributen). Een relying party verklaart op het moment van registratie welke attributen ze van plan is op te vragen en voor welk doel. Een wallet kan een live verzoek dan toetsen aan die verklaarde reikwijdte. Vraagt u meer op dan waarvoor u geregistreerd bent, dan kan een conforme wallet dit weigeren.

Dat derde punt onderschatten de meeste teams. Registratie is geen eenmalige bureaucratische poort — het definieert een scope-envelop die elke transactie beperkt die u ooit zult uitvoeren. Voor een leeftijdsverificatie-use case is dat bevrijdend: een relying party die zich alleen registreert voor een leeftijdsbewijs-attribuut, is zichtbaar en aantoonbaar niet in staat om een geboortedatum of een volledige identiteit op te vragen — precies het data-minimalisatieverhaal dat toezichthouders willen horen. We hebben datzelfde principe vanuit het oogpunt van gegevensbescherming verkend in AVG-compliance: hoe eIDAS gegevensverzameling minimaliseert.

Hoe Topic X verband houdt met WRPAC en WRPRC

Het ARF onderscheidt twee certificaattypen die bovenop de registratie zitten, en Topic X in 2.9.0 is het verbindende weefsel daartussen:

• WRPAC — Wallet-Relying Party Access Certificate. Authenticeert de relying party bij de wallet wanneer deze een toegangsverzoek (presentatieverzoek) doet. Dit is het certificaat waar de meeste handelaren en verifiers om geven.
• WRPRC — Wallet-Relying Party Registration Certificate. Bevestigt de registratie zelf — de rechten en de in het nationale register vastgelegde reikwijdte van het beoogde gebruik.

Topic X is wat deze twee coherent maakt: het definieert de gegevens die bij registratie worden vastgelegd (de inhoud van het WRPRC) en de authenticatievereisten waaraan het toegangscertificaat (WRPAC) moet voldoen. Als u onze volledige gids voor relying party-registratie heeft gelezen, is Topic X de uitdrukking op HLR-niveau van het daar beschreven proces.

De juridische helft: uitvoeringsverordening 2025/848

Het ARF staat niet op zichzelf. De juridische grondslag voor relying party-registratie is Uitvoeringsverordening (EU) 2025/848 van de Commissie, vastgesteld op grond van artikel 5b, lid 11, van de eIDAS-verordening. Twee data zijn van belang:

• Ze trad medio 2025 in werking (kort na vaststelling op 6 mei 2025).
• De inhoudelijke verplichtingen gelden vanaf 24 december 2026.

Die tweede datum moet u omcirkelen. Zoals we hebben gedocumenteerd in de WRPAC-statusopname van de EU-27, heeft geen enkele lidstaat momenteel een publiek verifieerbaar productie-WRPAC-traject in werking, en het EU-brede trusted-list-eindpunt op het eIDAS Dashboard is nog niet gepubliceerd. Dat is geen mislukking — de toepassingsdatum is simpelweg nog niet aangebroken. Dat ARF 2.9.0 Topic X finaliseert voordat de wettelijke verplichting van toepassing wordt, is het systeem dat in de juiste volgorde werkt: eerst de specificatie stabiliseren, dan de registers openen.

Een kanttekening bij wat we nog niet kunnen bevestigen. De precieze set gegevens die een relying party moet indienen onder bijlage I van 2025/848 — en of de discussie van maart 2026 rond de registratiehandeling (aangekaart door brancheorganisaties zoals Bitkom, die betogen dat technische details thuishoren in standaarden en niet in wetgeving) die set nog zal wijzigen — blijft in beweging. Behandel de veldenlijst van bijlage I als structureel stabiel, maar controleer de specifieke details aan de hand van de officiële tekst voordat u een registratieformulier bouwt.

Wat dit betekent voor uw roadmap

De praktische conclusie draait om volgorde. Doordat Topic X Final is, kunt u nu al echt werk verzetten, vooruitlopend op de toepassingsdatum van 24 december 2026:

Voor een relying party wier use case specifiek leeftijdsverificatie is, is de volgorde nog helderder, omdat de EU-referentie-implementatie voor leeftijdsverificatie de verifier-kant van deze vereisten al beoefent in een testomgeving — zie ons binnenkort verschijnende vervolgartikel over het valideren van leeftijdsbewijs tegen de EU Trusted List, en over de DC API-/OpenID4VP-aanvraagflow die een geregistreerde relying party gebruikt om die verzoeken te doen.

Kortom

ARF 2.9.0 heeft de WRPAC-deadline niet veranderd — die blijft 24 december 2026 onder uitvoeringsverordening 2025/848. Wat wel is veranderd, is uw zekerheid: het registratiedatamodel en de authenticatiemechaniek onder WRPAC zijn nu een Final Topic. U kunt uw architectuur erop baseren zonder te verwachten dat ze nog verschuiven.

De relying parties die op dag één klaar zullen zijn, zijn niet degene die wachten tot de registers opengaan. Het zijn degene die vandaag al hun reikwijdte van beoogd gebruik hebben bepaald, hun verzoekondertekeningsflow hebben gebouwd op basis van het stabiele Topic X-model, en dit end-to-end hebben getest. ARF 2.9.0 is het groene licht om daarbij te horen.

Dit artikel weerspiegelt het ARF vanaf versie 2.9.0 (21 mei 2026) en de regelgevende positie per juni 2026. Beide volgen een actief 2026-tempo — controleer data en bijlagespecificaties aan de hand van de officiële ARF-repository en EUR-Lex voordat u erop vertrouwt.