- From: Markus Sabadello <markus@danubetech.com>
- Date: Fri, 22 Mar 2019 11:44:57 +0100
- To: W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <62eaf019-4f5b-06ab-2baf-bcaedb460cd5@danubetech.com>
Zoom recording and chat logs for this week's DID Spec Community Final Draft Meeting are here: https://github.com/w3c-ccg/meetings/tree/gh-pages/2019-03-21-did-spec Markus On 3/22/19 10:04 AM, rhiaro wrote: > 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. >> >> >> >> >> >> >> >> >> >> >> -- all the best, Markus Sabadello Danube Tech ~ danubetech.com Sovrin Foundation * sovrin.org +43 664 3154848
Received on Friday, 22 March 2019 10:45:29 UTC