Publish Box goes here

End-to-end flow

End-to-end flow

Deze pagina brengt de eerder beschreven bewijzen samen. Zie voor de afzonderlijke regels vertrouwen, clientauthenticatie, autorisatie en DPoP en transport.

Sequentie

sequenceDiagram
    autonumber
    participant CLIENT as Clientsysteem URA-A
    participant TRUST as Vertrouwensvoorziening
    participant AUTH as Authorization server URA-B
    participant RESOURCE as Resource server URA-B

    CLIENT->>TRUST: Resolveer URA-B
    TRUST-->>CLIENT: Registratie, endpoints en publieke sleutels
    CLIENT->>CLIENT: Maak client assertion, RAR en token-DPoP
    CLIENT->>AUTH: mTLS-tokenverzoek
    AUTH->>TRUST: Resolveer client, JWKS en certificaatstatus
    TRUST-->>AUTH: Vertrouwde clientgegevens
    AUTH->>AUTH: Valideer identiteit, RAR en DPoP
    AUTH-->>CLIENT: Getekend en DPoP-gebonden access token
    CLIENT->>CLIENT: Valideer issuer, claims, RAR, aud en cnf.jkt
    CLIENT->>CLIENT: Maak resource-DPoP met htm, htu, jti en ath
    CLIENT->>RESOURCE: mTLS FHIR GET + access token + DPoP
    RESOURCE->>RESOURCE: Valideer token, policy en resource-DPoP
    RESOURCE-->>CLIENT: FHIR-response over mTLS
    CLIENT->>CLIENT: Registreer eigen audit
    RESOURCE->>RESOURCE: Registreer eigen audit

Fase 1 — Vertrouwde bestemming

Vraag: bij welke organisatie hoort de gewenste resource en waar bevinden zich haar beveiligingsendpoints?

Bewijs: één vertrouwde registratie bindt URA-B aan issuer, tokenendpoint, resourcebasis, JWKS en certificaatgegevens.

Beslissende controle: alle later gebruikte URI's en keys moeten tot diezelfde registratie herleidbaar zijn.

Fase 2 — Lokale voorbereiding

Het clientsysteem bouwt drie afzonderlijke artefacten:

1. een client assertion voor identiteit, met de authorization-server-issuer als audience;
2. een RAR voor resource, doelorganisatie en gebruiksdoel;
3. een DPoP-proof voor bezit van de sleutel die aan het token wordt gebonden.

Deze artefacten mogen niet inhoudelijk worden samengevoegd. De assertion tekent bijvoorbeeld niet automatisch de losse RAR-formparameter.

Fase 3 — Tokenaanvraag

POST /oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
DPoP: [compact proof verwijderd]

grant_type=client_credentials
&client_id=2.16.528.1.1007.3.3.11111111
&resource=https://fhir.example.org/fhir/bgz
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=[compact JWT verwijderd]
&authorization_details=[nl-gis-v1 JSON]

Het request loopt over mTLS. De authorization server controleert eerst clientcertificaat, status en assertion, daarna RAR-policy en token-DPoP. De volgorde mag intern verschillen, maar een token wordt alleen uitgegeven als alle onafhankelijke controles slagen.

Fase 4 — Geaccepteerde autorisatie

De authorization server tekent niet blind de ontvangen RAR. Zij neemt de geaccepteerde details op in het access token, stelt de resource als aud in en bindt het token via cnf.jkt aan de DPoP-key.

Het resultaat is een verklaring van URA-B over:

• de identiteit van URA-A als client;
• de exacte resource;
• de geaccepteerde autorisatiedetails;
• de sleutel die het token mag gebruiken;
• de beperkte geldigheidsduur.

Fase 5 — Controle door het clientsysteem

Het clientsysteem valideert handtekening en claims tegen de eerder vertrouwde registratie en eigen requestcontext. Dit voorkomt dat een geldig getekend token voor een andere issuer, client, resource, doelorganisatie of DPoP-key wordt gebruikt.

Deze controle is een expliciete profielregel in deze uitwerking. Zij vervangt de latere resource-servercontrole niet.

Fase 6 — Resource-aanroep

GET /fhir/bgz HTTP/1.1
Authorization: DPoP [access token verwijderd]
DPoP: [requestspecifieke proof verwijderd]

De resourceproof gebruikt dezelfde DPoP-key en bindt methode, exacte URI en access token aan een verse jti. De resource server controleert token, autorisatiepolicy en proof opnieuw voordat de FHIR-response over mTLS wordt teruggestuurd.

Fase 7 — Gescheiden verantwoording

URA-A registreert de uitgaande aanvraag en ontvangen uitkomst. URA-B registreert tokenuitgifte, resourcebeslissing en dataverstrekking. Een gedeelde correlatie-id kan onderzoek ondersteunen, maar beide organisaties blijven verantwoordelijk voor hun eigen beveiligde auditspoor.