DID WG Telco — Minutes

Date: 2021-03-30

See also the Agenda and the IRC Log

Attendees

Present: Shigeya Suzuki, Charles Lehner, Ted Thibodeau Jr., Kyle Den Hartog, Markus Sabadello, Manu Sporny, Kelsey Rhoda, Geun-Hyung Kim, Orie Steele, Brent Zundel, Drummond Reed

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Charles Lehner

Content:

1. Agenda Review, Introductions, Re-introductions

Brent Zundel: Going to announce the special topic. brief conversation about DID method implementations. slightly longer conversation about process moving forward. Then will run through the DID Core issues, speak briefly about untested features, then finish with talking about test suite issues. Suggestions for agenda changes?
… Intros and reintros. Asking KelseyRhoda

Kelsey Rhoda: I work with Spruce, working on some applications adjacent to the space
… coming into try to understand the goals of the committee, the different specifications as it’s going

Brent Zundel: Excellent, welcome.

2. Special Topic Call

Brent Zundel: One of these days, I will send a special topic call agenda email that is perfect. That day was not to be this week. I still said it was Tuesday April first - there is no such time this year. April fools day?
… Thursday April 1st special topic call. Test suites.

3. DID Method Implementations

See github issue did-spec-registries#266.

Brent Zundel: We are nearly ready for DID Method implementors to submit their DID method implementations to the test suite.
… We are not yet ready. So this is a call for DID Method implementations to be prepared: be ready. Very very soon the test suite will be ready.
… Not quite ready yet, so don’t submit yet.
… Any quesitons, comments?

Kyle Den Hartog: 2+ for production-ready status - are we in alignment with that in the group?

Brent Zundel: Can you clarify?

Kyle Den Hartog: When we were discussing what are the requirements for different levels - provisional, implementation, production. impl requires only one, but Production requires 2+ independent.
… is what we were thinking

Brent Zundel: Excellent question. Assuming on thread … in DID Spec Registries?

Markus Sabadello: I don’t understand the question. Said to require 2+ implementations of a feature in the DID Core specification, but what does this have to do with Provisional status

Kyle Den Hartog: For reference looking at this issue: https://github.com/w3c/did-spec-registries/issues/266

Manu Sporny: I think you are talking about the did-spec-registries, the Provisional field
… Drummond and Kyle you are proposing we have different words other then provision? Specification, Implementation and Production. That is the proposal?

Kyle Den Hartog: Yeah. Happy to bikeshed the names as well.

Manu Sporny: Not concerned with names but with having the editors have to go out and verify the implementation. Hard enough working on the registry without making a determination on 85 DID methods
… having arguments about what an implementation is.
… “I’ve got two implementations: my brother and I did one”
… I am wondering if we could go the other way, and remove that field altogether
… I am hesitant about the classifications putting burdens on the people in registry. Would like to hear from Orie

Orie Steele: I agree with the concerns. Registry needs more people in the pool to do these reviews.
… Need to make requirements clear for the reviewers. Not obviously wrong -> Approve.
… Have to be careful about making the burden for registration too high. Need to make it easy.
… I agree with what you are saying, manu. I don’t know if the proposal can be beaten into a shape where the pull request template would be enough.

Kyle Den Hartog: I understand your concerns, think they make sense.
… I probably wouldn’t go sa far as to say let’s completely remove it
… but was thinking what if… when you submit the original spec, we have some sort of template
… where as part of that template, if you have a registered test suite connected with that method, and the test results come back positive, we could change it to “tested”. Have effectively two statuses …
… Concerned we have a bunch of DID methods I’ve never seen code for.

Brent Zundel: would like to continue. Best place in issues.

Manu Sporny: Agree we should continue to discuss this.

Kyle Den Hartog: +1 thanks, let’s discuss over there. Thanks for taking a look at it

4. Process moving forward

Brent Zundel: We are in CR.
… We want to get out of CR.
… Previously, when pull requests were merged, it was consensus of the group and then we would merge the PR and continue moving forward. We recorded consensus through the GitHub Issues. There wasn’t a lot of formality around merging PRs.
… Moving forward, in order to safely exit CR, we need to have a disposition of comments, especially around substantive issues.
… what this means is any issue raises, we must … record what changes were made
… so that folks can tell what changed from one version to another
… We have introduced a couple new labels: comment-resolved-implicit, comment-resolved-explicit.
… Asking manu to explain the difference.

