Document toolboxDocument toolbox

Vervallen op 14 mei 2022

Resource interface

Owned by Former user (Deleted)
Last updated: Jul 09, 2021 by Former user (Deleted)Version comment
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.
1a.

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.

1b.De OAuth Client voegt bij het versturen van een resource request een HTTP Header Field toe met de naam MedMij-Request-ID. Het MedMij-Request-ID moet een willekeurige waarde bevatten en dient uniek te zijn binnen het MedMij netwerk. Het kan een integer waarde zijn, of een UUID, maar kan ook volgens een ander geldig identificatiepatroon worden gevuld.
2.Na ontvangst van een resource request, in UCI Verzamelen of UCI 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 PGO Server. Dit gedrag van de Resource Server is gedurende minimaal 98,5% van de tijd beschikbaar.
3.

Voor zover er in het verkeer tussen PGO Server en Resource Server in de use case-implementaties UCI Verzamelen en UCI Delen sprake is, in de stuurgegevens, van een gegevenselement dat tot de identiteit van de Zorggebruiker 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. PGO Server, Authorization Server en Resource Server treffen goed beveiligde voorzieningen waarmee zij hieruit waar nodig zelf de identiteit van de Zorggebruiker 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 Zorggebruiker onderweg zo betekenisloos mogelijk te houden. Alle betekenis wordt er ter weerszijden aan verbonden door raadpleging van interne registraties. Omdat de PGO Server, Authorization Server en Resource Server samen een OAuth-flow afhandelen, beschikken zij (na authenticatie van de Zorggebruiker) over tokens die de identiteit van de Zorggebruiker 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.

4.

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

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 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.

Vervallen op 14 mei 2022