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 eithera 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
alsoidentifies 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 (notthe 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