- From: Markus Sabadello <markus@danubetech.com>
- Date: Tue, 13 Aug 2019 01:59:09 +0400
- To: Charlie Haviland <charliehaviland@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>
- Cc: Credentials Community Group <public-credentials@w3.org>
- Message-ID: <612b517f-f8cc-48eb-a5d1-efc2f4b8a131@danubetech.com>
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 > > >
Received on Monday, 12 August 2019 21:59:41 UTC