De authorization interface hoort bij de hoofdfunctie Regie.

Op deze pagina staan alleen de verantwoordelijkheden inzake de authorization interface die nog niet genoemd staan in de OAuth 2-specificatie. Deze verantwoordelijkheden vormen een uitbreiding op de al geldende verantwoordelijkheden voor de Authorization interface vanuit de MedMij Core.

1.

De parameters in de authorization request worden als volgt gevuld:

parameter

vulling

toelichting

scope

Voor "abonneren":

de letterlijke waarde subscribe
gevolgd door een tilde ~
gevolgd door een niet-negatief geheel getal, aangevende de gevraagde maximale duur van het Abonnement
gevolgd door een forward slash /
gevolgd door één aanbieder-gegevensdienst-combinatie.

Een aanbieder-gegevensdienst-combinatie bestaat uit:

één Aanbiedernaam, ontdaan van de suffix @medmij
gevolgd door een tilde (~)
gevolgd door één GegevensdienstId van een Gegevensdienst uit de Gegevensdienstnamenlijst.

Er worden geen andere scopes of onderdelen van scopes opgenomen dan de genoemde.

Voorbeelden van syntactisch juiste scopes zijn:

"subscribe~180/eenofanderezorgaanbieder~42", voor het aangaan van een Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij van maximaal 180 dagen, of het aanpassen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij naar maximaal 180 dagen vanaf vandaag;
"subscribe~0/eenofanderezorgaanbieder~42", voor het beëindigen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij.

Bovenstaande tabel is een uitbreiding op de tabel die is weergegeven in core.authint.200

ext.abo.authint.200

2.

Vervolgens verifieert de OAuth Authorization Server dat:

de gevraagde GegevensdienstId voorkomt op de OAuth Client List, bij de betreffende client_id en voor de gehanteerde Interfaceversie;
zij namens deze Aanbieder, voor de gehanteerde Interfaceversie, deze Gegevensdienst ontsluit, in overeenstemming met de gepubliceerde Aanbiederslijst;
indien in de scope ook subscribe voorkomt (in geval van de functie Abonneren is dit verplicht):
- de scope slechts één GegevensdienstId bevat;
- bij de betreffende client_id en Gegevensdienst op de OAuth Client List ook een subscription notification endpoint en een resource notification endpoint voorkomen;
- zij namens deze Aanbieder ook Abonnementen op deze Gegevensdienst ontsluit;
- de waarde van de duur parameter in het request de waarde heeft van 0 of een waarde groter dan 0 die kleiner of gelijk is aan de maximale duur van het Abonnement zoals de betreffende Aanbieder deze aanbiedt.

Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid core.authint.207.

Toelichting

Zo voorkomt de Authorization Server dat gevolg wordt gegeven aan een verzoek dat blijkens de OAuth Client List of Aanbiederslijst niet is toegestaan.

Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.authint.203.

ext.abo.authint.201

3.

Onmiddellijk na authenticatie van de Persoon, zoals bedoeld in verantwoordelijkheid core.authint.204, en alleen als deze slaagt, vraagt de OAuth Authorization Server de Persoon om een Toestemmingsverklaring (in het geval van Verzamelen of Abonneren) of een Bevestigingsverklaring (in het geval van Delen), volgens het daaromtrent bepaalde op de pagina User interface (Autorisatieserver), volgens de standaard OAuth 2.0, op de wijze waarop deze in het MedMij Afsprakenstelsel wordt toegepast.

Dit geldt als uitbreiding op de verantwoordelijkheid zoals beschreven in core.authint.205.

ext.abo.authint.202

4.

Authorization Server en DVP Server behandelen uitzonderingssituaties inzake het authorization interface af volgens onderstaande tabel.

Nummer	Implementeert uitzonderingen	Uitzondering	Actie	Melding	Vervolg
Authorization interface 1a	Abonneren 1	Authorization Server ontvangt een authorization request zonder (geldige) `redirect_uri` en/of zonder een (geldige) `client_id`.	Authorization Server informeert de Persoon over de technische fout, zonder de Persoon automatisch te redirecten.	conform OAuth 2.0-RFC 6749, par. 4.1.2.1	Allen stoppen de flow van de functies Verzamelen/Delen en Abonneren onmiddellijk nadat de Persoon is geïnformeerd over de uitzondering.
Authorization interface 1b	Abonneren 1	Authorization Server ontvangt een ongeldige authorization request, anders dan uitzondering 1.	Authorization Server informeert DVP Server over de technische fout. DVP Server informeert Persoon.	conform OAuth 2.0-RFC 6749, par. 4.1.2.1 , met de daar genoemde, HTTP 302 'invalid_request'.
Authorization interface 2	Abonneren 2	Authorization Server kan de identiteit van de Persoon niet vaststellen.	Authorization Server informeert de Persoon dat diens verzoek geen voortgang kan vinden en noemt daarbij behorende reden.
Authorization interface 3	Abonneren 3	Authorization Server stelt tijdens de afhandeling van de authorization request vast dat: in geval van de functie Verzamelen: van Persoon bij Aanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is; in geval van de functie Delen: Aanbieder niet ontvankelijk is voor die Gegevensdienst van Persoon; in geval van de functie Abonneren: Persoon geen Notificaties beschikbaar maakt voor Persoon op die Gegevensdienst. Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.
Authorization interface 4	Abonneren 4	De autorisatievraag wordt ontkennend beantwoord.	Authorization Server 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.
Authorization interface 5	Abonneren 5	Authorization Server kan de autorisatie niet vaststellen.	Authorization Server informeert DVP Server over deze uitzondering. DVP Server informeert daarop Persoon hierover.	conform OAuth 2.0-specificatie, par. 4.1.2.1, error code `access denied`, met in de error description "`Authorization failed.`"

Toelichting

De uitzonderingssituaties kunnen gezien worden als de implementatie-tegenhangers van de uitzonderingen van de functies Verzamelen en de Delen. Op de Applicatielaag zijn deze echter per interface geordend. Alle uitzonderingen worden door de Authorization Server ontdekt. In deze versie van het MedMij Afsprakenstelsel is bepaald dat zij altijd leiden tot het zo snel mogelijk afbreken van de flow door alle betrokken rollen. Daartoe moeten echter eerst nog de andere rollen geïnformeerd worden. Om te voorkomen dat de DVP Server informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven, moet het onderscheid tussen de uitzonderingen 2, 3 en 4 niet te maken zijn door de DVP Server.

Deze tabel bevat alleen die uitzonderingssituaties ten aanzien waarvan het MedMij afsprakenstelsel eigen eisen stelt aan de implementatie. In de specificatie van OAuth 2.0 staan daarnaast nog generiekere uitzonderingssituaties, zoals de situatie waarin de redirect URI ongeldig blijkt. Ook deze uitzonderingssituaties moeten geïmplementeerd worden.

ext.abo.authint.203

Browser not supported