Samenvatting

Waarom is deze RFC nodig?	Door de introductie van Gebruikersvriendelijke autorisatie Fase 1 is duidelijk geworden dat deelnemers voor meerdere gegevensdiensten dezelfde endpoint gebruiken. Dit konden zij doen, omdat de gegevensdienst geïdentificeerd kon worden uit de scope van het access-token. Echter, daarin worden nu mogelijk meerdere gegevensdiensten meegegeven, waardoor identificatie vanuit het access-token niet meer mogelijk is.
Oplossingsrichting	Tijdens een expertgroepsessie is dit onderwerp behandeld en er werd geconcludeerd dat het gebruik van unieke endpoints per gegevensdienst de enige juiste weg is. Hoewel dit een verantwoordelijkheid is van de deelnemers zelf, moet hierover wel een tekst worden toegevoegd in het afsprakenstelsel.
RACI	Responsible: Team ontwikkeling Accountable: Product Management Consulted Deelnemers Communicatie Informed Loket (info@medmij.nl) Leveranciersmanagement Acceptatie (acceptatie@medmij.nl) Security Management (secmgt@medmij.nl) Stelselregie
Aanpassing van	Verantwoordelijkheden MedMij Core
Impact op rollen	DVA
Impact op beheer	-
Impact op RnA	-
Impact op Acceptatie	-
PIA noodzakelijk	-
Gerelateerd aan (Andere RFCs, PIM issues)	-
Implementatietermijn	1.5.1 (Verduidelijking), 1.6.0

Uitwerking

Oud

Nieuw

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;

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

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

7

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

core.gegevensdiensten.201

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen
-	-	-	-	-

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
Productmanager Stichting MedMij			Productmanager Beheerorganisatie
Leadarchitect Stichting MedMij			Leadarchitect Beheerorganisatie
Ontwerpteam
Deelnemersraad			Eigenaarsraad

Browser not supported