DID WG Telco — Minutes

Date: 2022-01-11

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Pierre-Antoine Champin, Michael Prorock, Shigeya Suzuki, Brent Zundel, Markus Sabadello, Charles Lehner, Orie Steele, Dmitri Zagidulin, Ted Thibodeau Jr., Manu Sporny, Justin Richer, Drummond Reed, Ryan Grant, Adrian Gropper, Joe Andrieu, Michael Jones, Daniel Burnett, Juan Caballero

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Charles Lehner

Content:

1. Agenda Review.

Brent Zundel: A few minutes to Ivan, then talk about meeting schedule, then a few minutes about the id method, then the bulk of the time for the keri method..
… Anything to add/modify?.

2. New staff contact.

Ivan Herman: Some of you probably know that I have partially retired this year..
… I am still active at W3C but on a reduced hour compared to before..
… Other fact is that there are new activities with the VC WG, and with the canonicalization WG..
… Bottom line is that I cannot be the staff contact for all these at once..
… After discussing it with Brent, I decided I will stay active in the VC WG with Brent….
… I am happy to introduce Pierre-Antoine Champin, “Pa”, who will be the staff contact for this WG..
… While the FOs are underway, I will also stay along, so there can be a smooth change..
… Pierre-Antoine knows a lot about the Semantic Web, and about JSON-LD, made an implementation of JSON-LD in Rust..

Pierre-Antoine Champin: Thank you for the kind introduction.
… As Ivan told, I joined the W3C team a year ago, as a fellow..
… Before that - I’m technically still - an associate professor..
… Involved in other groups… JSON-LD 1.1.
… I’ve followed at a distance this group’s activity….
… I didn’t write a JSON-LD impl in Rust, but contributed to an impl.
… I think that will give me time enough to get into the swing (Ivan staying along).

Manu Sporny: Very excited to have Pierre-Antoine involved! :).

Ivan Herman: But you mastered Rust which is more than I could do with it… :-).

Brent Zundel: Reminder: Credentials Community Group (CCG) meeting after this meeting. Discussing chair election process as a chair has stepped down..

3. Upcoming meeting schedule.

Brent Zundel: In recognition of the fact that we exist as a working group due to administrative extensions of our charter, in order to wait out the formal objection processs….
… … and in recognition of the monumental work that has been done, the chairs will be curtailing meetings going forward.
… We will be keeping abreast of changes….
… So we won’t be discussing did registries, rubric, impl guide, etc. We’ve published them, and feel the work is primarily done,.
… and feel deserving of spending a little less time on DIDs..
… We ask you keep this slot on your calendars, but unless you get an agenda announcement, don’t come, since we won’t be here..

Manu Sporny: +1 on the proposed direction..

Drummond Reed: +1 to this transition.

Brent Zundel: If nothing more to discuss, this may be our last meeting..

Orie Steele: +1 on the proposed direction.

Ivan Herman: Just to make it clear, we don’t intend to close down the repositories. Any discussion on GitHub - which this group is very active on - is of course very possible and welcome..

Brent Zundel: Yes, continue to work offline. If anyone feels the group needs to meet and discuss something, that’s possible..
… I don’t think it’s necessary to do a proposal… We’ve fulfilled our charter..
… But if someone wants to propose a proposal, we have time….

Adrian Gropper: Where might we discuss biometrics as it relates to the current or future DID specifications?.

Brent Zundel: the CCG probably would be the best place.

Orie Steele: Biometrics should be discused here: https://github.com/fedidcg/.

Ivan Herman: At this moment, the CCG….
… What we don’t know yet is what exactly we will put in the charter for a future version of the DID specification..
… Originally the idea was that the next version of the DID WG would be the maintenance WG, and so would not include something like that… but who knows, these days things are changing rapidly - maybe we will have a full-blown specification on our hands.

Orie Steele: DIF would also be a good place to discuss biometrics, there is a device binding work item in the wallet security group..

Manu Sporny: I think a maintenance WG is fine, the community is doing DID Method interop in the CCG on did:key and did:web, and it’s not clear if that work will make the three orgs that have raised FOs happy. So, +1 for maintenance WG for next DID WG..

4. did:id Method.

See github pull request did-spec-registries#363.

