Samenvatting
| Waarom is deze RFC nodig? | Om de Persoon in Regie te houden bij zijn gebruik van de use cases Verzamelen, Delen en Abonneren, moet hij ook steeds weten wie hij tegenover zich heeft in de verschillende stappen. Om te beginnen is dat steeds precies die Zorgaanbieder die hij uit de Zorgaanbiederslijst heeft gekozen om er een Gegevensdienst van af te nemen. Nadat de authorization request is uitgegaan naar de Authorization Server, moet de Persoon ervan op de hoogte worden gesteld dat hij het domein van de Zorgaanbieder is binnengetreden. Dat kan door middel van een landingspagina. Die landingspagina biedt de mogelijkheid om de Persoon ervan op de hoogte te brengen dat hij zo gaat inloggen bij de geselecteerde Zorgaanbieder. Dit is in lijn met de eisen die door authenticatievoorzieningen wordt gesteld. In sommige gevallen wil de Zorgaanbieder zijn wettelijke authenticatieplicht vervullen door de Persoon zich . In geval van DigiD zal die Authenticerende derde dan aansluithouder moeten zijn. |
|---|
| Oplossingsrichting | - namens de Zorgaanbieder gaat optreden. Vooralsnog wordt de volgende tekst getoond: "Welkom bij NaamZorgaanbieder. Voordat u toestemming kunt geven voor het verzamelen of delen van informatie, moet u inloggen." Tevens wordt op een gereserveerde positie de inlogknop getoond conform de eisen van de gebruikte Authenticatieprovider ZA.
- Mocht de Zorgaanbieder authenticatiemiddelen van meerdere niveaus aanbieden, zal hem gevraagd worden op zijn landingspagina de Persoon ertoe te bewegen te kiezen voor het hoogste niveau dat door de Zorgaanbieder wordt aangeboden. Zaak blijft daarbij:
- dat het de Zorgaanbieder is die kiest welke authenticatiemiddelen van welke niveaus hij voorlegt aan de Persoon, en
- dat MedMij niet discrimineert tussen authenticatiemiddelen, anders dan op hun niveau;
- Invoeren van een "geannuleerde inlog" met de volgende tekst: "U hebt uw inlog bij NaamZorgaanbieder geannuleerd. Voordat u toestemming kunt geven voor het verzamelen of delen van informatie, moet u alsnog inloggen. Als u wilt stoppen, kunt u dit scherm sluiten."Tevens wordt op en een gereserveerde positie de inlogknop getoond conform de eisen van de gebruikte Authenticatieprovider ZA en een "Sluiten" knop waarmee teruggekeerd wordt naar de PGO.
- Toevoegen aan het toestemmings-/bevestigingsscherm dat bij het nalaten van toestemming/bevestiging de sessie bij de Zorgaanbieder onmiddellijk wordt beëindigd. Dit door de volgende zin toe te voegen: "Als u uw keuze heeft gemaakt of deze pagina sluit, wordt u uitgelogd bij NaamZorgaanbieder."
- Op alle schermen mag van de zorgaanbieder te voeren. Dit kan in de hoeks links boven in het scherm.
Voorwaarden Authenticerende derde: - De Persoon heeft geen juridische relatie met de Authenticerende derde en gaat die ook niet aan.
- De Authenticerende derde is, in geval van DigiD, de DigiD-aansluithouder.
- De rol van de Authenticerende derde respecteert de principes van MedMij inzake gelijk speelveld.
- De Authenticerende derde heeft een overeenkomst met de Zorgaanbieder die regelt dat, als een Persoon zich authenticeert bij de Authenticerende derde, dit geldt als een vervulling van de wettelijke plicht van de Zorgaanbieder de Persoon te authenticeren.
- De Authenticerende derde heeft een dienstverlenings-/verwerkersovereenkomst met de Dienstverlener zorgaanbieder van Zorgaanbieder, of is die Dienstverlener zorgaanbieder zelf.
Het invoeren van de landingspagina en een pagina voor annuleren kan onafhankelijk van het gaan toestaan van een Authenticerende derde. Omdat dat laatste complexer is, kan deze RFC ook opleveren dat in release 1.3.0 alleen het eerste wordt ingevoerd. Op korte termijn (per heden) al toestaan en stimuleren om de nieuwe pagina's te gebruiken. Dus wanneer een landingspagina en annuleringspagina worden toegepast, dan moet de pagina gebruikt worden als omschreven. Eveneens worden de toegevoegde zin op de toestemmings- en bevestigingsschermen en het voeren van het zorgaanbiederslogo toegestaan. Zie ook bijgevoegd factsheet: 
|
|---|
| Aanpassing van | - Landingspagina
- Toestemmingsscherm
- Bevestigingsscherm
- Toevoegen van Authenticerende derde aan rollenplaten en in verantwoordelijkheden op de lagen Processen en Informatie, en Applicatie
- Als deze RFC wordt aangenomen, moet RFC0018 worden genuanceerd.
|
|---|
| Impact op rollen | Zorgaanbieder, Dienstverlener zorgaanbieder, Authenticerende derde |
|---|
| Impact op beheer | |
|---|
| Impact op RnA | |
|---|
| Impact op Acceptatie | |
|---|
| Gerelateerd aan (Andere RFCs, PIM issues) | |
|---|
| Eigenaar | Paul Oude Luttighuis, Bouke de Boer | MedMij |
|---|
| Implementatietermijn | |
|---|
| Motivatie verkorte RFC procedure (patch) | |
|---|
Goedkeuring
| Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
|---|
| Productmanager Stichting MedMij |
|
| Productmanager Beheerorganisatie |
|
|
| Leadarchitect Stichting MedMij |
|
| Leadarchitect Beheerorganisatie |
|
|
| Ontwerpteam |
|
|
|
|
|
| Deelnemersraad |
|
| Eigenaarsraad |
|
|
Principe's
| Principe |
| Principe |
|
|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | | 11 Stelselfuncties worden vanaf de start ingevuld | |
| 2 Dienstverleners zijn transparant over de gegevensdiensten | | 12 Het afsprakenstelsel is een groeimodel | |
| 3 Dienstverleners concurreren op de functionaliteiten | | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | |
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | | 14 Uitwisseling is een keuze | |
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | |
| 6 MedMij spreekt alleen af wat nodig is | | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | |
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | |
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | |
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | |
Uitwerking
Toevoegen ontvang in diagrammen
Toevoegen annuleer in diagrammen met mogelijkheid om te stoppen of in te loggen
Totaalperspectief (happy flow)
Toelichting
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
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. 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 te authenticeren of de flow af te breken. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.
- Dan breekt het moment aan waarop de Bron op zijn vroegst ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of
Toevoegen ontvang in diagrammen
Toevoegen annuleer in diagrammen met mogelijkheid om te stoppen of in te loggen
Totaalperspectief (happy flow)
Toelichting
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
De totale procesgang van de UC Delen kent de volgende stappen:
- De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om te delen.
- De Zorggebruiker kiest de zorgaanbieder waarmee hij de informatie wenst te delen en de Gegevensdienst. Daarvoor kunnen desgewenst de Gegevensdienstnamen worden gebruikt uit de Gegevensdienstnamenlijst. Het verzoek gaat naar de passende Lezer.
- De Lezer ontvangt de Zorggebruiker.
- De Lezer laat de Zorggebruiker zich authenticeren.
- Wanneer de Zorggebruiker de authenticatie heeft afgebroken geeft de Lezer de mogelijkheid alsnog te authenticeren of de flow af te breken. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.
Toevoegen ontvang in diagrammen
Toevoegen annuleer in diagrammen met mogelijkheid om te stoppen of in te loggen
Totaalperspectief (happy flow)
Toelichting
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
De totale procesgang van de UC Abonneren kent de volgende stappen:
- De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om Abonnementen aan te gaan, aan te passen of te beëindigen.
- De Zorggebruiker selecteert voor het aangaan van een Abonnement expliciet de Zorgaanbieder en de specifieke Gegevensdienst, en voor het aanpassen of beëindigen het betreffende Abonnement. 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. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.
1. Het welkomstscherm dat aan de Zorggebruiker wordt gepresenteerd bij ontvangst op de Autorisatieserver in de UCI Verzamelen, UCI Delen en UCI Abonneren en staat gespecificeerd op de pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135627886. 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;
2. Het Annuleringsscherm, dat aan de Zorggebruiker wordt gepresenteerd na afbreken van de authenticatie in de UCI Verzamelen, UCI Delen en UCI Abonneren en staat gespecificeerd op de pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135627902. 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;
1a. 3a. 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 Gegevensdienst (
NaamGegevensdienst) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen; - 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.
1b. 3b. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "bevestig" in UCI Delen staat gespecificeerd op de pagina Bevestigingsverklaring. 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 Gegevensdienst (
NaamGegevensdienst) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen; - 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.
1c. 3c. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "autoriseer" in UCI Abonneren staat gespecificeerd op de pagina Toestemmingsverklaring Abonneren. 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 aangeboden looptijd van het Abonnement (
Duur) door de beleid van de Zorgaanbieder wordt bepaald, op basis van de door de Persoon gevraagde looptijd, en nooit langer dan de maximale looptijd die in de Catalogus bij de betreffende Gegevensdienst staat genoemd; - de gebruikersvriendelijke weergave van de Gegevensdienst (
NaamGegevensdienst) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen; - 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.
Toelichting
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
De flow kent de volgende stappen:
- De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om een bepaalde Gegevensdienst 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 de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
- De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een verzamel-verzoek 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). - Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
- .
4. 5 Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de browser 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.
5. 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. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.
Daarna hernummeren
UCI Delen
- De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om een bepaalde Gegevensdienst met een zekere Zorgaanbieder te delen. 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 de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
- De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een deel-verzoek 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).
- Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
4. 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.
5. 6. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.
5. 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. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.
Daarna hernummeren
- De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om zich bij een zekere Zorgaanbieder te Abonneren op Notificatiesvoor een bepaalde Gegevensdienst. Het gaat altijd om precies één Gegevensdienst. Uit de Zorgaanbiederslijst weet de PGO Server op welke Gegevensdiensten een Zorgaanbieder Abonnementen aanbiedt worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
- De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een abonneer-verzoek 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). - Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
- De Authorization Server vraagt de Zorggebruiker via zijn PGO Presenter in te loggen.
4. 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.
5. 6. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.
5. 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. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.
Daarna hernummeren
Nieuwe pagina: Landingspagina, zie bijlage
Nieuwe pagina: Annuleringspagina, Zie bijlage
Gewijzigde schermen opnemen, zie bijlage.
Gewijzigde schermen opnemen, zie bijlage.
Gewijzigde schermen opnemen, zie bijlage.
Bijlage
20201027medmij-toestemmingen-en-bevestiging.zip
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 (privacy)risico's, het wordt voor de persoon juist duidelijker met wie hij van doen heeft.
| Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
|---|
| |
|
|
|