22:06:09 RRSAgent has joined #did 22:06:09 logging to https://www.w3.org/2021/03/23-did-irc 22:06:11 Zakim has joined #did 22:06:23 manu: I'll do it 22:06:26 brent: Thank you 22:06:28 present+ 22:06:30 present+ 22:06:33 Topic: Special Topic Call 22:06:34 brent: Next topic: 22:06:35 scribe+ cel 22:06:52 brent: starting with agenda review 22:06:57 brent: plan for it to be a test suite working session. if you have been assigned normative statements to turn into tests 22:07:00 ... starting about the special topic call, 22:07:03 ... giving brief overview of our timeline, where we are in the process of creating a recommendataion, ... 22:07:05 ... and process moving forward 22:07:09 ... then talk about resolutions made during the did spec registries 22:07:13 ... then talk about testing of the did spec - as primary topic of the day 22:07:18 ... Does anyone have any questions or items to add to agenda? 22:07:20 present+ 22:07:23 drummond: No, looks really good 22:07:28 brent: Now we are on to introductions and reintroductions 22:07:31 ... asking joakim 22:07:34 agropper has joined #did 22:07:35 joakim: ... R&D, machine learning engineer, 22:07:39 ... working in car signal and related analytics 22:07:41 present+ 22:07:43 brent: Welcome 22:07:45 present+ 22:07:48 ... for reintros, asking Orie 22:07:52 Orie: I'm Orie Steel, CTO at Transmute. I work on DIDs, VCs and supply chain traceability 22:07:56 brent: Thank you, Orie. Next topic... 22:08:03 Topic: Special Topic Call 22:08:10 brent: plan for it to be a test suite working session. if you have been assigned normative statements to turn into tests 22:08:16 manu: we are caught up. 22:08:20 rrsagent, draft minutes 22:08:20 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html manu 22:08:23 brent: Thank you. Apologies for the delay 22:08:26 rrsagent, make logs public 22:08:29 rrsagent, draft minutes 22:08:29 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html manu 22:08:36 brent: Minutes in IRC serve as minutes for the meeting; want to have them correctly scribed. 22:08:48 ... Special topic call is this coming thursday at I believe noon eastern time. 22:08:59 shigeya has joined #did 22:09:01 i/Next topic:/scribe+ manu/ 22:09:03 rrsagent, draft minutes 22:09:03 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html manu 22:09:06 ... Please come if you are contributing to the test suite, especially if you have been assigned to write tests for normative statements 22:09:07 burn has joined #did 22:09:11 Topic: Timeline - where we are 22:09:14 ... Any questions on the special topic call before we move forward? 22:09:16 present+ 22:09:17 present+ 22:09:22 present- shigeya_ 22:09:29 https://docs.google.com/presentation/d/1nSLk3cwJ8CanDoMLsO_JS3-ltBEeM8HZVXSsAZbrIl4/edit#slide=id.p 22:09:29 s/manu: I'll do it// 22:09:38 s/brent: Thank you// 22:09:41 rrsagent, draft minutes 22:09:41 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html manu 22:09:48 ... This is a single slide. Anyone can view it. 22:10:12 ... which I am sharing on my screen, which is this ... where we are, where red circle is. Entered CR as of March 2021 22:10:26 ... Working backwards from end of WG, need to have a rec by September of this year 22:10:37 ... which means our proposed recommendation needs to be in place by August 2021 22:10:51 That means that if we are going to go through another CR phase, the last opportunity we will have to do that happens in June of this year 22:11:11 ... So if there are substantive changes that need to be changed in the spec to address feedback from implementers of the test suite, need to have them in by June 22:11:19 ... This means we must have the test suite done as soon as we can. 22:11:27 q+ 22:11:39 ack manu 22:11:40 ... Please add yourself to Q if you have questions. We have time for a second CR if necessary, but only have a couple of months to get there 22:12:00 please review https://github.com/w3c/did-test-suite/pulls 22:13:15 manu: This past weekend I was able to implement all core properties tests, all conforming producer tests, JSON-LD productiona dnc consumption tests. I think that is the magority of the core of the specification now testable; added a did:key impleementation and will add two more implementations. Good news: got through all tests without needing a second CR. Things could have gone really wrong and 22:13:17 they didn't. now biggest sections concerned about are the DID resolution and DID URL dereferencing sections 22:13:20 Topic: Process moving forward 22:13:26 brent: Thank you for writing tests. 22:13:59 Meeting: DID WG Asia-Pacific Telecon 22:14:06 rrsagent, draft minutes 22:14:06 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html manu 22:14:07 Chair: Brent 22:14:50 brent: Our process moving forward will be similar to as thus far. we are going to respond to issues with PRs. As those PRs come in, we are going to determine through consensus whether we are going to merge them in or now. Slight change: as PRs come in, we need to determine whether the changes they propose are substantive changes, = one that would require an implementer to change their 22:14:52 implementation. It may involve normative statements 22:15:16 burn: we are trying to restrict ourselves to nonsubstantive changes. something that would break the spec if we don't change it. 22:15:30 kdenhartog has joined #did 22:15:45 ... not talking about something not ideal, but if something fundamentally broken, we must fix it. Could happen if we discover we did not put in a distinguish needed to implement, or something that cannot be implemented that way 22:15:50 present+ 22:15:53 present+ joakim 22:15:56 present+ Orie 22:15:57 ... Our goal is not to do that unless it is critical 22:16:00 present+ drummond 22:16:02 rrsagent, draft minutes 22:16:02 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html manu 22:16:08 ... Even if we have a second CR, the smaller such changes the better 22:16:08 present+ 22:16:25 Topic: DID Spec Registries resolutions 22:16:52 brent: During a special topic call, a number of resolutions regarding DID Spec Registries were made. This is primarily an informative step here 22:17:07 also this big cleanup PR should be merged asap: https://github.com/w3c/did-spec-registries/pull/269 22:17:09 ... but our process does allow for ... statements 22:17:20 since it will cause lots of merge confs if it lingers 22:17:32 https://www.w3.org/2019/did-wg/Meetings/Minutes/resolutions 22:17:43 ... Here is the link to resolutions we made 22:17:52 https://www.w3.org/2019/did-wg/Meetings/Minutes/resolutions#resolutions-taken-at-working-group-topic-calls 22:18:00 ... The resolutions we are specifically talking about right now is further down the page ^ 22:18:10 ... We have resolution 1 2 and 3 at top of 2.1.2021 22:18:21 Resolution 1 ... 22:18:43 change provisional to "Provisional. + YYYY-MM" so that date of registration can be used to sort 22:18:49 brent: First resolution was this ^ 22:18:57 brent: Second resolution was somewhat related... 22:18:58 Update the registration table to include, status, first registered date, last reviewed date 22:19:08 q+ 22:19:26 ack kdenhartog 22:19:29 ... so that in addition to having a status, we would not when the DID method showed up in the registry and the last time it was reviewd 22:19:44 kdenhartog: do we want that only for a DID method? 22:19:52 ... I'm fine to add all these things for everything registered 22:20:08 q+ 22:20:23 ack manu 22:20:27 brent: I think that is an excellent question, ... to discuss in issues. These resolutions open the way for that to happen, but not necessarily. These resolutions are around DID method registration 22:20:27 q+ 22:20:47 manu: Some of the things don't necessarily apply to some of the other entries in the registries 22:20:56 third resolution: create a new table for 1.0 conformant methods registered after the spec is published 22:20:58 ... The biggest thing was for DID methods. We could talk about other things in a future call 22:21:01 +1 agree Manu for case by case basis. Let's start with did methods and I want to consider adding to others after 22:21:29 brent: Once we have a spec, DID methods would need to either re-register, or at that point register to be added to a list that is methods conformant to the recommendation 22:21:49 ... Because the current list of registered DID methods - we don't have assurance that those are or will be conformant to the recommendation once its published 22:21:51 q+ 22:21:59 ack drummond 22:22:00 https://github.com/w3c/did-spec-registries/issues/266 22:22:07 drummond: There is the issue that has been started ^ 22:22:26 ... I wrote several things right after that call, just to bring to folks' attention. This process to go beyond provisional is written up... 22:22:42 q+ to ask about dynamic table re-ordering "sort by column x" functionality 22:22:46 ... I've written up a set of ideas and thoughts coming out of that special topic call discussion. Ivan has added some notes from the minutes of that meeting 22:22:57 q- 22:23:02 ack kdenhartog 22:23:03 ... I invite any member of the WG. It's pretty well-spelled out 22:23:09 ack TallTed 22:23:09 TallTed, you wanted to ask about dynamic table re-ordering "sort by column x" functionality 22:23:29 TallTed: When we made that first resolution, I was thinking the table was dynamically sortable, which it seems it is not 22:23:37 ... The second resolution ... probably don't need that 22:23:43 q+ 22:23:56 ack justin_r 22:23:56 ... Is it possible to make that table a sortable thing? For someone coming to the page, being able to sort would be helpful 22:24:36 justin_r: I have not looked at what is generating that page, but there is a fantastic JavaScript library known as DataTables, set up to do exactly that kind of thing, sortable tables. I have used it on a number of projects, and recommend looking into it 22:24:43 TallTed: Key question is whether Respec can do it 22:24:46 brent: I'll make a note 22:24:58 justin_r: I didn't realize we were using Respec; apologies 22:25:16 brent: Made note to ask Ivan about tools for dynamically ordering tables 22:25:25 ... I agree the first resolution is somewhat subsumed by the second. 22:25:33 Topic: Testing the DID Spec 22:25:50 s/... The second/... Given the second/ 22:25:50 q+ to go over open PRs 22:26:07 ... I think I put the wrong link in the agenda 22:26:13 https://github.com/w3c/did-test-suite/pulls 22:26:23 ack manu 22:26:23 manu, you wanted to go over open PRs 22:26:31 manu: On the PRs: I've got a question for the group 22:26:42 ... The question is how quickly can we merge these things in 22:26:57 ... We have tests and certain implementaitons. If we fall bac to the way that we work with the spec, it could take a long time. I would like us to iterate faster 22:27:10 ... Meaning that hopefully it becomes very clear that there is an issue on a particular test 22:27:23 ... I wonder if we can use Issues to iterate quickly, vs. standards and consensus-making process 22:27:28 +1 for using GH issues to move test suite 22:27:36 ... Difficult on a test suite - it has a lot of code, difficult to follow if don't read code 22:27:57 ... Can we merge when at least 2-3 implementers have looked at, and have all tests passing? Or are we expected to wait for objections? 22:28:01 q+ 22:28:08 ack markus_sabadello 22:28:28 markus_sabadello: I think it's fine to manage the process through GitHub and make progress and merge things without necessarily having to discuss everything on a call 22:28:30 +1 to managing the process through github 22:28:31 q+ 22:28:38 ... I would suggest we have a minimum time before merging 22:28:52 ... Would not like to see something merged after 2 days if just 2 people approved it... that would be too fast I think 22:29:04 ... In previous test suite work I have had some problems, misunderstandings 22:29:11 +2 to managing the process through GitHub. Suggest that editors propose something 22:29:13 ... Maybe we do it like that with a ... 7 day period or so 22:29:15 ack burn 22:29:31 burn: I've seen this done in a number of groups. The spec statements are normative; the tests are not 22:29:57 ... Obviously we are using the tests to demonstrate the spec is implementable. Assumption of correctness. But most groups do not go through an excruciatingly detailed process around tests 22:30:00 q+ to propose something. 22:30:07 ... Usually the problem is to get people to write tests, and look at them 22:30:19 ... The chairs ... you guys need to agree on something 22:30:33 ... If there is something grossly wrong, that it is not ignored. Most of the group will not be reviewing tests in any detail 22:30:39 ack manu 22:30:39 manu, you wanted to propose something. 22:30:41 brent: I agree 22:30:45 brent: +1 to that 22:30:50 manu: +1 to that 22:31:25 manu: don't want things people disagree with to stick around. 7 day wit period for tests... what I was not looking for ... not conducive ... drag out forever. we have a tight turnaround 22:31:35 ... We will not exit CR if people disagree about tests 22:31:46 ... will not able to address CR unless we address ... issues 22:32:03 q+ to mention how questions about the suite itself emerge 22:32:03 ... My suggestion is either get 3 people implementing to give a thumbs up on test, then can merge; 22:32:13 ... Or after 7 days with the same amount of support 22:32:39 ... to be clearer: 3 implementers +1 means gets merged, minimum 2 days 22:32:54 ... if don't have that, as long as Orie approves, at 7 days can merge 22:32:56 ack brent 22:32:56 brent, you wanted to mention how questions about the suite itself emerge 22:33:34 brent: In the past, with test suites, it's when an implementation is submitted and a test either passes or doesn't pass (that the implementer expects to go the other way) - using the test suite is often the process where errors may emerge 22:33:50 ... Agree that PRs being merged more quickly than not - doesn't mean that errors will not be fixed 22:33:54 q? 22:34:02 ... Often the best people to judge are the editors and implementers 22:34:10 manu: Curious to hear from markus_sabadello 22:34:22 brent: would you opposed to the process manu outlined? 22:34:38 markus_sabadello: two days is very short. there is a difference between adding a substantial new test suite and fixing smaller things 22:34:52 ... Previously I looked at production and consumption, and I disagreed with how the tests were written 22:35:08 ... Felt like if tests are merged after 2 days and something wrong, would have been better to discuss more 22:35:15 ... But don't want to block things and hold things up 22:35:21 q+ 22:35:26 ... I'd rather have more time, but ... 22:35:28 ack shigeya 22:35:47 shigeya: How about if we are going to extend the review period more than 2 days if anyone lays concern 22:36:02 ... If something difficult, someone thinks needs more review, can extend more days for reviewing it 22:36:06 +1 to Shigeya's suggestion 22:36:08 markus_sabadello: Sounds good 22:36:27 shigeya: We can add whether the PR is complex or not enough, can look at it and quickly determine whether need more time 22:36:29 +1 to Shigeya's suggestion (as rephrased by Orie) 22:36:32 Merge after a rolling 2 days without objection (i.e., since last change to the test PR), seems reasonable. 22:36:33 brent: Good suggestion 22:36:40 ... Any more questions and comments? 22:36:58 https://github.com/w3c/did-test-suite/pulls 22:37:00 ... Manu, want to go through PRs individually? 22:37:07 https://github.com/w3c/did-test-suite/pull/34 22:37:10 manu: here is the URL 22:37:16 ... This is a call to review or object 22:37:22 ... Charles' PR. out there for 15 days 22:37:42 ... Meant to fix a number of items in the test suite having to do with camel case, versionTime, etc. Has two positive +1s 22:37:58 ... Good example of something to merge immediately. No one voted against it. Orie and I think it should be merged 22:38:17 ... Let's try with what we were talking about - this would have been merged. Would anyone object to it being merged? #34 22:38:26 +1 to merging 34 22:38:31 +1 22:38:33 ... We're seeing if anyone has any issues with it 22:38:38 brent: I am hearing no objects 22:38:46 https://github.com/w3c/did-test-suite/pull/37 22:38:56 manu: That is going to be merged when the editors get around to it 22:39:41 ... Next is #37. Raised by Joel. New tests for metadata properties. Also fixed a couple issues with the test suite - contentType, DID Resolution metadata, stuff like this. Two positive +1s by Orie and myself. Out there for 4 days. 22:39:52 ... What did we say... sit for 7 days and then merge? 22:40:05 brent: At least one more reviewer giving a +1 and we would be able to merge it 22:40:20 manu: If you want to review, this is it. There we go, Ted, thank you, approved the changes. This will go in 22:40:34 ... Three positive reviews. Any objections? If get objection, would hold off 22:40:39 brent: I'm hearing no objections 22:41:02 burn: to be clear, it is no objections for 2 days. But it has been out there for a while and I think it is fine to ask on the call as you are doing 22:41:09 https://github.com/w3c/did-test-suite/pull/38 22:41:11 manu: Agreed. This process is a little shaky since we just agreed to it 22:41:18 manu: Next: PR 38. A big PR. 22:42:16 ... I would hold off for a little while before merging this, because it tests all of the DID Core process. There are 40-50 tests in here. Might be good for people to take a look at it. Honestly, the way people would see stuff go wrong is they go add theiri DID method and it fails... "Wait a second, I should be passing section ... DID Controller" Then they see ... didn't implement correctly 22:42:36 ... Typically when people discover issues with the tests, they discover it when they go to add their DID method 22:42:50 ... I would hold off on merging this until the end of this week and 3 people approved 22:43:01 ... Not going to ask for objections; people couldn't reasonably review it on the call 22:43:20 ... A lot of questions on this PR that I raised for Orie. Might be good to share your thinking on how this work. And Ted. 22:43:41 for the record I agree with Ted 22:43:45 ... Previously, Orie had said these are vendor tests, Ted said is about implementations. I believe the test suite is now implementation-based 22:43:53 ... One thing tried out is specify the implementation... 22:43:56 Implementations can be specified like so: "did:key - 2018 Ed25519 cryptosuite - did-key-js - Digital Bazaar" 22:43:58 and am greatful for the recommendation and feedback. 22:44:30 ... I did an implemntation of did:key with 2018 Ed25519 cryptosuite for the did-key-js library by Digital Bazaar. That is how you tell people that's the DID method that you are testing. did:key is an interesting example of that because we have multiple did:key implementations. 22:44:35 q+ 22:44:40 ack Orie 22:44:40 q+ 22:44:46 ... Orie, did you see any issues with doing that; Ted, does that address your concerns?D 22:45:11 Orie: I don't, assuming it gets reviewed positively. I agree with what Ted said about implementations; we are starting to have multiple implementations of the same ... by different vendors 22:45:28 ... Think it is important to test multiple implementations by different folks for the same DID method... however we structure it. 22:45:38 ack TallTed 22:45:42 ... Generally +1 to your PR manu, we'll see if it gets merged 22:46:13 TallTed: I think the general motion is going in the right direction. This boiler plate needs to be translated to a boilerplate so it is clear what is in the columns. That is product you are producing as Digital Bazaar? 22:46:19 manu: It's a library we are producing. 22:46:32 TallTed: the product name. Seems like one library ... product 22:46:33 q+ 22:46:38 +1 there needs to be a way to tell differences 22:46:49 q+ 22:46:49 ... Seems like need a way to differentiate implementations by a vendor... or all the complementary implementations of a given method 22:47:00 a better solution might be to formalize metadata, like github repo, company website, etc... 22:47:08 ack manu 22:47:08 manu: +1, need to be able to differentiate implementations; even multiple implementations within the same product within the same vendor 22:47:15 ... think we have a path there with this proposal 22:47:21 ack kdenhartog 22:47:30 q+ 22:47:36 kdenhartog: What's our take on when we are reusing libraries? Think will be common with the new Indy DID method 22:47:51 q+ regarding shallow forks 22:47:55 ... For us, we will reuse implementations if they are out there. Do we consider it a different implementation? 22:47:58 q+ to regarding shallow forks 22:48:02 ... Or if because that library is conformant, we are also conformant? 22:48:04 ack manu 22:48:44 manu: Nuance: if all you are doing is taking someone else's library of the shelf and reusing it, you are not a separate implementations. Those cannot be counted as independent implementations. But if you are taking someone's library and doing something significant (hand-wavey) then it may be considered an independent implementation 22:49:01 q+ to say that all tested implementations may not be "independent" implementations 22:49:14 ... We have to be careful. This is about DID Document: if you are not doing anything different to the way the document is generated, it would be hard to argue it is an independent implementation if you are reusing that code path. 22:49:24 q+ 22:49:27 ... We should be careful. People are going to scrutinize the implementation. 22:49:30 ack Orie 22:49:30 Orie, you wanted to regarding shallow forks 22:49:56 Orie: Yeah, I've come across this in a couple other areas, in particular student competitions - for code reuse, students will use a straight-up copy to win a competition 22:50:21 ... Typically, folks who manage the registration of the implementation will at regular intervals review the source behind implementations; often flag or disable entries too close to others 22:50:35 ...Starcraft ... most folks publish code with license forbidding submitting shallow forks without consent 22:50:55 ... The burden is on folks reviewing submissions to look at the code if available. If available and a very shallow fork, to flag in some way 22:51:18 ... But for code that is proprietary, absolutely know way to tell. Need to be transparent to evaluate, folks asserting what library they are using 22:51:28 ack brent 22:51:28 brent, you wanted to say that all tested implementations may not be "independent" implementations 22:51:35 ... At end of day what we are doing is submitting test fixtures. You can totally cheat - I expect people will 22:52:07 brent: All the tested implementations may not be truly independent implementations. Even if not fraud, it can be multiple implementations... it's complicated, but I think we will be able to clearly see that everything has been implemented the way it needs to 22:52:08 ack kdenhartog 22:52:34 kdenhartog: I was going to bring up the proprietary factor. We are that our customers are getting standards based implementations. 22:52:52 ... whether or not we should submit ... Sounds like ... I'll let you guys know 22:53:01 q? 22:53:01 thanks 22:53:02 manu: When in doubt, ask questions: always a good strategy 22:53:35 manu: Other things from that PR: when you write a test, put the section number and title before each test, so people testing know what they are passing 22:54:08 ... i.e. in your test text, don't put "the value must be a string, ..." - that doesn't tell people where. Instead put "5.1.1 DID Subject ... normative language". Examples already there, trying to set up best practices there. 22:54:18 ... Everything else is stuff we can clean up in the test suite 22:54:52 ... I believe we want to make it easy for people to write/submit DID documents. Currently there is this deeply nested structure 22:55:19 Orie: The original structure of the tests was based on the idea that you would be providing some structured data in the same format, and then the tests would iterate that structured nested data and find the parts that need to be tested. 22:55:41 ... I shamelessly copied the integration tests from our did:key implementation, that uses a structure to allow us do testing with that... there were no objections 22:55:51 ... Whatever solutions we pick, that problem will have to be implemented 22:56:12 ... I suspect there will be some dependency on the structure of the fixtures. You will need to bind your input to a fixture structure in order to pass the tests. 22:56:18 q? 22:56:19 ... You'll encounter these problems are you start to write tests 22:56:57 manu: I think the structure is fine. it didn't take a lot of effort. I didn't read any documentation; felt self-explanatory. 30 minutes of frustration until figured it out, then fairly easy. Think it's fine and fairly workable. Only other thing... 22:57:18 ... The tests are weird and repetitive - because we are testing statements - effectively writing a linter - or JSON Schema 22:57:45 ... Because we are trying to tell people exactly what part of the specification their DID method does not conform to ... something to keep in mind 22:58:52 ... "Why not just use JSON Schema" is a valid thought... Welcome to testing specifications instead of implementations 22:59:13 Manu has regrets for Thursday -- Jury Duty again. 22:59:33 rrsagent, draft minutes 22:59:33 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html manu 22:59:49 @kyle - good suggestion on the thread on DID method specification registration proposals 23:00:00 I'm responding now 23:00:01 zakim, who is here? 23:00:01 Present: TallTed, cel, agropper, brent, shigeya, burn, manu, joakim, Orie, drummond, kdenhartog 23:00:04 On IRC I see kdenhartog, burn, shigeya, agropper, Zakim, RRSAgent, Orie, GeunHyung_Kim, joakim, drummond, brent, markus_sabadello, justin_r, cel, faceface, bigbluehat, dlehn, 23:00:04 ... hadleybeeman, dlongley, manu, ChristopherA, wayne, Travis_, rhiaro 23:00:44 zakim, end the meeting 23:00:44 As of this point the attendees have been TallTed, cel, shigeya_, agropper, brent, shigeya, burn, manu, joakim, Orie, drummond, kdenhartog 23:00:47 RRSAgent, please draft minutes 23:00:47 I have made the request to generate https://www.w3.org/2021/03/23-did-minutes.html Zakim 23:00:49 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 23:00:53 Zakim has left #did 23:00:58 rrsagent, bye 23:00:58 I see no action items