RFC0004 Architectuurschuld 1.1.2

Samenvatting

Goedkeuring

Principe's

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:

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

Bijlagen

Nog geen bestanden gedeeld hier.