RFC0039 Toestemming voor meerdere diensten van één aanbieder

Samenvatting

Goedkeuring

Principe's

Uitwerking

Processen en Informatie - UC Verzamelen

De totale procesgang van de UC Verzamelen kent de volgende stappen:

• De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om te verzamelen.
• De Zorggebruiker kiest expliciet de Zorgaanbieder waarbij hij de informatie wenst te verzamelen en de specifieke Gegevensdienst(en). Daarvoor kunnen desgewenst de Gegevensdienstnamen worden gebruikt uit de Gegevensdienstnamenlijst. Het verzoek gaat naar de passende Bron.
• De Bron ontvangt de Zorggebruiker.
• De Bron laat de Zorggebruiker zich authenticeren.
• Wanneer de Zorggebruiker de authenticatie heeft afgebroken geeft de Bron de mogelijkheid alsnog te authenticeren of de flow af te breken.
• Dan breekt het moment aan waarop de Bron op zijn vroegst ervoor instaat dat de Zorgaanbieder voor tenminste één van de gevraagde Gegevensdiensten überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. In deze release staat het MedMij Afsprakenstelsel het toe die voorwaarde op een later moment van kracht te laten zijn, maar niet later dan het laatste in het figuur aangegeven moment.
• De Bron vraagt aan de Zorggebruiker of hij toestemming geeft tot het verstrekken van de gevraagde informatie aan de Uitgever. Deze vraag staat op de pagina Toestemmingsverklaring.
• De Bron logt die toestemming en geeft een autorisatie af aan de Uitgever.
• Nu kan de Uitgever de Bron vragen om de gezondheidsinformatie.
• Uiterlijk na de ontvangst van het verzoek zal de Bron ervoor instaan dat de Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
• Bij ontvangst slaat de Uitgever die informatie op in het persoonlijke dossier. 
• Mocht een Gegevensdienst waartoe de Uitgever is geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), dan bevraagt de Uitgever de Bron daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe interactie met de Zorggebruiker. Hetzelfde geldt wanneer de Uitgever is geautoriseerd voor meerdere Gegevensdiensten van de betreffende Zorgaanbieder.
• Bij de informatie wordt ook de meta-informatie opgeslagen die wordt bedoeld in verantwoordelijkheid 19 van de Processen- en Informatielaag.

In plaatje met de flows onderscheid maken tussen toestemming door Zorggebruiker en autorisatie door Bron. Dit staat er nu niet goed.

Applicatie - Use case implementaties - UCI Verzamelen

De flow kent de volgende stappen:

1. De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om één of meerdere Gegevensdiensten bij een zekere Zorgaanbieder te verzamelen. Het gaat altijd om precies één Gegevensdienst (één scope, in OAuth-termen). Uit de Zorgaanbiederslijst weet de PGO Server welke Gegevensdiensten door een Zorgaanbieder aangeboden worden. Desgewenst worden aan de Zorggebruiker de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gepresenteerd.
2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een authorization request sturen naar de Authorization Server. Het adres van het authorization endpoint komt uit de ZAL. De redirect_uri geeft aan waarnaartoe de Authorization Server de OAuth User Agent verderop moet redirecten (met de authorization code). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Zorgaanbieder bevatten. Zie hiervoor de de toelichting "Toestemming voor meerdere Gegevensdiensten van een Zorgaanbieder".
3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
4. De Authorization Server vraagt de Zorggebruiker via zijn PGO Presenter in te loggen.
5. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de OAuth User Agent naar de Authentication Server te redirecten, onder meegeven van een redirect_uri, die aangeeft waarnaartoe de Authentication Server straks de OAuth User Agent moet terugsturen, na het inloggen van de Zorggebruiker.
6. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.
7. Wanneer deze juist zijn, redirect de Authentication Server de OAuth User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken geeft de Authorization Server de Zorggebruiker alsnog de mogelijkheid via zijn PGO Presenter in te loggen.
8. Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.
9. Dan breekt het vroegste moment aan waarop de Authorization Server ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
10. Indien de Zorgaanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst, of wanneer géén gebruik wordt gemaakt van dit vroegste moment, dan presenteert de Authorization Server via de PGO Presenter aan Zorggebruiker de Toestemmingsverklaring. vraag of laatstgenoemde hem toestaat de gevraagde persoonlijke gezondheidsinformatie aan de PGO Server (als OAuth Client) te sturen. Onder het flow-diagram staat gespecificeerd welke informatie, waarvandaan, de OAuth Authorization Server verwerkt in de aan Zorggebruiker voor te leggen Toestemmingsverklaring. Indien op dit moment al bekend is dat een bepaalde Gegevensdienst niet beschikbaar is voor de Zorggebruiker, dan mag deze niet worden opgenomen in de Toestemmingverklaring.
11. Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een OAuth User Agent redirect met de in het authorization request ontvangen redirect_uri, naar de PGO Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de PGO Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren.
12. De PGO Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de toestemming is gegeven en logt het verkrijgen van het ophaalbewijs.
13. Met dit ophaalbewijs wendt de PGO Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de OAuth User Agent, voor een access token.
14. Daarop genereert de Authorization Server een access token en stuurt deze naar de PGO Server.
15. Nu is de PGO Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen, nadat hij de Zorggebruiker eventueel nog nadere keuzes heeft laten maken. Het adres van de juiste resource endpoints haalt hij uit de ZAL. Hij plaatst telkens het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
16. De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op. Dan breekt het uiterste moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Zorgaanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze ze in een resource response naar de PGO Server. Is dat niet zo, dan breekt de Resource Server de happy flow af.
17. De PGO Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), of mocht één Transactie volgens de betreffende Informatiestandaard uit meerdere requests bestaan, bevraagt de De PGO Server bevraagt de Resource Server daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe interactie met de Zorggebruiker. Zolang het access token geldig is, kan dat.

