architecture of universal resolver

[praveensankar]

I am doing research on DID. It would be really helpful if I could get answers to the following questions.

1. I want to know whether the universal resolver has been replicated in a decentralized manner or not. (As per my understanding, it seems like, the universal resolver is controlled by decentralized-identity.)
2. is there anyone who decides whether to add a support for particular DID method based on some rules? or is it automatic?
3. is the docker-container responsible for universal-resolver is maintained by a single company or group of companies ?

[peacekeeper]

Hello @praveensankar , great questions! Here are some thoughts:

1. The Universal Resolver is open-source, and anyone can run their own instance. The one at https://dev.uniresolver.io/ is hosted by DIF as a community service, but nobody should rely on this instance for anything other than testing and non-sensitive experimental use. You can deploy it yourself on your own server, and you should get the same results. Several companies in the community are running their own instance on their own infrastructure.
2. This is something we should probably discuss more. As a general rule, we only add drivers for DID methods that already have a specification listed in the DID method registry at the W3C DID WG. And we do some lightweight testing of the new driver to see if actually works, before adding it. We also follow some guidelines for driver developers. There is probably some room for improving this process, please let us know if you have ideas!
3. The Universal Resolver consists of a "main container" (universalresolver/uni-resolver-web - see source). This is mostly maintained by one company (Danube Tech), but it's an official DIF project, so anyone can contribute. The individual drivers of the Universal Resolver (see list) are contributed and maintained by various DID method authors and implementers from different communities.

Also feel free to join us at the I&D Working Group to discuss this more!

[praveensankar]

Hello @peacekeeper, thanks for the answers.

if I understand your answers correctly,

1. Danube Tech maintains the source code (universal resolver)
2. support for new DID methods are added based on the DID method registry (W3C DID WG)
3. Companies use the docker container to do the DID resolution

I think it would be nice, if there is a way to dynamically add and remove support for DID methods. Do you think it will be useful and possible ?.

[peacekeeper]

We revisited this on the 28 Jul 2021 Universal Resolver Work Item call..

Right now, the config.json file is "static" and contains a list of drivers. Drivers can be implemented as locally run Docker containers, or could alternatively be remote endpoints.

Adding and removing drivers from that config file is a manual process, and we have recently improved the policies around that (see Driver Development).

Do you mean that instead of using a static config.json file, drivers should be automatically detected somehow? How would that work exactly? Or do you mean that DID methods can be added and removed at runtime?

Curious to hear more about your ideas here!

[praveensankar]

Hello @peacekeeper ,

It's been some time since i have asked these questions. I tried to recollect the exact motivations behind asking those questions. The main problem i see with the current process is due to the manual addition of new DID methods ( through drivers ), it might become bottleneck. I assume it involves human operators to verify each drivers before adding it in the "config" file. This approach is fine, if the number of drivers are in 2 or 3 digits ( around 100 ). But once the number of DID methods started to rise, let's say around 1000, then this whole process will become bottleneck. Since it also depends on the DID method registry, each addition / removal should have to go through 2 verifications (one at the W3C side and the second one at here). I feel atleast the addition should be automatic and the removal can be done manually if the newly added driver is malicious.

[peacekeeper]

@praveensankar thanks for providing more details, and sorry it took us so long to respond to your initial message!

I agree with everything you're saying. The current manual process (mostly done by @BernhardFuchs ) could become too difficult if we see more driver contributions.

Personally, I believe we will probably always have some manual step in the process, but we could certainly automate some things a bit more. For example, in the future we might be able to automatically test new drivers against the W3C DID test suite, or we might be able to automatically remove (or disable) drivers if they stop working. For more on this topic of removing drivers, also see some rules we wrote recently about handling problems with drivers.

[praveensankar]

@peacekeeper I understand that providing answers to queries like these will take time due to the amount of different questions and allocating time for it.

This idea seems interesting. I can try to come up with a solution and maybe contribute to this development. Let me know if you have any other interesting problems with respect to DID.