Clarify that DID URL dereferencing returns the final resource. #544
Conversation
|
I'm struggling a bit with this --
(And this struggle may not belong here on #544, nor perhaps on #399.) But elsewhere (though perhaps this was changed in the past year, and I have overlooked that change?), we've said that the DID, though it is a URL/URI/IRI, must be resolved in order to get the DID URL, which literal is therefore presumably not (at least not always, if ever!) the same literal as the DID. That means, among other things, that the literal of the DID need not be contained within the literal of the DID URL (though we expect the DID, presumably its literal, to be included within the DID Document retrieved when the DID URL is dereferenced). More, we've said (elsewhere, at least) that resolution of the DID happens before dereferencing of the DID URL, not as a part of that dereferencing. Indeed, how can a DID be separated from a DID URL in order to be resolved, if that resolution doesn't actually occur after the dereferencing delivers the DID Document which does contain the DID? What is the canonical order of these operations? |
|
This is what I'm getting at in this thread, starting here #539 (comment) |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
To be honest, both statements sound strange to me. Can you find a reference when/where we said this?
RFC3986 says "URI "resolution" is the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI". So I think you're right about this. If we say anywhere in the spec that resolution is a part of dereferencing, do you want to create a separate PR to fix that? |
|
I think some things must have changed during my hiatus ... and/or I had internalized something that wasn't actually said. I see the weird differentiation we now have between DID Resolution (get a DID Document from a DID) and DID URL Dereferencing (get something from a DID URL, which might be a DID Document, or a fragment thereof, or something entirely external) ... which I think will confuse many, but I guess it's OK if we're internally consistent. |
|
@TallTed wrote:
Yes, I think the same, Ted. I'm equally concerned of that, but I can't quite put my finger on /why/. I mean, if you think of it -- this is exactly what happens w/ HTTP -- first you do DNS Resolution, and then you do URL dereferencing. So why should that confuse many? I think the issue may be the way we're using "Resolution" in the specification is misleading? It might just be the "get me just the data associated with the fragment" that might throw people... that's supposed to happen client-side, not server side. We may also want to make the distinction between URI Resolution and DNS Resolution (we mean the latter, but I don't think we ever say it). URI Resolution is about getting to an absolute URL (not hitting the DNS system): https://tools.ietf.org/html/rfc3986#section-5 DNS Resolution is about getting data associated with a name. Just some thoughts on our Resolution / Dereferencing sections... I had thought I knew what URI Resolution meant, but upon re-reading the spec, it's very different from DNS resolution. |
| a resource with contents depending on the <a>DID URL</a>'s components, | ||
| including the <a>DID method</a>, method-specific identifier, path, query, | ||
| and fragment. This process depends on <a>DID resolution</a> of the <a>DID</a> | ||
| contained in the <a>DID URL</a>. | ||
| contained in the <a>DID URL</a>. <a>DID URL dereferencing</a> might involve | ||
| multiple steps (e.g., when the DID URL being dereferenced includes a fragment), |
There was a problem hiding this comment.
Are there any other dereferencing libraries in existence that do this? This might confuse people that are used to their resolution libraries not doing this part of the process for them.
There was a problem hiding this comment.
Nobody is saying that the entire dereferencing process has to be implemented in a single library. As we know, in the case of HTTP URLs, the dereferencing processes involves both server and client components. In the case of DID URLs, those details depend on the method and concrete dereferencer implementation. This PR just clarifies that dereferencing returns the final resource after all the steps (including potential "client"-side fragment dereferencing) are completed.
There was a problem hiding this comment.
Hmm, perhaps we could use a less misleading example then... like: "e.g., when the DID URL being dereferenced requires the resolution process to query a Decentralized Ledger."
There was a problem hiding this comment.
Waiting on @peacekeeper to respond to see if he's ok w/ this change before merging.
There was a problem hiding this comment.
@msporny That section is about "URI reference resolution", which is different from "URI resolution" :) For URI resolution, see https://tools.ietf.org/html/rfc3986#section-1.2.2. |
Right, I had completely read past the "reference resolution" bit... and even worse, that makes it even more confusing. I was finally able to find the one sentence in the URI specification that speaks to "URI resolution" instead of "URI reference resolution". In any case, we may want to do better than the URI spec here and really spell out what we mean (and provide an example). |
This is an attempt to address #399, in order to clarify that DID URL dereferencing returns the final resource (including when the DID URL contains a fragment). How this is implemented is out of scope for DID Core.
Preview | Diff