Page tree
Skip to end of metadata
Go to start of metadata

Samenvatting

Waarom is deze RFC nodig?

Deze RFC is nodig om de gebruiksvriendelijkheid van MedMij voor gebruikers (Persoon) en (zorg)aanbieders te vergroten.

Doelstellingen:

  1. Persoon hoeft niet voor iedere uitwisseling (opnieuw) in te loggen en toestemming te geven;
  2. PGO Server verkrijgt naast online access ook offline access, d.w.z. PGO Server kan ook gegevens uitwisselen met een Resource Server, zonder dat Persoon online is.

Scope:

  • UC Verzamelen (UC Delen volgt in een later stadium)

Requirements:

  • Persoon kan kiezen hoe lang een toestemming geldt en kan deze weer intrekken
  • Intrekken kan tenminste vanuit de betreffende DVP bij de DVA - DVP biedt hiervoor verplicht een gebruikersinterface aan de Persoon
  • Intrekken kan bij voorkeur op termijn ook bij één of meerdere onafhankelijke toestemmingsvoorzieningen (voor nu buiten scope)
Input van deelnemers
  1. Graag de oplossing met refresh_tokens zoveel mogelijk conform de standaard vormgeven. Mogelijk ook MedMij standaarden hanteren voor de mogelijke geldigheidstermijnen. En goed nadenken over foutsituaties en foutafhandeling.

  2. Oplossing met refresh_tokens goed afstemmen met Logius/DigiD. E.e.a. ook in het kader van de Wet Digitale Overheid (WDO).

  3. Ook security officers van (grote) zorginstellingen betrekken bij een op te zetten risico-analyse.

Oplossingsrichting

Wat is hiervoor nodig:

  • DVA moet voor een gegeven toestemming ook de beschikbaarheid van de Aanbieder kunnen toetsen of afleiden
  • PGO Server moet iets van een “toegangsbewijs” kunnen insturen, met een langdurige geldigheidstermijn
  • Dit "toegangsbewijs" moet door DVA, zonder nadere interactie met Persoon
    • kunnen worden gerelateerd aan het BSN van Persoon
    • kunnen worden gevalideerd

Gekozen oplossingsrichting:

  • OAuth refresh_tokens, inclusief de mogelijkheid om refresh_tokens in te trekken (token revocation).


Samenvatting:

  • Aanbieder volgt, binnen de grenzen van beschikbaarheid, de toestemming van Persoon en zet deze om in een autorisatie (access_token) EN in een voorwaardelijke autorisatie (refresh_token)
  • Access_token
    • Geldigheidsduur van 15 minuten
    • Scope omvat één of meerdere aanbieder-gegevensdienst combinaties
  • Refresh_token
    • Geldigheidsduur van de verleende toestemming
    • Scope omvat één of meerdere aanbieder-categorie combinaties (zodat een toestemming langer kan bestaan dan een gegevensdienst)
  • O.b.v. het refresh_token kan de DVP ook zonder dat Persoon is ingelogd, gegevens uitwisselen met de betreffende Aanbieder - DVA toetst de beschikbaarheidsvoorwaarde
    • bij het verstrekken van een access_token o.b.v. een refresh_token, OF
    • bij het gebruik van een verkregen access_token bij de Resource Server
  • Hiermee wordt de voorwaardelijke autorisatie omgezet in een autorisatie


Flow voor 1e verzamel-actie:

  1. Persoon kiest de (één) aanbieder en de gewenste (gegevens)diensten.
  2. DVP bepaalt het juiste authorization endpoint en het juiste token endpoint.
  3. De autorisatieserver ontvangt, van de OAuth User Agent, een Authorization Request met in de scope één of meerdere diensten van deze aanbieder en de gewenste duur voor autorisatie.
  4. Gebruiker authentiseert zich bij een Authenticatie Provider en wordt teruggestuurd naar de autorisatieserver.
  5. Optioneel: de autorisatieserver toetst de beschikbaarheidsvoorwaarde voor de gewenste (gegevens)diensten.
  6. De autorisatieserver toont een toestemmingscherm met de tekst:

    U geeft hierbij Naamaanbieder toestemming om gedurende Periode, met NaamLeverancierPGO NaamCategorie uit te wisselen, voor het doel deze persoons- en gezondheidsgegevens op te nemen in uw persoonlijke gezondheidsomgeving.

    (Optioneel) De volgende, van de door u gevraagde, gegevens worden door Naamaanbieder niet aan u beschikbaar gesteld:
    - NaamGegevensdienst;
    - NaamGegevensdienst.

  7. De PGO server verkrijgt
    1. een access_token (15 minuten) voor de toegekende scope (aanbieder-dienst-combinaties) EN
    2. een refresh_token dat geldig is voor de overeengekomen duur en toestemming (aanbieder-categorie-combinaties)
  8. DVP bepaalt de juiste resource endpoints.
  9. De PGO server gebruikt het access_token bij de benodigde interacties met de resource server.


Flow bij herhaalde verzamel-actie:

  1. DVP detecteert dat het beschikt over een geldig refresh_token.
  2. DVP bepaalt het juiste token endpoint.
  3. De PGO server verkrijgt d.m.v. het refresh_token, voor één of meerdere diensten van deze aanbieder
    1. een geldig access_token (15 minuten) voor de toegekende scope (aanbieder-dienst-combinaties)
    2. een nieuw refresh_token dat geldig is voor de eerder overeengekomen duur en scope (oude refresh_token wordt ongeldig).
  4. DVP bepaalt de juiste resource endpoints.
  5. De PGO server gebruikt het access_token bij de benodigde interacties met de resource server.
Aanpassing van

N.t.b.

Impact op rollen

DVP, DVA

Impact op beheer

N.t.b.

Impact op RnA

N.t.b.

Impact op Acceptatie

Ja

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

Deze RFC is afhankelijk van RFC0039.

Eigenaar
Implementatietermijn

1.5.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
  •  
Dienstverleners concurreren op de functionaliteiten
  •  
13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
  •  
Dienstverleners zijn aanspreekbaar door de gebruiker
  •  
14 Uitwisseling is een keuze
  •  
De persoon wisselt gegevens uit met de zorgaanbieder
  •  
15 Het MedMij-netwerk is gebruiksrechten-neutraal
  •  
MedMij spreekt alleen af wat nodig is
  •  
16 De burger regisseert zijn gezondheidsinformatie als uitgever
  •  
De persoon en de zorgaanbieder kiezen hun eigen dienstverlener
  •  
17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
  •  
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

Volgt.

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
N.t.b.





Bijlagen

No files shared here yet.


  • No labels