14:36:29 <RRSAgent> RRSAgent has joined #did
14:36:29 <RRSAgent> logging to https://www.w3.org/2021/04/06-did-irc
14:36:31 <Zakim> RRSAgent, make logs Public
14:36:32 <Zakim> please title this meeting ("meeting: ..."), ivan
14:36:40 <ivan> Meeting: DID WG Telco
14:36:40 <ivan> Chair: burn
14:36:40 <ivan> Date: 2021-04-06
14:36:40 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Apr/0012.html
14:36:56 <ivan> ivan has changed the topic to: Meeting Agenda 2021-04-06: https://lists.w3.org/Archives/Public/public-did-wg/2021Apr/0012.html
14:36:57 <ivan> Regrets+ manu, brent
14:41:15 <yoshiaki> yoshiaki has joined #DID
14:56:44 <burn> burn has joined #did
14:59:28 <TallTed> TallTed has joined #did
14:59:32 <burn> present+
15:01:12 <justin_r> justin_r has joined #did
15:01:21 <chriswinc> chriswinc has joined #did
15:01:37 <GeunHyung_Kim> GeunHyung_Kim has joined #did
15:01:47 <rhiaro> present+
15:01:53 <GeunHyung_Kim> present+
15:02:08 <shigeya> present+
15:02:26 <cel> present+
15:02:43 <cel> yes
15:03:06 <ivan> present+
15:03:28 <ivan> zakim, who is here?
15:03:28 <Zakim> Present: burn, rhiaro, GeunHyung_Kim, shigeya, cel, ivan
15:03:30 <Zakim> On IRC I see GeunHyung_Kim, chriswinc, justin_r, TallTed, burn, RRSAgent, Zakim, tzviya, dmitriz, ivan, ChristopherA, dlehn1, wayne, faceface, shigeya, cel, bigbluehat,
15:03:30 <Zakim> ... hadleybeeman, dlongley, manu, Travis_, rhiaro
15:03:36 <markus_sabadello> markus_sabadello has joined #did
15:03:37 <burn> Topic: Agenda Review, Introductions, Re-introductions
15:03:38 <markus_sabadello> present+
15:03:42 <markus_sabadello> scribe+
15:03:55 <agropper> agropper has joined #did
15:03:59 <TallTed> present+
15:04:07 <markus_sabadello> Special topic call will be about W3C Notes we will be working on. Then we hope to get an update on DID Rubric, and status review of DID Rubric.
15:04:56 <markus_sabadello> s/Special topic call/today's call/
15:05:07 <markus_sabadello> Anyone joining for the first time? Anyone want to re-introduce?
15:05:14 <markus_sabadello> burn: Maybe Adrian?
15:05:32 <KelseyRhoda> KelseyRhoda has joined #did
15:05:33 <dlongley> regrets+ dlongley
15:05:40 <dmitriz> present+
15:05:48 <ivan> present+ TallTed, justin_r, adrian, KelseyRhoda, kristina
15:05:55 <markus_sabadello> agropper: I am around as Invited Expert on privacy and community issues. I'm volunteer CTO of Patient Privacy Rights, and also lead of a reference implementation of some of the SSI stuff, called HIE of One.
15:06:01 <jonathan_holt> jonathan_holt has joined #did
15:06:11 <ivan> present+ chriswinc
15:06:11 <markus_sabadello> agropper: One of my immediate goals is to harmonize IETF GNAP with data models of VCs and DIDs.
15:06:13 <burn> Topic: Special Topic Call
15:06:19 <drummond> drummond has joined #did
15:06:20 <ivan> present+ dmitriz
15:06:28 <drummond> present+
15:06:33 <markus_sabadello> burn: Special topic call will be on Thursday at noon US Eastern.
15:06:39 <markus_sabadello> burn: This will be a test suite working sessions.
15:06:41 <agropper> present+
15:06:48 <ivan> present+ jonathan_holt
15:06:50 <markus_sabadello> burn: Also if you're in the process of writing tests and need help
15:06:58 <markus_sabadello> burn: Last session on test suite was quite productive.
15:07:03 <burn> Topic: Additional Notes
15:07:28 <markus_sabadello> burn: We have two WG Notes: 1. DID Rubric, and 2. Implementation Guide.
15:07:43 <markus_sabadello> burn: There is a first draft of the Rubric document. I believe something has come in for the Implementation Guide.
15:08:02 <markus_sabadello> burn: People have expressed interest in the Imp Guide, need a draft by end of April.
15:08:20 <markus_sabadello> burn: If we do not have a first draft by end of this month, then as a WG we will encourage not to produce something.
15:08:39 <markus_sabadello> burn: We havent agreed on the PR as first draft, but there's some text to look at.
15:08:50 <markus_sabadello> burn: If you have any opinions, now is the time to contribute.
15:08:58 <burn> Topic: DID Rubric status update
15:09:25 <markus_sabadello> burn: Anyone know the status of the DID Rubric?
15:09:52 <markus_sabadello> dmitriz: I know that Joe &co are actively working on it. I reviewed one of the drafts. It is in progress.
15:09:59 <markus_sabadello> burn: But it's still not a first draft?
15:10:05 <markus_sabadello> dmitriz: Reach out to Joe, it might be ready for that.
15:10:25 <markus_sabadello> burn: We're at a point where it has to officially move into the group and become one of the WG items.
15:10:33 <markus_sabadello> burn: Otherwise we won't have time for the group to work on it.
15:10:41 <markus_sabadello> dmitriz: Do you mind emailing Joe?
15:11:00 <markus_sabadello> burn: The chairs will follow up on that.
15:11:02 <burn> Topic: Test Suite status review
15:11:15 <markus_sabadello> q+
15:11:23 <rhiaro> scribe+
15:11:28 <burn> ack markus_sabadello
15:11:45 <rhiaro> markus_sabadello: I was on the last special topic call where we made a lot of progress, merged all the PRs
15:11:52 <rhiaro> ... people have contributed a lot of work, multiple people have contributed not just one or two
15:12:05 <rhiaro> ... the PRs that have arrived pretty much cover all of the spec, or almost all of it
15:12:21 <rhiaro> ... what has to happen now is some restructuring and harmonisation because different test implementers becauseu people have approached it differently
15:12:27 <rhiaro> ... and there's a certain amount of duplication
15:12:30 <rhiaro> ... there oculd be code reuse
15:12:33 <rhiaro> ... that is expected at this stage
15:12:35 <rhiaro> ... it's looking good
15:12:45 <rhiaro> ... now just about deduplicating things and getting the test suite into a structure that works for everybody
15:12:55 <rhiaro> ... I don't think it's quite ready yet for did method implementers to submit their data or results
15:12:59 <rhiaro> ... because there is this restructuring going on
15:13:01 <rhiaro> ... but almost ready
15:13:06 <burn> Topic: DID Method Implementations
15:13:09 <markus_sabadello> scribe+
15:13:14 <dbuc> dbuc has joined #did
15:13:17 <dbuc> present+
15:13:26 <justin_r> present+
15:13:30 <markus_sabadello> burn: There is some refactoring that still needs to happen.
15:13:43 <markus_sabadello> burn: This is not a call for implementations yet, this is a call to get ready.
15:14:08 <markus_sabadello> burn: Once the refactoring is done, we will be asking implementers to submit their reports.
15:14:27 <markus_sabadello> burn: Anyone planning to submit, please mention it in the chat.
15:14:31 <dmitriz> +1 impl report for did-key, did-veres-one and did-web
15:14:37 <dbuc> Microsoft will submit, possibly incoordination with other Sidetree implementers
15:14:38 <markus_sabadello> q+
15:14:49 <burn> ack mark
15:14:58 <rhiaro> markus_sabadello: manu did create a PR to do this refactoring or part of it
15:15:01 <kristina> kristina has joined #did
15:15:02 <rhiaro> ... not merged yet
15:15:10 <rhiaro> ... can't say if after that PR we'll be ready for data
15:15:15 <rhiaro> ... but that work is happening to this refactoring
15:15:24 <kristina> present+
15:15:25 <rhiaro> ... the second comment is that the idea is that there could be multiple types of implementations that can be submitted
15:15:34 <rhiaro> ... so you don't necessarily have to implement your own did method, you can also test implementations of other parts of the spec
15:15:40 <rhiaro> ... producers, consumers, parsers, resolvers
15:15:41 <ivan> present+ dpuc
15:15:53 <rhiaro> ... the idea of the test suite would be that you can submit implementation reports for those things even if you don't implement your own did method
15:15:57 <markus_sabadello> scribe+
15:16:15 <markus_sabadello> burn: dbuc, do you know what you are planning to support?
15:16:26 <markus_sabadello> burn: e.g. are you planning to submit implementation support for JSON
15:16:33 <markus_sabadello> dbuc: We'll support both.
15:16:54 <markus_sabadello> burn: That's helpful, we were not sure if we will get enough implementations of JSON.
15:16:58 <cel> +1 Spruce to submit an implementation report, possibly including did:tz, did:key, did:web, did:onion
15:17:16 <jonathan_holt> yes
15:17:28 <dbuc> JSON, by way of doing basically nothing to the JSON-LD variant
15:17:36 <markus_sabadello> burn: We need to cover all of the tests, this includes the various implementations.
15:17:49 <burn> Topic: Test Suite Issues
15:18:19 <markus_sabadello> burn: As chairs, we wanted to go over test suite issues, and DID Core issues.
15:18:50 <burn> https://github.com/w3c/did-test-suite/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
15:19:15 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/53
15:19:15 <rhiaro> markus_sabadello: we can go over the 10 open issues
15:19:32 <rhiaro> ... the first one I raised. I submitted tests for did resolution and url dereferencing sections, which have bene merged
15:19:47 <ivan> subtopic: Missing tests in DID Resolution and DID URL Dereferencing @issue 53
15:19:47 <rhiaro> ... this issue tracks sentences in those sections that are not yet covered
15:20:16 <rhiaro> ... eg. in did core there's a statement that says a conforming did method spec must guarantee that each equivalent id value is logically equivalent to the id property value. Not sure if this is testable at all
15:20:19 <rhiaro> ... that's what this issue is about
15:20:34 <dbuc> q+
15:20:42 <burn> ack dbuc
15:20:55 <rhiaro> dbuc: we had one we were taking about in a PR that we were going to mod some language..
15:21:20 <rhiaro> ... did we decide if we're going to accept... the equivalent stuff the method defines.. there are ways inside method sto figure this out
15:21:37 <rhiaro> ... can we accept a test where an implementation test takes in a did and says I've got an equivalent and id property, I'll save both - test success
15:21:38 <rhiaro> ... is that acceptable?
15:22:04 <rhiaro> markus_sabadello: I don't know, the did core spec says a conforming did method must guarantee that some identifiers are logically equivalent. I don't know how to write a tests that tests that the did method spec guarantees that
15:22:13 <rhiaro> dbuc: it would happen inside.. i don't know that the external thing would be testing that
15:22:28 <ivan> s/issue 53/issue did-test-suite#53/
15:23:02 <rhiaro> ... eg. the did spec says the did method should determine the correct keys to put in the did doc.. I don't know how it's doing that, we can't test inside all the methods how they're doing that.. grabbing keys and sticking them in a json object.. but because we tell them they output the correct json doc we assume they get the correct keys
15:23:14 <rhiaro> burn: if you join on thursday that would be a great time to discuss the topic
15:23:18 <rhiaro> dbuc: okay
15:23:32 <dbuc> I am, will do
15:23:34 <rhiaro> burn: and you were also signed up to write some tests? good chance to talk about that and the question
15:23:43 <rhiaro> markus_sabadello: this is one case where I just didn't know how to write a test, maybe someone can help in a working session
15:23:47 <rhiaro> dbuc: I don't think there is a way
15:23:55 <rhiaro> markus_sabadello: that might occur in several more times
15:24:03 <rhiaro> ... we discover some statement where we don't have a way of tesing it in an automated wya
15:24:06 <rhiaro> ... not sure then what we need to do
15:24:18 <rhiaro> ... we've had discussions a few times if you can still have normative statements in the spec without testing them in an automated way
15:24:29 <rhiaro> ... in that case they'd have to be demonstrated in some other way that it is possible to implement them
15:24:37 <rhiaro> ... we've had those discussions, manu and ivan know better how that works
15:24:47 <dbuc> DID Key and some other initial state long-form type DIDs are really the only ones you could 'test' if they have included the correct keys
15:24:49 <rhiaro> ... if we can't demonstrate that it's possible to implement then the alternative is to not use normative language
15:24:57 <rhiaro> ... and just say did methods are expected to guarantee that instead of saying MUST
15:25:02 <dbuc> DID Key is a key, so obviously you can know what the right key should be
15:25:02 <rhiaro> ... other peopl ekno better what to do in these cases
15:25:17 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/51
15:25:28 <rhiaro> markus_sabadello: I'm not familiar with this one, self describing
15:25:29 <ivan> subtopic: How will be produce visualization of the test results @issue did-test-suite#51
15:25:32 <dbuc> But any method that has had a rotation occur forms the correct key associations internally
15:25:45 <dbuc> so that's always going to be specific to the method
15:25:47 <rhiaro> ... test report in the form of a json file
15:25:52 <dbuc> as everything in the DID Doc is
15:25:52 <rhiaro> ... a number o fways of how to render that in html
15:25:57 <dbuc> including Service Endpoints
15:26:13 <rhiaro> burn: even though we don't have a notion of editorial with the test suite, this falls into that category
15:26:18 <rhiaro> ... presentation, not about the actual running of the tests
15:26:25 <ivan> q+
15:26:31 <rhiaro> ... in the end orie will decide osmething but if you have an opinion, express it
15:26:32 <burn> ack ivan
15:26:43 <rhiaro> ivan: we discussed this with orie on the last call
15:26:53 <rhiaro> ... we will have to produce some sort of report of the whoel CR phase, test results, implementations, etc
15:26:58 <rhiaro> ... there are other examples in other WGs
15:27:05 <rhiaro> ... I can help with that at the end
15:27:17 <rhiaro> ... the only thing it affects right now is that there should be a clear strucured wya of characterising each test
15:27:20 <rhiaro> ... metadata about the test
15:27:23 <rhiaro> ... and about the implementations
15:27:30 <rhiaro> ... once those are there in some format, whatever format, we can do something at the end
15:27:45 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/50
15:27:50 <ivan> subtopic: Proposal to create a suite per major section of the spec @issue did-test-suite#50
15:27:55 <rhiaro> markus_sabadello: relatively simple
15:28:11 <rhiaro> ... internal restructuring to organise the test suite into multiple suites which each contain tests related to one section
15:28:20 <rhiaro> ... in the initial draft of the test suite we had one suite which contained a huge list of tests
15:28:28 <rhiaro> ... this is a way of dividing and structuring the test suite a bit better
15:28:33 <rhiaro> ... will result in better reports
15:28:50 <rhiaro> burn: also editorial
15:28:54 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/49
15:29:00 <rhiaro> markus_sabadello: next is similar, about restructuring the input files
15:29:09 <rhiaro> ... in an early version there was a single gigantic input file with lots of dids and did docs
15:29:17 <rhiaro> ... and production and consumption inputs and outputs for multiple dids and did methods
15:29:19 <rhiaro> ... in a single file
15:29:25 <rhiaro> ... this issue is about organising that better and splitting up that one file
15:29:29 <ivan> subtopic: Proposal to refactor the input json into js files @issue did-test-suite#49
15:29:31 <rhiaro> ... which will be easier for people to submit their own data
15:29:34 <rhiaro> ... uncontroversial
15:29:35 <burn> q?
15:29:44 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/48
15:29:45 <ivan> subtopic: Producer tests should be of the ADM not resolution result @issue did-test-suite#48
15:29:50 <rhiaro> markus_sabadello: next is substantive
15:30:00 <rhiaro> ... other issues related
15:30:05 <rhiaro> ... how to properly test the ADM and different representations
15:30:17 <rhiaro> ... a topic that has taken time on the working calls to specify that in did core
15:30:22 <rhiaro> ... now we're working on how to properly test that in the test suite
15:30:40 <rhiaro> ... there are existing tests that have been merged related to production and consumption and this issue is to keep track of improvements that may have to be made onto those tests
15:30:53 <rhiaro> ... to distinguish between the did doc as a data model and the did doc as a concrete representation
15:31:03 <rhiaro> ... ideally the test suite would distinguish between the ADM and the representations in clean way
15:31:18 <rhiaro> ... production tests and ocnsumption tests and reoslution tests would either operation on the data model or the representations depending on what the spec says
15:31:30 <rhiaro> burn: manu's last comment was that you, orie and cel need to get to gether to decide on a plan
15:31:32 <rhiaro> ... do you have a plan?
15:31:37 <rhiaro> markus_sabadello: I don't think we have that yet
15:31:42 <rhiaro> ... special topic call might be an opportunity
15:31:58 <rhiaro> ... a case where things have moved very fast in past weeks, people have worked in paraellel and done certain things slightly differently
15:32:16 <jonathan_holt> q+
15:32:27 <rhiaro> ... I think cel has done it really nicely
15:32:35 <rhiaro> ... very clean distinction between those layers
15:32:42 <burn> ack jonathan_holt
15:32:53 <rhiaro> jonathan_holt: one thing i was working on before was representing the ADM in ABNF rules
15:32:58 <rhiaro> ... that is supported in the CDDL
15:33:00 <cel> thanks markus_sabadello
15:33:04 <rhiaro> ... I haven't seen the test suite in a while, getting back up to speed
15:33:14 <rhiaro> ... but curious if I were to write an ABNF rule for the entire spec would that be received well?
15:33:21 <markus_sabadello> q+
15:33:30 <rhiaro> ... would it be a soultion? I have a hard time with the ADM being too abstract, I can't test for it
15:33:38 <burn> ack markus_sabadello
15:33:42 <rhiaro> ... I haven't followed the typescript representation orie has been working on
15:33:51 <rhiaro> markus_sabadello: i suspect people would ask how an abnf applies to an abstract data model
15:33:54 <rhiaro> ... probably a deeper conversation
15:33:58 <rhiaro> ... abnf is a way of specifying a syntax
15:34:07 <rhiaro> ... specify an abnf for one of the representaitons, not sure how you'd use it to describe the ADM
15:34:12 <rhiaro> ... but maybe I'm missing something
15:34:22 <rhiaro> burn: probably a good topic for thursday
15:34:38 <rhiaro> ... we're missing some people today
15:34:43 <rhiaro> ... would be good to raise on thursday or to submit as an issue
15:34:59 <rhiaro> markus_sabadello: point of the test suite is to test all t he normative statement sin the did core spec
15:35:06 <rhiaro> ... we need to prove that it is possible to implement all those statements
15:35:23 <rhiaro> ... if that can be done with an abnf maybe that would be useful but we should look at how exactlyt hat would be done and which statements in the spec that would test
15:35:38 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/36
15:35:45 <ivan> subtopic: Use of better jest matchers @issue did-test-suite#36
15:35:49 <rhiaro> markus_sabadello: next is about using jest matchers
15:35:56 <rhiaro> ... I'm not a javascript expert so I probably can't explain that well
15:36:01 <rhiaro> ... shigeya is here, maybe..?
15:36:28 <rhiaro> shigeya: a way to define matches which is construct like a ?? sometimes useful whether you want to test whether the expected variable is in a string
15:36:31 <rhiaro> ... or certain kind of string
15:36:40 <rhiaro> ... eg. we have tons of the did identifier syntax
15:37:03 <rhiaro> ... so we are going to have a string that matches.. can be easier to do it.. easy to chang ethe syntax if we want to change it
15:37:06 <rhiaro> ... I'm going to write matches
15:37:10 <rhiaro> ... maybe later this week or early next week
15:37:17 <rhiaro> ... so we can refactor the entire test suite to be simpler
15:37:20 <rhiaro> ... that's the idea
15:37:22 <rhiaro> markus_sabadello: sounds fantastic
15:37:34 <rhiaro> ... has exactly to do with this kind of paraellel implementation and code uplication we have right now
15:37:39 <burn> s/matches/matchers/
15:37:55 <rhiaro> ... at least three different people who have worked on tests for different sections have all writeen some kind of test code that checks if a string is a valid did that conforms with the syntax because that's somthing that occurs in many parts of the spec
15:38:03 <rhiaro> ... therefore different people have implemented a test for did syntax in different ways
15:38:13 <rhiaro> ... if we had a jest matcher for the test suite that does that it will save everybody work
15:38:17 <rhiaro> ... and result in a more correct test suite
15:38:39 <rhiaro> markus_sabadello: next two are self explanatory
15:38:42 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/33
15:38:43 <ivan> subtopic: need clear instructions for implementers @issue did-test-suite#33
15:38:47 <markus_sabadello> https://github.com/w3c/did-test-suite/issues/32
15:38:55 <rhiaro> ... also related to refactoring
15:39:09 <rhiaro> ... implementers of a did method or the spec in another way so they know how exactly they submit their data
15:39:27 <rhiaro> burn: pretty straightforward
15:39:31 <ivan> scribejs, issue did-test-suite#33
15:39:37 <rhiaro> markus_sabadello: last two are about sections of the spec which are still missing
15:39:41 <rhiaro> ... ther eare not tests yet
15:40:10 <ivan> subtopic: Need tests for CBOR/JSON Production and Consumption @issue did-test-suite#28,did-test-suite#26
15:40:37 <rhiaro> ... those are about sections tha tdon't have tests
15:40:42 <rhiaro> ... 28 is about cbor
15:40:45 <rhiaro> ... 26 is about json
15:40:53 <rhiaro> ... there are test for jsonld production and consumption
15:41:01 <rhiaro> ... and for generic sections about production and consumption that are not representation specific
15:41:13 <rhiaro> ... it looks like there are no tests yet for cbor and json production and consumption
15:41:26 <rhiaro> ... the cbor one is assigned to orie and json is assigned to ??
15:41:40 <ivan> s/??/Daniel/
15:41:47 <rhiaro> burn: we were hoping for someone like jonathan ot contribute on the cbor
15:42:02 <rhiaro> jonathan_holt: doing my best to get back in the swing with DID contributions
15:42:20 <rhiaro> burn: daniel can you contribute on the json? the json format in particular was one of the biggest requests from microsoft on day one of the working group
15:42:28 <rhiaro> ... so we really want to make sure it's complete
15:42:52 <rhiaro> dbuc: the way we've gone about it I don't know... it's worked perfectly fine working jsonld as json and saying you don't have to resolve contexts
15:42:57 <rhiaro> ... I can work on any tests that take that approach
15:43:01 <rhiaro> ... that's what we're doing in our implementation
15:43:04 <rhiaro> ... make sense?
15:43:10 <markus_sabadello> q+
15:43:11 <rhiaro> ... are there bugs or issues out there that want it to be different than that?
15:43:14 <burn> ack markus_sabadello
15:43:15 <justin_r> q+
15:43:33 <dbuc> Yesssss :)
15:43:34 <dbuc> I do
15:43:35 <rhiaro> markus_sabadello: i know some people want to treat jsonld and json as equivalent and to include @context in both and this has to do with long discussions we had
15:43:36 <dbuc> Lazy
15:43:40 <dbuc> don't want to care
15:43:48 <rhiaro> ... my personal opinion is this is not what the did core spec describes right now
15:44:00 <rhiaro> ... it does not envision that json and jsonld are byte to byte equivalent
15:44:06 <rhiaro> ... if that's what WG members want to do we should change the did core spec
15:44:09 <burn> q?
15:44:13 <rhiaro> ... right now on the test suite we need to take the normative statements
15:44:21 <rhiaro> ... the open issues on the test suite they list the normative statements that need to be tested
15:44:23 <dbuc> q+
15:44:24 <rhiaro> ... so we need to work based on that
15:44:27 <burn> ack justin_r
15:44:38 <rhiaro> justin_r: +1 to what markus was saying
15:45:02 <rhiaro> ... one of the things that got brought up a necessary test conditon is that a did doc that is described to be in plain json should be allowed to have the @context field and have it be a completely invalid value, and that should pass
15:45:08 <rhiaro> ... that should get parsed, the @context dumped into the bucket
15:45:14 <rhiaro> ... with whatever value it is
15:45:18 <rhiaro> ... no checking if it's an array or string or anything
15:45:21 <dbuc> Yes Justin, yeeeessss
15:45:30 <dbuc> Love everything you are saying right now
15:45:32 <rhiaro> ... so if you have the @context value with boolean false an d a plain json encoding by the way the did core spec is defined today that is allowable
15:45:50 <rhiaro> ... because the reserializaiton on the producer side needs ot be able to place the appropriate context value and not just pass through blindly whatever it was handed
15:46:11 <rhiaro> ... I will say I'm not personally familiar with the structure and function of the test suite code to suggest how to contribute this piece and don't have the bandwidth, I apologise for that
15:46:18 <rhiaro> ... but that is the type of corner case we need to have tests cases for
15:46:32 <rhiaro> ... if you're doing lazy validation that's not proving you're compliant
15:46:38 <burn> ack dbuc
15:46:52 <rhiaro> dbuc: the interesting thing.. it doesn't say anything about must exclude properties... isn't lazy validation accurate?
15:47:04 <rhiaro> ... if you had context with a bool and the spec doesn't say it has to be right isnt' the way i'd write the test to not deal with that property?
15:47:08 <rhiaro> ... lazy validation is the valid wayt o do it?
15:47:12 <burn> q?
15:47:22 <rhiaro> justin_r: you need to go one step further becasue the spec says what to say with unknown properties
15:47:27 <rhiaro> ... in this case @context would be an unknown property
15:47:33 <rhiaro> ... you need to make sure things will accept things with an invalid @context
15:47:35 <rhiaro> ... that's important
15:47:39 <dbuc> q+
15:47:50 <rhiaro> ... not enought to just say if i give you something an call it plain json but i'ts really jsonld that you'll be happy with that, that's not enough
15:47:54 <rhiaro> ... we need to test these kinds of things
15:48:07 <rhiaro> ... if you do that by ignoring it using a precise definiton of ignore that' sin the spec, that's fine
15:48:09 <rhiaro> ... that's not lazy validation
15:48:15 <burn> ack dbuc
15:48:16 <rhiaro> ... that's explicitly handling unknown properties in a particular way
15:48:50 <rhiaro> dbuc: instead of completely avoidng it or not putting any lines of code that deal with unknown properties, it'll iterate all the properties and have some sort of if that says if you're not in the set.. log it.. do something.. recognise it exists.. if it is in the set do what you're supposed to do?
15:49:07 <dbuc> ok, this makes sense
15:49:08 <rhiaro> justin_r: to be specific what it does is processes the serliazed property based on the type value of the serialized property and puts it into the properties map
15:49:15 <rhiaro> ... there will be an @context with boolean value of false inside the ADM
15:49:15 <dbuc> thank you justin
15:49:31 <rhiaro> ... when it comes time to do a production from that ADM if you want to do it into jsonld your jsonld producer needs to be able to make sense of that bad @context value
15:49:40 <rhiaro> ... and either throw an error there or replace it with a good @context value on thew ay out which is more likely
15:49:46 <rhiaro> ... there are specific rules of how to handle these
15:49:54 <rhiaro> ... from a code standpoint it does look like the else at the end of your validators
15:50:14 <rhiaro> dbuc: that's a good answer, thank you
15:50:30 <rhiaro> burn: issue 26 about json... orie had asked in feb whether you might be able to contribute in writing some tests
15:50:40 <rhiaro> ... largely this is in here because microsoft fought hard for it
15:50:55 <rhiaro> ... we want to make sure everyone else is not doing all of the test work
15:51:00 <rhiaro> dbuc: I'll try to do something about it
15:51:14 <dbuc> I will get the mop bucket...
15:51:18 <rhiaro> burn: I think that's it for the test issues
15:51:25 <burn> Topic: DID core issues
15:51:35 <burn> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Adefer-v2
15:51:38 <markus_sabadello> scribe+
15:51:51 <dbuc> Someone summon drummon
15:52:00 <dbuc> d
15:52:05 <markus_sabadello> burn: I wanted to ask drummond to cover these, but he isn't present now
15:52:07 <kristina> drummond went to a good health pass call i believe..
15:52:35 <markus_sabadello> burn: The link I dropped is about least recently updated.. Last updated was 6 days ago, which is a good sign.
15:52:50 <markus_sabadello> burn: I will go through them and skip editorial ones
15:52:53 <burn> https://github.com/w3c/did-core/issues/712
15:53:01 <ivan> subtopic: Explain verification suite definition and explain reuse of verification method type/material @ISSUE 712
15:53:51 <markus_sabadello> burn: Any comments about this issue?
15:54:25 <burn> https://github.com/w3c/did-core/issues/717
15:54:42 <ivan> subtopic: equivalentId and canonicalId should be optional @issue 717
15:54:51 <dbuc> Let's fight!
15:54:58 <dbuc> jk
15:55:15 <markus_sabadello> burn: All involved people of this issue seem to be on the call, maybe we can move this forward.
15:55:46 <rhiaro> markus_sabadello: I raised this because my reading of the spec text regarding the equivalent id and canonical id was that it felt like those are mandatory
15:55:49 <ivan> scribejs, pr 720
15:55:52 <rhiaro> ... or the spec did not say that they are optional
15:56:01 <dbuc> q+
15:56:03 <TallTed> q+
15:56:03 <rhiaro> ... which is different from how other did doc metadata are described
15:56:12 <rhiaro> ... I raised a simple PR that adds language to say that they are optional
15:56:24 <rhiaro> ... I think that had support. Daniel then explained what this meant
15:56:27 <rhiaro> ... and what did methods have to do
15:56:38 <rhiaro> ... I'm not sure if the PR is sufficient or if there's anything else that needs to bed one
15:56:39 <burn> ack dbuc
15:57:02 <rhiaro> dbuc: the interesting thing here is properties are required for methods that implement them. it's a directive that says if you're going to implement then you can't sometimes not throw them in
15:57:12 <rhiaro> ... I don't know if we reflect that in the spec test.. optional in the general sense of did docs
15:57:17 <rhiaro> ... if you choose to use these features it becomes required
15:57:20 <rhiaro> ... not sure if we shoudl put that in
15:57:23 <burn> ack TallTed
15:57:30 <rhiaro> TallTed: I'm fine with the text as its' in 720
15:57:37 <rhiaro> ... it sounds like there's an addtiional piece
15:57:39 <markus_sabadello> Open PR to address this issue: https://github.com/w3c/did-core/pull/720
15:57:53 <rhiaro> ... someplace else we said methods can be mroe stringent or can require something or can define things.. maybe there's another few words to throw in
15:58:00 <rhiaro> ...I don't think this would count as a normative change to push another CR
15:58:15 <ivan> q+
15:58:15 <rhiaro> ... the ambiguous test that suggested it was required would have meant that they forced it and the change to make it optional doesn't break anything
15:58:29 <burn> ack ivan
15:58:30 <rhiaro> dbuc: I can say that any method impelmenting these, the 4 or 5 today, woudl not be broken by changing it to optional in the general document sense
15:58:46 <rhiaro> ivan: daniel answered for those he knows about. Any change like that does it affect existing implementations?
15:58:52 <rhiaro> ... if the answer is no then we are in a good place
15:58:55 <rhiaro> dbuc: the answer is no
15:59:10 <rhiaro> ... if they didn't, if they were broekn by this change it means they were misreadin gthe rest of the properties
15:59:31 <dbuc> will do
15:59:37 <rhiaro> burn: is there anything not said by the existing text after 720 is applied? take a look at 720 and if it's not complete make a suggestion or a new PR
16:00:14 <rhiaro> ... thanks everyone
16:00:15 <dbuc> gtg, thank you for all your help (Justin, Dan, Markus, Ted, etc.)
16:00:34 <ivan> rrsagent, draft minutes
16:00:34 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-did-minutes.html ivan
16:02:02 <ivan> zakim, end meeting
16:02:02 <Zakim> As of this point the attendees have been burn, rhiaro, GeunHyung_Kim, shigeya, cel, ivan, markus_sabadello, TallTed, dmitriz, justin_r, adrian, KelseyRhoda, kristina, chriswinc,
16:02:06 <Zakim> ... drummond, agropper, jonathan_holt, dbuc, dpuc
16:02:06 <Zakim> RRSAgent, please draft minutes
16:02:06 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/06-did-minutes.html Zakim
16:02:08 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:02:09 <ivan> rrsagent, bye
16:02:09 <RRSAgent> I see no action items