DID WG Telco — Minutes

Date: 2021-08-10

See also the Agenda and the IRC Log


Present: Daniel Burnett, Ivan Herman, Shigeya Suzuki, Drummond Reed, Markus Sabadello, Manu Sporny, Justin Richer, Brent Zundel, Joe Andrieu, Adrian Gropper, Charles Lehner, dmitri, Kaliya Young, Geun-Hyung, Ted Thibodeau Jr.



Chair: Daniel Burnett

Scribe(s): Brent Zundel, Manu Sporny


1. Agenda Review, Introductions

Daniel Burnett: we’ll talk press release, next charter, then update on Rubric, then bit of time on implementation guide, then remaining time on registries
… any additions or changes?

2. Press Release

Manu Sporny: brent and I met with Coralie yesterday, she is in charge of communications for W3C
… came up with a general strategy and what the press release should say.
… but broader: decentralized identifiers, but also how the rest of what we do folds into the rest of W3C stuff, particularly web of data
… we talked about getting testimonials: people inside and outside of W3C who are deploying DIDs
… next step is Coralie will chat with Ivan and the internal team about what they want the messaging to be
… hope to have a draft in 1-2 weeks, which we can show to people we want testimonials from
… particularly from government work that is happening, companies that are involved here, as well as anyone else
… Hoping to time press release with DID spec going to rec
… this means that if we’re slow on the press release, we may want to delay announcement of the rec

Drummond Reed: +1 to making the highest impact release we can.

Manu Sporny: targeting early-mid september, but may need to delay
… did I miss anything?

Daniel Burnett: think that’s right, any questions?

Manu Sporny: identitywoman, would it be possible for linux foundation/good health pass to make a statement?

Kaliya Young: I think I can take this to them

Manu Sporny: we’ll have a draft in a couple of weeks

Kaliya Young: I’ll pass it to Brian

Geun-Hyung: Geun-Hyung has joined #did

Drummond Reed: Trust Over IP Foundation and DIF should both provide quotes

Ivan Herman: who collects the testimonials?

Manu Sporny: excellent question, I suggest we put a google doc together where people can add their testimonials, along with a template so we get points of contact and see who added things through change tracking

Drummond Reed: +1 to a Google doc

Ivan Herman: may want to ask Coralie first

Manu Sporny: +1
… I will take an action to contact Coralie about this

Markus Sabadello: I have been in touch with DIF, they are already preparing a statement. Also the EU Commission. I will add this to the google doc

Drummond Reed: Excellent, thanks Markus. An EU Commission quote would be fantastic.

3. Next Charter

Ivan Herman: See new charter draft

Brent Zundel: We have a draft of a new charter ^^^
… We have done our best to reflect the consensus of this group as it was established over a series of conversations, the charter specifies that at most we can do substantive changes in response to bugs in the specification.
… It also states that if W3C process supports registries, we can transfer from NOTE to REGISTRY and mentions rubric and plain cbor rep as notes.
… It also states that the WG can deploy new notes, proposals of new features, etc.
… out of scope is class 4 features (or removing existing features)… keeps out of scope authentication/auth protocols, signing/crypto, etc.
… In scope is DID Methods like did:key, did:peer, did:web, should the maintenance group wish to publish notes to that effect… two year charter, starting in October… any comments/questions?

Ivan Herman: When I wrote this down, didn’t realize implementation guide might be published as a note, if it’s done, then I’ll add it to the list.
… The W3C Strategy team will review for i18n and other things, I don’t expect a lot of feedback there. I don’t know when they’ll decide when to send out an advanced notice to the AC… out of my hands. I have ping’d Wendy (head of strategy) to get that done, but that’s all I can do at this moment.

Daniel Burnett: Under scope, following notes WILL be maintained, we should make it clear that the group MAY update… we might not have a rubric before that group starts.
… There isn’t a requirement that we will make updates, there is an opportunity, but not a requirement.

Joe Andrieu: I was surprised that the specification registry isn’t yet a registry
… my request is that the rubric also possibly transition to a registry

Manu Sporny: I’d be +1 to mentioning it.

Ivan Herman: first, to answer Joe. We can add that. It is essentially the same text as the previous entry
… the new process gives a formal status to a W3C registry, which means that the policy part of the registry gets a higher status, the membership votes on it like it votes on a recommendation
… that’s what the new process envisages. 99% probability it will be part of the process, but the only way we can put it into the charter we need to have the hand-waving
… which is why they current registry isn’t yet a Registry
… Back to Dan: to me maintain means we only touch the document if the community wants to touch it, doesn’t mean we have to. Same goes for the spec.
… if no one wants to change it because it is perfect, then we won’t

Joe Andrieu: right now we are treating the registry like a Registry, so calling it a Note feels off

