DID WG Telco — Minutes

Date: 2021-08-24

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Brent Zundel, Charles Lehner, Justin Richer, Markus Sabadello, Ted Thibodeau Jr., Shigeya Suzuki, Manu Sporny, Drummond Reed, Kyle Den Hartog, Adrian Gropper

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Charles Lehner, Manu Sporny

Content:

1. Agenda Review, Introductions

Daniel Burnett: Moving into administrative-type discussions. Just about done with the spec. Talking about press release briefly, the upcoming SRI report on DID Core
… errata management on the DID spec,
… then give Joe some time to talk about the Rubric and something he would like to propose.
… Then going to the Implementation Guide, and DID Spec registries
… Modifications?

Drummond Reed: Sounds good

2. Press Release

Brent Zundel: We are holding off collecting testimonials and evidence of wide usage until we get a draft.
… Ivan has been working with Coralie, who is in the W3 Public Relations Group. She is drafting the press release.
… As soon as we have that, we will send it around, for anyone who is using DIDs or even VCs. The scope seems to be SSI in general.

Drummond Reed: Does it actually use the term SSI?

Brent Zundel: Most likely not, I’m using it as am umbrella term.

Drummond Reed: Question: timing. It will help to know - I repeat this - Some folks will want to know so they can do their own promotion or tack onto it. Do we know when the actual announcement will be?

Brent Zundel: The best direction for an estimate that we have is that the W3C wants to, as best as they can, synchronize the DID Spec becoming a recommendation and the press release.
… We are expecting that the DID Spec will become a recommendation the 23rd of September (?) - That’s the date I’ve heard mentioned. Approximately around there.

Drummond Reed: Let me suggest… ToIP, DIF, various groups that may plan events, announcements… At what point do we think we will have a definitive date?

Brent Zundel: The data by which we will know the date for publishing a recommendation is probably the 7th of September.
… In anticipation of that… There’s a narrow window in September for actually publishing things. So Thursday the 23rd is most likely.

Drummond Reed: Very helpful for folks to make plans, thanks

3. Upcoming SRI Report on DID Core

Manu Sporny: DHS effectively hired SRI to do an independent review on the DID spec and DID methods and things like that.
… So you can think of it as kind of a third-party audit on the type of ecosystem we’ve created.
… They did a pretty in-depth look, but it’s not exhaustive.
… They would like to present their findings. Question: what would we like to hear about?
… There’s enough content for 2 or 3 calls. If we had a choice on what they could present, what would we want them to talk about?

Drummond Reed: I haven’t looked through the content yet, but want to go to the heart of it, Manu, what do you want to hear about.

Manu Sporny: It’s been enough time that I’ve forgotten the presentation.
… I think the first blush view they had of the ecosystem was interesting.
… There was a lot of pointing to places as deep topics that they could not get into.
… I think the things they may feel are very difficult to provide input for… There would be so much variation they might not be able to tell us anything…
… There were parts about… NIST, the standardization story…
… It could take years…
… So there were things like “If you’re creating a DID method”, please pay attention to X, Y, and Z.
… We basically told them we would give the content to the WG, and they will look through it, and then have questions for them.
… It is their expectation that we will have read the material and have detailed questions.
… It’s not going to be good if they show up and we haven’t reviewed it. So please take a look, before the 7th when they present.
… I’ll send a reminder

Drummond Reed: I was going to suggest exactly that.

Brent Zundel: Is there a link? PDF files?

Manu Sporny: They are PDF files, we will send them…
… Orie was thinking of checking them into the Implementation Guide.

4. Errata management for DID Spec

Daniel Burnett: So, what do we want to do? brent or manu, would you talk about what that means?

Brent Zundel: In spite of our best efforts, the DID Spec will not be perfect. In order to address the unfortunately inevitable errors that people will find, we need some way to manage them - The errata need to be managed.
… The suggestion to the group is to set up the same process that the VCWG set up.
… In issues or PRs that identify errata, they can be labeled as such by the WG.
… After that, they will automatically be incorporated into a page that’s linked to from the specification that says here are the errata that have been discovered.

Daniel Burnett: One additional comment: this is really for mistakes. It’s not for new features or anything like that.
… It’s often used for things like immediately obvious typos.

Manu Sporny: +1 to that. The other thing to mention is… it works very well. It’s the cleanest way of managing errata that I’ve seen for specs. It just depends on GitHub. The documentation generation is automatic, as far as I can tell.
… It’s a really simple, low-key automated process.

Drummond Reed: +1, sounds good.

