MO-156 SR-Verduidelijken van de bestaande functionele flows

Autoriseren zonder geldige langdurige toestemming

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.

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.

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.