Manu Sporny: IIRC… CR is a very special time. When we get a comment in during CR, we are required to say whether or not we resolved it.
… And we have to check with the person who filed it (the comment), if they are okay with change we made.
… Need to say whether it was addressed, confirm with the commenter.
… Explicit means yes they responded: they respond yes okay with change
… Implicit means we asked, they don’t respond, and we say “we will assume you are okay with this if you do not respond”. In 7 days.
… At end of 7 days, we would mark as comment-resolved-implicit.
… Does anyone have any questions about this?

Brent Zundel: That is what I was hoping you would say. It clarified things for me and hopefully for the group.
… Any questions for process moving forward?
… Primarily the burden of this will fall to the editors.
… What it means in general is if there was an issue raised, don’t close it, unless we have the appropriate disposition of comments.

5. DID core issues

Brent Zundel: Issue processing.

Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Adefer-v2

Brent Zundel: These are all the issues that have not been marked defered.
… The current set of issues we are required to address and resolve before we can leave CR.
… We are going to go through them one at a time.
… Ivan has asked us to be careful with the notes in this
… so we can properly attribute folks to the right issues.

5.1. Diagrams need SVG and detailed description

See github issue #625.

Markus Sabadello: I created this issue when I was working on some of the diagrams for DID Core, especially those for the Data model and DID resolution section
… I did not create SVG versions yet, which Ivan suggested and I agree with that
… So I don’t forget. I will do that for the ones I created. Not sure if there are other non-SVG diagrams
… but if there are then we should also convert those

Brent Zundel: Are you looking for assistance with that?

Markus Sabadello: I will do it for the ones I created

5.2. CR Feedback: Support of publicKeyMultibase

See github issue #707.

Brent Zundel: if you identify some other ones, please mention them

Shigeya Suzuki: if somebody needs help on diagram, I can (after finishing test spec, of course)

Orie Steele: I’m one of the folks who commented on this. I’m very supportive of this issue.
… Generally, everyone should read the issue. Whatever I can do to move this ball forward, sign me up

Brent Zundel: I am adding you as an assignee to the issue.

Manu Sporny: +1 to what Orie_ said. I believe on purpose we put language in the spec that would allow us to make this substantive change during CR.
… Digital Bazaar to provide two multibase encodings to the test suite.
… The reason for multibase is to make it easier to compress in things like CBOR-LD.
… Comes up for vaccination certificates and anything to put in a QR code. If you have a multibase encoding, you can in some case save a significant number of bytes.
… Also a good future-proofing mechanism.

Kyle Den Hartog: Maybe venturing into “take it into the comments” … but does it make sense for us to define it here, or better in the linked data suites work?

Manu Sporny: good question, it should have been done years ago in that work. But because it did not go standards track first, we are in the awkward position of having to define this stuff.
… We wanted to keep it out of the spec like we did with vc-data-model. But now we have publicKeyBase58 in there. Want to either add publicKeyMultibase, or replace it.
… Because it’s in there, let’s try to do the right thing this time around.

5.3. verification method IDs MUST contain a fragment

See github issue #708.

Brent Zundel: manu you are assigned; do you have an update for us?

Manu Sporny: I do not, have not been tracking updates. Need to read. Charles…

Charles Lehner: I don’t have anything to add right now.

Brent Zundel: Last activity was nearly three weeks ago. We will come back to it another time

5.4. Explain verification suite definition and explain reuse of verification method type/material

See github issue #712.

Kyle Den Hartog: Manu, I’m good with that. If we plan to put something in here than I agree publicKeyMultibase makes more sense.

Brent Zundel: raised by Oliver, currently assigned to manu.

Manu Sporny: just assigned 8 minutes ago. Orie_ ?

Orie Steele: It’s very related to the previous issue, regarding VM suites and VM material.
… Essentially, Oliver is surprised we are not discussing VM suites in DID Core. We have discussed this at length.
… I don’t think there is a need to describe verification methods in DID Core.

5.5. Proving Control sections are wrong

See github issue #583.

Brent Zundel: Assigned to Amy, but I don’t see her. manu or markus_sabadello?

Manu Sporny: Amy is going to do it

5.6. Can DID methods be semantically versioned?

See github issue #715.

