(1.6.0N) Verantwoordelijkheden, Core
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: 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.
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 (1.6.0N) 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:
| 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:
met dien verstande dat:
| core.rollen.207 |
11. | In hetĀ MedMij-netwerkĀ functioneert:
| 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 Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.logging.101. | core.algemeen.100 |
Dossier
1. | Dienstverlener persoon biedt Persoon de functie (1.6.0N) 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. | core.dossier.100 |
2. | 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 usecase betrokken rollen gebruiken hiertoe het betreffende stroomdiagram. | core.dossier.101 |
3. | 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. | core.dossier.102 |
4. | Dienstverlener persoon biedt Persoon de functie Raadplegen dossier om hetĀ persoonlijk gezondheidsdossierĀ te raadplegen. | core.dossier.103 |
5. | In het kader van de functie RaadplegenĀ dossier zal Persoon te allen tijde moeten kunnen nagaan:
| core.dossier.104 |
6. | 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 |
7. | In het kader van de functie Verwijderen gegevens zal Persoon te allen tijde worden geĆÆnformeerd:
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 |
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 (1.6.0N) 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 (1.6.0N) 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:
Zie Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.gegevensdiensten.201 voor de verantwoordelijkheden betreffende technische adressen. | core.alst.100 |
2. | MedMij Beheer beheert en publiceert, in de Aanbiederslijst, unieke en gebruikersvriendelijke namen van Aanbieders, van het formaat | core.alst.101 |
3. | MedMij Beheer biedt aan Dienstverleners persoon een functie ((1.6.0N) 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 (1.6.0N) Opvragen Aanbiederslijst, door middel van het bepaalde inzake het Aanbiederslijstinterface op (1.6.0N) 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 (1.6.0N) 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 | 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. | core.whl.306 |
10. | DeĀ NodeĀ die
| core.whl.307 |
11. | Voor zover de Dienstverlener aanbieder ervoor kiest de controle tegen deĀ WhitelistĀ na afĀloop van de TLS-handshake uit te voeren, is deze controle logisch gescheiĀden van de bedoelde eerstvolgende stap. De vereiste volgordelijkheidĀ kan worĀden aangeĀtoond door middel van code-inspecĀties, penetratietesten en inspecties van logs. | core.whl.308 |
12. | Indien eenĀ Whitelist-controle, in het kader van verantwoordelijkheid Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.whl.307 en Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#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. | 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:
| core.ocl.100 |
2. | De OAuth Client ListĀ voldoet aan wat over haar is bepaald in de (1.6.0N) 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 (1.6.0N) Opvragen OAuth Client List, door middel van het bepaalde inzake het interface voor OAuth Client List op (1.6.0N) 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. | core.ocl.300 |
Ā Gegevensdiensten
1. | Dienstverlener persoon laat Persoon met een Gegevensdienst uit de GegevensdienstnamenlijstĀ 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. | 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Ā toepasĀselijĀke eisen. | core.gegevensdiensten.102 |
4. | Voor elke GegevensdienstĀ waarvan de Aanbiederslijst aanĀgeeft 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. | core.gegevensdiensten.103 |
5. | Het in verantwoordelijkheidĀ Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#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. | core.gegevensdiensten.104 |
6. | 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. | core.gegevensdiensten.200 |
7 | 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 slechts van kracht binnen Ć©Ć©n doorloping van de functie. | 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 (1.6.0N) Verzamelen en Delen handelen DVP Server enerzijds en Authorization Server en Resource Server anderzijds, hun onderlinge verkeer af conform deĀ standaard OAuth 2.0. | core.autorisatie.200 |
4. | Van de vier soorten authorization grants die OAuth 2.0 biedt, beperken de OAuth-rollen zich tot Authorization Code. | core.autorisatie.201 |
5. | De OAuth Client en OAuth Resource Server zullen slechts tokens van het type Bearer-token uitwisselen, conform RFC6750. | core.autorisatie.202 |
6. | DeĀ OAuth Client maakt alleen gebruik van Ć©Ć©n scope tegelijk.Ā De OAuth Authorization Server genereert authorization-codes en access-tokens met een enkelvoudige scope die geheel vervat moet zijn in de Gegevensdienst waarom de OAuth Client heeft gevraagd. | 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). Zij geeft bovendien geen refresh-tokens uit. | core.autorisatie.204 |
8. | DeĀ OAuth Authorization Server genereert authorization-codes en access-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 |
7. | In de authorization-codes en access-tokens is het desgewenst toegestaan Ć©Ć©n of meer van de informatie-elementen uit de volgende limitatieve lijst op te nemen:
| core.autorisatie.206 |
9. | Geen andere informatie dan de in verantwoordelijkheid 7 genoemde mag voorkomen in de authorization-code of het acces-token, ook niet versleuteld. Er mogen t.a.v. informatie-inhoud van het token verschillende keuzes gemaakt worden tussen authorization-code en access-token. DeĀ OAuth Client mag de inhoud van het token niet interpreteren. | core.autorisatie.207 |
10. | Met betrekking tot zowel authorization-codes als access-tokens, draagt de OAuth Authorization Server die hen uitgeeft ervoor zorg, dat daarvan nooit twee dezelfde geldige in omloop zijn. | core.autorisatie.208 |
11. | Access-tokens worden alleen uitgegeven na controle van de client_id, de opgegeven autorisatie-code en de Common name van het in de TLS verbinding gebruikte certificaat. De controles worden uitgevoerd conform:
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 |
12. | Het OAuth-client type van de OAuth Client is confidential. | core.autorisatie.210 |
Authenticatie
1. | Dienstverlener aanbieder draagt ervoor zorg dat de onder Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.gegevensdiensten.103, Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.gegevensdiensten.104, Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.autorisatie.100 en Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#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:
| core.adressering.201 |
3. | In alle adressering op het authorization interface, het token interface en het resource interface is het gebruik van het voorĀ | 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 (1.6.0N) Opvragen Aanbiederslijst,Ā (1.6.0N) Opvragen OAuth Client List enĀ (1.6.0N) Opvragen Gegevensdienstnamenlijst geadresseerd met de hostname stelselnode.medmij.nl . | core.adressering.204 |
Beveiliging
1. | In het gegevensverkeer voor de functies (1.6.0N) Verzamelen, Delen, (1.6.0N) Opvragen Aanbiederslijst, (1.6.0N) Opvragen OAuth Client List en (1.6.0N) 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. | core.beveiliging.201 | |||||||||||||||||||||||||||||||||||||||||||||||||||
3. | DeĀ OAuth Client realiseert de volgende beveiligingsmaatregelen, conformĀ RFC 6819:
| core.beveiliging.202 | |||||||||||||||||||||||||||||||||||||||||||||||||||
4. | DeĀ OAuth Client realiseert de volgende beveiligingsmaatregelen, conformĀ RFC 6819:
| core.beveiliging.203 | |||||||||||||||||||||||||||||||||||||||||||||||||||
5. | De OAuth Authorization Server realiseert de volgende beveiligingsmaatregelen, conformĀ RFC 6819:
| 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. | core.beveiliging.205 |
Logging
1. | Dienstverlener persoon zal het logbestand inrichten zoals bedoeld in de AVGĀ en NEN 7513:2018, van de door enige Persoon bij enige Dienstverlener aanbieder uitgevoerde functies. | core.logging.100 |
2. | De bewaartermijn van de logbestanden is ten minste 24 maanden en niet meer dan 36 maanden. Na de bewaartermijn van de logbestanden moeten deze vernietigd worden. | 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. | core.logging.200 |
4. | Bij hetĀ loggen van ontvangen resource requestsĀ neemt de OAuth Resource Server ook het MedMij-Request-ID Header Field op in het logbestand. | core.logging.201 |
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:
| 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 (1.6.0N) Informatiemodellen en heeft de technische vorm van een XML-document, dat voldoet aan het XML-schema dat op de paginaĀ (1.6.0N) XML-schema's te vinden is. | 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. | core.dns.301 |
TLS en certificaten
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 Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.tls.301kan 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. | 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 Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.tls.302 geldt, in afwijking van Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#core.tls.301:
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.
| 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:
| 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. | core.tls.307 |
10. | Tijdens de handshake van TLS, wordtĀ door de TLS-server in deĀ
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 Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#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. | core.tls.310 |
13. | Met inachtneming van verantwoordelijkheid Verantwoordelijkheden, Core#Verantwoordelijkheden, Core#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 |