Versions Compared

Old Version 2

changes.mady.by.user Martin Wilmink

Saved on

compared with

New Version Current

changes.mady.by.user Casper van der Harst

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

1.Eigenaar MedMij neemt de functionele rol van MedMij Beheer op zich. Er is één Eigenaar MedMij die één MedMij Beheer speelt.

Anchor
core.rollen.100
core.rollen.100
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.

Anchor
core.rollen.101
core.rollen.101
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.

Anchor
core.rollen.200
core.rollen.200
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 in combinatie met een Resource Server.

Anchor
core.rollen.201
core.rollen.201
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.

Anchor
core.rollen.202
core.rollen.202
core.rollen.202

6.Persoon gebruikt één geautomatiseerde rol User Agent voor toegang tot de functionaliteit van DVP Server en Authorization Server. User Agentpresenteert de functionaliteit aan Persoon, spreekt DVP Server aan en verwijst de Persoon naar de Authorization Server.

Anchor
core.rollen.203
core.rollen.203
core.rollen.203

7.MedMij Beheer ontsluit ten behoeve van alle betrokkenen een geautomatiseerde rol, hier genoemd: MedMij Registratie.

Anchor
core.rollen.204
core.rollen.204
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.

Anchor
core.rollen.205
core.rollen.205
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.
Expand
titleToelichting

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.


Anchor
core.rollen.206
core.rollen.206
core.rollen.206

10.

Als MedMij-verkeer is gedefinieerd: al het gegevensverkeer in het kader van enige usecase-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 usecase-implementaties, telkens inbegrepen zijn de Nodes waarop zij functioneren.

Anchor
core.rollen.207
core.rollen.207
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.
Expand
titleToelichting

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.


Anchor
core.rollen.300
core.rollen.300
core.rollen.300

12.
Op één Node functioneert hetzij één Authorization Server, hetzij één Resource Server, hetzij een combinatie van voorgaande rollen.

Anchor
core.rollen.301
core.rollen.301
core.rollen.301

...

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;
Note

De technische adressen van een Dienstverlener aanbieder moeten uniek zijn per gegevensdienst. Bij ieder verzoek vanuit een Dienstverlener persoon kan de Dienstverlener aanbieder hiermee eenvoudig bepalen welke gegevensdienst wordt opgevraagdZie core.gegevensdiensten.201 voor de verantwoordelijkheden betreffende technische adressen.


Expand
titleToelichting

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.


Anchor
core.alst.100
core.alst.100
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.

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


Anchor
core.alst.101
core.alst.101
core.alst.101

3.MedMij Beheer biedt aan Dienstverleners persooneen functie (Opvragen Aanbiederslijst) om de actuele versie van die Aanbiederslijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

Anchor
core.alst.102
core.alst.102
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.

Anchor
core.alst.200
core.alst.200
core.alst.200

5.DVP Server betrekt minstens elke vijftien minuten (900 seconden) de meest recente Aanbiederslijst van MedMij Registratie.

Anchor
core.alst.201
core.alst.201
core.alst.201

6.DVP Server valideert elke nieuw verkregen Aanbiederslijst tegen het XML-schema van de Aanbiederslijst.

Anchor
core.alst.202
core.alst.202
core.alst.202

...

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.

Expand
titleToelichting

Een Gegevensdienst is een op een specifieke en gestandaardiseerde set gezondheidsinformatie gerichte dienst waarmee Dienstverlener aanbieder zulke informatie ontsluit naar Dienstverlener persoon in het kader van de functie Verzamelen of Dienstverlener aanbieder zulke informatie geplaatst krijgt ten behoeve van een Aanbieder. In de Gegevensdienstnamenlijst zijn de Gegevensdiensten opgenomen die op enig moment worden aangeboden, maar de Catalogus is de autoriteit daarvoor.


Anchor
core.gegevensdiensten.100
core.gegevensdiensten.100
core.gegevensdiensten.100

2.

Elke Dienstverlener aanbieder ontsluit op elk moment minstens één Gegevensdienst.

Expand
titleToelichting

Het ontsluiten van een Gegevensdienst door een Dienstverlener aanbieder is, in deze versie van het MedMij Afsprakenstelsel, hetzij in het kader van 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.


