RFC0054 Langdurige en offline autorisatie van DVP

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
  • DVA biedt hiervoor een systeeminterface aan de DVP
• Intrekken kan bij voorkeur op termijn ook bij één of meerdere onafhankelijke toestemmingsvoorzieningen (voor nu buiten scope)

Wat is hiervoor nodig:

• DVA moet voor een gegeven toestemming, op het moment dat deze wordt gebruikt, 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.

• 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 voorwaardelijke autorisatie 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, d.w.z. indien vroeg getoetst en niet beschikbaar voor Persoon) De volgende, van de door u gevraagde, gegevens worden door Naamaanbieder niet aan u beschikbaar gesteld:
   - NaamGegevensdienst;
   - NaamGegevensdienst.
   

   Zonder stap 3

   U geeft hierbij <Naamaanbieder> toestemming om <NaamCategorie> uit te wisselen met <NaamLeverancierPGO>, voor het doel persoons- en gezondheidsgegevens op te nemen in uw persoonlijke gezondheidsomgeving. Deze toestemming is geldig tot de hieronder opgegeven einddatum. Indien u geen einddatum opgeeft, geldt de toestemming totdat u deze intrekt.

   -Einddatum: <Einddatum>

   De volgend gegevens zijn voor u beschikbaar en worden met <NaamLeverancierPGO> gedeeld. Indien u bepaalde gegevens niet wilt laten uitwisselen, kunt u deze uitschakelen:
   [] <NaamGegevensdienst>;
   [] <NaamGegevensdienst>.

   [toestemmingbutton]

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.

N.t.b.

DVP, DVA

N.t.b.

N.t.b.

Ja

Deze RFC is afhankelijk van RFC0039.

Ron van Holland (Unlicensed) Bouke de Boer | MedMij 

1.5.0