Internal behavior of drivers

[peacekeeper]

We discussed that drivers (both for resolver and registrar) can work in different ways to fulfill their purpose, for example:

1. A resolver driver may have direct access to a full node, or it may use a thin client, or it may call a remote API in order to resolve an identifier. In other words, the driver may be more or less "close" to the source of truth.
2. A registrar driver may or may not require user interaction in order to register an identifier. For example, the "btcr" driver may in a private organizational setting be deployed with a pre-funded wallet shared by all clients, or it may be available publicly but require each client to fund their own wallet. And for example the "sov" driver may be able to act as a "trust anchor" on its own, or it may have to redirect a client to the services of an external trust anchor.

Some points to consider:

• Should there be strictly one driver per DID method, or could there be e.g. two different "btcr" drivers, one for full node support, and one for thin client support?
• Should this be controlled by a driver's configuration (JSON config file, Docker environment variables), so an operator of the resolver/registrar can customize how they want a driver to work?
• This could also be controlled individually for each client request using request parameters, e.g. a client requests that a full node must be used, otherwise abort. (But you have to trust the resolver/registrar to honor those parameters).
• In some cases certain request parameters may be mandatory (e.g. in order to submit a registration request for a "btcr" DID, you need to specify whether you want mainnet or testnet).
• Metadata about the resolution/registration process can be included in the result metadata, e.g. a boolean flag saying that a full node was used. (But you have to trust the resolver/registrar to not lie about this).
• In some cases, both full node mode and thin client mode may be supported, but not actually make a difference in terms of trustworthiness of the result (e.g. state proofs in the "sov" method).

It seems a DID method spec should specify what behavior variations (level of verification, full node vs thin client, etc.) are supported. The individual drivers can then implement this (and may only support a subset of the variations).

The resolver/registrar and their drivers could expose an API that allows clients to discover which variations, configuration settings, request parameters, etc. are supported.

[csuwildcat]

On the issue of having two separate drivers vs one with both capabilities in it:

I think it would be nice to have one that could set itself up internally for either configuration based on ENV vars, but I am not sure how easy/feasible that is. If that's not a simple task, or hygienically poor practice, I would say just go with two separate drivers.

If we do two separate drivers, I think we should have a naming convention or pattern that denotes which is which, and clearly explain to folks who want to run the UR how they change the config to include the different types. Also, if we go with two drivers, we could check-in pre-built versions of the UR: one that has all known DID Methods included as light, and one that has all Methods included with their full variants.

[peacekeeper]

I'm also not sure yet whether one configurable driver vs multiple drivers is better. I used to think strictly "one driver per method", but now I can more and more see the advantages of separating them in order to better isolate specific functionality.

Regarding a naming convention, one small problem I see is that it may not always be possible to strictly distinguish between "full" and "light". For example, to implement BTCR, the driver can include its own full node (very secure), or it could talk SPV (medium secure), or it could query a remote transaction explorer API (least secure). So there are three options, not just "full" and "light". Other DID methods in the future may have yet other, more complex variations.

But yes +1 to smart naming of drivers, and +1 to pre-built versions of the UR with different configurations depending on one's needs.

[peacekeeper]

We looked at this issue on today' Universal Resolver weekly call, and it seems some of the content here is obsolete, and some of it belongs in different places (documentation, DID method specs, etc.).

We should re-use some of the content from this issue in appropriate other places, and then close the issue.

[peacekeeper]

We discussed this on the 29 Sep 2021 Universal Resolver work item call, and agreed that the previous comment still applies.