Manu Sporny: The answer is yes; we don’t really need to say anything about it. I’ll take it

Kyle Den Hartog: Easy way to answer that: reference the did:peer stuff. They have built in a way to semantically version the different DID stuff. I’m happy to answer that if that would help.

Manu Sporny: Yes, please

5.7. FAQ Question: Can the DID Controller of a DID Document be updated/changed after the DID Document has been registered?

See github issue #719.

Brent Zundel: Currently unassigned, and has one comment.
… I don’t know that more needs to happen

Manu Sporny: There is a request to add a FAQ for it.
… drummond, are you refactoring the end of the document to be a FAQ?

Drummond Reed: I thought the goal was to refactor it to not be a FAQ

Manu Sporny: My bad, the other way then
… Never mind
… I was going to say… can you speak to it …

Drummond Reed: Definitely. Feels like one of the things to discuss
… If you want me to cover it, I’m happy to do that
… All the update will do is change the questions into headings. It wasn’t a FAQ originally …
… I’ll take that action item.

5.8. FAQ Question: Can the DID Subject of a DID Document be updated/changed after the DID Document has been registered?

See github issue #718.

Brent Zundel: This would be another thing if drummond can in his refactoring, make sure this question ends up query
… I think it’s clear from the rest of the document… but making it clear would be valuable

Drummond Reed: OK, I will take that one too.
… Although the answer to earlier one seems obvious, I think there may be different answers for this one, depending on who you ask.
… Do we have a well-documented reply to answer?

Manu Sporny: This is not explicitly mentioned anywhere I think. It’s really DID Method specific.
… I don’t know of any DID method that allows you do change the DID Subject.
… Could imagine … tombstoning… to make it seem like that happened.

Drummond Reed: It might be theoretically possible to that, but we don’t know of any. Or we could flat out say no.

Brent Zundel: Or you could say whether or not it is possible is DID Method-specific.

Kyle Den Hartog: Advocating for no. Huge can of worms
… we did a good job avoiding.

Brent Zundel: I know of at least one working group participant who would say yes. If we say DID method-specific, we could avoid that

Orie Steele: I agree with what you just said, brent.
… Example is DID subject is human owner at house. It changes over time. Does the subject change? I don’t think so.
… But depending on how you read English, you might come up with different ways of answering ti.

Markus Sabadello: I think we have a normative statement somewhere that when you resolve the DID, the id property of the resolved DID document must match what was resolved. If change the DID, feels like this would break. Maybe misunderstanding the question?

Drummond Reed: Tricky question. It feels like two questions: one is is it the same DID document if you change the value of the id property.
… That’s one thing the question could be asking
… The other, that I thought it was asking, is we said the DID controller controls what the DID identifies. I thought it was asking if that DID controller could make the DID identify something different. That is the one there was a WG participant who would say yes. … Could be DID method specific

Brent Zundel: I recommend answering as best you can in the PR and then allowing the conversation to continue.

Drummond Reed: I’ll make it a separate PR so we can have a discussion just about that.

5.9. equivalentId and canonicalId should be optional

See github issue #717.

Brent Zundel: Final issue. Assigned to Markus.

Markus Sabadello: I came across this while I was working on my part of the test suite, implementing the resolution sections. I noticed that these two properties
… unlike all the others, don’t say whether they are optional or required.
… Maybe me just misunderstanding … It specifies what the values must be, but not if they are required or optional.
… I’m sure the intention of the WG is to make them optional; raised a PR to clarify it.
… Since sections marked at-risk, hope it does not cause complications.

Manu Sporny: Reading the spec right now, I think it is a problem.
… Trying to figure out if it pushes us into another CR phase to fix it.
… It would be a normative change.
… Could argue it was unclear whether optional or not. It didn’t say you have to specify it.
… We didn’t do that, therefore it was optional. All we are doing is clarifying it is optional.

Ted Thibodeau Jr.: It’s a change to a normative section, but I don’t think it should force changed behavior

Brent Zundel: Comment said they are optional for methods to leverage.
… Meaning the one implementer is intending them to be optional.

Drummond Reed: I collaborated with Daniel on that text. It absolutely… I swear it has always been the intention.
… I have a stack of bibles off-screen

Markus Sabadello: Reading the actual text, it wasn’t clear… The section marked at-risk: doesn’t that mean we can make these changes?

