Als een consumer de API van een provider aanroept wordt onderstaande informatie meegegeven:
Deze informatie wordt in de header van het bericht meegegeven en dus niet in de payload.
Bij de provider wordt deze informatie bij verwerkingenlogging opgenomen in de volgende attributen:
Zie de toelichting op B8157 (Opname van Verwerking ID en Verwerking ID afnemer) voor een voorbeeld verwerkingenlog van consumer en provider.
De informatie wordt bewust in de header en niet in de payload meegegeven. Dit voorkomt dat alle koppelvlakken van de gemeente aangepast moeten worden. Natuurlijk moet er ook nu ‘achter’ alle koppelvlakken werk verzet worden. Maar dat werk is inherent aan het goed implementeren van de AVG.
Door de informatie in de header te zetten en niet in de payload houden we alle systemen maximaal ontkoppeld. Hierdoor kunnen leveranciers in hun eigen tempo de verwerkingenlogging standaard implementeren. Hopelijk verhoogt dit de snelheid van de realisatie en implementatie.
Als gemeente X een koppelvlak van gemeente Y aanroept dan zou gemeente Y in ieder geval de volgende zaken moeten controleren:
We zien dan functie 1 en 2 vaak al buiten de applicatie gecontroleerd worden met behulp van zogenaamde offloaders. Deze gebruiken daarvoor bijvoorbeeld het PKIoverheid-certificaat dat gebruikt is voor ondertekening van het bericht.
Functie 3 (functionele autorisatie) kan normaal gesproken niet door dit soort offloaders uitgevoerd worden. Er is te veel applicatie specifieke informatie nodig om te kunnen bepalen of de afnemer geautoriseerd is.
Lastige is dat de applicatie vaak niet weet wie de API aangeroepen heeft. Deze informatie is bijvoorbeeld aanwezig in het PKIoverheid-certificaat. Dit certificaat bevindt zich echter op een andere laag in het OSI-model en wordt doorgaans niet doorgegeven aan de applicatie. Daar komt nog bij dat het steeds gebruikelijker is dat het verkeer niet loopt via de infrastructuur van de gemeente maar via die van haar leveranciers. Vaak machtigt de gemeente de leverancier en lopen signing en encryptie via de certificaten van die leverancier.
In B7259 (Verwerkingen loggen aan beide kanten van een API) is de relatie tussen functionele autorisatie en het VAR geschetst. Zonder geldige doelbinding, ofwel zonder een verwerkingsactiviteit in het VAR, mag er niet geautoriseerd worden. Het ligt daarom voor de hand om dit proces te vereenvoudigen en het OIN van de consumer mee te geven.
N.B. Het meegeven van het OIN ontslaat de provider niet van ‘de verplichting’ om te controleren of het PKIoverheid-certificaat en het OIN bij elkaar kloppen.
Bij het uitwerken van de cases is gebleken dat dit de minimale informatie is die meegegeven dient te worden om uiteindelijk te kunnen voldoen aan de in de AVG gestelde eisen. Het meegeven van informatieactiviteit lijkt niet vereist maar lijkt vanuit de dienstenaanbieder wel gewenst. Door raadpleging hiervan kan een dienstenaanbieder controleren of de afnemer daadwerkelijk beschikt over een doelbinding.