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). |
| Aanpassing van | /wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136155521, /wiki/spaces/MedMijAfsprakenStelselOntwikkeling120/pages/136159141: in de plaat en de toelichting het token interface uitsluiten . |
| 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) | |
| 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
| 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 | Neutraal | 11 Stelselfuncties worden vanaf de start ingevuld | Neutraal |
| 2 Dienstverleners zijn transparant over de gegevensdiensten | Neutraal | 12 Het afsprakenstelsel is een groeimodel | Neutraal |
| 3 Dienstverleners concurreren op de functionaliteiten | Neutraal | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Neutraal |
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | Neutraal | 14 Uitwisseling is een keuze | Neutraal |
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | Neutraal | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Neutraal |
| 6 MedMij spreekt alleen af wat nodig is | Positief | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Neutraal |
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Neutraal | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Neutraal |
| 9 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.
| Nummer | Implementeert uitzondering | Uitzondering | Actie | Melding | Vervolg |
|---|---|---|---|---|---|
| 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 code | Allen 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.
| Dreiging | Kans | Impact | Maatregelen |
|---|---|---|---|
Bijlagen