DID Resolution Result in case of upstream issues

[frankhinek]

Seeking commentary on what the resolve() function in our DID method/resolver implementations should do when there is either a network failure or upstream gateway failure. Examples include:

• for did:web, when attempting a GET to the server specified by the DID URI the network call might return a failure or the remote server could respond with status codes 404, 500, 503, etc.
• for did:dht, there are multiple steps in the resolution process where network calls or upstream gateways might return an error status

Note

This only pertains to DID methods in which resolution relies on an external service. In other words, we need to consider for did:dht and did:web but not did:jwk or did:key.

We haven't yet added test vectors for DID DHT but there is one test for DID Web checks for didResolutionMetadata containing an error value of notFound given an invalid domain.

Do we want to mirror this pattern for other DID test vectors? Should implementations raise an exception? (Kotlin/JS) or return an error result (Go, Rust). Is it up to the implementation and all of the Web5 SDKs will do it differently?

Additional Reference Information

• List of DID Resolution Errors in draft community group report
• § 8.3 notFound

  If during DID Resolution or DID URL dereferencing a DID or DID URL doesn't exist, the value of the DID Resolution or DID URL dereferencing Metadata error property MUST be notFound as defined in sections DID Resolution Metadata and DID URL Dereferencing Metadata in [DID-CORE].

[andresuribe87]

For did:dht, the proposed impelementation does:

• notFound, when the given did isn't found by the gateway.
• internalError for all other types of errors, e.g. a timeout.

[frankhinek]

@andresuribe87 Given that, what are your thoughts on returning internalError in the event the HTTP GET request during resolution of a did:web DID either outright fails (network transport layer issue) or returns a status code other than 200?

[andresuribe87]

@frankhinek I proposed something a bit different in this PR:

• When the host is unknown (e.g. domaindoesnotexist.com), return a notFound
• Any other error results in internalError. For example, timeouts or parsing errors.

The motivation behind this was to follow the did spec notFound definition (which was pointed by you at the top).

[andresuribe87]

FWIW, this reference implementation always returns notFound when there are any issues.