jandrieu
commented
5 years ago 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
mwherman2000
peacekeeper
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.