Inleiding

In de MedMij Core zijn verschillende rollen beschreven, die met elkaar de verschillende functies uitvoeren en gegevens uitwisselen. Hierbij gelden de verantwoordelijkheden, zoals in dit hoofdstuk benoemd.

De verantwoordelijkheden worden beschreven op de drie lagen van de architectuur, waarbij verantwoordelijkheden op de:

businesslaag getoond worden als gele regels;
applicatielaag getoond worden als blauwe regels;
technologielaag getoond worden als groene regels.

Iedere verantwoordelijkheid heeft een unieke code, die achter de regel wordt getoond. Verwijzingen naar de verantwoordelijkheid worden uitgevoerd vanuit deze unieke codes. De code is opgebouwd uit verschillende onderdelen.

Het eerste deel bestaat altijd uit 'core', om aan te geven dat het om verantwoordelijkheden gaat die in de MedMij Core beschreven staan.
Het tweede deel verwijst naar het onderwerp waarop de verantwoordelijkheid van toepassing is.
Het derde deel is een volgnummer, waarbij verantwoordelijkheden uit de:
- businesslaag beginnen met 100;
- applicatielaag beginnen met 200;
- technologielaag beginnen met 300.

Rollen

1.	Eigenaar MedMij neemt de functionele rol van MedMij Beheer op zich. Er is één Eigenaar MedMij die één MedMij Beheer speelt.	core.rollen.100
2.	Een Deelnemer neemt de functionele rol van Dienstverlener persoon en/of Dienstverlener aanbieder op zich. Hierbij speelt één Deelnemer één of meerdere dienstverleners en wordt elke dienstverlener gespeeld door één Deelnemer.	core.rollen.101
3.	Dienstverlener persoon biedt aan Persoon, in het kader van de toepasselijke Dienstverleningsovereenkomst, een geautomatiseerde rol ter gebruik, hier genoemd: DVP Server. Eén Dienstverlener persoon biedt één of meerdere DVP Servers en elke DVP Server wordt door één Dienstverlener persoon geboden.	core.rollen.200
4.	Dienstverlener aanbieder biedt een geautomatiseerde rol Authorization Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Deze rol wordt altijd gecombineerd met een Resource Server .	core.rollen.201
5.	Dienstverlener aanbieder biedt een geautomatiseerde rol Resource Server, voor het namens Aanbieders uitwisselen van gezondheidsinformatie met DVP Server. Eén Dienstverlener aanbieder biedt één of meer combinaties van één Authorization Server en één Resource Server en elke combinatie van één Authorization Server en één Resource Server wordt door één Dienstverlener aanbieder geboden.	core.rollen.202
6.	Persoon gebruikt één geautomatiseerde rol User Agent voor toegang tot de functionaliteit van DVP Server en Authorization Server. User Agent presenteert de functionaliteit aan Persoon, spreekt DVP Server aan en verwijst de Persoon naar de Authorization Server.	core.rollen.203
7.	MedMij Beheer ontsluit ten behoeve van alle betrokkenen een geautomatiseerde rol, hier genoemd: MedMij Registratie.	core.rollen.204
8.	Ten behoeve van het authenticeren van Persoon, zal de betrokken Authorization Server, in de rol van Authentication Client, gebruikmaken van de Authentication Server van een Dienstverlener authenticatie.	core.rollen.205
9.	Ten behoeve van het autoriseren van DVP Server voor toegang tot Resource Server, in het kader van de functies Verzamelen en (MedMij Afsprakenstelsel 2.2.3) Delen, zullen de betrokken User Agent, DVP Server, Authorization Server en Resource Server gebruik maken van OAuth 2.0, waarbij als grant type gebruik wordt gemaakt van Authorization Code en waarbij: de rol van OAuth Resource Owner wordt verzorgd door de Persoon; de rol van OAuth Client wordt verzorgd door de DVP Server; de rol van OAuth Resource Server wordt verzorgd door de Resource Server; de rol van OAuth Authorization Server wordt verzorgd door de Authorization Server. Toelichting 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.	core.rollen.206
10.	Als MedMij-verkeer is gedefinieerd: al het gegevensverkeer in het kader van enige functie-implementatie, onmiddellijk tussen twee verschillende van de vier volgende soorten rollen, namelijk: ten eerste DVP Server, ten tweede User Agent, ten derde Authorization Server of Resource Server en ten vierde MedMij Registratie, met dien verstande dat: in deze rollen telkens begrepen zijn de door hen eventueel verzorgde respectievelijke Autorisatie-rollen, van deze rollen telkens uitgesloten zijn de door hen eventueel verzorgde Authenticatie-rollen, en in deze rollen, met betrekking tot de functie-implementaties, telkens inbegrepen zijn de Nodes waarop zij functioneren.	core.rollen.207
11.	In het MedMij-netwerk functioneert: iedere rol uit de applicatie-laag op één of meer Frontchannel en/of Backchannel Nodes, met uitzondering van: Voor al diens frontchannel-verkeer gebruikt elke DVP Server één Frontchannel Node, en wel met een hostname die voor die DVP Server voorkomt op de OAuth Client List. MedMij Registratie functioneert op precies één node, welke bekend staat onder de naam 'Stelselnode'. Zonder de MedMij Stelselnode is er geen MedMij-netwerk. Toelichting 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 eindverantwoordelijkheid ook op netwerk-niveau toetsbaar. Zie de drie (ingewikkelde) invarianten bij AanbiederGegevensdienst 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.	core.rollen.300
12.	Op één Node functioneert hetzij één Authorization Server, hetzij één Resource Server, hetzij een combinatie van voorgaande rollen.	core.rollen.301

Functies & gegevens

De interpretatie door een Persoon van zorg- en gezondheidsinformatie die hij heeft verzameld bij een Aanbieder, en de interpretatie door een Aanbieder van zulke informatie die met hem/haar gedeeld is door een Persoon, hangt niet alleen af van de inhoud van die informatie, maar ook van de partij die de betreffende informatie oorspronkelijk heeft geregistreerd. De oorspronkelijke herkomst van de gegevens (de auteur) kent geen rol in het MedMij afsprakenstelsel. Dat betekent niet alleen dat er binnen de grenzen van het MedMij Afsprakenstelsel momenteel geen basis is om auteursauthenticiteit (met bijvoorbeeld certificaten) te arrangeren, maar het brengt ook met zich mee dat informatie over de auteur, hoe wezenlijk ook, voor het MedMij Afsprakenstelsel een gegevens-inhoudelijke aangelegenheid is. Die informatie wordt immers ook gebruikt voor de interpretatie van de gedeelde zorg- en gezondheidsinformatie. Omdat, conform principe 1, het MedMij Afsprakenstelsel gegevensneutraal wil zijn, wordt de auteursinformatie een onderdeel geacht van de inhoud van een Gegevensdienst.

Algemeen

1.

MedMij Beheer onderhoudt een archief van alle ooit verspreide versies van de Aanbiederslijst, de OAuth Client List, de Whitelist en de Gegevensdienstnamenlijst. De bewaartermijn, gerekend vanaf het einde van de geldigheid van de betreffende versie, is niet korter dan die van de logbestanden als bedoeld in verantwoordelijkheid core.logging.101.

core.algemeen.100

Dossier

1.	Dienstverlener persoon biedt Persoon de functie (MedMij Afsprakenstelsel 2.2.3) Verzamelen om bij Dienstverlener aanbieder gezondheidsinformatie te verzamelen van Aanbieder, indien deze die informatie beschikbaar stelt, die op deze Persoon betrekking heeft en laat deze in een persoonlijk gezondheidsdossier (kortweg Dossier) van Persoon bewaren. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. Toelichting 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.	core.dossier.100
2.	Dienstverlener persoon mag de Persoon de functie Automatisch verzamelen aanbieden, mits uitgevoerd vanuit een gegeven langdurige toestemming, het doel is de gebruiksvriendelijkheid (performance) voor de Persoon te verbeteren of dat dit ten dienste staat van analytische oplossingen waarbij de afhankelijkheid van de Persoon de dienstverlening belemmert. De Dienstverlener persoon moet hier afspraken over opnemen in de Gebruikersovereenkomst die hij met de Persoon afsluit.	core.dossier.107
3.	Dienstverlener persoon biedt Persoon de functie Delen om bij Dienstverlener aanbieder ten behoeve van een Persoon, indien deze daartoe ontvankelijk is, gezondheidsinformatie te plaatsen die op deze Persoon betrekking heeft en die afkomstig is uit het Dossier. Bij deze functie betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.	core.dossier.101
4.	Dienstverlener persoon draagt ervoor zorg dat in het Dossier bij alle bij Dienstverlener aanbieder in het kader van een Gegevensdienst verzamelde informatie onlosmakelijk deze Dienstverlener aanbieder en Gegevensdienst als bron en verzamelcontext worden aangetekend. Dienstverlener persoon draagt ervoor zorg dat, in geval van het delen van informatie met een (andere) Aanbieder deze bron- en context-informatie wordt meegeleverd aan de Dienstverlener aanbieder. Voor de benoeming van de bron wordt daarbij gebruik gemaakt van de Aanbiedersnaam. Voor de benoeming van de context wordt daarbij gebruik gemaakt van de betreffende Gegevensdienstnaam uit de Gegevensdienstnamenlijst. Toelichting 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.	core.dossier.102
5.	Dienstverlener persoon biedt Persoon de functie Raadplegen dossier om het persoonlijk gezondheidsdossier te raadplegen. Toelichting 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.	core.dossier.103
6.	In het kader van de functie Raadplegen dossier zal Persoon te allen tijde moeten kunnen nagaan: welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer van Dienstverlener aanbieder is betrokken van welke Aanbieder, en sindsdien niet is veranderd; welke inhoud van het Dossier wel, en welke niet, via MedMij-verkeer bij Dienstverlener aanbieder is geplaatst ten behoeve van welke Aanbieder. Toelichting 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.	core.dossier.104
7.	Dienstverlener persoon biedt Persoon de functie Verwijderen gegevens, waarmee Persoon gegevens, die via de MedMij Functie Verzamelen zijn verkregen, uit het persoonlijk gezondheidsdossier kan verwijderen.	core.dossier.105
8.	In het kader van de functie Verwijderen gegevens zal Persoon te allen tijde worden geïnformeerd: Welke verzamelde gegevens precies verwijderd worden. Dat verwijderen alleen in het PGO plaats vindt (en niet in enig bron systeem) Dat verwijderde gegevens in een later stadium mogelijk niet meer opgevraagd kunnen worden uit de bron systemen (bv bij het verlopen van de beschikbaarheidstermijn) De gepresenteerde Informatie ondersteunt de gebruiksvriendelijkheid door gebruik te maken van taalniveau B1. Met de gepresenteerde informatie is het voor de Persoon duidelijk op welk deel, van de inhoud van zijn dossier, de functie verwijderen gegevens wordt toegepast. En is duidelijk wat hiervan de mogelijke consequenties zijn.	core.dossier.106
9.	De Aanbieder, en daarmee de Dienstverlener aanbieder, moet de aanwezige langdurige toestemmingen beëindigen bij overlijden van de Persoon.	core.dossier.108

Opvragen gegevensdienstnamenlijst

1.	MedMij Beheer beheert en publiceert de Gegevensdienstnamenlijst. Deze beschrijft welke gebruikersvriendelijke namen horen bij welke Gegevensdiensten. De Gegevensdienstnamenlijst voldoet aan wat over haar is bepaald in de (MedMij Afsprakenstelsel 2.2.3) Informatiemodellen.	core.gnl.100
2.	MedMij Beheer biedt aan Deelnemers de functie Opvragen Gegevensdienstnamenlijst om de actuele versie van die Gegevensdienstnamenlijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.	core.gnl.101
3.	MedMij Registratie, DVP Server en Authorization Server implementeren de functie Opvragen Gegevensdiensnamenlijst, door middel van het bepaalde inzake het Gegevensdienstnamenlijstinterface op (MedMij Afsprakenstelsel 2.2.3) Interfaces lijsten. Zij gebruiken hiervoor het betreffende stroomdiagram.	core.gnl.200
4.	DVP Server en Authorization Server betrekken minstens elke vijftien minuten (900 seconden) de meest recente Gegevensdienstnamenlijst van MedMij Registratie.	core.gnl.201
5.	DVP Server en Authorization Server valideren elke nieuwe verkregen Gegevensdienstnamenlijst tegen het XML-schema van de Gegevensdienstnamenlijst.	core.gnl.202

Opvragen Aanbiederslijst

1.	MedMij Beheer beheert en publiceert een Aanbiederslijst, namens de deelnemende Dienstverlener aanbieder. De gepubliceerde Aanbiederslijst bevat steeds en slechts alle actuele entries, en beschrijft van elke Aanbieder: welke Gegevensdiensten deze momenteel aanbiedt, en welke technische adressen daarvoor moeten worden aangesproken bij de Dienstverlener aanbieder, gegeven een zekere Interfaceversie; Zie core.gegevensdiensten.201 voor de verantwoordelijkheden betreffende technische adressen. Toelichting 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.	core.alst.100
2.	MedMij Beheer beheert en publiceert, in de Aanbiederslijst, unieke en gebruikersvriendelijke namen van Aanbieders, van het formaat `<aanbieder>@medmij.` Daarop is naamgevingsbeleid van toepassing. Toelichting Aanbieders kunnen in hun directe of indirecte contact met Personen deze naam meegeven als hun "MedMij-naam". MedMij Beheer zorgt voor uniciteit en heeft het laatste woord bij het vaststellen ervan.	core.alst.101
3.	MedMij Beheer biedt aan Dienstverleners persoon een functie ((MedMij Afsprakenstelsel 2.2.3) Opvragen Aanbiederslijst) om de actuele versie van die Aanbiederslijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.	core.alst.102
4.	MedMij Registratie en elke DVP Server implementeren de functie (MedMij Afsprakenstelsel 2.2.3) Opvragen Aanbiederslijst, door middel van het bepaalde inzake het Aanbiederslijstinterface op (MedMij Afsprakenstelsel 2.2.3) Interfaces lijsten. Zij gebruiken hiertoe het betreffende stroomdiagram.	core.alst.200
5.	DVP Server betrekt minstens elke vijftien minuten (900 seconden) de meest recente Aanbiederslijst van MedMij Registratie.	core.alst.201
6.	DVP Server valideert elke nieuw verkregen Aanbiederslijst tegen het XML-schema van de Aanbiederslijst.	core.alst.202

Opvragen Whitelist

