Publish Box goes here

Actoren en vertrouwen

Actoren en vertrouwen

Protocolrollen

Actor	Organisatie	Verantwoordelijkheid
Clientsysteem	URA-A, raadplegende zorgaanbieder	bronhouder vinden, client assertion en RAR maken, token aanvragen en controleren, resource aanroepen
Authorization server	URA-B, bronhoudende zorgaanbieder	client- en certificaatcontrole, autorisatiebeleid, DPoP-tokenbinding en tokenuitgifte
FHIR resource server	URA-B, bronhoudende zorgaanbieder	access token, DPoP en resourcepolicy opnieuw controleren en FHIR verstrekken
Vertrouwensvoorziening	gedeelde vertrouwenslaag	organisatie koppelen aan issuer, tokenendpoint, resourcebasis, JWKS en certificaatgegevens
Certificaatstatusvoorziening	gedeelde vertrouwenslaag	actuele status van het relevante certificaat leveren

Eén product mag meerdere rollen combineren, maar de verantwoordelijkheden en controles blijven logisch gescheiden. Het profiel schrijft dus geen specifieke applicatie- of deploymentarchitectuur voor.

Organisatie en systeem

De organisatie is het subject van de grensoverschrijdende authenticatie. Een clientsysteem treedt namens URA-A op en bewijst bezit van geregistreerde cryptografische sleutels.

Dat bewijs zegt niets over de individuele zorgprofessional. URA-A blijft verantwoordelijk voor:

• lokale gebruikersauthenticatie;
• bevoegdheid en mandatering;
• behandelrelatie, toestemming en doelbinding;
• beveiligd sleutelgebruik door het clientsysteem.

URA-B combineert het technische organisatiebewijs met haar eigen autorisatiebeleid voordat zij toegang verleent.

Vertrouwde discovery

Het clientsysteem begint met de identiteit van de doelorganisatie, niet met een willekeurige URL uit een bericht. De vertrouwde registratie levert één samenhangende set:

• organisatie-identificatie;
• issuer;
• tokenendpoint;
• resourcebasis;
• JWKS-URI;
• relevante certificaatidentifiers.

Profielregel: endpoints en sleutels die tijdens de flow worden gebruikt moeten herleidbaar zijn tot dezelfde vertrouwde organisatieregistratie. Een netwerkresponse mag niet stilzwijgend een nieuw trustanker introduceren.

Sleutelvertrouwen

Een geldige handtekening bewijst alleen dat de bijbehorende privésleutel is gebruikt. De registratie geeft betekenis aan de publieke sleutel:

flowchart LR
    ORG["Organisatie-identiteit"]
    REG["Vertrouwde registratie"]
    META["Issuer, endpoints, JWKS<br/>en certificaatgegevens"]
    SIGNATURE["Gevalideerde handtekening"]
    PROOF["Bewijs van de<br/>geregistreerde organisatie"]

    ORG --> REG --> META --> SIGNATURE --> PROOF

JWKS-ophaling moet daarom via de geregistreerde URI en een gevalideerde TLS-verbinding plaatsvinden. Een kid of publieke JWK uit het onbetrouwbare bericht is onvoldoende om vertrouwen te vestigen.

Certificaatstatus

Certificaatketenvalidatie tijdens mTLS en actuele certificaatstatus zijn afzonderlijke controles. Een certificaat kan correct zijn uitgegeven maar inmiddels ingetrokken zijn.

Open ontwerpkeuze: de productiebron, actualiteit en foutsemantiek voor certificaatstatus moeten landelijk worden vastgesteld. De referentie-implementatie gebruikt good, revoked en unknown in een lokale testvoorziening.

Referentie-implementatie

In de code vervult ReceivingAdapter de rol van clientsysteem. Dat is een voorbeeldarchitectuur, geen profielvereiste. De authorization server, FHIR resource server en trustservices draaien als afzonderlijke lokale Ktor-rollen, zodat iedere grensovergang en controle zichtbaar kan worden gemaakt.