DID WG Telecon (US-APac) — Minutes

Date: 2020-02-25

Attendees

Present: Brent Zundel, Justin Richer, Joe Andrieu, Orie Steele, Markus Sabadello, Jingxuan Li, Kyle Den Hartog, Manu Sporny, Drummond Reed, Dmitri Zagidulin, Daniel Buchner, Jonathan Holt, Ganesh Annan, Sumita T. Jonak

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Markus Sabadello, Brent Zundel, Manu Sporny

1. Agenda Review

Brent Zundel: We will talk about what consensus means
… The editors are going to discuss the PR process, work mode
… Then we will have the status check of issues
… Any requests for changes/additions to the agenda?

Justin Richer: Are we going to take time to go over merged PRs? There has been some work lately

Brent Zundel: We will touch on this a bit
… Anyone here for the first time who wants to introduce themselves?

Jingxuan Li: Hi, I am from China

Orie Steele: welcome!

Brent Zundel: Reintroductions? Volunteeers?
… drummond, thank you for volunteering

Drummond Reed: Chief Trust Officer at Evernym, working on DIDs since the start. Evernym has been involved since the outset at the CCG. I am one of the three editors on the spec. I live in Seattle, am a Sea Hawks fan!

2. A brief note about strong consensus

Brent Zundel: What does it mean for us to have consensus at W3C
… Strong consensus model, this is a bit more than what other SDOs go for
… We’re aiming for everyone to agree that what we produced is agreed to by the whole group
… Want to remind the group that as we raise PRs and discuss issues, we want to be especially sensitive to other opinions, we have to take them into account
… We all want to get to a point where we all agree to what we are producing
… As we work on PRs and raise issues, it’s very important for our goal of consensus, to be nice to each other

Manu Sporny: I wanted to +1 that, and outline what that looks like in practice
… We’re trying to get more people in the WG to raise PRs and participate in discussions.
… When people participate, it’s really important to pay attention to people who are not necessarily agreeing with you
… When you drive a discussion, try to make sure you are paying attention to what people are saying.
… Regarding PRs, it may seem like editors are pedantic or pushing back or slow to pull in PRs, usually that is because editors are trying to make sure that when the PR is merged, it is difficult for others to argue that it shouldn’t have been merged.
… Basically we’re trying not to steamroll people. Keep this in mind when you’re processing issues and PRs.
… We’re trying to get broad consensus.

3. PR Process

Manu Sporny: What the editors wanted to make sure is the standard process for discussing issues.
… When a new issue is raised, if the person is in the WG, they get “assigned” to the issue to drive it.
… The person who raised the issue should drive the discussion, until they are happy with the outcome
… Next step is general discussion, reach out to others who may have an opinion. You should drive the issue to a concrete change (rather than only having meta-discussions).
… Once you reach that point, you can attach tags to the issue.

Manu Sporny: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3A%22ready+for+PR%22

Manu Sporny: One tag is “ready-for-PR”
… This tag says we got to some closure for this issue, now we need someone to write a PR. Ideally you or some other participant of the discussion should write the PR.
… If that’s not possible, you can ask editors to look that your issue.
… When a PR is raised, there is another tag you should use “PR-exists”
… This says the issue is associated with a PR, this usually triggers more discussion on the PR.
… At this point, all discussion typically happens in the PR. You should expect the PR to settle down over time. There is some fine-tuning until editors believe the PR can be merged without objections.
… If there is more and more disagreement, it’s probably a bad PR. You need to go back to the drawing board and create a new PR.
… Often this happens when the PR is too big.
… After discussing the PR, the PR is merged. Then a new tag is added to an issue “ready-to-close”.
… You, as member of the WG, should be able to do all of this yourself, EXCEPT for the actual merging of the PR (this is done by editors).
… Questions about this process?

Drummond Reed: manu did a great job describing this. Anyone have objections to this?

4. Issue status check

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

Brent Zundel: We’ll start at the top and go over this list.

Brent Zundel: https://github.com/w3c/did-core/issues/98

Markus Sabadello: issue was raised about syntax of DIDs, specifically the use of multiple colons
… there are some methods that use additional colons to identify subnets or specific ledgers.
… these additional colons are for method specific identifiers, but that wasn’t clear.
… I think the issue could be closed with no changes

Brent Zundel: https://github.com/w3c/did-core/issues/75

Daniel Buchner: Just commented on this, this is related to issue 14.
… In that issue, I think we agreed that we will not do anything to retain revoked keys.
… So I just commented that if we agreed to not standardize this, it doesn’t apply in this issue.

Joe Andrieu: The consensus we had was not what dbuc thinks, I’ll try to unpack that in the issue.

Brent Zundel: https://github.com/w3c/did-core/issues/118

Brent Zundel: https://github.com/w3c/did-core/issues/53

Manu Sporny: This one needs a PR, ivan split this issue into two different issues.

Daniel Buchner: JoeAndrieu_: Didn’t see the one sentence bit that talks about allowing an endlessly growing key list

Manu Sporny: Will make a comment to that effect in the issue

Brent Zundel: https://github.com/w3c/did-core/issues/140

Daniel Buchner: I will reply with some thoughts

Orie Steele: please close

Orie Steele: :party: :)

Drummond Reed: I wrote a comment that I propose to close this, based on the consensus we had during the F2F about multiple representations.

Brent Zundel: https://github.com/w3c/did-core/issues/134

Brent Zundel: Amy is not here, anyone else wants to comment?

Manu Sporny: This should be normative, id is mandatory

Markus Sabadello: i believe we made ids optional

Manu Sporny: not for keys, that would be dangerous

Markus Sabadello: it is still optional

Brent Zundel: https://github.com/w3c/did-core/issues/70

Daniel Buchner: This has now spanned across multiple DID methods that have a propagation delay
… Most DID methods in the method-specific-id have a truncated identifier
… Sometimes you have to wait until a DID is propagated, before it can be resolved
… So we need a way to pass the initial value as part of the identifier
… We wanted this to be a generic matrix parameter

Joe Andrieu: Thank you for pointing to the use case. Some ledger-based DIDs can be used immediately (such as did:ethr)

Daniel Buchner: For some DID methods, the identifier IS the value
… Any DID method that wants a verbose DID document associated with an initial state, or wants rotation, have this need
… At this point, I have no way to use my DIDs without waiting for several minutes

Joe Andrieu: Maybe this is a shortcoming of the method design

Daniel Buchner: Design a better method would require me literally breaking the laws of physics

Daniel Buchner: I mean, I think I am pretty good and coming up with cool stuff, but breaking the laws of physics is a toughy

Daniel Buchner: I do not appreciate folks suggesting that this has anything to do with the DID Method being crappy or having some failing

Kyle Den Hartog: Let’s resolve matrix parameters before discussing this one.

Brent Zundel: Let’s have the discussion in the issue.

Markus Sabadello: +1 to kdenhartog , this has a dependency on the matrix parameters discussion

Brent Zundel: https://github.com/w3c/did-core/issues/72

Daniel Buchner: I will just close the darn issue and use a URL param

Daniel Buchner: yep

Daniel Buchner: don’t want to deal with it anymore, so I will just let others run face first into this when they inevitably hit it

Brent Zundel: drummond, status?

Drummond Reed: This should be done, this is ready for PR
… I’ll update the issue

Brent Zundel: https://github.com/w3c/did-core/issues/45

Drummond Reed: Can I break protocol?

Brent Zundel: I will allow that.

Drummond Reed: Issue 45 - I think Andrew makes a good point, need to look at it a bit more closely, will ask Markus to look, if Markus is ok with it, we can get this into a PR

Brent Zundel: https://github.com/w3c/did-core/issues/122

Joe Andrieu: It’s not clear where we ended up - we need amy to clarify what she was trying to get at, much of the conversation was discussing something that wasn’t the primary issue.

Brent Zundel: https://github.com/w3c/did-core/issues/137

Manu Sporny: I tried to re-assign it to markus_sabadello , but Github’s API was down

Markus Sabadello: i agree :)

Markus Sabadello: this status depends on another issue

Orie Steele: markus_sabadello: this issue depends on the other issue, which is if matrix params should be removed

Markus Sabadello: I worked on a document to describe use cases for matrix parameters

Brent Zundel: .. I think the next step, if we should remove them, is to describe how the use cases can be done without matrix parameters

Joe Andrieu: I interpreted the F2F homework differently, my understanding was that there was one use case (hierarchical portability)
… I think dbuc’s use case needs to be considered
… There are also considerations around versions
… There may be other use cases
… Not sure if Markus’ document is the right place to collect them all
… If you have a use case that you think depends on matrix/query parameters, please create an issue so we can discuss it

Brent Zundel: https://github.com/w3c/did-core/issues/131

Manu Sporny: We need both, because the “id” for the verification method is not the same as the “id” for the key
… We should not conflate “kid” with “id”, I expect a lively debate on that

Brent Zundel: https://github.com/w3c/did-core/issues/9

Manu Sporny: Probably the spec should not say anything about how you protect the DID document, this is out of scope
… Will add a comment to the issue

Brent Zundel: https://github.com/w3c/did-core/issues/58

Joe Andrieu: The CCG hasn’t updated its formal process to deal with registries yet. Intention is to have a light-weight process
… We haven’t yet organized/document the process
… Will add a comment
… This is related to the DID WG registry process

Brent Zundel: This is specifically related to the DID method registry and LD cryptographic suite registry, not necessarily related to the DID WG extensibility registry

Brent Zundel: https://github.com/w3c/did-core/issues/10

Manu Sporny: Same comments apply as to the last issue

Brent Zundel: https://github.com/w3c/did-core/issues/8

Manu Sporny: This needs more discussion from the group, we should schedule time to talk about this

Brent Zundel: Agree

Brent Zundel: https://github.com/w3c/did-core/issues/188

Justin Richer: agree that dedicated time for crypto suites is going to be important

Orie Steele: Right now, we have the DID Core registry (for interop concepts), we have JSON-LD contexts in the DID Core repo
… How do we have a place where we can update the JSON-LD context so that documents are actually compliant
… My proposal is to host JSON-LD contexts together with JSON schemas in the DID Core repo. This way we have all machine-readable document in one place, as opposed to having things in different repos.
… Pretty much every issue related to JSON-LD is blocked by this. Might be best to have a standalone call to address this

Manu Sporny: +1 to what Orie said. We need to make a decision about this.

Orie Steele: related: https://github.com/w3c/did-core-registry/issues/3

Manu Sporny: This also related to our context strategy / caching strategy. It would be best if the chairs can schedule a call for this
… Will add a comment

Brent Zundel: https://github.com/w3c/did-core/issues/16

Kyle Den Hartog: Last time I thought about this I may have been wrong. Based on the discussion, we may be able to close this.

Brent Zundel: If you like you can add a comment saying that this is resolved

Kyle Den Hartog: Can you assign this to me please

Brent Zundel: You are assigned
… We will continue this process in future meetings, thank you for coming
… Make your comments throughout the week, thanks everybody

Orie Steele: thanks!