W3C home > Mailing lists > Public > public-credentials@w3.org > August 2019

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 5 Aug 2019 23:16:30 -0400
To: public-credentials@w3.org
Message-ID: <6376cb4a-34c9-d75d-a771-08256caa8515@digitalbazaar.com>
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 Tuesday, 6 August 2019 03:16:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:54 UTC