RFC0004 Architectuurschuld 1.1.2
Samenvatting
Waarom is deze RFC nodig? | In release 1.1.2 zijn een aantal issues en wijzigingen bewust niet opgenomen of ingezet waarbij er nog een tweede afrondende wijziging nodig is. Deze RFC is een verzamelbak voor deze wijzigingen. |
---|---|
Oplossingsrichting | Uitvoeren van lijst van kleine wijzigingen in Afsprakenstelsel die wel nodig zijn, maar geen echte samenhang of verband hebben. |
Aanpassing van | Afsprakenstelsel |
Impact op rollen | Alle |
Impact op beheer | Geen tot beperkt |
Gerelateerd aan (Jira issues) | |
Eigenaar | Arjan |
Implementatietermijn | 1.2.0 |
Motivatie verkorte RFC procedure (patch) | NvT |
Goedkeuring
Beoordelaar | Datum | Reactie | Toelichting |
---|---|---|---|
Productmanager | |||
Ontwerpteam | |||
? |
Principe's
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | NvT | 11 Stelselfuncties worden vanaf de start ingevuld | NvT |
2 Dienstverleners zijn transparant over de gegevensdiensten | NvT | 12 Het afsprakenstelsel is een groeimodel | NvT |
3Â Dienstverleners concurreren op de functionaliteiten | NvT | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | NvT |
4Â Dienstverleners zijn aanspreekbaar door de gebruiker | NvT | 14Â Uitwisseling is een keuze | NvT |
5Â De persoon wisselt gegevens uit met de zorgaanbieder | NvT | 15Â Het MedMij-netwerk is gebruiksrechten-neutraal | NvT |
6Â MedMij spreekt alleen af wat nodig is | NvT | 16Â De burger regisseert zijn gezondheidsinformatie als uitgever | NvT |
7Â De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | NvT | 17Â Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | NvT |
9Â De dienstverleners zijn deelnemers van het afsprakenstelsel | NvT | 18Â Afspraken worden aantoonbaar nageleefd en gehandhaafd | NvT |
10Â Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | NvT | 19Â Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | NvT |
Uitwerking
Nav https://vzvz.atlassian.net/browse/AF-1049:Â
Op pagina Zorgaanbiedersnamenbeleid aanpassen:
.7
De naam wordt geregistreerd in kleine letters; De naam wordt geregistreerd (ook in de Zorgaanbiederslijst) in het volgende formaat:
- een reeks van één of meer segmenten, gescheiden door
- hetzij één koppelteken,
- hetzij één ampersand,
- hetzij één punt;
- gevolgd doorÂ
@medmij
, waarin- elk segment een reeks van één of meer fragmenten is, zodanig dat
- elk fragment bestaat uit een reeks van
- minimaal één kleine letter uit het Nederlandse alfabet (bestaande uit de zesentwintig lettersÂ
a..z
),- gevolgd door een reeks van maximaal vier Arabische cijfers (
0..9
)..8
De naam mag alleen bestaan uit karakters die voorkomen in het Nederlandse alfabet (bestaande uit zesentwintig letters). Diakrieten, speciale tekens (zoals spatie, koppelteken en punt) zijn dus niet toegestaan;Â Van de naam mogen, buiten de registratie, varianten voorkomen waarin een kleine letter is vervangen door de corresponderende hoofdletter en/of diakritische varianten van letters voorkomen. Deze lettervarianten worden echter als identiek gezien aan de kleine basisletter. De naam is dus niet hoofdletter-gevoelig en evenmin diacriet-gevoelig.
Nav https://vzvz.atlassian.net/browse/AF-1044:
Op pagina Token interface aanpassen:
client_id
niet gebruiktde hostname van de Node van de OAuth Client die de authorization request deed die de nu aangeboden authorization code opleverde
Zie de toelichting bij verantwoordelijkheid 1b.De OAuth 2.0-specificatie stelt deze parameter niet verplicht indien de OAuth Client zich authenticeert, hetgeen in het MedMij Afsprakenstelsel gebeurt door middel van mutual TLS. En de noodzaak van het gebruik ervan wordt beperkt door verantwoordelijkheid 4 op deze pagina, die borgt dat het access token alleen wordt verstrekt aan de OAuth Client aan wie de OAuth Resource Owner toestemming heeft verleend. In hoofdstuk 2 van een Internet-Draft ter zake wordt echter gesteld dat deÂ
client_id
 toch gebruikt moet worden ingeval mutual TLS wordt gebruikt. Dat laatste is het geval in het MedMij Afsprakenstelsel (zie Netwerk-laag).
