Handling additional errors in resolution/dereferencing

[clehner]

Three error codes are defined for DID resolution and DID URL Dereferencing:

• invalid-did
• unauthorized
• not-found

Source:

• § 8.1.2 DID Resolution Metadata Properties
• § 8.2.2 DID URL Dereferencing Metadata Properties
• did-spec-registries § 6.2 error

What should an implementation do if it encounters errors during resolution or dereferencing other than the three specified? For example:

• a DID resolves to a supposed JSON-encoded DID, but the JSON is invalid
• a DID resolves to a supposed DID document, but the document doesn't fit the Data Model, such as by missing a required property like "id", or would have other errors produced during processing
• a transient network failure prevents resolving the DID or dereferencing the URL
• the DID method or URL scheme is not implemented

Should implementers make up additional error values as needed? Or return additional errors outside the metadata structure?

Is this an appropriate place for a question like this?

[peacekeeper]

@clehner Good question, I actually wanted to raise a similar issue myself. When we added the DID Resolution and DID URL Dereferencing sections, we said at some point that we would still have to decide on the exact error values.

My answer would be that we should only define a minimal set of error values in the DID Core spec, and that additional error values can be defined in other places, such as the DID Resolution spec.

Based on what we currently have, my preference would be to do this:

• Remove the unauthorized value. (Because it would be very hard to define what it means to authorize a resolution process; in fact we usually consider resolution something that doesn't require authentication/authorization of the client).
• Add a deactivated value. (This would be returned if the DID has been deactivated).
• Maybe add a method-not-supported value. (To indicate that the DID resolver doesn't support this particular DID method).

So we would then have the following error values defined in DID Core: invalid-did, not-found, deactivated, (maybe) method-not-supported.

Again, additional error values can be defined later using the DID Spec Registries, but the above seem like a useful "core set" of errors to me.

[msporny]

The PR has been merged into the main specification. This issue will be closed in 7 days unless there are objections.

[kdenhartog]

No objections made and 7 days have passed. Closing this issue.