Samenvatting
| Waarom is deze RFC nodig? | De OAuth2 specificaties doen geen (harde) uitspraak over of/hoe urls die als parameter in een Oauth2 request of response worden meegegeven, moeten worden encoded. Dit kan potentieel tot problemen leiden wanneer bij het verwerken van een request/response een url 'dubbel' of 'anders' geencodeerd wordt en daarna niet correct meer kan worden verwerkt. Denk bijvoorbeeld aan de redirect_uri. De ruimte die OAuth laat, heeft tot nu toe nog niet in de praktijk geleid tot problemen. Wel is ontstond recent een probleem in de tooling van Acceptatie, waarbij een proxy automatisch url's encodeerde. Om problemen te voorkomen dat toekomstige ontwikkelomgevingen en tools ook een 'automagische encoding' toepassen zal een afspraak worden toegevoegd aan het AS. |
|---|---|
| Oplossingsrichting | In het Afsprakenstelsel een expliciete uitspraak opnemen (bovenop de OAuth2 specificatie) die de wijze van encodering voorschrijft. |
| Aanpassing van | Afsprakenstelsel |
| Impact op rollen | DVP, DVZA (gezien het feit dat er tot nu toe geen problemen zijn opgetreden, is de impact waarschijnlijk klein) |
| Impact op beheer | Geen |
| Impact op RnA | Geen |
| Impact op Acceptatie | Ja, aanpassingen aan scripts waar url's voorkomen in aanroepen. Uitbreiden testen met controle op encodering op voorgeschreven manier. |
| PIA noodzakelijk | |
| Gerelateerd aan (Andere RFCs, PIM issues) | |
| Eigenaar | Arjan van Krimpen Casper van der Harst|
| Implementatietermijn | 1.5 |
| Motivatie verkorte RFC procedure (patch) | Nvt |
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 | 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=hst0#frgmnt
\_____/ \_________________/\__________/ \_________/ \_____/
| | | | |
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 (of niet anders dan enkelvoudige URL_ENCODE)
- in het token request de redirect_uri NIET te encoden (of niet anders dan enkelvoudige URL_ENCODE)
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 )
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.
| 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