...
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 vertegenwoordigingVerantwoordelijkheden 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;
Expand |
---|
| 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
|
|
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 opgevraagd.Zie core.gegevensdiensten.201 voor de verantwoordelijkheden betreffende technische adressen. |
Expand |
---|
| 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
|
|
|
7 | Voor iedere gegevensdienst moet de Dienstverlener aanbieder een unieke endpoint voor de Resource Server registreren in MedMij Registratie. | Anchor |
---|
| core.gegevensdiensten.201 |
---|
| core.gegevensdiensten.201 |
---|
| 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.
...