Autoriseren voor Abonneren
Inleiding
Hieronder wordt autoriseren voor Abonneren beschreven.
Businesslaag
Hieronder staat het diagram behorende bij de functie Autoriseren voor Abonneren. De flow beschrijft 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 betekent bij Abonneren:
Bij Abonneren wordt de Toestemmingsverklaring afgegeven, waarmee de Dienstverlener aanbieder toestemming wordt gegeven voor meldingen over gezondheidsgegevens naar de Dienstverlener persoon te zenden en/of een Beëindigingsverklaring worden afgegeven, waarmee de Persoon een abonnement stopt
Autoriseren voor Abonneren
De totale procesgang van de functie Autoriseren voor Abonneren kent de volgende stappen:
De Dienstverlener aanbieder ontvangt een verzoek tot autorisatie.
De Dienstverlener aanbieder presenteert de landingspagina.
De Dienstverlener aanbieder laat de Persoon zich authenticeren bij de Dienstverlener authenticatie.
Nadat de persoon geauthenticeerd is, voert de Dienstverlener aanbieder optioneel de beschikbaarheidstoets uit en vraagt de Persoon om een toestemmingsverklaring voor Abonneren.
De Dienstverlener aanbieder logt die toestemming voor het Abonnement 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.
nr. | uitzondering | actie | vervolg |
|---|---|---|---|
autoriseren 1 | Dienstverlener aanbieder stelt op enig moment vast dat van Persoon bij Aanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is. Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde. | Dienstverlener aanbieder informeert de Persoon dat diens verzoek geen voortgang kan vinden en noemt daarbij behorende reden. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
autoriseren 2 | De voorgelegde Toestemmingsverklaring voor Abonneren wordt niet afgegeven. | Dienstverlener aanbieder informeert DVP Server over deze uitzondering. DVP Server informeert Persoon dat diens verzoek geen voortgang kan vinden, maar laat de oorzaak daarvan helemaal in het midden. | |
autoriseren 3 | Dienstverlener aanbieder kan het antwoord op de toestemmingsvraag niet vaststellen. | Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
Applicatielaag
Autoriseren voor Abonneren
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:
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 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.
Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst, presenteert de Authorization Server via de User Agent aan Persoon de Toestemmingsverklaring voor Abonnement met de vraag of Persoon de Aanbieder toestaat een melding te sturen als er iets wijzigt in de gegevens die de Aanbieder over de Persoon bijhoudt naar de DVP Server (als OAuth Client).
Bij akkoord logt de Authorization Server dit als toestemming en genereert een authorization-code. Vervolgens stuurt de Authorization Server dit als ophaalbewijs naar de DVP Server door middel van een User Agent redirect met de in het authorization request ontvangen redirect_uri. 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 de subscription server. Eén van deze twee momenten is verplicht.
Daarop genereert de Authorization Server een access-token en stuurt deze naar de DVP Server.