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

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>
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
>
>
>
>