Configuring DID Drivers

[vpapanchev]

Hello,

I am deploying the universal resolver locally in a microservice-based application. During development I don't want to support all existing DID Methods and therefore want to use only some of the DID Drivers.
In my docker-compose I can configure which drivers to build. However, once the application starts, the universal resolver still outputs that drivers have been added for all DID Methods:

uni-resolver-web_1  | 2022-03-07T10:58:58,987 INFO  [main] u.l.c.LocalUniResolverConfigurator: Added driver for pattern '^(did:btcr:.+)$' at http://driver-did-btcr:8080/1.0/identifiers/ (http://driver-did-btcr:8080/1.0/properties)
uni-resolver-web_1  | 2022-03-07T10:58:58,989 INFO  [main] u.l.c.LocalUniResolverConfigurator: Added driver for pattern '^(did:sov:(?:(?:\w[-\w]*(?::\w[-\w]*)*):)?(?:[1-9A-HJ-NP-Za-km-z]{21,22}))$' at http://driver-did-sov:8080/1.0/identifiers/ (http://driver-did-sov:8080/1.0/properties)
...

When resolving a DID, it also matches the did against all registered did patters:

uni-resolver-web_1  | 2022-03-07T10:59:10,431 DEBUG [qtp1479696465-21] u.l.LocalUniResolver: Attempting to resolve did:kilt:light:014t.. with driver HttpDriver
uni-resolver-web_1  | 2022-03-07T10:59:10,432 DEBUG [qtp1479696465-21] u.d.h.HttpDriver: Skipping identifier did:kilt:light:014t.. - does not match pattern ^(did:btcr:.+)$
uni-resolver-web_1  | 2022-03-07T10:59:10,432 DEBUG [qtp1479696465-21] u.l.LocalUniResolver: Attempting to resolve did:kilt:light:014t.. with driver HttpDriver
uni-resolver-web_1  | 2022-03-07T10:59:10,432 DEBUG [qtp1479696465-21] u.d.h.HttpDriver: Skipping identifier did:kilt:light:014t.. - does not match pattern ^(did:sov:(?:(?:\w[-\w]*(?::\w[-\w]*)*):)?(?:[1-9A-HJ-NP-Za-km-z]{21,22}))$
...

This implodes the log files and also may result in misleading responses when trying to resolve a DID without a built driver:

papanchev@xxx:~/ssi-workspace/ssi-acs$ curl -X GET http://localhost:5010/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw
{"@context":"https://w3id.org/did-resolution/v1","didDocument":null,"didResolutionMetadata":{"error":"internalError","errorMessage":"Driver cannot retrieve resolve result for did:sov:WRfXPg8dantKVubE3HX8pw from http://driver-did-sov:8080/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw: driver-did-sov: Temporary failure in name resolution","contentType":"application/did+ld+json"},"didDocumentMetadata":{}}

Here the DID is not resolved due to the unsupported DID Method (I have not added the Sovrin Driver) but the response states that the driver failed to resolve the DID: "Temporary failure in name resolution". (See edit below)

My question: Is there a better way of configuring which DID Methods to support?

PS: Is it also possible to configure the logging?

Edit: Actually, when configuring the drivers like this (simply not building them), trying to resolve a DID of an unsupported DID Method result in the following error:

uni-resolver-web_1  | Caused by: java.net.UnknownHostException: driver-did-sov: Temporary failure in name resolution

This shows me that this is definitely not the intended way of configuring which DID methods to support.

[Markus Sabadello]

Hello @vpapanchev, thanks for your question, and nice to hear that you are running the Universal Resolver.

Unfortunately we require a bit of duplication here in the setup. When configuring the list of supported DID methods, you have to do it in 2 places:

• Configure the Docker containers in the docker-compose.yml file. You did this already. This specifies which drivers are started as Docker containers.
• Also configure the drivers in the config.json file. You have to do this too. This tells the Universal Resolver which DID methods are available.

If you only do the first step but not the second, then the Universal Resolver "thinks" that all drivers are running, but they are not, which causes the error you described.

Sorry for this complication. Please let us know if it works after you do the above.

[vpapanchev]

Thank you @peacekeeper for the timely response and detailed instructions.
I have forked the project and deployed locally successfully. Feel free to close the issue :)

[Markus Sabadello]

Good to hear it works now! Closing.