API design rule no-sensitive-uris (No sensitive information in URIs) lost het onderliggende probleem niet volledig op. Het verwijderen van bijvoorbeeld een BSN als URL-parameter in verband met mogelijke opname in logging is wel een valide argument, maar in de meeste gevallen wordt deze gevoelige data noodgedwongen verplaatst naar de payload van het bericht en dat is geen goede beheersingsmaatregel. De reden hiervan is dat de payload van een bericht ook kan worden gelogd afhankelijk van de instelling van de gebruikte API-Gateway. In dat geval komen de BSN’s alsnog in de logbestanden terecht.
Daarnaast is een ongewenst gevolg van het verplaatsen van URL-parameters naar de payload dat linked-data technieken niet meer kunnen worden toegepast. Dit kan blokkerend zijn voor het effectief kunnen implementeren van het principe van data bij de bron in een federatief stelsel van registraties.
De eerste vraag is of we deze API design rule kunnen voorzien van een disclaimer zodat de API-designer niet op het verkeerde been wordt gezet door te denken dat met het verplaatsen van de gevoelige data van de URL naar de payload het probleem volledig oplost is.
Tweede vraag: zijn er al concrete oplossingen in de maak voor dit onderliggende probleem? Wellicht polymorfe pseudoniemen en het gebruik van het BSN-k om BSN’s te versleutelen.
API design rule no-sensitive-uris (No sensitive information in URIs) lost het onderliggende probleem niet volledig op. Het verwijderen van bijvoorbeeld een BSN als URL-parameter in verband met mogelijke opname in logging is wel een valide argument, maar in de meeste gevallen wordt deze gevoelige data noodgedwongen verplaatst naar de payload van het bericht en dat is geen goede beheersingsmaatregel. De reden hiervan is dat de payload van een bericht ook kan worden gelogd afhankelijk van de instelling van de gebruikte API-Gateway. In dat geval komen de BSN’s alsnog in de logbestanden terecht.
Daarnaast is een ongewenst gevolg van het verplaatsen van URL-parameters naar de payload dat linked-data technieken niet meer kunnen worden toegepast. Dit kan blokkerend zijn voor het effectief kunnen implementeren van het principe van data bij de bron in een federatief stelsel van registraties.
De eerste vraag is of we deze API design rule kunnen voorzien van een disclaimer zodat de API-designer niet op het verkeerde been wordt gezet door te denken dat met het verplaatsen van de gevoelige data van de URL naar de payload het probleem volledig oplost is.
Tweede vraag: zijn er al concrete oplossingen in de maak voor dit onderliggende probleem? Wellicht polymorfe pseudoniemen en het gebruik van het BSN-k om BSN’s te versleutelen.