DID WG Telco — Minutes
Date: 2020-09-08
See also the Agenda and the IRC Log
Attendees
Present: Ivan Herman, Phil Archer, Dave Longley, Markus Sabadello, Manu Sporny, Brent Zundel, Justin Richer, Wayne Chang, Orie Steele, Amy Guy, Dmitri Zagidulin, Kaliya Young, Drummond Reed, Pamela Dingle, Jonathan Holt, Adrian Gropper, Daniel Burnett, Joe Andrieu, Eugeniu Rusu, Brett McDowell
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Markus Sabadello
Content:
Brent Zundel: Any additions to the agenda?
… Anyone want to reintroduce themselves?
… justin_r can you re-introduce yourself?
Justin Richer: I’m an independent consultant from the Boston area, involved in security topics
… I am here trying to help the community build something that actually works
Drummond Reed: Thanks to Justin!
Brent Zundel: Our next special topic call will be on Thursday noon ET
… In Amsterdam we had a resolution to create registries that serve as a point of interoperability
… So far, JSON-LD interoperability is great, but other representations need more work
… On Thursday we will talk about CBOR and what it needs in the registries, in order to be interoperable
Jonathan Holt: Was there a request for the CBOR representation to be more interoperable? Is this about the test suite?
Brent Zundel: 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
… English is the official language of W3C, but we have several non-native English speakers
… The use of idioms and colloquialisms can make it more difficult to understand English
… During calls, and on Github issues, please refrain from using more “colorful” language and stick with language you learned at school.
… We had some requests from the chairs to increase clarity
1. Test suite updates
Orie Steele: At the last F2F we discussed the test suite and some desirable features
… 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
… I started building something that can support this. A dockerized Webserver
… You can submit inputs to the container, and it will return test results, based on built-in configuration
… There is a strawman implementation of this, it’s currently not covering anything, but at some point it should cover normative statements
… Amy has worked on a list of normative statements
… If you can construct test inputs in JSON, we should be able to cover all the normative statements in the spec.
… The next step is to tell you all about it, hear concerns and then potentially merge the work into the did-test-suite repo
… I hope to get some support for this
Ivan Herman: Two questions..
Orie Steele: https://github.com/w3c/did-test-suite/issues
Ivan Herman: What is a test? What do I have to put into a test?
… And, how can I get the results and how can I generate a report?
Orie Steele: this is a test: https://github.com/OR13/did-core-tests/blob/master/packages/did-core-test-server/src/services/scenarios/resolve.js#L3
Ivan Herman: Is it done by the implementer, or is there a mechanism that does that?
Orie Steele: You supply JSON to the test suite. You get back a JSON test report of compliance.
… A test is a program written in JavaScript that operates on JSON and evaluate a set of assertions (based on DID spec normative statements)
… I posted an example of a test that covers a normative statement about the “id” property.
… The input is the DID and the DID document. The test is to check if the DID in the DID document matches.
… The painful part of this is writing small JavaScript programs, and encoding inputs in such a way that normative statements can be tested.
… The report that comes out is a series of assertions that are true/false, for every test scenario you submit
… One scenario is DID resolution, this will have multiple assertions.
… The test report has a number of true/false values for assertions.
Ivan Herman: We will have to have a client-side script that will convert this into a readable report (that’s the easy part)
Orie Steele: We just need to perform surgery on the JSON data and turn it into nice HTML.
Brent Zundel: Any other questions for Orie?
… Even though Orie has done great work to make this happen, but additional resources will be appreciated
Manu Sporny: https://github.com/w3c/did-core/issues/384
Manu Sporny: Amy has done fantastic work going through the DID spec document and listing a lot of normative statements.
… As a group, we need to go through all normative statements to see what’s testable.
… There are too many statements to go over on a call, so this is homework for the group.
… On the call today, we will go through statements to see what the thought process is.
… We may convert this into a Google doc spreadsheet to enable people to do reviews easily.
… I think we will end up with a number of changes to the specification
… Once we make those changes, we will implement the test suite
… It will become more difficult to change normative statements without changing the test suite as well
… We will go into CR with a functioning test suite and a number of implementations
… Any questions?
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.
Manu Sporny: You mean add a column in front of “testability”?
Jonathan Holt: There are attributes that are optional. If we specific “if present” in a column…
Manu Sporny: We should make these statements in the normative text.
Amy Guy: jonathan_holt, got it, I can update that. manu - I think the normative text says it, jonathan_holt just wants scannability in the list?
Manu Sporny: Example: “If a DID document includes a service property”…
… You’re correct that the conformance statement needs to state if it’s optional.
Orie Steele: 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.
Manu Sporny: Is this enough for the branching logic you are concerned about?
Jonathan Holt: I think it should be split out more
Manu Sporny: 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.
… I though we would go over how to read the table, and provide feedback by going over a number of examples.
… Starting top-down to show the group what the thought process is
… Amy, anything else you want to add to what’s been said?
… 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
Drummond Reed: In the Conformance section, if you are making normative statements about other normative statements, I think they don’t have to be testable?
Manu Sporny: This is the type of feedback we are looking for.
… We may want to keep the statements even if they are not testable.
… Vast majority of statements about DID methods are not automatically testable, only by a human process.
… Such statements about DID methods may become a checklist.
… There are some things here that are judgement calls. That’s why we should go over the statements in the list.
… 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.
… So we could change this normative “MUST” and replace it with “complies”.
… That would make it non-normative, but still clearly set the expectation.
… There are other specifications that make similar normative statements like this.
Amy Guy: we could make the test suite aggregate results of other tests in order to test the conformance ones
Manu Sporny: That’s the type of thinking that goes into each one of these statements.
… We’re suggesting to reword this one
… Amy’s suggestion may increase test suite complexity
… Looking at statement 2, this is not testable by itself but points to other normative statements.
… This is the type of statement we’re looking for, e.g. propose changed language
Drummond Reed: 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.
Manu Sporny: Looking at statement 3, this is a duplicate of another normative statement.
… Sometimes we say the exact same thing (or something very close) in multiple sections
Drummond Reed: +1 to removing any duplicate normative statements
Justin Richer: -1 to removing “duplicates” just because they seem similar
Manu Sporny: Looking at statement 4: This is good statement that is directly testable.
Justin Richer: 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.
… In this case, we’re coming to the same conclusion, but saying it in different ways and for different reasons.
… Statement 3 (about serialization format) is an example of this, I don’t agree it’s an actual duplicate even though they are similar.
… We may end up removing important information
… 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.
Manu Sporny: Based on this feedback, we may decide to not remove this but re-word
… Solid points, Justin
… Anything else on this?
Justin Richer: +1 to normative conformance
Drummond Reed: Can we just decide this one question right here, i.e. do we want normative statements in the Conformance section or not?
Manu Sporny: It depends on the Working Group, I’ve seen WGs do both
Phil Archer: 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.
Brent Zundel: Please review the list of statements and add your opinions
Ivan Herman: 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.
… I’m looking now at JSON-LD Conformance statements.. “It is conformant… if it follows the normative statements… “
… In other documents, it’s even shorter than that
… 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, …”
Drummond Reed: I’m fine with the Conformance section just pointing to the normative statements elsewhere in the spec.
Manu Sporny: 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.
… We would like to do this well before we go into CR
… 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.
… We’d like this process to be done by the final week of September.
Ivan Herman: 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.
Manu Sporny: I agree with what Ivan said.
2. Core issues and status check
Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
Brent Zundel: https://github.com/w3c/did-core/issues/119
… We have the DID Explainer complete, are still waiting for privacy questionnaire
Brent Zundel: https://github.com/w3c/did-core/issues/174
Brent Zundel: https://github.com/w3c/did-core/issues/174
Wayne Chang: 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.
Markus Sabadello: I think this had been addressed by PRs, it can be closed and will add a comment
Brent Zundel: https://github.com/w3c/did-core/issues/23
Brent Zundel: Orie, any update?
Orie Steele: Same as last time, I recommend closing this
Brent Zundel: Anyone opposed to closing this now?
Brent Zundel: https://github.com/w3c/did-core/issues/318
Brent Zundel: Dave, any updated on this?
Dave Longley: No updates, maybe on a special topic call
Brent Zundel: https://github.com/w3c/did-core/issues/199
Brent Zundel: 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
Drummond Reed: Brent, you and I need to schedule a call to go over this
Brent Zundel: https://github.com/w3c/did-core/issues/171
Manu Sporny: +1 to close
Orie Steele: We did this, merged examples, I recommend closing
… Mike agreed in a comment that a PR fixed this
… This is also in the did-spec-registries, DID Core and the registries need to remove publicKeyPem
Brent Zundel: Just because Orie is assigned to it, doesn’t mean he has to do the work.
Brent Zundel: https://github.com/w3c/did-core/issues/170
Manu Sporny: +1 to close
Brent Zundel: Good conversation between, Mike, Kyle, Orie, Manu
Manu Sporny: +1 to Orie’s reasoning for close.
Orie Steele: I think we addressed this by supporting different key representations, recommend to close it. We need “id” and “type” because not everybody uses JWK
Brent Zundel: https://github.com/w3c/did-core/issues/332
Manu Sporny: +1 to support the change.
Brent Zundel: I fear this is misguided desire to enact social justice. Changing “master” to “main” may be […] difficult
Manu Sporny: you can now publish non-master branches via Github now.
Manu Sporny: so, not a big deal
Brent Zundel: https://github.com/w3c/did-core/issues/329
Dave Longley: I left a comment on this one, it depends on the discussion in 382 about service endpoints
Brent Zundel: It’s important to move forward on the privacy questionnaire
Brent Zundel: https://github.com/w3c/did-core/issues/361
Justin Richer: I don’t know if any work has been done on this. Haven’t seen any PRs
Brent Zundel: We need someone to step forward to raise a PR
Manu Sporny: There is ongoing conversation in the INFRA spec; whatever they come up with will change what we do
… Right before CR, we have to make a decision on this. We may have put in explicit formats.
… We’re waiting for the INFRA folks to tell us what they’re planning on doing
Brent Zundel: You’re in touch with them?
Manu Sporny: Only through the issue tracker
Jonathan Holt: As far as using INFRA, there is the ordered set that was brought up before
Ivan Herman: We have to be consistent. I don’t remember the issuer/PR number, but we agreed we would have the date specified for parameters
… I think we agreed we would use ISO
Markus Sabadello: Issue mentioned by Ivan assigned to me about date and time format: https://github.com/w3c/did-core/issues/379
Justin Richer: It would be great if in the future we can align with INFRA and point to it instead of defining them ourselves
Orie Steele: +1 to justin_r… lets not build on a hypothetical future that may never come.
Manu Sporny: That wasn’t the suggestion :)
Manu Sporny: It either goes in the INFRA spec and we can refer to it… or we’ll have to do it.
Manu Sporny: (in the DID Core spec)
Justin Richer: 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
Brent Zundel: https://github.com/w3c/did-core/issues/85
Drummond Reed: +1 to Justin’s point that we need to “write down the obvious so that everyone does it”
Ivan Herman: +1 to justin, too
Brent Zundel: I’ll add a comment to ask to reiterate what needs to be done, and recommend closing.
… Thank you everyone for coming, apologies for confusion regarding the agenda.
… The agenda thats says 15th September is WRONG