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

Toelichting

De toelichtingen bij release 1.1 maken geen onderdeel uit van de formele afspraken, maar verduidelijken bestaande afspraken en dragen daarmee bij aan een eensluidende implementatie. Bij de eerstvolgende major release worden de toelichtingen geïntegreerd in de afsprakenset.

Applicatierollen en hun getalsverhoudingen

De rollen in het MedMij Afsprakenstelsel zijn bijeen horende setjes verantwoordelijkheden. Ze komen voor op elke laag van de architectuur, van de Juridische laag, via de Processen-en-Informatie-laag en de Applicatie-laag tot de Netwerk-laag. Tussen twee aangrenzende architectuurlagen, zijn de rollen aan elkaar gekoppeld. Een rol op de ene laag gaat gepaard met een of meerdere rollen op de laag eronder. Een rol is dus geen component of systeem. Menige rol wordt weliswaar door componenten en systemen gerealiseerd, maar hoe dat precies gebeurt, en hoeveel en welke componenten- of systeemarchitectuur daarvoor wordt gebruikt is aan de Dienstverlener , zolang deze zijn rollen, op alle lagen, maar naar behoren speelt, dat wil zeggen, de verantwoordelijkheden van die rollen draagt.

Voor een Dienstverlener moet er maximale vrijheid zijn om één rol op het ene niveau in te richten met meerdere op de laag eronder. Het moet echter andersom wel duidelijk blijven, op alle lagen, dat er één Dienstverlener verantwoordelijk is voor elke rol. Meerdere rollen kunnen dus niet op één lagere worden afgebeeld. Het is wel mogelijk dat meerdere rollen door een gezamenlijk systeem gerealiseerd worden, zolang hun afzonderlijke eindverantwoordelijken maar intact blijven.

De Nodes op Netwerk-niveau worden geïdentificeerd met een hostname. Omdat dus ook elke PGO Node en ZA Node bij één Dienstverlener hoort, is aan de hostname de Dienstverlener te herkennen.

In het persoonsdomein geldt zo dat:

  • één Dienstverlener Persoon één of meerdere Uitgevers verzorgt en elke Uitgever verzorgd wordt door één Dienstverlener Persoon;
  • één Uitgever door één of meerdere PGO Servers wordt gerealiseerd en elke PGO Server één Uitgever realiseert;
  • één PGO Server door één of meerdere PGO Nodes wordt ondersteund en elke PGO Node één PGO Server ondersteunt.

Zo kan dus ook in de OAuth Clientlist de hostname van een PGO Node geassocieerd worden met één (gebruikersvriendelijke naam van de) PGO Server .

In het zorgaanbiedersdomein geldt zo dat:

  • één Dienstverlener Zorgaanbieder één of meerdere Bronnen en/of Lezers verzorgt en elke Bron en/of Lezer verzorgd wordt door één Dienstverlener Zorgaanbieder;
  • één Bron en/of Lezer door één of meer combinaties van ééAuthorization Server en één Resource Server  wordt gerealiseerd en elke combinatie van één Authorization Server en één Resource Server één Bron en/of Lezer realiseert;
  • één Authorization Server, net als één Resource Server, door één of meerdere ZA Nodes wordt ondersteund;
  • elke ZA Node hetzij één  Authorization Server  ondersteunt, hetzij één Resource Server , hetzij de combinatie van één Authorization Server en één Resource Server ondersteunt;
  • elke ZA Node één of meerdere endpoints kent en elk endpoint hoort bij één ZA Node, zodanig dat de hostname in een endpoint-adres de hostname van die ZA Node is;
  • elk endpoint hetzij een Authorization Endpoint, hetzij een Token Endpoint, hetzij een Resource Endpoint is.

Het vierde punt staat het toe om een Authorization Server en een Resource Server te verdelen over verschillende ZA Nodes, maar ook te combineren op dezelfde. Het derde punt staat het zelfs toe dat Authorization Server en Resource Server elk apart op meerdere ZA Nodes worden geprojecteerd. Het kan dan voorkomen dat, bij de betreffende ZorgaanbiederGegevensdiensten in de Zorgaanbiederslijst, hostnames in de endpointadressen staan die verschillen tussen het authorization endpoint, het token endpoint en het resource endpoint. Een belangrijke eis blijft evenwel dat al deze hostnames bij ZA Nodes van eenzelfde Dienstverlener Zorgaanbieder horen. De hele flow behorend bij een zekere ZorgaanbiederGegevensdienst moet namelijk onder de eindverantwoordelijkheid van één zo'n Dienstverlener vallen, namelijk van de Dienstverlener die die ZorgaanbiederGegevensdienst aanbiedt.  Zo blijft die integrale eindverantwoordelijk­heid ook op net­werk-niveau toetsbaar. Zie de drie (ingewikkelde) invarianten bij  Zorgaanbie­derGegevensdienst  van het soort “niet-lokale afhankelijkheid”. 


