Consider use of "Problem Details" in case of errors

[peacekeeper]

At the moment, the specification defines various errors that can be returned by the DID Resolution and DID URL Dereferencing functions:
https://w3c.github.io/did-resolution/#errors

During the 29 Aug 2024 DID WG meeting, it has been suggested that the "Problem Details" specification (RFC9457) could be used here as well.

[pchampin]

This was discussed during the did meeting on 23 January 2025.

View the transcript

w3c/did-resolution#87

markus_sabadello: This has been addressed -- exists. We have resolution and dereferencing result. Pending closed.

manu: Good idea to settle on Problem Details. Handled in other specs and works well. Nice if the DID Resolution spec so there was consistency across the specs (DI, DID, others)/.

ivan: Formerly -- if have a DID error, inherits the CID error, so that covers it.

Wip: Argument to put it in the spec. Any takers to put it in?

manu: I'll volunteer.

---

[peacekeeper]

The thing about this issue is that we have some language in the CID spec on how to return errors (using RFC9457), and we also have language in the DID Resolution spec on how to return errors.

We also have concrete lists of errors in the CID spec (e.g. INVALID_CONTROLLED_IDENTIFIER_DOCUMENT_ID, and we also have concrete lists of errors in the DID spec (e.g. invalidDid) and in DID extensions.

Theoretically they could both be returned as part of DID Resolution Metadata, e.g. something like this:

{
  "didDocument": null,
  "didDocumentMetadata": { },
  "didResolutionMetadata": {
    "error": "invalidDid",
    "problemDetails": {
      "type": "https://w3id.org/security#INVALID_CONTROLLED_IDENTIFIER_DOCUMENT_ID",
      "title": "The resolved DID is invalid.",
      "detail: "Parse error of the resolved DID at character 3, expected ':'."
    }
  }
}

But maybe we want to align a bit more than that, i.e. only have a single way of returning (and registering) errors, shared between CID and DID.