DID WG Telco — Minutes

Date: 2021-07-20

See also the Agenda and the IRC Log


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



Chair: Brent Zundel

Scribe(s): Joe Andrieu, Dave Longley


Brent Zundel: today’s agenda. press release. implementation feedback. options for allowing recommendations to be updated, proposed recommendation, next steps
… maybe extra time for did spec registries

Joe Andrieu: I’d like to propose something about the rubric

Brent Zundel: ok

1. Content for a Press Release

Brent Zundel: w3c, recognizing we are close to a recommendation, would like to create a press release about it
… they are seeking content for the press release.
… quotes from implementers, user stories, projects
… We have approximately a week or two
… anyone who would like to provide content for an official release, please contact the chairs
… Any other questions?
… Ok. Moving on.

2. Status of Implementation Feedback

Manu Sporny: Hi.
… Great news! All the features seem to be implemented. We’re in good shape.

Manu Sporny: https://w3c.github.io/did-test-suite/

Manu Sporny: Here’s the current report.
… For those that haven’t been tracking Github, Drummond and Markus got two implementations in. I confirmed they are from two separate code bases
… You can test and see results. We have a solid two implementations for that feature
… The other items we were waiting for test results, we show we have good implementations for everything.
… Everything survived.
… Everything we put in the spec has been appropriately implemented.
… We are ready to go to proposed Rec

Drummond Reed: Woohoo!

Daniel Buchner: Good job Markus/Drummond

Drummond Reed: Thanks. Markus is a hero.

Dave Longley: great work, everyone!

Brent Zundel: I’m just going to let that sink in
… You guys are amazing. Thanks, Manu

3. Options for Updating the Recommendation

Brent Zundel: The WG had agreed to follow “Process 2020”

Geun-Hyung: Geun-Hyung has joined #did

Brent Zundel: This may not mean a lot, but it does change our process slightly
… for example, it changed how we did CR (with snapshots)
… Another thing it gives us is the option to add an indication in the spec that “new features may be added to it”
… New features may be shown to the community and reviewed, then the maintenance working group will have the option to add this to the spec
… There are reasons for and against
… we have a few minutes

Manu Sporny: https://github.com/w3c/did-core/pull/787/files

Manu Sporny: real quick. the text is simple
… Digital Bazaar is very supportive of this
… This will allow us to keep pace with the market while at the same time protecting the specification
… thanks to existing process
… W3C can protect against break changes
… This has a lot of positive upsides and very few negative downsides

Markus Sabadello: I was a little concerned when I first heard.
… there may be features that could cause problems or conflict with decisions we made
… For example, matrix parameters

Daniel Burnett: This is only about whether a new WG with a new charter would be needed in order to add features, or whether it could be done under the existing charter.

Markus Sabadello: we looked at that and decided no. Someone could reintroduce it.
… The problem is that the people who cared may not be part of the group when it gets added later
… Net net, the positive outweighs the negative.
… We also have the DID spec registries, so we would need to figure that out as well

Joe Andrieu: I’m opposed to this. Pretty strongly. I think if we look at just the number of people on this call, 17, we have dwindled as we’ve gotten over the core work of figuring out how this will work. Many of my core concerns didn’t make it and some did.

Justin Richer: +1

Joe Andrieu: There were arguments over privacy and so on. Not everyone will be able to be here to give the same amount of consideration, debate, and time to figure out what to do about new features and it could undermine the independence of this architecture we’ve created. I’m good with a maintenance mode, with errata and so on. Having an extension registry is good too. Having another WG handle this blessed by W3C is ok, but otherwise seems like a mistake.

Drummond Reed: yes, its one of those rare situations where I’m not in full alignment with joe
… my concern is what Joe articulated
… One of the reasons W3C enabled it is for specs that cut new ground
… the ability to make a change based on market feedback is more of an asset than a liability
… I share Joe’s fear. There are downsides.
… But as one member of the group. I plan to stay involved with monitoring any proposals for features or changes
… I hope others on this call feel the same way.
… What I’ve heard about the process. You have to go through the same process.

Daniel Buchner: Propose that we create a Joe-Batsignal, and any new proposals require shining it into the sky for 48 hours before concluding discussions

Drummond Reed: The power of a recommendation, once you have anything that “changes” it will get a significant scrutiny

Brent Zundel: one reason to support this is that features that go into the spec have to undergo wide review and they have to be shown to have at least two independent implementers
… the Requirements are a higher bar than just getting something into the registries
… The other thing to share. When a maintenance group wants to add a change, they propose a rec change with a 60 day review period
… All liaisons must be contacted and have two months to say everything they hate. And if there isn’t enough support, they don’t go in

Dave Longley: +1 to acknowledge that there are risks, but I also think that dangerous features will get a bright light shone on them and attention drawn bringing people in to review (and Brent is mentioning a long review period to allow for that)
And acknowledging the potential for imperfections is not a bad thing. That’s not one of the risks with this concept, the risks are that features people don’t want would get in.

