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.

Conform het bepaalde onder core.rollen.300, mag een DVP Server meerdere Nodes gebruiken, maar mag de DVP Server maar één 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 DVP Server is erkend, zodat de Authorization Server een authorization request kan weigeren wanneer de DVP 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 DVP Server, in de OAuth Client List alleen die ene Node te worden opgenomen die deze DVP Server voor haar frontchannelverkeer gebruikt. Om geen overbodige gegevens te verspreiden, worden alle andere eventuele Nodes van de OAuth Client List geweerd.

Een Gegevensdienst is een op een specifieke en gestandaardiseerde set gezondheidsinformatie gerichte dienst waarmee Dienstverlener aanbieder zulke informatie ontsluit naar Dienstverlener persoon in het kader van de functie Verzamelen of Dienstverlener aanbieder zulke informatie geplaatst krijgt ten behoeve van een Aanbieder. In de Gegevensdienstnamenlijst zijn de Gegevensdiensten opgenomen die op enig moment worden aangeboden, maar de Catalogus is de autoriteit daarvoor.

Het ontsluiten van een Gegevensdienst door een Dienstverlener aanbieder is, in deze versie van het MedMij Afsprakenstelsel, hetzij in het kader van Verzamelen of in het kader van Delen van zekere gezondheidsinformatie. De term 'ontsluiten' wordt hier gebruikt in plaats van de term 'aanbieden', omdat als aanbieder van een Gegevensdienst de Aanbieder wordt gezien, niet de Deelnemer (Dienstverlener aanbieder). De Deelnemer ontsluit de Gegevensdienst dus namens de Aanbieder die die Gegevensdienst aanbiedt.

De termen 'aanbieden' en 'ontsluiten' vertegenwoordigen een tweedeling in de verantwoordelijkheid voor een geleverde Gegevensdienst. De Aanbieder is, ook als verwerkingsverantwoordelijke in de zin der AVG, verantwoordelijk voor het aanbieden van een Gegevensdienst aan de Dienstverlener persoon; de Dienstverlener aanbieder is, ook als verwerker in de zin der AVG, verantwoordelijk voor het ontsluiten van diezelfde Gegevensdienst aan diezelfde Dienstverlener persoon. Aanbieden en ontsluiten zijn dus niet achter elkaar geschakeld: de Aanbieder biedt de Gegevensdienst niet zozeer aan de Dienstverlener aanbieder aan, maar aan de Dienstverlener persoon. Aanbieden en ontsluiten zijn aspecten van eenzelfde geleverde Gegevensdienst: het eerste het verwerkingsverantwoordelijke, het tweede het verwerkende.

Zo wordt geborgd dat de juiste functie-implementaties en informatiestandaarden worden gebruikt. Ook wordt het correcte gebruik geborgd, wat bijdraagt aan interoperabiliteit en vertrouwen.

Conform wettelijke verplichting geeft Persoon, in de functie Verzamelen, actief toestemming aan de Aanbieder. In de functie Delen is deze verplichting niet aan de orde, maar vindt op dit moment evengoed een bevestiging door de Persoon plaats. De User Agent presenteert een venster waarin de Persoon deze toestemming, respectievelijk bevestiging, kan geven. Aangezien in het persoonsdomein niet met BSN gewerkt mag worden, moet er een vervangende identificatie van de Persoon gebruikt worden.

Met deze ene soort kunnen alle situaties die in het MedMij Afsprakenstelsel voorkomen worden bediend. Voor het maximaliseren van de interoperabiliteit kiest MedMij ervoor de andere drie soorten uit te sluiten.

De OAuth-standaard laat het (access) token type vrij. Token types verschillen in het vertrouwen waarmee de OAuth Resource Server aan de OAuth Client de gevraagde resources kan prijsgeven als laatstgenoemde het access-token aan eerstgenoemde overlegt. Bij de eenvoudigste vorm (bearer-token) geeft de OAuth Resource Server eenvoudigweg aan elke OAuth Client die een geldig access-token overlegt, de resources die daarbij horen. "Aan toonder", net zoals een bank een cheque kan verzilveren aan toonder. Daaraan kleven evenwel veiligheidsrisico's, omdat het access-token na uitgifte gestolen kan zijn, of anderszins vervreemd van de OAuth Client aan wie het uitgedeeld was. Andere token types kunnen daarom vragen om meer garanties, zoals een identiteit van de OAuth Client of een client-secret. Bearer-token is echter het enige goed gestandaardiseerde en breed gebruikte token type. Het legt wel veel verantwoordelijkheid voor beheersing van de veiligheidsrisico's bij OAuth Client en OAuth Authorization Server. In hoofdstuk 5 van de specificatie van de standaard RFC6750 is daarom expliciete aandacht voor die beveiligingsrisico's en maatregelen om die het hoofd te bieden.

