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

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.