RFC0069 Losse functiebeschrijvingen voor authenticeren en autoriseren
Samenvatting
Waarom is deze RFC nodig? | In het kader van meer gebruiksvriendelijkheid in de toekomst moet het mogelijk zijn als gebruiker om met 1 x autoriseren meerdere gegevensdiensten bij meerdere aanbieders bij verschillende DVA's op te halen. |
---|---|
Oplossingsrichting | De rollen Resource Server en Authorization Server worden van elkaar gescheiden. De processen worden apart beschreven. |
RACI | |
Aanpassing van | Processen los van elkaar beschrijven in versie 1.6 |
Impact op rollen | DVA |
Impact op beheer | N.v.t. |
Impact op RnA | N.v.t. |
Impact op Acceptatie | N.v.t. |
PIA noodzakelijk | N.v.t. |
Gerelateerd aan (Andere RFCs, PIM issues) | |
Implementatietermijn | AF 1.6 |
Motivatie verkorte RFC procedure (patch) | N.v.t. |
2. Uitwerking epic
3. Wijzigingen afsprakenstelsel
. Principe's
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal |
| 11Â Stelselfuncties worden vanaf de start ingevuld |
|
2 Dienstverleners zijn transparant over de gegevensdiensten |
| 12Â Het afsprakenstelsel is een groeimodel |
|
3Â Dienstverleners concurreren op de functionaliteiten |
| 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders |
|
4Â Dienstverleners zijn aanspreekbaar door de gebruiker |
| 14Â Uitwisseling is een keuze |
|
5Â De persoon wisselt gegevens uit met de zorgaanbieder |
| 15Â Het MedMij-netwerk is gebruiksrechten-neutraal |
|
6Â MedMij spreekt alleen af wat nodig is |
| 16Â De burger regisseert zijn gezondheidsinformatie als uitgever |
|
7Â De persoon en de zorgaanbieder kiezen hun eigen dienstverlener |
| 17Â Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld |
|
9Â De dienstverleners zijn deelnemers van het afsprakenstelsel |
| 18Â Afspraken worden aantoonbaar nageleefd en gehandhaafd |
|
10Â Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling |
| 19Â Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat |
|
Toelichting |
5. 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 |
---|---|---|---|---|
6. Bijlagen
Nog geen bestanden gedeeld hier.
- Sleep hier je bestanden naartoe of bladerenÂ
7. Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |
Samenvatting
Waarom is deze RFC nodig? | In het kader van meer gebruiksvriendelijkheid in de toekomst moet het mogelijk zijn als gebruiker om met 1 x autoriseren meerdere gegevensdiensten bij meerdere aanbieders bij verschillende DVA's op te halen. |
---|---|
Oplossingsrichting | De rollen Resource Server en Authorization Server worden van elkaar gescheiden. De processen worden apart beschreven. |
RACI | |
Aanpassing van | Processen los van elkaar beschrijven in versie 1.6 |
Impact op rollen | DVA |
Impact op beheer | N.v.t. |
Impact op RnA | N.v.t. |
Impact op Acceptatie | N.v.t. |
PIA noodzakelijk | N.v.t. |
Gerelateerd aan (Andere RFCs, PIM issues) | |
Implementatietermijn | AF 1.6 |
Motivatie verkorte RFC procedure (patch) | N.v.t. |
2. Uitwerking epic
3. Wijzigingen afsprakenstelsel
. Principe's
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal |
| 11Â Stelselfuncties worden vanaf de start ingevuld |
|
2 Dienstverleners zijn transparant over de gegevensdiensten |
| 12Â Het afsprakenstelsel is een groeimodel |
|
3Â Dienstverleners concurreren op de functionaliteiten |
| 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders |
|
4Â Dienstverleners zijn aanspreekbaar door de gebruiker |
| 14Â Uitwisseling is een keuze |
|
5Â De persoon wisselt gegevens uit met de zorgaanbieder |
| 15Â Het MedMij-netwerk is gebruiksrechten-neutraal |
|
6Â MedMij spreekt alleen af wat nodig is |
| 16Â De burger regisseert zijn gezondheidsinformatie als uitgever |
|
7Â De persoon en de zorgaanbieder kiezen hun eigen dienstverlener |
| 17Â Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld |
|
9Â De dienstverleners zijn deelnemers van het afsprakenstelsel |
| 18Â Afspraken worden aantoonbaar nageleefd en gehandhaafd |
|
10Â Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling |
| 19Â Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat |
|
Toelichting |
5. 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 |
---|---|---|---|---|
6. Bijlagen
Nog geen bestanden gedeeld hier.
- Sleep hier je bestanden naartoe of bladerenÂ
7. Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |