Notes from 2019-03-21 DID Spec Community Final Draft Meeting

These were the attendees and notes from today's first call. We expect these
to continue weekly at the same time until the end of April (and the
completion of a Community Final Draft). You can also read them on the meeting
page
<https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/edit?usp=sharing>
.

Amy also took notes in the CCG IRC and she will send a link to that too.

Markus will be sending the  the DID Resolution Spec call that immediately
followed this one.

=Drummond

DID Spec Community Final Draft Meeting Page

This page is for taking notes of weekly meetings held in March & April 2019
of members of the W3C Credentials Community Group
<https://www.w3.org/community/credentials/> who are collaborating to
complete the Community Final Draft of the DID specification
<https://w3c-ccg.github.io/did-spec/>. Meeting notes are listed in reverse
chronological order.

Note: This meeting is directly followed by the weekly DID Resolution Spec
First Draft Meeting
<https://docs.google.com/document/d/1BKbwWCS9ZT1Aawxv2YVvGUUOv9WfPqMK9MiWh1s9dLo/>
.
Call Information

Time: Every Thursday, 13:00-14: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/>

Thursday 21 March 2019Attending

   -

   Markus Sabadello
   -

   Jonathan Holt
   -

   Drummond Reed
   -

   Joe Andrieu
   -

   David Longley
   -

   Ken Ebert
   -

   Stephen Curren
   -

   Dmitri Zagidulin
   -

   Dan Burnett
   -

   Nader Helmy
   -

   Amy Guy
   -

   Adrian Gropper
   -

   Chris Boscolo
   -

   Yancy Ribbens
   -

   Manu Sporny

Agenda

   1.

   Attendance and Introductions
   2.

   How we want to operate as a subgroup of the CCG
   1.

      Short-term group
      2.

      Goal: a completed Community Final Draft by the end of April
      3.

      Community governance: Issue resolution and closure policies; did-spec
      issue remediation
      4.

      Weekly calls, but also use the CCG list and github issue for progress
      5.

      Notes from each call sent to the CCG list
      3.

   Discussion of priorities and agenda topics
   1.

      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)
      2.

      Relationship of DID Spec and DID Resolution Spec (5 mins)
      3.

      Status report from Amy/Dmitri/Manu on editorial (5 mins)
      4.

      Logging new features (instead of adding them to the spec) (5 minutes)
      5.

      JSON-LD context(s) (10 mins?)
      6.

      ABNF Plan of Action (20 mins)


Meeting Notes

Drummond: The main focus of this group is the DID spec. Other issues should
be submitted to the CCG as a new work items. We need to have direct
discussions regarding issues and move items forward with a goal of closure
by the end of April.  Amy and Dmitri have done a tremendous amount of
editorial work.
Topic #1: Agenda

Drummond: Normally we will agree on the agenda items. (see above). Any
additional items for the agenda? I'll add status report to the agenda.

Jonny: What is the status of the DID working group?

Drummond: The CCG is responsible. We want to be able to hand off the DID
spec when the working group is formed.

… Any additional topics? I'll set time guidelines for topics.

... Prioritization of topics (see agenda above).
Topic #2: Presentation of the README deferred to second call;Topic #3:
Relationship of the DID Spec and the DID Resolution Spec

Markus: The DID Spec covers DID identifier syntax, the abstract data model
of DID Documents, and concrete syntaxes (e.g. JSON-LD) for DID Documents.

The DID Resolution deals with how to go from a DID using the method to
arrive at the DID document.

Drummond: DNS is an example of a specification that combines the URI and
the resolution.

… The DID Resolution Spec arose out of the need to have a separate
specification to address the details of how to achieve this.

Dan: I know Markus understands the difference between the idea that
resolution does not always result in a document. Dereferencing has multiple
actions associated with it.  The key is that resolution is about getting
the rules, policies, etc. for dereferencing a resource, while dereferencing
is about taking an action on a resource. The default action may be to
return something, but we should be careful not to always assume that
dereferencing means to return a document.  In particular, the “resource”
here is not necessarily defined (yet) to be a DID document.

