...
| Principe | Principe | ||
|---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | 11 Stelselfuncties worden vanaf de start ingevuld | ||
| 2 Dienstverleners zijn transparant over de gegevensdiensten | 12 Het afsprakenstelsel is een groeimodel | ||
| 3 Dienstverleners concurreren op de functionaliteiten | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | ||
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | 14 Uitwisseling is een keuze | ||
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | ||
| 6 MedMij spreekt alleen af wat nodig is | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | ||
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | ||
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | ||
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | ||
| Toelichting | |||
Uitwerking
In MedMij wordt in het OAuth2 protocol de redirect_uri alleen statisch toegepast om beveiligingsredenen (conform https://tools.ietf.org/html/rfc6819#section-5.2.3.3).
https://willekeurigpgo.nl/over/there?srvr=hst1#nose
\_____/ \_________________/\__________/ \_________/ \__/
| | | | |
scheme authority path query fragment
Dit betekent in de praktijk dat een redirect_uri binnen MedMij (waarschijnlijk) alleen zal zijn opgebouwd uit een scheme, authority/domein en path deel :
- Conform OAuth2 mag er geen fragment gebruikt worden
- Omdat binnen MedMij de url statisch wordt gebruikt, (b)lijkt het query deel geen toegevoegde waarde. (Een scan van de OCL bevestigd dat dit in ieder geval op dit moment zo is. )
Een tweede reden om geen query toe te staan op de redirect_uri is om te voorkomen dat hier 'status'-informatie wordt opgeslagen. OAuth2 heeft hier juist de 'state'-parameter voor bedoelt in het request.
Door binnen MedMij het query deel van de redirect_uri niet langer te gebruiken en te verbieden, is er geen noodzaak meer om de redirect_uri te encoden.
Binnen MedMij zou daarom de eis toegevoegd worden om:
- in het authorization request de redirect_uri NIET te encoden
- in het token request de redirect_uri NIET te encoden
Dit betekent dat DVP's encoding moeten verwijderen uit hun codebase en dat DVZA's er van uit kunnen gaan dat de redirect_uri niet encoded is.
Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )
...
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.
| Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
|---|---|---|---|---|
| DVZA kan authorization of token request niet verwerken door encode url in request. | L | H | In Acceptatie controleren op correct gebruik redirect_uri in requests. |
Bijlagen
| Attachments |
|---|