Ivan Herman: but it is a Note…

Drummond Reed: +1 to having it become an official W3C Registry if we can.

Daniel Burnett: my comment is that the charter should enable us to do things, but not require that we do things
… this is the first group where folks have said “the charter says we will do something, why aren’t we doing it?”
… charters are for defining the normative text we’ll publish. the non-normative stuff shouldn’t matter, but I think it would be nice to be more careful with the wording

Brent Zundel: .. also fine if it stays the way it is.

Ivan Herman: I was careful to only list explicitly those that are only Notes already
… plus hand-wavy text around possible new notes
… I don’t think there’s any way to interpret it that way. But I am happy if you propose something specific

Daniel Burnett: I will do that.

4. DID Rubric

Joe Andrieu: we’ve made some progress. Added a new category. added canonical numbering - easing into the registry idea
… Daniel has updated the criteria that added did:foo as examples. Hopefully next week we’ll have something to review.
… we also have a google doc that contains the second pass draft for possible registry rules.

Daniel Burnett: thank you. Any questions for Joe?

5. Implementation Guide

Brent Zundel: The purpose of bringing this to the group today is to ask the question – would we want to publish the implementation guide as a note, text as it is now, with possibility of updating note in the future… there is a fair amount of editorial work that would be needed to pass pubrules to get it to the point where we can publish as a NOTE w/o modifying content.

Drummond Reed: +1 to including the Implementation Guide in the revised charter.

Brent Zundel: Do folks feel like that’s worth it, who is going to help?

Ivan Herman: Drummond put a comment in IRC which is interesting. If the group doesn’t think the implementation guide should be published as a note, the other option is to make it explicit in the maintenance charter that we want to publish it there, so there may not be urgency

Manu Sporny: +1 to Drummond and Ivan. Orie and Markus have done some work. If they commit to doing the editorial work to get it out, then I’m in favor of publishing it, but otherwise not
… there are sections that need a fair bit of elaboration before it is ready to publish.
… I think we can pick it up in the recharter.

Markus Sabadello: I’ve been contributing to implementation guide… on topic of representations and preserving @context.

Drummond Reed: +1 to including it in the recharter.

Markus Sabadello: There is an open PR by Orie to add another opinion on how to do that, we should merge that.

Ted Thibodeau Jr.: +1 to publish as Note before this WG ends and include it in new Charter. Just in case new Charter gets blocked, keeps Guide visible, and makes plain the intention to continue to improve it.

Markus Sabadello: Other than that, I agree with Manu, a lot of content doesn’t have context on where it comes from, don’t have a strong opinion on if it should be published or not.
… I have been contributing a bit on the implementation guide. And there is a PR from Orie adding a different viewpoint. Other than that, I agree that a lot of the content doesn’t have good context, so I’m not sure if it should be published or not

Daniel Burnett: I think it’s better to publish now
… we won’t have the same people in the maintenance group. I think it is important to put a stake in the ground and publish what we have now.
… otherwise we risk not having a Note published at all

Drummond Reed: +1 to publishing a first version now.

Daniel Burnett: I think it would be better to publish the implementation guide before it is perfect. Same for the Rubric, we should have published it months ago as a first step

Joe Andrieu: +1 excepting the did:foo fake references

Daniel Burnett: any last comments on implementation guide?
… it looks like there is interest, but we need someone who agrees to do the work. I think Manu has done more than enough for this group. Who would be a good person to tie up what we have?
… I’m guessing Manu would be fully willing to advise someone
… This is where “we” needs to become “you” or “I”
… until we have that, sounds like the group is okay not going to publication

Charles Lehner: I’m willing to help

Daniel Burnett: will you chat with Charles to get him started?

Manu Sporny: happy to. Charles, send me an email

Daniel Burnett: Charles, if you could get the major part done in the next two weeks, that will give the group time to look at it.

Ivan Herman: forewarning. From the moment of voting on a working group call, it will take ten days to publish. We need to be careful with timing
… it is not that far away.

Kaliya Young: September 16 is World Identity Day :)

Daniel Burnett: hopefully we will have time if the bulk is done by the end og August.

Drummond Reed: Really? World Identity Day? Wow, cool.

Kaliya Young: https://www.id-day.org/

Kaliya Young: ((its also weirdly enough - my birthday))

6. DID Spec Registries

Daniel Burnett: is there anyone who has topics for this or would like to walk us through?