Hoezeer ook alle eindverantwoordelijkheden gedragen worden door de Dienstverleners die deelnemer zijn in het MedMij Afsprakenstelsel, zij kunnen ervoor kiezen de uitvoering van die verantwoordelijkheden deels of zelfs geheel uit te besteden.  In een mogelijke systeemarchitectuur maken meerdere  Resource Server -systemen  gebruik van een­zelf­de (al dan niet uitbesteed)  Authorization Server -systeem . Het is mogelijk dat die  Resource Server-systemen   samen onder de eindverantwoordelijkheid van één  Dienstverlener Zorgaanbieder  vallen, met de uitvoering al dan niet  uitbesteed . Het is ook mogelijk dat twee verschillende  Dienstverleners Zorgaanbie­der  voor de  Authorization Server  gebruik maken van eenzelfde onderaannemer. De host­names in de adressen van de  Authorization Endpoints / Token Endpoints  zullen dan evengoed ver­schillen tussen die twee eindverantwoordelijke  Dienstverleners Zorgaanbieders , zelfs al zou er het zelfde   Authorization Server -systeem   achter zitten. Voor de  Zorgaanbiedergegevensdiensten  waar­voor  Dienstverlener Zorgaanbieder  A verant­woordelijk is, moet dat de hostname van een  Node  van A zijn; voor de  Zorgaanbieder­Gege­vensdiensten  waarvoor  Dienstverlener Zorgaan­bieder  B verantwoordelijk is moet dat de hostname van een Node van B zijn.

De architectuur heeft zo maximale ruimte aan de eigen businessmodellen en architecturen van Dienstverleners Zorgaanbieder willen geven zonder daarbij de interoperabiliteit en strakke eindverantwoordelijkheden geweld aan te doen.

Bedoeling van de beschikbaarheids- en de ontvankelijkheidstoets

De bedoeling van de beschikbaarheids- en de ontvankelijkheidstoets — onmiddellijk na de gebruikersauthenticatie in UC(I) Verzamelen, respectievelijk UC(I) Delen — is tweeledig.

  1. De toetsen willen veilig stellen dat er zo snel mogelijk na de authenticatie van de persoon uitgegaan mag worden van het vervuld zijn van twee voorwaarden voor het ver­zamelen of delen van de betreffende informatie: het bestaan van een (eventueel voorbije) behan­del­relatie als grond­slag daarvoor en van een leeftijd van de persoon van minimaal zes­tien jaar. Het is de juri­dische eindverantwoordelijkheid van de zorgaanbieder deze voorwaar­den te (laten) verifiëren. Zie voor het aspect leeftijd verder het Juridisch kader.
  2. Het geeft de zorgaanbieder de kans naar eigen bevinden extra beperkingen, structu­reel of incidenteel, op te leggen aan het laten verzamelen of delen van informatie, bijvoorbeeld om technische redenen of vanwege bijzondere situaties, bijzondere patiënten of aangrij­pende inhoud.

Een succesvol resultaat van de toets betekent dus dat de zorgaanbieder ervoor instaat dat de behandelrelatie aanwezig is en dat de leeftijd voldoende is. Hoe de zorgaanbieder dat geborgd heeft is vrij, zolang het eindresultaat maar is dat de zorgaanbieder ervoor kan in­staan. Aan die borging kunnen bijvoorbeeld bijdragen:

  • juridische middelen, zoals bepalingen in de dienstverleningsovereenkomst tussen Zorg­aanbieder en Dienstverlener Zorgaanbieder;
  • organisatorische maatregelen in de wijze waarop  Zorgaanbieders  het dossier beheren, zodat aan de dossierinfo, aan de ordening ervan, of zelfs aan de loutere aanwezigheid er­van, gezien kan worden of er een behandelrela­tie aan ten grondslag ligt;
  • geautomatiseerde logica, die voor een zekere Persoon en een zekere Gegevensdienst de ontvankelijkheid/beschikbaarheid bij een zekere Zorgaanbieder bepaalt, voortbouwend op organisatorische maatregelen. 

