search

minvws / generiekefuncties-lokalisatie

Repo generiekefuncties-lokalisatie for minvws
https://irealisatie.nl
1 stars 3 forks source link

Communicatie met 2 niet-bsn gerechtige partijen mbv pseudoniem over het zelfde BSN #3

Open stevenvegt opened 6 months ago

stevenvegt commented 6 months ago

We hebben de volgende architectuur uitdaging mbt het gebruik van pseudoniemen:

3 Partijen:

  1. Zorgaanbieder 1 (ZA1) de raadplegende partij.
  2. Lokalisatie Register (LR)
  3. Toestemmingsvoorziening (TV)

LR en TV mogen beiden geen BSN verwerken LR moet de toestemming controleren voordat het gegevens mag vrij geven

Stappen: 1-2: ZA1 vraagt voor BSN 2 DEPs aan: DEP(BSN)@LR en DEP(BSN)@TV

  1. ZA1 vraagt lokalisatie gegevens op aan LR en geeft beide DEPs mee.
  2. LR kan DEP(BSN)@TV gebruiken bij TV om de toestemming te controleren.

Probleem: Hoe kan LR vaststellen dat beide DEPs bij het zelfde BSN horen (en de toestemming dus kan vertrouwen)?

sequenceDiagram
autonumber
ZA1 ->> BSNk : request DEP(BSN)@[LR,TV]
BSNk -->> ZA1: [DEP(BSN)@LR, DEP(BSN)@TV)]
ZA1 ->> LR: request Lokalisatie(DEP(BSN)@LR, DEP(BSN)@TV)
LR ->> TV: request toestemmingen(DEP(BSN)@TV)
TV -->> LR: toestemmingen
LR -->> ZA1: lokalisatie informatie
PieterVanGemeren commented 6 months ago

Voor duidelijkheid: het gaat over de situatie dat ZA1 niet te vertrouwen is. Dus is voor LR niet zeker dat beide deb's tot zelfde BSN behoren. Hierdoor kan TV een andere toestemming van een ander BSN aan LR retourneren. Oplossing kan zijn dat BSNk bij uitgifte van deb's in stap 2, de deb's cryptografisch aan elkaar linked. Kan dit?

PieterVanGemeren commented 6 months ago

Is gefixed, kan gesloten worden. BSNk kan de binnenkomende DEP call, waarbinnen meerdere DEP's tegelijk opgevraagd worden, in het antwoord als geheel signen zodat onafhankelijk kan worden gevalideerd of DEP's bij elkaar horen.