Page tree
Skip to end of metadata
Go to start of metadata

Samenvatting

Waarom is deze RFC nodig?

Deze RFC is nodig om de kern van het afsprakenstelsel zo veel mogelijk generiek van toepassing te kunnen laten zijn voor verschillende domeinen naast het zorgaanbiederdomein.

Ook is deze RFC nodig om meer duidelijkheid te scheppen aan deelnemers over de juiste afhandeling van uitzonderingsituaties door OAuth Resource Servers. De RFC betreft daarom zowel de resource interface als de subscription interface.

Het MedMij afsprakenstelsel hanteert RFC6749 als generieke basis voor OAuth. In RFC6749 wordt ondermeer verwezen naar RFC6750 voor de wijze waarop access tokens dienen te worden gebruikt bij de OAuth resource server en voor de juiste afhandeling hiervan door de OAuth resource server. RFC0041 verheldert de relatie tussen RFC6749 en RFC6750, met name voor wat betreft de omgang met uitzonderingen.

Oplossingsrichting

In de interfaces specificaties van het MedMij Afsprakenstelsel, inclusief de uitzonderingen, dienen geen elementen uit domeinspecifieke standaarden te worden opgenomen. De koppeling van de generieke eisen uit het afsprakenstelsel aan een domein moet volledig plaatsvinden binnen de informatiestandaard van het betreffende domein.

Verheldering van de juiste toepassing van de OAuth standaard in uitzonderingssituaties.

Benoemen dat specificaties van de resource interface in het afsprakenstelsel prevaleren boven specificaties in de informatiestandaard.

Aanpassing van

De tabel met uitzonderingen van de resource interface en van de subscription interface.

Impact op rollen

DVP (mogelijk, wanneer in bepaalde foutsituaties was gerekend op een andere response)
DVZA (mogelijk, wanneer in bepaalde foutsituaties een andere dan de gewenste response wordt gestuurd)

Uitzondering subscription interface 1, zoals beschreven in versie 1.3.0 van het afsprakenstelsel, wordt in deze RFC wel gewijzigd. DVP's en DVZA's die zijn geaccepteerd voor abonneren & notificeren dienen hun implementaties hier dus mogelijk zeker op aan te passen.

Impact op beheer

Geen.

Impact op RnA

Geen.

Impact op Acceptatie

Vereist mogelijk aanscherpingen in acceptatiescripts.

Gerelateerd aan (Andere RFCs, PIM issues)

AF-1202

Eigenaar
Implementatietermijn

Release 1.4.0

Motivatie verkorte RFC procedure (patch)


Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Positief

11 Stelselfuncties worden vanaf de start ingevuld

NvT

2 Dienstverleners zijn transparant over de gegevensdiensten 

NvT

12 Het afsprakenstelsel is een groeimodel

Positief

Dienstverleners concurreren op de functionaliteiten

NvT

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Neutraal

Dienstverleners zijn aanspreekbaar door de gebruiker

NvT

14 Uitwisseling is een keuze

NvT

De persoon wisselt gegevens uit met de zorgaanbieder

NvT

15 Het MedMij-netwerk is gebruiksrechten-neutraal

NvT

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

NvT

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

NvT

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

NvT

De dienstverleners zijn deelnemers van het afsprakenstelsel

NvT

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

NvT

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

NvT

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Positief

Uitwerking

Resource interface

Gewijzigde verantwoordelijkheid 4:

4. OAuth Resource Server en OAuth Client handelen uitzonderingssituaties inzake het resource interface af volgens onderstaande tabel. Naast de meldingen die zijn benoemd in de tabel, is het mogelijk dat de Resource Server ook meldingen dient te includeren die zijn gespecificeerd in de informatiestandaard waar het resource request deel van uitmaakt. De meldingen die zijn benoemd in onderstaande tabel zijn echter ten alle tijden leidend.

Nummer

Implementeert uitzondering

Uitzondering

Actie

Melding

Vervolg

Resource interface 1

UC Verzamelen 6

UC Delen 6






Het resource request bevat geen access_token.Resource Server informeert PGO Server over deze uitzondering. 



Een Status-Code 401 conform HTTP specificatie. In deze situatie retourneert de Resource Server uitdrukkelijk géén nadere informatie over de opgetreden uitzondering.

PGO Server informeert daarop Zorggebruiker over deze uitzondering.

