Map error types not defined in this specification to HTTP status codes

[danpape]

Addresses #355.

Per @peacekeeper's suggestion there, a custom error code could either declare which existing error type it refines and inherit that type's status, or declare its HTTP status code directly. Both routes are here.

I made two edits: In the Errors section, a specification that defines an error type not defined there MAY declare which of the defined types it refines. In the HTTP(S) Binding section, a rule after the status code table: a status declared by the defining specification wins, otherwise the status of the type it declares it refines, otherwise 500.

These fix a gap described in #355. The Errors section says it "uses some errors defined in Section 3.5 Processing Errors of the [CID] specification", but none of those have a row in the status code table. The error registry in DID Resolution Extensions carries seven DIF-defined codes (notAllowedVerificationMethodType and the rest) and none of those have a row either. All of them would end up as (any other error URI) -> 500 today.

One question: I annotated the catch-all row as (any other error URI; see below) rather than deleting it. Step 3 in the text I added kind of makes that row redundant, but the 500 default was proposed deliberately in #72 and I would rather not remove it uninvited.

Two things I can't fix here. The error registry doesn't have a place to put such a declaration as an entry records only where the error is normatively defined, and its example is {"error": "invalidDid"}, a bare string rather than an RFC 9457 object with a URL type. I've raised that as #359, which is really the broader question of how a registered error type gets a URL at all. And the test suite asserts the exact standard type URI rather than just the status, so a conformant resolver raising a correctly-mapped method error would fail it. I brought that up informally in w3c/did-resolution-test-suite#9.

---

Preview | Diff

[wip-abramson]

Thanks Dan, I will aim to get this on the agenda next week to get some more attention on it. But it looks good to me.

[danpape]

Thanks!

No preference came back on the wording (discussed in the original issue), so I'll leave "refines".

[peacekeeper]

Looks good, thanks!