Justin Richer: While I appreciate the effort to raising the bar for things like this
… it genuinely makes me question what’s the point of an extensibility of a spec if we can still just add new features to sneak changes in
… If we believe we did extensibility right, this should not be a necessary function
… Any additions beyond errata should be handled by a newly chartered working group to do just that
… Other groups, like IETF, this proposal would never fly.
… Having a bis document immediately after publishing (w/in years), that’s just signaling that you don’t think you got it right this time.
… I share the previously stated concerns about people not paying attention any more

Drummond Reed: I don’t agree with Justin that this “signals that we didn’t think we got it right”. W3C adopted the new process specifically to allow this option.

Manu Sporny: Joe and Markus and Justin are making good points.
… One other note: the web platform, especially HTML5 already works this way
… big fight between W3C and the WHATWG

Justin Richer: arguably the web was already broken and this is a response to that

Manu Sporny: The other point is that when these new revisions are made, formal objections can be a useful tool.
… If we formally object now, we don’t get a spec
… With this, it will be far less socially bad to formally object.
… Because all you are objecting to is the particular amendment
… We shouldn’t take this decision lightly

Brent Zundel: proposal

Proposed resolution: The DID WG will allow new features to be added to the DID Specification after is has become a recommendation (Brent Zundel)

Manu Sporny: +1

Joe Andrieu: -1

Justin Richer: -1 this feels like a sneaky way to get around the agreed upon extension mechanisms

Drummond Reed: +1

Brent Zundel: +1

Dave Longley: +1

Charles Lehner: +0.5

Shigeya Suzuki: -1

Markus Sabadello: +0.5

Daniel Burnett: +0

Ted Thibodeau Jr.: +1

Brent Zundel: The proposal is not passing

Adrian Gropper: -1

Brent Zundel: next topic

4. Transition to Proposed Recommendation

Drummond Reed: Bingo ;-)

Joe Andrieu: No. It wouldn’t be.

Brent Zundel: I would like to say at this point, to outline process-wise what is happening
… manu has created a static version of the DID specification
… link, manu?

Manu Sporny: This is the Proposed Recommendation DRAFT: https://w3c.github.io/did-core/PR/2021-07-29/

Brent Zundel: This is the document we are voting on today
… Our process requires 7 days for folks to object to a past resolution
… This document does not have anything feature-wise that was not already present in last candidate recommendation
… All of these changes from CR have been editorial
… We hope that it is unlikely that anyone who voted for the transition (today) would change their mind, but one could
… we are going to combine the window to a single week

Manu Sporny: that should cover it.

Brent Zundel: I think that’s good.

Daniel Burnett: yep. The publication date is the key thing. The question is if someone objects between the 29th and …
… we might need to say that any objections received will invalidate…

Joe Andrieu: [discussion of proposal text]

dan: director is going to ask, Were there any objections?

Brent Zundel: text looks good to me. any other suggested changes?

Daniel Burnett: before we run it…
… this is it. Proposed Recommendation is the last stage at which the group actually does anything.
… After this, we don’t touch it again.

Proposed resolution: Publish the DID Core specification at https://w3c.github.io/did-core/PR/2021-07-29/ as a Proposed Recommendation on July 29th 2021 with a review period that ends on August 26th 2021. Any objections from DID WG members before July 27th 2021 will require the group to rerun the proposal. (Manu Sporny)

Drummond Reed: Agreed, we are ready for that.

Manu Sporny: +1

Adrian Gropper: +1

Dave Longley: +1

Markus Sabadello: +1

Joe Andrieu: +1

Brent Zundel: +1

Shigeya Suzuki: +1

Daniel Burnett: +1

Drummond Reed: +1

Ted Thibodeau Jr.: +1

Charles Lehner: +1

Amy Guy: +1

Geun-Hyung: +1

Resolution #1: Publish the DID Core specification at https://w3c.github.io/did-core/PR/2021-07-29/ as a Proposed Recommendation on July 29th 2021 with a review period that ends on August 26th 2021. Any objections from DID WG members before July 27th 2021 will require the group to rerun the proposal.

Drummond Reed: Woohoo!!!

Brent Zundel: No opposition. We are resolved!
… We did it!
… We made a spec! Whew!

Markus Sabadello: we DID it

Dave Longley: lol.

Brent Zundel: Amsterdam seems like just yesterday

Drummond Reed: Yeah, it’s actually 5, but who’s counting? ;-)

5. Next Steps for DID WG?

Brent Zundel: next topic
… a few options: start chartering another version or “Nah, we’re done”