Markus Sabadello: This is a new PR to add a DID method to the registry.
… I have reviewed it and requested changes..
… I think it’s a pretty extreme example of a centralized DID method that has significant privacy issues… big potential for surveillance and censorship, and other problematic things..
… I think this stands against everything DIDs stand for… But we decided centralized DID methods can be registered.
… But I think some of these issues should be mentioned in the method specification.
… (did:id by Mastercard).
… They have some of these considerations in there, but there are many others they should be mentioning….
… tracking, etc..
… Summary is that even though the method spec has a Privacy Considerations section, I think it is missing much that matters, and therefore the method spec is incomplete..

Manu Sporny: I think we should discuss this after recharter.

Orie Steele: +1 manu, this is a charter conversation… that aligns with the FOs perspective as well, AFAIK..

Manu Sporny: Markus, I appreciate that you are trying to fight from a principled position, but we would be changing the rules…. compared to the ones that came before it..
… We want to improve the registries, we can do that later… one thing would be to apply all the normative statements in the DID Methods section, make an announcement months in advance saying methods need to be updated or fall out of the registry.
… But I think even then Mastercard would be re-registered..

Markus Sabadello: Completely agree we shouldn’t change the rules of the process. I don’t think we should allow centralized DID methods. Can’t change that now. But the Privacy & Considerations section doesn’t discuss the considerations..
… Same as if the DID Syntax section didn’t describe the syntax of the DID….

Drummond Reed: I am willing to offer to facilitate a dedicated discussion w/the Mastercard team about what changes would be necessary to accept their method if that would help..

Manu Sporny: These are different rules – I want to be crystal clear about this..

Manu Sporny: We have not applied this level of scrutiny to any other DID Method..

Markus Sabadello: Section doesn’t describe the privacy considerations. We have requested changes from a lot of changes from other DID methods that were incomplete and missing significant parts, and that’s also what we should do here..

Dmitri Zagidulin: this group created the registry rules and can change tham. We’re under no obligation to apply the same criteria, we can change the rules going forward..
… I understand we have limited charter status; I would propose we do not accept any more, or await discussion of this DID method until the next chartered group..

Justin Richer: huge +1 to everything Dmitri just said.

Orie Steele: The charter should guide a change of rules… I hear a proposal to pause all new registrations… make a proposal please..

Joe Andrieu: I agree with what Manu and not with what Dmitri said. I think it’s against our framework to change the rules. I agree don’t like centralized methods….

Michael Prorock: +1 manu and JoeAndrieu.

Justin Richer: -1 to JoeAndrieu.

Joe Andrieu: But when we change rules because we don’t like it, it’s like abandoning free speech because we don’t like what was said..
… We could have criteria that might remove methods… but I believe we meet the requirements as said, and would abandon our moral integrity to change it.

Orie Steele: justin_r that’s not a generous interpretation, I am hearing that we can change the rules, and that we should use the charter to give use clearer powers regarding these changes..

Markus Sabadello: This one isn’t spec conformant..

Michael Jones: We decided we would not apply criteria to determine spec conformance….

Orie Steele: +1 selfissued.

Michael Jones: Otherwise we have no grounds to run a registry if we’re going to pick and choose what to register..

Manu Sporny: There is no requirement to be spec conformant, Markus..

Michael Jones: We should stop that and register it right now..

Manu Sporny: To respond to what Markus said, we have no such requirement to be spec conformant. We call out a couple things (have to do the CRUD stuff), but we don’t require full spec compliance (we should in the future, when we’ve got our act together on all these things). Agreeing with Mike Jones.

Markus Sabadello: I think if it’s not spec-compliant, we do have a rule in the spec registries that says that DID methods that don’t meet the requirements in DID Core won’t be accepted….
… Even if we don’t apply it, since in the past we haven’t, even then I think this registration should not be accepted as-is, because it’s incomplete..

Manu Sporny: Just about every DID Method is incomplete… not a good criteria..

Brent Zundel: We’ve heard arguments for an against merging it. The chairs leave it to the editors to make a determination here. We will note any objections..

Michael Prorock: +1.

Manu Sporny: Editors, I suggest a determination to merge it as-is..

Manu Sporny: +1.

Orie Steele: +1.

Drummond Reed: I wanted to suggest the editors should discuss it on the call on Thursday..

