In documentatie Minimale en Volledige logging is ook beschreven welke http-header meegegeven moeten worden. Deze elementen komen ook voor de requestBody van de specificatie. Wordt verwacht dat overeenkomstige elementen (bv. verwerkingsactiviteitId, vertrouwelijkheid, bewaartermijn, ...) zowel in de vorm van een http-header als in de requestBody in een request worden opgenomen?

NB. De voorbeeldvulling voor 'bewaartermijn' is nog niet aangepast aan nieuwe format.

Via Swagger kijkend naar de POST-specificatie zie ik de Request-body enkele verschillen ten opzichte van de opsomming 'Volledige logging' (https://github.com/VNG-Realisatie/gemma-verwerkingenlogging/blob/master/docs/_content/quickstart/index.md#Volledige-logging-van-verwerkingen); dit betreft:

Gegevens afnemer:

"soortAfnemerId": "OIN",
"afnemerId": "00000001821002193000",
"verwerkingsactiviteitIdAfnemer": "c5b9f4e7-8c79-41b9-91e2-6268419cb167",
"verwerkingsactiviteitUrlAfnemer": "https://www.amsterdam.nl/var/api/v1/verwerkingsactiviteiten/5f0bef4c-f66f-4311-84a5-19e8bf359eaf",
"verwerkingIdAfnemer": "4b698de3-ffba-45e7-8697-a283ec863db2",

Gegevens verwerkte objecten; per object:

"verwerkteSoortenGegevens": [
{
"soortGegeven": "BSN"
}
]

Hoe verhoudt zich dit tot de opsomming 'Volledige logging van verwerkingen'?

Naar aanleiding van terugkoppeling die het project heeft ontvangen van fouten in de OAS-specificaties zijn aanpassingen aan deze specificaties gemaakt. Deze wijzigingen leiden tot breaking changes ten aanzien van de 1.0.0 RC1 release. Om deze reden is besloten een nieuwe release candidate aan te maken (1.0.0 RC2). Wijzigingen in de OAS-specificaties hebben onder andere te maken met:

• foutieve lengtes van een aantal velden,
• wijziging van de manier van doorgeven van het vertrouwelijkheid attribuut,
• het ontbreken van de foutcode 400 (Bad Request) in de GET van verwerkingacties, en
• incorrect gebruik van minLength bij het attribuut verwerkingsactiviteitUrl.
• ook is overbodig commentaar uit het yaml-bestand verwijderd.

Deze week (14 april) is gestart met de ontwikkeling van de referentie implementatie van de providerkant van de Verwerkingenlogging API op basis van de 1.0.0 RC2 specificaties. De verwachting is dat de ontwikkeling van deze referentie implementatie ongeveer 5-6 weken in beslag zal nemen. De referentie implementatie zal via Github (source code) en de vng.cloud omgeving (werkende implementatie) ter beschikking worden gesteld.

Tijdstip: hier dient het formaat logDateUtc gebruikt te worden, voorbeeld
"2018-06-22T14:30:08.4714372Z"
Op die manier worden verschillen in tijdzones automatisch op een juiste wijze verwerkt.

Voor deze Id is ook de UUID opgenomen als specificatie. Ik heb daar een vraag over.
Er zijn al diverse oplossingen actief die een eigen unieke id aan een registratie toekennen. Mogen deze ook worden toegepast? Denk aan een ID als a2Tq9HUBJMs2i1O01eJP.
Ik zou nog een extra argument hiervoor willen aandragen De UUID is gebaseerd op een timestamp en min of meer gebeurtenis gerelateerd. De verwerkingsactiviteit kent daarentegen een levenscyclus met wijzigingen.

Misschien dat ik ergens nog iets over het hoofd zie maar toch maar even deze vraag:
Hoe verhoudt zicht het vastleggen van meerdere personen in één log zich tot het bevragen van de vastgelegde logs?
Hoe zien jullie het bevragen van de logs? Als dat namelijk voor een burger wordt opgevraagd, mag die toch alleen zijn eigen gegevens weten? Of zien jullie ook een bevraging met als zoekcriterium een bepaalde verwerking die alle betrokken personen laat zien? Wat zou de rechtmatigheid van een dergelijke bevraging zijn?

Gedurende de ontwikkeling van een referentieimplementatie van de providerkant van de API-standaard (een verwerkingenlogcomponent) zijn we binnen VNG-R tot de conclusie gekomen dat de verantwoordelijkheden van de provider- en de consumerkant van de API-standaard scherper gescheiden moeten worden. Voor het beheren/muteren van verwerkingen voldoet de ontwikkelde API-standaard naar onze mening, maar voor het ontsluiten van verwerkingsacties rondom specifieke verwerkte objecten is verbetering van de standaard mogelijk en gewenst.

In de huidige (RC2) standaard bevragen consumers de verwerkingsacties rondom een verwerkt object (bijvoorbeeld een persoon via BSN) via de verwerkingsacties resource. Bij de implementatie van de referentieimplementatie is gebleken dat deze constructie van het bevragen van een child- via een parentresource onhandig is en in veel gehanteerde (REST) frameworks leidt tot extra ontwikkelinspanning.

Besloten is om het bevragen van een verwerkingenlog door een consumer (bijvoorbeeld een MijnGemeente component) en het bijhouden van dat log door procesapplicaties van elkaar te scheiden. Voor het bijhouden van het verwerkingenlogcomponent wordt de API-standaard gehanteerd zoals in RC2 gepubliceerd. Voor het ontsluiten van de verwerkingenlogcomponent richting consumers wordt een nieuwe API-standaard ontwikkeld waarin de verwerkte objecten via een verwerkteObjecten resource benaderbaar worden gemaakt. De standaard voor het muteren en de standaard voor de ontsluiting gaan beiden uit van het informatiemodel Verwerkingenlogging maar gebruiken een ander uitwisselingsmodel (UGM). Voor al ontwikkelde verwerkingenlogcomponenten veranderd er ten aanzien van de bijhouding van het verwerkingenlog niets. Voor het ontsluiten van gelogde verwerkingsacties naar consumers zal een nieuwe API-functie met bijbehorende autorisatiescopes geïmplementeerd moeten worden.

De referentieimplementatie, de Github repository en de architectuurdocumentatie op GEMMAonline worden aangepast. Deze wijziging leidt tot een nieuwe Release Candidate (RC3) die naar verwachting in week 29 in de master branch wordt gepubliceerd.

De bewaartermijn zou niet in jaren maar in dagen vastgelegd moeten worden.
Dat maakt het automatisch schonen bij verlopen van de termijn veel eenvoudiger.
Ook een bewaartermijn van minder dan een jaar of een deel van een jaar kan dan gehanteerd worden.

In de AVG staat verwerken gedefinieerd als ” een bewerking of een geheel van bewerkingen met betrekking tot persoonsgegevens of een geheel van persoonsgegevens, al dan niet uitgevoerd via geautomatiseerde procedés, zoals het verzamelen, vastleggen, ordenen, structureren, opslaan, bijwerken of wijzigen, opvragen, raadplegen, gebruiken, verstrekken door middel van doorzending, verspreiden of op andere wijze ter beschikking stellen, aligneren of combineren, afschermen, wissen of vernietigen van gegevens”.

Zijn dit de verwerkingsacties zoals bedoeld op https://vng-realisatie.github.io/gemma-verwerkingenlogging/gegevenswoordenboek/objecttypen/Verwerkingsactie.html? Is er een waardenlijst (uit een bepaald domeinmodel) beschikbaar?