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