Re: Update on DID Spec Task Force and final week sprint to prepare the Community Final Draft

Charlie,

Just as a reminder, the DID URL Dereferencing
<https://w3c-ccg.github.io/did-resolution/#dereferencing> algorithm in
the DID Resolution spec is at an early stage and still likely to change
a lot.
Nevertheless, thanks for taking a close look and providing feedback!
This will help us clarify things in the spec.

The meaning of terms like "DID Fragment" has changed a bit over time.
My explanation would be that a DID Fragment is just a "normal" URI
fragment in a DID URL, it's exactly the same construct.

Therefore, in both Example 2
<https://w3c-ccg.github.io/did-resolution/#example-2> and Example 3
<https://w3c-ccg.github.io/did-resolution/#example-3>, we have a "DID
Fragment".

The results of the dereferencing algorithm are different however, since
Example 2 has a "service" matrix parameter (therefore it derefences to a
service endpoint URL), whereas Example 3 doesn't have that (therefore it
dereferences to a part of the DID Document).

Your comment about the DID spec defining DID Fragments
<https://w3c-ccg.github.io/did-spec/#fragment> to always point to a part
of a DID Document may have to be revised a bit, since in Example 2
that's clearly not the case.

Note that Section 8 <https://w3c-ccg.github.io/did-spec/#did-resolvers>
of the DID spec has been updated to defer to the DID Resolution spec.

Also, just to be clear, there is no such thing as a "fragment" matrix
parameter, just in case you were asking about this in your original email.

Markus

On 8/8/19 3:57 AM, Charlie Haviland wrote:
> Manu,
>
> Thanks for your thorough reply! I believe that answers all of my
> questions and I have a follow-up on just one. The 'dereferencing
> algorithm' from question 4 can be found here
> <https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm>,
> and I should better clarify what exactly I was asking about.
>
> This particular section of the algorithm, shown below, says that a
> service matrix-parameter can be accompanied, not just by any fragment,
> but specifically by a DID Fragment. 
>
> If the input DID URL
> <https://w3c-ccg.github.io/did-resolution/#dfn-did-url> contains the
> matrix parameter |service| and optionally a DID Path
> <https://w3c-ccg.github.io/did-resolution/#dfn-did-path>, DID Query
> <https://w3c-ccg.github.io/did-resolution/#dfn-did-query>, and/or DID
> Fragment <https://w3c-ccg.github.io/did-resolution/#dfn-did-fragment>:
> EXAMPLE 2 <https://w3c-ccg.github.io/did-resolution/#example-2>
> did:example:1234;service=agent/profile?query#frag
> Since a DID Fragment is defined in the DID spec as always pointing to
> a section of a DID document (as seen here
> <https://w3c-ccg.github.io/did-spec/#fragment>) I wonder, does this
> example show a generic URL fragment, but not a DID Fragment? Since my
> understanding is that service endpoint requests should return an
> endpoint, and DID Fragment requests return a section of the DID
> Document, I was confused specifically by the use of "DID Fragment"
> instead of simply "fragment" in that sentence.*
> *
>
> I hope that does a better job explaining the question than my first
> attempt!
>
> Thanks again and looking forward to tomorrow's call,
> Charlie
> *
> *
> *Charlie Haviland*
> Software Developer | SelfKey
> Boston, MA
> +1-(203)-913-1756
> +66-099-380-8383
>
> <https://www.linkedin.com/pub/charlie-haviland/b4/416/11>
>
>
>
> On Mon, Aug 5, 2019 at 11:18 PM Manu Sporny <msporny@digitalbazaar.com
> <mailto:msporny@digitalbazaar.com>> wrote:
>
>     Hey Charlie, great questions!
>
>     A few quick responses below:
>
>     On 8/4/19 3:24 PM, Charlie Haviland wrote:
>     > * How should a resolver handle network connectivity issues during
>     > resolution?
>
>     That's really up to the resolver... it's an implementation detail.
>     We do
>     want to be specific about when you should and should not cache
>     responses, though.
>
>     > * Will establishing a Data Model for the DID Document be an early
>     > priority for the new WG?
>
>     Yes, in fact, this is one of the primary goals of the first version of
>     the DID spec.
>
>     > * Is the no-cache input-option always passed by the client, or
>     can it
>     > be supplied by the resolver? o How does the client pass this input
>     > option to the resolution algorithm when it's not an input option
>     for
>     > the dereferencing algorithm?
>
>     Not enough information to answer. My gut reaction says that
>     no-cache is
>     always passed by the client... suggest you follow standard HTTP
>     caching
>     rules and headers here...
>
>     > * Are steps 3 and 4 in the dereferencing algorithm (matrix
>     parameters
>     > 'service' and 'fragment') mutually exclusive?
>
>     Which algorithm are you referring to? Links help here.
>
>     In any case, service and fragment are not mutually exclusive, you
>     should
>     be able to use fragments w/ services.
>
>     > If not, how should a DID URL with both be dereferenced?
>
>     You resolve the service first and then tack the rest of the URL,
>     including fragment, to the end of the final URL... but I may have
>     missed
>     some nuance in your question.
>
>     > * Section 8 (Resolvers) of the DIDs spec says that a resolver "MAY
>     > offer the service of returning requested properties of the DID
>     > Document." If this means dereferencing, should it say MUST, as this
>     > is said to be required in the resolver spec?
>
>     Section 8 of the DID spec should probably defer entirely to the DID
>     Resolution spec and not have any normative language. That's
>     probably old
>     text that needs to be updated/removed as it predates the DID
>     Resolution
>     spec. Please raise an issue on this in the did-spec repo so we don't
>     lose track of it.
>
>     -- manu
>
>     -- 
>     Manu Sporny (skype: msporny, twitter: manusporny)
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Veres One Decentralized Identifier Blockchain Launches
>     https://tinyurl.com/veres-one-launches
>
>
>