Resolution errors due to invalid parameters

[andrewwhitehead]

It might be good to clarify what a resolver should return when invalid or conflicting parameters are provided, here's a few cases I've noticed:

• versionNumber is zero or not numeric
• versionId is not in the correct format
• versionId and versionNumber conflict (f.ex. versionId = 1-QmPJ9ynGs6VKxqxAvW7U712PaqF8sL7awE7XZbcpYjUMfG, versionNumber = 2)
• versionTime cannot be parsed as a ISO date-time for comparisons

At the moment I have the resolver just short-circuiting and returning a notFound error if this happens, although that doesn't provide an indication of the actual issue. The error message could potentially be used to clarify.

In general, I believe we want to ignore a blank string if provided for any of these parameters (for ease of URL templating mostly)?

[swcurran]

Regards the expanded information to return. Based on the DID Core spec, there really is only three values to return — success, fail/invalid, and not found — and that is what is in the spec. Per @peacekeeper ’s suggestion and what may go into the DID Resolution spec in the future is the use of “Problem Details” and RFC9457 to add more information about the error. That spec is referenced in the Read (Resolve) section of the spec. Further, on the didwebvh.info site, there is a set of did:webvh resolution error codes that can/should be used by resolvers. It would be nice to have everyone use common codes/phrases, but I don’t think it is crucial, as it mostly developer debugging data.

Happy to add more of them to that list. I’ll add those ones in particular.

Is that sufficient to satisfy this issue?