Document toolboxDocument toolbox

RFC0015 Uitzondering Token interface 2

Samenvatting

Waarom is deze RFC nodig?

Vanwege een fout in de specificatie van de foutafhandeling op het token interface. Bij uitzondering 2 wordt een foutmelding vereist (access denied) die bij het authorization interface hoort, niet bij het token interface. Het token interface kent in de OAuth-specificatie echter geen toepasselijke standaard foutmelding.

Oplossingsrichting

De reden voor deze foutmelding is dat de Authorization Server er ook op het token interface achter kan komen dat niet aan de beschikbaarheids- of ontvankelijkheidsvoorwaarde wordt voldaan. Er gelden een vroegste en laatste moment waarop er moet worden ingestaan voor deze voorwaarde. Liefst gebeurt dat zo vroeg mogelijk, op het authorization interface. Maar sommige leveranciers kunnen dat pas op het resource interface implementeren (in de Resource Server).

Tussen het authorization interface en het resource interface ligt echter het token interface dat, hoewel het voor niemand een logische plek voor implementatie van de voorwaarden is, nu wel een toegestane plek is. Niet voor niets kent de OAuth-spec geen toepasselijke foutmelding. Toegangskwesties worden geregeld op het authorization interface; het token interface is er slechts om op de backchannel de token-uitgifte af te ronden.

De oplossing is daarmee om het instaan voor deze voorwaarden alleen toe te staan op:
- het authorization interface en het resource interface, voor UC(I) Verzamelen
- het authorization interface, voor UC(I) Delen

Aanpassing van
Impact op rollen

Authorization Server: OAuth-compliant maken van het token interface. De scheiding tussen Regie en Uitwisseling wordt scherper, vooral bij UC(I) Delen.

Impact op beheer

Geen

Impact op RnA

Nee, nu niet voorzien

Impact op Acceptatie

Ja

Gerelateerd aan (Jira issues)
EigenaarRon van Holland (Unlicensed) Arjan van Krimpen (Unlicensed)
Implementatietermijn

1.3.0 (okt 2020)

Motivatie verkorte RFC procedure (patch)

Indien er een release 1.2.1 komt, dan wel direct meenemen.

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

Neutraal

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten 

Neutraal

12 Het afsprakenstelsel is een groeimodel

Neutraal

Dienstverleners concurreren op de functionaliteiten

Neutraal

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Neutraal

Dienstverleners zijn aanspreekbaar door de gebruiker

Neutraal

14 Uitwisseling is een keuze

Neutraal

De persoon wisselt gegevens uit met de zorgaanbieder

Neutraal

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Neutraal

De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Neutraal

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Neutraal

De dienstverleners zijn deelnemers van het afsprakenstelsel

Neutraal

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Neutraal

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Neutraal

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Neutraal

Uitwerking

De UC's kennen de notie van een "interface" niet. Daarom geen aanpassing nodig in UC Verzamelen, Delen en Abonneren.

Geen aanpassing nodig van sectie "Beschikbaarheids- en ontvankelijkheidsvoorwaarde".


Aanpassen in secties UCI Verzamelen, UCI Delen en UCI Abonneren

De aanduiding van de vroegste en laatste momenten van de toetsen in de platen corrigeren. D.w.z. preciezer aangeven tussen welke stappen de toets wel en niet kan plaatsvinden. De teksten kunnen ongewijzigd blijven.

  • UCI Verzamelen: toets toegestaan v.a. "vraag om autorisatie" tot "geef autorisatiecode uit" en v.a. "valideer access token" tot "doe resource response"
  • UCI Delen: toets toegestaan v.a. "vraag om bevestiging" tot "geef autorisatiecode uit"
  • UCI Abonneren: toets toegestaan v.a. "vraag om autorisatie" tot "geef autorisatiecode uit" en v.a. "valideer access token" tot "doe subscription response"

Aanpassen in sectie Token interface:

6. OAuth Authorization Server en OAuth Client behandelen uitzonderingssituaties inzake het token interface volgens onderstaande tabel.

NummerImplementeert uitzonderingUitzonderingActieMeldingVervolg
Token interface 1

UC Verzamelen 6

UC Delen 6

UC Abonneren 6

Authorization Server moet vanwege één van de in de OAuth 2.0-specificatie, par. 5.2, genoemde redenen de token request weigeren.Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover.met de conform OAuth 2.0-specificatie, par. 5.2, toepasselijke error codeAllen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.







Risico's

Geen.










Bijlagen

  File Modified
No files shared here yet.