| Overleg | Strategisch Beraad ETD (SB 33) |
| Datum en tijd | 10 december september, 10.00 – 12.30u |
| Locatie | Digitaal via Webex |
|
Aanwezigen |
|
|
Andere deelnemers |
|
| Afwezigen |
|
1. Opening
Kolette heet iedereen welkom bij Logius. Een aantal leden neemt remote deel.
1.1. Vaststellen agenda
De agenda wordt vastgesteld.
1.2. Mededelingen
Kolette:
- Bernard Stibbe en Mark Baas hebben zich afgemeld. Jeroen van Wingerde is afwezig i.v.m. ziekte
- Gasten aan tafel zijn Rob Brand (ministerie EZK) en toehoorders Ka-Kin Fung (BZK) en Arthur van Geenen (Juridisch zaken Logius) t.b.v. agendapunt eIDAS2.0 / LSP.
- Mischa Puyenbroek (SO) update t.a.v. RFC2234, agendapunt 2.1.
- Servaas Schrama t.b.v. agendapunt Datareportr
1.3. Vaststellen notulen OB
Het verslag van de vorige meeting Schriftelijke ronde OB 103 (10 december 2024) is akkoord.
2. RFC's ter bespreking en advies
2.1 RFC2234 Verplichtstellen leveren geverifieerde WID attributen (aangepaste scope) - Change management eToegang - eHerkenning Wiki
Mischa Puyenbroek (Security Officer) doet een vooraankondiging dat er geen DPIA komt maar een notitie waarin een negatief advies wordt afgegeven om de WID-attributen verplicht te stellen omdat het verschillende risico's met zich mee brengt. De notitie ligt momenteel ter review bij de Beheerorganisatie. Zodra deze klaar is zal de RFC en de bijbehorende notitie wederom worden geagendeerd in het OB.
Samenvatting
| Waarom is deze RFC nodig? |
Voor veel digitale processen is het nodig om de handelende persoon te kunnen identificeren o.b.v. zijn naam of andere gegevens van zijn WID. Dit is ook #1 use case in de ontwikkeling van EDI/Wallet. Doordat het leveren van deze attributen nu optionele functionaliteit is kunnen Dienstverleners niet vertrouwen op levering en moeten ze alsnog een proces inrichten voor de situaties waar de attributen niet via ETD ontvangen worden. Hebben ze eenmaal een proces zonder ETD attributen, dan zullen ze niet alsnog een proces met ETD attributen inrichten. Meer informatie: deze RFC kent een lange geschiedenis en is in 2018 aangemaakt n.a.v. een use case van UWV. Deze wil persoonsgegevens van de handelende persoon ontvangen om te weten wie actief is in de digitale omgeving van UWV om zodoende te zorgen voor een complete audittrail op de toegang tot gegevens en om opvolging van signalen uit beveiligingsmonitoring efficiënt te kunnen doen. Daarbij zijn ook gegevens van de Dienstafnemer en (indien van toepassing) intermediaire organisatie in scope. Ook voor verwelkoming en identificatie op het scherm van de gebruiker wil UWV de naam van de gebruiker weer kunnen geven. De Belastingdienst deelt deze wensen. Het mobiele nummer van een gebruiker is ook gewenst om deze in bepaalde processen via SMS te kunnen informeren. Als deze informatie betrouwbaar uit ETD ontvangen kan worden, dan
|
| Oplossingsrichting |
Verplichtstelling voor de MU/AD om de hieronder genoemde attributen van de handelende persoon vast te leggen en bij een uitvraag op te leveren.
De UX en error handling wordt aangescherpt. Als de Dienstverlener om verplichte levering van attributen vraagt en AD/EB/MR deze niet kan leveren (bv geen consent). Dan mag dit NIET in een succes response resulteren |
| Aanpassing van | Algemeen |
| Impact op rollen | Geen. Alle huidige MU/AD registreren reeds deze gegevens en kunnen deze reeds leveren. |
| Impact op aanpalende systemen | Geen |
| Gerelateerd aan |
Dossier:
|
| Eigenaar | René Bonte, Reconi |
| Implementatietermijn | Nader te bepalen |
| Testcases van toepassing? | Testcases vormen geen onderdeel meer van het afsprakenstelsel. |
| Motivatie verkorte RFC procedure | Niet van toepassing |
RFC wordt aangehouden tot nader orde
2.2. RFC2433 Correctie versienummers attribuut URNs - Change management eToegang
Samenvatting
| Waarom is deze RFC nodig? |
In het afsprakenstelsel zijn verschillende attributen gedefinieerd die uitgevraagd kunnen worden. De attributen die hier staan, matchen echter niet met wat er in de attribuutcatalogus https://extranet.eherkenning.nl/1.11/attribuutcatalogus.xml staat. Omdat de attribuutcatalogus XML al lange tijd in gebruik is, worden met deze RFC de attribuut URNs in het stelsel aangepast naar de attributen zoals die in de XML gebruikt worden. Het is overwogen om de aanpassing andersom te doen (XML attribuutcatalogus aanpassen aan wat het stelsel momenteel voorschrijft), maar dit had niet de voorkeur van de leveranciers omdat dit er mogelijk toe zou kunnen leiden dat DVs een aanpassing moeten doen. |
| Oplossingsrichting | Aanpassen van het AS zodat dit weer match met de in gebruik zijnde XML attribuutcatalogus. |
| Aanpassing van | Afsprakenstelsel |
| Impact op rollen | Geen impact |
| Impact op aanpalende systemen | Geen impact |
| Gerelateerd aan | ET-54 - Data kan niet worden opgehaald door een onverwachte fout. |
| Eigenaar | Marco Bonsink, UnifiedPost |
| Implementatietermijn |
|
| Opgenomen in release (in te vullen door releasemanager) |
Releasemanager voegt link toe betreffende release onder de Space Operationele Zaken / 5. Implementatie Testcase(s):
|
| Meldplicht RDI |
|
- Marco Bonsink: geen op- en aanmerkingen n.a.v. toelichting op RFC2433.
- Advies OB 104: Het OB adviseert positief en mag direct door naar het TB.
2.3. RFC2434 Vernieuwing Proces Change en Releasemanagement, changemanagement eToegang
Samenvatting
| Waarom is deze RFC nodig? | In het Operationeel Handboek zijn een 3-tal procesbeschrijvingen opgenomen t.w. Proces Change en Release, Proces implementatie koppelvlakrelease en Proces realisatie koppelvlakwijzigingen. Afgelopen jaar is het proces C&R gereviewd. Deze RFC beschrijft de huidige en gewenste werkwijze van Change en releasemanagement |
| Oplossingsrichting | De processen implementatie koppelvlakrelease en realisatie koppelvlakwijzigingen kunnen vervallen omdat er een nieuw releaseproces is beschrijven. Het huidige changeproces is op onderdelen aangescherpt met elementen die eerder in het TB zijn voorgesteld. |
| Aanpassing van |
|
| Impact op rollen | Geen impact |
| Impact op aanpalende systemen | Geen impact |
| Gerelateerd aan | Niet van toepassing |
| Eigenaar | Kolette Visser, Logius |
| Implementatietermijn |
|
| Opgenomen in release (in te vullen door releasemanager) |
Releasemanager voegt link toe betreffende release onder de Space Operationele Zaken / 5. Implementatie Testcase(s):
|
| Meldplicht RDI |
|
- Kolette: Geen op- en aanmerkingen n.a.v. toelichting op RFC2434.
- Advies OB 104: Het OB adviseert positief en mag direct door naar het TB
3. Wdo Stelsel Toegang
René Bonte (dossiereigenaar Stelsel Toegang Wdo):
- Status: Het Petite Comité (PC) heeft structureel overleg waarin input/feedback van de leveranciers wordt gedeeld. Dat proces verloopt goed. De uitvoering van een POC op het architectuur voorstel van HRdR is van de baan. Eind januari is met BZK en PC overleg geweest waarbij ingestemd is met de uitvoering van een POC op de functionaliteit eHerkenning architectuur o.b.v. Stelsel Toegang. De usecases betreffen o.a. Ouderlijk Gezag (OG), Bewindvoering en Curatele
- Voordat gestart zou kunnen worden met de POC, moet nog een aantal belangrijke aandachtspunten/vragen worden besproken waarover eerst duidelijkheid moet komen:
- Wat wordt de juridische context van de ontsluitende dienst (OD)?
- Het is belangrijk dat als de nieuwe functionaliteit er is, deze tegelijkertijd wordt aangeboden als publieke en private OD.
- Een algemene vraag is hoe de functionele werking eruit gaat zien. Momenteel wordt hiervoor een notitie voorbereid welke t.z.t. zal worden besproken in het PC.
Frans de Kok geeft een weergave van de status en visie vanuit Logius Beheerorganisatie (BO)
- Voor een nieuw Stelsel Toegang zal, net als binnen de huidige BO eHerkenning, een governance en een beheerorganisatie worden ingericht. Momenteel wordt nagedacht over de inrichting en welke tooling (Datareportr, Aggregator etc.) noodzakelijk en nodig is voor het doen van een adequaat beheer. De opdracht van Jeroen van Wingerde is om dit in kaart te brengen voor de nieuwe op te richten BO Stelsel toegang en hoe deze naast de BO eHerkenning zich gaat ontwikkelen in de nabije toekomst.
- Naast o.a. de Aggregator zullen tevens de voorzieningen TRR en BSNk landen bij Logius voor het bedienen vanuit het Stelsel Toegang. Er zal een nieuwe beheer- en ontwikkeltrein worden ingericht voor TRR, traject BVD OG, Bewindvoering en Curatele. Deze voorzieningen gaan worden ondergebracht samen met DigiD en PKIo.
- Logius is ook betrokken, samen met de ICTU en DICTU, over ontwikkeling van de architectuur Stelsel Toegang samen met BZK voor de Bedrijvendomein, Burgerdomein (DigiD) en Zorgdomein (TVS) welke ook onderdeel is van Stelsel Toegang. De plannen van BZK zijn vrij ambitieus maar sluiten zich steeds meer aan op de architectuur eHerkenning.
- Complexiteit aansluiting DV; Het doel is om het gemakkelijk te maken voor de DV om eenvoudig aan te sluiten op eHerkenning en eIDAS maar ook op DigiD. Gekeken wordt waar winst te behalen is en verbetering door te voeren is op dit gebied. De doelstellingen zullen volgens Agile aanpak worden gerealiseerd. Kleine stapjes die waarde toevoegen i.p.v. grand design.
Frans heeft een voorstel gemaakt waarin een aantal beproevingen voor Stelsel Toegang wordt beschreven. Dit voorstel ligt momenteel ter review binnen Logius, hierover is nog geen eenduidige instemming. De volgende punten worden nader toegelicht:
- De kaders, doelstellingen en eisen t.b.v ontwerpopdracht ‘zorg voor een betrouwbare, veilige en privacy-vriendelijke toegang tot digitale dienstverlening’
- 1 bestaande aansluiting voor DigiD, eHerkenning BVD etc: via TVS en HM
- Maak het aantrekkelijk voor DV’s om aan te sluiten op het Stelsel Toegang [GDI]
- Zorg voor eenvoudige koppelvlakmigratie (SAML-OIDC)
Zie voorstel en meer informatie over Verifiable Credentials in dossier Beproevingen 2025. Frans geeft aan dat input hierop welkom is en tijd zal vrij maken voor eventuele vragen/opmerkingen en indien nodig een overleg zal inplannen met diegene. René en Frans worden bedankt voor hun toelichting.
4. eIDAS2.0 / Large Scale Pilots (LSP)
- Rob Brand (ministerie EZK), Coördinator van het consortium voor LSP.
- Ka-Kin Fung (BZK), Toehoorder om perspectief van leveranciers/Logius mee te nemen.
Rob vermeldt allereerst het goede nieuws dat de Europese Commissie recent de aanvraag van het WE BUILD consortium positief heeft beoordeeld. Score was goed. Een aantal eHerkenning leveranciers zullen medio september 2025 aan de slag gaan met de Large Scale Pilot 2. Vervolgens geeft Rob een presentatie waarin hij de aanwezigen de achtergrond schetst en informeert over het WE BUILD consortium voor Large Scale Pilot (LSP) waarin o.a. de eHerkenning leveranciers deelnemen. De LSP wordt gedaan i.h.k.v. de eIDAS-verordening. Toelichting volgt op de belangrijke acties en momenten welke afgelopen jaar ter voorbereiding hebben plaatsgevonden en de voortgang /status van inhoudelijke ontwikkelingen en vervolgacties:
- Oproep van de Europese Commissie is halverwege mei 2024 geweest, waarbij partijen de mogelijkheid hadden om zich aan te melden om in aanmerking te komen voor mede financiering maximaal 50%. Beschikbaar budget is 20 mln.
-
De voorstellen moeten het gebruik in ten minste één van de vier thematische usecase-gebieden bestrijken:
1. Business (portefeuilles voor bedrijven)
2. Payments (betalingen en bankieren),
3. Leeftijdsverificatie
4. Travel (portemonnee voor op reis).
- Start is begin september 2025 tot 2026. De lidstaten moeten over Wallets (verplichting opensource) beschikken en de publieke organisatie moet voor hun processen de wallet accepteren bij 2FA. Eind 2027 moeten bedrijven in een aantal sectoren (banken, onderwijs etc.) de wallet accepteren voor online authenticatie. • De integratie van de interfaces van vertrouwende partijen en PID-, EAA- en QEAAaanbieders met de Wallet in hun pre-productiesystemen moet gerealiseerd zijn. Daarna testen. • Uitgebreide tests van de grensoverschrijdende functionaliteit van portemonnees, waaruit blijkt dat ze klaar zijn om door te gaan naar productie bij daadwerkelijke portemonneegebruikers. • Een routekaart beschikbaar hebben voor de implementatie en aanbevelingen voor de verdere ontwikkeling van het ecosysteem, travel en een duurzaamheidsstrategie.
Nadere toelichting volgt over de organisatiestructuur European Wallet Consortium (EWC), plan van aanpak en de planning van de diverse werkpakketten:
- WE Build Business Case: Beschikbare Usecases, bijna 60 UC. Motto is betekenisvolle, alledaagse gebruiksscenario's. De focus is op de sectoren B2B, B2G, B2C en verbinding met single digit gateway (SDG).
- De belangrijke 13 usecases in het Domein Business en Domein Payments.
- Werkpakket voor generieke bouwblokken Testen (machtigingen, handtekeningen etc.), inrichting Communicatie en eisen qua standaard.
- Het consortium is groot en heeft 197 publieke en private organisaties (50% begunstigden, 50% geassocieerde partners.) Deelname uit 24 lidstaten en 4 andere landen (zoals VS, Zwitserland, Oekraïne) voor het leveren voorzieningen AI en Google. Het hart van het consortium wordt gevormd door 13 ondernemingsregisters welke actief mee doen en de Coördinatoren uit Nederland (Min EZ, KVK) en Zweden.
- PreProductie: Vereisten voor deelnemende partners is geen lege EUDI-portemonnees (European Digital Identity Wallet) en essentieel is authentieke bronnen; Wallets voor bedrijven moeten wel zijn gevuld met data.
- Technische implementatie is nu SAML en wellicht in de toekomst mogelijk om naar andere standaarden toe gaan.
Proces naar vaststelling van producten vindt plaats door een Review Group. Zowel private en publieke partij zijn hierbij betrokken.
- Als slot geeft Rob aan dat de plannen ambities zijn te noemen met veel uitdagingen voor de boeg om aan te gaan. Vervolgplanning: In juni 2025 staat een voorbereidende meeting gepland met het consortium voor de officiële start in september 2025.
- Jacques Urlus (NBA) geeft aan behoefte te hebben voor ondersteuning hierbij en meer verbinding. Rob zal vanuit beleidsverantwoordelijkheid separaat contact opnemen met Jacques.
Rob en Ka-Kin worden bedankt voor hun toelichting en deelname!
5. Presentatie DataReportr
Servaas Schrama van Logius informeert het OB over de stand van zaken rondom de ontwikkeling van de applicatie DataReportr. DataReportr is de opvolger van de huidige maandrapportage voor het weergeven van set van data gegevens voor eHerkenning. De DevOps team heeft een nieuwe variant gebouwd om de gegevens voor de maandrapportages via een API-koppeling uit te wisselen. Een API-koppeling wordt gebouwd voor het live rapporteren en het beschikbaar hebben van de actuele cijfers waarbij meegekeken kan worden in de Dienstencatalogus (DC). eIDAS maakt eveneens gebruik van DataReportr voor het opvragen van hun gegevens uit de DC. Het verloop van toename en groei DV afgelopen jaar is hierin tevens op te vragen en te downloaden.
De informatie/cijfers welke weergegeven en beschikbaar (hoe en wanneer) zal zijn via een API-koppeling is in afstemming met de stakeholders (Deelnemers, DV’s en de leveranciers.) De data is voor nu gebaseerd op maandbasis. Afhankelijk van de wensen leveranciers zal in de toekomst de mogelijkheid worden bekeken om op dagelijkse basis te kunnen leveren.
In afstemming met de Deelnemers zullen twee nieuwe cijfers opgenomen worden in DataReportr die nu nog apart worden gerapporteerd nl. TRR-gegevens en geslaagde authenticaties.
Voor de verschillende planningsmomenten (pre-productie en productie) van de technisch omgeving zal een vooraankondiging volgen naar alle stakeholders. Servaas geeft aan dat hij ook persoonlijk contact zal opnemen met leveranciers en DV. Aankondiging voor livegang met eerste dataset in productie is reeds geweest. Men kan zich melden voor deelname voor testomgeving. DDY heeft zich reeds gemeld.
Voorbereiding technische livegang
De eerste technische testen met API voor het aanleveren zijn gestart en worden gesprekken gevoerd UX-specialisten over o.a. de weergave.
René Bonte vraagt aandacht voor:
- Het up-to-date hebben van het dossier “aanleveren maandrapportage” bij het Intaketeam (dossierhouder Frans de Kok).
- De oplossingsrichtingen ‘wanneer en hoe te aanleveren’ van data af te stemmen met de leveranciers.
- Het aanpassen van de inhoud van de rapportage dat dit via het Change en Release proces verloopt. Ideeën en voorstellen eerst inbrengen bij het Intaketeam.
- Dat er nog geen commitment van de leveranciers is voor het aanleveren van gegevens via de API. Dit is een agendapunt voor het Leveranciers Overleg.
Servaas neemt dit mee en geeft aan dat overige input en feedback van harte welkom is. Rond het aankomende PI gaat DataReportr officieel live, dan zal een nieuwe URL gedeeld worden die ook via internet bereikt kan worden. Servaas wordt bedankt voor zijn komst.
6. Afsluiting
De volgende reguliere vergadering is op dinsdag 11 mrt. 2025 en zal digitaal (Teams) plaatsvinden. De uitnodiging hiervoor is reeds verstuurd naar de leden.