Document toolboxDocument toolbox

RFC0047 State op het Authorization endpoint

Owned by Casper van der Harst
Last updated: Apr 11, 2021

Samenvatting

Waarom is deze RFC nodig?

De huidige definitie en beschrijving van het attribuut state op het authorization endpoint geven onduidelijkheid.

Er staan twee eisen aan de vulling. De eerste is dat voldaan moet worden aan de eisen van sectie 4.1.1. van RFC 6749. De tweede geeft aan dat de waarde geen URI mag bevatten.

Als aan de eisen van sectie 4.1.1. van RFC 6749 wordt voldaan, is de tweede stelling dubbel op. Maar, doordat deze specifiek wijst naar het het niet gebruiken van URI, bestaat de kans dat de focus hierop komt te liggen. Mede door de beschrijving, welke ook vooral naar URI verwijst. Dit is niet correct, daar de waarde van state OPAQUE moet zijn en dus betekenisloos.

Oplossingsrichting

Verwijder de tekst 'de waarde mag geen URI bevatten' en 'De tweede eis is een maatregel tegen beveiligingsrisico 4.1.5. De state-parameter mag niet bedoeld zijn om te worden toegevoegd aan, of anderszins verwerkt in de redirect_uri.'.

In een Best practice kan worden uitgelegd wat wel geoorloofd is en wat niet. Het schrijven van een Best practice is fase twee en wordt na de 1.4.0 release uitgevoerd.

Aanpassing van

Beschrijving van de Authorization Interface, en dan specifiek van het attribuut state.

Impact op rollen

Geen, de eisen vanuit sectie 4.1.1. van RFC 6749 blijven staan en zijn afdoende.

Impact op beheer

Geen, de eisen vanuit sectie 4.1.1. van RFC 6749 blijven staan en zijn afdoende.

Impact op RnA

Geen, de eisen vanuit sectie 4.1.1. van RFC 6749 blijven staan en zijn afdoende.

Impact op Acceptatie

Geen, de eisen vanuit sectie 4.1.1. van RFC 6749 blijven staan en zijn afdoende.

PIA noodzakelijk
  •  
Gerelateerd aan (Andere RFCs, PIM issues)


Eigenaar

Casper van der Harst Bouke de Boer | MedMij

Implementatietermijn

1.4.0

Motivatie verkorte RFC procedure (patch)


Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
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

Als aan de eisen van sectie 4.1.1. van RFC 6749 wordt voldaan, is de tweede stelling dubbel op. Maar, doordat deze specifiek wijst naar het het niet gebruiken van URI, bestaat de kans dat de focus hierop komt te liggen. Mede door de beschrijving, welke ook vooral naar URI verwijst. Dit is niet correct, daar de waarde van state OPAQUE moet zijn en dus betekenisloos. Als we deze teksten verwijderen, voldoet staat waar het aan moet voldoen.

state

  1. conform sectie 4.1.1. van RFC 6749
  2. de waarde mag geen URI bevatten

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 tweede eis is een maatregel tegen beveiligingsrisico 4.1.5. De state-parameter mag niet bedoeld zijn om te worden toegevoegd aan, of anderszins verwerkt in de redirect_uri.

state

  1. 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.

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.

DreigingKansImpactDreigingsID (intern)Maatregelen





Bijlagen

  File Modified
No files shared here yet.