6.1. Should registry track how to contact DID method authors? (issue did-spec-registries#174)

See github issue did-spec-registries#174.

Manu Sporny: let me try and suggest something. We have a number of issues that are “needs contact info”
… Joe, I’m not sure how you feel about that. Can we close these?

Joe Andrieu: for the outstanding issues, I’m happy to close them. I would still like to get the requirement that new additions have contact information

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

Joe Andrieu: that should be part of registry process?

Manu Sporny: let’s get that in there. We need a PR. Joe can you take that?

Joe Andrieu: yes, I can do that.
… One question, I had initially stuck it in mentally, but that would mean for all properties, not just DID Methods. Do we want that?

Manu Sporny: let’s keep focused on just DId Methods, then we can expand it later if needed.
… this would say “We need contact information for DID MEthod authors, at least an email.”

Ivan Herman: there are quite a few of these without contact info. Does that mean we will remove those methods that haven’t responded?

Manu Sporny: my suggestion, we have contact info, we have github handles, but we should say we need email addresses moving forward.

Ivan Herman: I don’t have an opinion, but it should be clear.

Joe Andrieu: in my experience, a github handle is a poor way to communicate. There isn’t even a claim of authorship

Manu Sporny: we had also discussed marking them as “Unresponsive DID Method Author”

Joe Andrieu: some of these methods aren’t compliant. Is there some process to remove those methods that aren’t compliant.
… Daniel and I reached out to let them know about the Rubric. We didn’t reach out about non-compliance.

Manu Sporny: we are seeing that there is a need to deprecate things, like publicKey,
… maybe we need labels for did methods as well. This is a provisional did method that isn’t compliant with v1.0, and the author is unresponsive.
… we can add labels that give people an idea as to the current state of things.

Drummond Reed: we had talked about actually separating the DID Methods, particularly due to the large number of them. A single step for DID Methods to self-attest compliance to the official spec.

manu irc: +1 to separate tables for DID Methods that are “in a bad state”
… that would be a filtering process that results in the tags Manu mentioned. I suggest separate tables. If we have methods that never respond and don’t react. They would be in a separate table to indicate they never did what they needed to show they were in compliance.

Justin Richer: -1 to a second table but a status or tag is less offensive

Ivan Herman: just noting there is already a mechanism in the table. did:git is withdrawn, it is crossed out
… we should use that mechanism
… what drummond said is doable as well, but that is a lot of work to separate them

Markus Sabadello: I like the idea of labels. We also discussed a status field. We could also indicate whether a test suite has been submitted.

Drummond Reed: +1 to indicating if a test suite has been submitted.

Charles Lehner: maybe also a flag for whether it is mentioned in the DID Rubric?

Markus Sabadello: wanted to mention issue 83 is related to this. Registration process of methods vs process for other entries could be addressed by this discussion

Manu Sporny: We could always delete (offensive language) because it violates the registration rules.

Joe Andrieu: I agree with the general sense. Deleting could leave holes, so keeping things around and adding labels makes sense. But we also need the power to delete things that are inappropriate. So the editors should have that power.

Drummond Reed: +1 to giving the DID Spec Registries editors the choice for how to maintain the registry (in concert with the guidelines)

Manu Sporny: nest steps. Sounds like for 174 we’re just going to have a label that says: “no contact information” or something like that. We need to say that an email address is necessary. We add that label to methods that don’t have that.

Drummond Reed: +1 to a list of labels

Manu Sporny: more generally we need to come up with a list of labels that we believe we will be applying: deprecated, v1.0 compliant, etc.

Daniel Burnett: +1 to giving editors choice here, with the reminder that “we prioritize end users over implementers, and implementers over spec writers”

See github issue #-.

Manu Sporny: going back to the issues.
… I am scanning the rest of these to see what we need to discuss.
… I recommend that the editors mark things as pending close that should be closed.

6.2. PROPOSAL: Addressing Old Registration Entries (issue did-spec-registries#265)

See github issue did-spec-registries#265.

Manu Sporny: let’s pick up 265. This is Orie discussing old registration entries. Orie suggests separate tables, Justin -1 and says use labels. Concrete suggestion: we add labels as a first pass to address issue 265

Brent Zundel: adding labels that say they are wrong in some way but not remove them.

Drummond Reed: as a first pass indicates that we add labels, then decide later to move them into different tables?

Manu Sporny: yes

Drummond Reed: I am in favor of that

Manu Sporny: any objections? we label everything them decide later if we want to do more?

Daniel Burnett: sounds like agreement

Manu Sporny: do we have a volunteer to attempt a first round of labelling?

Ted Thibodeau Jr.: +1 label, then decide about segregation (too bad we still have no table sort in respec)

Drummond Reed: I don’t want to be the only volunteer, but I am one volunteer

Manu Sporny: my expectation is that Joe will be doing a chunk of that work as well for the DID Methods

Joe Andrieu: okay

See github issue #-.

Daniel Burnett: we are at the end of the meeting
… any last comments?

Joe Andrieu: cheers, folks!

Daniel Burnett: thank you everyone, thanks to scribes, bye all