DID WG Telco — Minutes

Date: 2021-07-13

See also the Agenda and the IRC Log

Attendees

Present: Drummond Reed, Brent Zundel, Shigeya Suzuki, Dave Longley, Charles Lehner, Manu Sporny, Ted Thibodeau Jr., Adrian Gropper, Geun-Hyung, Kaliya Young, bumblefudge, Joe Andrieu, Markus Sabadello

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Drummond Reed, Manu Sporny

Content:

Brent Zundel: welcome everyone

1. agenda review

Brent Zundel: No special topic call this week

2. Status of Implementation Feedback

Manu Sporny: summarized on the mailing list

Manu Sporny: https://w3c.github.io/did-test-suite/#spec-statement-summary

Manu Sporny: ready to go to recommendation as long as we can pass three proposals today
… this is the latest implementation report
… we have support for everything except three features
… other than that we’re ready to go to PR
… some of the implementation reports are missing names
… some of them had syntax errors in the JSON input files
… the full list is in the test suite reports
… they were all editorial fixes to the test suite
… there were 41 DID method implementations
… that is far more than is typical

Markus Sabadello: Regarding alsoKnownAs, it does not show up in the implementation report

Manu Sporny: that’s a bug in the test suite
… if they don’t show up, that means no one has implemented them
… if you search for “insufficient”, it will pop up
… but if you go into the tests and you do a grep for specific implementation features you get different results
… there is a bug that will undercount implementations
… so basically we can trust that the numbers are a minimum

Brent Zundel: If I recall correctly, if alsoKnown was added to our spec, then the ActivityPub spec normatively references our
… spec

Manu Sporny: what it will cause the ActivityPub community to do is to have to define it themselves

Drummond Reed: alsoKnownAs was supposed to be used at Trust over IP Foundation… requirement of all frameworks… disturbed about that.
… It’s also referenced in a section of the appendix – this is how you can use a DID.
… proposing to remove it when it’s got these clear cases of utility, I’m opposed to that.

Charles Cunningham: if two implementation add it to a DID document, would that be sufficient

Manu Sporny: yes, it would be
… in addition, the PR would remove all references to alsoKnownAs in the spec.

Dave Longley: we have a DID spec registries … interested parties should register alsoKnownAs there

Markus Sabadello: I am worried that it did not show up in the test suite reports
… it is also important to understanding the use of DIDs
… so I too believe it is important to keep

Drummond Reed: Both Markus and Brent will tell you, if I was aware that there weren’t sufficient implementations, I would’ve flagged this and worked w/ other developers/method implementers that the property was included… as of the last call, it was not flagged.