1.	MedMij Beheer beheert en publiceert een actuele Whitelist, namens de deelnemende Dienstverleners aanbieder en Dienstverleners persoon. De Whitelist beschrijft welke Nodes in MedMij-verkeer mogen deelnemen. De Whitelist voldoet aan wat over haar is bepaald in de (MedMij Afsprakenstelsel 2.2.3) Informatiemodellen.	core.whl.100
2.	MedMij Beheer biedt aan Deelnemers de functie Opvragen Whitelist om de actuele versie van die Whitelist op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.	core.whl.101
3.	De MedMij Stelselnode biedt aan Nodes de functie Opvragen Whitelist om de actuele versie van de Whitelist op te vragen. Betrokken rollen gebruiken hiervoor het betreffende stroomdiagram.	core.whl.300
4.	Het aandeel van de MedMij Stelselnode in de functie Opvragen Whitelist is voor minstens 99,9% van de tijd beschikbaar. MedMij Registratie laat, na het niet beschikbaar raken van het aandeel van MedMij Stelselnode in de usecase, maximaal acht uren (480 minuten) verstrijken voordat het weer beschikbaar is.	core.whl.301
5.	Nodes betrekken minstens elke vijftien minuten (900 seconden) de meest recente Whitelist van MedMij Registratie.	core.whl.302
6.	MedMij Registratie heeft `stelselnode.medmij.nl` als hostname. Toelichting 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.	core.whl.303
7.	Nodes valideren elke nieuw verkregen Whitelist tegen het XML-schema van de Whitelist. Alle hostnames op de Whitelist zijn fully-qualified domain names, conform RFC3696, sectie 2.	core.whl.304
8.	Ten behoeve van de technische beveiliging van het gegevensverkeer, dat zich voltrekt in het kader van de functie Opvragen Whitelist, maken betrokken rollen gebruik van Versleuteling, Server Authentication en Server Authorization.	core.whl.305
9.	Backchannel Nodes laten, elk hunnerzijds, backchannel-verkeer over het MedMij-netwerk dan en alleen dan doorgang vinden, nadat zij hebben vastgesteld dat de hostname van de andere Node, waarmee verbinding gemaakt zou worden, op de meest actuele Whitelist voorkomt. Toelichting In geval van frontchannel-verkeer vindt er geen Server Authorization plaats.	core.whl.306
10.	De Node die de TLS-client zou worden, voert de in verantwoordelijkheid core.whl.306 bedoelde controle tegen de Whitelist uit, voorafgaand aan de start van de TLS-handshake. Indien die controle niet kan worden uitgevoerd of een negatief resultaat oplevert, wordt de TLS-handshake niet gestart. de TLS-server is, voert de in verantwoordelijkheid core.whl.306 bedoelde controle tegen de Whitelist geheel uit voordat enige volgende stap wordt gezet door de OAuth Authorization Server of OAuth Resource Server, volgens de specificaties van de functies (MedMij Afsprakenstelsel 2.2.3) Verzamelen en (MedMij Afsprakenstelsel 2.2.3) Delen. Deze vereiste wordt volgordelijkheid genoemd. Indien de controle tegen de Whitelist niet kan worden uitgevoerd, of een negatief resultaat oplevert, wordt de procesgang onmiddellijk afgebroken en komt het niet tot een start van de uitvoering van die eerstvolgende stap. De controle tegen de Whitelist slaagt in dit geval dan en slechts dan als op de Whitelist tenminste een van de volgende namen uit het de door de TLS-client aangeboden certificaat voorkomen: de `Common Name` of een van de eventuele `Subject Alternative Names`.	core.whl.307
11.	Voor zover de Dienstverlener aanbieder ervoor kiest de controle tegen de Whitelist na afloop van de TLS-handshake uit te voeren, is deze controle logisch gescheiden van de bedoelde eerstvolgende stap. De vereiste volgordelijkheid kan worden aangetoond door middel van code-inspecties, penetratietesten en inspecties van logs. Toelichting 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 Whitelist uit te voeren is in dat geval gedurende de TLS-handshake, tussen de ontvangst van het certificaat van de TLS-client en de voorziene verzending van de `Finished` message. Indien die controle niet kan worden uitgevoerd, of een negatief resultaat oplevert, wordt dan in plaats van de `Finished message` de uitzondering `access_denied` verzonden. Hoewel sectie 7.2.2 van de TLS-specificatie voorziet in deze mogelijkheid, voorzien veel standaardimplementaties er niet in. Ingrepen in die standaardimplementaties zijn soms wel mogelijk, maar kunnen nieuwe beveiligingsrisico’s met zich meebrengen, bijvoorbeeld vanwege de complexiteit van het beheren van maatwerkaanpassingen aan standaardimplementaties. 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 geautoriseerd was. Omdat er meerdere manieren zijn om dat ook na afloop van de TLS-handshake te implementeren, vereist het MedMij Afsprakenstelsel hiervoor geen vaste architectuurvariant (zoals met een reverse proxy), maar stelt het de vereiste van volgordelijkheid, naast een logische scheiding. Deze moeten kunnen worden aangetoond door middel van code-inspectie, penetratietesten en inspecties van logs.	core.whl.308
12.	Indien een Whitelist-controle, in het kader van verantwoordelijkheid core.whl.307 en core.whl.308, niet kan worden uitgevoerd, of een negatief resultaat oplevert, breekt dit de voortgang af van de uitvoering van de functie en stellen de betrokken Applicatie-rollen elkaar hiervan niet op de hoogte. Toelichting Omdat het niet slagen van de Whitelist-controle duidt op een niet te vertrouwen tegenpartij, wordt deze daarvan niet op de hoogte gesteld.	core.whl.309

Opvragen OAuth Client List

1.	MedMij Beheer beheert en publiceert een actuele OAuth Client List, namens de deelnemende Dienstverleners persoon. De gepubliceerde OAuth Client List bevat steeds en slechts alle actuele entries, en beschrijft van elke OAuth Client: wat de gebruikersvriendelijke namen zijn die voor de Dienstverleners persoon worden gebruikt in de Toestemmingsverklaring en de Bevestigingsverklaring; Toelichting De OAuth Client List bevat dus geen namen voor Dienstverleners aanbieder. Dat is niet nodig, omdat deze niet voorkomen in de Toestemmingsverklaring.	core.ocl.100
2.	De OAuth Client List voldoet aan wat over haar is bepaald in de (MedMij Afsprakenstelsel 2.2.3) Informatiemodellen.	core.ocl.101
3.	MedMij Beheer biedt aan Deelnemers de functie Opvragen OAuth Client List om de actuele versie van die OAuth Client List op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.	core.ocl.102
4.	MedMij Registratie en Authorization Server implementeren de functie (MedMij Afsprakenstelsel 2.2.3) Opvragen OAuth Client List, door middel van het bepaalde inzake het interface voor OAuth Client List op (MedMij Afsprakenstelsel 2.2.3) Interfaces lijsten. Zij gebruiken hiervoor het betreffende stroomdiagram.	core.ocl.200
5.	Authorization Server betrekt minstens elke vijftien minuten (900 seconden) de meest recente OAuth Client List (OCL) van MedMij Registratie.	core.ocl.201
6.	Authorization Server valideert elke nieuwe verkregen OAuth Client List (OCL) tegen het XML-schema van de OAuth Client List.	core.ocl.202
7.	De OAuth Client List bevat voor elke DVP Server alleen die Node waarmee de betreffende DVP Server het frontchannelverkeer afhandelt. Toelichting 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.	core.ocl.300

Opvragen Aanbiedersregister

1.	Stichting MedMij publiceert het Aanbiedersregister op een publiek toegankelijke locatie. MedMij beheer publiceert uiterlijk 31 oktober 2023 de eerste versie van het Aanbiedersregister op de publiek toegankelijke locatie.	core.reg.100
2.	Het Aanbiedersregister is voor mensen begrijpelijk (human readable) weergegeven.	core.reg.101
3.	Het Aanbiedersregister bevat de gebruiksvriendelijke namen van aangesloten aanbieders, de bijbehorende identificerende gegevens, de bijbehorende gegevensdiensten en de uitwisselingsstatus. Het Aanbiedersregister bevat alleen de gegevens van aanbieders die voldoen aan de eisen en normen die in de DAP beschreven staan.	core.reg.102
4.	Aanbieders zijn zelf verantwoordelijk voor de kwaliteit van de informatie die in het register staat. Gewenste wijzigingen kunnen worden doorgegeven aan MedMij Beheer of worden doorgevoerd via de geboden interfaces.	core.req.103
5.	MedMij Beheer kan als enige partij de uitwisselingsstatus van een aanbieder of de bij de Aanbieder behorende gegevensdiensten aanpassen. MedMij Beheer baseert de keuze tot wijziging op de normen die in de DAP of specifieke bijlagen beschreven staan.	core.req.104
6.	MedMij Beheer biedt aan Deelnemers de functie Opvragen Aanbiedersregister om de actuele versie van het Aanbiedersregister op te vragen.	core.reg.105
7.	MedMij Registratie en DVP Server implementeren de functie Opvragen Aanbiedersregister, door middel van het bepaalde inzake het Aanbiedersregisterinterface op Interfaces lijsten en register.	core.reg.200
8.	Het Aanbiedersregister is gebaseerd op de inhoud van technische lijst(en) die in JSON-formaat wordt aangeboden. MedMij beheer levert uiterlijk 31 oktober 2023 de eerste versie van de lijst waarop het Aanbiedersregister gebaseerd is.	core.reg.201
9.	Het Aanbiedersregister is voor minstens 99,9% van de tijd beschikbaar. Onbeschikbaarheid duurt maximaal acht uren (480 minuten).	core.reg.300

Account bij Dienstverlener persoon

1.	Voor het inrichten van een MedMij dossier en voor het gebruikmaken van de verschillende MedMij functies moet de Persoon een actief account hebben bij de Dienstverlener persoon.	core.account.100
2.	De Dienstverlener persoon geeft een account de status 'inactief' zodra een account 6 maanden lang niet gebruikt is door de Persoon.	core.account.101
3.	De dienstverlener persoon geeft een inactief account de status 'actief' zodra de Persoon weer gebruikmaakt van het account.	core.account.102
4.	De Dienstverlener persoon moet de Persoon notificeren per e-mail of (als de DVP dit aanbiedt) per SMS van het feit dat het account de status 'inactief' heeft gekregen en indien van toepassing geen gebruikmaakt van aanwezige langdurige toestemmingen, totdat de Persoon opnieuw inlogt.	core.account.103

Gegevensuitwisseling

