Use Cases Autorisatie Server GBC
Overzicht Autorisatie Server GBC
Onderstaande figuur toont een overzicht van de interfaces en services van de Autorisatie Server GBC component.
Autorisatie Server GBC is verantwoordelijk voor:
Het opleveren van metadata aan GBC Clients.
Het beantwoorden van token requests van GBC Clients.
De services zijn toegankelijk via een geboden interface en worden beschreven in de vorm van use cases.
Opleveren Metadata
Primaire actor | GBC Client |
|---|---|
Systeem | Autorisatie Server GBC |
Secundaire actor | - |
Code | |
Realiseert Feature |
Pre-condities
Triggers
Main flow
Post-condities
Uitgeven AORTA access_token
Primaire actor | GBC Client |
|---|---|
Systeem | Autorisatie Server GBC |
Secundaire actor | ZORG-AB, Autorisatie Server ZA, AORTA Stelselnode, GBC Client |
Code | |
Realiseert Feature |
Pre-condities
De primaire actor is aangesloten op het systeem. |
De primaire actor heeft de benodigde Verifiable Presentations geproduceerd. |
Het systeem is slechts benaderbaar voor
|
Triggers
De primaire actor stuurt een token exchange request in.
Het systeem beschikt over up-to-date gegevens betreffende de ondersteunde interacties.
Main flow
Stap | Omschrijving | Uitkomst |
|---|---|---|
1 | Het systeem ontvangt een verzoek en start de verwerking. | |
2 | Het systeem controleert of het ontvangen request voldoet aan de AORTA interface specificaties zoals gedefineerd in de betreffende feature. Deze toets omvat niet de inhoudelijke controles van de | Ongeldig verzoek statuscode 400 Bad Request, error=invalid_request |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
3 | Het systeem toetst de ontvangen Zie ook de sectie Vulling error_description voor informatie over hoe een eventueel benodigde | Assertion ongeldig statuscode 400 Bad Request, error=invalid_grant |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
4 | Het systeem toetst de ontvangen Zie ook de sectie Vulling error_description voor informatie over hoe een eventueel benodigde | Client_assertion ongeldig statuscode 400 Bad Request, error=invalid_client |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
5 | Het systeem bepaalt de | Scope ongeldig statuscode 400 Bad Request, error=invalid_scope |
Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow. | ||
6 | Het systeem gebruikt Feature GetTokenRequest om een AORTA access_token te verkrijgen. Hierbij worden de volgende attributen gebruikt:
| |
7 <exit> | Het systeem retourneert een response naar de primaire actor. |
Post-condities
Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd. |
Het systeem heeft van het ontvangen request, de volgende attributen gelogd:
== Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:
|
Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:
== Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:
|
Toelichtingen
Toetsing assertion
Het systeem voert alle algemene verificaties uit van de verifiable presentation zoals beschreven in Verificatie van verifiable presentations.
Het systeem voert alle algemene verificaties uit van de verifiable credentials zoals beschreven in Verificatie van verifiable credentials.
Verder wordt als volgt geverifieert:
Het systeem MOET vaststellen dat de in de VP opgenomen VC’s gezamenlijk één consistente en niet-tegenstrijdige autorisatiecontext beschrijven. Indien VC’s niet onderling consistent zijn, MOETEN deze worden afgewezen.
Alle opgenomen VC’s MOETEN verwijzen naar dezelfde zorgaanbieder (URA).
Het HealthcareProviderCredential
credentialSubject.identifierMOET overeenkomen met het HealthcareProfessionalDelegationCredentialhasDelegation.issuedBy.identifier, indien aanwezig.Het HealthcareProviderCredential
credentialSubject.identifierMOET overeenkomen met het PatientEnrollmentCredentialhasEnrollment.issuedTo.identifier, indien aanwezig.
HealthcareProviderCredential specifieke verificaties:
Het
vc.typeMOETHealthcareProviderCredentialbevatten.Het pastype in de
issclaim MOET gelijk zijn aanS.
HealthcareProfessionalDelegationCredential specifieke verificaties:
Het
vc.typeMOETHealthcareProfessionalDelegationCredentialbevatten.De issuer van het credential MOET een zorgprofessional met een
did:x509‑identiteit zijn.Het pastype in de
issclaim MOET gelijk zijn aanZ(zorgverlenerspas).De
hasDelegation.scope.authorizationRuleMOET een geldige autorisatie‑scope hebben welke een subset is van de bevoegdheden die aan de zorgaanbieder zelf zijn toegekend.Indien een verloopdatum is opgenomen, MOET deze voor de
expires‑datum van de signing key zijn.
PatientEnrollmentCredentialspecifieke verificaties:
Het
vc.typeMOETPatientEnrollmentCredentialbevatten.Het pastype in de
issclaim MOET gelijk zijn aanZ(zorgverlenerpas) ofN(Medewerkerspas op naam).De geldigheidsduur van het credential MAG maximaal 18 maanden bedragen.
Indien een verloopdatum is opgenomen, MOET deze voor de
expires‑datum van de signing key zijn.
Toetsing client_assertion
Het systeem voert alle algemene verificaties uit van de verifiable presentation zoals beschreven in Verificatie van een Verifiable Presentation.
Het systeem voert alle algemene verificaties uit van de verifiable credentials zoals beschreven in Verificatie van een Verifiable Credential.
Verder wordt als volgt geverifieert:
Het systeem MOET vaststellen dat de presenterende partij (
vp.iss) bevoegd is om elke opgenomen VC te presenteren, op basis van cryptografische binding en stelselafspraken.
ServiceProviderCredential specifieke verificaties:
Het
vc.typeMOETServiceProviderCredentialbevatten.De issuer van het credential MOET de stelselhouder zijn.
De issuer DID MOET een
did:web‑identiteit zijn.De signing key MOET voorkomen in de
assertionMethodvan het DID‑document van de issuer.De
services‑claim MOET ten minste één dienst bevatten die binnen het stelsel is gedefinieerd.Het credential is geldig zolang de stelseltoelating van de dienstverlener geldig is.
ServiceProviderDelegationCredential specifieke verificaties:
Het
vc.typeMOETServiceProviderDelegationCredentialbevatten.De issuer van het credential MOET een zorgaanbieder zijn.
De issuer DID MOET een
did:web‑identiteit zijn.Het credential is geldig zolang de delegatie niet is ingetrokken en de stelseltoelating van de dienstverlener geldig is.
Binding client_assertion met assertion:
De ServiceProviderDelegationCredential
hasDelegation.issuedBy.identifierMOET overeenkomen met de HealthcareProviderCredentialidentifier.
Verificatie van een Verifiable Presentation
Het systeem verifieert de presentation als volgt:
De presentation MOET voldoen aan de specificaties van de betreffende presentation, inclusief eventuele de normatieve structuur en inhoudelijke eisen zoals gedefinieerd.
Daarnaast MOETEN de onderstaande verificaties plaatsvinden. Indien één van de onderstaande verificaties faalt MOET de presentation als ongeldig beschouwd. Het systeem MAG stoppen bij de eerste geconstateerde fout en hoeft niet alle verificaties uit te voeren.
Verificatie van de JWT-signature:
De JWT‑handtekening MOET cryptografisch correct zijn en succesvol valideren over de JWT header en payload.
De presentation MOET zijn ondertekend door de presenterende partij.
De
kid‑claim in de JWT header MOET aanwezig zijn en verwijst naar de signing key waarmee de presentation is ondertekend.Het DID‑document van de presenterende partij (
iss) MOET worden geresolveerd conform de toepasselijke DID‑methode.Het bijbehorende DID-document MOET gepubliceerd zijn over TLS 1.3 of hoger op een
.nl‑domein.De
kidMOET voorkomen in de authentication verification relationship van het DID‑document van de presenterende partij. Dekidmag verwijzen naar:een verification method in hetzelfde DID‑document, of
een verification method in een ander DID‑document.
De publieke sleutel behorend bij de
kidMOET resolvable zijn:indien de
kidverwijst naar een lokale verification method, wordt de bijbehorende sleutel gebruikt.indien de
kidverwijst naar een externe verification method, wordt het betreffende DID‑document geresolveerd en wordt daaruit de publieke sleutel opgehaald.
De JWT‑handtekening van de presentation MOET met de geresolveerde publieke sleutel geverifieerd worden.
Verificatie van de audience‑binding:
De waarde van
audMOET exact overeenkomen met de identifier van het verifiërende systeem.
Verificatie van geldigheid in tijd:
De presentation MOET geldig zijn op het moment van gebruik:
het
nbf‑tijdstip MOET in het verleden liggen,het
exp‑tijdstip MOET in de toekomst liggen.
Verificatie deelname GBC:
De presenterende partij (
iss) MOET worden vastgesteld als een vertrouwde GBC‑deelnemer. Op termijn zal deze controle uitgevoerd worden door een controle in ZORG-AB. Vooralsnog zal de controle worden uitgevoerd tegen een interne lijst van vertrouwde GBC deelnemers.
Verificatie hergebruik presentation:
De presentation MOET niet eerder zijn gebruikt in de context van een OAuth token request.
Verificatie van een Verifiable Credential
Het systeem verifieert de credential als volgt:
De credential MOET voldoen aan de specificaties van de betreffende credential, inclusief eventuele de normatieve structuur en inhoudelijke eisen zoals gedefinieerd.
Daarnaast moeten de volgende verificaties plaatsvinden. Indien één van de onderstaande verificaties faalt wordt de credential als ongeldig beschouwd. Het systeem MAG stoppen bij de eerste geconstateerde fout en hoeft niet alle verificaties uit te voeren.
Verificatie van de JWT-signature:
De JWT signature MOET cryptografisch correct zijn en succesvol valideren over de JWT header en payload.
De credential MOET zijn ondertekend door de issuer van de VC zoals geïdentificeerd in de
issclaim van de JWT payload.
Verificatie van DID en sleutelbinding
Het DID‑document van de issuer van de credential MOET worden geresolveerd conform de toepasselijke DID‑methode.
De signing key waarmee de credential is ondertekend MOET via de
kid‑claim herleidbaar zijn tot het DID‑document van de issuer.De signing key MOET voorkomen in de
assertionMethodvan het DID‑document van de issuer.De issuer DID van de credential MOET een geaccepteerde trust anchor bevatten, passend bij het type credential. Het type trust anchor is afhankelijk van het credential‑type.
Verificatie van sleutelgeldigheid:
De signing key MOET worden geresolveerd via key‑resolutie, waarbij de
nbfvan het credential als referentietijdstip wordt gebruikt.De signing key MOET geldig zijn geweest op het referentietijdstip en MAG NIET verlopen of ingetrokken zijn vóór de
issuanceDatevan het credential.
Verificatie van geldigheid in tijd:
De credential MOET geldig zijn op het moment van gebruik.
De credential MAG NIET herroepen zijn. Deze controle wordt vooralsnog niet uitgevoerd.
Indien
vc.credentialStatusaanwezig is, MOET de revocatiestatus worden gecontroleerd.
Verificatie deelname GBC:
De identiteit van de credential issuer (
iss) MOET worden vastgesteld als een vertrouwde GBC‑deelnemer. Op termijn zal deze controle uitgevoerd worden door een controle in ZORG-AB. Vooralsnog zal de controle worden uitgevoerd tegen een interne lijst van vertrouwde GBC deelnemers.
Voor de did:web credentials (ServiceProviderCredential en ServiceProviderDelegationCredential) gelden additionele controles:
did:web specifieke validaties:
Het domein dat wordt gebruikt in een did:web identifier moet een top-level domain hebben met voldoende betrouwbaarheid en juridische afdwingbaarheid. Binnen AORTA is het gebruik van het .nl verplicht. Dit waarborgt dat domeinnamen vallen onder Nederlands recht en dat de SIDN als registerhouder voldoende garanties biedt ten aanzien van eigenaarschap en geschilbeslechting.
Vulling error_description
Bij fouten in het token request wordt een error response geretourneerd conform RFC 6749 sectie 5.2. Additioneel wordt het error_description gevuld met een menselijke leesbare toelichting om ontwikkelaars te ondersteunen in het begrijpen van de voorgevallen error.
Minimaal moeten de volgende mogelijke fouten worden ondersteund en worden voorzien van een passende error_description:
VP is ongeldig (handtekening, structuur of audience, verlopen, ingetrokken, issuer niet vertrouwd);
VP bevat niet vereiste VC’s (specificeer het type VC);
Een VC wordt gepresenteerd door een organisatie die niet bevoegd is om dit credential te presenteren;
Een VC is ongeldig (handtekening, structuur, verlopen, ingetrokken, issuer niet vertrouwd) (specificeer het type VC);
De delegatierelatie tussen dienstverlener en zorginstelling is ongeldig of ontbreekt.
In een error_description mogen de volgende typen gegevens NIET worden opgenomen:
inhoud van VC’s of VP’s;
persoonsgegevens;
URA-, BSN- of UZI-nummers;
interne beleidsregels of beslislogica.
Bepalen scope
Het systeem MOET vaststellen dat hetscope in het getTokenRequest is toegestaan binnen de autorisatiecontext die wordt beschreven door de assertion en client_assertion. De VP’s en opgenomen VC’s MOETEN gezamenlijk één consistente en niet‑tegenstrijdige autorisatiecontext vormen, volgens de verificaties hieronder gedefinieerd. Indien één van de onderstaande verificaties faalt, MOET de scope worden afgewezen. Het systeem MAG stoppen bij de eerste geconstateerde fout en hoeft niet alle verificaties uit te voeren.
De opgegeven
gbc.contextcode.<code>uit descopeparameter MOET een ondersteunde GBC‑use‑case aanduiden.Alle aangeleverde clinical data scopes in de
scopeMOETEN een subset zijn van deservicesvan het ServiceProviderCredential.Alle aangeleverde clinical data scopes in de
scopeMOETEN een subset zijn van dehasDelegation.scope.authorizedActionsvan het ServiceProviderDelegationCredential, indien aanwezig.Alle aangeleverde clinical data scopes in de
scopeMOETEN een subset zijn van dehasDelegation.scope.authorizedActionsvan het HealthcareProfessionalDelegationCredential, indien aanwezig.Indien de scope patiëntgebonden SMART‑on‑FHIR scopes bevat (bijv. "patient/*"), MOET een geldig PatientEnrollmentCredential aanwezig zijn. De patiëntidentifier in de scope MOET overeenkomen met de
hasEnrollment.patient.identifierzoals opgenomen in het PatientEnrollmentCredential.
Indien de ontvangen scope geldig is bevonden MOET de scope parameter van het getTokenRequest worden gevuld met exact dezelfde scope-string als ontvangen in het oorspronkelijke verzoek.