Manu Sporny: Yes, it was flagged :( – during a call.

Manu Sporny: That’s why we put it as at risk :(

Drummond Reed: I’d be concerned if we didn’t include it… This is how you use a URN to make an alias…

Manu Sporny: we are out of time. If you look at our charter, this is the end.
… we have, multiple times during working group meetings, we have told people to implement it
… not having it in the core spec does not mean it cannot be added to the DID spec registries
… pushing it off for any further would imperil completing the spec.

Brent Zundel: the actual deadline is the 17th of June

Drummond Reed: I will put it on record that if the 17th is the deadline, I will do everything in my power to make that happen.

Brent Zundel: I am going to put the proposals in the chat
… everyone should have seen them just before the meeting

Justin Richer: Should that be “such as”?

Proposed resolution: While some of the normative statements around JSON Production did not receive at least two independent implementations (such as datetime, double, integer, and null), the Working Group desires to keep the normative statements in the specification to ensure full JSON data model support so future implementations can use the features if they have a need to express those data types. (Brent Zundel)

Manu Sporny: I believe it’s the full list but I believe “such as” should be added to be safe

Manu Sporny: +1

Brent Zundel: I will add that

Brent Zundel: +1

Drummond Reed: +1

Justin Richer: +1

Markus Sabadello: +1

Dave Longley: +1

Shigeya Suzuki: +1

Ted Thibodeau Jr.: +1

Charles Lehner: +1

Joe Andrieu: +0

Adrian Gropper: +1

Geun-Hyung: +1

Resolution #1: While some of the normative statements around JSON Production did not receive at least two independent implementations (such as datetime, double, integer, and null), the Working Group desires to keep the normative statements in the specification to ensure full JSON data model support so future implementations can use the features if they have a need to express those data types.

Brent Zundel: the second proposal is wordier
… so I have to paste in two parts
… this full explanatory text is needed for the director’s understanding
… any changes to the proposal?

Ted Thibodeau Jr.: The proposal is still missing a couple words

Brent Zundel: manu has reposted the proposal

Proposed resolution: While the deactivated: false feature only received one independent implementation, the Working Group desires to keep the feature in the specification. Expressing deactivated: false is optional. The value space (true/false) for the deactivated feature was correctly implemented by more than 2 independent implementations (no implementations used values other than true/false). Implementers could express either deactivated: false or nothing, and all implementers except for one chose the latter option. (Manu Sporny)

Manu Sporny: +1

Drummond Reed: +1

Markus Sabadello: +1

Dave Longley: +1

Brent Zundel: +1

Charles Lehner: +1

Ted Thibodeau Jr.: +1

Shigeya Suzuki: +1

Adrian Gropper: +1

Geun-Hyung: +1

Kaliya Young: +1

Resolution #2: While the deactivated: false feature only received one independent implementation, the Working Group desires to keep the feature in the specification. Expressing deactivated: false is optional. The value space (true/false) for the deactivated feature was correctly implemented by more than 2 independent implementations (no implementations used values other than true/false). Implementers could express either deactivated: false or nothing, and all implementers except for one chose the latter option.

Brent Zundel: these are the two proposals we could take up
… please add yourself to the queue

Drummond Reed: At the risk of repeating what I said earlier – on this particular feature, I strenuously disagree with Manu – not only of structure, but additional items we provided, illustrates a critical feature on how DIDs can be used and the value that they can provide. To understand that there are entire specifications that rely on that feature undermines discussing that in the spec… misses the value. I could live with either one of the proposals, will ensure that implementations are there… it’s explanatory power and that there are folks that rely on that function of that DID spec… removing it from, as well as explanations, devalues it.

Ted Thibodeau Jr.: Because at least part of the implementation was not shown due to the reportage bug, but when you look to see if this was covered in the testing results, the meeting did not say that the reportage was buggy.
… to the other side, this text could be turn into an informational note

Joe Andrieu: I think we don’t need alsoKnownAs is the main spec because it is both feature creep and because it is an active correlation between two identifiers.
… if it were truly used by multiple implementations then we should have it

Kaliya Young: +1 a few more days is good.

Joe Andrieu: but I do support giving a few days to get the implementations

Dave Longley: I would not recommend any proposal today to see if we have the implementations, and we should stick with the process

Brent Zundel: on the topic of not raising proposals now, we don’t want to have the risk of not being able to proceed next week

Dave Longley: +1 ok – I support your reasoning, Brent (that we want a resolution today given the timelines so we can move more quickly)

Proposed resolution: If at least two independent implementations for the the alsoKnownAs feature are not registered in the test suite by 6pm ET Sunday July 18th 2021, the DID Core specification will remove the feature and notify the ActivityPub community of its removal. (Brent Zundel)

Brent Zundel: so I want to run that proposal now

Manu Sporny: +1

Dave Longley: +1

Joe Andrieu: +1

Drummond Reed: 0

Justin Richer: +0 because the test suite is known to be buggy, this seems to be a targeted removal

Kaliya Young: +1

Markus Sabadello: +0.5

Brent Zundel: +1

Shigeya Suzuki: +0 because of potential bugs

Charles Lehner: +0.5

Adrian Gropper: +0

Ted Thibodeau Jr.: -.05

Geun-Hyung: +0

bumblefudge: humanists and editors have floating-point opinions

Ted Thibodeau Jr.: the summary report did not show this feature missing, so any other option seem disdisingenuous
… confirmed

bumblefudge: happens to the geniuses of us

Dave Longley: if this is so important, i’m convinced there will be implementations submitted in the next ~4 days – we should move on

Resolution #3: If at least two independent implementations for the the alsoKnownAs feature are not registered in the test suite by 6pm ET Sunday July 18th 2021, the DID Core specification will remove the feature and notify the ActivityPub community of its removal.

Dave Longley: +1 to what drummond just said, if we don’t have implementations by the deadline, it shouldn’t be in the spec

Ted Thibodeau Jr.: tangential observation – Because of the somewhat surprisingly large number of methods, there should perhaps be a general privacy note that DID methods with few users pose a more significant correlation risk than methods with billions of users. This might fit into the rubric, if it’s not already there.

Brent Zundel: I would encourage those two implementations should be as independent as possible

bumblefudge: @TallTed +1 – i think it’s already in there in some form, though, if memory serves

3. IETF Discussion

Manu Sporny: The WG asked Manu to write an email to the IETF directorate with two asks:
… first, please review the DID spec
… second, the DID WG and other related W3C WGs would like to set up a more long-term relationship where we can have more active, ongoing interactions
… the letter is being created because Mark Nottingham was asking what work we were doing that they should be looking at
… many people have jumped in to make comments
… I propose to make the proposed editorial changes
… the expectation is that I will send it off to the IETF Directorate if there are no objections

Justin Richer: Is the intent to jump over the W3C staff and Wendy?

Manu Sporny: No, we should give Wendy a heads up

Brent Zundel: +1 to giving Wendy a heads up

Justin Richer: It is in fact the IETF that requested this, and it’s a technically a different group

Manu Sporny: I will make that correction

4. Path to Proposed Recommendation

Brent Zundel: Due to the anticipated minimal differences between our current CR snapshot and our proposed recommendation…
… we don’t anticipate this group will need a long review of the final proposal
… we plan to present to the group at the meeting next week the proposal final draft for one final week of review
… during that period we will also run the resolution next week because the resolution also has a seven day window for decision
… the chairs have determined this path makes sense because of the minimal differences between the CR and the proposed PR

Manu Sporny: the last PRs include one about public key multi-base - needs Orie
… [missed this second one]
… alsoKnownAs has been discussed
… rearrange order of the appendices needs editorial review
… updating the IANA guidance needs review
… moving the revision history to an appendix is editorial but needs review
… #780 Update Editors, Authors, and Acknowledgements needs further discussion
… final issue is accessibility of diagrams

Manu Sporny: did Charles did all the alt-text

Charles Cunningham: not yet

Markus Sabadello: RE the SVG, Markus is planning to complete the rest of them

Brent Zundel: that is also editorial
… asks Manu to explain the data-based process for PR #780

Manu Sporny: there are three groups of info that need to be decided.
… Acknowledgements is easy: any contributor
… Authors and Editors are determined by contributions
… for Editors, the data is more clear, it is based on the commits. It’s fairly clear right now that Manu, Markus, Amy, and then contributions drop off after that
… that is resulted in the proposal that Drummond be dropped off the editors list
… Authors on the other hand recognizes contributions to the overall spec
… Drummond is on the Authors list due to early contributions
… Orie is proposed to be added to the Authors list because of the volume of his contributions
… the general idea is that this process is data driven so that it is a fair process

Joe Andrieu: Wanted to make a case to keep Drummond as an editor due to leadership provided

Justin Richer: +1

Drummond Reed: (thank you Joe)

Joe Andrieu: Thank you, Drummond.

Brent Zundel: We can continue that discussion in the PR.
… We are out of time…

5. Resolutions