Het MedMij Afsprakenstelsel verplicht er niet toe om leeftijdsgegevens en behandelrelatiegegevens expliciet te administreren. Waar het bestaan van een behandelrelatie of een toereikende leeftijd, op juridische en/of organisatorische gronden, geïmpliceerd wordt door andere gegevens, mogen laatstgenoemde gegevens ook met die implicatie gebruikt worden. Het MedMij Afsprakenstelsel speci­ficeert daarom geen logica voor de toetsen; het bepaalt slechts twee noodzakelijke onderdelen van hun post­conditie: een toereikende leeftijd van de  Persoon en het (hebben) bestaan van een toepasselijke behandelrelatie.

Een negatief resultaat van de toets zegt niets over de precieze reden. Daaruit kan zelfs niet worden geconcludeerd dat het­zij de behandelrelatie ontbreekt of de leeftijd ontoereikend is. De zorgaanbieder kan ook an­dere redenen gehad hebben te weigeren.


Er zijn twee hoofdredenen om de toets zo snel mogelijk uit te voeren, dat wil zeggen, onmid­dellijk na de authenticatie van de Persoon , nog voor de autorisatievraag (de vroege variant) en niet pas wan­neer de flow bij de  Resource Server  is aangekomen, mogelijk geïntegreerd met de uiteindelij­ke uit­vraag/plaatsing (de late variant). Die redenen zijn dataminimali­satie en gebrui­ksvriendelijkheid. Beide aspecten moeten vanuit het perspectief van de gehele use case en alle betrokken rollen beschouwd worden: de keuze  tussen de vroege en de late variant heeft effecten op meerdere plaatsen. De afweging onderscheidt vier situaties, afhankelijk van twee vragen:

  • Acht de Zorgaanbieder (zich voor) de informatie (uitein­delijk) beschikbaar/ontvankelijk?
  • Geeft de Persoon (uiteinde­lijk) toestemming?

De twee varianten laten zich als volgt vergelijken inzake dataminimalisatie.


(uiteindelijk) wel beschikbaar/ontvankelijk(uiteindelijk) niet beschikbaar/ontvankelijk
(uiteindelijk)
wel 
toestemming
  • Voor zover er aparte geautoma­ti­seerde mid­de­len worden ge­bruikt voor de toets vraagt de vroege variant ex­tra ver­keer ten opzichte van de late variant, namelijk tussen Autho­ri­zation Ser­ver en de com­ponent-(en) die zij voor het uitvoe­ren van die toets aan­spreekt. Dat ver­keer speelt zich wel geheel binnen de verantwoordelijkheid van een enkele verwerkingsverantwoordelijke af; er vindt geen verstrekking plaats.
  • De Authorization Server komt alleen in de vroege variant extra te weten dat behandel­relatie en leef­tijd in orde zijn. In de late variant komt alleen de Resource Server dat te weten. Dat laat onverlet dat beide onder dezelfde eindverantwoordelijke Dienstverlener Zorgaanbieder vallen.
  • In de late variant vindt, in tegenstelling tot in de vroege, al het verkeer na de au­thenti­catie (de toe­stem­mingsvraag, het uit­de­len van authoriza­tion code en ac­cess to­ken en het aan­spreken van de Resour­ce Ser­ver) onnodig plaats. Dit verkeer strekt zich uit over verantwoordelijkheidsgrenzen.
  • In toevoeging op het vorige punt vindt er in het geval van de UC(I) Delen een overbodige uitwisseling en verwerking van medische informatie plaats. De PGO Server zal immers medische informatie aanbieden aan de Resource Server voordat deze alsnog te weten komt dat de Zorgaanbieder zich er niet ontvankelijk voor acht.
  • In de late variant krijgt de PGO Server, onnodig, meer over de beschikbaarheid/ontvankelijkheid, en dus over de Persoon, te weten van de Resource Server dan in de vroege variant van de Authorization Server. In de vroege variant kan de betreffende uitzondering immers, vanuit de PGO Server bezien, ook door falende authenticatie of weigering van toestemming veroorzaakt zijn. In de late variant komt de PGO Server echter wel te weten, door het ontvangen van de onnodige authorization code, dat er sprake is van zowel een behandelrelatie als een toereikende leeftijd.
