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

Question:

Along with WebID, might we also consider DID Resolution for folks familiar
with OpenID Connect UserInfo Endpoint?

Adrian


On Fri, Mar 22, 2019 at 6:46 AM Markus Sabadello <markus@danubetech.com>
wrote:

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

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/