Hi @nichonien,

Can you say more about what why you need the resolver options, e.g. what are the use cases?

resolver_options (ResolverOptions) in the CLI includes options to use a given DID resolver HTTP(S) endpoint instead of the built-in resolvers (did_resolver_override, -R in CLI), or as a fallback resolver for non-built-in DID methods (did_resolver, -r in CLI). These CLI options are available in the VC/VP issue/verify and DID Auth CLI subcommands. Can you confirm are these the options you want in node/web?

There are also DID resolution options ("DID resolution input metadata", e.g. accept, versionId, versionTime) that could be passed to the DID resolution function (either with the built-in DID methods, or to a remote resolver); but these are not exposed in the credential issuance/verification/presentation functions currently.

The API of didkit web and node are based on that of didkit-http, which is based on VC API. The VC API verify operations don't have an option for DID resolution options or DID resolvers to use during verification. Possibly we could extend VC API to allow this - although the trend in VC API seems to be about reducing optionality, so maybe such options would have to be added outside the VC API data structures.

Hey @clehner,

The current requirement that we are looking at is to verify a credential from the DIDDocument of the subject. So maybe we should be able to provide a resolver which resolves a did on some configured chain and then verifyCredential be able to verify the credential?

We can verify a credential known before hand from a VP, but for the case where you also want to verify let's say issuer authority for issuance as well. Then one of the approaches would be get the authoritative credential from issuer's DIDDoc. What would you suggest for the mentioned use-case?