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

Hey folks,

Logs for both calls from IRC are here:
https://w3c-ccg.s3.digitalbazaar.com/minutes/2019-03-21-irc.log Thanks
to Dave Longley for activating the bots to generate these!

Cheers,

Amy

On 22.3.19. 00:49, =Drummond Reed wrote:
> 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 2019
>
>
>     Attending
>
>  *
>
>     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.
>
>
>
>
>
>
>
>
>
>
>

Received on Friday, 22 March 2019 09:04:36 UTC