Het resource interface hoort bij de hoofdfunctie Uitwisseling.
...
- 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.
| Expand |
|---|
| 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. | Expand |
|---|
| 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 Clienthandelen 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 |
, 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. |
|
