Repository navigation
Review RvIG #44
Description
- Algemeen: er wordt vaak gesproken over ‘afnemer’. Op zich begrijpelijk, maar in het geval van PID-verstrekking hebben wij het over ‘gebruiker’. Ik denk niet dat we zomaar kunnen uitgaan van ‘gebruiker = afnemer’. Indien in een specifieke beschrijving een gebruiker ook valt onder ‘afnemer’ is het wellicht handig om dat dan ook expliciet te vermelden.
Het begrip afnemer is opgenomen in de begrippenlijst: het is de afnemer van de gegevensdienst van de bronhouder. Dat kan dus ook een burger met een Wallet zijn. - Generieke functie 3 – Gegevensvoorziening. Hier wordt gesteld dat “de afnemer kan exact de velden opvragen die voor het specifieke gebruik nodig zijn”.
- Uitgaande van hergebruik van GBO voor PID-verstrekking wordt dat lastig: de inhoud van een PID staat (vrijwel) vast want moet leiden tot een unieke identificatie in Nederland van de gebruiker. Alleen m.b.t. de pasfoto heeft de gebruiker de mogelijkheid tot opt-out. Maar pasfoto is vooralsnog buiten scope van de opdracht aan RvIG.
De afnemer kan alleen velden opvragen binnen de gegevensset die bij de dienst hoort, maar kan dus ook minder opvragen. Als een Wallet/gebruiker/QTSP een PID opvraagt, zal hij de gehele gegevensset opvragen. Technisch hoeft dat niet, maar functioneel heeft het opvragen van een deel van de gegevensset geen zin.
- Uitgaande van hergebruik van GBO voor PID-verstrekking wordt dat lastig: de inhoud van een PID staat (vrijwel) vast want moet leiden tot een unieke identificatie in Nederland van de gebruiker. Alleen m.b.t. de pasfoto heeft de gebruiker de mogelijkheid tot opt-out. Maar pasfoto is vooralsnog buiten scope van de opdracht aan RvIG.
- Generieke functie 4 — Semantiek & Eenheid van Taal. Hier wordt gesteld dat GBO de beschrijving beheert van de beschikbaar gestelde gegevenselementen.
- Ik neem aan dat het eigenaarschap van begrippen en definities bij de betreffende bronhouders blijft liggen?
Dit wordt nog uitgewerkt, maar het zal waarschijnlijk een gedeeld beheer worden: voor bepaalde gegevensdiensten (OOTS evidence requests, attestatieverzoeken, ...) worden er mogelijk centraal gegevenssets bepaald, waar de bronhouder via een semantische mapping zijn gegevens op kan mappen. Die mapping is de verantwoordelijkheid van de bronhouder.
- Ik neem aan dat het eigenaarschap van begrippen en definities bij de betreffende bronhouders blijft liggen?
- Generieke functie 5 — Gegevenskwaliteit & Validatie. Hier word gesteld:
- “Afnemers kunnen geconstateerde onjuistheden terugmelden via een gestandaardiseerde feedbackloop; terugmeldingen zijn herleidbaar tot de specifieke gegevenslevering.”
- De BRP-V is de authentieke bron van PID-attributen. Als de gebruiker van mening is dat attributen een verkeerde waarde hebben, dient hij contact op te nemen met de gemeente van inschrijving (of als dat niet leidt tot het gewenste resultaat: met het MFO), niet met (RvIG in haar rol als) de PID-verstrekker.
De feedbackloop moet nog uitgewerkt worden; mogelijk loopt deze direct naar de plek waar het gegeven aangepast kan worden, of gaat deze naar de gegevensleverancier, die het dan moet doorsturen naar de plek waar het gegeven aangepast kan worden.
- De BRP-V is de authentieke bron van PID-attributen. Als de gebruiker van mening is dat attributen een verkeerde waarde hebben, dient hij contact op te nemen met de gemeente van inschrijving (of als dat niet leidt tot het gewenste resultaat: met het MFO), niet met (RvIG in haar rol als) de PID-verstrekker.
- “Gegevensherkomst (bronhouder, tijdstip, versie) is altijd meegeleverd bij uitgewisselde gegevens.”.
- Dit zou m.i. betekenen dat RvIG deze attributen moet opnemen in de optionele meta-data van de PID.
Dit wordt nog uitgewerkt - kan in de metadata, maar ook in de (gerelateerde) logging.
- Dit zou m.i. betekenen dat RvIG deze attributen moet opnemen in de optionele meta-data van de PID.
- “Afnemers kunnen geconstateerde onjuistheden terugmelden via een gestandaardiseerde feedbackloop; terugmeldingen zijn herleidbaar tot de specifieke gegevenslevering.”
- Generieke functie 8 — Beheer & Continuïteit: hier wordt gesteld “Wallet-lokale logs (EDI-traject) vallen buiten de server-side correlatie”.
- Met betrekking tot PID-verstrekking zullen we goede afspraken moeten maken wat waar wordt gelogd.
Ja, hier moeten goede afspraken over gemaakt worden. In de PSA is dit als vraagstuk B-10 opgenomen.
- Met betrekking tot PID-verstrekking zullen we goede afspraken moeten maken wat waar wordt gelogd.
- S07 — Gegevensontsluiting (Bronontsluiting API) Hier wordt gesteld “Selectieve uitvraag is structureel mogelijk”.
- In het geval van een PID is dat beperkt mogelijk. Zie eerdere opmerking over de samenstelling van een PID.
Dat klopt, deze functionaliteit is minder relevant voor PID-verstrekking.
- In het geval van een PID is dat beperkt mogelijk. Zie eerdere opmerking over de samenstelling van een PID.
- S11 — Attesteringsuitgifte (PuBEAA / QEAA). Hier wordt gesteld “Intrekkingsbeleid: wanneer een attestering wordt ingetrokken en hoe de statuslijst wordt bijgehouden“
- Vooruitlopend op de mogelijkheid dat RvIG ook Verstrekker PubEAA’s wordt: in dat geval houdt RvIG – analoog aan de PID – zelf de status bij en publiceert een statuslijst
Dit zien we inderdaad als een dienst die vooral bij de rol van PubEAA-verstrekker hoort. Als RvIG die dienst niet gebruikt dan zal zelf het intrekkingsbeleid moeten invullen.
- Vooruitlopend op de mogelijkheid dat RvIG ook Verstrekker PubEAA’s wordt: in dat geval houdt RvIG – analoog aan de PID – zelf de status bij en publiceert een statuslijst
Activity
Govert-Claus commentedon Aug 17, 2026
Zie reacties in het issue.
Govert-Claus commentedon Oct 20, 2026
Verwerkt in v0.9.5