Open bumblefudge opened 2 years ago
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.
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.
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.
One approach could be to decide and explicitly say that "contactName == change controller", but also clarify the role of the contact:
Pros:
Cons:
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."
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".
The issue was discussed in a meeting on 2022-01-11
From #395 :
@msporny wrote:
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.