[DID ABNF] How can we support DID Resolution requirements like `did:?ping` and `did:?methods`?

[mwherman2000]

1. How can we support DID Resolution proposed requirements like:

   • did:?ping, and
   • did:?methods

2. The current approach for defining the DID Resolution inputs and outputs in the did-spec spec and not in the did-resolution spec I believe is going to be problematic. See point 1 above as an example. Is it still best/proper to define the syntax for DID Resolution in a document that is separate/different from the DID Resolution spec?

3. Point 2 in https://github.com/w3c-ccg/did-resolution/issues/29#issue-412342140 is another example of the "wrong document" problem described in point 2 above.

[peacekeeper]

@mwherman2000 As we already discussed in other issues, I agree that "pinging" (see https://github.com/w3c-ccg/did-resolution/issues/27) and "listing supported methods" (see https://github.com/w3c-ccg/did-resolution/issues/26) could be useful features for a DID Resolver, BUT:

• You are again somehow mixing up DID syntax with the DID Resolution process or protocol. Those are two different things, as we already discussed in https://github.com/w3c-ccg/did-spec/issues/167.
• Your phrase "the syntax for DID Resolution" doesn't make sense to me. Or could you explain what you mean by that? DIDs or DID References or DID URLs are strings that follow a certain syntax, described by an ABNF. DID Resolution on the other hand is a process or protocol. There is no such thing as a "syntax for DID Resolution".
• The title of this issue says "[DID ABNF]", but the two proposed features have nothing to do with an ABNF.
• Even if we decide that these two features are useful, they may still not end up in either of the two specs, since we could decide that they are implementation specific features, rather than something that needs to be standardized. (I could see arguments for both)

[mwherman2000]

We also need to consider what the HTTP bindings will be for the DID Resolution protocol: https://github.com/w3c-ccg/did-resolution/issues/32

[rhiaro]

Closing, because this belongs in the did-resolution spec/issues, as variously linked in the thread.

[mwherman2000]

No, this can't be closed because the ABNF specification for DIDs (including any DID Resolution implications) is part of the did-spec.

...or move all of the DID Resolution components of the ABNF specification to the DID Resolution specification.

Please re-open this and leave it open until this is resolved.

@peacekeeper @talltree

[mwherman2000]

Additional reference: https://github.com/w3c-ccg/did-resolution/issues/32

[dmitrizagidulin]

@mwherman2000 We have a lot of good discussion and implementation ahead of us, with regards to DID resolution and resolvers. However, the url specs for resolvers are completely out of scope for either repo. They’re just regular urls to helper services some people might run. The resolver apis will also differ from resolver to resolver.

[mwherman2000]

@dmitrizagidulin How and where are these boundaries defined?

[mwherman2000]

https://github.com/w3c-ccg/did-resolution/issues/32 perhaps combines two separable issues: a) HTTP/URL binding and b) specific DID URL constructions. The latter is definitely within the scope of both specs.

It is more illuminating to look at them together.

[talltree]

On Sun, Mar 3, 2019 at 9:42 PM Michael Herman (Toronto) < notifications@github.com> wrote:

w3c-ccg/did-resolution#32 https://github.com/w3c-ccg/did-resolution/issues/32 perhaps combines two separable issues: a) HTTP/URL binding and b) specific DID URL constructions. The latter is definitely within the scope of both specs.

It is more illuminating to look at them together.

Since this question seems to keep coming up, let me propose a "hard line" between what belongs in the DID Specification vs. the DID Resolution Specification. This hard line is based on exactly the same hard line drawn in section 1.2.2 of RFC 3986 https://www.ietf.org/rfc/rfc3986.txt (the URI specification).

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.

To translate this to DIDs and DID Resolution, this would mean:

1. The DID spec defines the generic structure of the DID URI scheme, including all forms of a valid DID URL.
2. The DID spec defines the requirements for DID resolution that MUST, SHOULD, and MAY be specified in the DID Resolution specification. Note that this includes anything that MUST, SHOULD, or MAY be implemented in DID resolution to support DID dereferencing.
3. The DID spec defines the requirements for DID methods that MUST, SHOULD, and MAY be specified in any conformant DID method specification.

Relative to the ABNF, this means the following:

1. The DID spec can specialize (but not violate) the ABNF in RFC 3986.
2. If the DID Resolution spec needs to define ABNF for a URL-based syntax for DID resolvers, it can specialize (but not violate) the ABNF in the DID spec.

I hope this helps,

=Drummond

[mwherman2000]

1. The DID spec can specialize (but not violate) the ABNF in RFC 3986.
2. If the DID Resolution spec needs to define ABNF for a URL-based syntax for DID resolvers, it can specialize (but not violate) the ABNF in the DID spec.

Agreed. This was my expectation from the start and the reason why I posted these cross-over issues:

• to help ensure the DID spec ABNF accommodates the requirements in the DID resolution spec.

...and, to reconfirm my earlier comments, at this stage when the concrete (aka spec text) is fluid but starting to set for both the DID spec and the DID resolution spec, we need to make sure the DID spec provides in the DID spec ABNF all of the syntactic capabilities required by the DID resolution spec. I believe we can only achieve this be reviewing the patterns in the proposed DID resolution use cases and validating the DID spec ABNF against these patterns. I'm sure we'll discuss this in Thursday's DID resolution call.

NOTE the new tabular format for the use cases in https://github.com/w3c-ccg/did-resolution/issues/32