Page Comparison

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.

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, namelijk op het authorization interface. 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.

Het ontsluiten van een Gegevensdienst door een Dienstverlener aanbieder is, in deze versie van het MedMij Afsprakenstelsel, hetzij in het kader van (MedMij Afsprakenstelsel 2.2.4) 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 Agentpresenteert, in opdracht van de Authorization server of Resource server, een scherm 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.

De scope van het access-token wijkt bij de functie Verzamelen af van de scope van de overige onderdelen. Dit staat verder uitgewerkt in core.tkint.201.

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 en refresh-tokens zijn twee belangrijke eisen te stellen: uniciteit en vertrouwelijkheid. De eis van vertrouwelijkheid weegt in het MedMij Afsprakenstelsel zwaar. Omdat de authorization-code en het refresh-token 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 core.autorisatie.206 blijft erop van kracht.

Wanneer een verloopmoment is opgenomen in het access-token of refresh-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, het access-token of hetrefreshtoken waarbij het verloopmoment verlaat zou worden, leidt tot onterechte toegang tot, of onterechte plaatsing van gezondheidsinformatie. Het accepteren van een authorization-code, een access-token of een refreshtoken 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, access-token of refresh-token nog aan te bieden. De meerwaarde van het opnemen van een verloopmoment in de authorization-code, het access-token  of het refreshtoken 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 en refresh-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, het access-token en het refresh-token dragen 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, het access-token of het refresh-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, access-token en refresh-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, het access-token en het refresh-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.

De controle van het in de TLS verbinding gebruikte certificaat is vooralsnog optioneel. De implementatie van deze controle wordt sterk aangeraden, zodat met een hogere mate van zekerheid de verzoekende partij kan worden vastgesteld.

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.

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 technologielaag: 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.