Orie Steele: -1 to discussing, we have discussed this on the editors call for months..

Manu Sporny: The ditors discussed it on the last week’s call..

Drummond Reed: -1.

Drummond Reed: I believe, Markus, we should have a conversation directly with the Mastercard team directly, and then have a vote..

Michael Prorock: -1 to yet another discussion.

Drummond Reed: I think Markus’s points have been well-made….
… I think they would make changes that are satisfactory.

Justin Richer: for the record and the notes: I agree w/ drummond and markus_sabadello re: registries and think dmitri’s got the best proposed approach.

Brent Zundel: Thank you for this conversation.

5. did:keri Method.

See github pull request did-spec-registries#395.

Brent Zundel: Changing the source repository for this method.
… KERI was created and then brought into DIF..
… There was a split in the KERI community, and one of the pieces of that is did:keri..
… This PR moves the source repository link to outside DIF.
… We’ve been essentially asked to arbitrate a decision that’s not ours to make..

Markus Sabadello: In contrast to the previous topic, I don’t actually have a very strong opinion here..
… As a background, I believe this was worked on in DIF. Then there was a PR to change the location, and there has been a long discussion..

See github issue did-spec-registries#399.

Markus Sabadello: There was interesting discussion on something called a change controller - who would have the authority to make changes to a registration - Juan created an issue about that, #399, on how to set up privileges and governance for making changes..
… I made a proposal that whoever is listed as a contact has the right to make changes, and is responsible for the consequences.
… to attempt to keep controversy out of the WG..
… Note that this may be a change of rules.
… In this particular case I’m not sure if we should handle it like that; maybe for future changes..
… In this case I think we should wait until their community issues a result.

Manu Sporny: +1, there has been conversation.
… We’ve always put in things like contact email to mean something like change controller… Suggest we do a bulk search-and-replace to change “contact” to “change controlller”.

Drummond Reed: +1 to Manu’s proposal.

Adrian Gropper: It’s probably not worth taking the group’s time… but I have no idea what the controversy or substantive issue is that we’re discussing. If that’s my bad for not reading this very long thread, let’s move on.

Brent Zundel: For now we’ll move forward but if others want more detail, we can provide some.

Orie Steele: There have been a couple proposals made. We should try our best to run the proposals to record consensus on the call..
… Specifically I think I heard Ivan, Dmitri, Justin… There might be interest in pausing new DID methods until the new charter is accepted.
… (reading between the lines).
… I q’d to run that proposal.

Joe Andrieu: I agree, best resolution is if DIF and Sam can figure it out.
… But if they don’t, existing email contact is best.
… But need to push back that we always had this. In fact Veres One didn’t have one until this week.
… When we reached out to method authors, we had a hard time getting contact info..

Brent Zundel: +1 to Joe.

Joe Andrieu: I think an auto change would be unfortunate… The party to contact might not be the party with authority to make changes..
… +1 to freezing registrations.

Manu Sporny: -1 to freezing registrations.

Joe Andrieu: We should have a controller change property - DID, email, GitHub - multiple mechanisms.

Michael Jones: Should we pause, we are abdicating our responsibility to operate the registry..
… How would people feel if IANA stopped accepting registrations?.

Adrian Gropper: +1 MikeJones.

Joe Andrieu: that’s a good point @selfissued.

Michael Jones: If we’re claiming authority to operate it, we should not pause it..

Manu Sporny: Agree with Mike Jones, again! :).

Manu Sporny: +1 to Mike.

Dmitri Zagidulin: if IANA was about to be rechartered?.

Orie Steele: +1 selfissued.

Markus Sabadello: This is about pausing method registrations, not all registrations, right?.

Justin Richer: -1 to selfissued, pausing is being responsible and not reckless, in my opinion.

Dmitri Zagidulin: it would absolutely make sense for them to pause until rechartering.

Drummond Reed: I just want to assure folks that we are working to resolve the conflicts in the DIF+KERI communities around this.
… Completely different question than what to do about the registries..
… In fact there’s another call right after this one. Separate from proposals being made now..

Brent Zundel: Two proposals to run. Manu?.

Manu Sporny: +1 to what Mike Jones said. It would be an abdication of our responsibilities. The world goes on, people will create new DID methods..

Orie Steele: +1 manu.

