Overwegingen

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 bepaald 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 VDS) 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. In koppeltaal wordt dat 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.

...

• 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 binnen een domein toe door de JWKS URL te registeren bij domeinbeheer.

Publicatie

Een applicatie-instantie deelt zijn actieve publieke sleutels door middel van JWKS op een geconfigureerde JWKS URL beschikbaar te maken. 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:

...