Overwegingen

Applicaties en niet gebruikers

In Koppeltaal worden de rollen en rechten op de FHIR resources toegekend aan de applicatie-instanties in een domein, en niet aan de individuele gebruiker die van de applicatie gebruik maakt. Dit is in de kern een legacy probleem, omdat Koppeltaal 1.x nauwelijks een security model heeft, en het model dat er is, is gebaseerd op applicaties en hun rol in het domein. De keuze om hier niet wezenlijk een ander model in te voeren is meerledig, namelijk:

1. Koppeltaal 2.0 dient zoveel mogelijk de bestaande functionaliteit van Koppeltaal 1.x te vervangen, en juist geen nieuwe toe te voegen.

2. De huidige applicaties hebben, door het ontbreken van een geëlaboreerd security model in Koppeltaal 1.x, zelf inmiddels een eigen securitymodel ontwikkeld. Om hier een geünificeerd model van te maken die voor alle bestaande applicatie werkt ligt voor nu buiten scope.

3. Kijkende naar de toekomst van Koppeltaal lijkt een persoonlijk toegangsmodel onontkoombaar, de vraag is bij welke ontwikkeling en/of standaard het beste aangesloten kan worden. Een vraag die afhankelijk is van een nog te ontwikkelen visie.

Vertrouwen gedelegeerd & centraal

Een Koppeltaal domein bestaat uit een aantal applicatie-instanties die ieder in hun eigen rol met elkaar samenwerken om de Use Cases (TODO: link) van Koppeltaal te realiseren. In deze samenwerking, die als kern gegevensuitwisseling kent, is onderling vertrouwen essentieel. In Koppeltaal wordt voor een gedelegeerd vertrouwensmodel gekozen. Binnen het domein is er één enkele autoriteit die bepaalt wat een applicatie mag en kan, en vertrouwen de applicaties die in het domein toetreden deze autoriteit. Hiermee wordt het vertrouwen gedelegeerd en centraal in het domein belegd.

Identiteit en identificatie

Een applicatie binnen een domein maakt zichzelf kenbaar door een identiteit. Deze identiteit kent een cryptografische manifestatie die gefundeerd is in cryptografisch bewijs. In Koppeltaal wordt gewerkt met publieke en private sleutelparen. De houder van een private sleutel publiceert de publieke sleutel als verificatiemiddel. Door een verzameling gegevens te ondertekenen met de private sleutel kan de ontvanger met de publieke sleutel onomstotelijk bewijzen dat de ondertekenaar de eigenaar van de private sleutel is. Om die reden gaan we ervan uit dat het sleutelpaar, de combinatie van publieke en private sleutel de identiteit van de applicatie-instantie is.

Geheimhouding en vertrouwen

Om dit systeem van private en publieke sleutels goed te laten werken, zijn de volgende voorwaarden van toepassing:

...

• Het toe te staan dat meerdere sleutelparen actief zijn, dit zodat de actor in het domein de sleutels zo geheim mogelijk te maken. Zo hoeven ze niet in de infrastructuur gedeeld te worden.

• Het mogelijk te maken sleutelparen direct te kunnen publiceren en intrekken. Dit kent twee voordelen:

  • Applicatie-instanties (POD of VDSVirtuele Machine) kunnen bij het opstarten een sleutelpaar genereren, publiceren en gelijk gebruiken.

  • Snelle rotatie van sleutelparen mitigeert mogelijk verliezen of lekken van de private sleutels.

De uitwisseling van sleutels

De uitwisseling van de sleutels is de kern van het vertrouwensmodel. Dit topic wordt in detail besproken inTOP-KT-020 - Uitwisseling publieke sleutels. In Koppeltaal wordt dat met voorkeur geregeld via JWKS URLs. Per applicatie-instantie binnen het domein wordt een URL gepubliceerd waar een lijst van actieve sleutels in wordt bijgehouden. Een sleutelpaar kan in gebruik worden genomen door een publieke sleutel aan de lijst van publieke sleutels aan het JWKS endpoint toe te voegen, een sleutelpaar kan per direct worden uitgefaseerd door deze van deze lijst te verwijderen.

De JWKS URL wordt in het applicatiebeheer geconfigureerd. De autorisatie service maakt van deze URLs gebruik voor het identificeren en authenticeren van de applicatie-instanties en het valideren van JWK JWT tokens van applicatie-instanties binnen het domein. Dit kent een aantal voordelen:

...

• Het systeem leunt sterk op de DNS, een DNS overname van een applicatie-instantie vormt een reëel gevaar. Om die reden wordt ook geadviseerd om de JWKS URL niet een “well-known“ URL te laten zijn.

• De verantwoordelijkheid voor het intrekken van compromitteerde sleutels ligt bij de applicatie-instanties.

Overzicht van het vertrouwensmodel

Het vertrouwensmodel van Koppeltaal bestaat uit de volgende logische onderdelen.

Sleutelparen

Een applicatie-instantie genereert één of meerdere sleutelparen, het private deel dient geheim te worden gehouden. Het publieke deel dient gedeeld te worden.

Acceptatie

Een applicatie-instantie treedt een domein toe door de JWKS URL of publiek sleutel te registeren bij domeinbeheer.

Publicatie

Een applicatie-instantie deelt kan zijn actieve publieke sleutels door middel van JWKS op een geconfigureerde JWKS URL beschikbaar te makendelen. De publieke sleutels die op de JWKS URL beschikbaar worden gemaakt dienen enkel de sleutels te zijn die in gebruik zijn. Het terugtrekken van een sleutel gebeurt door deze niet langer op de JWKS url beschikbaar te maken.

Identificatie en verificatie

Een applicatie-instantie bewijst zijn authenticiteit door het ondertekenen van een JWT token met een private sleutel. De autorisatie service valideert deze door de publieke sleutel op te zoeken in het JWKS URL dat de applicatie-instantie publiceert. Het JWT token kent een kid header die moet overeenkomen met de key ID van de publieke sleutel die gepubliceerd is op de JWKS URL.

Gedelegeerd vertrouwen

De applicatie-instanties in het domein kunnen door middel van het introspection endpoint alle tokens die in het domein gebruikt worden valideren. Dit zijn:

...

Voorsorteren op de toekomst

Het zal niemand ontgaan zijn dat er op het gebied van vertrouwensnetwerken veel aan de hand is in Nederland, in de Kamerbrief over landelijk dekkend netwerk infrastructuren wordt dan ook onomwonden het volgende advies gegeven:

...

De keuzes die gemaakt zijn bij de ontwikkeling van het Koppeltaal standaard is zoveel mogelijk voorgesorteerd en geanticipeerd op de ondersteuning van DIDs en VCs. Zo bevat de access_token van de autorisatie service voor de FHIR resource service de toegangsrestricties in een Domain Specific Language (DSL), om zo de introductie van VCs niet in de weg te zitten.

Toepassing, restricties en eisen

Het vertrouwensmodel wordt in de volgende topics besproken:

...