The did is not a url for the did, but for a resolution structure which as yet has no name

[TomCJones]

This not only makes the definition of did incorrect, but it points to a need for a name for the structure returned by a did resolution. Would also like to understand how redirects fit into this structure.

[jandrieu]

Shoot. This response was written in the context of the DID-Spec, not DID-Resolution. However, I think it still applies, as it involves how we talk about DID, DID Documents, resolution and dereferencing a DID.

The definition definitely needs work. @burnburn and I had some good progress on this topic while working on the DID Explainer today.

To attempt to summarize:

A DID is a URI as per RFC3986 https://tools.ietf.org/html/rfc3986.

A URI can be further classified as a locator, a name, or both. The
term "Uniform Resource Locator" (URL) refers to the subset of URIs
that, in addition to identifying a resource, provide a means of
locating the resource by describing its primary access mechanism
(e.g., its network "location"). ...

An individual scheme does not have to be classified as being just one
of "name" or "locator". Instances of URIs from any given scheme may
have the characteristics of names or locators or both, often
depending on the persistence and care in the assignment of
identifiers by the naming authority, rather than on any quality of
the scheme. Future specifications and related documentation should
use the general term "URI" rather than the more restrictive terms
"URL" and "URN" [RFC3305].

I believe it is a fair representation of our discussion to say language like the following should be in the opening section:

Resolving a DID results in a DID Document, either dynamically generated or retrieved, depending on the method. The DID Document contains the information necessary to dereference the DID to a specific resource.

Going further, we think the spec should clarify with something like the following language:

The default dereference of a DID, when no path is specified, MUST return the DID Document. If a path component exists in the DID and that path matches an entry in the services property of the DID Document, dereferencing the DID shall proceed by resolving and dereferencing the matching service endpoint.

And lastly, a suggestion which makes sense to me, but I can't claim any consensus for:

If there is a path in the DID and the resolution yields a DID Document that lacks a matching service endpoint, dereferencing the DID should yield an error stating clearly that the path has no matching service endpoint.

What that error code is is a whole new kettle of fish. I don't think we've discussed error codes other than a NULL response for a DID that fails to resolve. I expect this won't be the first error code that deserves a more useful response from the resolver. The actual errors should be in the DID-Resolver spec, but the basics of how resolution fits into the relationship between DIDs and DID Documents and the dereferencing thereof, clearly needs to be spelled out in the DID spec.

In general, almost all of us, including me, have been exceedingly unrigorous in how we discuss DIDs "resolving to DID Documents". That is technically correct, but resolution is a process, which yields the information needed to dereference; when we say "resolving to a DID Document" many hear it as "returning the DID Document". However dereferencing is what actually returns some sort of resource. We need to improve our language to make this clear from the beginning.

Here's the relevant quote from RFC3986:

1.2.2. Separating Identification from Interaction

A common misunderstanding of URIs is that they are only used to refer
to accessible resources. The URI itself only provides
identification; access to the resource is neither guaranteed nor
implied by the presence of a URI. Instead, any operation associated
with a URI reference is defined by the protocol element, data format
attribute, or natural language text in which it appears.

Given a URI, a system may attempt to perform a variety of operations
on the resource, as might be characterized by words such as "access",
"update", "replace", or "find attributes". Such operations are
defined by the protocols that make use of URIs, not by this
specification. However, we do use a few general terms for describing
common operations on URIs. URI "resolution" is the process of
determining an access mechanism and the appropriate parameters
necessary to dereference a URI; this resolution may require several
iterations. To use that access mechanism to perform an action on the
URI's resource is to "dereference" the URI.

When URIs are used within information retrieval systems to identify
sources of information, the most common form of URI dereference is
"retrieval": making use of a URI in order to retrieve a
representation of its associated resource. A "representation" is a
sequence of octets, along with representation metadata describing
those octets, that constitutes a record of the state of the resource
at the time when the representation is generated.

[TomCJones]

how about
The default dereference of a DID, when no path is specified, MUST return a claim with the DID Document. If a path component exists in the DID and that path matches an entry in the services property of the DID Document, dereferencing the DID shall proceed by resolving and dereferencing the matching service endpoint.

this is to cover the metadata that comes with the did doc

[jandrieu]

Interesting. Yes. That's more appropriate.

