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.

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.

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

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

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).

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.

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

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.

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

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.

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

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 White­list uit te voeren is in dat geval gedurende de TLS-handshake, tussen de ontvangst van het certificaat van de TLS-client en de voorziene ver­zending van de Finished message. Indien die controle niet kan wor­den uitge­voerd, of een ne­ga­tief resultaat oplevert, wordt dan in plaats van de Finished message de uitzondering access_denied verzonden. Hoewel sectie 7.2.2 van de TLS-spe­cifi­catie voorziet in deze mogelijkheid, voorzien veel standaardimplementaties er niet in. In­grepen in die standaard­im­plementaties zijn soms wel mogelijk, maar kunnen nieuwe beveili­gingsrisico’s met zich meebren­gen, bijvoorbeeld vanwege de complexiteit van het beheren van maatwerk­aanpassingen aan stan­daardimplementa­ties.

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 geauto­riseerd was. Omdat er meerdere manieren zijn om dat ook na afloop van de TLS-hand­shake te imple­men­teren, vereist het MedMij Afspraken­stelsel hiervoor geen vaste architectuur­va­riant (zoals met een re­verse proxy), maar stelt het de vereiste van vol­gordelijkheid, naast een logische scheiding. Deze moe­ten kunnen worden aangetoond door middel van code-inspectie, penetratietesten en in­specties van logs.

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

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

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.