14:33:45 RRSAgent has joined #did 14:33:45 logging to https://www.w3.org/2021/05/04-did-irc 14:33:48 RRSAgent, make logs Public 14:33:48 please title this meeting ("meeting: ..."), ivan 14:33:53 Meeting: DID WG Telco 14:33:54 Chair: brent 14:33:54 Date: 2021-05-04 14:33:54 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Apr/0040.html 14:33:54 ivan has changed the topic to: Meeting Agenda 2021-05-04: https://lists.w3.org/Archives/Public/public-did-wg/2021Apr/0040.html 14:53:51 brent has joined #did 15:00:36 present+ 15:00:40 present+ 15:00:42 present+ brent 15:00:46 present+ shigeya 15:00:49 TallTed has joined #did 15:01:00 present+ cel 15:01:11 justin_r has joined #did 15:01:31 present+ justin_r 15:01:50 Geun-Hyung has joined #did 15:01:59 present+ chriswinc 15:02:06 present+ rhiaro 15:02:11 present+ Geun-Hyung 15:02:30 present+ 15:02:33 present+ 15:03:55 present+ TallTed 15:04:25 present+ drummond 15:04:42 drummond has joined #did 15:05:00 scribe: cel 15:05:17 brent: first topic: agenda review, along with intros and reintros 15:05:31 ... announcing special topic, brief test coverage report. 15:05:43 ... then jump into conversation about additional notes our group hoping to publish - impl guide and rubric 15:05:47 present+ dmitriz 15:05:56 ... then go through did-core PRs, issues. any questions, suggestions, changing/adding to agenda? 15:06:03 chriswinc has joined #did 15:06:14 dmitriz has joined #did 15:06:24 Topic: special topic call 15:06:30 Topic: Special Topic Call 15:06:35 ... We know eachother well enough - skipping reintros. Moving on... 15:06:45 ... Special Topic Call: 12pm eastern time - DID Rubric 15:06:57 ... We will be working on that document, refining it, feedback, making progress. 15:07:11 q+ to report out on test suite 15:07:14 Topic: Test Coverage Report 15:07:16 ... Thursday 12pm Eastern 15:07:21 ack manu 15:07:21 manu, you wanted to report out on test suite 15:07:22 ... Now we have a brief test coverage report. 15:07:45 manu: Over the past month and some change, there have been a number of people implementing tests in the test suite. Thank you to everyone who has submitted tests. 15:08:01 https://github.com/w3c/did-test-suite/issues/72 15:08:01 ... Linking to a couple of things... First item: set of issues tracking the test suite audit. 15:08:40 ... Issue 72: Amy went through latest specification. This includes latest PRs merged. Went through every normative statement in specification, pulled out by section, created checklist, to ensure every statement intended to test has a test in the test suite. 15:08:48 present+ by_caballero 15:08:59 agropper has joined #did 15:09:00 present+ 15:09:05 present+ 15:09:07 ... Editors and contributors have gone through checklist for every test, checked boxes felt needed to check; have not checked boxes for SHOULD/MAY statements, or human-testable statements. 15:09:18 ... Have completed that as of Sunday. Done full audit pass through specification. 15:09:29 ... We have tests for everything we believe we wanted to test, except for the CBOR section. 15:09:38 present+ agropper 15:09:40 ... No tests for the CBOR section - they have not been submitted. Today is cutoff day. 15:09:45 ... Everything else includes tests. 15:09:55 ... Issues 72 through 77 cover those tests. 15:10:01 ... I believe the audit is complete at this point. 15:10:07 ... Question: what to do about the CBOR section. 15:10:32 ... We did find a couple tests missing, a handful; language had changed, not reflected in tests. There are new PRs in to fix all of those omissions/errors. 15:10:45 ... Haven't pulled in PRs yet but they have reviews; waiting a couple days before merging. 15:10:48 jonathan_holt has joined #did 15:10:53 ... That's where we are. All documented in issues. 15:10:54 q? 15:11:24 brent: Chair things. 15:11:36 brent: On the 13th of April, the chairs set a deadline for tests to be written. 15:11:37 https://www.w3.org/2019/did-wg/Meetings/Minutes/2021-04-13-did#section4 15:12:06 ... for the end of April - and stated at that time that any normative statements that were untestable because no tests were written, would have to be removed from the specification. 15:12:18 ... What this means for group is need to decide what to do with the CBOR section. 15:12:18 https://github.com/w3c/did-test-suite/issues/28 15:12:27 ... Issue where CBOR production/consumption rules discussed ^ 15:12:42 burn has joined #did 15:12:44 https://www.w3.org/2019/did-wg/Meetings/Minutes/2021-04-08-did-topic 15:12:46 ... It is clear from those comments that the concerned parties were aware of the need for tests to be written. There was also a special topic call on the 8th of April ^ 15:12:57 ... that focused primarily on the CBOR section and how to test it, with concerned parties. 15:13:27 ... I outline all of this to make very clear that communication has been clear, and that all efforts have been made, as chairs and editorial staff, to encourage the writing of these tests. 15:13:32 present+ burn 15:13:39 present+ 15:13:47 ... With all of that said, we have some options, and will write these up as formal proposals once we get feedback from group. 15:13:59 ... Option 1: remove CBOR from DID Specification, and publish it as separate note. 15:14:10 ... Option 2: Remove CBOR from Specification to appendix of specification. 15:14:17 ... Option 3: remove it and don't do anything 15:14:19 move to appendix -> move to informative appendix 15:14:23 ... My encouragement is to strongly consider option 1. 15:14:25 q+ 15:14:31 ... Opening to group for comments/suggestions. 15:14:32 ack justin_r 15:14:52 present+ 15:15:06 justin_r: My concern for CBOR section as forcing function ... interoperability ... make JSON-based spec... 15:15:40 +1 option 1 .. makes sense as a note, which can be linked to from the registries, as any representation spec would be 15:15:47 ... Of options, I think 1 is best (don't know if we are debating that) but concerned that publication as note would give less weight to the specification, and allow it to be functionally ignored by other components, for example the registries, which could morph in such a way to shut out CBOR or other representations. 15:16:03 brent: For record, I agree with you for my motivations for a CBOR section 15:16:16 q+ to agree with Option 1 as best-worst option, new format in registries. 15:16:22 ack manu 15:16:22 manu, you wanted to agree with Option 1 as best-worst option, new format in registries. 15:16:23 ... Another option: to remove CBOR from spec, and change registries so that it can be registered as a new format in the registries. 15:16:45 manu: I agree with Justin's sentiment; I think it becomes fairly difficult to argue... we had an ADM so we could do things like CBOR 15:16:52 ... But where we are is not tests... 15:17:01 We have always said that new representations should be able to be registered in the DID Spec Registries. 15:17:20 ... I don't think anyone is actually implementing CBOR, they are doing variations on it. Digital Bazaar had: we are interested in CBOR-LD; would be interested in publishing as note. 15:17:42 ... danger of publishing CBOR as it is, it's a bit of an examplar - no one deploying it. would end up publishing note that no one intends to implement. 15:18:07 ... Biggest problem is it's in spec, but no tests, not implemented. I would be supportive of publishing as note, noting no one has implemented tests or implemented it. 15:18:11 q+ 15:18:25 ... Noting ... different implementation like CBOR-LD would be better, but not volunteering. 15:18:35 ... Having example of alternative in registry is a good idea. 15:18:47 ack ivan 15:19:23 ivan: Just an additional point to what was said before: it may be still too early to talk about the details, but at some point in time in the coming months, we have to begin discussing how we imagine the world post this WG. What kind of continuation, etc. 15:19:49 ... It would be possible to say that in maintenance WG following this one, we put CBOR (or CBOR-LD, etc) as potential agenda item. 15:20:00 ... so to try to message community beyond the note, that we haven't given up. 15:20:16 ... We have to do what we have to do now, but long-term this group still intends to have CBOR coming at some point, when it's ready. 15:20:38 brent: Comments, suggestions? 15:21:23 q+ 15:21:28 ... Please suggest alternate proposals if needed to +1. More detail needed? 15:21:31 q+ 15:21:39 ack drummond 15:21:40 ... Add Ivan's suggestion that it should be input to WG? 15:21:53 drummond: I'd love it for someone to speak to option 2, the appendix, the +/- of that. 15:22:14 ... My understanding is we are going to have/allow/provide for did-spec-registries to registry new representations, like for other things. 15:22:30 q+ 15:22:30 q+ to talk about registry requirements 15:22:32 ... It could be a path for that. What is the relationship of publishing as note or in appendix, or as requirement for registry? 15:22:36 q- 15:22:40 ack ivan 15:23:09 q+ to speak to not doing it in registry, volunteer. 15:23:11 ivan: Slight reservation about having as note because of time, is do we have someone who will volunteer to write that note? 15:23:15 ack justin_r 15:23:15 justin_r, you wanted to talk about registry requirements 15:23:34 justin_r: My concern with moving out into note or other thing is that it could allow for greater wiggle room in the registry 15:23:44 ... since this group has insisted on making its own registries - than is potentially helpful 15:23:54 ... because then we are functionally creating an abstraction from a single data representation type 15:24:11 ... - yes there are differences between JSON and JSON-LD but these are bigger than JSON and CBOR (?) 15:24:42 ... Concern about ... constructs. Any CBOR representation would be prohibited from translating a object key(?) to an abstract property name 15:25:06 ... We need to maintain flexibilty... Concerned that without the weight of CBOR as first-class citizen, the registry could easily slip away from enabling that. 15:25:19 ack manu 15:25:19 manu, you wanted to speak to not doing it in registry, volunteer. 15:25:37 manu: I'll volunteer to move the spec test. It was written to be easy to move into a note. 15:25:48 ... I note that in the registries we have a section for representations that is empty right now. 15:25:56 ... Having the CBOR note would allow us to point to that. 15:26:15 wait, but like.. the whole issue with the CBOR section is that nobody's put forth the implementations, test suite, etc. So regardless of if we're worried about its effect on the Registries, etc.. not much we can do here 15:26:21 ... To Justin's concerns: none of the spec test will change in any dramatic fashion. All the work done to ensure things like translate to binary and round-trip - text remains. 15:26:28 ... Exists in other sections that will be kept. 15:26:36 ... Some concerns others might not understand. 15:26:48 ... For example, CBOR-LD encoding depends on that language remaining. 15:27:01 ... DB uses it. 15:27:17 ... I would expect at least one editor to object to that language changing, so that it would enable CBOR-LD to exist 15:27:23 ... which has stronger needs than vanilla CBOR stuff. 15:27:32 FWIW I'm not concerned with core spec language changing, but with registry language itself, which is managed separately. 15:27:39 ... The CBOR-LD translation is a binary transformation from the ADM and back into the ADM. 15:27:51 ... I'm not concerned we will lose that, but there is a risk - not sure what to do 15:28:04 ... I don't think the registries will be affected. 15:28:22 PROPOSAL: remove CBOR from the DID Core Specification, publish it as a WG Note, and add CBOR to the DID Spec Registries with a reference to the WG Note 15:28:28 +1 15:28:35 +1 15:28:36 +1 15:28:36 +1 15:28:40 +1 15:28:41 +1 15:28:43 +1 15:28:43 +1 15:28:44 +1 15:28:45 +1 15:28:58 +1 15:29:10 +1 15:29:26 RESOLVED: remove CBOR from the DID Core Specification, publish it as a WG Note, and add CBOR to the DID Spec Registries with a reference to the WG Note 15:29:49 brent: with sadness, resolved. 15:30:02 ... If there are no more questions or comments on that topic, we will move on to a brief conversation aobut notes 15:30:17 ... primarily the implementation guide, as the rubric we will talk about mostly on the special topic call. 15:30:18 Topic: Notes: Implementation Guide and Rubric 15:30:58 brent: Chairs would like to say: if we do not have anyone sign up to be an editor of the implementation guide by the end of May, then we're not going to have an implementation guide. 15:31:11 ... At the end of May (possibly sooner), we will be calling for a first public working draft of the rubric note. 15:31:26 ... I know that some work has gone into an implementation guide. Orie and possibly others have been collaborating on it. 15:31:41 https://w3c.github.io/did-imp-guide/ 15:31:59 ... If you look at the implementation guide ^, there is some content in there, that it may be worth keeping. 15:32:34 ... The clock is ticking... If anyone wishes the implementation guide to move forward and be publishable by the WG as a note, and you are willing to make that happen, please let the chairs know, so we can assign you as an editor and get that work accomplished. 15:32:49 https://w3c.github.io/did-rubric/ 15:32:52 Note that Orie also has a huge update to the implementation guide here: https://github.com/w3c/did-imp-guide/pull/3 15:32:54 brent: The rubric has had a lot of work going into it, and I understand more is underway. 15:33:10 ... So please, before our special topic call on Thursday, familiarize yourself with the rubric, so that we can get that wrapped up. 15:33:17 ... Any questions or comments about these notes? 15:33:36 ... Any volunteer to be an editor of the implementation guide? 15:33:38 Topic: https://github.com/w3c/did-core/pulls 15:33:39 q+ to note -- request for implementers 15:33:47 ack manu 15:33:47 manu, you wanted to note -- request for implementers 15:34:05 manu: Given where we are, that that proposal passed, that I believe means we are done with tests. 15:34:21 ... We have tests for everything we intended to tests, including DID resolution, dereferencing and other sections. 15:34:42 ... Test suite done at this point. Need people to submit implementations. Once PRs merged, good time to get people to submit implementations. 15:34:53 ... Good news: we have a bunch of GitHub handles for DID Method implementors. 15:35:03 ... Could ask them to submit implementations to test suite. 15:35:12 ... Are we moving on to that phase where we are requesting broad implementation? 15:35:14 brent: Yes, thank you. 15:35:32 ... The chairs had said mid-May for getting implementations in. I am affirming that, with Dan's permission. 15:35:44 ... Two weeks from today, we'll have another call, and by that meeting, implementations will need to be in. 15:35:55 burn: Perfect 15:36:30 burn: People can continue to send implementations after that date, but the reason giving that date is that that's when we will look to see if we have sufficient implementations to move on in the process. 15:36:47 q+ 15:36:49 ... If you know people who want to submit later, they can do that. Just don't wait - if everyone waits, we don't get to move on in the process. 15:36:52 brent: Agreed. 15:36:54 q- 15:37:14 q+ 15:37:30 https://github.com/w3c/did-core/pull/727 15:37:30 brent: Is there an editor who would like to run through the PRs. or the chairs to do it? 15:37:44 q+ 15:37:44 subtopic: @pr 727 15:37:50 ack manu 15:37:50 q- 15:37:50 manu: PR: simple update to the diagram that shigeya is doing on behalf of someone else who did a full review of the spec. 15:38:04 ... Their review came back with nothing really wrong. 15:38:17 ... PR is editorial. If you have opinion on the diagram label, please take a look. 15:38:34 ... There is going to be a large series of PRs coming up: editorial fixes, appendices 15:38:55 q+ 15:39:02 ack ivan 15:39:05 ... Editors will make a pass... Non-normative sections, not expecting a lot of discussion, just giving heads up, will be getting a lot of PRs about appendices. 15:39:20 ivan: There is one appendix which is still a thorn in our side: the IANA Considerations one. 15:39:21 q+ 15:39:39 ack manu 15:39:40 ... At some point we have to decide what to do with the did+ld+json stuff. We are getting dangerously close to have to make the decision. 15:39:52 manu: Thank you, Ivan. Amy and I have been moving that conversation along at IETF. 15:40:27 ... Issue is that a number of people have stepped in with comments, which is good... No clear path. people say it's fine, others saying what does it really matter - MIME type supposed to identify completely. 15:40:32 ... Haven't lit a fire yet 15:40:42 ... Initially they pushed back, wanted discussion. 15:41:00 ... No one is saying can't register these. Either will be a specification that talks about structured media types 15:41:11 ... or there won't be, but will be allowed to do it. 15:41:16 ... Just an opaque string. 15:41:19 ivan: There has been push-back 15:41:32 manu: There was, but we had the discussion. 15:41:32 q+ 15:41:53 ... People said there should be meaning to the multiple pluses. If no meaning, can register. If meaning, need spec. 15:42:06 ... That is my interpretation of what folks are saying there. 15:42:14 ... We need a decision; will outline what was said. 15:42:40 ... We can also speak to the Area Director about what the relevant path forward is, and say that the WG really needs a decision, give a concrete timeline. 15:42:40 ack ivan 15:43:04 ivan: I would propose first to wait for your overall editorial stuff, so that what we go to IANA with is as final text as possible. 15:43:20 ... Once that's done, we can just try to register the two media types. One is not a problem. The other... just see what happens. 15:43:20 q+ to agree with ivan 15:43:29 ... That's the only way; we have to do that before we go to PR - ASAP. 15:43:44 ... I don't really know the mechanism as IETF. I'll follow your lead on that manu, but we have to do it. 15:43:52 ack manu 15:43:52 manu, you wanted to agree with ivan 15:43:55 ... Aside: let's not forget, unfortunately, to remove the application for did+cbor 15:44:13 manu: Agreed. Not an IETF expert; Justin would probably no better. 15:44:32 ... Multiple plus signs: problem not going away. Other people have same requirement. Really does need to be pushed at IETF. 15:44:41 ... If not this, will be did+ld+cbor. 15:44:47 ... Will try to send email 15:44:55 Topic: DID Core issues 15:45:03 https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Adefer-v2 15:45:08 q+ 15:45:15 ack burn 15:45:28 burn: Sorry, this is the previous topic. manu, are there any tests that depend on this result (the registration)? 15:45:31 manu: Yes, there are. Good catch. 15:45:41 burn: Problem: implementation reports may change as the result of the outcome here. 15:45:48 It is marked at risk though 15:45:58 ooh good point rhiaro 15:46:02 ... We can still get implementations in; still valuable; but we may need to reach out to implementors if we need to make an adjustment. 15:46:20 brent: 11 open issues. First one: 15:46:32 subtopic: @issue 583 15:46:34 https://github.com/w3c/did-core/issues/583 15:46:52 q+ to make a general statement about open issues. 15:47:01 ack manu 15:47:01 manu, you wanted to make a general statement about open issues. 15:47:03 ... There has been a bit of conversation. Need a PR to fix issue. 15:47:24 manu: General statement: I triaged issue this past weekend, marked everything that was a CR comment. Marked anything ready for a PR as ready for PR. 15:47:33 ... Almost every one except 2 or 3 are ready for PR. 15:47:48 brent, I'm looking at 583 but I think I'll need help. Will ping people. 15:47:53 brent: If you haven't and always wanted to write a PR for a specification, we have a number of issues to choose from, and I encourage you to do so. 15:48:11 subtopic: @issue 625 15:48:12 https://github.com/w3c/did-core/issues/625 15:48:46 brent: I believe some work has gone into changing diagrams to SVG format. Or perhaps I am thinking of new diagrams that are SVG. 15:48:49 brent, descriptions are also on my radar if nobody else gets there first 15:48:53 ... We need detailed descriptions for each diagram. 15:49:08 ... Pretend that you are telling the diagram to someone who can't see - since that what this is for. 15:49:16 ... The technical level to contribute is low. 15:49:28 ... Currently assigned to Markus. 15:49:41 suptoc: @issue 707 15:49:42 https://github.com/w3c/did-core/issues/707 15:50:00 s/suptoc/subtopic/ 15:50:05 brent: I know that some changes have come in as a result of this. What more needs to happen? 15:50:20 https://github.com/w3c/did-core/issues/707#issuecomment-826382717 15:50:21 manu: I proposed for the publicKeyMultibase stuff a path forward in this link 15:50:47 ... It looks like folks want to use publicKeyMultibase instead of publicKeyBase58. We do have an at-risk marker that this may be done. 15:51:11 ... One thing could do: update examples. Already have in did-spec-registries, but could add note. 15:51:22 ... Add to registries, update material in spec. 15:51:29 ... Not normative. 15:51:32 q+ 15:51:39 ... Concerns raised about publicKeyBase58 applies to publicKeyMultibase as well. 15:51:44 is it not normative if it's in the registry as a value with a link to a spec? 15:51:52 ... I believe we can make these changes; haven't seen any objections. I will put in a PR shortly. 15:51:54 (actual question on W3C normativity) 15:51:54 ack ivan 15:52:12 justin_r: no, nothing in the registry is normative -- it's just "a helpful document for people that care to know about the ecosystem". 15:52:24 ivan: The vocabularies, the constraint languages, also have to updated. There are some contraints expressed using b58, not have to exchange that. JSON Schema, etc. 15:52:27 s/justin_r: no/justin_r, no/ 15:52:34 ... I'm happy to do that when we have the document done; just listing here to be done. 15:52:44 subtopic: @issue 712 15:52:56 justin_r, it's the specs themselves that make things normative or not. 15:52:57 https://github.com/w3c/did-core/issues/712 15:53:27 manu: Either Oliver will do it, or I will. 15:53:37 ... I'll add him as an assignee. 15:53:49 subtopic: @issue 721 15:53:57 https://github.com/w3c/did-core/issues/721 15:54:36 manu: There is enough there to write something. dbuchner wanted to expand it. Need to explain it; put in list of things to consider for DID method specification. 15:55:01 q+ to ask something new at end of call, need 2-3 mins 15:55:15 subtopic: @issue 724 15:55:17 https://github.com/w3c/did-core/issues/724 15:56:12 shigeya: I think it is resolved in the latest 15:56:20 brent: There is a PR for this; folks should review it 15:56:30 ack burn 15:56:30 burn, you wanted to ask something new at end of call, need 2-3 mins 15:57:03 burn: Because are ready to call for implementations right now, it would be appropriate to email out to the various organizations that we have communicated with at various stages in the process. Typically the chairs have done this, to email DIF, CCG, any other place as appropriate 15:57:28 ... Because we don't have a change in official status, but have completed tests: would like someone to volunteer to send out email to ask for implementations. 15:57:38 ... That email needs pointer for instructions on what to do. 15:57:44 https://github.com/w3c/did-test-suite/#adding-your-did-implementation 15:57:48 ... Any info for what they need to know needs to be included. 15:58:00 ... Alternatively if someone else can get that information, chairs could send it out. 15:58:04 q+ 15:58:11 ... A link is nice, if the link is completely self-contained and you believe it has everything necessary. 15:58:14 ack manu 15:58:15 manu: I believe it does. 15:58:37 ... It has instructions. If you are an implementor, this is how to submit your implementations. ... It should be straightforward and easy. 15:58:45 ... Others have done it, without the instructions. 15:59:06 burn: It's short... Anyone who is aware of the work should be able to follow and understand this. 15:59:11 ... The chairs will take that as an action. 15:59:18 brent: Thank you everyone. 15:59:37 rrsagent, draft minutes 15:59:37 I have made the request to generate https://www.w3.org/2021/05/04-did-minutes.html ivan 16:00:18 s/Anyone who is aware/The hope is that anyone who is aware/ 16:00:25 rrsagent, draft minutes 16:00:25 I have made the request to generate https://www.w3.org/2021/05/04-did-minutes.html burn 16:01:05 zakim, end meeting 16:01:05 As of this point the attendees have been ivan, manu, brent, shigeya, cel, justin_r, chriswinc, rhiaro, Geun-Hyung, TallTed, drummond, dmitriz, by_caballero, agropper, burn 16:01:08 RRSAgent, please draft minutes 16:01:08 I have made the request to generate https://www.w3.org/2021/05/04-did-minutes.html Zakim 16:01:10 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:01:14 Zakim has left #did 16:01:31 rrsagent, bye 16:01:31 I see no action items