Legacy did:nuts configuration
This page covers configuration that’s only relevant for use cases that still use did:nuts DIDs and/or the Nuts gRPC network.
If your use case does not use these features, you can ignore this page.
Options
The following table contains additional (deprecated) options that are relevant for use cases that use did:nuts DIDs and/or the gRPC network:
Key |
Default |
Description |
|---|---|---|
tls.certfile |
PEM file containing the certificate for the gRPC server (also used as client certificate). Required in strict mode. |
|
tls.certheader |
Name of the HTTP header that will contain the client certificate when TLS is offloaded for gRPC. |
|
tls.certkeyfile |
PEM file containing the private key of the gRPC server certificate. Required in strict mode. |
|
tls.offload |
Whether to enable TLS offloading for incoming gRPC connections. Enable by setting it to ‘incoming’. If enabled ‘tls.certheader’ must be configured as well. |
|
tls.truststorefile |
./config/ssl/truststore.pem |
PEM file containing the trusted CA certificates for authenticating remote gRPC servers. Required in strict mode. |
Auth |
||
auth.accesstokenlifespan |
60 |
defines how long (in seconds) an access token is valid. Uses default in strict mode. |
auth.clockskew |
5000 |
allowed JWT Clock skew in milliseconds |
auth.contractvalidators |
[irma,dummy,employeeid] |
sets the different contract validators to use |
auth.irma.autoupdateschemas |
true |
set if you want automatically update the IRMA schemas every 60 minutes. |
auth.irma.schememanager |
pbdf |
IRMA schemeManager to use for attributes. Can be either ‘pbdf’ or ‘irma-demo’. |
auth.irma.cors.origin |
[] |
sets the allowed CORS origins for the IRMA server |
Events |
||
events.nats.hostname |
0.0.0.0 |
Hostname for the NATS server |
events.nats.port |
4222 |
Port where the NATS server listens on |
events.nats.storagedir |
Directory where file-backed streams are stored in the NATS server |
|
events.nats.timeout |
30 |
Timeout for NATS server operations |
GoldenHammer |
||
goldenhammer.enabled |
true |
Whether to enable automatically fixing DID documents with the required endpoints. |
goldenhammer.interval |
10m0s |
The interval in which to check for DID documents to fix. |
Network |
||
network.bootstrapnodes |
[] |
List of bootstrap nodes (‘<host>:<port>’) which the node initially connect to. |
network.connectiontimeout |
5000 |
Timeout before an outbound connection attempt times out (in milliseconds). |
network.enablediscovery |
true |
Whether to enable automatic connecting to other nodes. |
network.grpcaddr |
:5555 |
Local address for gRPC to listen on. If empty the gRPC server won’t be started and other nodes will not be able to connect to this node (outbound connections can still be made). |
network.maxbackoff |
24h0m0s |
Maximum between outbound connections attempts to unresponsive nodes (in Golang duration format, e.g. ‘1h’, ‘30m’). |
network.nodedid |
Specifies the DID of the party that operates this node. It is used to identify the node on the network. If the DID document does not exist of is deactivated, the node will not start. |
|
network.protocols |
[] |
Specifies the list of network protocols to enable on the server. They are specified by version (1, 2). If not set, all protocols are enabled. |
network.v2.diagnosticsinterval |
5000 |
Interval (in milliseconds) that specifies how often the node should broadcast its diagnostic information to other nodes (specify 0 to disable). |
network.v2.gossipinterval |
5000 |
Interval (in milliseconds) that specifies how often the node should gossip its new hashes to other nodes. |
Storage |
||
storage.bbolt.locktimeout |
1s |
Maximum time to wait for acquiring a lock on the BBolt database before giving up and returning an error. Formatted as Golang duration (e.g. 1s, 1m). |
storage.bbolt.backup.directory |
Target directory for BBolt database backups. |
|
storage.bbolt.backup.interval |
0s |
Interval, formatted as Golang duration (e.g. 10m, 1h) at which BBolt database backups will be performed. |
storage.redis.address |
Redis database server address. This can be a simple ‘host:port’ or a Redis connection URL with scheme, auth and other options. |
|
storage.redis.database |
Redis database name, which is used as prefix every key. Can be used to have multiple instances use the same Redis instance. |
|
storage.redis.password |
Redis database password. If set, it overrides the username in the connection URL. |
|
storage.redis.username |
Redis database username. If set, it overrides the username in the connection URL. |
|
storage.redis.sentinel.master |
Name of the Redis Sentinel master. Setting this property enables Redis Sentinel. |
|
storage.redis.sentinel.nodes |
[] |
Addresses of the Redis Sentinels to connect to initially. Setting this property enables Redis Sentinel. |
storage.redis.sentinel.password |
Password for authenticating to Redis Sentinels. |
|
storage.redis.sentinel.username |
Username for authenticating to Redis Sentinels. |
|
storage.redis.tls.truststorefile |
PEM file containing the trusted CA certificate(s) for authenticating remote Redis servers. Can only be used when connecting over TLS (use ‘rediss://’ as scheme in address). |
|
VCR |
||
vcr.openid4vci.definitionsdir |
Directory with the additional credential definitions the node could issue (experimental, may change without notice). |
|
vcr.openid4vci.enabled |
true |
Enable issuing and receiving credentials over OpenID4VCI. |
vcr.openid4vci.timeout |
30s |
Time-out for OpenID4VCI HTTP client operations. |
Client authentication
The /n2n endpoints and the gRPC Nuts network use TLS certificates for client authentication.
The Nuts-node validates the client certificates used by its peers on the gRPC network when a new connection is established, and periodically after that as long as the connection exists.
To do this, all trusted certificate chains must be configured in tls.truststorefile.
See Certificate revocation handling for how CRL checks and soft-fail behavior work for these certificates.
The gRPC Nuts network and /n2n endpoints are deprecated and will be removed in the future.
Publishing services for use cases
V5 use-cases define service endpoints or a collection of endpoints that should be registered in the Services on DID Documents.
The concrete endpoints are usually on the DID Document of the vendor, and then referenced by all DID Documents managed by that vendor.
did:nuts for example, requires the registration of a NutsComm endpoint to authenticate the connection.
Use-cases built on did:nuts should keep using the DIDMan API to manage and resolve Services on DID Documents.
Any Service change made using the DIDMan API will only update did:nuts DID Documents.
For use-cases built on v6 and later, any endpoint needed for the use-case should instead be listed in the registration on the Discovery Service for that use-case.
This means that did:web DID Documents (or non-did:nuts if we look further ahead) will contain very few Services, if any.
If there is a need to add a Service for these use-cases, they should be added using the VDR v2 API, which will then add the Service to _all_ DIDs that are part of the Subject.
Note that resolving Services using the VDR v2 API will return the Service from the document as is.
So, it resolves Services without following any references in the Service to a concrete endpoint, as is done by DIDMan.