1.	De Dienstverlener persoon mag alleen de functie Automatisch verzamelen aanbieden indien het doel is de performance voor de Persoon te verbeteren. Daarnaast kan gebruikgemaakt worden van automatisch verzamelen ten dienste van analytische oplossingen, zoals AI modules en andere technische toepassingen, waarbij de afhankelijkheid van de gebruiker een bottleneck is voor de te leveren dienst.	core.gegevensuitwisseling.100
2.	De Dienstverlener persoon mag alleen gebruik maken van automatisch verzamelen bij een uitdrukkelijke opdracht van de Persoon.	core.gegevensuitwisseling.101
4..	De Dienstverlener persoon mag slechts één keer per 24 uur geautomatiseerd gegevens verzamelen bij een Dienstverlener aanbieder.	core.gegevensuitwisseling.102
5.	De Dienstverlener persoon mag alleen geautomatiseerd gegevens verzamelen voor actieve accounts.	core.gegevensuitwisseling.103
6.	De Dienstverlener persoon is verplicht de Persoon van succesvolle automatische uitwisseling te notificeren op een door de Persoon gewenste manier. Dit kan bijvoorbeeld in de app/browser, per e-mail of per SMS. Ook andere denkbare varianten zijn mogelijk.	core.gegevensuitwisseling.104
9.	Indien uitwisseling van gegevens binnen een langdurige toestemming 48 uur of langer niet mogelijk is, is de DVP verplicht de Persoon te notificeren op een door de Persoon gewenste manier. Dit kan bijvoorbeeld in de app/browser, per e-mail of per SMS. Ook andere denkbare varianten zijn mogelijk.	core.gegevensuitwisseling.105
10.	Bij geautomatiseerd verzamelen moet bij het request gelogd worden dat het om een automatische opvraging gaat.	core.gegevensuitwisseling.200
11.	Batch-gewijs geautomatiseerd verzamelen voor meerdere Personen mag alleen in het tijdslot van 23.00 uur tot 6.00 uur en niet allemaal op hetzelfde tijdstip.	core.gegevensuitwisseling.201

Gegevensdiensten

1.	Dienstverlener persoon laat Persoon gezondheidsinformatie verzamelen bij een Dienstverlener aanbieder of, ten behoeve van een Aanbieder, plaatsen bij een Dienstverlener aanbieder.	core.gegevensdiensten.100
2.	Elke Dienstverlener aanbieder ontsluit op elk moment minstens één Gegevensdienst. Toelichting 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.3) 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.	core.gegevensdiensten.101
3.	MedMij Beheer zal alleen in de Aanbiederslijst opnemen dat een zekere Gegevensdienst door een zekere Aanbieder via een Dienstverlener aanbieder, wordt aangeboden, indien zij (Stichting MedMij) heeft vastgesteld dat de Dienstverlener aanbieder voldoet aan de specifiek op die Gegevensdienst toepasselijke eisen en de normen die staan beschreven in de DAP en aanverwante documenten. Toelichting De Dienstverlener aanbieder heeft minimaal één Aanbieder nodig om zich te kwalificeren in het MedMij Afsprakenstelsel voor een informatie standaard.	core.gegevensdiensten.102
4.	Voor elke Gegevensdienst waarvan de Aanbiederslijst aangeeft dat een zekere Aanbieder deze aanbiedt, zal een Dienstverlener aanbieder ervoor zorgdragen dat die Gegevensdienst ook geleverd wordt. Daarbij wordt geen enkel onderscheid gemaakt tussen Dienstverleners persoon, tenzij het MedMij Afsprakenstelsel daartoe uitdrukkelijk verplicht. Dit geldt ook voor de mogelijke andere Gegevensdienst(en) die in de Catalogus staan genoemd als Vereist bij eerstgenoemde Gegevensdienst. Toelichting Net als verantwoordelijkheid core.gegevensdiensten.102, moet ook vanuit deze verantwoordelijkheid rekening gehouden worden met de afhankelijkheid tussen de Dienstverlener aanbieder en de Aanbieder. Deze regel legt de verantwoordelijkheid bij de Dienstverlener aanbieder voor het zorg dragen dat de Aanbieder met wie hij een dienstverleningsovereenkomst heeft, ook de Gegevensdienst levert die hij toegezegd heeft.	core.gegevensdiensten.103
5.	Het in verantwoordelijkheid core.gegevensdiensten.103 bepaalde is ook van toepassing zolang de geldigheid van de toepasselijke vermelding in de Aanbiederslijst niet langer dan één uur (3600 seconden) geleden is verstreken. Toelichting Zo wordt ervoor ruimte geboden dat na-ijlende sessies, die nog gebruik maken van de verstrijkende versie van de Aanbiederslijst, nog kunnen worden afgemaakt.	core.gegevensdiensten.104
6.	In aansluiting op verantwoordelijkheid core.gegevevendiensten.102 heeft Stichting MedMij het recht registraties van Aanbieder-gegevensdienst-combinaties te verwijderen als blijkt dat uitwisseling voor deze combinatie niet mogelijk is, of dat voor deze combinatie niet wordt voldaan aan de normen die staan beschreven in het Ketennormenbeleid.	core.gegevensdiensten.105
7.	Als een Dienstverleners persoon een zekere Gegevensdienst ontsluit ten behoeve van zijn Personen en daartoe laat leveren door een Dienstverlener aanbieder, zullen de DVP Server van die Dienstverlener persoon en de Authorization Server en Resource Server van die Dienstverlener aanbieder daarvoor de bij de Gegevensdienst horende functie implementeren en de bij de Gegevensdienst horende Systeemrollen gebruiken, zoals deze in de Catalogus zijn opgenomen, en zich daarbij te conformeren aan de specificaties van die Systeemrollen zoals die zijn gepubliceerd op de plaats(en) waarnaar de Catalogus verwijst met Functionelespecificatieverwijzing en Technischespecificatieverwijzing. Toelichting Zo wordt geborgd dat de juiste functie-implementaties en informatiestandaarden worden gebruikt. Ook wordt het correcte gebruik geborgd, wat bijdraagt aan interoperabiliteit en vertrouwen.	core.gegevensdiensten.200
8.	Voor iedere gegevensdienst moet de Dienstverlener aanbieder unieke endpoints voor de Resource Server registreren in de MedMij Registratie.	core.gegevensdiensten.201

Autorisatie

