Inleiding

Op deze laag worden de infrastructurele rollen (Nodes) op het MedMij-netwerk bepaald en voorzien van verantwoordelijkheden op het gebied van versleuteling, authenticatie van Nodes en autorisatie van Nodes. Met dat laatste wordt bedoeld dat er steeds opnieuw moet worden vastgesteld dat een Node gerechtigd is zich te bewegen op het MedMij-netwerk. Voor versleuteling en authenticatie worden PKI-certificaten gebruikt.

Autorisatie zou op grofweg twee manieren in het MedMij Afsprakenstelsel kunnen worden opgenomen:

via diezelfde PKI-certificaten, waarin aan de domeinnaam van de houder van het certificaat gezien kan worden of het om een MedMij Node gaat, door daarvan te eisen dat die domeinnaam de vorm <dienstverlener>.medmij.nl heeft;
via een door MedMij-zelf beheerde lijst van geautoriseerde MedMij Nodes (een whitelist).

De voordelen van de eerste optie zouden zijn dat:

er zo maximaal gebruik wordt gemaakt van afspraken die ook voor andere doeleinden al nodig zijn, namelijk het gebruik van PKI-certificaten;
zo de mate van operationele centrale betrokkenheid van de Stichting MedMij wordt geminimaliseerd, en dus de kosten en risico's daarvan. In de tweede optie zou Stichting MedMij zelf een lijst moeten gaan beheren en ontsluiten naar alle servers om het operationele verkeer mogelijk te maken. In de eerste optie is alleen een name service nodig voor de medmij.nl-domeinnamen. Dat laatste is een goed gestandaardiseerde, goed begrepen en goed uit te besteden service, die lagere kosten, lagere risico's en minder afhankelijkheid voor de deelnemers met zich mee zal brengen;
MedMij zich zo maximaal houdt aan haar architectuurprincipe P6: MedMij spreekt alleen af wat nodig is.

Toch is voor de tweede optie gekozen, omdat de voor de eerste optie benodigde controle over de hostnames en de certificaten alleen met ongewenste bijeffecten gepaard zou gaan. De volgende opties zijn daarbij verkend:

