Skip to main content

Required Artifacts and Configuration

A use case writer supplements you with a number of artifacts, that need to be configured:

  • Service Discovery definitions
  • Policy definitions
  • DID document service definitions

This page details how to configure each artifact.

Warning: do not alter these artifacts after receiving them, as they supply the Nuts node with the trust anchors as defined by the use case. Changes might lead to unsafe configuration.

Service Discovery Definitions

These JSON files instruct your Nuts node where to publish use case participation, and where to find other participants. They need to be provided in the Nuts node's discovery definitions directory (discovery.definitions.directory). The file name may be changed; it does not influence the definition. It's recommended to mount the files/directory in read-only mode if Docker is used.

Registration: after configuring the definitions, the Discovery Service for the applicable subjects through the Nuts node's VDR (v2) API, to make them discoverable.

Endpoints can also be discovered this way; definitions can specify additional parameters (in the form of a DiscoveryRegistrationCredential), for instance API endpoints, or OAuth2 Authorization Server URLs. Note: existing use cases use DID document services instead.

Policy Definitions

These JSON files instruct your Nuts node which credentials a participant needs to present (to your Nuts node) to acquire an access token with a certain scope. They need to be provided in the Nuts node's policy directory (policy.directory). The file name may be changed; it does not influence the definition. It's recommended to mount the files/directory in read-only mode if Docker is used.

DID Document Service Definitions

These describe which endpoints to register in your DID document(s) to make them resovable for other participants. DID document services can't be preconfigured, but need to be registered on DID documents using the Nuts node's API. There is no pre-defined form, so they are typically described in text.

This could be in the

The DID document of the eOverdracht Receiver needs to contain the eOverdracht-receiver service, that specifies the following endpoints:

  • fhir: the FHIR base URL of the receiver
  • oauth2: the OAuth2 issuer URL at which the requester can
{
  "type": "eOverdracht-receiver",
  "serviceEndpoint": {
    "fhir": "https://example.com/fhir",
    "oauth2": "https://example.com/oauth2"
  }
}
Back to top