Voor vraagberichten zijn er in StUF zes mogelijkheden benoemd om de breedte (elementen per object in het resultaat) van het antwoord te bepalen. De eerste vijf maken gebruik van het attribuut scope om een voorgedefinieerde set van elementen/relaties op te vragen, de laatste gebruikt het scope-object om per vraag een specifieke set op te geven.
In het kader van de AVG is het volgens Centric wenselijk om in vraagberichten met privacygevoelige gegevens (met name dus voor de NPS-vraagberichten, maar ook in andere gevallen) het gebruik van scope=”alles” te verbieden. Een vraag om persoonsgegevens moet altijd gesteld worden vanuit een zeker doel, waarmee ook de opgevraagde gegevens moeten worden beperkt tot die gegevens die voor dat doel noodzakelijk zijn. Meer gegevens mogen niet worden gevraagd. Daarmee is gebruik van scope=”alles” dus zelden tot nooit toegestaan. Ook het gebruik van de andere waarden voor dit attribuut zal (voor persoonsgegevens) zelden van toepassing zijn.
Hiermee is de meest eenvoudige manier om de scope van een vraag te specificeren een manier die in het algemeen niet toegestaan is voor persoonsgegevens. De methode wordt echter vaak gebruikt en in onze ogen dus misbruikt. Hierbij dient ook te worden opgemerkt dat alle gegevens die gevraagd worden moeten worden vastgelegd in een log, omdat ze over de lijn gaan. De eindgebruiker ziet deze gegevens niet in zijn/haar scherm, maar ze staan vanuit de zender van de informatie wel gelogd als verstrekt aan die gebruiker.
Het gebruik van het scope-attribuut geeft een resultaat dat in het algemeen breder zal zijn dan wat de vraagsteller op dat moment echt nodig heeft. Voor privacygevoelige gegevens is dit niet wenselijk vanuit de AVG (en privacy-redenen in het algemeen), maar in het algemeen geldt ook dat het beantwoordende systeem gegevens moet aanleveren die niet nodig zijn. Dit leidt mogelijk tot zwaardere verwerking (meer gegevens moeten worden verzameld) en in ieder geval tot grotere antwoordberichten (meer gegevens). Daarom zou een verdergaande optie kunnen zijn om het scope-attribuut voor alle vraagberichten te verbieden en niet alleen voor berichten met persoonlijke gegevens.
Om systeemontwikkelaars/-leveranciers te verplichten goed na te denken over welke gegevens zij vragen, willen we ze dus dwingen om expliciet op te geven welke gegevens dat zijn. In ieder geval willen wij voorstellen om het scope-attribuut te verbieden voor berichten met persoonsgegevens (in het kader van de AVG). Een optie is om het scope-attribuut helemaal te verwijderen uit de specificaties.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0503.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Nog los van de inhoud vraag ik me af of dit een discussie is op niveau van StUF en de StUF EG. Betreft dit niet eerder een governance-vraag over de inrichting van het gegevensmanagement? In principe verandert de AVG deze afweging verder niet, de juridische kaders op het vlak van doelbinding bestaan al jaren. Positief dat de AVG voor meer aandacht hiervoor zorgt, maar deze kan aangezien de regels op dit vlak feitelijk niet veranderen m.i. niet de argumentatie vormen om zaken te moeten veranderen.
In het voorstel van Sid lijkt de vraagsteller volledig verantwoordelijk voor de protocollering en autorisatie. De stelling dat het beantwoordende systeem 'alle' gegevens moet aanleveren (met een mogelijk zwaardere en dus juridisch onjuiste gegevensverwerking) als een vragende applicatie daarom vraagt lijkt me echter niet juist. M.i. dient de antwoordende partij (als een Gegevensmagazijncomponent) altijd te werken met een geautoriseerd en geprotocolleerde inrichting conform de doelbinding voor de betreffende vragende partij. Hierdoor kan het überhaupt niet voorkomen dat i.h.k.v. de AVG niet toegestane gegevensverwerking plaatsvinden, voor de (niet geautoriseerde) elementen wordt dan geantwoord met nietGeautoriseerd. Een vragende partij zou in deze situatie scope="alles" wellicht ook kunnen zien als "geef mij alle gegevens terug waartoe ik geautoriseerd ben".
Verder is het uitgangspunt om systeemontwikkelaars/-leveranciers te verplichten goed na te denken over welke gegevens zij vragen uiteraard alleen maar goed. Het beeld dat met de scope="alles" werkwijze niet voldaan kan worden aan de AVG vind ik echter onterecht, aangezien in alle gevallen de bron slechts gegevens terug zal mogen geven waartoe de vragende partij geautoriseerd is, met of zonder gebruik van scope="alles".
Uiteraard moet de antwoordende partij het antwoord beperken tot die gegevens waarvoor de vrager is geautoriseerd. Dat neemt niet weg dat de vrager zelden of nooit alle gegevens nodig heeft waarvoor hij geautoriseerd is. De vraag komt voort uit een context binnen het systeem: binnen een bepaalde functie van de applicatie zijn op dat moment gegevens nodig. Welke gegevens dat zijn, is afhankelijk van de context.
Een voorbeeld: om te bepalen of een client recht heeft op een uitkering, kan het van belang zijn te weten of de persoon gehuwd is en/of kinderen heeft. Een applicatie voor de sociale dienst mag dergelijke gegevens dus opvragen. Wil je nu vanuit diezelfde applicatie een brief versturen naar een client of een (andere) belanghebbende, dan heb je alleen maar naw-gegevens nodig.
Het antwoordende systeem is zich niet bewust van de context waarbinnen de vraag wordt gesteld en kan dus nooit bepalen welke gegevens (waarvoor de vrager is geautoriseerd) ook daadwerkelijk nodig zijn op het moment dat de vraag wordt gesteld. Daarmee kan de zender dus ook nog steeds gegevens verstrekken waar de vrager (op dat moment) feitelijk niet om zou mogen vragen. Daarmee is autorisatie alleen dus niet voldoende om ongewenste gegevensuitwisseling te voorkomen. Het verbieden van scope="alles" kan dit ook niet voorkomen, maar dwingt de vrager meer om na te denken over de vraag die wordt gesteld.
Met betrekking tot het noemen van de AVG als reden voor dit voorstel: Inderdaad is het zo dat dit issue feitelijk al heel lang bestaat en niet direct afhankelijk is van de AVG. Dat neemt niet weg dat (met de AVG als trigger) het zinvol is om alsnog de werking tegen het licht te houden.