You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 7
Next »
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:
- Accountable:
- Consulted
- Informed
|
---|
Aanpassing van | Extensie vertegenwoordiging |
---|
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. | |
| 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. | |
|
| 7 | Voor iedere gegevensdienst moet de Dienstverlener aanbieder een unieke endpoint voor de Resource Server registreren in de Stelselnode. | 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 |
|
|