Bij het genereren van codes en tokens is de OAuth-scope meegenomen. Deze is gerelateerd aan de Gegevensdienst. Hoewel het technisch mogelijk is om meerdere scopes mee te geven is de scope beperkt tot één Gegevensdienst per keer.

Dit is een maatregel tegen de beveiligingsrisico's 4.4.1.1 en 4.4.1.3 uit RFC 6819. Bovendien wordt de hele flow van de functie Verzamelen ononderbroken uitgevoerd. De 900 seconden moeten dan voldoende zijn voor de OAuth Client om het access-token aan de OAuth Authorization Server aan te bieden. Een refresh-token is dan niet nodig.

Dit is een maatregel tegen beveiligingsrisico 4.4.1.3 uit RFC 6819. Aan de in omloop gebrachte authorization-codes en access-tokens zijn twee belangrijke eisen te stellen: uniciteit en vertrouwelijkheid. De eis van vertrouwelijkheid weegt in het MedMij Afsprakenstelsel zwaar. Omdat de authorization-code (indirect) en het access-token (direct) toegang geven tot persoonlijke gezondheidsinformatie, kiest MedMij voor een formaat dat vrijwel betekenisloos is en alleen betekenis krijgt door confrontatie met lokale en goed beschermde administraties van de OAuth Authorization Server. De maximale raadkans wordt geëist in RFC6749, sectie 10.10. Er mag door vergelijking van meerdere authorization-codes of access-tokens niet doorschemeren hoe zij gegenereerd worden.

Wanneer een identifier is opgenomen in het access-token, kan dat gebruikt worden als identificatie van de OAuth Authorization Server-sessie waarin het token werd uitgegeven, zodat de OAuth Resource Server deze sessie kan hervatten wanneer zij het access-token aangeboden krijgt. Het is ook mogelijk dat een dergelijke identifier niet zozeer is opgenomen in de authorization-code, respectievelijk het access-token, maar geheel overeenkomt met de authorization-code, respectievelijk het access-token. Hoe dan ook, verantwoordelijkheid 6 blijft erop van kracht.

Wanneer een verloopmoment is opgenomen in het access-token, wordt het mogelijk om de OAuth Resource Server te laten afzien van onnodige raadpleging van de OAuth Authorization Server, wanneer deze apart geïmplementeerd zouden zijn. De tweede voorwaarde bij deze mogelijkheid voorkomt dat een eventuele corrumpering, in het Persoonsdomein, van de authorization-code of het access-token waarbij het verloopmoment verlaat zou worden, leidt tot onterechte toegang tot, of onterechte plaatsing van gezondheidsinformatie. Het accepteren van een authorization-code of een access-token gebeurt altijd in het licht van de interne administratie van de OAuth Authorization Server. Die corrumpering kan het verloopmoment ook vervroegen, maar richt dan weinig schade aan. Overigens kan in de deze versie van het MedMij Afsprakenstelsel, waarin de geldigheidsduur een vaste waarde heeft, de OAuth Client zelf ook al uitrekenen wanneer het geen zin meer heeft een authorization-code of access-token nog aan te bieden. De meerwaarde van het opnemen van een verloopmoment in de authorization-code of het access-token zal dus hooguit in mogelijke toekomstige versies kunnen blijken.

De service die het token heeft uitgegeven is al wel in deze versie van het MedMij Afsprakenstelsel een nuttig informatie-element. In situaties waarin een OAuth Resource Server samenwerkt met meerdere van hem gescheiden geïmplementeerde OAuth Authorization Server, moet deze bij een aangeboden access-token kunnen bepalen welke OAuth Authorization Server moet worden aangesproken. Dat aanspreken kan bijvoorbeeld door middel van Token Introspection volgens RFC7662. De geëigende bron voor die informatie is het access-token zelf, dat weet heeft van zijn afkomst. Die afkomstinformatie levert geen extra privacyrisico's op, omdat de OAuth Client sowieso op de hoogte is van wie hij het access-token heeft ontvangen.

Verder mag de OAuth Authorization Server ook een kopie van de scope opnemen in (de authorization-code of) het access-token, de scope die hij eerder in de authorization request heeft ontvangen van de OAuth Client (zie Authorization interface). Zo hoeft de OAuth Resource Server niet apart door de DVP Server van de scope op de hoogte gebracht te worden. De authorization-code of het access-token draagt zo weliswaar extra betekenis, maar de risico's daarvan wegen niet op tegen de risico's van het apart door de DVP Server laten sturen van de scope, die bijvoorbeeld zou kunnen afwijken van die waarvoor de authorization-code of het access-token is uitgegeven.

De lijst van toegestane informatie-elementen is limitatief. Geen andere informatie, ook niet versleuteld, mag in de authorization-code of het access-token zijn opgenomen. Daaronder vallen zeker ook:

• informatie over Persoon;
• informatie over Aanbieder of Gegevensdienst, al dan niet in relatie tot Persoon, buiten de scope;
• benoeming van, en beperkingen aan, de beoogde acceptanten van de authorization-code of het access-token. Op dit punt is namelijk de Aanbiederslijst de autoriteit: als de OAuth Client een access-token heeft opgehaald op een plek die daartoe in de Aanbiederslijst stond, dan moet hij dat access-token kunnen aanbieden aan de plek die daartoe in de Aanbiederslijst staat.

Het verbod op interpretatie door de OAuth Client van authorization-code en access-token zorgt ervoor dat er een minimale afhankelijkheid wordt gecreëerd tussen de dienstverleners in het Persoonsdomein enerzijds en die in het Aanbiedersdomein anderzijds, zodat P1 en P7 maximaal worden nageleefd en interne complexiteit en implementatiekeuzes in het Aanbiedersdomein niet doorschemeren in, of invloed uitoefenen op, de implementatie in het Persoonsdomein.

De beperkingen van betekenisdragendheid van de authorization-code en het access-token, zelfs indien versleuteld, bevorderen de privacy door middel van dataminimalisatie. Bovendien voorkomen zij nieuwe risico's op compromittering van die informatie-inhoud. Zulke compromittering zou moeilijk te ontdekken en te pareren zijn in het Aanbiedersdomein, ingeval men er daar toe besloten zou hebben van interne autorisatie-administratie af te zien omdat de informatie toch al meereist op de authorization code of het acces token, via de OAuth Client.

Om de privacy te kunnen borgen is het van belang dat de OAuth Authorization Server voldoende zekerheid heeft over de identiteit van de OAuth Client. Die zekerheid is afhankelijk van hoe goed de OAuth Client zijn credentials vertrouwelijk kan houden. Daartoe maakt de OAuth-specificatie onderscheid tussen twee client types: confidential en public. De eerste soort kan een voor de OAuth Authorization Server afdoende mate van vertrouwelijkheid van zijn credentials bieden, de tweede niet. Het is een hoofddoel van MedMij om zulk vertrouwen te borgen in een afsprakenstelsel en niet over te laten aan individuele spelers. Daarom verbindt het MedMij Afsprakenstelsel verantwoordelijkheden aan OAuth Clients ten behoeve van hun betrouwbaarheid jegens OAuth Authorization Server. We verwachten dat een groot deel van de implementaties van de OAuth Client (van de DVP Server dus) deze vertrouwelijkheid sowieso kunnen bieden, omdat ze de architectuur hebben van wat de OAuth-specificatie web application noemt. Andersoortige DVP Server-architecturen, zoals die van een app, zijn ook mogelijk, maar alleen onder de voorwaarde dat de OAuth Client al het credentials-verkeer in de achtergrond op een server afhandelt, niet via het user device.

De eis dat https in lowercase staat volgt de canonical form zoals gespecificeerd in sectie 3.1 van RFC 3986. De eisen aan de hostname zijn o.a. gebaseerd op RFC 952 en RFC 1123. Het laatste segment is het zogeheten top-level domain.

Dat geldt dus ook voor de redirect_uri.

In release 1.1.1 van het MedMij Afsprakenstelsel was deze verantwoordelijkheid alleen van toepassing op frontchannel-verkeer en had de Dienstverlener aanbieder voor back-channelverkeer de vrijheid om een ander poortnummer te kiezen dan dat conform de IANA-lijst bij https hoort (443). Dat zorgt echter voor een extra beveiligingsbeheerlast bij de DVP Server die rekening houden met meerdere bestemmingspoortnummers bij uitgaand verkeer. Die beheerst brengt indirect ook extra beveiligingsrisico's met zich mee. Daartegenover staat dat de in deze release aangebrachte aanscherping naar verwachting geen wezenlijke beperking voor Dienstverleners aanbieder zal zijn, omdat zij toch al gebruik maken van het voor https bedoelde poortnummer uit de IANA-lijst. Een mogelijke uitzondering vormt de situatie waarin de Authorization Server en/of Resource Server in een multi-tenant omgeving draaien.

Dit is een maatregel tegen beveiligingsrisico's 4.4.1.1, 4.4.1.3, 4.4.1.4 en 4.4.1.5 in RFC 6819. De PKI-certificaten worden in deze release van het MedMij Afsprakenstelsel gebruik voor twee doelen op de tehnologielaag: authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd.

Deze verantwoordelijkheid is opgenomen omdat met het bearer token informatie verkregen kan worden zonder dat nogmaals de identiteit wordt gecontroleerd. Daarom moeten maatregelen getroffen worden om te waarborgen dat het token alleen correct gebruikt kan worden.

Met de logging wordt beoogd een betrouwbaar overzicht te kunnen leveren van de gebeurtenissen waarbij gezondheidsgegevens over een Persoon zijn verwerkt.

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

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

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.