Samenvatting

Waarom is deze RFC nodig?	Verduidelijken eisen voor de benodigde servercertificaten en DNS-instellingen voor DVP frontends. In de expertsessie is duidelijk gemaakt wat er met een frontend verbinding wordt bedoeld maar voor app's is dit anders. In dat geval krijgt een eindgebruiker het gebruikte server/servicecertificaat totaal niet te zien.
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	Responsible: PDM Accountable: $RFC_RACI_Accountable Consulted Ontwikkelteam (ontwikkeling@medmij.nl) Security Management (secmgt@medmij.nl) Acceptatie (acceptatie@medmij.nl) Stelselregie Deelnemers (Expertgroepsessie) Informed Communicatie Loket (info@medmij.nl) Leveranciersmanagement
Aanpassing van	https://vzvz.atlassian.net/wiki/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 zien maar is de APP het frontend waar de gebruiker mee te maken krijgen. Daar zal ook voorde frontend duidelijk moeten zijn dat DVP frontend waar gebruiker inlogt en via dit webinterface zijn gegevens te zien krijgt. 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 )

In de relevante eisen voor core functionaliteiten opnemen als toelichting:

/wiki/spaces/MMVerplicht/pages/132023217

Hierbij ook middels een figuur gebruikt tijdens de expertsessie duidelijk maken dat hier ook frontend verkeer mee wordt bedoeld.

Toelichting bij core.tls.315. Deze eis geldt voor de PGO frontend die een eindgebruiker ook daadwerkelijk te zien krijgt en kan verifieren op inhoud. Dit maakt het voor PGO's die als app zijn geimplementeerd niet mogelijk omdat de 'frontend' de daadwerkelijk app op de smartphone is.

De eis voor de PGO front end moet geinterpreteerd worden voor de PGO's die aangeboden via een website/portal de eindgebruiker kan daar direct het servercertifcaat zien. Indien er gebruikt wordt gemaakt van een authentiecatieservice en deze voor meerdere diensten wordt gebruikt kan dit een servercertificaat zijn waarbij de organisatie niet de betreffende deelnemer betreft. Dit dient dan wel duidelijk te worden in de flow voor het aanmelden/inloggen.

In het geval van een app:

Door het toevoegen van deze figuren en als toelichting bij interfaces en eis core.tls.315 wordt duidelijk waar de eisen tbv PKI OV certificaten gelden.

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

	File	Modified
Labels No labels Preview View	PNG File image2022-9-28_16-26-59.png	Sept 28, 2022 by schmidt
Labels No labels Preview View	PNG File image2022-9-28_16-29-23.png	Sept 28, 2022 by schmidt
Labels No labels Preview View	PNG File image2022-9-28_16-41-39.png	Sept 28, 2022 by schmidt

Download All

Goedkeuring

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

Browser not supported