RFC0060 Lengte state parameter voorschrijven
- Former user (Deleted)
Samenvatting
| Waarom is deze RFC nodig? | Naar aanleiding van een vraag van een DVZA-deelnemer is gekeken naar de state parameter. De deelnemer ontving een authorization request van een DVP waarvan de state parameter een dusdanige grootte had (aantal karakters), dat dit verzoek niet verwerkt kon worden door de DVZA. De benodigde aanpassing om dit verzoek toch af te kunnen handelen is moeilijk uit te voeren (cloud omgeving, standaard libraries. De andere optie is om conform OAuth2 een 414 error terug te geven. Dit betekent echter dat de interoperabiliteit van MedMij in gevaar komt. De afweging die daarom gemaakt is, is om bovenop de OAuth2 standaard extra eisen vanuit MedMij toe te voegen voor de lengte van de state parameter. |
|---|---|
| Oplossingsrichting | Voorschrijven (bovenop OAuth2) van de minimale (vanuit beveiligingsperspectief) en maximale (vanuit operabiliteitsoverwegingen) lengte van state parameter |
| Aanpassing van | Afsprakenstelsel |
| Impact op rollen | DVP, DVZA |
| Impact op beheer | Neen |
| Impact op RnA | Neen |
| Impact op Acceptatie | Ja, extra test of deelnemer zich hier aan houdt (?) |
| PIA noodzakelijk | |
| Gerelateerd aan (Andere RFCs, PIM issues) | |
| Eigenaar | Arjan van Krimpen|
| Implementatietermijn | 1.5.0, 1.4.0 (?) |
| Motivatie verkorte RFC procedure (patch) | Direct doorvoeren op 1.4.0 om huidig gemelde probleem op te lossen. |
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
Op pagina Authorization interface bij 1a toevoegen in de tabel:
state
- conform sectie 4.1.1. van RFC 6749
Hiermee geeft de OAuth Client informatie mee aan de OAuth Authorization Server, waaraan eerstgenoemde later, bij de redirect, kan afleiden bij welk verzoek de authorization code hoort. Deze informatie is verder betekenisloos voor de OAuth Authorization Server.
De state moet
- een minimale lengte hebben van 128 karakters (Voldoende lang om niet raadbaar te zijn)
- een maximale lengte hebben van 512 karakters (Praktische grens, rekening houdend met standaard libraries en maximale lengte uri's)
NB: Er is geen impact op de foutafhandeling, wanneer een state niet voldoet aan bovenstaande eisen, moet een DVZA conform Authorization interface 1b en OAuth2-specificatie de desbetreffende fout geven.
NB2: Na uitvraag van 'werkbare' lengten voor state-parameter zijn een klein aantal inzendingen binnen gekomen; op basis daarvan handhaven wij het 512 maximimum.
NB3: Minimale lengte state verhoogd naar 128 in lijn met NL GOV Assurance profile for OAuth 2.0 v1.0.
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 |
|---|---|---|---|---|
| Verzoeken van nog niet aangepaste DVP's moeten worden geweigerd door aangepaste DVZA's. | M | H | Communicatie. Zorgen dat deelnemers op tijd geïnformeerd worden. |
Bijlagen