peacekeeper
commented
1 year ago This makes my life a lot easier, we'll need statusCode for the
did:keyerrors too. I guess that will need to either be here or in a new section of the did:key spec.
I think the HTTP status code mapping for an error code should be done in the same document where the error itself is defined.
Just as a side note, new errors don't necessarily HAVE to be defined in either the DID Core or DID Resolution spec. If there are errors that are DID method specific, then they can also be defined in the DID method specification. Errors (or any other extension) can also be defined in some other place, e.g. we have already begun to define some errors and other extensions in a DIF repository: https://github.com/decentralized-identity/did-spec-extensions/
So if you want you could move some of the errors out of DID Resolution and into the did:key method spec (either way seems fine to me). OTOH in this specific case, maybe the public key related errors are more generally useful and don't exclusively apply to did:key, not sure.
In any case, no matter where errors or other extension are defined, they can always be listed in the DID Spec Registries.
This adds a table that maps DID Resolution and DID URL Dereferencing errors to HTTP status codes, which seems easier to read than a list of copy&paste text statements. Also adds an additional status code for the "methodNotSupported" error.
Related to https://github.com/w3c-ccg/did-resolution/issues/72.