Inleiding

Op deze pagina staan de diagrammen behorende bij de functie Autoriseren. De diagrammen tonen alleen de situatie waarin alle acties slagen tot en met dat de Dienstverlener aanbieder geautoriseerd is (de zogenaamde happy flow). De oranje banen horen (conform de MedMij-huisstijl) tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein en de grijze tot externe domeinen.

In de diagrammen en uitwerkingen wordt gesproken over toestemming. Dit heeft verschillende betekenissen:

1. Bij de functies Verzamelen en Abonneren wordt hier de Toestemmingsverklaring afgegeven, waarmee de Dienstverlener aanbieder toestemming wordt gegeven gezondheidsgegevens naar de Dienstverlener persoon te zenden.
2. Bij de functie Abonneren kan ook een Beëindigingsverklaring worden afgegeven, waarmee de Persoon een abonnement stopt.
3. Bij de functies Delen wordt hier de Bevestigingsverklaring afgegeven, waarmee de Dienstverlener aanbieder toestemming wordt gegeven gezondheidsgegevens van de Dienstverlener persoon te ontvangen.

Onderstaande diagrammen bevatten de term toestemming en zijn vanuit de functie Verzamelen uitgewerkt. Voor de andere functies zijn de bijbehorende verklaringen van toepassing.

Businesslaag

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.

De totale procesgang van de functie Autoriseren kent de volgende stappen:

• De Dienstverlener aanbieder ontvangt een verzoek tot autorisatie.
• De Dienstverlener aanbieder laat de Persoon zich authenticeren bij de Dienstverlener authenticatie.
• Nadat de persoon geauthenticeerd is, vraagt de Dienstverlener aanbieder aan de Persoon of hij toestemming geeft tot het verstrekken van de gevraagde informatie aan de Dienstverlener persoon. Deze vraag staat op de pagina Toestemmingsverklaring.
• De Dienstverlener aanbieder logt die toestemming en geeft een autorisatie af aan de Dienstverlener persoon.

Uitzonderingen op de Happy flow van de functie Autorisatie

In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle uitzonderingssituaties worden door de Dienstverlener aanbieder ontdekt. Om te voorkomen dat de Dienstverlener persoon informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven, moet het onderscheid tussen de uitzonderingen 1 en 2 niet te maken zijn door de Dienstverlener persoon.

Applicatielaag

Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.

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 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. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
   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). Indien op dit moment al bekend is dat een bepaalde Gegevensdienst niet beschikbaar is voor de Persoon, dan mag deze niet worden opgenomen in de Toestemmingsverklaring.
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. Daarop genereert de Authorization Server een access-token en stuurt deze naar de DVP Server.