Samenvatting

Waarom is deze RFC nodig?	Het verduidelijken van de bestaande functionele flows, deze zorgt ervoor dat de flows aansluiten op de bestaande processen. Hiermee worden geen functionaliteiten toegevoegd.
Oplossingsrichting	De bestaande flows onder de functies en extensies verduidelijken.
RACI	Responsible: Team ontwikkeling Accountable: Product management Consulted: Team ontwikkeling Informed: -
Aanpassing van	Autoriseren Authenticeren Beheren toestemmingen Autoriseren voor Vertegenwoordiging Authenticeren voor Vertegenwoordiging Abonneren
Impact op rollen	nvt
Impact op beheer	nvt
Impact op RnA	nvt
Impact op Acceptatie	nvt
PIA noodzakelijk	nvt
Gerelateerd aan (Andere RFCs, PIM issues)	MMOS-232 - Getting issue details... STATUS
Implementatietermijn	AF 2.0.0
Motivatie verkorte RFC procedure (patch)	Geen wijziging van functionaliteit, dit zijn bestaande schermen.

Uitwerking

Autoriseren

Huidige inhoud

Nieuwe inhoud

Autoriseren zonder geldige langdurige toestemming

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 User Agent stuurt een authorization request naar de Authorization Server.
Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
Na de authenticatieflow valideert de Authorization Server de identificerende gegevens en breekt het (vroegste) moment aan waarop of
1. de Authorization Server ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Op dit moment is de beschikbaarheidstoets optioneel voor de functie verzamelen, omdat later in het proces dezelfde toets verplicht uitgevoerd moet worden.
2. de Authorization Server ervoor instaat dat voor de betreffende Gegevensdienst de Aanbieder ontvankelijk is voor de gezondheidsgegevens van de betreffende Persoon. Is dat zo, dan verstuurt de Authorization Server het access-token naar de DVP Server. Is dat niet zo, dan breekt de Authorization Server de happy flow af en stuurt zij geen access-token naar de DVP Server.
Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst of kan instaan dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, dan presenteert de Authorization Server via de User Agent aan Persoon in een Toestemmingsverklaring, de vraag of Persoon de Aanbieder toestaat de gevraagde persoonlijke gezondheidsinformatie uit te wisselen met de DVP Server (als OAuth Client).
Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization-code en stuurt dit als ophaalbewijs, door middel van een User Agent redirect met de in het authorization request ontvangen redirect_uri, naar de DVP Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de DVP Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization-code moet associëren.
De DVP 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.
Met dit ophaalbewijs wendt de DVP Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de User Agent, voor een access-token.
De Authorization Server valideert de authorization-code. Nu is het vroegste moment dat de verplichte beschikbaarheidstoets uitgevoerd kan worden. De andere optie is het uitvoeren van de beschikbaarheidstoets op het resource endpoint. Eén van deze twee momenten is verplicht.
Daarop genereert de Authorization Server een access-token (en indien de Persoon langdurige toestemming geeft ook een referesh-token) en stuurt deze naar de DVP Server.

Autoriseren zonder geldige langdurige toestemming

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 User Agent stuurt een authorization request naar de Authorization Server.
De Authorization Server presenteert hierop de landingspagina aan de Persoon.
Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
Na de authenticatieflow valideert de Authorization Server de identificerende gegevens en breekt het (vroegste) moment aan waarop of
1. de Authorization Server ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Op dit moment is de beschikbaarheidstoets optioneel voor de functie verzamelen, omdat later in het proces dezelfde toets verplicht uitgevoerd moet worden.
2. de Authorization Server ervoor instaat dat voor de betreffende Gegevensdienst de Aanbieder ontvankelijk is voor de gezondheidsgegevens van de betreffende Persoon. Is dat zo, dan verstuurt de Authorization Server het access-token naar de DVP Server. Is dat niet zo, dan breekt de Authorization Server de happy flow af en stuurt zij geen access-token naar de DVP Server.
Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst of kan instaan dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, dan presenteert de Authorization Server via de User Agent aan Persoon in een Toestemmingsverklaring, de vraag of Persoon de Aanbieder toestaat de gevraagde persoonlijke gezondheidsinformatie uit te wisselen met de DVP Server (als OAuth Client).
Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization-code en stuurt dit als ophaalbewijs, door middel van een User Agent redirect met de in het authorization request ontvangen redirect_uri, naar de DVP Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de DVP Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization-code moet associëren.
De DVP 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.
Met dit ophaalbewijs wendt de DVP Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de User Agent, voor een access-token.
De Authorization Server valideert de authorization-code. Nu is het vroegste moment dat de verplichte beschikbaarheidstoets uitgevoerd kan worden. De andere optie is het uitvoeren van de beschikbaarheidstoets op het resource endpoint. Eén van deze twee momenten is verplicht.
Daarop genereert de Authorization Server een access-token (en indien de Persoon langdurige toestemming geeft ook een referesh-token) en stuurt deze naar de DVP Server.

