Formeel opdrachtgever is de Unit Manager Veiligheid, Architectuur en Standaarden van VNG Realisatie. Beheer van de standaard wordt uitgevoerd door de afdeling Veiligheid, Architectuur en Standaarden van VNG Realisatie.
Het ontwikkelen van een API-standaard inclusief referentie implementatie voor de vastlegging en ontsluiting van de verwerking van (persoons)gegevens. De API-standaard moet aan een aantal eisen voldoen:
Als onderdeel van de API-standaard worden de volgende zaken opgeleverd:
Er komt een nieuwe API-standaard. Deze standaard dient door alle leveranciers die informatiesystemen aan gemeenten leveren waarin persoonsgegevens worden verwerkt moeten worden ingebouwd. De referentie implementaties bieden leveranciers een voorbeeld hoe deze standaard ingebouwd kan worden.
De referentie implementatie is bedoeld als voorbeeld om te laten zien dat de API specificatie implementeerbaar is. Eventuele gedragsregels die niet in de OAS 3 specificatie staan kunnen dan ook gedemonstreerd worden. De referentie implementatie is geen productie waardige software. Het is een proof of concept, geen robuust geprogrammeerde component die direct uitgerold kan worden. Maar om een API implementatie te testen werkt het prima. Bovendien kunnen we door middel van de referentie-implementatie testscripts schrijven (Postman) zodat leveranciers kunnen testen of hun implementaties voldoen aan de standaard.
De referentieimplementatie is bedoeld voor het aantonen van de werking van de API-standaard en geschikt voor gebruik in een testomgeving. De referentieimplementatie is niet geschikt voor gebruik in een productie omgeving. De referentieimplementatie is hiervoor niet geschikt aangezien geen invulling is gegeven aan niet-functionele requirements zoals beschikbaarheid, performance, robuustheid etc. Ook is de ondersteuning vanuit VNG Realisatie tenaanzien van de referentieimplementatie niet ingericht op prodcutioneel gebruik.
Wanneer in de release candidate geen gebreken gevonden zijn en deze daarmee voldoende stabiel is wordt deze release candidate een release. De periode voor deze stabiliteit is vastgesteld op 2 maanden, ingaande vanaf de dag waarop de release candidate uitgebracht is. Onder gebreken wordt verstaan fouten in de standaard. Eventuele verbeteringen of verduidelijkingen in documentatie waarbij geen aanpassingen in de API’s noodzakelijk zijn worden niet beschouwd als reden om een nieuwe release candidate uit te brengen.
Hiervoor is een aantal cases beschreven. Deze zijn terug te vinden op Github:
Het attribuut moet de gebruiker identificeren binnen de context van het systeem. Het mag leeg gelaten worden indien de verwerking door het systeem wordt uitgevoerd. Mocht het systeem ook in dergelijke gevallen werken met ‘gebruikers’ dan mag de systeemgebruiker opgenomen worden.
Ziek ook Attribuut - Gebruiker
De standaard is opgezet om te voorzien in communicatie tussen informatiesystemen via een RESTful API over HTTP. Andere protocollen voor communicatie tussen de systemen wordt nogg niet voorzien.
Er is nog geen duidelijkheid over het bewaartermijn van de logging. Dit onderwerp wordt besproken met de Adviescommissie Archieven van de VNG. Zodra hierover duidelijk is, wordt dit opgenomen in de FAQ.
Nee, dat hoeft geen probleem te zijn. Zolang de vragende partij aangeeft wat het bewaartermijn is, kan de leverende partij dit ongewijzigd overnemen of een eigen bewaartermijn opnemen.
Het informatiesysteem moet zelf bijhouden uit welke informatiesystemen gegevens zijn opgehaald en aan welke informatiesystemen gegevens zijn geleverd. Dit is geen functionaliteit van de verwerkingenloggingcomponent.
De standaard gaat er vanuit dat zowel een provider als een consumer zelf een logging registreren. Een integratieoplossing zoals een ESB wordt gezien als een transparant doorgeefluik. De ESB registeert dus geen logging in het kader van de AVG. Mogelijk dat er wel technische logging wordt vastgelegd, maar dat valt buiten de standaard.
Nee, dat is nu nog niet voorhanden. Samen met gemeenten en leveranciers wordt gekeken wat het beste hierin kan worden gevolgd.
De gegevens moeten ontsloten worden via de RESTful API die gebaseerd is op het informatiemodel. De actie GET moet hierbij verplicht worden geïmplementeerd. Als de verwerkingenlogging niet als federatieve loggingcomponent aan andere consumers wordt aangeboden, hoeven de andere acties niet naar buiten toe worden opengesteld of geïmplementeerd.
Ja, als het gemeentelijk register van verwerkingsactiviteiten via een URL te benaderen is, is deze in elke externe pagina op te nemen.
Het verwerkingenloggingregister kan alleen met de juiste authenticatie en autorisatie benaderd worden. Communicatie tussen MijnOverheid en een gemeentelijk register vraagt extra inspanningen van beide partijen. Voorlopig is daarin nog niet voorzien, maar mogelijk dat dit in de toekomst wel gerealiseerd kan worden.
Er is gekeken naar kaders en richtlijnen zoals deze in de zorg worden toegepast. In Europa zijn wel initiatieven gestart, maar leveren nog geen concreet product op.
Op Github is opgenomen wanneer welke veranderingen zijn doorgevoerd. Zie hiervoor Voortgang ontwikkeling API-standaard voor logging van verwerkingen