Manu: here’s the link for the DID Working Group
<https://w3c-ccg.github.io/did-wg-charter>Charter.

Drummond: The DID resolution group has already had several calls. Slides
are available to distinguish between resolution / dereferencing.

Manu: It's basically use cases and syntax. When we feel like the DID
Resolution has at least 2 implementations and we are ready to work on it,
we can start on a standardization effort.

Drummond: More discussion?

Jonny: Where do we draw the line between the format and the serializations?
We need common ground that we are going to transform into JSON / JSON+LD.

Manu: Ted always says "It's a data model. Not protocol." The protocol is
out of scope for the VCWG; it is in scope for CCG.

Jonny: I think if we state it clearly that we are formulating it in
JSON/JSON+LD

Joe: There are protocolish things who will be using the data models that
can be captured in the use cases.

Drummond: Data model/serializations: DID Spec is a data model and one
serialization.

Jonny: I can work with that.

Drummond: I think that is sufficient for our current work.

Dan: Protocol work can happen in W3C, but we are chartered to not address
this so that we can reach easier consensus. Protocol work can happen in
other groups or later, perhaps, in this group.
Topic #4: Status Report on Editorial

Amy: We still have a large list of items to resolve. At rebooting we closed
23 issues at RWoT. Some issues have followup on Michael's issues.

Drummond: Are there areas where you would like feedback?

Amy: Not right now. The Intro and abstract sections will be overhauled.
Some content will be moved to other documents. A PR is coming.

Drummond: As someone responsible for early content, I give you license to
pare the spec down to more proper content.

Amy: I will edit with greater confidence. ;)

Drummond: Our goal is to have the explanatory document, with Ken and Dan,
by IIW.
Topic #5: Logging New Features Instead of Adding Them to the Spec

Manu: We will have a few calls to clean up the spec on its path to the WG.
During the meetings of the DID WG will also be a time to request new
features. Please log the issue in the issue tracker for current CCG work or
for the DID WG to discuss. We want to focus on editorial cleanup on the
current spec. The issue, if critical, can also be added to the spec now for
future consideration. If we follow these guidelines it will make the
editors' job easier.

Manu, please add link here to the issue tracker:

Drummond: I know that some obvious future features could be added to the
list.
Topic #6: JSON-LD Contexts

Drummond: There are questions regarding JSON-LD contexts in the VCWG. Do
all of the issues surrounding contexts applicable here?

Manu: Yes, we have the same set of conversations as the VCWG. If we make
the same decisions, all of the concerns could be addressed in the same
manner. Such as "What is the final URL for the VC Credential context?" We
can decide that the string is the identifier without the deep concerns for
centralized control. Regarding immutability, it is OK to hard code or
locally cache the files or build them into the application. Content-based
addressing or hash-links are also possible solutions. As long as we use the
same methods for resolving these issues as the VCWG, we should be ok.

Yancy: Re: contexts not being centralized, in the VCWG is the context is
mandatory?

Manu: The string is mandatory, but you don't have to retrieve the context
from the network, you can cache it or build it into the application because
it is not supposed to change. In the event of something catastrophic
happening, the community can resolve to use a standard definition instead.

Jonny: If there is an issue of trusting that URL, why not just define its
contents?

Manu: It helps the generic JSON-LD processors continue to function. It is
less disruptive to the rest of the web. It allows those who want it at a
URL and those who want it immutable, to both be happy.

Jonny: I can live with that.
Topic #7: Closed Github Issues

Micheal: Can items that were closed in editing without resolution be
re-opened?

Amy: There were a few that closed. Github needs to be adjusted to allow the
person who entered the issue to re-open it if they feel it was not properly
handled. My apologies, I thought the issues had been addressed. I'll
re-open those that need to be.

Michael: We need full discussion.

Drummond: What is "full discussion"?

Michael: Consensus is different than majority rule. Most issues were
handled well. A few with specific unaddressed comments should be reopened.
Action Items

# AMY: Re-open issues that have been closed so they can be fully discussed.