Authenticeren

Huidige inhoud Nieuwe inhoud

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 User Agent stuurt een authorization request naar de Authorization Server. Het adres van het authorization endpoint komt uit de Aanbiederslijst. De redirect_uri geeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization code). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten.
Toestemming voor meerdere Gegevensdiensten van een Aanbieder
In een authorization request mogen meerdere Gegevensdiensten van eenzelfde Aanbieder worden gecombineerd wanneer:
1. de gegevensdiensten worden aangeboden binnen één zelfde interfaceversie, EN
2. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen AuthorizationEndpoints met elkaar overeenkomen, EN
3. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen TokenEndpoints met elkaar overeenkomen.
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 Persoon via zijn User Agent om credentials.
Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de User Agent naar de Authentication Server te redirecten, onder meegeven van een redirect_uri, die aangeeft waarnaartoe de Authentication Server straks de User Agent moet terugsturen, na het inloggen van de Persoon.
De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
Wanneer deze juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken toont de Authorization Server de Persoon de melding waaruit op te maken valt dat het authenticatieproces is afgebroken en biedt het alsnog de mogelijkheid via zijn User Agent in te loggen.
Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.

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 User Agent stuurt een authorization request naar de Authorization Server. Het adres van het authorization endpoint komt uit de Aanbiederslijst. De redirect_uri geeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization code). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten.
Toestemming voor meerdere Gegevensdiensten van een Aanbieder
In een authorization request mogen meerdere Gegevensdiensten van eenzelfde Aanbieder worden gecombineerd wanneer:
1. de gegevensdiensten worden aangeboden binnen één zelfde interfaceversie, EN
2. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen AuthorizationEndpoints met elkaar overeenkomen, EN
3. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen TokenEndpoints met elkaar overeenkomen.
Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
De DVAuthn toont de Persoon een inlogpagina voor de authenticatie.
De Authorization Server vraagt de Persoon via zijn User Agent om credentials.
Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de User Agent naar de Authentication Server te redirecten, onder meegeven van een redirect_uri, die aangeeft waarnaartoe de Authentication Server straks de User Agent moet terugsturen, na het inloggen van de Persoon.
De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
Wanneer deze juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken toont de Authorization Server de Persoon de melding waaruit op te maken valt dat het authenticatieproces is afgebroken en biedt het alsnog de mogelijkheid via zijn User Agent in te loggen.
Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.

Beheren toestemmingen

Huidige inhoud

Nieuwe inhoud

Applicatielaag

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 User Agent vraag de Persoon een Aanbieder te selecteren.
De Persoon selecteert een Aanbieder bij wie hij de toestemming wil intrekken.
De User Agent stuurt een verzoek tot intrekken van de toestemming naar de Authorization Server.
Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
Na de authenticatieflow valideert de Authorization Server de identificerende gegevens.
De Authorization Server presenteert via de User Agent aan Persoon in een Toestemmingsoverzicht de aanwezige toestemmingen en vraagt de toestemming te selecteren die hij wil intrekken.
De User Agent stuurt het verzoek tot intrekken van desbetreffende toestemming naar de Authorization Server.
De Authorization Server presenteert via de User Agent aan Persoon de Beëindigingsverklaring Toestemming.
Bij bevestiging door de Persoon logt de Authorization Server het intrekken van de toestemming en trekt het refresh-token in.
De Authorization Server presenteert via de User Agent aan Persoon het Toestemmingsoverzicht. Hier kan de Persoon kiezen om nog een toestemming in te trekken of om terug te gaan naar zijn Dienstverlener Persoon.

Applicatielaag

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 User Agent vraag de Persoon een Aanbieder te selecteren.
De Persoon selecteert een Aanbieder bij wie hij de toestemming wil intrekken.
De User Agent stuurt een verzoek tot intrekken van de toestemming naar de Authorization Server.
De Dienstverlener aanbieder toont de landingspagina aan de Persoon waar de Persoon kan kiezen voor de optie Toestemmingen aanpassen.
Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
Na de authenticatieflow valideert de Authorization Server de identificerende gegevens.
De Authorization Server presenteert via de User Agent aan Persoon in een Toestemmingsoverzicht de aanwezige toestemmingen en vraagt de toestemming te selecteren die hij wil intrekken.
De User Agent stuurt het verzoek tot intrekken van desbetreffende toestemming naar de Authorization Server.
De Authorization Server presenteert via de User Agent aan Persoon de Beëindigingsverklaring Toestemming.
Bij bevestiging door de Persoon logt de Authorization Server het intrekken van de toestemming en trekt het refresh-token in.
De Authorization Server presenteert via de User Agent aan Persoon het Toestemmingsoverzicht. Hier kan de Persoon kiezen om nog een toestemming in te trekken of om terug te gaan naar zijn Dienstverlener Persoon.

Authenticeren voor Vertegenwoordiging

Huidige inhoud

Nieuwe inhoud