1.	Dienstverlener aanbieder vergewist zich ervan, elke keer opnieuw voordat hij Persoon gezondheidsinformatie van Aanbieder laat verzamelen door middel van de functie Verzamelen, dat deze Persoon uitdrukkelijk Toestemming heeft gegeven aan Aanbieder om de in de Gegevensdienst betrokken gezondheidsinformatie aan Dienstverlener persoon ter beschikking te laten stellen. De vraag om Toestemming heeft een vaste formulering, die is opgenomen in de functie Autoriseren. Deze Toestemming is: geldig voor de huidige sessie, of bij langdurige toestemming geldig voor onbepaalde tijd, mits minimaal één keer per 6 maanden gebruikgemaakt wordt van de toestemming en deze niet ingetrokken is.	core.autorisatie.100
2.	Dienstverlener aanbieder vergewist zich ervan, elke keer opnieuw voordat hij Persoon gezondheidsinformatie ten behoeve van Aanbieder laat plaatsen, dat deze Persoon uitdrukkelijk heeft bevestigd om de in de Gegevensdienst betrokken gezondheidsinformatie aan Aanbieder ter beschikking te willen stellen. De vraag om Bevestiging heeft een vaste formulering, die is opgenomen in de functie Delen. Deze bevestiging geldt niet buiten één doorloping van de functie Delen.	core.autorisatie.101
3.	In de implementatie van de functies (MedMij Afsprakenstelsel 2.2.3) Verzamelen en Delen handelen DVP Server enerzijds en Authorization Server en Resource Server anderzijds, hun onderlinge verkeer af conform de standaard OAuth 2.0. Toelichting 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, 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.	core.autorisatie.200
4.	Van de vier soorten authorization grants die OAuth 2.0 biedt, beperken de OAuth-rollen zich tot Authorization Code Grant. Toelichting 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.	core.autorisatie.201
5.	De OAuth Client en OAuth Resource Server zullen slechts tokens van het type Bearer-token uitwisselen, conform RFC6750. Toelichting 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.	core.autorisatie.202
6.	Hoewel het technisch mogelijk is om meerdere scopes mee te geven, maakt de OAuth Client voor de functie Verzamelen gebruik van een enkelvoudige scope. Hierin staat enkel de MedMij-naam van de Aanbieder, waarvoor autorisatie wordt gevraagd, genoemd. De OAuth Authorization Server genereert authorization-codes en refresh-tokens met een enkelvoudige scope die gelijk is aan de scope in het verzoek van de OAuth client. De OAuth Authorization Server genereert access-tokens met de mogelijkheid tot een meervoudige scope, waarin een lijst van beschikbare gegevensdiensten wordt toegevoegd. 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. Ook bij de functie Delen wordt gebruikgemaakt van een enkelvoudige scope. In tegenstelling tot de functie Verzamelen bevat de scope niet de MedMij-naam van de Aanbieder, maar is deze gerelateerd aan één Gegevensdienst per keer. Dit staat verder uitgewerkt in core.authint.200.	core.autorisatie.203
7.	De OAuth Authorization Server stelt van elke uitgegeven authorization-code en elk uitgegeven access-token de geldigheidsduur op exact 15 minuten (900 seconden). Toelichting 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.	core.autorisatie.204
8.	De OAuth Authorization Server stelt van elk uitgegeven refresh-token de geldigheidsduur op 6 maanden. Hierbij geldt de dag waarop het refresh-token uitgegeven wordt als eerste dag.	core.autorisatie.211
9.	De OAuth Authorization Server genereert authorization-codes, access-tokens en refresh-tokens zodanig, dat de kans op het raden ervan niet groter is dan 2^-128 en de daarvoor gebruikte random number generators cryptografisch veilig zijn.	core.autorisatie.205
10.	In de authorization-codes, access-tokens en refresh-tokens is het desgewenst toegestaan één of meer van de informatie-elementen uit de volgende limitatieve lijst op te nemen: een identifier van de authorization-code, respectievelijk het access-token of het refresh-token, indien die identifier op zichzelf voldoet aan de in verantwoordelijkheid 6 genoemde eisen; een verloopmoment van de geldigheid van het token, onder de voorwaarden dat zowel: de waarde daarvan in overeenstemming is met de verantwoordelijkheden in het MedMij Afsprakenstelsel en uit het verstreken zijn daarvan wél de ongeldigheid van de authorization-code of het access-token mag worden geconcludeerd door de OAuth Authorization Server of de Resource Server, maar uit het nog niet verstreken zijn daarvan niet diens geldigheid, waarvoor namelijk een validatie van het gehele token tegen de interne administratie van de OAuth Authorization Server de enige autoriteit is; een identificatie van de service die het token heeft uitgegeven; de `scope` waarvoor de authorization-code, het access-token of het refresh-token is uitgegeven. de naam van het token-formaat; een digitale handtekening.	core.autorisatie.206
11.	Geen andere informatie dan de in core.autorisatie.206 genoemde mag voorkomen in de authorization-code, het access-token of het refresh-token, ook niet versleuteld. Er mogen t.a.v. informatie-inhoud van het token verschillende keuzes gemaakt worden tussen authorization-code, access-token of het refresh-token. De OAuth Client mag de inhoud van het token niet interpreteren.	core.autorisatie.207
12.	Met betrekking tot zowel authorization-codes als access-tokens en refresh-tokens, draagt de OAuth Authorization Server die hen uitgeeft ervoor zorg, dat daarvan nooit twee dezelfde geldige in omloop zijn. Toelichting 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.	core.autorisatie.208
13.	Access-tokens worden alleen uitgegeven na controle van de client_id, de opgegeven autorisatie-code (of het refresh-token) en de Common name van het in de TLS verbinding gebruikte certificaat. De controles worden uitgevoerd conform: IETF RFC 6749, De code moet zijn uitgegeven aan de opgegeven client_id. IETF RFC 8705, Bij het verzoek naar het token-endpoint wordt gebruikgemaakt van een certificaat, waarvan de Common name geregistreerd is bij de opgegeven client_id. Controle certificaat optioneel 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.	core.autorisatie.209
14.	Het OAuth-client type van de OAuth Client is confidential. Toelichting 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.	core.autorisatie.210

Authenticatie

1.

Dienstverlener aanbieder draagt ervoor zorg dat de onder core.gegevensdiensten.103, core.gegevensdiensten.104, core.autorisatie.100 en core.autorisatie.101 bedoelde vraag om Toestemming, respectievelijk bevestiging, slechts plaatsvinden wanneer hij de identiteit van de Persoon met passende zekerheid heeft vastgesteld.

core.authenticatie.100

Adressering

1.	De OAuth Client stelt conform RFC 3986 de URI samen waarmee hij zichzelf, de Authorization Server en de Resource Server adresseert.	core.adressering.200
2.	De URI's een hostname die een fully-qualified domain name is, conform RFC3696, sectie 2, en heeft het patroon `scheme://host path`, waarbij: `scheme` altijd `https` is, in lowercase; `host` een hostname is waarin slechts de karakters [a-z], [0-9], "." (punt) en "-" (koppelteken) voorkomen; elke punt twee opeenvolgende segmenten scheidt en van elk der gescheiden segmenten geen deel uitmaakt; het eerste karakter van een segment geen koppelteken is; elk segment minstens één karakter lang is; het laatste segment minstens twee karakters lang is; het laatste karakter geen koppelteken mag zijn; maximaal 255 tekens voorkomen; ten minste twee segmenten voorkomen; `path` de syntax heeft van `path-abempty` uit sectie 3.3 van RFC 3986 (en dus leeg mag zijn), maar niet eindigt op een `/.` Toelichting 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.	core.adressering.201
3.	In alle adressering op het authorization interface, het token interface en het resource interface is het gebruik van het voor `https` bedoelde poortnummer, zoals opgenomen in de Service Name and Transport Protocol Port Number Registry van IANA, verplicht. Toelichting 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.	core.adressering.202
4.	Voor het samenstellen van alle adressen van het authorization request en het token request, betrekt de OAuth Client de eerste onderdelen van de URI, namelijk `host` en `path`, uit de Aanbiederslijst, op basis van de van toepassing zijnde Aanbieder, Interfaceversie en Gegevensdienst. Andere elementen van de algemene URI-syntax, zoals `user`, `password`, `query` en `fragment`, zijn afwezig in de adressen. Voor het samenstellen van alle adressen van het resource request, betrekt de OAuth Client de base url (het onderdeel van de URI dat is aangeduid als `[base]` in de specificaties van de Transactie die behoort bij de van toepassing zijnde combinatie Aanbieder, Gegevensdienst en Systeemrol), uit de Aanbiederslijst, op basis van de van toepassing zijnde Aanbieder, Interfaceversie, Gegevensdienst en Systeemrol. Wanneer de specificaties een request identificeren maar geen `[base]` aanduiden, mag de OAuth Client het resource request alleen indienen als de volledige, absolute URI van het resource request begint met de volledige ResourceEndpointuri zoals die is verkregen uit de Aanbiederslijst, op basis van de van toepassing zijnde Aanbieder, Interfaceversie, Gegevensdienst en Systeemrol.	core.adressering.203
5.	MedMij Registratie wordt in de functies (MedMij Afsprakenstelsel 2.2.3) Opvragen Aanbiederslijst, (MedMij Afsprakenstelsel 2.2.3) Opvragen OAuth Client List en (MedMij Afsprakenstelsel 2.2.3) Opvragen Gegevensdienstnamenlijst geadresseerd met de hostname `stelselnode.medmij.nl`.	core.adressering.204

Toelichting

De Aanbiederslijst wordt dus gebruikt door de OAuth Client om, gegeven een zekere Interfaceversie, het endpoint te kennen dat past bij de van toepassing zijnde Aanbieder, Gegevensdienst en, voor het resource endpoint, Systeemrol. Net zo gebruikt de Notification Client de OAuth Client List om, gegeven een zekere Interfaceversie, het endpoint te kennen dat past bij de van toepassing zijnde OAuth Client en Gegevensdienst. Daarom moet er uit één zo'n setje één endpoint-adres volgen. Andersom echter is dat geen eis. Het is mogelijk om, in elke door de Dienstverlener Aanbieder gewenste combinatie, endpointadressen te hergebruiken voor meerdere van zulke setjes in de Aanbiederslijst, respectievelijk door de Dienstverlener persoon in de OAuth Client List.

Beveiliging

1.

In het gegevensverkeer voor de functies (MedMij Afsprakenstelsel 2.2.3) Verzamelen, Delen, Beheren toestemmingen, (MedMij Afsprakenstelsel 2.2.3) Opvragen Aanbiederslijst, (MedMij Afsprakenstelsel 2.2.3) Opvragen OAuth Client List en (MedMij Afsprakenstelsel 2.2.3) Opvragen Gegevensdienstnamenlijst, maken betrokken rollen gebruik van de functies Versleuteling, Server Authentication en Server Authorization, zoals beschreven onder TLS en certificaten.