Joe Andrieu: note: registration is not required.

Manu Sporny: Just because we pause registrations, people are still making DID methods. Then there would be no up-to-date place for people to look for specs. -1 to pausing.
… about change controller, concerned… the points are good, but I never saw this like that… It was a change controller field. I think we can at least change contact email to change controller email, because that’s how we’ve been using that field to date..

Drummond Reed: I agree with Manu about not “abdicating” our responsibility for the registry.

Justin Richer: also, registration is not normatively referenced from did core.

Brent Zundel: Queue is empty. Running the proposal Orie mentioned. ^.

Proposed resolution: We will stop accepting changes to the DID Method Registry until the DID WG is re-chartered. (Brent Zundel)

Manu Sporny: -1 (with pitch forks and torches).

Ivan Herman: -1.

Drummond Reed: -1.

Dmitri Zagidulin: +1.

Brent Zundel: -1.

Shigeya Suzuki: -1.

Daniel Burnett: -1.

Justin Richer: +1.

Adrian Gropper: -1.

Joe Andrieu: 0.

Ryan Grant: -1 to registry pause.

Orie Steele: -1.

Pierre-Antoine Champin: +0.

Markus Sabadello: +0.5.

Ted Thibodeau Jr.: -1.

Michael Jones: -1.

Michael Prorock: -1.

Charles Lehner: -0.1.

Brent Zundel: Not passing. Manu put draft language above… repeating as a draft - don’t vote yet ^.

Manu Sporny: modify to changeControllerEmail?.

Adrian Gropper: change controller did?.

Drummond Reed: Agree w/.

Ryan Grant: The idea of change controller rename might be more acceptable if it is paired with a decision to in the future add another contact field, which may be a DID or other variable for contact.

Joe Andrieu: I think that treating the contact email as change controller is entirely in scope and I would support that. But changing the semantics of conformance….
… To rewrite that without their involvement I think is inappropriate.

Proposed resolution: For DID Spec Registries registration, change “contactEmail” to “changeControllerEmail” (with a definition of change controller) to be more clear about the purpose of the field.. (Brent Zundel)

Markus Sabadello: +1, but only apply to future cases.

Joe Andrieu: -1.

Ivan Herman: 0.

Drummond Reed: +1.

Manu Sporny: +1.

Shigeya Suzuki: 0.

Adrian Gropper: +0.

Ryan Grant: +1.

Justin Richer: +1, the registries do not run at the whim of those who register within.

Pierre-Antoine Champin: +0.

Daniel Burnett: +1.

Ted Thibodeau Jr.: +0.5.

Brent Zundel: +1.

Orie Steele: +1.

Charles Lehner: -0.

Michael Prorock: +1.

Dmitri Zagidulin: +1.

Michael Jones: 0.

Brent Zundel: Joe, and Markus, is there language that either of you would approve?.

Justin Richer: markus any changes would only apply to future entries. Retroactive application is … weird..

Markus Sabadello: My assumption is that this would be applied to future cases anyway. Then we would just not change the rules for current cases..

Justin Richer: at least with any registry I’ve ever seen.

Ryan Grant: hmm, good point markus_sabadello.

Joe Andrieu: Justin, you seem to support it, but you suggest retroactive application is weird. That’s my reason not supporting this - it’s a retroactive application to those methods in ways they may not be aware of..

Markus Sabadello: In the whole did:id discussion, we consistently said that we woudn’t change rules for current cases…

Justin Richer: Yeah, I get where you’re coming from. If the worry is that changing the name of the field changes the semantics - people could either update it, or ignore it..
… If we want to be extraordinarily cautious, we could drop the field and add a new column.
… The spectre that keeps getting raised here is that if we change the rules… it’s absurd. The editors do not agree with me, I think that is to this group’s detriment….
… I think changing the name is fine. The registry decides what the info in it means..
… If the registry decides it’s a reasonable interpretation that this field now has this meaning, then we apply that..

Manu Sporny: I think the thing that makes this different is that the editors have been treating all the contact fields as the change controller. We have no other signal as to who should be able to change that thing..
… We’re not changing the semantics of the field, we’re updating the name of the field to be clear to what we are using it for..
… We’re not changing process, we’re making it more clear about what that field is meant to assert..
… That’s why we think it’s okay to make it “retroactively” - we’re just making documentation more clear..

