TMLO: Integriteit uitwisselen over APIs

sergei-maertens commented 5 years ago

In de context van de ZDS 2.0 services was ik bezig met TMLO-integriteit informatie toe te voegen aan de API, en ik liep tegen een hoop praktische problemen aan (vooral op het gebied van machine-naar-machine communicatie). Ik denk dat het handig is om hier overeen te komen hoe dit er zou moeten uitzien op landelijk niveau, wat we vervolgens terug kunnen brengen naar de bedenkers van TLMO in een request-for-change.

Het gaat om Fysieke integriteit

Dit is een gegevensgroeptype dat bestaat uit drie onderdelen: algoritme, waarde en datum.

algoritme

Er zijn een hoop mogelijke algoritmes om de checksum te bepalen, en er worden voorbeelden gegeven:

“Longitudinal parity check”
“Fletcher’s checksum”
“Cyclic redundancy checks (CRCs)”

Dit is problematisch om een aantal redenen:

deze lijst is moeilijk te begrijpen voor machines/clients - er is geen exhaustieve lijst van mogelijke algoritmen, dus je kan een algoritme tegenkomen wat je niet ondersteunt (puur omdat je niet wist dat je het zou moeten ondersteunen)
de waarden zijn in essentie een 'vrij tekstveld'. Ik kan dus naar CRC refereren met de Engelse naam, de Nederlands naam of de afkorting CRC. Dit is veel te vaag in een gegevenslandschap waar machines met machines praten.

Voorstel (dit is hoe ik het ga uitwerken in ZDS 2.0): definieer een enum met de mogelijke algoritmes, gebaseerd op https://en.wikipedia.org/wiki/List_of_hash_functions:

algoritme:
  type: string
  enum:
  - CRC-16
  - CRC-32
  - CRC-64
  - fletcher-4
  - fletcher-8
  - fletcher-16
  - fletcher-32
  - HMAC
  - MD5
  - SHA-1
  - SHA-256
  - SHA-512
  - SHA-3

Deze (initiele) set is op dit moment arbitrair gekozen op wat ik zelf vaak voorbij zie komen - ik heb er geen idee van welke algoritmes op dit moment effectief gebruikt worden binnen Nederland. Het spreekt voor zich dat algoritmes die al in gebruik zijn en ontbreken, aan de lijst zouden moeten toegevoegd worden.

waarde

In het informatiemodel staat beschreven dat de waarde van de checksum numeriek is. Dit valt al uiteen op het moment dat je MD5-checksums gebruikt (komt nog enorm veel voor) - die bevat ook letters.

M.i. moet de waarde dan ook aangepast worden naar alfanumerieke waardes. In de Wikipedia tabel zie ik als maximale lengte 512 bits, in hexadecimale uitwisseling krijg je dan een veld dat maximaal 128 karakters lang is. Dit zou dus maken:

waarde:
    type: string
    minLength: 1
    maxLength: 128

in OpenAPI schema.

ehotting commented 5 years ago

Nagevraagd bij een intern expert.

"Vorig jaar is $onze_applicatie gemapt op TMLO en daar kwam uit dat $onze_applicatie daar nog niets doet met fysieke integriteit. We kunnen uiteraard wel uit technische metadata en auditlog aannemelijk maken dat degene die parafeert of tekent ook de juiste persoon is en wie documenten wijzigt, etc. Maar geen checksums of algoritmes.

Binnen Zaakgericht Werken hebben we er ook nog niets mee gedaan."

Ik schat in dat het bij veel gemeenten zo werkt, wat veel vrijheid geeft om het technisch te implementeren op een manier die ons nu verstandig lijkt.

joeribekker commented 5 years ago

Van Theo Peters begrepen dat VNG heeft een advies commissie heeft die hier iets over kan zeggen.

mrtn78 commented 3 years ago

@joeribekker, heb je al iets over dit punt gehoord van de advies commissie ? Voor zover bekend zijn hier op dit moment nog geen extensies voor.

joeribekker commented 3 years ago

Niet dat ik mij kan herinneren van de afgelopen 2,5 jaar ;-)

Geonovum / KP-APIs

TMLO: Integriteit uitwisselen over APIs #342