In ontwikkeling

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:

  • 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 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:

    1. de rol van OAuth Resource Owner wordt verzorgd door de Persoon;
    2. de rol van OAuth Client wordt verzorgd door de DVP Server;
    3. de rol van OAuth Resource Server wordt verzorgd door de Resource Server;
    4. 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:

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 eindverantwoordelijk­heid ook op net­werk-niveau toetsbaar. Zie de drie (ingewikkelde) invarianten bij Aanbie­derGegevensdienst van het soort “niet-lokale afhankelijkheid”.

De uitzondering daarop inzake het frontchannel-verkeer is noodzakelijk om de OAuth Client List te laten functioneren. Het is dus mogelijk voor een DVP Server om verschillende certificaten te hanteren voor frontchannel- en backchannel-verkeer, zolang op de OAuth Client List maar de hostname in het certificaat voor frontchannelverkeer voorkomt die tevens voorkomt in de redirect URI inzake OAuth.


In het Aanbiedersdomein treden alleen de Nodes op in het MedMij-netwerk. Dat wil zeggen dat bijvoorbeeld achterliggende xIS'en niet over het MedMij-netwerk communiceren met de Node. Dat verkeer is verborgen achter de Node. Alle daarvoor benodigde routering wordt afgehandeld door de server-implementaties en speelt zich buiten het zicht van het MedMij Afsprakenstelsel af.

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

 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 GegevensdienstenDe Gegevensdienstnamenlijst voldoet aan wat over haar is bepaald in de 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 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 (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 Opvragen Aanbiederslijst, door middel van het bepaalde inzake het Aanbiederslijstinterface op 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 deelnemenDe Whitelist voldoet aan wat over haar is bepaald in de 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 VersleutelingServer 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 wor­den uitge­voerd 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 specifi­ca­ties van de functies Verzamelen en Delen. Deze vereiste wordt volgordelijkheid genoemd. Indien de contro­le tegen de Whitelist niet kan worden uit­gevoerd, of een negatief resultaat ople­vert, wordt de proces­gang onmiddellijk af­gebroken en komt het niet tot een start van de uit­voering van die eerstvolgende stap. De con­trole tegen de Whitelist slaagt in dit geval dan en slechts dan als op de Whitelist tenmin­ste een van de vol­gende namen uit het de door de TLS-client aange­boden certificaat voorkomen: de Com­mon Name of een van de eventuele Subject Alterna­tive Names.

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.

 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 White­list uit te voeren is in dat geval gedurende de TLS-handshake, tussen de ontvangst van het certificaat van de TLS-client en de voorziene ver­zending van de Finished message. Indien die controle niet kan wor­den uitge­voerd, of een ne­ga­tief resultaat oplevert, wordt dan in plaats van de Finished message de uitzondering access_denied verzonden. Hoewel sectie 7.2.2 van de TLS-spe­cifi­catie voorziet in deze mogelijkheid, voorzien veel standaardimplementaties er niet in. In­grepen in die standaard­im­plementaties zijn soms wel mogelijk, maar kunnen nieuwe beveili­gingsrisico’s met zich meebren­gen, bijvoorbeeld vanwege de complexiteit van het beheren van maatwerk­aanpassingen aan stan­daardimplementa­ties.

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 geauto­riseerd was. Omdat er meerdere manieren zijn om dat ook na afloop van de TLS-hand­shake te imple­men­teren, vereist het MedMij Afspraken­stelsel hiervoor geen vaste architectuur­va­riant (zoals met een re­verse proxy), maar stelt het de vereiste van vol­gordelijkheid, naast een logische scheiding. Deze moe­ten kunnen worden aangetoond door middel van code-inspectie, penetratietesten en in­specties 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:
 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 Informatiemodellen.

core.ocl.101

3.