Internal behavior of drivers

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.