De keuze, in OAuth, voor de grant type Authorization Code past bij de typische software-architectuur die in MedMij in het Persoonsdomein wordt aangetroffen: toegang tot een PGO-dienst via componenten die niet onder controle van de OAuth Client vallen en als betrekkelijk onveilig moeten worden gezien.

Het is toegestaan om een Authorization Server en een Resource Server te verdelen over verschillende Nodes, maar ook te combineren op dezelfde. De afsprakenset staat het zelfs toe dat Authorization Server en Resource Server elk apart op meerdere Nodes worden geprojecteerd. Het kan dan voorkomen dat, bij de betreffende AanbiederGegevensdiensten in de Aanbiederslijst, 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 Nodes van eenzelfde Dienstverlener aanbieder horen. De hele flow behorend bij een zekere AanbiederGegevensdienst moet namelijk onder de eindverantwoordelijkheid van één zo'n Dienstverlener vallen, namelijk van de Dienstverlener die die AanbiederGegevensdienst ontsluit. Zo blijft die integrale eindverantwoordelijk­heid ook op net­werk-niveau toetsbaar. Zie de drie (ingewikkelde) invarianten bij Aanbie­derGegevensdienst 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 DVP 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.

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

Deze verantwoordelijkheid introduceert ook de notie van een persoonlijk gezondheidsdossier. Voor het voldoen aan deze regel is het dus niet voldoende aan de Persoon alleen inkijk in gezondheidsinformatie te bieden. Hij/zij moet het ook kunnen opslaan en beheren. Omdat deze functie zich over verschillende functionele rollen uitstrekt, is om interoperabiliteitsredenen de specificatie van het stroomdiagram aangehaald.

Hiermee wordt geborgd dat bij de uitgewisselde zorg- en gezondheidsinformatie altijd duidelijk is bij welke bron (Dienstverlener aanbieder) en in welke context (Gegevensdienst) deze is verzameld. Een ontvanger van deze informatie kan deze meta-informatie gebruiken voor een betere interpretatie van de betreffende informatie. Mochten hieruit alsnog interpretatievragen komen, kan de ontvanger zich vervoegen bij betreffende bron.

Omdat deze functie zich niet over meerdere domeinen uitstrekt, is zij niet nader gespecificeerd in een stroomdiagram. Het is aan de vrijheid van de Deelnemer om deze naar behoefte van haar klanten in te richten. Maar zij mag niet ontbreken, omdat dan de Persoon geen Regie over het dossier zou kunnen voeren.

Hiermee is het voor de Persoon duidelijk op welk deel van de inhoud van zijn dossier hij de aan het MedMij Afsprakenstelsel verbonden vertrouwen kan verbinden. Het is immers goed mogelijk dat een PGO alleen op bepaalde onderdelen deelneemt, en dus voldoet, aan het MedMij Afsprakenstelsel.

Deze afspraak wijst MedMij Beheer de verantwoordelijkheid toe om ten behoeve van alle Dienstverleners persoon een lijst te verspreiden van Aanbieders en de door hen aangeboden Gegevensdiensten. Zonder deze functie zou het stelsel niet functioneren.

Door op deze manier de MedMij Stelselnode te autoriseren voor MedMij-verkeer wordt ervoor gezorgd dat ook in foutsituaties of bootstrap-situaties een Backchannel Node de MedMij Stelselnode kan aanspreken om een Whitelist 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 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.