1b. Hoewel de Client geenclient_id
opneemt in de access token request, accepteert de Authorization Server access token requests zonder én metclient_id
. In dat tweede geval controleert de Authorization Server bovendien of declient_id
overeenkomt met declient_id
die hij heeft ontvangen in de authorization request op basis waarvan hij de authorization code heeft uitgegeven die in deze access token request wordt aangeboden. Als deze controle faalt, behandelt de Authorization Server dit conform uitzondering 'Token interface 1' uit verantwoordelijkheid 6 en wel met de error responseÂinvalid_client
.
Client_id in access token request
De OAuth 2.0-specificatie stelt declient_id
niet verplicht in de access token request indien de OAuth Client zich authenticeert, hetgeen in het MedMij Afsprakenstelsel inderdaad gebeurt door middel van mutual TLS. De noodzaak van het gebruik van deze parameter wordt bovendien beperkt door verantwoordelijkheid 4 op deze pagina. In hoofdstuk 2 van een Internet-Draft ter zake wordt niettemin gesteld dat declient_id
 gebruikt moet worden wanneer mutual TLS wordt gebruikt. Dat laatste is het geval in het MedMij Afsprakenstelsel (zie Netwerk-laag).
Daarom bereidt het MedMij Afsprakenstelsel zich voor op het verplicht stellen van declient_id
. In deze release 1.1.2 neemt de Client nog geenclient_id
op in het access token request, maar wordt de Authorization Server al wel geacht access token requests te accepteren die eenclient_id
bevatten en daar dan ook op te controleren. In een volgende release wordt beoogd de parameter verplicht te gaan stellen.
Op pagina Token interface aanpassen:
Bij punt .6 huidige tabel vervangen door onderstaande:
Nummer Implementeert uitzondering Uitzondering Actie Melding Vervolg Token interface 1 UC Verzamelen 6
UC Delen 6
Authorization Server moet vanwege één van de in de OAuth 2.0-specificatie, par. 5.2, genoemde redenen de token request weigeren. Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover. met de conform OAuth 2.0-specificatie, par. 5.2, toepasselijke error code Allen stoppen de flow van de UCI Verzamelen/UCI Delen onmiddellijk na geïnformeerd te zijn over de uitzondering. Token interface 2 UC Verzamelen 3
UC Delen 3
Authorization Server stelt tijdens de afhandeling van de token request vast dat:
- in geval van UCI Verzamelen: van Persoon bij Zorgaanbieder geen gezondheidsinformatie voor die Gegevensdienst beschikbaar is.
- in geval van UCI Delen: Zorgaanbieder niet ontvankelijk is voor die Gegevensdienst van Persoon.
Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.
Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Zorggebruiker dat diens verzoek geen voortgang kan vinden, maar laat de oorzaak daarvan helemaal in het midden. conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied
, met in de error description "Access denied.
"
Op pagina Logische modellen de verwijzingen naar 'portnummer' verwijderd (in 1.1.2 zijn poortnummers op 'standaard' gezet):
In tabel 'Logische invarianten':
- Rij 'ResourceEndpoint':  , r.ResourceEndpointport verwijderd
- Rij 'TokenEndpoint':Â , t.TokenEndpointport verwijderd
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.
* Wijzigingen moeten stuk voor stuk nagelopen worden en gecheckt of ze ook impact hebben op Acceptatie
* Kans op fouten bij deze aanpak (RFC als kapstok voor verzameling wijzigingen) groot