Versions Compared

Old Version 1

changes.mady.by.user Kailesh Bansi (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Kailesh Bansi (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.


Info

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


Anchor
ext.abo.authint.200
ext.abo.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.

Expand
titleToelichting

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


Info

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


Anchor
ext.abo.authint.201
ext.abo.authint.201
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 Persoonom 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.

Info

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


Anchor
ext.abo.authint.202
ext.abo.authint.202
ext.abo.authint.202

4.

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

NummerImplementeert uitzonderingenUitzonderingActieMeldingVervolg
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 User Agent over deze uitzondering. Authorization Server voert geen redirect naar de Client uit, ook niet met een foutmelding. 


Authorization Server informeert de Persoon over de technische fout, zonder de Persoon automatisch te redirecten. 

conform OAuth 2.0-specificatie, par. 4.1.2.1

conform OAuth 2.0-RFC 6749, par. 4.1.2.1  

Allen stoppen de flow van de functies Verzamelen/Delen en Abonneren onmiddellijk na geïnformeerd te zijn over de uitzondering.


Allen stoppen de flow van de functies Verzamelen/Delen en Abonneren onmiddellijk nadat de Persoon is geïnformeerd over de uitzondering.



Authorization interface 1b

Authorization Server ontvangt een ongeldige authorization request, anders dan uitzondering 1.

Authorization Server informeert DVP Server over deze uitzondering. DVP Server informeert Persoon daarover.


Authorization Server informeert DVP Server over de technische fout. DVP Server informeert Persoon .

conform OAuth 2.0-specificatie, par. 4.1.2.1, met de daar genoemde, zo specifiek mogelijke, toepasselijke error code HTTP 302 'invalid_request' 
Authorization interface 2

Abonneren 2

Authorization Server kan de identiteit van de Persoon niet vaststellen.

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 Server informeert de Persoon dat diens verzoek geen voortgang kan vinden en noemt daarbij behorende reden. 




conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Access denied."
Authorization interface 3

Abonneren 3

Authorization Server stelt tijdens de afhandeling van de authorization request vast dat:

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 Serverinformeert daarop Persoon hierover.conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Authorization failed."


Expand
titleToelichting

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.


Anchor
ext.abo.authint.203
ext.abo.authint.203
ext.abo.authint.203

...