De MedMij-beheerorganisatie wordt Registration Authority (RA) in PKIoverheid, jegens alle betrokken Certificate Authorities (CA's). PKIoverheid kent echter die mogelijkheid niet.
De MedMij-beheerorganisatie geeft een domeinverklaring af, zodat deelnemers zelf een subdomein onder .medmij.nl kunnen aanvragen bij een CA. Daarmee heeft de beheerorganisatie wel invloed op de uitgifte van een certificaat, maar laten intrekken is niet mogelijk, tenzij er sprake is van misbruik. Er is immers geen juridische relatie tussen de eigenaar van het domein (de beheerorganisatie) en de CA.
Analoog aan de wijze waarop door sommigen beroepsgebonden certificaten worden uitgegeven, is een maatwerk-certificeringsdienst denkbaar. In de voorwaarden van het product (geldend vanaf de aanvraag van het certificaat) wordt dan expliciet geregeld dat wanneer de inschrijving in een extern register wegvalt, het certificaat door de CA wordt ingetrokken. Dat vereist dat de registerhouder (beheerorganisatie) wijzigingen doorgeeft aan alle CA's. Dit is economisch pas interessant bij een aanzienlijke hoeveelheid certificaathouders, waarvan in MedMij voorlopig geen sprake zal zijn.
MedMij zou een eigen PKI-omgeving kunnen inrichten (afwijkend van PKIOverheid). Dit is niet verder verkend, vanwege de complexiteit en verantwoordelijkheid die op de schouders van de beheerorganisatie zou rusten.
De Stichting MedMij zou zelf houder kunnen zijn van alle certificaten, waarbij deelnemers gemandateerd worden voor beheerstaken rond hun eigen subset van certificaten. De Stichting kan certificaten intrekken. Identificatie van de dienstverlener naar de gebruiker is niet mogelijk, want de certificaten staan op naam van Stichting MedMij.
Er zou een custom field gebruikt kunnen worden in certificaten. De MedMij Beheerorganisatie zou de controle kunnen krijgen over de wijze waarop met dit veld wordt omgegaan. Dit vereist waarschijnlijk afspraken met alle CA's. Dit geeft controle op het uitgeven van certificaten, maar geeft de beheerorganisatie geen mogelijkheden het certificaat te laten intrekken.

Onderstaande tabel vat samen hoe in de verantwoordelijkheden op deze laag de beveiligingsfuncties beveiliging, authenticatie en autorisatie worden ingericht. Het onderscheid, bij autorisatie, tussen inkomend en uitgaand verkeer is het gevolg van dat in deze twee gevallen de identificatie van de andere Node anders plaatsvindt.

	frontchannel- verkeer	uitgaand backchannel-verkeer	inkomend backchannel-verkeer
versleuteling volgens TLS, met PKIoverheid-certificaat	altijd
identificatie op basis van ...	`redirect_uri` of Zorgaanbiederslijst		PKIoverheid- certificaat
authenticatie, op basis van PKIoverheid-certificaat, van ...	alleen de TLS-server	TLS-client én TLS-server
autorisatie op basis van controle tegen de Whitelist	niet	voorafgaand aan de TLS-handshake	zie verantwoordelijkheid 14a

Rollen

1. In het MedMij-netwerk functioneert:

elke PGO Server, met inbegrip van zijn OAuth-rol, op één of meerdere PGO Nodes. Voor al diens frontchannel-verkeer gebruikt elke PGO Server één PGO Node, en wel met een hostname die voor die PGO Server voorkomt op de OAuth Client List.
elke Authorization Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes;
elke Subscription Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes;
elke Notification Client op één of meer ZA Nodes;
elke Notification Server op één of meer PGO Nodes;
elke Resource Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes;
precies één MedMij Stelselnode, waarop MedMij Registratie functioneert.

Toelichting

Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.

De uitzondering daarop inzake het frontchannel-verkeer is noodzakelijk om de OAuth Client List te laten functioneren. Het is dus mogelijk voor een PGO Server om verschillende certificaten te hanteren voor frontchannel- en backchannel-verkeer, zolang op de OAuth Client List maar de hostname in het certificaat voor frontchannelverkeer voorkomt die tevens voorkomt in de redirect URI inzake OAuth.

Er is precies één MedMij Stelselnode in het MedMij-netwerk. Zonder die MedMij Stelselnode is er geen MedMij-netwerk.

In lijn met keuzes op de Proces- en Informatielaag, treden in het zorgaanbiedersdomein alleen de ZA Nodes op in het MedMij-netwerk. Dat wil zeggen dat bijvoorbeeld achterliggende xIS'en niet over het MedMij-netwerk communiceren met de ZA Node. Dat verkeer is verborgen achter de ZA Node. Alle daarvoor benodigde routering wordt afgehandeld door de server-implementaties en speelt zich buiten het zicht van het MedMij Afsprakenstelsel af.

2. Op één:

PGO Node functioneert hetzij één PGO Server, hetzij één Notification Server, hetzij de combinatie van één PGO Server en één Notification Server.
ZA Node functioneert hetzij één Authorization Server, hetzij één Resource Server, hetzij één Subscription Server, hetzij één Notification Client, hetzij een combinatie van voorgaande rollen.

Toelichting

Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.

3. Een of meerdere PKIoverheid TSP's treden op als PKIoverheid TSP.

Verantwoordelijkheden

TLS en certificaten

1a. Al het verkeer over het MedMij-netwerk is beveiligd met Transport Layer Security (TLS).

1b. Er wordt enkel gebruik gemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC.

Algoritmen

Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.

1c. Gebruik van TLS False Start is verboden.

Toelichting

Gebruik van TLS False Start is verboden om te voorkomen dat er inhoudelijke verwerking plaatsvindt van uitgewisselde gegevens voordat voor de betreffende uitwisseling authenticatie en autorisatie geslaagd zijn (zie onder).

2. Om zich te kunnen authenticeren en autoriseren op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKIoverheid-certificaat overleggen, en wel een server-certificaat van een PKIoverheid TSP.

3. Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKIoverheid-stelsel. Een organisatie mag meerdere certificaten hebben.

Toelichting

De keuze voor de PKI-standaard past bij principe P19 van het MedMij Afsprakenstelsel. Er bestaan andere manieren voor, en ideeën over, het borgen van vertrouwen in een netwerk van geautomatiseerde systemen, maar deze zijn nog lang niet zo bewezen als PKI, dat wereldwijd wordt ondersteund, en wereldwijd is beproefd, door overheden en marktspelers.

Bij gebruik van de PKI-standaard doet zich de vraag voor van welk(e) PKI-stelsel(s) gebruik gemaakt kan of moet worden. Zo'n PKI-stelsel voorziet in een hiërarchie van organisaties die certificaten uitgeven, zodanig dat de betrouwbaarheid van de certificaten van zo'n organisatie leunt op de betrouwbaarheid van de eerst-hogere organisatie in die hiërarchie, doordat de certificaten van de lagere-in-hiërarchie een handtekening hebben van die van de hogere-in-hiërarchie. Aan de top van zo'n hiërarchie staat een zogenoemde root Certificate Authority (root CA) die zijn betrouwbaarheid niet aan een hogere kan ontlenen, zijn eigen (stam)certificaten tekent, en zo een steunpilaar is van het vertrouwen in het hele betreffende PKI-stelsel.

Het MedMij Afsprakenstelsel had ervoor kunnen kiezen een PKI-stelsel specifiek voor MedMij in te richten, maar de kosten daarvan, voor zichzelf en voor haar deelnemers, wegen niet op tegen de voordelen, onder de voorwaarde dat er een ander geschikt PKI-stelsel voorhanden is. Deelnemers zullen met hun services immers ook in andere afsprakenstelsels betrokken kunnen zijn dan dat van MedMij. Zo'n keuze past bovendien niet bij principe P6.

Omdat het MedMij-netwerk een nationale en maatschappelijk kritische infrastructuur is, met hoge eisen aan betrouwbaarheid, kiest het MedMij Afsprakenstelsel voor het momenteel enige PKI-stelsel waarin de betrouwbaarheid uiteindelijk steunt op een Nederlandse publiekrechtelijke rechtspersoon: PKIoverheid met de Staat der Nederlanden als root CA. Zo is de governance van de root CA transparant en toegankelijk belegd.

Het MedMij Afsprakenstelsel bouwt voor het door hem aan zijn deelnemers geboden vertrouwen dus mede op het PKIoverheid-stelsel, op het door dat stelsel vastgestelde programma van eisen voor de in dat stelsel betrokken TSP's en op de certificatiehiërarchie van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past.

Functie Versleuteling

4. Op het MedMij-netwerk wordt al het verkeer versleuteld volgens TLS, zoals bedoeld in verantwoordelijkheid 1.

Functie Server Authentication

5. Tijdens de handshake van TLS, zoals bedoeld in verantwoordelijkheid 1, wordt door de TLS-server in de server hello-stap aan de TLS-client:

in geval van backchannel-verkeer, altijd een verzoek om een certificaat gedaan. Indien de TLS-client daarop geen certificaat overlegt, wordt de handshake onmiddellijk afgebroken.
in geval van frontchannel-verkeer, nooit een verzoek om een certificaat gedaan.

Toelichting

Bij backchannel-verkeer vindt dus twee-wegauthenticatie plaats, bij frontchannel-verkeer een-wegauthenticatie.

6a. ZA Node, PGO Node en MedMij Stelselnode valideren tijdens de TLS-handshake aan het begin van een TLS-sessie of het een PKIoverheid-certificaat is en controleren bij de Certification Authority of het ontvangen certificaat geldig is, op basis van CRL of OCSP. In geval van het falen van één van deze controles wordt het certificaat niet geaccepteerd en de TLS-sessie niet gestart.

6b. In geval van het gebruik van OCSP in het kader van verantwoordelijkheid 6a mag de OCSP response vastgeniet zitten aan het certificaat (OCSP Stapling).

Certificate revocation

Het laten vastnieten van een OCSP-antwoord aan het certificaat is toegestaan in het Afsprakenstelsel MedMij. De ontvanger mag dit OCSP-antwoord gebruiken maar kan de controle of het certificaat ingetrokken is ook op een andere manier uitvoeren. Wanneer ervoor gekozen is om de controle alleen via OCSP uit te voeren kan het voorkomen dat een OCSP responder geen of niet tijdig een antwoord geeft. In dat geval kan ervoor gekozen worden om de TLS sessie toch op te zetten (soft-fail). Het primaire mechanisme binnen het MedMij Afsprakenstelsel om te bepalen of nodes elkaar mogen benaderen is de Whitelist-controle.

Voor alle eisen gerelateerd aan PKIoverheid-certificaten, zie https://www.logius.nl/diensten/pkioverheid/aansluiten-als-tsp/pogramma-van-eisen.

6c. Met inachtneming van verantwoordelijkheid 6a, accepteren ZA Node, PGO Node en MedMij Stelselnode PKIoverheid certficaten van elkaar door:

alle root-certificaten te vertrouwen zoals gepubliceerd op https://cert.pkioverheid.nl/;
- waarvan de geldigheidsdatum niet is verlopen en die NIET zijn ingetrokken;
- met uitzondering van de onderstaande root certificaten (deze zijn NIET toegestaan):
  - de zogenaamde 'TEST' certificaten
  - Alle roots gemarkeerd met 'Persoon'
deelnemers moeten alle valide domein en TSP certificaten onder PKIo hiërarchie opnemen in de truststore; zie hiervoor https://cert.pkioverheid.nl/;
- met uitzondering van (deze roots moeten NIET opgenomen worden):
  - Organisatie Persoon
  - Burger
  - Autonome apparaten
  - Private Personen
- ook de zogenaamde intermediate-certificaten moeten worden opgenomen in de truststore

Toelichting

Voor alle frontchannel (internet-facing) verkeer moeten deelnemers een PKIoverheid-certificaat van het type 'publiek' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties:
- Stamcertificaat
  - Staat der Nederlanden EV Root CA
- Intermediair Domein Server CA 2020
  - QuoVadis PKIoverheid Server CA 2020
  - Digidentity PKIoverheid Server CA 2020
  - KPN PKIoverheid Server CA 2020
Voor alle backchannel verkeer (machine2machine) moeten deelnemers een PKIoverheid-certificaat van het type 'privaat' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties:
- Private Root CA (per medio 2020 de standaard voor m2m)
  - Stamcertificaat
    - Staat der Nederlanden Private Root CA - G1
  - Domein Private Services, maar alleen de volgende:
    - Staat der Nederlanden Private Services CA - G1
    - KPN PKIoverheid Private Services CA - G1
    - QuoVadis PKIoverheid Private Services CA - G1
    - Digidentity BV PKIoverheid Private Services CA - G1

Omdat het vastnieten van OCSP antwoorden (stapling) is toegestaan, zal iedere Node welke een certificaat moet controleren het vastnieten in zoverre moeten ondersteunen dat het alleen het feit dat er een vastgeniet OCSP antwoord gebruikt wordt niet mag leiden tot een foutmelding of het anderszins plots beëindigen van de TLS handshake of sessie.

6d. PKIoverheid certificaten moeten (in ieder geval op productie en acceptatie omgevingen) als complete keten inclusief alle intermediate certificaten worden verstuurd en gecontroleerd. Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie van het betreffende certificaat. Het root certificaat moet niet meegeleverd worden (dit is al aanwezig in de truststore van de tegenpartij).

Functie Server Authorization

Verspreiding van de Whitelist

7. De MedMij Stelselnode biedt aan PGO Node en ZA Node een use case-implementatie (UCI Opvragen WHL) om de actuele versie van de WHL-implementatie op te vragen. Betrokken rollen gebruiken hiervoor het betreffende stroomdiagram.

Toelichting

De WHL-implementatie is de implementatie van de Whitelist in XML.

8. Het aandeel van de MedMij Stelselnode in UCI Opvragen WHL is voor minstens 99,9% van de tijd beschikbaar. MedMij Registratie laat, na het niet beschikbaar raken van het aandeel van MedMij Stelselnode in de use case, maximaal acht uren (480 minuten) verstrijken voordat het weer beschikbaar is.

9. PGO Nodes en ZA Nodes betrekken minstens elke vijftien minuten (900 seconden) de meest recente WHL-implementatie van MedMij Stelselnode.

10. De MedMij Stelselnode heeft stelselnode.medmij.nl als hostname. De MedMij Stelselnode staat niet op de WHL-implementatie, maar wordt er voor de controle tegen de Whitelist-implementatie wel geacht op te staan.

Toelichting

Door op deze manier de MedMij Stelselnode te autoriseren voor MedMij-verkeer wordt ervoor gezorgd dat ook in foutsituaties of bootstrap-situaties een PGO Node of ZA Node de MedMij Stelselnode kan aanspreken om een WHL-implementatie op te halen.

11. PGO Nodes en ZA Nodes valideren elke nieuw verkregen Whitelist tegen het XML-schema van de Whitelist. Dit XML-schema is een technische implementatie van het MedMij-metamodel. Alle hostnames op de Whitelist zijn fully-qualified domain names, conform RFC3696, sectie 2

12. Ten behoeve van de technische beveiliging van het gegevensverkeer dat zich voltrekt in het kader van UCI Opvragen WHL maken betrokken rollen gebruik van Versleuteling, Server Authentication en Server Authorization, volgens het bepaalde op deze Netwerk-laag.

Gebruik van de Whitelist

13. ZA Node, PGO Node en MedMij Stelselnode laten, elk hunnerzijds, backchannel-verkeer over het MedMij-netwerk dan en alleen dan doorgang vinden, nadat zij hebben vastgesteld dat de hostname van de andere Node, waarmee verbinding gemaakt zou worden, op de meest actuele Whitelist voorkomt.

Toelichting

In geval van frontchannel-verkeer vindt er geen Server Authorization plaats.

14a. De Node die

de TLS-client zou worden voert de in verantwoordelijkheid 13 bedoelde controle tegen de Whitelist uit voorafgaand aan de start van de TLS-handshake. Indien die controle niet kan worden uitgevoerd of een negatief resultaat oplevert, wordt de TLS-handshake niet gestart.
de TLS-server is, voert de in verantwoordelijkheid 13 bedoelde controle tegen de Whitelist geheel uit voordat enige volgende stap wordt gezet door de OAuth Authorization Server of OAuth Resource Server, volgens de specificaties van UCI Verzamelen, UCI Delen, UCI Abonneren en UCI Notificeren. Deze vereiste wordt volgordelijkheid genoemd. Indien de controle tegen de Whitelist niet kan worden uitgevoerd, of een negatief resultaat oplevert, wordt de procesgang onmiddellijk afgebroken en komt het niet tot een start van de uitvoering van die eerstvolgende stap. De controle tegen de Whitelist slaagt in dit geval dan en slechts dan als op de Whitelist tenminste een van de volgende namen uit het de door de TLS-client aangeboden certificaat voorkomen: de Common Name of een van de eventuele Subject Alternative Names.

14b. Voor zover de Dienstverlener Zorgaanbieder ervoor kiest de controle tegen de Whitelist na afloop van de TLS-handshake uit te voeren, is deze controle logisch gescheiden van de bedoelde eerstvolgende stap. De vereiste volgordelijkheid kan worden aangetoond door middel van code-inspecties, penetratietesten en inspecties van logs.

Toelichting

In geval van uitgaand verkeer kan de voorziene TLS-client de controle tegen de Whitelist al uitvoeren voordat hij de TLS-handshake initieert, omdat hij de voorziene TLS-server al heeft geïdentificeerd, om te weten wie hij überhaupt moet aanspreken. In geval van inkomend verkeer echter, kan de TLS-server de zich aandienende TLS-client pas identificeren gedurende of na de TLS-handshake, aan de hand van het certificaat dat hij, conform verantwoordelijkheid 2, moet ontvangen. Daarop moet een hostname voorkomen die op de Whitelist is terug te vinden. Door toe te staan dat niet alleen de Common Name de voor MedMij geautoriseerde hostname mag bevatten, maar ook een Subject Alternative Name, biedt het MedMij Afsprakenstelsel aan deelnemers de mogelijkheid tot hergebruik van certificaten voor meerdere MedMij-nodes, of voor meerdere doelen dan alleen deelname in MedMij.

Het vroegste, en op het eerste gezicht dus meest veilige, moment om de controle tegen de Whitelist uit te voeren is in dat geval gedurende de TLS-handshake, tussen de ontvangst van het certificaat van de TLS-client en de voorziene verzending van de Finished message. Indien die controle niet kan worden uitgevoerd, of een negatief resultaat oplevert, wordt dan in plaats van de Finished message de uitzondering access_denied verzonden. Hoewel sectie 7.2.2 van de TLS-specificatie voorziet in deze mogelijkheid, voorzien veel standaardimplementaties er niet in. Ingrepen in die standaardimplementaties zijn soms wel mogelijk, maar kunnen nieuwe beveiligingsrisico’s met zich meebrengen, bijvoorbeeld vanwege de complexiteit van het beheren van maatwerkaanpassingen aan standaardimplementaties.

Daarom wil het MedMij Afsprakenstelsel meer implementatievrijheid bieden, zonder evenwel het risico te accepteren dat er inhoudelijke informatie gaat worden verwerkt die afkomstig is van een TLS-client, voordat de controle tegen de Whitelist heeft verzekerd dat die TLS-client tot MedMij-verkeer geautoriseerd was. Omdat er meerdere manieren zijn om dat ook na afloop van de TLS-handshake te implementeren, vereist het MedMij Afsprakenstelsel hiervoor geen vaste architectuurvariant (zoals met een reverse proxy), maar stelt het de vereiste van volgordelijkheid, naast een logische scheiding. Deze moeten kunnen worden aangetoond door middel van code-inspectie, penetratietesten en inspecties van logs.

15. Indien een Whitelist-controle, in het kader van verantwoordelijkheid 14, niet kan worden uitgevoerd, of een negatief resultaat oplevert, breekt dit de voortgang af van de uitvoering van de use case-implementatie en stellen de betrokken Applicatie-rollen elkaar hiervan niet op de hoogte.

Toelichting

Omdat het niet slagen van de Whitelist-controle duidt op een niet te vertrouwen tegenpartij, wordt deze daarvan niet op de hoogte gesteld.

Domain Name System

16. Dienstverleners persoon, Dienstverleners zorgaanbieder en MedMij Beheer zijn, in hun rol als DNS Server of cliënt daarvan, ervoor verantwoordelijk dat de name records behorende bij de hostnames van MedMij Nodes, respectievelijk de MedMij Stelselnode, zijn ondertekend volgens DNSSEC.

17. De MedMij Stelselnode en elke MedMij Node, in zijn rol als DNS resolver in het Domain Name System, controleert of de ontvangen name records zijn voorzien van ondertekening volgens DNSSEC en valideert deze volgens DNSSEC. Indien deze controle en validatie niet beide slagen, ziet hij af van verbinding met de betreffende hostname.

Toelichting

Het gebruik van DNSSEC (RFC 4033, RFC 4034, RFC 4035) vermindert de kwetsbaarheid van het Domain Name System voor bijvoorbeeld DNS spoofing.

Samenstelling OAuth Client List

18. De OAuth Client List bevat voor elke PGO Server alleen die PGO Node waarmee de betreffende PGO Server het frontchannelverkeer afhandelt.

Informatie

Conform het bepaalde onder punt 1 onder Rollen, mag een PGO Server meerdere PGO Nodes gebruiken, maar mag de PGO Server maar één PGO Node gebruiken voor al haar frontchannelverkeer, op het authorization interface dus. De inhoud van de OAuth Client List wordt alleen gebruikt op dat authorization interface, voor twee doelen:

het kennisnemen van de Gegevensdiensten waarop de PGO Server is erkend, zodat de Authorization Server een authorization request kan weigeren wanneer de PGO Server niet is erkend op de Gegevensdienst waarvoor hij autorisatie vraagt;
het kennisnemen van de naam van de Dienstverlener persoon die moet verschijnen in de Toestemmingsverklaring en de Bevestigingsverklaring.

Daarom hoeft, voor een PGO Server, in de OAuth Client List alleen die ene PGO Node te worden opgenomen die deze PGO Server voor haar frontchannelverkeer gebruikt. Om geen overbodige gegevens te verspreiden, worden alle andere eventuele PGO Nodes van de OAuth Client List geweerd.

Overzicht van de architectuur

Toelichting

Autorisatie zou op grofweg twee manieren in het MedMij Afsprakenstelsel kunnen worden opgenomen:

via diezelfde PKI-certificaten, waarin aan de domeinnaam van de houder van het certificaat gezien kan worden of het om een MedMij Node gaat, door daarvan te eisen dat die domeinnaam de vorm <dienstverlener>.medmij.nl heeft;
via een door MedMij-zelf beheerde lijst van geautoriseerde MedMij Nodes (een whitelist).

De voordelen van de eerste optie zouden zijn dat:

er zo maximaal gebruik wordt gemaakt van afspraken die ook voor andere doeleinden al nodig zijn, namelijk het gebruik van PKI-certificaten;
zo de mate van operationele centrale betrokkenheid van de Stichting MedMij wordt geminimaliseerd, en dus de kosten en risico's daarvan. In de tweede optie zou Stichting MedMij zelf een lijst moeten gaan beheren en ontsluiten naar alle servers om het operationele verkeer mogelijk te maken. In de eerste optie is alleen een name service nodig voor de medmij.nl-domeinnamen. Dat laatste is een goed gestandaardiseerde, goed begrepen en goed uit te besteden service, die lagere kosten, lagere risico's en minder afhankelijkheid voor de deelnemers met zich mee zal brengen;
MedMij zich zo maximaal houdt aan haar architectuurprincipe P6: MedMij spreekt alleen af wat nodig is.

De MedMij-beheerorganisatie wordt Registration Authority (RA) in PKIoverheid, jegens alle betrokken Certificate Authorities (CA's). PKIoverheid kent echter die mogelijkheid niet.
De MedMij-beheerorganisatie geeft een domeinverklaring af, zodat deelnemers zelf een subdomein onder .medmij.nl kunnen aanvragen bij een CA. Daarmee heeft de beheerorganisatie wel invloed op de uitgifte van een certificaat, maar laten intrekken is niet mogelijk, tenzij er sprake is van misbruik. Er is immers geen juridische relatie tussen de eigenaar van het domein (de beheerorganisatie) en de CA.
Analoog aan de wijze waarop door sommigen beroepsgebonden certificaten worden uitgegeven, is een maatwerk-certificeringsdienst denkbaar. In de voorwaarden van het product (geldend vanaf de aanvraag van het certificaat) wordt dan expliciet geregeld dat wanneer de inschrijving in een extern register wegvalt, het certificaat door de CA wordt ingetrokken. Dat vereist dat de registerhouder (beheerorganisatie) wijzigingen doorgeeft aan alle CA's. Dit is economisch pas interessant bij een aanzienlijke hoeveelheid certificaathouders, waarvan in MedMij voorlopig geen sprake zal zijn.
MedMij zou een eigen PKI-omgeving kunnen inrichten (afwijkend van PKIOverheid). Dit is niet verder verkend, vanwege de complexiteit en verantwoordelijkheid die op de schouders van de beheerorganisatie zou rusten.
De Stichting MedMij zou zelf houder kunnen zijn van alle certificaten, waarbij deelnemers gemandateerd worden voor beheerstaken rond hun eigen subset van certificaten. De Stichting kan certificaten intrekken. Identificatie van de dienstverlener naar de gebruiker is niet mogelijk, want de certificaten staan op naam van Stichting MedMij.
Er zou een custom field gebruikt kunnen worden in certificaten. De MedMij Beheerorganisatie zou de controle kunnen krijgen over de wijze waarop met dit veld wordt omgegaan. Dit vereist waarschijnlijk afspraken met alle CA's. Dit geeft controle op het uitgeven van certificaten, maar geeft de beheerorganisatie geen mogelijkheden het certificaat te laten intrekken.

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 één 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.

Rollen

1.	In het MedMij-netwerk functioneert: elke PGO Server, met inbegrip van zijn OAuth-rol, op één of meerdere PGO Nodes. Voor al diens frontchannel-verkeer gebruikt elke PGO Server één PGO Node, en wel met een hostname die voor die PGO Server voorkomt op de OAuth Client List. elke Authorization Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes; elke Subscription Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes; elke Notification Client op één of meer ZA Nodes; elke Notification Server op één of meer PGO Nodes; elke Resource Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes; precies één MedMij Stelselnode, waarop MedMij Registratie functioneert. Toelichting Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties. Het is toegestaan om een Authorization Server en een Resource Server te verdelen over verschillende ZA Nodes, maar ook te combineren op dezelfde. De afsprakenset 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, zelfs bij eenzelfde Interfaceversie. 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 ontsluit. Zo blijft die integrale eindverantwoordelijkheid ook op netwerk-niveau toetsbaar. Zie de drie (ingewikkelde) invarianten bij ZorgaanbiederGegevensdienst van het soort “niet-lokale afhankelijkheid”. De uitzondering daarop inzake het frontchannel-verkeer is noodzakelijk om de OAuth Client List te laten functioneren. Het is dus mogelijk voor een PGO Server om verschillende certificaten te hanteren voor frontchannel- en backchannel-verkeer, zolang op de OAuth Client List maar de hostname in het certificaat voor frontchannelverkeer voorkomt die tevens voorkomt in de redirect URI inzake OAuth. Er is precies één MedMij Stelselnode in het MedMij-netwerk. Zonder die MedMij Stelselnode is er geen MedMij-netwerk. In lijn met keuzes op de Proces- en Informatielaag, treden in het zorgaanbiedersdomein alleen de ZA Nodes op in het MedMij-netwerk. Dat wil zeggen dat bijvoorbeeld achterliggende xIS'en niet over het MedMij-netwerk communiceren met de ZA Node. Dat verkeer is verborgen achter de ZA Node. Alle daarvoor benodigde routering wordt afgehandeld door de server-implementaties en speelt zich buiten het zicht van het MedMij Afsprakenstelsel af.
2.	Op één: PGO Node functioneert hetzij één PGO Server, hetzij één Notification Server, hetzij de combinatie van één PGO Server en één Notification Server. ZA Node functioneert hetzij één Authorization Server, hetzij één Resource Server, hetzij één Subscription Server, hetzij één Notification Client, hetzij een combinatie van voorgaande rollen. Toelichting Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.
3.	Een of meerdere PKIoverheid TSP's treden op als PKIoverheid TSP.

Verantwoordelijkheden

	frontchannel- verkeer	uitgaand backchannel-verkeer	inkomend backchannel-verkeer
versleuteling volgens TLS, met PKIoverheid-certificaat	altijd
identificatie op basis van ...	`redirect_uri` of Zorgaanbiederslijst		PKIoverheid- certificaat
authenticatie, op basis van PKIoverheid-certificaat, van ...	alleen de TLS-server	TLS-client én TLS-server
autorisatie op basis van controle tegen de Whitelist	niet	voorafgaand aan de TLS-handshake	zie verantwoordelijkheid 14a

TLS en certificaten

1a.	Al het verkeer over het MedMij-netwerk is beveiligd met Transport Layer Security (TLS).
1b.	Er wordt enkel gebruik gemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.
1c.	Gebruik van TLS False Start is verboden. Toelichting Gebruik van TLS False Start is verboden om te voorkomen dat er inhoudelijke verwerking plaatsvindt van uitgewisselde gegevens voordat voor de betreffende uitwisseling authenticatie en autorisatie geslaagd zijn (zie onder).
2.	Om zich te kunnen authenticeren en autoriseren op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKIoverheid-certificaat overleggen, en wel een server-certificaat van een PKIoverheid TSP.
3.	Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKIoverheid-stelsel. Een organisatie mag meerdere certificaten hebben. Toelichting De keuze voor de PKI-standaard past bij principe P19 van het MedMij Afsprakenstelsel. Er bestaan andere manieren voor, en ideeën over, het borgen van vertrouwen in een netwerk van geautomatiseerde systemen, maar deze zijn nog lang niet zo bewezen als PKI, dat wereldwijd wordt ondersteund, en wereldwijd is beproefd, door overheden en marktspelers. Bij gebruik van de PKI-standaard doet zich de vraag voor van welk(e) PKI-stelsel(s) gebruik gemaakt kan of moet worden. Zo'n PKI-stelsel voorziet in een hiërarchie van organisaties die certificaten uitgeven, zodanig dat de betrouwbaarheid van de certificaten van zo'n organisatie leunt op de betrouwbaarheid van de eerst-hogere organisatie in die hiërarchie, doordat de certificaten van de lagere-in-hiërarchie een handtekening hebben van die van de hogere-in-hiërarchie. Aan de top van zo'n hiërarchie staat een zogenoemde root Certificate Authority (root CA) die zijn betrouwbaarheid niet aan een hogere kan ontlenen, zijn eigen (stam)certificaten tekent, en zo een steunpilaar is van het vertrouwen in het hele betreffende PKI-stelsel. Het MedMij Afsprakenstelsel had ervoor kunnen kiezen een PKI-stelsel specifiek voor MedMij in te richten, maar de kosten daarvan, voor zichzelf en voor haar deelnemers, wegen niet op tegen de voordelen, onder de voorwaarde dat er een ander geschikt PKI-stelsel voorhanden is. Deelnemers zullen met hun services immers ook in andere afsprakenstelsels betrokken kunnen zijn dan dat van MedMij. Zo'n keuze past bovendien niet bij principe P6. Omdat het MedMij-netwerk een nationale en maatschappelijk kritische infrastructuur is, met hoge eisen aan betrouwbaarheid, kiest het MedMij Afsprakenstelsel voor het momenteel enige PKI-stelsel waarin de betrouwbaarheid uiteindelijk steunt op een Nederlandse publiekrechtelijke rechtspersoon: PKIoverheid met de Staat der Nederlanden als root CA. Zo is de governance van de root CA transparant en toegankelijk belegd. Het MedMij Afsprakenstelsel bouwt voor het door hem aan zijn deelnemers geboden vertrouwen dus mede op het PKIoverheid-stelsel, op het door dat stelsel vastgestelde programma van eisen voor de in dat stelsel betrokken TSP's en op de certificatiehiërarchie van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past.

Functie Versleuteling

4.	Op het MedMij-netwerk wordt al het verkeer versleuteld volgens TLS, zoals bedoeld in verantwoordelijkheid 1.

Functie Server Authentication

5.	Tijdens de handshake van TLS, zoals bedoeld in verantwoordelijkheid 1, wordt door de TLS-server in de `server hello`-stap aan de TLS-client: in geval van backchannel-verkeer, altijd een verzoek om een certificaat gedaan. Indien de TLS-client daarop geen certificaat overlegt, wordt de handshake onmiddellijk afgebroken. in geval van frontchannel-verkeer, nooit een verzoek om een certificaat gedaan. Bij backchannel-verkeer vindt dus twee-wegauthenticatie plaats, bij frontchannel-verkeer een-wegauthenticatie.
6a.	ZA Node, PGO Node en MedMij Stelselnode valideren tijdens de TLS-handshake aan het begin van een TLS-sessie of het een PKIoverheid-certificaat is en controleren bij de Certification Authority of het ontvangen certificaat geldig is, op basis van CRL of OCSP. In geval van het falen van één van deze controles wordt het certificaat niet geaccepteerd en de TLS-sessie niet gestart.
6b.	In geval van het gebruik van OCSP in het kader van verantwoordelijkheid 6a mag de OCSP response vastgeniet zitten aan het certificaat (OCSP Stapling). Omdat het vastnieten van OCSP antwoorden (stapling) is toegestaan, zal iedere Node welke een certificaat moet controleren het vastnieten in zoverre moeten ondersteunen dat het alleen het feit dat er een vastgeniet OCSP antwoord gebruikt wordt niet mag leiden tot een foutmelding of het anderszins plots beëindigen van de TLS handshake of sessie. Toelichting Het laten vastnieten van een OCSP-antwoord aan het certificaat is toegestaan in het Afsprakenstelsel MedMij. De ontvanger mag dit OCSP-antwoord gebruiken maar kan de controle of het certificaat ingetrokken is ook op een andere manier uitvoeren. Wanneer ervoor gekozen is om de controle alleen via OCSP uit te voeren kan het voorkomen dat een OCSP responder geen of niet tijdig een antwoord geeft. In dat geval kan ervoor gekozen worden om de TLS sessie toch op te zetten (soft-fail). Het primaire mechanisme binnen het MedMij Afsprakenstelsel om te bepalen of nodes elkaar mogen benaderen is de Whitelist-controle. Voor alle eisen gerelateerd aan PKIoverheid-certificaten, zie https://www.logius.nl/diensten/pkioverheid/aansluiten-als-tsp/pogramma-van-eisen.
6c.	Met inachtneming van verantwoordelijkheid 6a, accepteren ZA Node, PGO Node en MedMij Stelselnode PKIoverheid certficaten van elkaar door: alle root-certificaten te vertrouwen zoals gepubliceerd op https://cert.pkioverheid.nl/; waarvan de geldigheidsdatum niet is verlopen en die NIET zijn ingetrokken; met uitzondering van de onderstaande root certificaten (deze zijn NIET toegestaan): de zogenaamde 'TEST' certificaten Alle roots gemarkeerd met 'Persoon' deelnemers moeten alle valide domein en TSP certificaten onder PKIo hiërarchie opnemen in de truststore; zie hiervoor https://cert.pkioverheid.nl/; met uitzondering van (deze roots moeten NIET opgenomen worden): Organisatie Persoon Burger Autonome apparaten Private Personen ook de zogenaamde intermediate-certificaten moeten worden opgenomen in de truststore.
6d.	Voor alle frontchannel (internet-facing) verkeer moeten deelnemers een PKIoverheid-certificaat van het type 'publiek' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties: Stamcertificaat Staat der Nederlanden EV Root CA Intermediair Domein Server CA 2020 QuoVadis PKIoverheid Server CA 2020 Digidentity PKIoverheid Server CA 2020 KPN PKIoverheid Server CA 2020 Voor alle backchannel verkeer (machine2machine) moeten deelnemers een PKIoverheid-certificaat van het type 'privaat' toepassen, uitgegeven door de volgende keten en/of opvolgende generaties: Private Root CA (per medio 2020 de standaard voor m2m) Stamcertificaat Staat der Nederlanden Private Root CA - G1 Domein Private Services, maar alleen de volgende: Staat der Nederlanden Private Services CA - G1 KPN PKIoverheid Private Services CA - G1 QuoVadis PKIoverheid Private Services CA - G1 Digidentity BV PKIoverheid Private Services CA - G1
6e.	PKIoverheid certificaten moeten (in ieder geval op productie en acceptatie omgevingen) als complete keten inclusief alle intermediate certificaten worden verstuurd en gecontroleerd. Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie van het betreffende certificaat. Het root certificaat moet niet meegeleverd worden (dit is al aanwezig in de truststore van de tegenpartij).

Functie Server Authorization

Verspreiding van de Whitelist

7.	De MedMij Stelselnode biedt aan PGO Node en ZA Node een use case-implementatie (UCI Opvragen WHL) om de actuele versie van de WHL-implementatie op te vragen. Betrokken rollen gebruiken hiervoor het betreffende stroomdiagram. Toelichting De WHL-implementatie is de implementatie van de Whitelist in XML.
8.	Het aandeel van de MedMij Stelselnode in UCI Opvragen WHL is voor minstens 99,9% van de tijd beschikbaar. MedMij Registratie laat, na het niet beschikbaar raken van het aandeel van MedMij Stelselnode in de use case, maximaal acht uren (480 minuten) verstrijken voordat het weer beschikbaar is.
9.	PGO Nodes en ZA Nodes betrekken minstens elke vijftien minuten (900 seconden) de meest recente WHL-implementatie van MedMij Stelselnode.
10.	De MedMij Stelselnode heeft `stelselnode.medmij.nl` als hostname. De MedMij Stelselnode staat niet op de WHL-implementatie, maar wordt er voor de controle tegen de Whitelist-implementatie wel geacht op te staan. Toelichting Door op deze manier de MedMij Stelselnode te autoriseren voor MedMij-verkeer wordt ervoor gezorgd dat ook in foutsituaties of bootstrap-situaties een PGO Node of ZA Node de MedMij Stelselnode kan aanspreken om een WHL-implementatie op te halen.
11.	PGO Nodes en ZA Nodes valideren elke nieuw verkregen Whitelist tegen het XML-schema van de Whitelist. Dit XML-schema is een technische implementatie van het MedMij-metamodel. Alle hostnames op de Whitelist zijn fully-qualified domain names, conform RFC3696, sectie 2
12.	Ten behoeve van de technische beveiliging van het gegevensverkeer dat zich voltrekt in het kader van UCI Opvragen WHL maken betrokken rollen gebruik van Versleuteling, Server Authentication en Server Authorization, volgens het bepaalde op deze Netwerk-laag.

Gebruik van de Whitelist

13.	ZA Node, PGO Node en MedMij Stelselnode laten, elk hunnerzijds, backchannel-verkeer over het MedMij-netwerk dan en alleen dan doorgang vinden, nadat zij hebben vastgesteld dat de hostname van de andere Node, waarmee verbinding gemaakt zou worden, op de meest actuele Whitelist voorkomt. Toelichting In geval van frontchannel-verkeer vindt er geen Server Authorization plaats.
14a.	De Node die de TLS-client zou worden voert de in verantwoordelijkheid 13 bedoelde controle tegen de Whitelist uit voorafgaand aan de start van de TLS-handshake. Indien die controle niet kan worden uitgevoerd of een negatief resultaat oplevert, wordt de TLS-handshake niet gestart. de TLS-server is, voert de in verantwoordelijkheid 13 bedoelde controle tegen de Whitelist geheel uit voordat enige volgende stap wordt gezet door de OAuth Authorization Server of OAuth Resource Server, volgens de specificaties van UCI Verzamelen, UCI Delen, UCI Abonneren en UCI Notificeren. Deze vereiste wordt volgordelijkheid genoemd. Indien de controle tegen de Whitelist niet kan worden uitgevoerd, of een negatief resultaat oplevert, wordt de procesgang onmiddellijk afgebroken en komt het niet tot een start van de uitvoering van die eerstvolgende stap. De controle tegen de Whitelist slaagt in dit geval dan en slechts dan als op de Whitelist tenminste een van de volgende namen uit het de door de TLS-client aangeboden certificaat voorkomen: de `Common Name` of een van de eventuele `Subject Alternative Names`.
14b.	Voor zover de Dienstverlener Zorgaanbieder ervoor kiest de controle tegen de Whitelist na afloop van de TLS-handshake uit te voeren, is deze controle logisch gescheiden van de bedoelde eerstvolgende stap. De vereiste volgordelijkheid kan worden aangetoond door middel van code-inspecties, penetratietesten en inspecties van logs. Toelichting In geval van uitgaand verkeer kan de voorziene TLS-client de controle tegen de Whitelist al uitvoeren voordat hij de TLS-handshake initieert, omdat hij de voorziene TLS-server al heeft geïdentificeerd, om te weten wie hij überhaupt moet aanspreken. In geval van inkomend verkeer echter, kan de TLS-server de zich aandienende TLS-client pas identificeren gedurende of na de TLS-handshake, aan de hand van het certificaat dat hij, conform verantwoordelijkheid 2, moet ontvangen. Daarop moet een hostname voorkomen die op de Whitelist is terug te vinden. Door toe te staan dat niet alleen de `Common Name` de voor MedMij geautoriseerde hostname mag bevatten, maar ook een `Subject Alternative Name`, biedt het MedMij Afsprakenstelsel aan deelnemers de mogelijkheid tot hergebruik van certificaten voor meerdere MedMij-nodes, of voor meerdere doelen dan alleen deelname in MedMij. Het vroegste, en op het eerste gezicht dus meest veilige, moment om de controle tegen de Whitelist uit te voeren is in dat geval gedurende de TLS-handshake, tussen de ontvangst van het certificaat van de TLS-client en de voorziene verzending van de `Finished` message. Indien die controle niet kan worden uitgevoerd, of een negatief resultaat oplevert, wordt dan in plaats van de `Finished message` de uitzondering `access_denied` verzonden. Hoewel sectie 7.2.2 van de TLS-specificatie voorziet in deze mogelijkheid, voorzien veel standaardimplementaties er niet in. Ingrepen in die standaardimplementaties zijn soms wel mogelijk, maar kunnen nieuwe beveiligingsrisico’s met zich meebrengen, bijvoorbeeld vanwege de complexiteit van het beheren van maatwerkaanpassingen aan standaardimplementaties. Daarom wil het MedMij Afsprakenstelsel implementatievrijheid bieden, zonder evenwel het risico te accepteren dat er inhoudelijke informatie gaat worden verwerkt die afkomstig is van een TLS-client, voordat de controle tegen de Whitelist heeft verzekerd dat die TLS-client tot MedMij-verkeer geautoriseerd was. Omdat er meerdere manieren zijn om dat ook na afloop van de TLS-handshake te implementeren, vereist het MedMij Afsprakenstelsel hiervoor geen vaste architectuurvariant (zoals met een reverse proxy), maar stelt het de vereiste van volgordelijkheid, naast een logische scheiding. Deze moeten kunnen worden aangetoond door middel van code-inspectie, penetratietesten en inspecties van logs.
15.	Indien een Whitelist-controle, in het kader van verantwoordelijkheid 14, niet kan worden uitgevoerd, of een negatief resultaat oplevert, breekt dit de voortgang af van de uitvoering van de use case-implementatie en stellen de betrokken Applicatie-rollen elkaar hiervan niet op de hoogte. Toelichting Omdat het niet slagen van de Whitelist-controle duidt op een niet te vertrouwen tegenpartij, wordt deze daarvan niet op de hoogte gesteld.

Domain Name System

16.

Dienstverleners persoon, Dienstverleners zorgaanbieder en MedMij Beheer zijn, in hun rol als DNS Server of cliënt daarvan, ervoor verantwoordelijk dat de name records behorende bij de hostnames van MedMij Nodes, respectievelijk de MedMij Stelselnode, zijn ondertekend volgens DNSSEC.

17.

De MedMij Stelselnode en elke MedMij Node, in zijn rol als DNS resolver in het Domain Name System, controleert of de ontvangen name records zijn voorzien van ondertekening volgens DNSSEC en valideert deze volgens DNSSEC. Indien deze controle en validatie niet beide slagen, ziet hij af van verbinding met de betreffende hostname.

Toelichting

Het gebruik van DNSSEC (RFC 4033, RFC 4034, RFC 4035) vermindert de kwetsbaarheid van het Domain Name System voor bijvoorbeeld DNS spoofing.

Samenstelling OAuth Client List

18.

De OAuth Client List bevat voor elke PGO Server alleen die PGO Node waarmee de betreffende PGO Server het frontchannelverkeer afhandelt.

Toelichting

het kennisnemen van de Gegevensdiensten waarop de PGO Server is erkend, zodat de Authorization Server een authorization request kan weigeren wanneer de PGO Server niet is erkend op de Gegevensdienst waarvoor hij autorisatie vraagt;
het kennisnemen van de naam van de Dienstverlener persoon die moet verschijnen in de Toestemmingsverklaring en de Bevestigingsverklaring.

Browser not supported