Document toolboxDocument toolbox

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

BeoordelaarDatumReactieToelichting
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:

  1. een reeks van één of meer segmenten, gescheiden door
    1. hetzij één koppelteken,
    2. hetzij één ampersand,
    3. hetzij één punt;
  2. gevolgd door @medmij, waarin
  3. elk segment een reeks van één of meer fragmenten is, zodanig dat
  4. elk fragment bestaat uit een reeks van
    1. minimaal één kleine letter uit het Nederlandse alfabet (bestaande uit de zesentwintig letters a..z),
    2. 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 gebruikt

de 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 geen client_id opneemt in de access token request, accepteert de Authorization Server access token requests zonder én met client_id. In dat tweede geval controleert de Authorization Server bovendien of de client_id overeenkomt met de client_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 de client_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 de client_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 de client_id. In deze release 1.1.2 neemt de Client nog geen client_id op in het access token request, maar wordt de Authorization Server al wel geacht access token requests te accepteren die een client_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:

NummerImplementeert uitzonderingUitzonderingActieMeldingVervolg
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 codeAllen 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

Bijlagen




Nog geen bestanden gedeeld hier.