RFC0041 Aanscherping uitzonderingen OAuth Resource Servers

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	Ron van Holland (Unlicensed), Casper van der Harst
Implementatietermijn	Release 1.4.0
Motivatie verkorte RFC procedure (patch)

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
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
3 Dienstverleners concurreren op de functionaliteiten	NvT	13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders	Neutraal
4 Dienstverleners zijn aanspreekbaar door de gebruiker	NvT	14 Uitwisseling is een keuze	NvT
5 De persoon wisselt gegevens uit met de zorgaanbieder	NvT	15 Het MedMij-netwerk is gebruiksrechten-neutraal	NvT
6 MedMij spreekt alleen af wat nodig is	Positief	16 De burger regisseert zijn gezondheidsinformatie als uitgever	NvT
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener	NvT	17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld	NvT
9 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 2		De 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 3		De 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 6		Resource 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 1	UC 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 2		De 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 3		De 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 4		Het 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 6		Subscription 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 7		Subscription 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.

Deze RFC introduceert geen nieuwe beveiligingsrisico's.

Bijlagen

	File	Modified

No files shared here yet.