In de regel worden bij een eenmalig gebruik van UCI Verzamelen het authorization interface, het token interface en het resource interface allemaal aangesproken, in die volgorde. Mocht de PGO Server echter nog beschikken over een nog niet verlopen access token voor de betreffende Zorgaanbieder-Gegevensdienst-combinatie, dan kan het onmiddellijk het resource interface aanspreken.

In plaatje met de flows onderscheid maken tussen toestemming door Zorggebruiker en autorisatie door Authorization Server. Dit staat er nu niet goed, maar werkt op verschillende plaatsen door. Bijv. "vraag om autorisatie" moet zijn "vraag om toestemming". N.a.v. daarvan kan de Zorgaanbieder vervolgens autorisatie verlenen aan PGO Server.

Communicatie - Toestemmingsverklaring

Ook HTML schermen aanpassen.

Applicatie - Interfaces - User interface (Autorisatieserver)

2a. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "autoriseer" in UCI Verzamelen staat gespecificeerd op de pagina Toestemmingsverklaring. Daarbij geldt dat:

• de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (NaamZorgaanbieder) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder;
• de gebruikersvriendelijke weergave van de identiteit van de Uitgever (NaamLeverancierPGO) wordt betrokken uit de OAuth Client List, op basis van de redirect_uri (van OAuth) die in stap 1 is verkregen;
• de gebruikersvriendelijke weergave van een Gegevensdienst (NaamGegevensdienst) wordt betrokken uit de Gegevensdienstnamenlijst.

Applicatie - Interfaces - Authorization interface

1a. De parameters in de authorization request worden als volgt gevuld:

2b. Vervolgens verifieert de Authorization Server dat:

• alle gevraagde GegevensdienstId's voorkomen op de OAuth Client List, bij de betreffende client_id en voor de gehanteerde Interfaceversie;
• zij namens deze Zorgaanbieder, voor de gehanteerde Interfaceversie, deze Gegevensdienst(en) ontsluit, in overeenstemming met de gepubliceerde Zorgaanbiederslijst;
• indien in de scope meerdere GegevensdienstId's zijn opgenomen:
  • alle Gegevensdiensten betrekking hebben op de UCI Verzamelen;
  • de hostnames van de AuthorizationEndpoints, waarop de Gegevensdiensten worden aangeboden, met elkaar overeenkomen;
  • de hostnames van de TokenEndpoints, waarop de Gegevensdiensten worden aangeboden, met elkaar overeenkomen.
• indien in de scope ook subscribe voorkomt:
  • de scope slechts één GegevensdienstId bevat;
  • bij de betreffende client_id en Gegevensdienst op de OAuth Client List ook een subscription notification endpoint en een resource notification endpoint voorkomen;
  • zij namens deze Zorgaanbieder ook Abonnementen op deze Gegevensdienst ontsluit;
  • de waarde van de duur parameter in het request de waarde heeft van 0 of een waarde groter dan 0 die kleiner of gelijk is aan de maximale duur van het Abonnement zoals de betreffende Zorgaanbieder deze aanbiedt.

Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid 6.

6. Uitzondering Authorization interface 3

Authorization Server stelt tijdens de afhandeling van de authorization request vast dat:

• in geval van UCI Verzamelen: van Persoon bij Zorgaanbieder voor geen van de gevraagde Gegevensdiensten gezondheidsinformatie beschikbaar is;
• in geval van UCI Delen: Zorgaanbieder niet ontvankelijk is voor die Gegevensdienst van Persoon;
• in geval van UCI Abonneren: Zorgaanbieder geen Notificaties beschikbaar maakt voor Persoon op die Gegevensdienst.

Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Applicatie - Interfaces - Token interface

2. De parameters in de access token response worden als volgt gevuld:

Managementinformatie

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

Deze RFC introduceert geen nieuwe beveiligingsrisico's. De impact van een aanval op een PGO Server, waardoor access_tokens zouden kunnen worden misbruikt wordt wel groter, doordat de scope van het access_token nu meerdere gegevensdiensten kan omvatten. De scope blijft echter nog altijd beperkt tot 15 minuten toegang tot de gezondheidsgegevens van één Persoon. Om deze reden zijn geen extra maatregelen nodig.

Bijlagen