Kyle Den Hartog: I presume we’re going to keep it to non-normative changes for now. Or are we allowing normative changes as well? Not new features but fixes to normative statements.

Brent Zundel: Errata refers to any bug or mistake. It doesn’t necessarily imply it’s been fixed. In some, in the VCWG we’re working on addressing many of them.
… It’s difficult to imagine an errata that would require new features to address. That would be out of scope for the charter.

Daniel Burnett: I think Kyle was asking about not new features but substantive changes - affecting normative behavior.

Kyle Den Hartog: Sweet thanks for clarifying

Brent Zundel: Those are on the table for errata.

Brent Zundel: example of the VC spec errata page: https://w3c.github.io/vc-data-model/errata.html

Daniel Burnett: Just to point out, Kyle, it is just for bugs. If there is doubt, it likely will not go in as a bug fix.

Kyle Den Hartog: Thanks for clarifying that. My expectation is that for new features people will define extensions, as the recommended path.

Daniel Burnett: That’s typical. No spec represents the final word. It’s just the first version.
… Not only is it recommended to make extensions, but that will be helpful for the next versions, to have implementation experience.

5. DID core issues

See github pull request #792, #790.

Manu Sporny: Just wanted to draw attention to the two issues on DID Core.

Daniel Burnett: Alrighty.
… Since we don’t have Joe on at the moment… let’s just spend a few minutes on that, Manu.

Manu Sporny: There are two PRs for DID Core: one of them is the acknowledgement section - I believe that is completely ready to merge… Well, there’s one minor thing and then it’s ready to merge.
… I’m not hitting the merge button until the votes are in. I think that’s the right thing to do? It won’t autopublish…
… The other Pull Request is for… Charles made a representation-specific entries change to the spec. I believe it’s largely editorial.
… I suggest we don’t pull that in until after the votes are in and we’re cleaning up the recommendation document.
… Two questions: is that the process the chairs want? And does the group see any issue with pulling in these PRs?
… Charles, it’s strange to make changes to the specification after putting it to vote. But I think they’re totally okay as it’s editorial.

Markus Sabadello: +1 they’re editorial

Manu Sporny: “mostly editorial” -> I am asserting both of these things are entirely editorial - and would be surprised if anyone said otherwise.

Drummond Reed: I’ve looked at them and agree it’s editorial. Not an issue.

Drummond Reed: I also agree not to pull them into the final until after the vote is done.

Daniel Burnett: I’m not hearing any objections to pulling them in - when the time is right.
… I guess we could do it in the working copy… but they wouldn’t apply until we get to the final specification.

Manu Sporny: Editors… are we good to go?

Ted Thibodeau Jr.: +1 merge when it feels right

Brent Zundel: To my understanding, he is satisfied.

Drummond Reed: +1

6. DID Rubric

Brent Zundel: This topic was put on the agenda to allow time for the group to discuss issues Joe addressed in the past.
… I was hoping Joe would be here to lead it himself. The suggestion was made that it might make sense to turn the rubric into a Registry, rather than a Note.

Drummond Reed: I was going to ask, it’s too bad Joe’s not here… A discussion about what does it mean for it to be a registry?

Daniel Burnett: I think an email was sent…

Kyle Den Hartog: I’ve been working on it… My understanding is he is looking for a way to register these documents… as a way of seeing who is making the statements.
… There is obviously some bias about who is making the statements. funding models…

Brent Zundel: The last email from Joe that briefly describes the rubric registry idea: https://lists.w3.org/Archives/Public/public-did-wg/2021Aug/0016.html

Drummond Reed: thanks

Manu Sporny: I believe where Joe wants to take this is to allow anyone to make an analysis of a DID method. There’s a website you go to to look at the rubric you care about.
… You pick a criteria, then see what comes up, which methods are doing well or not, and see who said that.
… So it’s kindof a big dynamic registry of reviews that have been done using the rubric.
… It helps you pick the things you are interested in, and then see how certain DID methods did along those axes.

Drummond Reed: I remember the blog post… that does clear it up. Wow, this one could get hairy.
… The incentives here… I would equate it with the complexity of designing something like Amazon Reviews.
… The incentives for promoting or demoting a method are controlled by the market.
… This is a big deal. Not saying a bad idea, but need to think about it.

Markus Sabadello: Besides the political challenges, there are also some practical considerations. We have done, with a research partner, evaluations of 7 different DID methods.
… There’s an issue open on the repo to add that work.
… On that open issue, there is a question of what it means to add that work. We’ve published a PDF document that contains the evaluations. Converting that to some specific form and then doing the PR to somehow add that would be a lot of work that I don’t think we can do, for practical reasons.
… In some cases people do it their own way and don’t follow the registry rules.

Daniel Burnett: Attempting to either remove bias, or to allow people to make their own decision as to whether bias has occurred… By creating a registry we are essentially removing the assumption of expertise of those who made the report.
… There are people like Joe and Markus who understood deeply what it was about… If we create the registry, it would be very different from having a rubric document.

Drummond Reed: “Tricky” is the right word for it. It could have great value and it could also be the source of great controversy.

Ted Thibodeau Jr.: Mixed mind. It’s a heavy lift to go down the attributes to decide which matter to them. But turning it into a public writable registry of reviews is dangerous in more ways than I can count.
… There are some ways in which this has zero value, and some … national value.
… Yelp shows reviews… for a restaurant with one hair on a french fry. I could see some getting dinged because someone on 8chan doesn’t like it.

Daniel Burnett: I don’t think we have a particular decision. Without Joe on the call, I think it’s going to be challenging to decide how we want to move forward this week.
… Any last comments?

Brent Zundel: When Joe has spoke about it in the past, he said his plan would be to make the PR with the changes, and that would be where we could talk about it.
… When we drafted the next charter, we added language that if this group hasn’t already established registration requirements, then for the maintenance WG it would not be in scope for them to do so.

Charles Lehner: [burn reads from the charter]

Daniel Burnett: I’m not hearing people excitedly jumping up and down about having a registry.
… We’ll see when Joe creates the PR.

7. Implementation Guide

Daniel Burnett: https://www.w3.org/TR/2021/NOTE-did-imp-guide-20210826/

Daniel Burnett: We have an implementation guide, which is fabulous.
… Is there something people would want to discuss. I think one was the SRI report?

Brent Zundel: The suggestion was made by Orie that perhaps it would make good sense to include the documents that describe the review as part of the implementation guide linked to from it.
… I’m curious what the group thinks of that notion.

Manu Sporny: I think it’s a good idea.
… The whole SRI review is part of an initiative to demonstrate to the world that we’ve done our due diligence. We’ve had NIST look at it, … CFRG.
… A much broader review that most W3C specs.
… We need to … document it in perpetuity.
… SRI’s PDF - where do we put it?
… Feel like Implementation Guide is best place.
… In TR Space, it falls under the Library of Congress agreement.
… +1 to putting it in the Implementation Guide and saying something that points to it.

Daniel Burnett: It would also be possible to publish it as its own Note - But procedurally I like the idea of putting it in the Implementation Guide
… which is already a Note and easy to update.

Kyle Den Hartog: +1 to implementation guide as well. It seems most relevant to that audience as well

Drummond Reed: +1 to putting it in the Implementation Guide.

Daniel Burnett: I think we have support for putting it in the Implementation Guide, and think that will be the most obvious thing to do.

Ted Thibodeau Jr.: +1 to linking from implementation guide

8. DID Spec Registries

Daniel Burnett: https://github.com/w3c/did-spec-registries/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Aneeds-contact-info+

Charles Lehner: “Need contact info”

Daniel Burnett: Anyone who wants to walk through the issues?

Manu Sporny: I can. Is there anything specific that folks would like to cover in the list? If not, I can pick

Manu Sporny: https://github.com/w3c/did-spec-registries/issues/244

Drummond Reed: I have to remind myself what the number is… There is one thing about the resource parameter which needs a spec… I am still working on it. Spec en route.
… Probably don’t need to discuss that one.

8.1. Consider allowing multiple registrations by the same “name” in a given category (issue did-spec-registries#304)

See github issue did-spec-registries#304.

Ted Thibodeau Jr.:
… Allowing multiple registration by the same name…
… It’s entirely likely people will create the same 3 or 4 character name.

Manu Sporny: https://github.com/w3c/did-spec-registries/issues/304

Ted Thibodeau Jr.: It seems worthwhile to let them all register, and let the collisions sort out naturally.
… It puts things in the open, rather than let collisions happen more later.

Markus Sabadello: For DID methods, or properties, or everything?

Ted Thibodeau Jr.: Initially I was thinking of methods, but I think it’s worth it for all of them, really.

Manu Sporny: I get the philosophy, Ted, of why we would want to do this.
… I’m concerned that it allows bad actors to kind of mess with DID methods that they don’t like.
… First come first serve… Second registration -> Have a discussion, could create problem for community.
… I’m concerned about saying we can have double registrations without something pushing back on it hard.

Ted Thibodeau Jr.: I think there will be a lot of those conversations.

Justin Richer: if we allow things to be registered twice what’s the point of a registry?

Manu Sporny: agree with justin_r

Drummond Reed: Exactly

Daniel Burnett: agree with justin

Markus Sabadello: For DID methods, I think it’s an interesting topic - I’m not sure I have a strong opinion. We did have a case in our Universal Resolver project where there were two different implementations of the same DID method - two implementations of two different DID methods with the same name.
… I think the argument could be made that there are different communities using the same name.
… For parameters, I think it would create problems for the data model and defeat the purpose of the registry.

Kyle Den Hartog: For methods, +0. As Markus highlighted.
… For properties…

Ted Thibodeau Jr.: just consider https://acronyms.thefreedictionary.com/DID

Drummond Reed: I think allowing this would completely defeat the point of the registry. If there’s contention, we can have a process for handling that.
… The disambiguation on Wikipedia - which I love - resolves it by actually giving them different names. Is that’s what being proposed?
… But the registry entries need to be unique, or what’s the point of having the registry at all.

Ted Thibodeau Jr.: I’m hearing it, strongly disagreeing with all of you. It means a lot of people will not register what they are using.

Justin Richer: if they happen “in the wild” then people aren’t using the registry

Ted Thibodeau Jr.: The collisions have likelihood of bad results in a big way.

Manu Sporny: We’re saying it could theoretically happen, and we’re disagreeing… I suggest we delay, come back and rethink it.
… If it’s just 2 or 3, we talk to them and they change the name, fine. But if all of the sudden people try to registry, we tell them no and they use it anyway, that’s a bigger issue we need to discuss.

Ted Thibodeau Jr.: I’m not so much thinking of people who register before they deploy, but people who try to register a test thing they have already deployed and it will just be that way.
… People trying to tell what they are dealing with by looking at the registry… it would be problematic.

Daniel Burnett: IANA has registries. Precisely this situation has occurred. Justin, could you talk about this?

Justin Richer: I am not a deep expert on IANA processes. But there is a long-standing formal process. It basically boils down to, if someone shows up with something already registered, IANA is going to say no.
… Unless they say it’s an update to a thing we already know about.
… For example, HTTP URI now points to the newest HTTP specification rather than the historical ones from the late 90s.
… Things like that happen all the time. But those are cases where it’s not two completely unrelated things trying to use the same name.
… In IETF, registry must be consulted. In this WG, not, despite my arguing for it.
… If people are going to collide in the wild, it means they’re not using the registry to communicate.
… I could write a browser that does something weird with an HTTP URL. I’m allowed to, but it’s not compliant and anyone using it will be confused. That’s okay, that’s supposed to fail - That’s the whole point.

Daniel Burnett: Okay. Other comments?

Ted Thibodeau Jr.: I think the things supposed to fail in that way are different…

Justin Richer: completely disagree w/ted

Daniel Burnett: I think we are practically at the point, Ted, where if you can garner support for it, great, otherwise may just have to tell us I told you so.

Ted Thibodeau Jr.: I’ll put a bottle in the cellar and wait.

Drummond Reed: “put a bottle of champagne in the cellar and wait” <== great remark

8.2. Can we add date added/deprecated or version added/deprecated to track addition of properties? (issue did-spec-registries#143)

See github issue did-spec-registries#143.

Kyle Den Hartog: The date PR… almost done. #143
… In this case, what I’m looking for is consensus on being able to specify dates, to be able to say we are compliant up to version X.
… This has been a common issue communicating to our engineering team what features we support… and to external parties…
… so people could see if a feature is new and not supported
… Do people agree this is a problem? If so do you have any preferences on how I go about doing that?

Manu Sporny: Usually, when talking with large organizations that really want you tell them what version you are compliant to, the best you can do is the latest point release
… i.e. on TR
… Anything experimental, not having a stable spec (W3C Rec or IETF RFC) - I don’t think we can say much about those features.
… We can say we are compliant to what so-and-so did there. Or to the test suite.
… Until it’s locked down, it’s hard to say we’re compliant to anything.
… For DID spec registries… it could happen at any time. I don’t think it’s useful, you’re not going to implement everything in the registry.

Daniel Burnett: On GitHub, anyone can point to past history of anything.
… As Manu said, that’s not that common.

Kyle Den Hartog: That’s a good point. I left this open to see… For the large part people don’t seem to have an opinion.
… I’m alright closing this issue.
… May reopen some day.