Voor een overzicht over alle lagen van de architectuur, en voor een toelichting van de betekenis van de symbolen en lijntjes, zie de overzichtspagina.

De afkorting:

• BV staat voor Bevestigingsverklaring;
• GNL staat voor Gegevensdienstnamenlijst;
• OCL staat voor OAuth Client List;
• TV staat voor Toestemmingsverklaring;
• TVA staat voor Toestemmingsverklaring Abonneren;
• ZAL staat voor Zorgaanbiederslijst.

Hier worden de rollen van de Processen-en-Informatie-laag vertaald naar rollen op applicatieniveau. Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.

In het persoonsdomein zijn drie rollen onderscheiden: de PGO Presenter, PGO User Agent en de PGO Server. Dat is nodig om de verbinding te kunnen leggen met de rollen volgens OAuth. PGO Presenter en PGO User Agent zijn alle front-end-rollen voor de PGO Server, en kunnen bijvoorbeeld allebei in een browser zijn geïmplementeerd, maar voor een goede binding aan de OAuth- en Authentication-rollen en voor een goede beveiligingsmaatregelen is het nodig deze twee rollen te scheiden. Zoals ook elders in het MedMij Afsprakenstelsel gaat het hier om rollen, om setjes verantwoordelijkheden dus, niet om implementatiecomponenten.

In het Zorgaanbiedersdomein is zo'n scheiding niet nodig. Waar een Persoon zelf operationeel betrokken wordt in het informatieverkeer — namelijk om zich te laten authenticeren, en het verkeer te laten autoriseren — laat de Zorgaanbieder zich operationeel geheel vertegenwoordigen door zijn Dienstverlener en diens Authorization Server en Resource Server. Ook al zal in veel gevallen de gezondheidsinformatie uiteindelijk uit een achterliggend systeem worden betrokken, voor het MedMij Afsprakenstelsel is dat geen kwestie. Het is voldoende om bij de Authorization Server en Resource Server de eindverantwoordelijkheid neer te leggen (black box).

In lijn met keuzes op de Proces- en Informatielaag, treden deze servers op namens alle eventuele achterliggende systemen in het Zorgaanbiedersdomein, zoals xIS'en. Die achterliggende complexiteit is een black box. Het is mogelijk dat een individuele xIS optreedt voor beide servers, maar dan moeten ook alle met deze rollen verbonden verantwoordelijkheden zijn ingevuld, zowel de direct verbonden verantwoordelijkheden (op de Applicatielaag) als de indirect verbonden verantwoordelijkheden (op de lagen erboven en eronder).

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. Op deze laag onderscheiden we bij deze toegang twee rollen: de rol PGO Presenter die zorgt voor de presentatie van de functionaliteit aan de Zorggebruiker, en de rol PGO User Agent die zorgt voor het aanspreken van de PGO Server en de Authorization Server. Het is de rol PGO User Agent die verbonden wordt met de rollen OAuth User Agent en Authentication User Agent. De PGO User Agent spreekt uiteindelijk dus ook de Authentication Service aan.

De rollen Authorization Server en respectievelijk Resource Server (in UCI Verzamelen en UCI Delen) of Subscription Server (in UCI Abonneren) werken in het MedMij-afsprakenstelsel samen in eenzelfde ononderbroken sessie. Hun onderlinge relatie is een proceskoppeling. Dat wil zeggen, zij worden georkestreerd onder de hoede van één procesgang. Rollen in het MedMij Afsprakenstelsel zijn echter groepjes verantwoordelijkheden, geen implementatiecomponenten. Het is daarmee aan de Dienstverlener zorgaanbieder om in zijn implementatie, en business model, keuzes te maken over het scheiden of juist combineren van deze twee rollen. Als de rollen gescheiden zijn is het bovendien goed mogelijk om één Authorization Server of Subscription Server te laten samenwerken met meerdere Resource Servers en om één Resource Server zaken te laten doen met meerdere Authorization Servers of Subscription Servers. Steeds echter zullen zij samen het gedrag moeten vertonen dat wordt geëist door het MedMij Afsprakenstelsel. Overigens maakt ook de OAuth-specificatie gewag van deze implementatievrijheid.

