Credentials Common

Introductie

Verifiable Credentials (VC’s) worden gebruikt als gestandaardiseerde, cryptografisch verifieerbare bewijzen om context te leveren over organisaties, applicaties, zorgprofessionals en patiënten. VC's maken het mogelijk om dergelijke claims op een betrouwbare, herleidbare en machine‑verifieerbare wijze over te dragen. VC's worden ingezet ter ondersteuning van authenticatie en autorisatie voorafgaand aan de uitgifte van AORTA access_tokens en maken zij geen onderdeel uit van de FHIR‑interactie zelf. De toepassing van VC’s is gebaseerd op het W3C Verifiable Credentials Data Model toegepast in JWT‑encoding.

VCs worden gemodelleerd conform het W3C Verifiable Credentials Data Model en geserialiseerd als JWT (VC‑JWT). De VC heeft een JWT Header, JWT Payload en JWT Signature zoals hieronder gedefineerd.

Decentralized Identifiers

Decentralized Identifiers (DID’s) worden gebruikt op basis van de W3C DID Core. DID's hebben het doel om de identiteit van organisaties die VC's uitgeven of presenteren eenduidig en cryptografisch vast te stellen. DID’s vormen de basis voor het herleiden van cryptografische sleutels en het verifiëren van handtekeningen op VC’s en Verifiable Presentations (VP's).

De structuur en semantiek van DID Documents worden hier niet gedefinieerd, maar volgen rechtstreeks uit de W3C DID Core‑standaard. Op basis hiervan worden eisen gesteld aan gebruik en verificatie van VC's en VP's. Aan een DID wordt geen semantische betekenis toegekend anders dan via gevalideerde VC’s. De DID zelf mag niet worden geïnterpreteerd als bewijs van rol, bevoegdheid of domeinbinding.

Er worden twee vormen van DID’s ondersteund: did:x509 en did:web.

Een did:x509‑identiteit is gebaseerd op een bestaand X.509‑certificaat en ontleent zijn betrouwbaarheid aan de onderliggende PKI‑keten, zoals PKIoverheid en UZI‑certificaten, en wordt primair gebruikt voor zorginstellingen en zorgprofessionals.

Een did:web‑identiteit is gekoppeld aan een internetdomein en wordt ontsloten via een DID‑document over HTTPS. Deze vorm wordt ingezet voor dienstverleners en applicaties, en vertrouwt op DNS, TLS en aanvullende afspraken.

Het domein dat wordt gebruikt in een did:web‑identiteit moet een top-level domain hebben met voldoende betrouwbaarheid en juridische afdwingbaarheid. Hierbij 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.

Door beide identiteitsvormen te ondersteunen, wordt aangesloten op bestaande zorginfrastructuur én op moderne, web‑gebaseerde architectuurprincipes.

JWT header van een VC

DID:x509

De JWT header van deze VC bevat de volgende velden:

Voorbeeld did:x509 JWT header

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "did:x509:0:sha256:WE4P5dd8DnLHSkyHaIjhp4udlkF9LqoKwCvu9gl38jk::subject:O:Autoriteit::san:otherName:00000000#0",
  "x5c": [
    "",
    "",
    ""
  ],
  "x5t#S256": "WE4P5dd8DnLHSkyHaIjhp4udlkF9LqoKwCvu9gl38jk"
}

DID:web

De JWT Header van deze Verifiable Credential bevat de volgende velden:

Voorbeeld did:web JWT header

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "did:web:huisarts-delinden.nl#keys-1"
}

JWT Payload van een VC

De JWT Payload van deze Verifiable Credential bevat de volgende velden:

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.

JWT signature van een VC

De JWT Signature van een Verifiable Credential borgt de integriteit en herkomst van de JWT en de daarin opgenomen VC. De JWT signature MOET worden geplaatst over de base64url‑gecodeerde JWT header en payload conform JWS (RFC 7515).

• De JWT MOET worden ondertekend door de issuer van de VC.

• De issuer van het credential wordt geïdentificeerd via de iss‑claim in de JWT payload.

• De kid‑claim in de JWT header MOET verwijzen naar de signing key waarmee de JWT is ondertekend.

• De signing key MOET overeenkomen met het leaf-certificaat waarmee de JWT is ondertekend.

• De relatie tussen de signing key en de issuer MOET worden vastgesteld via validatie van de X.509-certificaatketen tegen geaccepteerde PKI-trust anchors (zoals PKIoverheid en UZI).

• De signing key MOET zijn gepubliceerd als een verificationMethod in het DID-document van de issuer.

• De signing key MOET geautoriseerd zijn voor gebruik als assertionMethod binnen het DID-document van de issuer.

• De relatie tussen de signing key en de issuer MOET worden vastgesteld door resolutie en validatie van het DID-document via HTTPS.

Toetsing van een Verifiable Credential

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 iss claim 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 assertionMethod van 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 issuanceDate van 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.credentialStatus aanwezig 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.

• 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.

Toetsing van het credentialSubject

DID van het subject.

Indien aanwezig: MOET gelijk zijn aan de sub claim.