core.beveiliging.200

2.

De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling.

Toelichting

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.

core.beveiliging.201

3.

De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

beveiligingsmaatregel	paragraaf in RFC 6819	gemitigeerde risico('s)
Clients should use an appropriate protocol, such as OpenID or SAML to implement user login. Both support audience restrictions on clients.	4.4.1.13	4.4.1.13
All clients must indicate their client ids with every request to exchange an authorization "code" for an access token.
Keep access tokens in transient memory and limit grants.	5.1.6
Keep access tokens in private memory.	5.2.2	4.1.3
The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token.	5.3.5	4.4.1.8
CSRF defense and the "state" parameter created with secure random codes should be deployed on the client side. The client should forward the authorization "code" to the authorization server only after both the CSRF token and the "state" parameter are validated.	4.4.1.12

core.beveiliging.202

4.

De OAuth Client realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

beveiligingsmaatregel	paragraaf in RFC 6819	gemitigeerde risico('s)
Client applications should not collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g., the system browser.	4.1.4	4.1.4
The client server may reload the target page of the redirect URI in order to automatically clean up the browser cache.	4.4.1.1	4.4.1.1
If the client authenticates the user, either through a single-sign-on protocol or through local authentication, the client should suspend the access by a user account if the number of invalid authorization "codes" submitted by this user exceeds a certain threshold.	4.4.1.12	4.4.1.12
Client developers and end users can be educated to not follow untrusted URLs.	4.4.1.8	4.4.1.8
For newer browsers, avoidance of iFrames during authorization can be enforced on the server side by using the X-FRAME-OPTIONS header. For older browsers, JavaScript frame-busting techniques can be used but may not be effective in all browsers.	5.2.2.6	4.4.1.9
Explain the scope (resources and the permissions) the user is about to grant in an understandable way	5.2.4.2	4.2.2

core.beveiliging.203

5.

De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conform RFC 6819:

beveiligingsmaatregel	paragraaf in RFC6819	gemitigeerde risico('s)
Authorization servers should consider such attacks: Password Phishing by Counterfeit Authorization Server	4.2.1	4.2.1
Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites.
Authorization servers should decide, based on an analysis of the risk associated with this threat, whether to detect and prevent this threat.	4.4.1.10	4.4.1.10
The authorization server may force a user interaction based on non-predictable input values as part of the user consent approval.
The authorization server could make use of CAPTCHAs.
The authorization server should consider limiting the number of access tokens granted per user.	4.4.1.11	4.4.1.11
The authorization server should send an error response to the client reporting an invalid authorization "code" and rate-limit or disallow connections from clients whose number of invalid requests exceeds a threshold.	4.4.1.12	4.4.1.12
Given that all clients must indicate their client ids with every request to exchange an authorization "code" for an access token, the authorization server must validate whether the particular authorization "code" has been issued to the particular client.	4.4.1.13	4.4.1.13
Best practices for credential storage protection should be employed.	5.1.4.1	4.4.1.2
Enforce system security measures.	5.1.4.1.1	4.3.2 en 4.4.1.2
Enforce standard SQL injection countermeasures.	5.1.4.1.2
Store access token hashes only.	5.1.4.1.3
The authorization server should enforce a one-time usage restriction.	5.1.5.4	4.4.1.1
If an authorization server observes multiple attempts to redeem an authorization "code", the authorization server may want to revoke all tokens granted based on the authorization "code".	5.2.1.1
Bind the authorization "code" to the redirect URI.	5.2.4.5	4.4.1.3
the authorization server associates the authorization "code" with the redirect URI of a particular end-user authorization and validates this redirect URI with the redirect URI passed to the token's endpoint,	4.4.1.7

core.beveiliging.204

6.

OAuth Client, OAuth Authorization Server en OAuth Resource Server implementeren de op deze respectievelijke rollen toepasselijke beveiligingsmaatregelen, volgens paragaaf 5.3 van RFC 6750.

Toelichting

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.

core.beveiliging.205

Toelichting

Voor het opstellen van bovenstaande verantwoordelijkheden 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.

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;
- het gebruik van een (externe) Authentication Server;
- het beperken van de scope en de geldigheidsduur van authorization codes en access tokens;
- verantwoordelijkheid 3 op het (MedMij Afsprakenstelsel 2.2.3) Token interface;
maatregelen die weliswaar door RFC 6819 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 DVP Server, OAuth Client of OAuth Authorization Server.

Logging

In het MedMij Afsprakenstelsel worden verschillende soorten loggegevens besproken. De verantwoordelijkheden die gelden voor alle soorten loggegevens worden beschreven onder “Algemene verantwoordelijkheden logging”. De verantwoordelijkheden die alleen gelden voor de ketenlog loggegevens staan onder “Ketenlog”.

Algemene verantwoordelijkheden logging

1	Deelnemers richten de logbestanden in zoals beschreven bij Logging interface, de AVG en NEN 7513:2018.	core.logging.100
2	De bewaartermijnen voor de verschillende soorten loggegevens staan beschreven op de pagina A.12.4.1 Gebeurtenissen registreren van het Normenkader. Na afloop van de bewaartermijn van loggegevens moeten Deelnemers de loggegevens vernietigen.	core.logging.101
3	Bij het loggen van verzonden resource requests neemt de OAuth Client ook het MedMij-Request-ID Header Field op in het logbestand als ID attribuut van het request object.	core.logging.200
4	Bij het loggen van ontvangen resource requests nemen de OAuth Authorization Server en de OAuth Resource Server ook het MedMij-Request-ID Header Field op in het logbestand als ID attribuut van het request object.	core.logging.201

Ketenlog

1	De vastgelegde logregels worden near-realtime (kleine logbestanden, maar met hoge frequentie) of in grotere logbestanden (minimaal eenmaal per uur) aangeleverd. Maximaal één uur na het vastleggen van de gebeurtenis moet de logregel zijn aangeleverd bij MedMij.	core.logging.102
2	Logregels die met MedMij gedeeld worden mogen geen inhoudelijke gegevens over de Persoon bevatten, niet direct herleidbaar zijn naar de Persoon en mogen alleen metagegevens over de gebeurtenissen bevatten.	core.logging.103
3	De aangeboden logbestanden dienen te bestaan uit niet eerder succesvol aangeleverde logregels. Het aanbieden van duplicaat regels/logbestanden dienen door de deelnemer tot een minimum te worden beperkt.	core.logging.104
4	Aanbevolen wordt om de logregels en logbestanden die niet succesvol aangeleverd kunnen worden alsnog aan te bieden op het eerst volgende moment nadat de uitdaging is verholpen.	core.logging.105
5	Aanbevolen wordt dat in het geval dat er in het tijdsbestek van één uur na het leveren van een logbestand geen nieuwe gebeurtenissen worden vastgelegd, de deelnemer gedurende het voortbestaan van deze situatie minimaal één keer (1x) per uur een leeg logbestand aanlevert.	core.logging.106
6	De DVP Server logt: in de rol van OAuth Client elk verzoek aan en antwoord van de OAuth Authorization Server, ook het Authorization request dat vanuit de User Agent wordt gestuurd; in de rol van Resource Client elk verzoek aan en antwoord van de Resource Server; elke technische storing bij het uitvoeren van de MedMij functies.	core.logging.202
7	De Authorization Server logt: in de rol van OAuth Authorization Server elk verzoek van en antwoord aan de OAuth Client; het versturen van de pagina's naar de User Agent; in de rol van Authentication Client elk verzoek naar en antwoord van de Authentication Server; het resultaat van het uitvoeren van de beschikbaarheids- (Verzamelen en Abonneren) en ontvankelijkheidstoets (Delen); de door de Persoon teruggestuurde toestemmings- (Verzamelen en Abonneren) en bevestigingsverklaring (Delen); elke technische storing bij het uitvoeren van de MedMij functies.	core.logging.203
8	De Resource Server: elk verzoek van en antwoord aan de Resource Client; het resultaat van het uitvoeren van de beschikbaarheids- (Verzamelen en Abonneren) en ontvankelijkheidstoets (Delen); het resultaat van de verzamelde gegevens; elke technische storing bij het uitvoeren van de MedMij functies.	core.logging.204
9	Logregels worden in het JSON-formaat bij MedMij aangeleverd, zoals gespecificeerd bij Logging interface, op het door MedMij hiervoor beschikbaargestelde endpoint.	core.logging.205
10	Voordat de door de deelnemer aangeleverde logregels worden ontvangen door de loggingscomponent wordt een technische toetsing uitgevoerd op deze logregels. Krijgt de deelnemer een code 200 terug van de Logging Interface dan is het aanleveren van logregels geslaagd en is de data opgeslagen. Bij elke andere code was het aanleveren onsuccesvol en moet de batch opnieuw aangeleverd worden.	core.logging.209
11	De endpoint van de Logging interface heeft op jaarbasis een beschikbaarheid van minimaal 99,5%. MedMij laat, na het niet beschikbaar raken van de MedMij Logging interface, maximaal 43 kantooruren (2580 minuten) verstrijken voordat het weer beschikbaar is.	core.logging.206
12	De DVP Server maakt voor het versturen van een Authorization Request, of in het geval van langdurige toestemming voor het versturen van een Token Request, een trace-id aan dat gedurende het hele proces door alle rollen wordt gebruikt bij het vastleggen van bijbehorende logregels. De DVP Server neemt dit trace_id op als parameter `X-Correlation-ID` in het request, zoals gespecificeerd in de interface specificatie van (MedMij Afsprakenstelsel 2.2.3) Authorization interface, (MedMij Afsprakenstelsel 2.2.3) Token interface en Resource interface. Dit om de logregels van verschillende partijen in een proces aan elkaar te kunnen correleren.	core.logging.207
13	Bij het loggen van de verschillende gebeurtenissen tijdens het proces nemen OAuth Client, de OAuth Authorization Server en de OAuth Resource Server het X-Correlation-ID op in het logbestand als trace_id attribuut van het request object.	core.logging.208

Portabiliteit

1.	Dienstverlener persoon biedt Persoon de mogelijkheid om een Portabiliteitsrapport te verkrijgen. Daarmee kan Persoon geautomatiseerd een lijst exporteren, genaamd het Portabiliteitsrapport. Het Portabiliteitsrapport omvat de gegevens van alle keren, gedurende een zekere periode, dat Persoon deze Dienstverlener persoon bij een Aanbieder gezondheidsinformatie volgens een zekere Gegevensdienst heeft verzameld. De gegevens die met de functie Verwijder gegevens zijn verwijderd worden niet in het Portabiliteitsrapport opgenomen.	core.portabiliteit.100
2.	Dienstverlener persoon biedt Persoon pro-actief de export van een Portabiliteitsrapport aan: voordat Dienstverlener persoon, om welke reden dan ook, haar dienstverlening aan Persoon staakt; voordat Dienstverlener persoon de logbestanden zou verwijderen waaruit zij Portabiliteitsrapporten voor Persoon over een zekere periode zou samenstellen.	core.portabiliteit.101
3.	Dienstverlener persoon beperkt Persoon niet in het gebruik van de Portabiliteitsrapport in de relatie van Persoon met mogelijke andere en/of latere Dienstverlener persoon.	core.portabiliteit.102
4.	Het Portabiliteitsrapport voldoet aan hetgeen daarover bepaald is in de (MedMij Afsprakenstelsel 2.2.3) Informatiemodellen en heeft de technische vorm van een XML-document, dat voldoet aan het XML-schema dat op de pagina (MedMij Afsprakenstelsel 2.2.3) XML-schema's te vinden is. Toelichting Met het Portabiliteitsrapport krijgt Persoon een middel in handen om een belangrijk deel van de gezondheidsinformatie die hij in het Dossier in zijn PGO heeft verzameld, naar believen ook in andere PGO's onder te brengen (portabiliteit, overdraagbaarheid). Ook dat draagt bij aan de Regie van de Persoon over zijn gezondheidsinformatie, aan zijn voortdurend vrije keuze tussen Dienstverlener persoon (principe 7) en aan het beperken van het nadeel dat hij zou ondervinden wanneer zijn Dienstverlener persoon haar activiteiten zou staken. Er is geen garantie dat een Portabiliteitsrapport geautomatiseerd door een andere PGO dan die het rapport heeft gemaakt zou kunnen worden 'afgespeeld', al is het maar doordat niet alle gebruikte Gegevensdiensten nog als geldig in de Catalogus hoeven te staan. Het Portabiliteitsrapport geeft in dat soort gevallen nog steeds precieze en menselijkerwijs enigszins leesbare informatie waarmee de nieuwe PGO alsnog, desnoods, handmatig gevuld kan worden. Dienstverleners persoon kunnen hun dienstverlening aan Persoon kracht bij zetten door een importfunctie voor Portabiliteitsrapporten aan te bieden. Dit is echter niet verplicht en moet gezien worden in het licht van principe 3. Een zwaarder middel voor portabiliteit zou een uitwisselstandaard tussen PGO's zijn. Dit zou echter een flinke complexiteit en kosten met zich meebrengen, niet in het minst doordat het rekening zou moeten houden met alle voormalige versies van het MedMij Afsprakenstelsel en met Gegevensdiensten die ondertussen niet meer als geldig in de Catalogus staan.	core.portabiliteit.103

Domain Name System

1.	Dienstverleners persoon, Dienstverleners aanbieder en MedMij Beheer zijn, in hun rol als DNS Server of cliënt daarvan, ervoor verantwoordelijk dat de name records behorende bij de hostnames van Nodes zijn ondertekend volgens DNSSEC.	core.dns.300
2.	Elke Node, in zijn rol als DNS resolver in het Domain Name System, controleert of de ontvangen name records zijn voorzien van ondertekening volgens DNSSEC en valideert deze volgens DNSSEC. Indien deze controle en validatie niet beide slagen, ziet hij af van verbinding met de betreffende hostname. Toelichting Het gebruik van DNSSEC (RFC 4033, RFC 4034, RFC 4035) vermindert de kwetsbaarheid van het Domain Name System voor bijvoorbeeld DNS spoofing.	core.dns.301

TLS en certificaten

Toelichting

Onderstaande tabel vat samen hoe in de verantwoordelijkheden op deze laag de beveiligingsfuncties beveiliging, authenticatie en autorisatie worden ingericht. Het onderscheid, bij autorisatie, tussen inkomend en uitgaand verkeer is het gevolg van dat in deze twee gevallen de identificatie van de andere Node anders plaatsvindt.

	frontchannel- verkeer	uitgaand backchannel-verkeer	inkomend backchannel-verkeer
versleuteling volgens TLS	altijd
identificatie op basis van ...	`redirect_uri` of Aanbiederslijst		PKIoverheid- certificaat
authenticatie, op basis van PKI-certificaat, van ...	alleen de TLS-server	TLS-client én TLS-server
autorisatie op basis van controle tegen de Whitelist	niet	voorafgaand aan de TLS-handshake	zie verantwoordelijkheid core.whl.307

1.	Al het verkeer over het MedMij-netwerk is beveiligd en versleuteld met Transport Layer Security (TLS).	core.tls.300
2.	Er wordt gebruikgemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. Indien meerdere TLS-versies als "goed" geclassificeerd zijn, moet minimaal de laagste TLS-versie worden ondersteund. Hogere TLS-versies mogen worden aangeboden.	core.tls.301
3.	Van verantwoordelijkheid core.tls.301 kan in het MedMij Afsprakenstelsel worden afgeweken, indien dit expliciet benoemd wordt in nadere eisen binnen de afsprakenset.	core.tls.302
4.	Gebruik van TLS False Start is verboden. Toelichting 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.	core.tls.303
5.	Bij de TLS-handshake moet de hoogste toegestane TLS-versie gekozen worden die beide partijen ondersteunen.	core.tls.304
6.	Als invulling van core.tls.302 geldt, in afwijking van core.tls.301: TLS 1.2 moet door elke deelnemer ondersteund worden. TLS 1.3 moet door elke deelnemer ondersteund worden, indien redelijkerwijs mogelijk. TLS 1.2 TLS 1.3 wordt in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC als enige met "goed" geclassificeerd. Daarmee is dit de enige TLS-versie die volgens eis 1b ondersteund mag worden. Bij deze release van dit afsprakenstelsel kan TLS 1.3 niet door alle deelnemers ondersteund worden, omdat dit niet wordt aangeboden in door sommigen gebruikte componenten. Daarom maken we gebruik van de mogelijkheid die regel 1c biedt om een afwijkende regeling te treffen. De afwijkende regeling bestaat eruit dat TLS 1.3 door iedere deelnemer aangeboden moet worden, indien redelijkerwijs mogelijk. Om redenen van interoperabiliteit moet iedere deelnemer TLS 1.2 blijven ondersteunen. Het voornemen is deze afwijking te schrappen zodra TLS 1.3 breed ondersteund wordt, waardoor verantwoordelijkheid 1b weer onverkort geldt en TLS 1.3 de enige toegestane versie wordt. Dit kan al dan niet met behulp van een snel door te voeren patch op het MedMij Afsprakenstelsel.	core.tls.305
7.	Voor authenticatie en autorisatie bij backchannel-verkeer op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKIoverheid-certificaat overleggen, en wel een G1-certificaat van een PKIoverheid TSP. Private Root CA (per medio 2020 de standaard voor m2m) Stamcertificaat Staat der Nederlanden Private Root CA - G1 Domein Private Services, maar alleen de volgende: Staat der Nederlanden Private Services CA - G1 KPN PKIoverheid Private Services CA - G1 QuoVadis PKIoverheid Private Services CA - G1 Digidentity BV PKIoverheid Private Services CA - G1	core.tls.314
8.	Voor authenticatie en autorisatie bij frontchannel-verkeer tussen productieomgevingen op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKI-certificaat overleggen dat aan de volgende eisen voldoet: De vereisten aan de certificaat leverancier voor PKI certificaten zijn: De meest up-to-date WebTrust audit is succesvol doorlopen en de certificering is geldig voor de ‘Certificatie Authority’ op iedere schakel in de keten van ondertekeningen tot en met de uitgifte processen. De technische vereisten zijn: De ‘private key’ moet worden gegenereerd op het doelplatform waar het PKI certificaat wordt toegepast. Bij gebruik van publieke PKI certificaten is de toepassing van ‘Certification Authority Authorization Resource Record’ vereist. Het toepassen van DNSSEC op de gebruikte domeinen is vereist onder de voorwaarden van pas-toe-of-leg-uit. Strengere eisen kunnen worden gesteld vanuit aanvullende kaders, zoals aansluitvoorwaarden. Het gebruik van wildcard certificaten wordt niet toegestaan. Het gebruik van ‘multi-domain’-certificaten is toegestaan, onder de voorwaarde dat de eigenaar van het certificaat gelijk is aan de eigenaar van alle domeinen die opgenomen zijn in de Subject Alt Name DNS waarden van het certificaat. Uitgifte: Het zekerheidsuitgifte niveau moet minimaal op het OV-niveau (Organisation Validated) of met hogere zekerheid zijn uitgegeven voor publieke PKI webserver certificaten wanneer persoonsgegevens van bijzondere aard worden verwerkt. Dit is relevant voor de aanschaf van het certificaat en dit valt achteraf te controleren op het bestaan van Policy Object Identifiers (OIDs) die markeren welk type certificaat het betreft. De uitgever van de PKI certificaten is verantwoordingsplichtig aan de AVG en/of GDPR. Beheer: Veilig beheer moet zijn toegepast zoals toegelicht in ‘Factsheet Veilig beheer van digitale certificaten’.	core.tls.315
9.	Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel waarvan zij een certificaat afnemen. Een organisatie mag meerdere certificaten hebben. Toelichting Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel waarvan zij een certificaat afnemen. Een organisatie mag meerdere certificaten hebben. De keuze voor de PKI-standaard past bij principe 19 van het MedMij Afsprakenstelsel. Er bestaan andere manieren voor, en ideeën over, het borgen van vertrouwen in een netwerk van geautomatiseerde systemen, maar deze zijn nog lang niet zo bewezen als PKI, dat wereldwijd wordt ondersteund, en wereldwijd is beproefd, door overheden en marktspelers. Bij gebruik van de PKI-standaard doet zich de vraag voor van welk(e) PKI-stelsel(s) gebruik gemaakt kan of moet worden. Zo'n PKI-stelsel voorziet in een hiërarchie van organisaties die certificaten uitgeven, zodanig dat de betrouwbaarheid van de certificaten van zo'n organisatie leunt op de betrouwbaarheid van de eerst-hogere organisatie in die hiërarchie, doordat de certificaten van de lagere-in-hiërarchie een handtekening hebben van die van de hogere-in-hiërarchie. Aan de top van zo'n hiërarchie staat een zogenoemde root Certificate Authority (root CA) die zijn betrouwbaarheid niet aan een hogere kan ontlenen, zijn eigen (stam)certificaten tekent, en zo een steunpilaar is van het vertrouwen in het hele betreffende PKI-stelsel. Het MedMij Afsprakenstelsel had ervoor kunnen kiezen een PKI-stelsel specifiek voor MedMij in te richten, maar de kosten daarvan, voor zichzelf en voor haar deelnemers, wegen niet op tegen de voordelen, onder de voorwaarde dat er een ander geschikt PKI-stelsel voorhanden is. Deelnemers zullen met hun services immers ook in andere afsprakenstelsels betrokken kunnen zijn dan dat van MedMij. Zo'n keuze past bovendien niet bij principe P6. Omdat het MedMij-netwerk een nationale en maatschappelijk kritische infrastructuur is, met hoge eisen aan betrouwbaarheid, kiest het MedMij Afsprakenstelsel voor de beveiliging van al het backchannel-verkeer voor het momenteel enige PKI-stelsel waarin de betrouwbaarheid uiteindelijk steunt op een Nederlandse publiekrechtelijke rechtspersoon: PKIoverheid met de Staat der Nederlanden als root CA. Zo is de governance van de root CA transparant en toegankelijk belegd. Het MedMij Afsprakenstelsel bouwt ondermeer voor het door hem aan zijn deelnemers geboden vertrouwen dus mede op het PKIoverheid-stelsel, op het door dat stelsel vastgestelde programma van eisen voor de in dat stelsel betrokken TSP's en op de certificatiehiërarchie voor private G1 certificaten van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past.	core.tls.307
10.	Tijdens de handshake van TLS, wordt door de TLS-server in de `server hello`-stap aan de TLS-client: in geval van backchannel-verkeer, altijd een verzoek om een certificaat gedaan. Indien de TLS-client daarop geen certificaat overlegt, wordt de handshake onmiddellijk afgebroken. in geval van frontchannel-verkeer, nooit een verzoek om een certificaat gedaan. Bij backchannel-verkeer vindt dus twee-wegauthenticatie plaats, bij frontchannel-verkeer een-wegauthenticatie.	core.tls.308
11.	Alle Backchannel Nodes valideren tijdens de TLS-handshake bij backchannel-verkeer aan het begin van een TLS-sessie of het een PKIoverheid-certificaat is en controleren bij de Certification Authority of het ontvangen certificaat geldig is, op basis van CRL of OCSP. In geval van het falen van één van deze controles wordt het certificaat niet geaccepteerd en de TLS-sessie niet gestart.	core.tls.309
12.	In geval van het gebruik van OCSP in het kader van verantwoordelijkheid core.tls.309 mag de OCSP response vastgeniet zitten aan het certificaat (OCSP Stapling). Omdat het vastnieten van OCSP antwoorden (stapling) is toegestaan, zal iedere Node welke een certificaat moet controleren het vastnieten in zoverre moeten ondersteunen dat het alleen het feit dat er een vastgeniet OCSP antwoord gebruikt wordt niet mag leiden tot een foutmelding of het anderszins plots beëindigen van de TLS handshake of sessie. Toelichting 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/domeinen/toegang/aansluiten-als-trust-service-provider.	core.tls.310
13.	Met inachtneming van verantwoordelijkheid core.tls.309, accepteren Backchannel Nodes PKIoverheid certficaten van elkaar door het stamcertificaat van de hiërarchie 'Staat der Nederlanden Private Root CA - G1', zoals gepubliceerd op https://cert.pkioverheid.nl/, te vertrouwen, zolang de geldigheidsdatum niet is verlopen en het stamcertificaat NIET is ingetrokken; Uitzondering Tot 4 december 2022 moeten alle Deelnemers ook de certificaten uit de hiërarchie 'Staat der Nederlanden EV', zoals gepubliceerd op https://cert.pkioverheid.nl/, accepteren. Dit doen zij door ook van deze hiërarchie het stamcertificaat te vertrouwen. Na 4 december 2022 mag dit stamcertificaat niet meer vertrouwd worden.	core.tls.311
14.	PKI-certificaten moeten (in ieder geval op productie en acceptatie omgevingen) als complete keten inclusief alle intermediate certificaten worden verstuurd en gecontroleerd. Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie van het betreffende certificaat. Het root certificaat moet niet meegeleverd worden (dit is al aanwezig in de truststore van de tegenpartij).	core.tls.313

Browser not supported