Omdat de sessiecoördinatie in het Zorgaanbiederdomein zich over het scheidsvlak tussen Authorization Server en Resource Server of Subscription Server uitstrekt, moet er in geval van gescheiden implementatie van Authorization Server en Resource Server of Subscription Server een interface worden gerealiseerd waarin die sessiecoördinatie in stand blijft. Bovendien moet, als de relatie tussen Authorization Server en Resource Server of Subscription Server niet één-op-één is, ervoor worden gezorgd dat de juiste twee elkaar vinden bij de communicatie over een specifiek access token.

Ondanks deze implementatievrijheid hebben de verantwoordelijkheden in het MedMij Afsprakenstelsel invloed op de implementatie-architectuur in het Zorgaanbiedersdomein. Met name vereist de adressering dat er voor één combinatie van Zorgaanbieder, Gegevensdienst, Interfaceversie (en Systeemrol) maar één authorization endpoint en één token endpoint (en één resource endpoint of subscription endpoint) kan zijn. Bovendien voorkomen beperkingen op de informatie-inhoud van authorization codes en access tokens dat het interface tussen Authorization Server en Resource Server of Subscription Server via het Persoonsdomein wordt gerealiseerd. Op enkele uitzonderingen na is dat interface een interne aangelegenheid van het Zorgaanbiedersdomein. Daarmee worden zowel principes P1 en P7 gediend, alsook dataminimalisatie, en dus de privacy. De belangrijkste uitzondering is dat de authorization code en het access token desgewenst een identificatie mogen bevatten van de service die het heeft uitgegeven. Daarmee kan de (voorziene) acceptant van de authorization code of het access token de Authorization Server of Subscription Server vinden waar de validatie van de authorization code of het access token moet plaatsvinden.

Zelfs als er sprake is van gescheiden implementatie, is het nog steeds één Dienstverlener Zorgaanbieder die eindverantwoordelijk is, jegens MedMij, voor het gezamenlijke gedrag van Authorization Server en Resource Server of Subscription Server. Dat betekent dat de interoperabiliteit tussen Authorization Server en Resource Server of Subscription Server moet vallen onder de overeenkomst die de betreffende Dienstverlener zorgaanbieder aangaat met eventuele onderaannemers, bijvoorbeeld als de Dienstverlener zorgaanbieder zelf de Resource Server of Subscription Server exploiteert maar een onderaannemer voor de Authorization Server contracteert. Zie ook de toelichting, onder de Rollen op de Netwerk-pagina, van hoe op netwerkniveau met Nodes wordt omgegaan indien een Dienstverlener zorgaanbieder gebruik zou maken van onderaannemers voor bijvoorbeeld AuthorizationServer- of Subscription Server-functionaliteit..

Het is denkbaar dat een community van dienstverleners in het Zorgaanbiedersdomein tot een afsprakenstelsel komt, aanpalend aan en voldoend aan het MedMij Afsprakenstelsel, waarin de interne architectuur van het Zorgaanbiedersdomein aan de orde is. Naast bovenbedoelde scheiding zouden daarin bijvoorbeeld ook architectuurkeuzes over de beschikbaarheids- en ontvankelijkheidstoets kunnen worden opgenomen.

Het is van belang om een heldere scheiding te maken tussen autorisatie en authenticatie in het MedMij Afsprakenstelsel. Niet alleen zijn het verschillende functionaliteiten, authenticatie voor vaststelling van identiteit en autorisatie voor het beheren van toegangsrechten, de bijbehorende rollen kunnen in het MedMij Afsprakenstelsel niet zomaar worden gecombineerd. De Authorization Server heeft de rol om, namens de Zorgaanbieder, op verzoek van de Persoon, autorisaties uit te delen aan de PGO Server. Om dat betrouwbaar te kunnen doen, en om aan een wettelijke verplichting van de Zorgaanbieder invulling te geven, schakelt de Authorization Server de (externe) Authentication Service in.

Dat betekent echter niet dat de Authorization Server op haar beurt identiteitsdiensten gaat verlenen aan de PGO Server, door bijvoorbeeld een aan de BSN gekoppelde identiteit mee te geven met het acces token dat ze uitdeelt. Dat zou oneigenlijke verbreding zijn van haar authenticatierol, die begrensd zou moeten blijven tot de verantwoordelijkheden jegens de Zorgaanbieder en zich niet moet uitstrekken tot het bedienen van de PGO Server. Bovendien zou het een centrum van Persoons-identiteit creëren in het MedMij-landschap die, gezien de regiedoelstellingen van MedMij, bij voorkeur niet in het Zorgaanbiedersdomein ligt, maar in het Persoonsdomein, en daarbinnen bij voorkeur zo dicht mogelijk bij de Persoon zelf.

