14:23:29 <RRSAgent> RRSAgent has joined #did
14:23:29 <RRSAgent> logging to https://www.w3.org/2020/09/08-did-irc
14:23:31 <Zakim> RRSAgent, make logs Public
14:23:32 <Zakim> please title this meeting ("meeting: ..."), ivan
14:24:59 <ivan> Meeting: DID WG Telco
14:25:29 <ivan> Date: 2020-09-08
14:57:53 <dmitriz> dmitriz has joined #did
14:59:21 <brent> brent has joined #did
15:00:08 <ivan> Chair: Brent
15:00:11 <ivan> Agenda: https://www.w3.org/mid/000000000000b88d0705aece8a43@google.com
15:00:27 <ivan> ivan has changed the topic to: meeting agenda 2020-09-08: https://www.w3.org/mid/000000000000b88d0705aece8a43@google.com
15:00:30 <phila> phila has joined #did
15:00:33 <ivan> present+
15:00:41 <phila> present+
15:00:54 <ivan> present+ dlongley
15:00:56 <markus_sabadello> markus_sabadello has joined #did
15:01:00 <ivan> present+ markus_sabadello
15:01:05 <ivan> present+ manu
15:01:29 <ivan> present+ brent
15:01:30 <brent> present+
15:01:41 <justin_r> justin_r has joined #did
15:01:45 <justin_r> present+
15:02:12 <manu> present+
15:02:55 <Orie> Orie has joined #did
15:03:02 <wayne> present+
15:03:21 <Orie> present+
15:03:49 <rhiaro> present+
15:03:57 <ivan> present+ dmitriz
15:04:02 <markus_sabadello> scribe+
15:04:07 <ivan> present+ identitywoman
15:04:16 <ivan> present+ drummond
15:04:23 <ivan> present+ pam
15:04:27 <drummond> drummond has joined #did
15:04:30 <markus_sabadello> brent: Any additions to the agenda?
15:04:38 <drummond> present+
15:04:45 <markus_sabadello> brent: Anyone want to reintroduce themselves?
15:05:12 <jonathan_holt> jonathan_holt has joined #did
15:05:18 <markus_sabadello> brent: justin_r can you re-introduce yourself?
15:05:20 <jonathan_holt> present+ jonathan_holt
15:05:28 <ivan> ppresent+ adrian
15:05:36 <ivan> present+ adrian
15:05:37 <markus_sabadello> justin_r: I'm an independent consultant from the Boston area, involved in security topics
15:05:46 <burn> burn has joined #did
15:05:58 <markus_sabadello> justin_r: I am here trying to help the community build something that actually works
15:06:06 <drummond> Thanks to Justin!
15:06:27 <markus_sabadello> brent: Our next special topic call will be on Thursday noon ET
15:06:46 <markus_sabadello> brent: In Amsterdam we had a resolution to create registries that serve as a point of interoperability
15:07:00 <markus_sabadello> brent: So far, JSON-LD interoperability is great, but other representations need more work
15:07:01 <burn> present+
15:07:07 <jonathan_holt> q+
15:07:21 <markus_sabadello> brent: On Thursday we will talk about CBOR and what it needs in the registries, in order to be interoperable
15:07:38 <markus_sabadello> jonathan_holt: Was there a request for the CBOR representation to be more interoperable? Is this about the test suite?
15:08:01 <brent> ack jonathan_holt
15:08:05 <markus_sabadello> brent: If someone adds a property to the registry, it needs be interoperable across different representations. We will try to address this for CBOR on Thursday
15:08:27 <ivan> present+ JoeAndrieu
15:08:33 <markus_sabadello> brent: English is the official language of W3C, but we have several non-native English speakers
15:08:51 <markus_sabadello> brent: The use of idioms and colloquialisms can make it more difficult to understand English
15:09:16 <markus_sabadello> brent: During calls, and on Github issues, please refrain from using more "colorful" language and stick with language you learned at school.
15:09:26 <markus_sabadello> brent: We had some requests from the chairs to increase clarity
15:09:33 <markus_sabadello> Topic: Test suite updates
15:09:38 <Orie> q+
15:09:41 <JoeAndrieu> JoeAndrieu has joined #did
15:09:56 <brent> ack Orie
15:09:57 <manu> q+ to go through normative statements.
15:10:01 <ivan> present+ wayne
15:10:03 <markus_sabadello> Orie: At the last F2F we discussed the test suite and some desirable features
15:10:27 <markus_sabadello> Orie: The core issues that were created are: We would like to not have to create Python or specific languages. We want to run tests against a Docker container or web server
15:10:43 <markus_sabadello> Orie: I started building something that can support this. A dockerized Webserver
15:10:59 <markus_sabadello> Orie: You can submit inputs to the container, and it will return test results, based on built-in configuration
15:11:23 <markus_sabadello> Orie: There is a strawman implementation of this, it's currently not covering anything, but at some point it should cover normative statements
15:11:27 <ivan> present+ Eugeniu_Rusu_Jolocom
15:11:35 <markus_sabadello> Orie: Amy has worked on a list of normative statements
15:12:05 <markus_sabadello> Orie: If you can construct test inputs in JSON, we should be able to cover all the normative statements in the spec.
15:12:06 <Eugeniu_Jolocom> Eugeniu_Jolocom has joined #did
15:12:15 <Eugeniu_Jolocom> present+
15:12:20 <pam> pam has joined #did
15:12:35 <markus_sabadello> Orie: The next step is to tell you all about it, hear concerns and then potentially merge the work into the did-test-suite repo
15:12:37 <ivan> q+
15:12:42 <manu> q- later
15:12:46 <markus_sabadello> Orie: I hope to get some support for this
15:12:53 <brent> ack ivan
15:12:53 <markus_sabadello> ivan: Two questions..
15:13:01 <Orie> https://github.com/w3c/did-test-suite/issues
15:13:05 <markus_sabadello> ivan: What is a test? What do I have to put into a test?
15:13:18 <markus_sabadello> ivan: And, how can I get the results and how can I generate a report?
15:13:31 <Orie> this is a test: https://github.com/OR13/did-core-tests/blob/master/packages/did-core-test-server/src/services/scenarios/resolve.js#L3
15:13:32 <markus_sabadello> ivan: Is it done by the implementer, or is there a mechanism that does that?
15:13:54 <markus_sabadello> Orie: You supply JSON to the test suite. You get back a JSON test report of compliance.
15:14:12 <markus_sabadello> Orie: A test is a program written in JavaScript that operates on JSON and evaluate a set of assertions (based on DID spec normative statements)
15:14:33 <markus_sabadello> Orie: I posted an example of a test that covers a normative statement about the "id" property.
15:14:58 <markus_sabadello> Orie: The input is the DID and the DID document. The test is to check if the DID in the DID document matches.
15:15:16 <markus_sabadello> Orie: The painful part of this is writing small JavaScript programs, and encoding inputs in such a way that normative statements can be tested.
15:15:45 <markus_sabadello> Orie: The report that comes out is a series of assertions that are true/false, for every test scenario you submit
15:16:00 <markus_sabadello> Orie: One scenario is DID resolution, this will have multiple assertions.
15:16:12 <markus_sabadello> Orie: The test report has a number of true/false values for assertions.
15:16:29 <markus_sabadello> ivan: We will have to have a client-side script that will convert this into a readable report (that's the easy part)
15:16:43 <markus_sabadello> Orie: We just need to perform surgery on the JSON data and turn it into nice HTML.
15:16:50 <markus_sabadello> brent: Any other questions for Orie?
15:17:22 <markus_sabadello> brent: Even though Orie has done great work to make this happen, but additional resources will be appreciated
15:17:43 <manu> https://github.com/w3c/did-core/issues/384
15:18:14 <markus_sabadello> manu: Amy has done fantastic work going through the DID spec document and listing a lot of normative statements.
15:18:38 <markus_sabadello> manu: As a group, we need to go through all normative statements to see what's testable.
15:18:50 <markus_sabadello> manu: There are too many statements to go over on a call, so this is homework for the group.
15:19:19 <markus_sabadello> manu: On the call today, we will go through statements to see what the thought process is.
15:19:34 <markus_sabadello> manu: We may convert this into a Google doc spreadsheet to enable people to do reviews easily.
15:19:47 <markus_sabadello> manu: I think we will end up with a number of changes to the specification
15:19:57 <markus_sabadello> manu: Once we make those changes, we will implement the test suite
15:20:09 <markus_sabadello> manu: It will become more difficult to change normative statements without changing the test suite as well
15:20:21 <markus_sabadello> manu: We will go into CR with a functioning test suite and a number of implementations
15:20:23 <jonathan_holt> q+
15:20:28 <markus_sabadello> manu: Any questions?
15:20:36 <brent> ack manu
15:20:36 <Zakim> manu, you wanted to go through normative statements.
15:20:39 <brent> ack jonathan_holt
15:20:53 <markus_sabadello> jonathan_holt: It would be helpful to preface the second column with "if present". This will help a decision tree to see if a certain item must be present.
15:21:09 <markus_sabadello> manu: You mean add a column in front of "testability"?
15:21:43 <markus_sabadello> jonathan_holt: There are attributes that are optional. If we specific "if present" in a column...
15:21:57 <markus_sabadello> manu: We should make these statements in the normative text.
15:22:12 <rhiaro> jonathan_holt, got it, I can update that. manu - I think the normative text says it, jonathan_holt just wants scannability in the list?
15:22:30 <markus_sabadello> manu: Example: "If a DID document includes a service property"...
15:23:20 <markus_sabadello> manu: You're correct that the conformance statement needs to state if it's optional.
15:23:38 <Orie> I removed JSON Schema tests for did registries.. after nobody contributed to them.... if we intend to use JSON Schema... I would like to get a hard commitment in developers hours from folks who want that to be a thing.
15:23:39 <markus_sabadello> manu: Is this enough for the branching logic you are concerned  about?
15:23:47 <markus_sabadello> jonathan_holt: I think it should be split out more
15:24:15 <markus_sabadello> manu: I think we will put this in Google doc spreadsheet, then feel free to duplicate the page and lay it out in a way that you think is helpful.
15:24:17 <manu> q?
15:24:35 <markus_sabadello> manu: I though we would go over how to read the table, and provide feedback by going over a number of examples.
15:24:48 <markus_sabadello> manu: Starting top-down to show the group what the thought process is
15:25:11 <markus_sabadello> manu: Amy, anything else you want to add to what's been said?
15:25:33 <drummond> q+
15:25:48 <brent> ack drummond
15:25:53 <markus_sabadello> manu: The first column is the section. The second is the statement itself. The third is testability. The fourth is a proposed changed. The fifth may eventually link to PRs
15:26:22 <markus_sabadello> drummond: In the Conformance section, if you are making normative statements about other normative statements, I think they don't have to be testable?
15:26:30 <markus_sabadello> manu: This is the type of feedback we are looking for.
15:26:42 <markus_sabadello> manu: We may want to keep the statements even if they are not testable.
15:27:05 <BrettM> BrettM has joined #did
15:27:11 <markus_sabadello> manu: Vast majority of statements about DID methods are not automatically testable, only by a human process.
15:27:25 <markus_sabadello> manu: Such statements about DID methods may become a checklist.
15:27:53 <markus_sabadello> manu: There are some things here that are judgement calls. That's why we should go over the statements in the list.
15:28:41 <markus_sabadello> manu: E.g. statement 1 (A conforming DID is any concrete ...) -> This is not directly testable, because we first have to look into Section 3 which is referenced by this statement.
15:28:58 <markus_sabadello> manu: So we could change this normative "MUST" and replace it with "complies".
15:29:14 <markus_sabadello> manu: That would make it non-normative, but still clearly set the expectation.
15:29:33 <markus_sabadello> manu: There are other specifications that make similar  normative statements like this.
15:29:39 <rhiaro> we could make the test suite aggregate results of other tests in order to test the conformance ones
15:29:46 <markus_sabadello> manu: That's the type of thinking that goes into each one of these statements.
15:29:52 <markus_sabadello> manu: We're suggesting to reword this one
15:30:13 <markus_sabadello> manu: Amy's suggestion may increase test suite complexity
15:30:35 <markus_sabadello> manu: Looking at statement 2, this is not testable by itself but points to other normative statements.
15:30:49 <markus_sabadello> manu: This is the type of statement we're looking for, e.g. propose changed language
15:31:04 <drummond> I think it's fine to categorize a normative statement as a "aggregation statement" that does not need to be testable by itself because it just aggregates other normative statements.
15:31:15 <markus_sabadello> manu: Looking at statement 3, this is a duplicate of another normative statement.
15:31:29 <justin_r> q+
15:31:31 <markus_sabadello> manu: Sometimes we say the exact same thing (or something very close) in multiple sections
15:31:31 <drummond> +1 to removing any duplicate normative statements
15:31:49 <justin_r> -1 to removing "duplicates" just because they seem similar
15:32:01 <markus_sabadello> manu: Looking at statement 4: This is good statement that is directly testable.
15:32:07 <brent> ack justin_r
15:32:37 <markus_sabadello> justin_r: I agree that actual duplication can be avoided, but we need to be very careful that we're not removing things from appropriate contexts just because we come to the same conclusion twice.
15:32:58 <markus_sabadello> justin_r: In this case, we're coming to the same conclusion, but saying it in different ways and for different reasons.
15:33:32 <markus_sabadello> justin_r: Statement 3 (about serialization format) is an example of this, I don't agree it's an actual duplicate even though they are similar.
15:33:37 <manu> q+ to agree
15:33:40 <markus_sabadello> justin_r: We may end up removing important information
15:34:11 <markus_sabadello> justin_r: From previous conversations, in the Representations sections, there is language about producing and about consuming. They may seem similar but it is vitally important to keep them separate.
15:34:13 <brent> ack manu
15:34:13 <Zakim> manu, you wanted to agree
15:34:35 <markus_sabadello> manu: Based on this feedback, we may decide to not remove this but re-word
15:34:46 <markus_sabadello> manu: Solid points, Justin
15:34:55 <markus_sabadello> manu: Anything else on this?
15:35:13 <manu> q+
15:35:15 <justin_r> +1 to normative conformance
15:35:17 <markus_sabadello> drummond: Can we just decide this one question right here, i.e. do we want normative statements in the Conformance section or not?
15:35:19 <phila> q+
15:35:21 <brent> ack manu
15:35:24 <brent> q+
15:35:40 <markus_sabadello> manu: It depends on the Working Group, I've seen WGs do both
15:35:53 <brent> ack phila
15:36:20 <ivan> q+
15:36:35 <markus_sabadello> phila: If you have a section on Conformance and you want to repeat it elsewhere, you can point to it. The Conformance section might have some additional things, but generally you conform to the document itself.
15:36:52 <brent> ack brent
15:36:52 <markus_sabadello> brent: Please review the list of statements and add your opinions
15:37:00 <manu> q+ to note next steps.
15:37:01 <brent> ack ivan
15:37:29 <identitywoman> identitywoman has joined #did
15:37:34 <identitywoman> present+
15:37:35 <markus_sabadello> ivan: I was looking at some other specifications that were published lately, and usually the Conformance section does not really contain "MUST" statements in terms of information that is not elsewhere.
15:37:58 <markus_sabadello> ivan: I'm looking now at JSON-LD Conformance statements.. "It is conformant... if it follows the normative statements... "
15:38:05 <markus_sabadello> ivan: In other documents, it's even shorter than that
15:38:32 <brent> ack manu
15:38:32 <Zakim> manu, you wanted to note next steps.
15:38:37 <markus_sabadello> ivan: I think it's perfectly fine if the Conformance statements have some general language "You have to be conformant with the MUSTs in the spec, ..."
15:38:37 <drummond> I'm fine with the Conformance section just pointing to the normative statements elsewhere in the spec.
15:38:50 <ivan> present+ brett
15:39:15 <markus_sabadello> manu: Next steps are, we will put together a Google doc. Once we get to a certain point, the editors will start putting in PRs to update the document as appropriate. We will notify the WG when we do that.
15:39:25 <markus_sabadello> manu: We would like to do this well before we go into CR
15:39:42 <ivan> q+
15:39:58 <genaris> genaris has joined #did
15:40:04 <markus_sabadello> manu: We need this to get the test suite implemented. We want a high degree of trust that when we enter CR, we have what we need.
15:40:19 <markus_sabadello> manu: We'd like this process to be done by the final week of September.
15:40:20 <brent> ack ivan
15:40:54 <markus_sabadello> ivan: I am fine with what you said Manu, but the most important thing when we go to CR is that we settle the question what goes into the Conformance section.
15:41:10 <manu> I agree with what Ivan said.
15:41:19 <brent> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
15:41:23 <markus_sabadello> Topic: Core issues and status check
15:41:54 <wayne> q+
15:42:11 <markus_sabadello> brent: https://github.com/w3c/did-core/issues/119
15:42:13 <markus_sabadello> brent: We have the DID Explainer complete, are still waiting for privacy questionnaire
15:42:18 <brent> https://github.com/w3c/did-core/issues/174
15:42:20 <markus_sabadello> brent: https://github.com/w3c/did-core/issues/174
15:42:56 <brent> ack wayne
15:42:59 <markus_sabadello> wayne: Just a note that the horizontal privacy review (and a lot of the other ones) are contingent on whether we keep service endpoints or not.
15:43:05 <markus_sabadello> q+
15:44:06 <markus_sabadello> markus_sabadello: I think this had been addressed by PRs, it can be closed and will add a comment
15:44:11 <brent> ack markus_sabadello
15:44:13 <brent> https://github.com/w3c/did-core/issues/23
15:44:27 <markus_sabadello> brent: Orie, any update?
15:44:37 <markus_sabadello> Orie: Same as last time, I recommend closing this
15:45:09 <markus_sabadello> brent: Anyone opposed to closing this now?
15:45:34 <brent> https://github.com/w3c/did-core/issues/318
15:46:09 <markus_sabadello> brent: Dave, any updated on this?
15:46:17 <markus_sabadello> dlongley: No updates, maybe on a special topic call
15:46:35 <brent> https://github.com/w3c/did-core/issues/199
15:47:18 <markus_sabadello> brent: Last time we were still waiting on the "representation" property, which has been replaced by the "type" property. There is also a PR about "alsoKnownAs" related to this. We're waiting for PRs, just need to go forward with it
15:47:34 <markus_sabadello> drummond: Brent, you and I need to schedule a call to go over this
15:47:41 <brent> https://github.com/w3c/did-core/issues/171
15:48:07 <manu> +1 to close
15:48:08 <markus_sabadello> Orie: We did this, merged examples, I recommend closing
15:48:36 <markus_sabadello> Orie: Mike agreed in a comment that a PR fixed this
15:49:42 <markus_sabadello> Orie: This is also in the did-spec-registries, DID Core and the registries need to remove publicKeyPem
15:49:58 <markus_sabadello> brent: Just because Orie is assigned to it, doesn't mean he has to do the work.
15:50:05 <brent> https://github.com/w3c/did-core/issues/170
15:50:06 <Orie> q+
15:50:38 <manu> +1 to close
15:50:41 <markus_sabadello> brent: Good conversation between, Mike, Kyle, Orie, Manu
15:51:07 <manu> +1 to Orie's reasoning for close.
15:51:11 <markus_sabadello> Orie: I think we addressed this by supporting different key representations, recommend to close it. We need "id" and "type" because not everybody uses JWK
15:51:23 <brent> https://github.com/w3c/did-core/issues/332
15:51:35 <manu> +1 to support the change.
15:52:05 <markus_sabadello> brent: I fear this is misguided desire to enact social justice. Changing "master" to "main" may be [...] difficult
15:52:09 <manu> you can now publish non-master branches via Github now.
15:52:13 <manu> so, not a big deal
15:52:20 <brent> https://github.com/w3c/did-core/issues/329
15:52:21 <dlongley> q+
15:52:30 <brent> ack Orie
15:52:36 <brent> ack dlongley
15:52:56 <markus_sabadello> dlongley: I left a comment on this one, it depends on the discussion in 382 about service endpoints
15:53:34 <markus_sabadello> brent: It's important to move forward on the privacy questionnaire
15:53:47 <brent> https://github.com/w3c/did-core/issues/361
15:54:23 <manu> q+
15:54:33 <markus_sabadello> justin_r: I don't know if any work has been done on this. Haven't seen any PRs
15:54:37 <jonathan_holt> q+ to ask if is this a limitation of INFRA?
15:54:41 <markus_sabadello> brent: We need someone to step forward to raise a PR
15:54:49 <brent> ack manu
15:54:59 <markus_sabadello> manu: There is ongoing conversation in the INFRA spec; whatever they come up with will change what we do
15:55:26 <markus_sabadello> manu: Right before CR, we have to make a decision on this. We may have put in explicit formats.
15:55:30 <ivan> q+
15:55:33 <justin_r> q+
15:55:36 <markus_sabadello> manu: We're waiting for the INFRA folks to tell us what they're planning on doing
15:55:40 <markus_sabadello> brent: You're in touch with them?
15:55:45 <markus_sabadello> manu: Only through the issue tracker
15:55:46 <brent> ack jonathan_holt
15:55:46 <Zakim> jonathan_holt, you wanted to ask if is this a limitation of INFRA?
15:56:02 <brent> ack ivan
15:56:03 <markus_sabadello> jonathan_holt: As far as using INFRA, there is the ordered set that was brought up before
15:56:26 <markus_sabadello> ivan: We have to be consistent. I don't remember the issuer/PR number, but we agreed we would have the date specified for parameters
15:56:27 <markus_sabadello> q+
15:56:46 <markus_sabadello> ivan: I think we agreed we would use ISO
15:56:50 <brent> ack justin_r
15:57:03 <markus_sabadello> Issue mentioned by Ivan assigned to me about date and time format: https://github.com/w3c/did-core/issues/379
15:57:05 <markus_sabadello> q-
15:57:30 <markus_sabadello> justin_r: It would be great if in the future we can align with INFRA and point to it instead of defining them ourselves
15:57:34 <Orie> +1 to justin_r... lets not build on a hypothetical future that may never come.
15:57:46 <manu> That wasn't the suggestion :)
15:57:59 <manu> It either goes in the INFRA spec and we can refer to it... or we'll have to do it.
15:58:06 <manu> (in the DID Core spec)
15:58:19 <markus_sabadello> justin_r: There is a lot more than just numbers and dates. There are concrete data elements like URIs, etc. We need to comb through all of the properties to say how they are serialized. In many cases this will be obvious, but our job as spec writers is to write down what's obvious
15:58:41 <brent> https://github.com/w3c/did-core/issues/85
15:58:43 <drummond> +1 to Justin's point that we need to "write down the obvious so that everyone does it"
15:58:50 <markus_sabadello> q+
15:58:54 <ivan> +1 to justin, too
15:59:16 <markus_sabadello> q-
15:59:30 <markus_sabadello> brent: I'll add a comment to ask to reiterate what needs to be done, and recommend closing.
15:59:43 <markus_sabadello> brent: Thank you everyone for coming, apologies for confusion regarding the agenda.
15:59:56 <markus_sabadello> brent: The agenda thats says 15th September is WRONG
16:00:20 <ivan> rrsagent, draft minutes
16:00:20 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/08-did-minutes.html ivan
16:00:26 <ivan> zakim, end meeting
16:00:26 <Zakim> As of this point the attendees have been ivan, phila, dlongley, markus_sabadello, manu, brent, justin_r, wayne, Orie, rhiaro, dmitriz, identitywoman, drummond, pam, jonathan_holt,
16:00:29 <Zakim> ... adrian, burn, JoeAndrieu, Eugeniu_Rusu_Jolocom, Eugeniu_Jolocom, brett
16:00:29 <Zakim> RRSAgent, please draft minutes
16:00:29 <RRSAgent> I have made the request to generate https://www.w3.org/2020/09/08-did-minutes.html Zakim
16:00:31 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:00:36 <Zakim> Zakim has left #did
16:11:59 <dmitriz> dmitriz has joined #did
18:00:17 <ivan> ivan has joined #did
19:21:08 <dmitriz> dmitriz has joined #did