Document toolboxDocument toolbox

Under construction!

Voor de huidige versie https://afsprakenstelsel.medmij.nl/display/MMOptioneel

Resource interface

Owned by Casper van der Harst
May 09, 2023
3 min read


Het resource interface hoort bij de hoofdfunctie Uitwisseling.

Op deze pagina staan alleen de verantwoordelijkheden inzake het resource interface die nog niet genoemd staan in:

  • de OAuth 2-specificatie;
  • de informatiestandaard van de Gegevensdienst die op het resource interface wordt aangesproken.
1.

De OAuth Client gebruikt voor het sturen van het acces token, in de resource request, de methode Authorization Request Header Field, zoals beschreven in sectie 2.1 van RFC6750.

 Toelichting

De methode Authorization Request Header Field biedt de beste beveiliging.

core.rscint.200

2.De OAuth Client voegt bij het versturen van een resource request twee HTTP Header Fields toe, de eerste met de naam MedMij-Request-ID, de tweede met de naam X-correlation-ID. Het MedMij-Request-ID moet een willekeurige waarde bevatten en dient uniek te zijn voor ieder request binnen het MedMij netwerk. De waarde bestaat uit een UUID. Het X-Correlation-ID wordt overgenomen van X-Correlation-ID uit het Authorization request. Als gebruikgemaakt wordt van langdurige toestemming, dan wordt X-Correlation-ID uit het Token request overgenomen.

core.rscint.201

3.Na ontvangst van een resource request, in de functies Verzamelen of Delen, zal de Resource Server, indien in antwoord daarop een resource response dient te worden gedaan, na maximaal zestig (60) seconden dit resource response ter beschikking stellen aan de DVP Server. Dit gedrag van de Resource Server is gedurende minimaal 98,5% van de tijd beschikbaar.

core.rscint.202

4.

Voor zover er in het verkeer tussen DVP Server en Resource Server in de implementaties van de functies Verzamelen en Delen sprake is, in de stuurgegevens, van een gegevenselement dat tot de identiteit van de Persoon herleid kan worden, gebruiken zij daarvoor niets anders dan de OAuth-gegevens die zij in hun respectievelijke OAuth Client en OAuth Resource Server moeten uitwisselen. DVP Server, Authorization Server en Resource Server treffen goed beveiligde voorzieningen waarmee zij hieruit waar nodig zelf de identiteit van de Persoon kunnen vaststellen.

 Toelichting

Met het oog op het borgen van de privacy en het zo eenvoudig mogelijk houden van de architectuur van het MedMij Afsprakenstelsel, wordt ervoor gekozen de identifier voor de Persoon onderweg zo betekenisloos mogelijk te houden. Alle betekenis wordt er ter weerszijden aan verbonden door raadpleging van interne registraties. Omdat de DVP Server, Authorization Server en Resource Server samen een OAuth-flow afhandelen, beschikken zij (na authenticatie van de Persoon) over tokens die de identiteit van de Persoon vertegenwoordigen, namelijk (eerst) de authorization code en (later) het access token. Buiten deze hoeft en zal er geen identificerende gegevenselementen in het verkeer worden opgenomen. Het FHIR-gegevenselement PatientID wordt niet gebruikt.

core.rscint.203

5.

OAuth Resource Server en OAuth Client handelen uitzonderingssituaties inzake het resource interface af volgens onderstaande tabel. De Resource Server dient de status code uit de tabel te retourneren in combinatie met de bijbehorende melding zoals gespecificeerd in de gebruikte informatiestandaard (indien van toepassing). 

NummerImplementeert uitzonderingUitzonderingActieMeldingVervolg
Resource interface 1

Verzamelen 3

Delen 2

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

Een statuscode 400 of een statuscode 401, beiden worden binnen MedMij geaccepteerd. In deze situatie retourneert de Resource Server géén nadere informatie over de opgetreden uitzondering, conform RFC 6750.

DVP Server informeert daarop Persoon over deze uitzondering.

Na afhandeling van de in deze tabel benoemde informatiestappen stoppen allen 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 4Het 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.De flow mag worden voortgezet.

core.rscint.204