How does contact column in registry relate to ongoing change privileges and governance?

[bumblefudge]

From #395 :

@msporny wrote:

As an aside, we should change the word contact in each registration to changeController, because that's the only thing we're really interested in wrt. the registry. That's what we initially meant by contact IMHO. We might need to go back to the WG to confirm this, get a proposal resolved, and make it explicit.

My only additional thought is that perhaps it should be typed as an array and/or non-normative text added to recommend more than one individual account be listed as changeController, and that github orgs/teams should be valid entries as well as individuals, in cases like #395 where editorship or employment changes occur between updates to an entry.

[OR13]

You may request changes of this file:

https://github.com/w3c/did-spec-registries/blob/main/tooling/did-method-registry-entry.yml#L27

Its type is string, to account for Organization Names, or multiple folks.

I don't like the idea of changing the range of contactEmail to an array, I like a clear responsibility and a single point of entry for inquiries.

For most methods that many companies rely on, I would hope to see an SDO host the spec and a WG manage contact requests.

[bumblefudge]

An untyped, human-readable string? What is this, unprofiled JSON?

The array idea was... just spitballing, who am I to define a data model. Mostly, I want to tease out what Kyle, in typical Kyle fashion, explained very crisply in the original PR, in response to Markus' apt alarm at semantic drift.

Seems like you're conflating the contact information to mean that this is also the change controller. ...Historically the contact information was a way for the editors to have a point of contact with spec editors if we needed something from them. Not a further granting of privileges which is the problem I see here. It's unclear who should be granted the additional privileges since it wasn't stated from the outset. [...] One of the reasons I understood that people want specs to be moved to groups like DIF and CCG is because then the rights are maintained by the WG and not by individuals. By allowing individuals to remain the moral controller of the work what additional guarantees are we granted by doing work in the CCG, DIF, IETF or any standards body for that matter?
(emphasis mine)

Should methods defined in an IPR-protected/governed pact have the option (or the requirement) to list an org (CCG, say, or DIF, or TOIP) as its controller or authorizer of new editors? This would be an important change for many DID Methods, including did-pkh.

My other off-the-hook suggestion (equally presented as strawman for elaboration, not as ready for PR!) was to use a GH team/org instead of individual GH accounts, which would greatly simplify things operationally for orgs like CCG and DIF that want those kinds of privileges to be governed collectively rather than by individuals.

[bumblefudge]

I also don't want us to lose or miss Phil's excellent observation, which might be a third strawman, and perhaps the closest of the three to being "ready for PR":

RFC8126 contains the following:
When creating a new registry with First Come First Served as the
registration policy, in addition to the contact person field or
reference, the registry should contain a field for change controller.
Having a change controller for each entry for these types of
registrations makes authorization of future modifications more clear.
See Section 2.3.

[peacekeeper]

One approach could be to decide and explicitly say that "contactName == change controller", but also clarify the role of the contact:

1. The contact can request changes to a registration.
2. It is the contact's responsibility to ensure that they indeed have the legal right to request changes.
3. The contact alone is responsible for any ramifications of a change of a registration.
4. The contact has an obligation to make changes to the contact itself whenever that is appropriate (e.g. transfer of ownership).

Pros:

• Might be what some WG members had been assuming from the start anyway.
• Much less burden on registry editors, since they don't have to verify if changes are legitimate.
• Community disputes about registrations are kept out of DID WG.

Cons:

• Not sure about legal downsides if registry editors don't verify change requests in any way.
• Higher potential for "wrong" registry entries, and therefore harm to interoperability.
• Potential for conflicts escalating elsewhere.

[msporny]

One approach could be to decide and explicitly say that "contactName == change controller"

+1 to what @peacekeeper has suggested above. I think it's clean and is (IMHO) what was originally intended.

I think we should add a check mark to the registration checklist that says something to this effect:

"A trademark review has been performed with respect to the DID Method identifier, there are no known trademark concerns with this DID Method registration, and the change controller accepts all liability for any trademark violations."

[kdenhartog]

I'm more in line with the RFC8126 approach of First Come First Serve where the contact name and the controller are not expected to be the same. The purposes of the contact information is additional optional information that we can utilize to request changes. I'd also prefer that the change controller be a required field that specifically names a github handle that is authorized to make changes. Or if we want to get fancy we could make it a DID that needs to sign with a verification method that we can resolve to verify the update request has been signed by a authorized VM controller of the DID. This would double as an interop use case we could cite, but I don't plan to write the code for this hence the "if we want to get fancy".

[iherman]

The issue was discussed in a meeting on 2022-01-11

• no resolutions were taken

View the transcript

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 #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.

---