(uiteinde­lijk) geen toestemming

In de late variant vindt, in tegenstelling tot in de vroege, een overbodige toe­stemmingsvraag plaats. Dit verkeer vindt plaats over het relatief onveilige frontchannel.

De twee varianten laten zich als volgt vergelijken inzake gebruiksvriendelijkheid. 


(uiteindelijk) wel beschikbaar/ontvankelijk(uiteindelijk) niet beschikbaar/ontvankelijk
(uiteindelijk) wel toestemming

geen verschil

In de vroege variant is de persoon onmiddellijk op de hoogte, zodat deze:

  • geen onnodige en verwarrende handeling (holle toestemming) met rechtsgevolgen hoeft uit te voeren, zoals in de late variant;
  • preciezer dan in de late variant op de hoogte raakt van waarom een uitwisseling faalt. In de late variant kan dat falen andere redenen hebben, zodat de Persoon voor opheldering op ondersteuningsvragen aangewezen zou zijn, die wellicht zelfs aan de Zorgaanbieder gericht worden. In de vroege variant zijn Uitzonderingen 2, 3 en 4 in zowel UC(I) Verzamelen als UC(I) Delen weliswaar samengenomen in één melding naar de PGO Server, zodat deze het onderscheid tussen falende authenticatie, falende autorisatie en falende beschikbaarheid/ontvankelijkheid niet kan maken. De Persoon zelf echter kent vanwege zijn/haar voorafgaande rechtstreekse interactie met de Authorization Server het resultaat van de authenticatie en de autorisatie en kan dus alsnog uit deze gecombineerde melding, buiten medeweten van de PGO Server, afleiden of er sprake was van falende beschikbaarheid/toegankelijkheid.
(uiteindelijk) geen toestemming

In de vroege variant is de persoon onmiddellijk op de hoogte en hoeft deze geen onnodige en verwarrende handeling (holle afwijzing) uit te voeren, zoals in de late variant.

De gevallen waarin de Zorgaanbieder (zich voor) de informatie beschikbaar/ontvan­kelijk acht zijn, uitgaande van redelijk gedrag van de PGO Server, waarschijnlijk talrijker dan die waarin dat niet het geval is. Anderzijds wegen de nadelen van de vroege variant voor eerstgenoemde gevallen licht, omdat het zorgaanbiedersdomein en de Authorization Server om andere redenen al afdoende beveiligd moeten zijn, al is het maar vanwege het gebruik van het BSN. Bovendien is er alleen sprake van extra verkeer voor zo­ver geautomatiseerde logica wordt ingezet en daarvoor rollen anders dan de Authorization Server, en dus buiten het MedMij Afsprakenstelsel, worden aangesproken.

De nadelen van de late variant wegen naar verhouding zwaar, omdat het extra verkeer zich voor een belangrijk deel over verantwoordelijkheidsgrenzen uitstrekt en omdat de Persoon onno­dige han­delingen (holle toestemming) met rechtsgevolgen moet plegen.

Daarom kiest het MedMij Afsprakenstelsel voor de vroege variant. Het zal afhangen van de specifieke inrichtingskeuzes van  Dienstverlener(s) Zorgaanbieder  welke mix van juridi­sche middelen, organisa­torische maatregelen en geautomatiseerde logica een afdoende en effi­ciënte vervulling van de postconditie van de toetsen oplevert.

Eisen van DigiD inzake uitloggen

Het MedMij Afsprakenstelsel brengt het gebruik van DigiD onder in de OAuth-flow, onder verant­woordelijkheid van de Authorization Server. Dat is in zoverre bijzonder dat de te authenti­ce­ren Persoon uiteindelijk  niet de directe gebruiker is van de aanroeper van DigiD, zoals in veel gevallen van DigiD-gebruik, maar een indirecte gebruiker, namelijk door tussenkomst van de PGO Server. De directe interactie van de Persoon met de Authorization Server is bedoeld om de PGO Server daartoe te autoriseren. Deze indirectie kan vragen oproepen bij de interpretatie van enkele aansluiteisen van DigiD.

