Skip to end of banner
Go to start of banner

RFC0015 Uitzondering Token interface 2

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

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

Nee, nu niet voorzien

Gerelateerd aan (Jira issues)
Eigenaar

Paul Oude Luttighuis

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.

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 van de UCI Verzamelen/UCI Delen onmiddellijk na geïnformeerd te zijn over de uitzondering.







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.

DreigingKansImpactMaatregelen




Bijlagen

  File Modified
No files shared here yet.


  • No labels