Potentially drop HTTP binding for "dereferencers"?

[jandrieu]

As I was drafting a holistic fix for #226, it seems that one way to clean up some of the confusion between dereferencing and resolution is to NOT define an http binding for dereferencing. In fact, to not define any interface for dereferencing, just define algorithms.

That is, I see the primary purpose of the DID resolution spec is to define a single interface, Resolve, that allows for interoperable DID resolution across DID methods over a common https binding.

The dereferencing algorithm which uses resolution to dereference a DID URL must also be defined--that is a dereferencer. But the value in dereferencing is not, IMO, in an interoperable API for dereferencing, its in understanding how to create a call to a resolver and apply the result, including some nice transformations like expanding URLs or alternate representations.

The current text was written to introduce the dereferencer as a peer of resolvers, with https bindings and specific method calls with inputs and outputs. That parallelism was a good initial idea, but based on my cleaning up to clarify resolution v dereferencing, iI know think it was a case of irrelevant consistencies. Not only do I not know of anyone making a stand-alone dereferencer, but the final stages of dereferencing literally CANNOT be remote&mdsh;as fragments are always interpreted by the resolving client; that is, dereferencing cannot be a simple peer of resolving.

This is part of the ongoing conversation about "dereferencers", which was not a thing we were thinking about when we all came up with DID core. I think we have neither figured out the best way to discuss these differences, nor have we socialized this separation of function particularly well.

I'll take a stab at this in my revision for #226, but I'm curious if anyone else was imagining shipping a stand-alone dereferencer; even more interesting if someone thought they might be implementing a remote dereferencer. Both would be interesting to unpack.

[swcurran]

I agree with that about dereferencers and the challenge of having an HTTP interface. The idea is complicated by the DID URL query parameters that impact resolving a DID to get a Document Document. I think it is more appropriate that the specification define the result of a DID URL Dereferencer and to leave how it to implement it outside the scope of the spec. The spec defines a logical definition of DID URL Dereferencer.

I second Joe's comment about a DID URL Fragment. I think a fragment should be handled by the client of a (logical) DID URL Dereferencer given the result of the dereferencing to that point - just as a browser handles a fragment after getting a result from a Web Server.

As to whether a someone will implement a DID URL Dereferencer. We do that with Attested Resources (signed, hashlinked resources) associated with a did:webvh DID. We think Attested Resources are useful offchain DID resources and could be used by many DID Methods. We also dereference the /whois DID URL path and did:webvh -- and again, would like all DID Methods to have such an endpoint.

[peacekeeper]

I'm not sure what you mean by "stand-alone" dereferencer, but there are various existing implementations and HTTP(S) endpoints of the DID URL Dereferencing function, e.g.:

• https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b
• https://dev.uniresolver.io/#did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b
• https://docs.godiddy.com/apis/universal-resolver/did-url

Personally I think it's valuable to have HTTP(s) bindings for both DID Resolution and DID URL Dereferencing. I don't really follow why the latter should be removed?

[peacekeeper]

If we remove the "DID URL dereferencing" algorithm, then behaviors like the following would become unspecified (you can click on the links):

• Return a DID Linked Resource via HTTP: https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:a28a4d02-f690-403a-a438-cc2eeb9c7763/resources/492c1700-46e1-4ce2-892d-bf060038f549
• HTTP redirect to a service endpoint: https://did.re/did:web:20230614.dpp.spherity.com:products:tshirt?service=product

I think a fragment should be handled by the client

Yes, everybody agrees with that. The specification also says that. This is not an argument for removing the "DID URL dereferencing" algorithm or its HTTP binding.

[swcurran]

@peacekeeper -- I'm intrigued with the links. Where in the DID Resolution spec today does it say that a DID URL Dereferencer returns a resource, as in your examples?

[peacekeeper]

@peacekeeper -- I'm intrigued with the links. Where in the DID Resolution spec today does it say that a DID URL Dereferencer returns a resource, as in your examples?

Section 2

DID URL dereferencing result: A data structure that represents the result of the DID URL dereferencing algorithm. May contain a DID document or other content.

Section 5

The DID URL dereferencing function dereferences a DID URL into a resource with contents depending on the DID URL's components, including the DID method, method-specific identifier, path, query, and fragment.

The contentStream MAY be a resource such as a DID document that is serializable in one of the conformant representations, a verification method, a service, or any other resource format that can be identified via a Media Type

Section 5.4.1

8.1) The applicable DID method MAY specify how to dereference the DID path and/or DID query of the input DID URL.

Section 10.1

9.3) If the function is successful and returns a contentStream with any other contentType:

The HTTP response status code MUST be 200.
The HTTP response MUST contain a Content-Type HTTP response header. Its value MUST be the value of the contentType metadata property in the dereferencingMetadata (see 5.2 DID URL Dereferencing Metadata).
The HTTP response body MUST contain the contentStream that is the result of the DID URL dereferencing function, in the representation corresponding to the Content-Type HTTP response header.

[jandrieu]

If we remove the "DID URL dereferencing" algorithm, then behaviors like the following would become unspecified (you can click on the links):

My thought is definitely NOT to lose the dereferencing algorithm, but to clarify that it is a client-side algorithm, not one that you call remotely.

I argue you fundamentally can't dereference remotely. If I'm calling an http-based "dereferencer", the calling party is actually the dereferencer for the HTTP URL that points to the dereferencer. When I use a browser to visit a URL, I'm dereferencing that URL an displaying it on the page. There's no need for the browser to expose a "dereferencing" API to other applications. It simply performs dereferencing as a fundamental function. For example, there is no API in any browser I know that enables interprocess (or command-line) requests to dereference a URL other than opening it in the browser. Dereferencing as an API seems counter-productive when you still have to dereference the URL that accesses that API...

I'll have a PR with my proposed restructuring by Wednesday. Give me another day or so and hopefully I'll have some language that explains what I'm proposing with actual spectext.

I would argue that anyone can perform these http functions. What I question is the value of a standard for doing so, especially when the http function cannot fully dereference to a fragment. So we would be creating a dereferencing standard that creates "dereferencers" who can't actually fully dereference any URL with a fragment. Which is to say, we are defining a client-side function in dereferencing the fragment in 5.4.2 Dereferencing the Fragment

I think a fragment should be handled by the client

Yes, everybody agrees with that. The specification also says that. This is not an argument for removing the "DID URL dereferencing" algorithm or its HTTP binding.

So the specification necessarily defines the client-side functionality for dereferencing a fragment--which a conformant https dereferencer cannot do. That introduces a third software component, the "client" for which we have, I believe, just one task defined: dereferencing the fragment. But we have no language making that clear. No introduction of this "client" software, just the specification for its behavior buried in 5.4.2.

Since it seems there is agreement that we MUST specify client-side functionality, IMO, we should define all of dereferencing as client-side behavior as the rest of the Web has done for three decades.

[swcurran]

@jandrieu What do you mean by "all of dereferencing" in this statement?

Since it seems there is agreement that we MUST specify client-side functionality, IMO, we should define all of dereferencing as client-side behavior as the rest of the Web has done for three decades.

[jandrieu]

Hopefully, it'll be clear in my PR.

Dereferencing is how you turn the URL into a resource for presentation or processing.

Currently, DID URL dereferencing is partially defined by the algorithms implemented by a conformant DID dereferencer with a dependency on an underspecified "client".

I think that's part of the confusion about dereferencing versus resolution.