Joe Andrieu: how about adding a changeController field with an email property that we set to the current contactEmail value as default.

Brent Zundel: Please be respectful of one another and make sure we are cognizant of the hard work people have been making. People have been operating with the best interests of the group and the ecosystem at heart..

Manu Sporny: I’m fine w/ holding on did:keri.

Markus Sabadello: Just to clarify what I meant “only for future cases” I think this change should be made both for current and existing DID method registrations, I agree with Manu that we should update it, but for existing changes in process (did:keri) we may want to wait.

Manu Sporny: (until that community sorts its stuff out).

Markus Sabadello: but I think it’s fine for existing and future ones..

Brent Zundel: Five minutes left.

Orie Steele: I am in favor of merging the PR for DID Keri, would love to run a proposal on that… would prefer more proposals and less debate..

Ryan Grant: I think copying the fields allows us to maintain the prior contact field and either inform registrants that we are interested in change controller, and the best we can do is interpret contact as change controller.
… I disagree with that we can change the rules at any time. That’s the same logic the formal objectors used..
… I strongly suggest we don’t be hippocritical.

Justin Richer: to be clear, the ability to change rules is not arbitrary.

Ivan Herman: don’t want to go into the details, but we have to have a proposal of what to do with the did:keri PR, that’s what’s out there right now..
… I agree with Orie that a proposal should be done, but not with what he rights… The community out there, the did:keri community, they have to sort out their own problems..
… To do it here, while it’s unclear, is not right.

Manu Sporny: It will be viewed as arbitrary if we don’t give everyone a heads-up on the rule changes (which is what I’m proposing).

Manu Sporny: We give everyone a big heads up on the rule changes (once we settle on them)… then give people ample time to bring themselves up to conformance.

Orie Steele: +1 justin_r, we can change rules we are chartered to change… the ambiguity originates from what the current charter allows us to do to the registry..

Proposed resolution: we will merge https://github.com/w3c/did-spec-registries/pull/395 since the change controllers / points of contact have approved the PR.. (Brent Zundel)

Ryan Grant: +1.

Orie Steele: +1.

Joe Andrieu: +1.

Ivan Herman: -1.

Michael Jones: +1.

Drummond Reed: +1.

Justin Richer: +0.

Pierre-Antoine Champin: 0.

Markus Sabadello: -1.

Dmitri Zagidulin: +1.

Shigeya Suzuki: +0.

Adrian Gropper: 0.

Manu Sporny: +0 (I’d rather the did:keri community figures their own stuff out first).

Juan Caballero: 0, same reason.

Ted Thibodeau Jr.: +0.

Ivan Herman: Based on the comment, my -1 is equal to manu’s 0.

Brent Zundel: markus_sabadello about your -1?.

Markus Sabadello: In this case I think we should wait for the did:keri community to figure out, because at the point when it was registered, it was not clear the meaning of the field..

Proposed resolution: wait to merge PR 395 until the did:keri community sorts itself out. (Brent Zundel)

Manu Sporny: +1.

Ivan Herman: +1.

Justin Richer: +0.

Joe Andrieu: +1.

Drummond Reed: 0.

Ted Thibodeau Jr.: +1.

Markus Sabadello: +1.

Daniel Burnett: +1.

Adrian Gropper: +1.

Ryan Grant: 0.

Shigeya Suzuki: +1.

Pierre-Antoine Champin: 0.

Michael Jones: -1.

Orie Steele: -1, they can always open another PR.

Juan Caballero: 0.

Markus Sabadello: Like Brent, I’m also DIF Steering Committee, should I have abstained too?.

Brent Zundel: Good conversation, will continue in PR 395.

Ted Thibodeau Jr.: Is there a way we can add a note to the registry, that “xyz is in flux. see {uri}”?.

Juan Caballero: not necessarily, markus !.

Brent Zundel: Thanks for being here. We anticipate the next meeting not happening until February… We’ll let you know… Keep this space available..
… I’ll do my best to say if a meeting is scheduled or not… but I am fallible.
… I’ve appreciated working with all of you, and look forward to doing so in the future. See you again!.

Drummond Reed: Thanks so much to Brent and Dan!.

Orie Steele: thanks, especially for the polling, it helps editors a lot.