Summary

  • W3C's 1 October DID Resolution draft offered an HTTP(S) route and a conformance class for a network-based DID URL dereferencer. The 24 and 26 October drafts remove both from that binding.
  • HTTPS resolution of a DID remains specified. A client still has to select a resolver, use the returned DID document, choose a handler and complete the task represented by the whole DID URL.

Imagine an application asking for did:example:123#key-1. The resolver can hand back the DID document. The #key-1 fragment still has to be found and used by the application. A successful courier delivery is an awkward substitute for opening the parcel.

That distinction has acquired a sharper edge in W3C's 26 October DID Resolution Candidate Recommendation Draft. The 1 October draft described a “conforming network-based DID URL dereferencer,” put dereferencing in its HTTP(S) binding and supplied HTTP examples. The 24 October draft removed that class and those HTTP provisions. The 26 October text keeps the change. Its revision history says the OpenAPI definition lost dereferencing too.

The HTTP door stays open for the narrower job. The current draft describes a conforming network-based DID resolver and an HTTPS binding for DID resolution. GET is required for conforming resolvers; POST is optional. An endpoint can return a DID document and resolution metadata. The contract for the HTTP endpoint stops there.

The rest of the route is laid out in the draft's DID URL dereferencing algorithm. The client lets its user choose a resolver for a DID method, calls for resolution, decides how the result should be handled and invokes the handler. The draft's examples put fragment handling on the client. A service query can take the client along a different path again. The application that uses the answer owns that last decision, with all the context the resolver never saw.

This boundary also changes what a buyer should ask for in a test report. An HTTP status and a DID document show that resolution reached the door. A test of the complete DID URL must follow the chosen handler and the resource it actually yields. W3C's March issue on the HTTP binding raised precisely the trouble with treating a remote dereferencer as a peer of a resolver: fragments finish at the client. The group's 15 October minutes show an active discussion about how abstract algorithms and rigid test interfaces meet.

The working draft still marks DID URL dereferencing as a feature at risk. That makes this a live standards choice. For operators, the useful inventory already has two columns: which service resolved the DID, and which client code turned the full URL into a resource. The second column cannot be filled by the server's receipt.