Manu Sporny: We didn’t mark it at-risk in that way. We basically said we are seeking implementer feedback. If not enough, might remove … not modify.
… Grey area… As long as no one objections … we just forgot to put the language there.
… Unfortunately, intent doesn’t matter. If it is possible someone looked at the specification and implemented it using just the words… If we are going to make a change to it, would it affect that person’s implementation? I think good argument for no, since we didn’t say you must have either of these properties.

Kyle Den Hartog: +1 to that interpretation

Brent Zundel: Agree

6. A Note about untested features

Brent Zundel: Untested features may need to be removed from the specification. This means if there is a normative statement and no way to test whether or not it has two or more independent implementations, we may be forced to remove that untested feature from the spec.
… Just as we will be required to remove insufficiently implemented features.
… That needed to be clarified I believe. Hopefully that will encourage those folks who care about specific features to contribute to the test suite.

Drummond Reed: Want to make clear we have some normative statements not machine testable. Let’s not discriminate … but anything machine-testable, shuld test.

7. Test Suite Issues

Brent Zundel: https://github.com/w3c/did-test-suite/issues

7.1. Use of better jest matchers

See github issue did-test-suite#36.

Brent Zundel: shigeya, can you talk about it?

Shigeya Suzuki: There are several ways to write tests, mentioned in this … whether the specific string in a variable is actually a string or not, and so on.
… After filing this issue, I found that there are variations of the test against, for example, if a variable is a string or not, there is variation on how to write the test.
… I think it is better to use the same pattern in the test. Not necessarily as matchers as I stated here, but at least should use the same pattern for the entire test.
… If we use matchers, we can simplify both the expressions and the test.
… So I think it is better to use matchers.

Charles Lehner: +1

Manu Sporny: I agree with shigeya.
… There is a certain amount of cleanup … I agree we should use the matchers shigeya is mentioning. +1

Brent Zundel: Is anyone willing to be assigned to this issue?

Shigeya Suzuki: I can work on it.

Brent Zundel: Thank you

Charles Lehner: Next issue raised by me…

7.2. need clear instructions for implementers

See github issue did-test-suite#33.

Brent Zundel: When an implementer goes to the test suite, there needs to be a clear set of instructions for submitting tests.
… Last time I looked, I didn’t see … guidance on submitting an implementation report.

Kyle Den Hartog: +1 definitely ran the tests saw they passed and went “Huh, I didn’t connect any of my code though”

Markus Sabadello: I agree with what Manu said earlier. Test suite needs to be restructured. Not entirely clear what an implementor would submit.
… There are a number of PRs using different formats … needs to be reconciliated a bit.

Brent Zundel: Will someone take this issue

Orie Steele: I will … assuming …

Brent Zundel: I have no problem with that

7.3. We need to refactor fixtures for implementers

See github issue did-test-suite#32.

Orie Steele: Same point Markus and others have raised. Essentially, the structure of the test suites is not set in stone or finalized or working.
… This issue is raised at a time of great frustration, but since then we have got many more people contributing to this.
… I don’t think we have finished refactoring the test fixtures, as evidenced by Markus’s comments, but I think we are on our way.

Brent Zundel: This one is unassigned

Manu Sporny: I will take it
… Critical path… I don’t want to put myself in the critical path… I will make an attempt.
… There is an order of operations here. One is we figure out details of testing all this stuff. Once we figure it out, it will be a bit of a mess
… We will need to refactor it. Then we expect the DID method implementers to come in and fill it out.
… Concerned about order of operations…
… If anyone gets to it before I do, please take a shot at it.

Markus Sabadello: Please review my PR about DID Resolution tests.. https://github.com/w3c/did-test-suite/pull/43

7.4. Need tests for Metadata Structure

See github issue did-test-suite#31.

Shigeya Suzuki: I almost finished writing tests besides one issue, related to the DID registry, as I commented in the issue.
… Please look at the last comment I made.
… The spec says all metadata property definitions registered in the registry must define a variable type.
… I need a way to find this. Option 1: refer to did-spec-registries
… Or we can assume that properties other than the core properties are registered.
… I need some way to determine the list of types for this test.

Brent Zundel: Thank you for the overview

Charles Lehner: Thank you all for your work.

Brent Zundel: Special Topic call this Thursday