Samenvatting
Waarom is deze RFC nodig? | Verduidelijken eisen voor de benodigde servercertificaten en DNS-instellingen voor DVP frontends. |
---|---|
Oplossingsrichting | Verduidelijk de eisen voor server/servicecertificaten voor DVP-app's en DVP_portal frondends. Zodat er een duidelijke toetsing/validatie door een auditor en of acceptatie test kan plaatsvidnen en de eisen ook eenvoudiger te controleren zijn. Het gaat dus niet om een nieuwe eis maar om verduidelijking en toelichting bij de bestaande eisen. |
RACI |
|
Aanpassing van | https://afsprakenstelsel.medmij.nl/display/MMOptioneel/Verantwoordelijkheden%2C+Core specifiek deel TLS certificaten |
Impact op rollen | DVP en DVZA |
Impact op beheer | nee |
Impact op RnA | nee |
Impact op Acceptatie | ja mogelijk |
PIA noodzakelijk | nee |
Gerelateerd aan (Andere RFCs, PIM issues) | |
Implementatietermijn | nu 1.5 en 1.6 ev |
Motivatie verkorte RFC procedure (patch) | In eerder sessies met de deelnemers, zie expert sessie 202220220127.Expertgroep is dit ook onderbouwd en grafisch weergegeven. In gespreken met deelnemers blijkt dat het nog onvoldoende scherp is geformuleerd is wat de front-end waar een PKI OV certificaat voor een DVP en ook voor de publieke frontend voor DVZA waar de gebruikers op inloggen. Het gaat daar om frontend URI die eindgebruikers ook daadwerkelijk te zien krijgen en waarbij zij inloggen of hun gegevens omtrent de gezondheid te zien krijgen. Dit kan ook een frontend zijn waar de eindgebruiker zoch moet autenticeren omdat de deelnemer hiervoor een apart frontend URI gebruikt. In het geval van een PGO app krijgt de eindgebruiker deze URI en bijbehorend certificaat niet te zijn maar is de APP het frontend waar de gebruiker mee te maken krijgen. DigiD formuleert het als volgt: "het webbrowsercertificaat van uw webdienst een PKIo certificaat moet zijn" => MedMij het webbrowsercertificaat van uw webdienst minimaal een PKI Organisation Validated certificaat moet zijn. Inclusief aanvullende eisen. |
Uitwerking
Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )
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 |
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 |
---|---|---|---|---|
Bijlagen
Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |