Netherlands - Generic Functions for data exchange Implementation Guide - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

ServiceProviderDelegationCredential

ServiceProviderDelegationCredential

The ServiceProviderDelegationCredential proves that a healthcare provider authorizes a service provider to act on its behalf within a defined authorization scope. It records the delegation from a healthcare provider to a service provider and is consumed before an access token is issued.

It confirms delegation, not system authorization; the system authorization of the service provider is carried by the ServiceProviderCredential.

Overview

Purpose: Assert that a healthcare provider has authorized a service provider to act on its behalf, within the scope of an authorization rule from the applicable agreement framework (afspraakstelsel).

Issuer: did:web of the healthcare provider that delegates the authority.

Subject: did:web of the service provider receiving the delegation.

Status: draft

Data model: W3C Verifiable Credentials Data Model 1.1

VC type: ["VerifiableCredential", "ServiceProviderDelegationCredential"]

Proof type: JWT

Signature algorithm: ES256 (recommended), ES512 or PS256

Revocation method: Bitstring Status List v1.0 via the optional credentialStatus field (not currently used).

Proof of Possession: presenter is holder: the identifier of the presenter MUST equal the credential subject identifier.

Trust anchors: the healthcare provider that issues the delegation. Framework-specific issuer and trust requirements are defined per agreement framework; see Agreement framework specifics.

Background

This credential records that a healthcare provider has delegated a defined set of authorized actions to a service provider. It confirms the delegation, not the system authorization of the service provider, which is carried by the ServiceProviderCredential.

The credential names the delegating healthcare provider (hasDelegation.issuedBy) by its URA number. The binding between that URA number and the issuer did:web of the healthcare provider must be established through a HealthcareProviderCredential presented in the same Verifiable Presentation.

The set of valid values for authorizationRule and authorizedActions is determined by the applicable agreement framework (afspraakstelsel); see Agreement framework specifics for the AORTA definitions.

Attributes

All fields below are scoped to credentialSubject.

Semantic relations

The credential expresses the following entity model:

graph TD
    VC[ServiceProviderDelegationCredential]
    VC -->|issuer| ISSUER["did:web (healthcare provider)"]
    VC -->|credentialSubject| SP["ServiceProvider"]
    SP -->|id| SPID["did:web:dienstverlener.example.nl"]
    SP -->|hasDelegation| DEL["Delegation"]
    DEL -->|issuedBy| HP["HealthcareProvider"]
    HP -->|identifier| HPID["Identifier"]
    HPID -->|system| HPSYS["http://fhir.nl/fhir/NamingSystem/ura"]
    HPID -->|value| HPVAL["12345678 (URA)"]
    DEL -->|scope| SCOPE["DelegationScope"]
    SCOPE -->|authorizationRule| RULE["https://aorta.example.nl/authorizations/gtk"]
    SCOPE -->|authorizedActions| ACTIONS["[tokenRequest, presentCredentials]"]

JSON-LD Context

The credential uses the GIS JSON-LD context.

Example credential

The following is a non-normative example of a ServiceProviderDelegationCredential using the W3C Verifiable Credentials Data Model 1.1 JWT encoding, using values from the AORTA agreement framework (see Agreement framework specifics). It asserts that the healthcare provider with URA 12345678 has authorized the service provider did:web:dienstverlener.example.nl to perform the actions tokenRequest and presentCredentials.

JWT Header:

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

JWT Payload:

{
  "iss": "did:web:zorginstelling.example.nl",
  "sub": "did:web:dienstverlener.example.nl",
  "jti": "urn:uuid:4c2a1f3e-9a5b-4f90-8d3e-abcdef123456",
  "nbf": 1740000000,
  "exp": 1786320000,
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "http://gis-nl.example/"
    ],
    "type": [
      "VerifiableCredential",
      "ServiceProviderDelegationCredential"
    ],
    "issuanceDate": "2025-02-20T00:00:00Z",
    "expirationDate": "2026-08-08T00:00:00Z",
    "credentialSubject": {
      "id": "did:web:dienstverlener.example.nl",
      "@type": "ServiceProvider",
      "hasDelegation": {
        "@type": "Delegation",
        "issuedBy": {
          "@type": "HealthcareProvider",
          "identifier": {
            "@type": "Identifier",
            "system": "http://fhir.nl/fhir/NamingSystem/ura",
            "value": "12345678"
          }
        },
        "scope": {
          "@type": "DelegationScope",
          "authorizationRule": "https://aorta.example.nl/authorizations/gtk",
          "authorizedActions": ["tokenRequest", "presentCredentials"]
        }
      }
    }
  }
}

Validation

In addition to the generic validation steps from the Credential Catalog, verifiers MUST perform the following checks:

1. The issuer is a did:web DID of a healthcare provider. Framework-specific issuer requirements apply; see Agreement framework specifics.
2. The credential type array includes ServiceProviderDelegationCredential.
3. The sub claim matches credentialSubject.id (if present).
4. The URA in credentialSubject.hasDelegation.issuedBy.identifier.value identifies the delegating healthcare provider; its binding to the issuer did:web MUST be established through a HealthcareProviderCredential presented in the same Verifiable Presentation.
5. The values for authorizationRule and authorizedActions MUST be valid within the applicable agreement framework.

Agreement framework specifics

The main specification above is agreement-framework-generic. The issuer identity and the value sets for authorizationRule and authorizedActions are defined per agreement framework (afspraakstelsel).

AORTA

Within the AORTA agreement framework:

• Issuer: the healthcare provider that delegates the authority. The issuer did:web MUST use a .nl top-level domain (e.g. did:web:zorginstelling.example.nl).
• Authorization rule: authorizationRule MUST be an AORTA-defined authorization rule URI (e.g. https://aorta.example.nl/authorizations/gtk).
• Authorized actions: authorizedActions MUST contain one or more AORTA-defined actions (e.g. tokenRequest, presentCredentials).

Example use cases

• A healthcare provider authorizing a service provider (e.g. a software vendor) to request access tokens and present credentials on its behalf.
• A data holder verifying that a requesting service provider holds a valid delegation from the healthcare provider whose data is being requested.