Re: Notes from 2019-03-21 DID Resolution Spec First Draft Meeting

Hello Michael,

Thanks once more for your input, there is definitely much value in this!

I think what's not going to work is you unilaterally presenting >60
slides for an hour.

I continue to see a few fundamental challenges regarding your work, e.g.
mixing Indy-specific functionality into the DID layer, or your
assumptions that "The two current specs were misspec'ed" and that there
is a need for a separate "Hyperonomy Universal Decentralized Identifier
URL Specification".

But having said that, I can say that your work is great input that has
triggered a lot of thinking for me, and I look forward to listening to
your latest insights tomorrow.

Markus

On 3/27/19 9:42 PM, Michael Herman (Parallelspace) wrote:
>
> For tomorrow’s DID Resolution (and/or DID Spec) community calls, I’d
> like to pick up on the did-urlgrammar discussion from the last week
> when my Internet connection went down.
>
>  
>
> I can speak for an hour on the topic of the did-urlgrammar; including
> the lower-level did-urluse cases.  I have some prepared content:
>
>  
>
> PPT Presentation and spreadsheets (most recent versions):
> https://github.com/mwherman2000/did-url-spec/tree/master/src
>
>  
>
> [I’ve also pre-recorded a version of the talk on YouTube:
> https://www.youtube.com/watch?v=B7e-15mivNs&index=4&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&t=9s
> ]
>
>  
>
> Please confirm.
>
>  
>
> Best regards,
>
> Michael Herman (Toronto/Calgary/Seattle)
>
> Independent Blockchain Developer
>
> Hyperonomy Business Blockchain / Parallelspace Corporation
>
>  
>
> W: http://hyperonomy.com <http://hyperonomy.com/>
>
> C:  +1 416 524-7702
>
>  
>
>  
>
> *From:*Markus Sabadello <markus@danubetech.com>
> *Sent:* March 22, 2019 4:45 AM
> *To:* W3C Credentials CG <public-credentials@w3.org>
> *Subject:* Notes from 2019-03-21 DID Resolution Spec First Draft Meeting
>
>  
>
> Zoom recording, chat logs, and slides for the (now weekly) DID
> Resolution Spec First Draft Meeting are here:
> https://github.com/w3c-ccg/meetings/tree/gh-pages/2019-03-21-did-resolution
>
> List of attendees and call notes are here below. You can also read
> them on the meeting page
> <https://docs.google.com/document/d/1BKbwWCS9ZT1Aawxv2YVvGUUOv9WfPqMK9MiWh1s9dLo/>.
>
> Markus
>
> *DID Resolution Spec First Draft Meeting Page*
>
> /This page is for taking notes of weekly meetings held in 2019 of
> members of the //W3C Credentials Community Group/
> <https://www.w3.org/community/credentials/>/who are collaborating to
> complete the First Draft of the //DID Resolution specification/
> <https://w3c-ccg.github.io/did-resolution/>/. Meeting notes are listed
> in reverse chronological order./
>
> /Note: This meeting directly follows the weekly //DID Spec Community
> Final Draft Meeting/
> <https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/>/./
>
>
>   Call Information
>
> Time: Every Thursday, 14:00-15:00 PT
>
>  
>
> https://zoom.us/j/7077077007
>
>  
>
> Or iPhone one-tap:
>
>    US: +16465588656,,7077077007#  or +16699006833,,7077077007#
>
>  
>
> Or Telephone:
>
>    Dial (for higher quality, dial a number based on your current
> location):
>
>         US: +1 646 558 8656  or +1 669 900 6833
>
>         United Kingdom: +44 (0) 20 3051 2874  or +44 (0) 20 3695 0088
>
>     Meeting ID: 707 707 7007
>
>    International numbers available:https://zoom.us/u/q6mghCSZ
>
>
>   Links (Generally Useful to the Group)
>
>   * DID Spec <https://w3c-ccg.github.io/did-spec/>
>   * DID Resolution Spec <https://github.com/w3c-ccg/did-resolution/>
>
>
>   Thursday 21 March 2019
>
>
>     Attending
>
>   * Markus Sabadello
>   * Jonathan Holt
>   * Drummond Reed
>   * Joe Andrieu
>   * Michael Herman
>   * Stephen Curren
>   * Dmitri Zagidulin
>   * Dan Burnett
>   * Nader Helmy
>   * Amy Guy
>   * Adrian Gropper
>   * Chris Boscolo
>   * Yancy Ribbens
>
>
>     Agenda
>
> 1. Community governance: issue resolution and closure policies
>
> 2. What does it mean to dereference a DID URL?
>
> 3. Presentation of the above README: did-url-spec - Decentralized
> Identifier URL (did-url) Specification as well as the spreadsheet:
> https://github.com/mwherman2000/did-url-spec/tree/master/src (latest
> numbered version)
>
>
>     Meeting Notes
>
>
>       Topic #1: Understanding DID URLs and “Resolution” and
>       “Dereferencing”
>
> Markus explained the overall topic using this slide:
>
>  
>
> Michael pointed out that the “defererencing” category also splits into
> two:
>
>  1. A DID URL that dereferences to a subcomponent of a DID document.
>  2. A DID URL that undergoes a transformation to address a resource
>     external to the DID document via a service endpoint.
>
>  
>
> Markus went on to explain the following slide:
>
>  
>
> Jonny asked how much DID resolution is actually parallel to DNS
> resolution.
>
>  
>
> Michael said that he has a set of proposals for how a set of DID
> resolution operations can work, e.g., how to query the capabilities of
> a resolver, or how to get a list of DID documents.
>
>  
>
> Michael whether returning a DID document is “access”?
>
>  
>
> Joe responded that access to a DID document is an open issue. Some
> proposals are to encrypt a DID document.
>
>  
>
> Drummond proposed that “DID resolution” be the set of steps that a DID
> method takes to return a DID document. He agreed with Joe that a
> particular DID method may in fact impose access control on obtaining a
> DID document. He then said that once a DID document is returned, you
> move into the “dereferencing” stage, and that can divide into the two
> types discussed above.
>
>  
>
> Dan: The DID document is not itself the resource, but a means of
> determining how to access the identified resource.
>
>  
>
> Markus next talked about this slide:
>
>  
>
> Drummond: Let’s avoid the HTTP Range 14 rathole! Let’s be clear that a
> DID never identifies a DID document! A DID identifies a DID Subject.
> That DID Subject MAY be a network-accessible resource. In that case a
> DID document describes how to access that resource. But the DID
> document may identify a non-network resource (like a person), in which
> case the DID document describes how to access service endpoints
> associated with the resource.
>
>  
>
> Jonny: IPLD is a type of resource that a DID may identify.
>
>  
>
> Joe: The resource when a DID is dereferenced is always on the network.
>
>  
>
> Markus spoke to this slide:
>
>  
>
> Joe and Drummond discussed the analogy with DNS and URL-identified
> resources. Drummond said that the DNS record that is retrieved in
> order to access the web page or RDF document. The DNS record is not
> the resource being identified by a URI. Therefore it is the equivalent
> of a DID document.
>
>  
>
> Markus next discussed this slide:
>
>  
>
> Dan dove into this “HttpRange-14” issue by suggesting that a DID
> subject was not actually a person. “+1 that action on a DID for a
> physical resource could be to return a URL for a file
.”
>
>  
>
> Drummond suggested that if a DID always identifies a DID subject, and
> that DID subject may be *either* a *real-world resource*
> (non-network-retreivable) or a *network resource*. If a DID identifies
> a real-world resource, then the DID document describes options for
> interacting either with that real-world resource via some type of
> network connection, or accessing other descriptions of that real-world
> resource. But the DID itself still identifies the real-world resource.
>
>  
>
> If the DID identifies a network-retrievable resource, then resolving
> the DID to the DID document will enable obtaining the actual URL that
> *also* identifies that network-retrievable resource. That means the
> DID and the URL would actually be “synonyms”, but at different layers
> of abstraction.
>
>  
>
> Drummond also said this addresses the “two URI” problem from Web ID.
> The DID that identifies Alice is URI #1, and the URL that identifies
> some resource describing Alice (*not* the DID document) is a second URI.
>
>  
>
> Joe mentioned that this means that a “naked DID” by itself should not
> be considered a URL. We should need to add a delimiter at the end of
> the naked DID to turn it into a URL for the DID document.
>
>  
>
> Drummond seconded that suggestion. It could be either the empty path,
> or the empty fragment.
>
>  
>
> Dan said that he had clarity that a DID document is about how to
> *describe how to interact with a resource*, but not describing the
> resource itself. That’s why a DID document is never the resource
> identified by the DID.
>
>
>
>     Action Items
>