RFC0047 State op het Authorization endpoint

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
Implementatietermijn	1.4.0
Motivatie verkorte RFC procedure (patch)

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

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

conform sectie 4.1.1. van RFC 6749
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

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.

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen

Bijlagen

	File	Modified

No files shared here yet.