RFC0064 (Patch), AF-1329 Gebruik publieke certificaten in afsprakenstelsel 1.4
Samenvatting
Waarom is deze RFC nodig? | PKIOverheid stopt per 4 december 2022 met het aanbieden van publieke certificaten. Bij al het frontchannel verkeer binnen MedMij, alsmede mogelijk bij een deel van het backchannel verkeer, wordt gebruiktgemaakt van deze publieke (EV) certificaten. |
---|---|
Oplossingsrichting | Deelnemers moeten voor 4 december 2022 overgestapt zijn naar andere publieke certificaten voor frontchannel verkeer. Deze certificaten moeten aan een nieuwe set van eisen voldoen, die zijn overgenomen uit de beleidslijnen van VWS. Daarnaast moeten publieke certificaten die gebruikt worden voor backchannel verkeer vervangen worden door PKIoverheid private (G1) certificaten. |
RACI |
|
Aanpassing van | Afsprakenstel versie 1.4 |
Impact op rollen | MedMij Beheer, DVP, DVA |
Impact op beheer | Bestaand proces moet gevolgd worden. |
Impact op RnA | Bestaand proces moet gevolgd worden. |
Impact op Acceptatie | Proces blijft hetzelfde, controle op de certificaten wordt net wat anders. |
PIA noodzakelijk | |
Gerelateerd aan (Andere RFCs, PIM issues) | |
Motivatie verkorte RFC procedure (patch) | Binnen een jaar zijn de publieke certificaten van PKIoverheid niet meer te gebruiken. Het is van belang de deelnemers in het aankomende jaar goed te begeleiden en te informeren. Om de deelnemers goed voor te bereiden op deze wijziging, is daarom gekozen een wijziging door te voeren op de versies 1.4 en 1.5 van het afsprakenstelsel. |
Uitwerking epic
Wijzigingen afsprakenstelsel
In de architectuur van het afsprakenstelsel wordt een overzicht gegeven van de rollen op de verschillende lagen. Hierbij wordt ook PKIOverheid TSP genoemd. Omdat PKIOverheid nu niet meer alle certificaten zal aanbieden, moet dit aangepast worden. Hiervoor zijn drie opties:
- Voor PKI TSP wordt een generieke rol beschreven, waarin de aanbieder niet meer genoemd wordt. Dit heeft als voordeel dat het rollenmodel niets zegt over implementatie en altijd te hanteren is. In de verantwoordelijkheden moet/kan wel naar specifieke partijen (bijvoorbeeld PKIoverheid) verwezen worden, om hiermee aan de eis te kunnen voldoen dat PKIoverheid nog wel de leverancier is van de backchannel-certificaten.
- Naast PKIOverheid TSP benoemen we een tweede, meer generieke, rol, voor het leveren van frontchannel-certificaten. In de verantwoordelijkheden worden voor de verschillende rollen de zaken verduidelijkt.
- In het rollenmodel worden de verwijzingen naar TSP volledig verwijderd. Dit is conform de aanpak in 1.5.0. De keuze is hierbij TSP weg te laten, omdat PKI een stelsel is waarvan MedMij gebruikmaakt. Het heeft niet een speciale rol, anders dan benoemd kan worden in de verantwoordelijkheden betreffende nodes en verkeer. De impact op het model is echter wel groot, omdat de TSP rol op netwerk niveau gekoppeld is met functies en gegevens. Deze moeten ook anders ingericht worden.
Om de impact op deze versie van het afsprakenstelsel zo klein mogelijk te houden, wordt gekozen voor de eerste optie. Dit betekent dat in het rollenmodel de verwijzing naar PKIoverheid TSP vervangen wordt door Trust Service Provider. Dit moet ook op de verschillende lagen worden doorgevoerd. In de verantwoordelijkheden zal wel verwezen worden naar PKIOverheid, omdat dit voor het backchannelverkeer de enige infrastructuur is om te gebruiken.
Architectuur en technische specificaties
Huidige inhoud | Nieuwe inhoud |
---|---|
Juridica
Huidige inhoud | Nieuwe inhoud |
---|---|
In deze laag staan de juridische rollen, als juridische basis voor de rollen op andere lagen van de architectuur. De reden dat deze laag in deze architectuur is opgenomen is dat haar rollen voor de samenhang tussen de verschillende architectuurlagen zorgen en de architectuur geborgd moet zijn in de juridische rollen in het MedMij Afsprakenstelsel. Bij een juridische rol horen verplichtingen voor het spelen van rollen op verschillende architectuurlagen. De rollen die we hier in de architectuur noemen vallen uiteen in twee groepen:
In de architectuur van het afsprakenstelsel heeft de Persoon een operationele rol bij authenticatie en autorisatie van het gegevensverkeer. De Zorgaanbieder wordt operationeel geheel vertegenwoordigd door de Dienstverlener Zorgaanbieder. | In deze laag staan de juridische rollen, als juridische basis voor de rollen op andere lagen van de architectuur. De reden dat deze laag in deze architectuur is opgenomen is dat haar rollen voor de samenhang tussen de verschillende architectuurlagen zorgen en de architectuur geborgd moet zijn in de juridische rollen in het MedMij Afsprakenstelsel. Bij een juridische rol horen verplichtingen voor het spelen van rollen op verschillende architectuurlagen. De rollen die we hier in de architectuur noemen vallen uiteen in twee groepen:
In de architectuur van het afsprakenstelsel heeft de Persoon een operationele rol bij authenticatie en autorisatie van het gegevensverkeer. De Zorgaanbieder wordt operationeel geheel vertegenwoordigd door de Dienstverlener Zorgaanbieder. |
Applicatie
Huidige inhoud | Nieuwe inhoud |
---|---|
De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKIoverheid-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling. | De OAuth Client en OAuth Authorization Server gebruiken voor al hun onderlinge verkeer PKI-certificaten, en wel servercertificaten, ten behoeve van de authenticatie van de andere server in een uitwisseling. |
Netwerk
Huidige inhoud | Nieuwe inhoud |
---|---|