Daarom vindt er op het koppelvlak tussen PGO Server en Authorization Server geen uitwisseling van Persoons-identiteiten plaats, niet met bijvoorbeeld de standaard OpenID Connect, noch met een andere standaard met dat doel. Dat wil niet zeggen dat zulke standaarden niet op andere toekomstige koppelvlakken in het MedMij Afsprakenstelsel toegepast kunnen gaan worden, op koppelvlakken dus die juist wel voor identiteitsdienstverlening bedoeld zijn, in plaats van voor autorisatie.

De standaarden OAuth 2.0 en SAML 2.0 — als voorbeeld; de gekozen Authentication Service kan een ander koppelvlak gebruiken dan SAML — hebben dus verschillende doelen: OAuth voor autorisatie en SAML voor authenticatie. Dat zorgt er onder andere voor dat de rolstructuur anders is. In OAuth is er een gebruiker (Resource Owner) die via zijn browser of app (User Agent) aan de ene applicatie (Client) toegang verleent aan een andere (Resource Server), welke laatste zich daarvoor laat bijstaan door een Authorization Server. In SAML is er een gebruiker die via een browser of app (User Agent) inlogt bij een dienst (Service Provider), die zich daarvoor laat bijstaan door een Identity Provider.

Toch zitten er belangrijke overeenkomsten tussen de manieren waarop ze werken.

• Beide gaan ervan uit dat de eindgebruiker zich aandient via een betrekkelijk onveilig kanaal (de User Agent, het "front-channel"), terwijl er ook gevoeliger informatie moet worden uitgewisseld ("back-channel"), dat niet via dit kanaal verloopt. 
• Bij beide moet de User Agent aan de hand worden genomen en heen- en teruggestuurd (redirect). Bij OAuth is dat van de Client naar de Authorization Server en terug. Bij SAML is dat van de Service Provider naar de Identity Provider en terug.
• Bij beide krijgt de Client (bij OAuth de Client en bij SAML de Service Provider) niet onmiddellijk de gewenste informatie (bij OAuth het access token en bij SAML de gebruikersidentiteit), maar via een ophaalbewijs (bij OAuth de authorization code, bij SAML het artefact). Het ophaalbewijs gaat voorlangs (via de User Agent), waarna achterlangs met het ophaalbewijs de gewenste informatie wordt opgehaald.

In artikel 7 wordt het MedMij-verkeer afgebakend, met het oog op de Netwerk-laag. Al het MedMij-verkeer is over domeingrenzen. Bovendien maakt noch eventueel verkeer tussen PGO Presenter en PGO User Agent, noch eventueel verkeer tussen Authorization Server en Resource Server deel uit van MedMij-verkeer. Ook authenticatieverkeer is uitgesloten, omdat het MedMij Afsprakenstelsel geen eisen oplegt over welke (externe) Authentication Service wordt gebruikt. Het MedMij Afsprakenstelsel vereist dát er een passende authenticatie door Zorgaanbieder moet plaatsvinden, maar het verkeer dat daarvoor nodig is — tussen Authorization Server, Authentication Service en PGO User Agent — is geen MedMij-verkeer. Het is de Zorgaanbieder die niettemin als verwerkingsverantwoordelijke verantwoordelijk blijft voor een passende keuze van een Authentication Service en voor het laten inrichten van het authenticatieverkeer.

Deze afbakening is bovendien de opmaat voor punt 8 erna. Het daarin gemaakte onderscheid tussen frontchannel- en backchannelverkeer is nodig voor het formuleren van verantwoordelijkheden over beveiliging (zie Netwerk-laag). In punt 7 moet ermee rekening gehouden worden dat er ook een use case-implementatie is op de Netwerk-laag: UCI Opvragen WHL.

Van de meeste use cases (zie de laag Processen en Informatie) wordt op deze (Applicatie)laag een use case-implementatie (UCI) voorgeschreven. Het gaat om de volgende.

De gebruikersbeleving wordt het best bediend door de gehele procesgang ononderbroken te houden.

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

Conform wettelijke verplichting geeft Zorggebruiker, in deUC Verzamelen en de UC Abonneren, actief toestemming aan de Zorgaanbieder. In de UC Delen is deze verplichting niet aan de orde, maar vindt op dit moment evengoed een bevestiging door de Zorggebruiker plaats. De PGO Presenter presenteert een venster waarin de Zorggebruikerdeze toestemming, respectievelijk bevestiging, kan geven. Aangezien in het persoonsdomein niet met BSN gewerkt mag worden, moet er een vervangende identificatie van de zorggebruiker gebruikt worden. Zie verantwoordelijkheid 5.

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 Resource Server aan de Client de gevraagde resources kan prijsgeven als laatstgenoemde het access token aan eerstgenoemde overlegt. Bij de eenvoudigste vorm (Bearer Token) geeft de Resource Server eenvoudigweg aan elke 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 Client aan wie het uitgedeeld was. Andere token types kunnen daarom vragen om meer garanties, zoals een identiteit van de 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 Client en 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. Zie hiervoor verantwoordelijkheid 18.

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 Verzamelen ononderbroken uitgevoerd (zie onder 1). De 900 seconden moeten dan voldoende zijn voor de Client om het access token aan de 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 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 Authorization Server-sessie waarin het token werd uitgegeven, zodat de 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 8a blijft erop van kracht.

Wanneer een verloopmoment is opgenomen in het access token, wordt het mogelijk om de Resource Server te laten afzien van onnodige raadpleging van de 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 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 Resource Server samenwerkt met meerdere van hem gescheiden geïmplementeerde Authorization Servers, moet deze bij een aangeboden access token kunnen bepalen welke 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, verantwoordelijkheid 1). Zo hoeft de Resource Server niet apart door de PGO 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 PGO 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 Zorgaanbieder 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 Zorgaanbiederslijst de autoriteit: als de OAuth Client een access token heeft opgehaald op een plek die daartoe in de Zorgaanbiederslijst stond, dan moet hij dat access token kunnen aanbieden aan de plek die daartoe in de Zorgaanbiederslijst 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 Zorgaanbiedersdomein anderzijds, zodat principes P1 en P7 maximaal worden nageleefd en interne complexiteit en implementatiekeuzes in het Zorgaanbiedersdomein 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 zorgaanbiedersdomein, 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 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 Clients ten behoeve van hun betrouwbaarheid jegens Authorization Servers. We verwachten dat een groot deel van de implementaties van de Oauth Client (van de PGO Server dus) deze vertrouwelijkheid sowieso kunnen bieden, omdat ze de architectuur hebben van wat de OAuth-specificatie web application noemt. Andersoortige PGO 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 Netwerklaag:authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd.

Voor het opstellen van verantwoordelijkheden 15, 16 en 17 is gebruik gemaakt van RFC 6819 van IETF, dat een uitgebreide inventarisatie van die risico's bevat, inclusief een reeks van maatregelen per risico. Waar het risico van toepassing is op het gebruik van OAuth binnen MedMij, en de maatregelen passen binnen de MedMij-principes, zijn zij opgenomen in het afsprakenstelsel.

Met betrekking tot het gestelde in sectie 3.1 van RFC 6819 kan gesteld worden dat MedMij uitgaat van:

• handles i.p.v. assertions, zodat de OAuth Resource Server moet kunnen refereren aan data van de OAuth Authorization Server;
• bearer tokens i.p.v. proof tokens. Zie hiervoor verantwoordelijkheid 5 op deze laag.

In hoofdstuk 4 van RFC 6819 staat een uitgebreide lijst van beveiligingsrisico's. Niet van toepassing zijn, voor de deze release van het afsprakenstelsel:

• bedreiging 4.1.2: Obtaining Refresh Tokens, omdat het afsprakenstelsel niet met refresh tokens werkt;
• bedreiging 4.2.3: Malicious Client Obtains Existing Authorization by Fraud, omdat in het afsprakenstelsel de autorisatie (vooralsnog) strikt eenmalig mag worden gebruikt;
• bedreiging 4.3.4: Obtaining Client Secret from Authorization Server Database, omdat authenticatie van OAuth Clients in MedMij werkt op basis van PKI-servercertificaten, niet op basis van client secrets;
• bedreiging 4.3.5: Obtaining Client Secret by Online Guessing, omdat authenticatie van OAuth Clients in MedMij op basis van PKI-servercertificaten wordt gedaan, niet op basis van client secrets.

Wel van toepassing zijn:

• bedreiging 4.1.3: Obtaining Access Tokens;
• bedreiging 4.1.4: End-user Credential Phished Using Comprised or Embedded Browser;
• bedreiging 4.1.5: Open Redirectors on Client;
• bedreiging 4.2.1: Password Phishing by Counterfeit Authorization Server;
• bedreiging 4.2.2: User Unintentionally Grants Too Much Access Scope;
• bedreiging 4.2.4: Open Redirector;
• bedreiging 4.3.1: Eavesdropping Access Tokens;
• bedreiging 4.3.2: Obtaining Access Tokens from Authorization Server Database;
• bedreiging 4.3.3: Disclosure of Client Credentials during Transmission;
• bedreiging 4.1.1: Obtaining Client Secrets;
• bedreiging 4.4.1.1: Eavesdropping or Leaking Authorization Code;
• bedreiging 4.4.1.2: Obtaining Authorization "codes" from Authorization Server Database;
• bedreiging 4.4.1.3: Online Guessing of Authorization "codes";
• bedreiging 4.4.1.4: Malicious Client Obtains Authorization;
• bedreiging 4.4.1.5: Authorization "code" Phishing;
• bedreiging 4.4.1.6: User Session Impersonation;
• bedreiging 4.4.1.7: Authorization "code" Leakage through Counterfeit Client;
• bedreiging 4.4.1.8: CSRF against redirect-URI;
• bedreiging 4.4.1.9: Clickjacking Attack against Authorization;
• bedreiging 4.4.1.10: Resource Owner Impersonation;
• bedreiging 4.4.1.11: DoS Attacks That Exhaust Resources;
• bedreiging 4.4.1.12: DoS Using Manufactured Authorization "codes";
• bedreiging 4.4.1.13: Code Substitution (OAuth Login).

In relatie tot het MedMij Afsprakenstelsel vallen de maatregelen die getroffen moeten worden ter mitigatie van deze risico's uiteen in drie groepen:

• maatregelen waarin al is voorzien door één of meerdere verantwoordelijkheden in het MedMij-afsprakenstelsel, zoals bijvoorbeeld:
  • het gebruik van TLS (Netwerk-laag);
  • het gebruik van een (externe) Authentication Service (Afsprakenset release 1.4.0 > Architectuur en technische specificaties > Applicatie-laag);
  • het beperken van de scope en de geldigheidsduur van authorization codes en access tokens (Afsprakenset release 1.4.0 > Architectuur en technische specificaties > Applicatie-laag);
  • verantwoordelijkheid 3 op het Token interface;
• maatregelen die weliswaar door RFC6819 worden gesuggereerd, maar niet worden overgenomen in het MedMij Afsprakenstelsel, omdat zij niet passen bij diens principes of bij andere verantwoordelijkheden in het stelsel;
• overige maatregelen, die alsnog getroffen dienen te worden door PGO Server, OAuth Client of OAuth Authorization Server en in verantwoordelijkheden 15-17 staan genoemd.

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.

Voor een overzicht over alle lagen van de architectuur, en voor een toelichting van de betekenis van de symbolen en lijntjes, zie de overzichtspagina.

De afkorting:

• BV staat voor Bevestigingsverklaring;
• GNL staat voor Gegevensdienstnamenlijst;
• OCL staat voor OAuth Client List;
• TV staat voor Toestemmingsverklaring;
• TVA staat voor Toestemmingsverklaring Abonneren;
• ZAL staat voor Zorgaanbiederslijst.

Voor het opstellen van verantwoordelijkheden 15, 16 en 17 is gebruikgemaakt van RFC 6819 van IETF, dat een uitgebreide inventarisatie van die risico's bevat, inclusief een reeks van maatregelen per risico. Waar het risico van toepassing is op het gebruik van OAuth binnen MedMij, en de maatregelen passen binnen de MedMij-principes, zijn zij opgenomen in het afsprakenstelsel.