Also, a quick read of the DID-Resolution draft states that when a path is specified, instead of resolving and dereferencing the service endpoint, the resolver simply returns the endpoint. That's probably the better default option to remove the load of subsequent dereferencing from the DID resolver. This should probably be selectable, perhaps as intended with the followRedirect parameter, although the current language suggests that only DID service endpoints are redirects. It wouldn't be crazy to support having the resolver optionally resolve and dereference the service endpoints directly, if it knows how to.

However, section 4.1 defining DID Document probably shouldn't use the phrase "retrieved"

[mwherman2000]

It all depends on what layer of the architecture and to what level of detail you want to discuss this at.

From a developer perspective, a DID Resolver doesn't return a DID Document to the caller; it returns a DID Resolver Response (which, in turn, wraps the returned DID Document). It isn't correct to say that DID Resolution returns a DID Document (unless you having a casual discussion over a coffee or as part of a PowerPoint presentation - but that's not what specifications are about).

Here's a link to the section of the draft INDY ARM that describes the DID Resolution process (also verified by @peacekeeper): https://github.com/mwherman2000/indy-arm#3-did-resolution-viewpoint

The "thing" that is returned by the DID Resolver (41) is element (42): a DID Resolver Response. A DID Resolver Response is subsequently used to realize a DID Document (16).

[jandrieu]

I think we are in violent agreement. The DID Document is not what is returned by a resolver. Hence we should not define that as such in 4.1

[mwherman2000]

I think we are in violent agreement. The DID Document is not what is returned by a resolver. Hence we should not define that as such in 4.1

True but the DID Resolver Response does have to be defined as a "new section 4.1" ...shifting the current 3 elements either down one or indented one level to the right in the DID Resolution spec.

[peacekeeper]

Coming back to this after a while, I wonder how much of it is still relevant. I believe some of what has been discussed in this issue is covered by now in the DID Resolution spec, e.g.

The default dereference of a DID, when no path is specified, MUST return the DID Document.

I think this is covered by section DID URL Dereferencing.

a DID Resolver doesn't return a DID Document to the caller; it returns a DID Resolver Response (which, in turn, wraps the returned DID Document)

I think this is covered by section DID Resolution Result.

instead of resolving and dereferencing the service endpoint, the resolver simply returns the endpoint

I think this is covered by section DID URL Dereferencing.

Maybe @TomCJones or @jandrieu could provide their opinion what should be done with this issue.

[peacekeeper]

Per discussion on today's DID WG call, marking this as pending-close.

[pchampin]

This was discussed during the did meeting on 10 October 2024.

View the transcript

DID Resolution Issue/PR Processing

burn: Contact the chairs if anyone would suggest an improvement

markus_sabadello: let's start with new issues

<markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close

markus_sabadello: first with pending close issues

burn: note that, in the agenda email, we listed these issues.
… We'll be using this process until the end of the thursday meeting to object to the close.

<TallTed> I strongly recommend such searches be ordered by "least recently updated" to keep the churn active, e.g., https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close+sort%3Aupdated-asc

burn: the point is, we'll review these quickly today, but the expectation is that you are too look for these in the agenda and speak up or comment in the issue if you have an objection
… so we will not be spending time unless there is a concern (as a general rule)

<markus_sabadello> w3c/did-resolution#57

markus_sabadello: Proposal to rename one of the resolution functions
… Resolve and ResolveStream
… This issue is a proposal to rename ResolveStream. That's already happened. I posted a comment 2 weeks ago. No further discussion

burn: any objections to closing?

markus_sabadello: I'll close them after the call

<markus_sabadello> w3c/did-resolution#30

markus_sabadello: Issue 30, several years old. Has to do with dereferencing discussion at TPAC
… "The result of dereference can be a DID document, but it can also be something else"
… Looking at this issue after a long time, I think the current specification addresses this. I see 3 thumbs up to that comment.
… So, if no objections, we'll be closing this.

<markus_sabadello> w3c/did-resolution#29

markus_sabadello: also several years old, about the definition of the term did resolver.
… In the current specification, both terms are defined formally in terminology section. Also two thumbs up.
… Any objections?

<markus_sabadello> w3c/did-resolution#21

markus_sabadello: Issue 21 about removing the term DID Reference from DID core to DID Resolution.
… I think this is now obsolete. We don't use that term in any spec.
… Same discussion was also in did-core, which was closed. So I think this one can be as well.
… Any objections?

<markus_sabadello> w3c/did-resolution#11

markus_sabadello: All methods must have a name of at least three characters.
… This seems like a DID Core issue, not in DID Resolution
… Similar issue in DID-core, which has also been closed.
… For all of these issues, it seems straightforward to close them.
… Since they are older issues, we may not be getting engagement from the initial poster, but unless there are objections, seems like we should close

decentralgabe: If we mark it pending close and give it a week, that would address the older participants

burn: requirements vary from group to group. In past groups, we've made the point to actively reach out by email and ask for engagement. Then you can comment that in the issue.
… so ping in the issue, then email, then document that email in the issue.
… That let's us show we've done what we can to address the concerns of the original poster
… For these, I think we're good, but going forward that's a nice improvement to our process

burn: you have 10 more minutes if you like

<markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22

markus_sabadello: one other thing. A few issues are tagged as "Good First Issue"
… Two of them have been assigned. One has not.
… These are a good way to contribute, especially if you might not be familiar with deeper technical issues.
… We'll try to find more like that and encourage PRs
… A few that might be ready to close

<markus_sabadello> w3c/did-resolution#23

markus_sabadello: Issue 23 is about result of dereferencing

<manu> JoeAndrieu: Looking at the backlog. There is an opportunity here to make a distinction -- how we talk about a DID with and without a trailing slash... but I don't know if that helps us. I need to look at this in more detail, it's five years old, we can close it, if problem still exists, we can raise a new issue again.

<manu> markus_sabadello: I think this might be obsolete by now?

<manu> JoeAndrieu: Yeah, sounds like it might be.

<manu> markus_sabadello: We will have until next call to look at it or raise a new issue if this comes back.

<manu> JoeAndrieu: Sounds good to me.

manu: I'm wondering what is the ... I'm fine with closing it. I'm wondering where did we land?
… the response from a resolver is a resolution result, which might contain a did document?
… Is that where we landed?

markus_sabadello: that's right the resolution response might contain a did document, but dereferencing might return something else

manu: i think it's already addressed (as opposed to an older issue that isn't valid)

