Inleiding
Tijdens de POC machtigen is een aantal zaken naar voren gekomen die behandeld moeten worden. Deze uitwerking bevat een diepere beschrijving van de gevonden issues en een beschrijving van de mogelijk te nemen stappen.
Koppelingen
bevindingen
Combineren van dossiers
Bij vertegenwoordiging maakt de Vertegenwoordiger gebruik van de PGO van de Vertegenwoordigde. Hierbij krijgt de Vertegenwoordiger een account bij de PGO, waarmee hij/zij gebruik kan maken van het Dossier van de Vertegenwoordigde. Bij de DVP is dus bekend om wie het gaat, maar er is geen BSN bekend. Bij de DVA is dit echter niet persé het geval.
Om bij de DVA te kunnen autoriseren, moet de Vertegenwoordiger geauthenticeerd worden. Tijdens het authenticatieproces wordt gevraagd of de Vertegenwoordiger namens iemand anders gebruik gaat maken van de diensten en namens wie dat is. Indien een Vertegenwoordiger door meerdere Personen gemachtigd is hen te vertegenwoordigen, krijgt de Vertegenwoordiger een lijst te zien van de Personen die hij/zij vertegenwoordigt. De Vertegenwoordiger kiest de Vertegenwoordigde namens wij hij gegevens wil verzamelen/delen. Gedurende dit proces kan een Vertegenwoordiger een andere Vertegenwoordigde kiezen (per ongeluk of met opzet) dan voor wie hij op dat moment gebruikmaakt van de PGO. Zonder verdere controles vermengt de Vertegenwoordiger verschillende dossiers met elkaar, bewust of onbewust.
Oplossingsrichtingen
De volgende onderstaande opties zijn goed genoeg om te onderzoeken:
- 4.4. Gegevensdienst voor identificerende gegevens.
- 4.3.1. Scherm voordat gegevens worden opgehaald.
- 4.3.2. Gegevens in tijdelijke box, scherm om gegevens naar dossier te verplaatsen
- 4.2.4. Identificerende gegevens meegestuurd met token response.
Daarnaast moet gestreefd worden naar een situatie waarin beide domeinen gebruik kunnen maken van dezelfde geauthentiseerde identiteit, waarbij onderzocht moet worden of het gebruik van BSN dan noodzakelijk is.
Ideale situatie
Het probleem van vermenging van dossiers wordt opgelost als in beide domeinen gebruikgemaakt kan worden van dezelfde identifier voor een persoon, bijvoorbeeld het BSN (of polymorfe pseudoniemen). Het BSN kan gedeeld worden, waardoor op meerdere momenten in het proces gecontroleerd kan worden of in beide domeinen dezelfde Vertegenwoordiger en dezelfde Vertegenwoordigde worden gebruikt. Hierdoor kunnen de systemen controleren of de identifiers gelijk zijn. Zo niet, kan een foutmelding worden getoond en kan de flow worden afgebroken.
Autorisatie server gekoppeld met resource server of xIS
Zolang de autorisatie server gekoppeld is met de resource server, of directe toegang heeft tot het xIS, kan de autorisatie server identificerende gegevens ophalen. Hiermee kan een controle op de Vertegenwoordigde worden uitgevoerd.
Identificerende gegevens meegestuurd met authorization request
Als de DVP in het Authorization request vooraf gedefinieerde identificerende gegevens van de vertegenwoordigde meestuurt en de Authorization server dezelfde gegevens kan ophalen bij de Resource server (of direct bij het xIS), kan de Authorization server een controle doen op deze gegevens. Door de gegevens van de DVP te vergelijken met de gegevens uit de Resource server kan met enige zekerheid worden bepaald of de gegevens gaan over dezelfde Vertegenwoordigde. Indien de vergelijking een negatief resultaat heeft, toont de Authorization server een scherm waarop het resultaat van de vergelijking getoond wordt en de vraag of de Vertegenwoordiger wilt stoppen of doorgaan.
Voordeel: De controle wordt vroeg in het proces uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
Nadeel: Identificerende gegevens worden op een onveilige manier gedeeld, namelijk in een redirect van de browser. (mogelijke oplossing is gebruikmaken van Pushed Authorization Request)
Nadeel: Door het scherm te tonen kan iemand nog steeds bewust gegevens van verschillende personen vermengen in één dossier.
Identificerende gegevens meegestuurd met authorization response
Als de Authorization server gedefinieerde identificerende gegevens van de Vertegenwoordigde kan ophalen bij de Resource Server of het xIS, kunnen deze gegevens worden teruggestuurd naar de DVP. De DVP kan dan een controle doen van deze identificerende gegevens tegen de eigen gegevens. Indien de vergelijking een negatief resultaat heeft, toont de DVP een scherm waarop het resultaat van de vergelijking getoond wordt en de vraag of de Vertegenwoordiger wilt stoppen of doorgaan.
Voordeel: De controle wordt vroeg in het proces uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
Nadeel: Identificerende gegevens worden op een onveilige manier gedeeld.
Identificerende gegevens meegestuurd met token request
In vergelijking met optie 4.2.1 worden de gegevens nu niet meegestuurd met het authorization request, maar met het token request.
Voordeel: De controle wordt nog steeds voor een resource request uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
Nadeel: Het gaat hier om backchannelverkeer, waardoor de Authorization server geen scherm kan tonen. Bij een negatief resultaat moet dit worden teruggegeven aan de DVP. Indien gewenst moet deze de gegevens tonen en de vraag stellen of de Vertegenwoordiger toch wilt doorgaan. Het request moet dan opnieuw worden gestuurd, met extra informatie betreffende het antwoord op de vraag.
Nadeel: Door het scherm te tonen kan iemand nog steeds bewust gegevens van verschillende personen vermengen in één dossier.
Identificerende gegevens meegestuurd met token response
Vergelijkbaar met optie 4.2.2 worden de gegevens nu niet meegestuurd met het authorization request, maar met het token response.
Voordeel: De controle wordt nog steeds voor een resource request uitgevoerd, waardoor het proces vroegtijdig gestopt kan worden op het moment dat het resultaat van de vergelijking negatief is.
Nadeel: De Authorization server moet in direct contact staan met de resource server of het xIS. Vanuit 'Gebruiksvriendelijke autorisatie' is de gedachte dat deze rollen van elkaar ontkoppeld moeten worden.
Controlescherm DVP, zonder technische controle
Zodra de DVP gegevens gaat ophalen (of heeft opgehaald), wordt een scherm getoond waarin gevraagd wordt of de Persoon de nieuwe informatie wil toevoegen aan het actieve dossier. Bij vertegenwoordiging betekent dit dat gevraagd wordt of de opgehaalde gegevens toegevoegd mogen worden aan het dossier van de Vertegenwoordigde. Hierbij wordt nergens een technische controle gedaan op de gegevens, het gaat hierbij echt om een (re)actie van de Persoon. Dit kan op twee momenten in het proces. In beide gevallen zou het goed zijn om gegevens te kunnen tonen die de Vertegenwoordiger kan gebruiken om te vergelijken of de op te halen / opgehaalde gegevens ook echt bij Vertegenwoordigde horen. Echter bevatten niet alle gegevensdiensten gegevens betreffende de Persoon en daarmee dus geen identificerende gegevens.
Scherm voordat gegevens worden opgehaald of gedeeld.
Zodra de Persoon middels een redirect teruggaat naar de PGO, voordat een access-token opgehaald zal worden, toont de PGO een scherm met een tekst als: "U heeft zojuist aangegeven dat de gegevens (<lijst van geautoriseerde gegevensdiensten>) kunnen worden opgeslagen in het dossier van <Vertegenwoordigde>. Weet u dit zeker?"
Voordeel: De Vertegenwoordiger geeft nog voor het ophalen van de gegevens aan of hij/zij zeker weet dat de gegevens geplaatst moeten worden in het dossier van de Vertegenwoordigde.
Nadeel: Er kan niet altijd een goede vergelijking worden gedaan van identificerende gegevens, omdat deze niet beschikbaar zijn.
Gegevens in tijdelijke box, scherm om gegevens naar dossier te verplaatsen
Zodra de gegevens daadwerkelijk zijn opgehaald worden deze in een aparte tijdelijke map gezet. De PGO vraagt over deze gegevens aan de Vertegenwoordiger of de gegevens in het dossier geplaatst kunnen worden. In dit geval kan de tekst zijn: "De gegevens (lijst van opgehaalde gegevens) staan klaar om in het dossier van <Vertegenwoordigde> te plaatsen. Klik op opslaan om de gegevens naar het dossier te verplaatsen."
Voordeel: Gegevens worden nooit direct aan een dossier toegevoegd, maar staan in een tijdelijke box en worden pas verplaatst na goedkeuring.
Nadeel: Er kan niet altijd een goede vergelijking worden gedaan van identificerende gegevens, omdat deze niet beschikbaar zijn.
Nadeel: Gegevens zijn opgehaald voordat zeker is dat de gegevens daadwerkelijk over de Vertegenwoordigde gaan.
Nadeel: Gegevens worden gedeeld met een PGO waar de Vertegenwoordigde (Aanbiedersdomein) geen account heeft.
Endpoint voor identificerende gegevens
Om er zeker van te zijn dat een goede vergelijking kan worden uitgevoerd, worden door de DVP identificerende gegevens opgehaald via een daarvoor ingericht endpoint. Voordat de daadwerkelijk gewenste gegevensdienst wordt opgehaald, worden eerst de identificerende gegevens opgehaald en vergelijkt de DVP deze met de eigen gegevens. Indien deze niet voldoende overeenkomen, toont de DVP een scherm. Dit scherm kan een foutmelding bevatten en/of de vraag of de gegevens daadwerkelijk in het dossier geplaatst moeten worden.
Voordeel: De controle wordt uitgevoerd voordat daadwerkelijk gegevensuitwisseling plaatsvindt, maar wordt buiten de autorisatie getrokken (waar het al niet thuishoort).
Voordeel: Ditzelfde endpoint kan gebruikt worden voor de beschikbaarheids- en ontvankelijkheidstoets.
Nadeel: Alle deelnemers krijgen te maken met een nieuwe functionaliteit die geïmplementeerd dient te worden. DVA's moeten dit endpoint beschikbaar stellen, DVP's moeten het endpoint aanroepen.
Nadeel: Deelnemers moeten allemaal de identificerende gegevens in hun bezit hebben, zodat de controle kan worden uitgevoerd.
Nadeel: De controle wordt pas na autorisatie uitgevoerd, waardoor meerdere requests nodig zijn voordat duidelijk is dat er geen gegevensuitwisseling kan plaatsvinden.
Risico's
Geen identificerende gegevens aanwezig bij de Aanbieder
Het kan gebeuren dat de Aanbieder niet de identificerende gegevens heeft die nodig zijn voor de vergelijking. In dit geval kan bij geen van de opties de controle op uitgevoerd worden met een positief resultaat. In deze gevallen zal uitwisseling daarom niet tot stand kunnen komen bij vertegenwoordiging. De vraag is hiermee dan ook of de controle een verplichting moet zijn, of dat deze optioneel wordt.
Geen identificerende gegevens aanwezig bij de DVP
Niet alle DVP's bezitten de identificerende gegevens van een zorggebruiker. Wij verplichten hen dat op dit moment ook niet. Als een DVP de identificerende gegevens niet bezit, kan de controle niet worden uitgevoerd.
Vragen
Verplicht of optioneel
Moet de controle van de identificerende gegevens verplicht worden uitgevoerd of mag dit optionele implementatie zijn? Indien verplicht, dan verplichten we alle deelnemers ook de identificerende gegevens van de zorggebruiker te bezitten.
Alleen bij vertegenwoordiging of altijd
In de situatie dat we niet over vertegenwoordiging spreken, maar de zorggebruiker in het eigen dossier werkt, kunnen ook gegevens van een andere zorggebruiker vermengd worden met de eigen gegevens. De gekozen oplossing kan ook hiervoor een oplossing zijn, maar dan verplichten we de controle altijd uit te voeren.