Na afhandeling van de in deze tabel benoemde informatiestappen, stoppen allen de onmiddellijk met de flow.





Resource interface 2De Resource Server detecteert dat het meegezonden access_token is verlopen of om een andere reden niet geldig is.

Een Status-Code 401 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_token". conform RFC 6750.

Resource interface 3De Resource Server detecteert dat de scope die is verbonden aan het meegezonden access_token niet toereikend voor de uitvoering van het resource request.Een Status-Code 403 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "insufficient_scope". conform RFC 6750.
Resource interface 4

Het resource request mist een vereiste (header) parameter, bevat een niet-ondersteunde (header) parameter of parameterwaarde, gebruikt meer dan één methode voor het doorgeven van een access_token, of is op een andere wijze misvormd.

Een Status-Code 400 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_request". conform RFC 6750.
Resource interface 5

De Resource Server detecteert dat niet kan worden voldaan aan de beschikbaarheidsvoorwaarde.

Zie ook de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Een Status-Code 403 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "access_denied". conform RFC 6750.

Het vereiste error attribuut is bewust in lijn gebracht met het gedrag van de Authorization Server bij deze uitzonderingssituatie.

Resource interface 6Resource Server kan in de request niet, niet geheel of niet tijdig voorzien, om redenen anders dan in bovengenoemde uitzonderingen.Een toepasselijke Status-Code conform HTTP specificatie.

Subscription interface

Gewijzigde verantwoordelijkheid 8:

8. OAuth Resource Server en OAuth Client handelen uitzonderingssituaties inzake het subscription interface af volgens onderstaande tabel.

Nummer

Implementeert uitzondering

Uitzondering

Actie

Melding

Vervolg

Subscription interface 1UC Abonneren 6






Het subscription request bevat geen access_token.Subscription Server informeert PGO Server over deze uitzondering.






Een Status-Code 401 conform HTTP specificatie. In deze situatie retourneert de Subscription Server uitdrukkelijk géén nadere informatie over de opgetreden uitzondering.

PGO Server informeert daarop Zorggebruiker over deze uitzondering.

Na afhandeling van de in deze tabel benoemde informatiestappen, stoppen allen de onmiddellijk met de flow.







Subscription interface 2De Subscription Server detecteert dat het meegezonden access_token is verlopen of om een andere reden niet geldig is.Een Status-Code 401 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_token". conform RFC 6750.
Subscription interface 3De Subscription Server detecteert dat de scope die is verbonden aan het meegezonden access_token niet toereikend voor de uitvoering van het subscription request.Een Status-Code 403 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "insufficient_scope". conform RFC 6750.
Subscription interface 4Het subscription request mist een vereiste (header) parameter, bevat een niet-ondersteunde (header) parameter of parameterwaarde, gebruikt meer dan één methode voor het doorgeven van een access_token, of is op een andere wijze misvormd.Een Status-Code 400 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_request". conform RFC 6750.
Subscription interface 5

De Subscription Server detecteert dat niet kan worden voldaan aan de beschikbaarheidsvoorwaarde.

Zie ook de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Een Status-Code 403 conform HTTP specificatie en een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "access_denied". conform RFC 6750.

Het vereiste error attribuut is bewust in lijn gebracht met het gedrag van de Authorization Server bij deze uitzonderingssituatie.

Subscription interface 6Subscription Server ontvangt een correct verzoek dat op basis van door de Zorgaanbieder ingesteld beleid geweigerd wordt.

Een Status-Code 422 "Aanvraag kan niet verwerkt worden" conform HTTP specificatie.

Subscription interface 7Subscription Server ontvangt een correct verzoek dat echter verwijst naar een niet bestaand Abonnement (subscription-id).

Een Status-Code 404 "Niet gevonden" conform HTTP specificatie.

Subscription interface 8

Subscription Server kan in de request niet, niet geheel of niet tijdig voorzien, om redenen anders dan in bovengenoemde uitzonderingen.

Een toepasselijke Status-Code conform HTTP specificatie.

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

DreigingKansImpactDreigingsID (intern)Maatregelen










Bijlagen

No files shared here yet.


  • No labels

1 Comment

  1. Ik heb met N. van Galen gekeken naar het voorstel. Hieruit vallen nog enkele verbeteringen te halen voor de Nictiz FHIR IG. Deze zijn vastgelegd in BITS ticket MM-1182.