archetech / archon / 32611482526

95%

push

github

feat(gatekeeper): Label the resolution result, and stop faking Accept (#931)

* feat(gatekeeper): Label the resolution result, and stop faking Accept

Closes #770. Options B and C from that issue, together and Accept-driven,
in both implementations.

The deferral there was explicitly a timing call -- hold until the DID test
suite fixture PR landed, so a behaviour change would not draw fresh
scrutiny to a nearly-closed review. w3c/did-test-suite#240 merged
2026-07-30, so the reason to wait is gone.

B. application/did+ld+json and application/did+json describe a DID
*document*; this endpoint answers with the resolution triple. A client can
now ask for application/did-resolution and get the result labelled for
what it is. Opt-in only: absent, */* and application/* still yield
did+ld+json, because that is what Universal Resolver drivers expect.
didResolutionMetadata.contentType keeps reporting a document
representation either way -- that field describes what is inside the
envelope, not the envelope.

C. An Accept naming only unsupported representations is now 406 with
representationNotSupported, rather than being quietly satisfied with
JSON-LD. That also settles a published inconsistency: the merged fixture
declares supportedContentTypes as the two document types while the
endpoint accepted anything.

Two things I got wrong on the way, both recorded rather than papered over:

- I asserted `*/*;q=1, application/did+json;q=0.5` should yield did+json.
  It yields did+ld+json, and that is correct: RFC 7231 gives the more
  specific range precedence, so the wildcard's q=1 applies to the other
  type. Both implementations already agreed; the test was wrong. Kept as a
  pinned case since it is what a lenient driver sends.
- The no-wildcard rule on the envelope is defensive, not load-bearing.
  Flipping it changes no behaviour, because accept_quality takes the best
  match across entries and the tie favours the document. Commented as such
  in both flavors instea... (continued)

3844 of 4328 branches covered (88.82%)

Branch coverage included in aggregate %.

32 of 32 new or added lines in 1 file covered. (100.0%)

8484 of 8794 relevant lines covered (96.47%)

688.62 hits per line