Joe Andrieu: I want to propose something for the rubric.
… In particular, we are still finding that there’s lots of work to be done there. There’s good criteria that hasn’t made it in and some that doesn’t really work for all methods. For example did:web has a different architecture and it doesn’t work well with some of the criteria for other DID methods with consensus mechanism.s

Daniel Buchner: Consensus for did:web: whoever a social media company hasn’t cancelled yet

Joe Andrieu: I’m working on writing up DID registry rules but it seems to me that we don’t know all the DID criteria now and we’re still learning that. I’d like, in a structured way, to be able to add new examples and criteria moving forward.

Manu Sporny: +1 to what Joe said, that seems like good work

Justin Richer: dbuc so exactly the same as any owned data network. :)

Manu Sporny: Also a maintenance working group for errata and non-normative text
… It would be good to have some exemplar DID methods out there, did:key, did:web
… Also, we are starting the linked data integrity group. that’s moving towards charter.
… keeping the spec aligned with that may be a useful thing to do

Brent Zundel: because the maintenance working group would be to republish
… would updating the note sufficient
… be sufficient?
… which way is the best option
… where as updating the note is less overhead

Daniel Burnett: at a minimum the group does need to be able to do maintenance on the core spec itself
… when there are agreed upon bugs. That’s needed. More than that seems dangerous
… I see no problem with a maintenance charter, updating the context of registries
… It’s the rules changes that tend to be challenging in terms of the IPR concerns that dominate charter discussions
… suggesting a charter that allows for bug fixes and non-normative corrections to the core spec.
… additions or modifications to registry contents, not rules,
… and updates to or creation of non-recommendation track notes

Drummond Reed: +1 to Dan’s proposal

Joe Andrieu: I’d like a lightweight process. Instead of a note, I’d like to turn it into a registry for the group.

Brent Zundel: that works with Dan’s proposal

dan: if a registry is created before the group ends, it works. Otherwise, I would suggest we don’t put in.

Brent Zundel: dan’s proposal…
… create a charter that puts in scope maintenance for bug fixes and editorials, managing registries (additions/modifications), and updates to existing notes.
… also new notes could be created.
… In part to support the ability to split notes.
… I think that’s unlikely, frankly, but it’s allowed in my proposal

Manu Sporny: asking directly, does the work like to standardize did:web and did:key

Brent Zundel: to clarify, you mean create a standards track recommendation?

Manu Sporny: yes

Brent Zundel: q if you want to discuss

Daniel Burnett: I’m not against the work… you’ll understand
… my concern is calling it a maintenance charter and adding new recommendation track work items

Manu Sporny: I won’t stand in the road on this – just raising the question :)

Daniel Burnett: that could include new IP scope that the group needs to handle
… I don’t want to stand against this, I’d just like to get a charter quickly

Brent Zundel: +1 to Dan’s point. Fully support the work, but don’t see it as part of maintenance work.

Manu Sporny: We can always up-charter :)

Joe Andrieu: +1 same. good work, not maintenance though

Daniel Burnett: Yes, we can abolutely up-charter

bumblefudge: +1 to Dan B – support the work AND support a quick maintenance charter

Shigeya Suzuki: +1 too.

Drummond Reed: +1

Brent Zundel: next steps are drafting a charter and sharing it with the community

6. DID Spec Registries

Brent Zundel: we had a number of very long detailed conversations about DID spec registries, how they should be outlined, rules, regulations, and made a bunch of resolutions

Brent Zundel: https://www.w3.org/2019/did-wg/Meetings/Minutes/2021-05-11-did#resolution1

Brent Zundel: this is a link to resolutions about the registries
… explicitly CDDL is no longer required and current CDDL will be removed
… JsonSchema will no longer be required and will be removed (except for that in did-core)
… There was some opposition. These were two resolutions that have been made, but not yet resulted in changes to the registries
… Is there anyone in the group who is willing to raise PRs to address these resolutions?
… Can we move this forward?

Drummond Reed: Noting that Orie is not present on today’s call.

Manu Sporny: Markus, I’d like you to raise a PR. You had some concerns with Orie’s proposal, so maybe you can find a path through

Markus Sabadello: I’d be happy to do it

Manu Sporny: ty markus_sabadello :)

Brent Zundel: Fantastic
… we look forward to seeing that PR
… Wow! We have 8 minutes left!
… We’re done.
… We have a proposed recommendation forthcoming.

Manu Sporny: woo! The Chairs are amazing too!!!! :)

Drummond Reed: Thank you Joe!

Manu Sporny: (and Ivan!)

Brent Zundel: Thanks for all your hard work.

Drummond Reed: Thank you so much to the chairs.

Dave Longley: thank you, Brent! for excellent chairing – same to Dan! and thank you Ivan and Joe and all!

Brent Zundel: It’s been a long, awesome two years.
… See you next week

Markus Sabadello: :)

Shigeya Suzuki: :)

Brent Zundel: lol

Dave Longley: :)

7. Resolutions