Met betrekking tot het gestelde in sectie 3.1 van RFC 6819 kan gesteld worden dat MedMij uitgaat van:

• handles i.p.v. assertions, zodat de OAuth Resource Server moet kunnen refereren aan data van de OAuth Authorization Server;
• bearer tokens i.p.v. proof tokens. Zie hiervoor verantwoordelijkheid 5 op deze laag.

In hoofdstuk 4 van RFC 6819 staat een uitgebreide lijst van beveiligingsrisico's. Niet van toepassing zijn, voor de deze release van het afsprakenstelsel:

• bedreiging 4.1.2: Obtaining Refresh Tokens, omdat het afsprakenstelsel niet met refresh tokens werkt;
• bedreiging 4.2.3: Malicious Client Obtains Existing Authorization by Fraud, omdat in het afsprakenstelsel de autorisatie (vooralsnog) strikt eenmalig mag worden gebruikt;
• bedreiging 4.3.4: Obtaining Client Secret from Authorization Server Database, omdat authenticatie van OAuth Clients in MedMij werkt op basis van PKI-servercertificaten, niet op basis van client secrets;
• bedreiging 4.3.5: Obtaining Client Secret by Online Guessing, omdat authenticatie van OAuth Clients in MedMij op basis van PKI-servercertificaten wordt gedaan, niet op basis van client secrets.

Wel van toepassing zijn:

• bedreiging 4.1.3: Obtaining Access Tokens;
• bedreiging 4.1.4: End-user Credential Phished Using Comprised or Embedded Browser;
• bedreiging 4.1.5: Open Redirectors on Client;
• bedreiging 4.2.1: Password Phishing by Counterfeit Authorization Server;
• bedreiging 4.2.2: User Unintentionally Grants Too Much Access Scope;
• bedreiging 4.2.4: Open Redirector;
• bedreiging 4.3.1: Eavesdropping Access Tokens;
• bedreiging 4.3.2: Obtaining Access Tokens from Authorization Server Database;
• bedreiging 4.3.3: Disclosure of Client Credentials during Transmission;
• bedreiging 4.1.1: Obtaining Client Secrets;
• bedreiging 4.4.1.1: Eavesdropping or Leaking Authorization Code;
• bedreiging 4.4.1.2: Obtaining Authorization "codes" from Authorization Server Database;
• bedreiging 4.4.1.3: Online Guessing of Authorization "codes";
• bedreiging 4.4.1.4: Malicious Client Obtains Authorization;
• bedreiging 4.4.1.5: Authorization "code" Phishing;
• bedreiging 4.4.1.6: User Session Impersonation;
• bedreiging 4.4.1.7: Authorization "code" Leakage through Counterfeit Client;
• bedreiging 4.4.1.8: CSRF against redirect-URI;
• bedreiging 4.4.1.9: Clickjacking Attack against Authorization;
• bedreiging 4.4.1.10: Resource Owner Impersonation;
• bedreiging 4.4.1.11: DoS Attacks That Exhaust Resources;
• bedreiging 4.4.1.12: DoS Using Manufactured Authorization "codes";
• bedreiging 4.4.1.13: Code Substitution (OAuth Login).

In relatie tot het MedMij Afsprakenstelsel vallen de maatregelen die getroffen moeten worden ter mitigatie van deze risico's uiteen in drie groepen:

• maatregelen waarin al is voorzien door één of meerdere verantwoordelijkheden in het MedMij-afsprakenstelsel, zoals bijvoorbeeld:
  • het gebruik van TLS (Netwerk-laag);
  • het gebruik van een (externe) Authentication Service (Afsprakenset release 1.4.0 > Architectuur en technische specificaties > Applicatie-laag);
  • het beperken van de scope en de geldigheidsduur van authorization codes en access tokens (Afsprakenset release 1.4.0 > Architectuur en technische specificaties > Applicatie-laag);
  • verantwoordelijkheid 3 op het Token interface;
• maatregelen die weliswaar door RFC6819 worden gesuggereerd, maar niet worden overgenomen in het MedMij Afsprakenstelsel, omdat zij niet passen bij diens principes of bij andere verantwoordelijkheden in het stelsel;
• overige maatregelen, die alsnog getroffen dienen te worden door PGO Server, OAuth Client of OAuth Authorization Server en in verantwoordelijkheden 15-17 staan genoemd.