markus_sabadello: this was from when we didn't have a did resolution result, we were just returning DID documents
… That has been addressed

<JoeAndrieu> +1

manu: +1

markus_sabadello: also to be aware of, from discussions at TPAC, when we talked about path, query, and fragment parts.
… we talked about different patterns in the past and how much of that should be in the resolution spec itself or in did core, or in both.
… If people come up with certain features that use the path or query string, how does that fit in and where does it get specified?

<markus_sabadello> w3c/did-resolution#85

markus_sabadello: There are two open issues for new DID parameters with certain functionality

<markus_sabadello> w3c/did-resolution#90

markus_sabadello: The first introduces version-type the second XYZ as parameters
… Please comment about where these should go and whether or not it should be did-method-specific or standardized across methods

burn: ok, you have about another 5 minutes if you'd like

markus_sabadello: ok. I'm wondering if we can merge that pull request

<markus_sabadello> w3c/did-resolution#89

markus_sabadello: or if anyone has new thoughts about the discussion we had about primary resource and secondary resource
… there is an open PR where I tried to improve the headings
… to help with that. I'm wondering if people have opinions.
… I would actually prefer not to merge because it makes the headings longer
… But the algorithm talks about dereferencing the primary resource and secondary resource
… This PR adds explanation to the headings

manu: I think it is unfortunate that the initial wording was primary and secondary resource, as that is so abstract it is confusing.
… +1 to comment about section titles get hard

<TallTed> +1 to manu's suggestion

manu: maybe we can call it derereferencing a DID? or a #fragment
… +1 to not merge this, but maybe we can have did document and fragment as the terms

markus_sabadello: there is something that right now is called a primary resource.
… there needs to be a name for what you get when you dereference the did document
… For example, dereferencing the DID URL resource may be a better phrase

manu: yes. that was my thinking. Name the types of things you can dereference.
… A use case where you get a DID Document. A case where you dereference a fragment in a resource. And a third case where it's neither of those.
… Related Resource? (Not suggesting that, but if we name it, it will help)

markus_sabadello: this needs to be extensible. we can't imaging all the things they dereference to.
… but i think we can use better terms than Primary & Secondary. I'll try to do that.

<manu> JoeAndrieu: I would like to try my hand at writing this PR, don't know when I'm going to get to it, but want to help.

---

[pchampin]

This was discussed during the did meeting on 17 October 2024.

View the transcript

w3c/did-resolution#23

markus_sabadello: I'll close this at end of meeting, marked it pending close last week, no further comment/objection, closing at end of this call.

<markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

markus_sabadello: There are a number of older issues, one with the latest input was 22

---