Anchor
core.gegevensdiensten.101
core.gegevensdiensten.101
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.

Expand
titleToelichting
Omdat er een indirectie speelt, via de Dienstverlener aanbieder naar de Aanbieder, moet gezegd worden dat één Aanbieder genoeg is (die een bepaalde Gegevensdienst ontsluit) om ervoor te zorgen dat de Dienstverlener aanbieder zich voor die Informatiestandaard moet kwalificeren in het MedMij Afsprakenstelsel.


Anchor
core.gegevensdiensten.102
core.gegevensdiensten.102
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 /wiki/spaces/MMCatalogus/overview staan genoemd als Vereist bij eerstgenoemde Gegevensdienst.

Expand
titleToelichting
Net als verantwoordelijkheid core.gegevensdiensten.102, moet ook vanuit deze verantwoordelijkheid rekening houden met de indirectie via Dienstverlener aanbieder naar de Aanbieder zelf. Deze regel legt het bij de Dienstverlener aanbieder om ervoor zorg te dragen dat de Aanbieder met wie hij een dienstverleningsovereenkomst heeft, ook de Gegevensdienst levert die hij toegezegd heeft.


Anchor
core.gegevensdiensten.103
core.gegevensdiensten.103
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.

Expand
titleToelichting
Zo wordt ervoor ruimte geboden dat na-ijlende sessies, die nog gebruik maken van de verstrijkende versie van de Aanbiederslijst, nog kunnen worden afgemaakt.


Anchor
core.gegevensdiensten.104
core.gegevensdiensten.104
core.gegevensdiensten.104

6.

Als een Dienstverleners persooneen zekere Gegevensdienst ontsluit ten behoeve van zijn Personen en daartoe laat leveren door een Dienstverlener aanbieder, zullen de DVP Servervan die Dienstverlener persoonen de Authorization Serveren Resource Servervan die Dienstverlener aanbiederdaarvoor 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.


Anchor
core.gegevensdiensten.200
core.gegevensdiensten.200
core.gegevensdiensten.200

7.Voor iedere gegevensdienst moet de Dienstverlener aanbieder een unieke endpoint voor de Resource Server registreren in de Stelselnode MedMij Registratie.

Anchor
core.gegevensdiensten.201
core.gegevensdiensten.201
core.gegevensdiensten.201

...

1.In het gegevensverkeer voor de functies Verzamelen, Delen, Opvragen Aanbiederslijst, Opvragen OAuth Client List en Opvragen Gegevensdienstnamenlijst, maken betrokken rollen gebruik van de functies Versleuteling, Server Authentication en Server Authorization, zoals beschreven onder TLS en certificaten.

Anchor
core.beveiliging.200
core.beveiliging.200
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.

Expand
titleToelichting

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 tehnologielaag: authenticatie van servers en versleuteling, waarmee de vertrouwelijkheid en integriteit van de inhoud van het gegevensverkeer wordt geborgd.


Anchor
core.beveiliging.201
core.beveiliging.201
core.beveiliging.201

3.

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

beveiligingsmaatregelparagraaf 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.134.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.24.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.54.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


Anchor
core.beveiliging.202
core.beveiliging.202
core.beveiliging.202

4.

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

beveiligingsmaatregelparagraaf 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.44.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.14.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.124.4.1.12
Client developers and end users can be educated to not follow untrusted URLs.4.4.1.84.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.64.4.1.9
Explain the scope (resources and the permissions) the user is about to grant in an understandable way5.2.4.24.2.2


Anchor
core.beveiliging.203
core.beveiliging.203
core.beveiliging.203

5.

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

beveiligingsmaatregelparagraaf in RFC6819gemitigeerde risico('s)
Authorization servers should consider such attacks: Password Phishing by Counterfeit Authorization Server4.2.14.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.114.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.124.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.134.4.1.13
Best practices for credential storage protection should be employed.5.1.4.14.4.1.2
Enforce system security measures.5.1.4.1.14.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.44.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.54.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


Anchor
core.beveiliging.204
core.beveiliging.204
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.

Expand
titleToelichting

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.


Anchor
core.beveiliging.205
core.beveiliging.205
core.beveiliging.205

...