Ten eerste eist DigiD dat de eindgebruiker “gedurende de gebruikersessie” de ge­le­gen­heid houdt uit te loggen. Voor de UC(I) Verzamelen en UC(I) Delen strekt deze gebrui­kerssessie zich niet verder uit dan de Authorization Server. Daarna is immers de Persoon geen gebruiker meer van de Authorization Server, maar van de PGO Server, die op zijn beurt de gebruiker van de Resource Server is geworden, daartoe eerder door Persoon geautoriseerd. Tijdens de gebruikerssessie bij de Authorization Server is er boven­dien slechts één eindgebruikersinteractie, namelijk bij het voorleggen van de toestemmings­vraag. Het afwijzen van die toestemming door de Per­soon mag worden opgevat als uitlog­gen. Er zijn geen verdere uitlogvoorzieningen nodig.

Ten tweede stelt DigiD eisen aan de “DigiD-sessiegegevens” en de daarvan afgeleide gege­vens. Dat roept de vraag op om welke gegevens dat gaat en of de authorization code en het access token moeten wor­den opgevat als afgeleide gegevens. De reden voor deze eis is dat de bedoelde gegevens nodig zijn om weer uit te loggen, vooral in het geval van single sign-on. In de UC(I) Verzamelenen UC(I) Delen zijn deze gegevens echter niet nodig voor uitlog­gen. Überhaupt worden authoriza­tion code en access token niet als afgeleide gegevens opgevat.

Ten derde eist DigiD dat na de authenticatie wordt geredirect naar hetzelfde domein van waaruit DigiD is aangeroepen. Daaraan is eenvoudig voldaan in het MedMij Afsprakenstelsel, zij het dat deze DigiD-aanroep en -redirect zijn ingebed in een vergelijkbare Oauth-aanroep en -redirect. De situatie is dus genest: de PGO Server roept de Authorization Server aan, die DigiD aanroept, die redirect naar de  Authorization Server , die de OAuth-flow vervolgt, waarin onder meer een redirect naar de PGO Server plaatsvindt.

Whitelist -controle tijdens de TLS-handshake

In het MedMij Afsprakenstelsel wordt gewerkt met een Whitelist voor het autoriseren van servers voor deelname in MedMij-verkeer. In het geval van inkomend backchannel-verkeer vindt de controle tegen de Whitelist plaats gedurende de TLS-handshake. De implementatie daarvan kan enige complexiteit opleveren. Het MedMij Afsprakenstelsel kiest niettemin voor deze optie om de volgende redenen.

Allereerst is een reeks van alternatieven voor de Whitelist overwogen, vooral op basis van certificaten. Deze overwegingen zijn te vinden in het eerste toelichtingsblok op de Netwerk-pagina. Gegeven het gebruik van een  Whitelist  kan vervolgens, in het geval van inkomend back­chan­nel-verkeer, gedacht worden aan de volgende plaatsen om de controle tegen de Whitelist uit te voeren:

  • op TLS-niveau, voorafgaand aan de TLS-handshake;
  • op TLS-niveau, tijdens de TLS-handshake;
  • op TLS-niveau, na de TLS-handshake;
  • boven TLS-niveau, in een apart autorisatieprotocol.

De eerste optie kan niet, want de identiteit van de tegenpartij wordt pas tijdens de TLS-handshake bekend, uit het aangeboden certificaat. De derde optie is ongewenst omdat deze leidt tot het starten van onveilige TLS-sessies, waarin ongeautoriseerd verkeer kan plaatsvin­den. De andere twee opties kennen allebei een extra implementatie-complexi­teit. Die van de vierde optie is echter ruim groter dan van de tweede, omdat de vierde optie om een MedMij-eigen autorisatieprotocol zou vragen. De tweede optie is preferent.

G2- en G3-certificaten van PKIoverheid

Certificate Authorities in PKIoverheid geven certificaten uit onder twee verschillende rootcertificaten: een oude (G2) en een nieuwe (G3). De geldigheid van G2-certificaten zal uiterlijk eindigen op 22 maart 2020. Hoewel er dus geen G2-certificaten meer kunnen worden uitgegeven met een geldigheid van drie jaar, moet het vooralsnog mogelijk zijn oudere G2-certificaten te gebruiken voor MedMij-doeleinden. Waar PKIoverheid-certificaten moet worden geaccepteerd, moeten die dus G2- of G3-certificaten kunnen zijn. Het MedMij Afsprakenstelsel heeft geen redenen extra beperkingen op te leggen ten opzichte van hoe PKIoverheid de transitie van G2 naar G3 maakt.

  • No labels