De flow van de functie Authenticeren kent voor Vertegenwoordiging de volgende wijzigingen:

De Dienstverlener aanbieder ontvangt van de Dienstverlener Persoon een verzoek tot verzamelen op basis van vrijwillige Vertegenwoordiging of op basis van Vertegenwoordiging op grond van het ouderlijk gezag.
1. Wanneer de Dienstverlener aanbieder een verzoek tot verzamelen op basis van een vrijwillige Vertegenwoordiging ontvangt, vraagt de Dienstverlener aanbieder de Dienstverlener authenticatie, de authenticatie flow te starten voor Vertegenwoordiging op basis van een vrijwillige machtiging. De scope van het authorization request bevat de letterlijke waarde 'onbehalfof'.
2. Wanneer de Dienstverlener aanbieder een verzoek tot verzamelen op basis van Vertegenwoordiging op grond van het ouderlijk gezag ontvangt, vraagt de Dienstverlener aanbieder de Dienstverlener authenticatie, de authenticatie flow te starten voor Vertegenwoordiging op basis van het ouderlijk gezag. De scope van het authorization request bevat de letterlijke waarde 'onbehalfofchild'.
Nadat de credentials van de Persoon zijn gevalideerd, worden de bij de Persoon behorende Vertegenwoordigden gepresenteerd.
De Persoon kiest één van de Vertegenwoordigden en maak dit kenbaar aan de Authentication server.
Voor het uitgeven van een authenticatieverklaring voegt de Authentication server hieraan de identificerende gegevens (BSN) van de Vertegenwoordigde en Vertegenwoordiger toe.
De Authorization server valideert of in de authenticatieverklaring de identificerende gegevens staan van de Vertegenwoordigde en Vertegenwoordiger:
1. De Authorization server stelt vast dat op de juiste manier gebruikgemaakt is van vrijwillige Vertegenwoordiging of van Vertegenwoordiging op grond van het ouderlijk gezag. Authorization server gaat verder met de flow.
2. De Authorization server stelt vast dat geen gebruikgemaakt is van vrijwillige Vertegenwoordiging of van Vertegenwoordiging op grond van het ouderlijk gezag, of niet op de juiste manier. Authorization server stopt de flow onmiddellijk.

De flow van de functie Authenticeren kent voor Vertegenwoordiging de volgende wijzigingen:

De Dienstverlener aanbieder ontvangt van de Dienstverlener Persoon een verzoek tot verzamelen op basis van vrijwillige Vertegenwoordiging of op basis van Vertegenwoordiging op grond van het ouderlijk gezag.
1. Wanneer de Dienstverlener aanbieder een verzoek tot verzamelen op basis van een vrijwillige Vertegenwoordiging ontvangt, vraagt de Dienstverlener aanbieder de Dienstverlener authenticatie, de authenticatie flow te starten voor Vertegenwoordiging op basis van een vrijwillige machtiging. De scope van het authorization request bevat de letterlijke waarde 'onbehalfof'.
2. Wanneer de Dienstverlener aanbieder een verzoek tot verzamelen op basis van Vertegenwoordiging op grond van het ouderlijk gezag ontvangt, vraagt de Dienstverlener aanbieder de Dienstverlener authenticatie, de authenticatie flow te starten voor Vertegenwoordiging op basis van het ouderlijk gezag. De scope van het authorization request bevat de letterlijke waarde 'onbehalfofchild'.
De DVAuthn toont de Persoon een inlogpagina voor de authenticatie.
Nadat de credentials van de Persoon zijn gevalideerd, worden de bij de Persoon behorende Vertegenwoordigden gepresenteerd.
De Persoon kiest één van de Vertegenwoordigden en maak dit kenbaar aan de Authentication server.
Voor het uitgeven van een authenticatieverklaring voegt de Authentication server hieraan de identificerende gegevens (BSN) van de Vertegenwoordigde en Vertegenwoordiger toe.
De Authorization server valideert of in de authenticatieverklaring de identificerende gegevens staan van de Vertegenwoordigde en Vertegenwoordiger:
1. De Authorization server stelt vast dat op de juiste manier gebruikgemaakt is van vrijwillige Vertegenwoordiging of van Vertegenwoordiging op grond van het ouderlijk gezag. Authorization server gaat verder met de flow.
2. De Authorization server stelt vast dat geen gebruikgemaakt is van vrijwillige Vertegenwoordiging of van Vertegenwoordiging op grond van het ouderlijk gezag, of niet op de juiste manier. Authorization server stopt de flow onmiddellijk.

Autoriseren voor Vertegenwoordiging

Huidige inhoud

Nieuwe inhoud

Tekst blijft hetzelfde

Abonneren

Huidige inhoud	Nieuwe inhoud

Tekst blijft hetzelfde.

Autoriseren voor abonneren

Nieuwe pagina opnemen onder functie abonneren. Deze is onder deze pagina te vinden.

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
Toelichting

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.

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen
Geen

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad