Document toolboxDocument toolbox

(v0.1) MO-156 SR-Flows aanpassen met schermen [RFC]

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 noodzakelijknvt
Gerelateerd aan (Andere RFCs, PIM issues)


Implementatietermijn

AF 2.0.0

Motivatie verkorte RFC procedure (patch)

Geen wijziging van functionaliteit, dit zijn bestaande schermen.

Uitwerking

Autoriseren

Huidige inhoudNieuwe 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:

  1. De User Agent stuurt een authorization request naar de Authorization Server. 
  2. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  3. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
  4. 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.
  5. 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).
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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:

  1. De User Agent stuurt een authorization request naar de Authorization Server. 
  2. De Authorization Server presenteert hierop de landingspagina aan de Persoon.
  3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  4. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
  5. 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.
  6. 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).
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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 inhoudNieuwe 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:

  1. 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.
  2. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  3. De Authorization Server vraagt de Persoon via zijn User Agent om credentials.
  4. 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.
  5. De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
  6. 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.
  7. 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:

  1. 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.
  2. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  3. De DVAuthn toont de Persoon een inlogpagina voor de authenticatie.
  4. De Authorization Server vraagt de Persoon via zijn User Agent om credentials.
  5. 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.
  6. De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
  7. 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.
  8. 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:

  1. De User Agent vraag de Persoon een Aanbieder te selecteren.
  2. De Persoon selecteert een Aanbieder bij wie hij de toestemming wil intrekken.
  3. De User Agent stuurt een verzoek tot intrekken van de toestemming naar de Authorization Server. 
  4. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  5. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
  6. Na de authenticatieflow valideert de Authorization Server de identificerende gegevens.
  7. 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.
  8. De User Agent stuurt het verzoek tot intrekken van desbetreffende toestemming naar de Authorization Server.
  9. De Authorization Server presenteert via de User Agent aan Persoon de Beëindigingsverklaring Toestemming.
  10. Bij bevestiging door de Persoon logt de Authorization Server het intrekken van de toestemming en trekt het refresh-token in.
  11. 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:

  1. De User Agent vraag de Persoon een Aanbieder te selecteren.
  2. De Persoon selecteert een Aanbieder bij wie hij de toestemming wil intrekken.
  3. De User Agent stuurt een verzoek tot intrekken van de toestemming naar de Authorization Server. 
  4. De Dienstverlener aanbieder toont de landingspagina aan de Persoon waar de Persoon kan kiezen voor de optie Toestemmingen aanpassen. 
  5. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  6. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow.
  7. Na de authenticatieflow valideert de Authorization Server de identificerende gegevens.
  8. 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.
  9. De User Agent stuurt het verzoek tot intrekken van desbetreffende toestemming naar de Authorization Server.
  10. De Authorization Server presenteert via de User Agent aan Persoon de Beëindigingsverklaring Toestemming.
  11. Bij bevestiging door de Persoon logt de Authorization Server het intrekken van de toestemming en trekt het refresh-token in.
  12. 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 inhoudNieuwe inhoud

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

  1. 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'.
  2. Nadat de credentials van de Persoon zijn gevalideerd, worden de bij de Persoon behorende Vertegenwoordigden gepresenteerd.
  3. De Persoon kiest één van de Vertegenwoordigden en maak dit kenbaar aan de Authentication server.
  4. Voor het uitgeven van een authenticatieverklaring voegt de Authentication server hieraan de identificerende gegevens (BSN) van de Vertegenwoordigde en Vertegenwoordiger toe.
  5. 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:

  1. 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'.
  2. De DVAuthn toont de Persoon een inlogpagina voor de authenticatie.
  3. Nadat de credentials van de Persoon zijn gevalideerd, worden de bij de Persoon behorende Vertegenwoordigden gepresenteerd.
  4. De Persoon kiest één van de Vertegenwoordigden en maak dit kenbaar aan de Authentication server.
  5. Voor het uitgeven van een authenticatieverklaring voegt de Authentication server hieraan de identificerende gegevens (BSN) van de Vertegenwoordigde en Vertegenwoordiger toe.
  6. 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 inhoudNieuwe inhoud








Tekst blijft hetzelfde

Abonneren


Huidige inhoudNieuwe 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.

DreigingKansImpactDreigingsID (intern)Maatregelen
Geen






Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad