DID Spec Registries needs to specify registration process wrt. restrictions.

[jandrieu]

In PR #410, @msporny wrote:

Within days there will be a PR to add it to the registry, who knows who will raise that PR or what they will document, but it could be completely out of our hands to define the property. type is defined and used, but possibly without any of the good points made in this thread.

The real issue here is not this property, but that we have not codified any terminological restrictions on what may go into the DID registries. https://www.w3.org/TR/did-spec-registries/#the-registration-process

Despite aspirations for a completely open world, I guarantee we will have attempts to register properties that we will not be able to tolerate. We have already run into this problem with Method names.

• Trademarks
• Namesquatting
• Profanity
• Obscenities
• Racist terms
• Dehumanizing terms
• Terms simply offensive beyond the pale
• Terms designed simply to break the process (spamish/DDOS attacks)

Today the registry process says:

Any submission to the registries that meet all the criteria listed above will be accepted for inclusion.

Yet the criteria does not include any means for restricting the above mentioned unacceptable entries.

We will have to address how we moderate such abusive practices, or the maintainers of the registries (both the editors and the W3C separately and collectively) will be subject to lawsuits, criminal action, and spam.

[msporny]

Agree that the DID Spec Registries needs to protect against the abuses the @jandrieu raises above. We need a PR to be submitted for that.

[jandrieu]

Do we have anyone in the community who is familiar with the ICANN approach to trademarks? I think that's the clearest example of quality control in a system designed to be open and international.

I'm much less confident there are similar good examples for social suitability and privacy, but at the end of the day I expect we will need to empower some standing group to review and/or mediate. I'd like to propose that extant W3C groups might be good candidates, e.g., PING for reviewing privacy impact of proposed terms.

FWIW, this is NOT ready for PR, at least not a PR that I know how to write. It needs a PR, but we don't have consensus on how we want to handle this.

[shigeya]

I have some knowledge of the ICANN's process in this context since we at Keio did a research project jointly with Japanese Financial Services Agencies: "A Study on Governance for Decentralized Finance Systems Using Blockchain Technologies" in FY2019. I'm one of the authors of the report.

Now, we can write a spec text which describes limitations as mentioned in the above, but in reality, maintaining a "global" namespace (like DNS does) with multiple jurisdiction involvement (international way) is extremely challenging. We need a mechanism to resolve conflicts. At the very least, 1) a mechanism to judge whether the method name is acceptable or not, and maybe 2) an Alternative dispute resolution mechanism for extreme cases.

To understand the context, Jun Murai's interview part of the above report (Sec. 1.1, esp. page 12-18) might help.

[iherman]

@wseltzer I will send you an email on this, but pinging you here, too.

[wseltzer]

Rather than ICANN's domain dispute resolution, I'd encourage looking toward the IANA protocol registries and registration procedures.

As with IANA's expert review, I'd suggest you should describe the criteria for inclusion in the registry and who's the arbiter of whether a submission fits those criteria.

[iherman]

The issue was discussed in a meeting on 2020-12-17

List of resolutions:

• Resolution No. 2: The DID Spec Registries maintenance process will be documented in the DID Spec Registries document..
• Resolution No. 3: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, moral, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Considerations will be expressed as policies in the DID Spec Registries Process section. Entities registering items can challenge rejections first with the DID WG and then with the W3C Staff..
• Resolution No. 4: W3C Staff need not be consulted on changes to the DID Spec Registries, but do have the final say on registry contents. This is to ensure that W3C can adeqately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on them..

View the transcript

2. Registry governance

See github issue #425, did-spec-registries#156.

Manu Sporny: the next one seems obvious, but we had confusion about where the discussion should happen.
… this is to try and clarify.
… the group has a preference on where it happens.
… we'd like it to happen in the DID spec registries issue tracker, followed by the mailing list, and then the credentials CG mailing list.

Jonathan Holt: my reservation about this is there's not a lot of discussion happening in the DID spec registry issue tracker.
… and it's been slow and painful to get my contributions resolved.
… I'm all for the registry but we need to get to some sort of commonality of the extension process.
… I'm more of a proponent of pulling that into DID Core.
… as orie will also point out it was not getting enough communication and coordination, being in a separate repo.

Ivan Herman: i don't disagree with what is said, and it's okay if this is a resolution for this WG, remaining a year or so, but I don't think that this WG should take any resolution which is valid for the continuation WG which has the right to organise its own work.
… I don't see the reason of having this resolution longer term.
… we can agree how it is done now while we are active.
… but why do we want to go beyond that?.

Manu Sporny: to point out it doesn't say anything about future.
… each of these proposals talks in the present tense.
… I agree with ivan, I don't think the proposal is saying anything about the new group.

Ivan Herman: what's in the proposal is something that is happening already.

Manu Sporny: that is correct but people were objecting to it happening in this way, they were saying it must only happen in the DID WG and the problem there is there's conversation that happens in the CCG as well so it's just highlighting the order of preference, but it's okay if the conversations happen in any of these places.

Ivan Herman: the conversation can happen anywhere as long as the result is submitted to the WG.

Manu Sporny: agreed but there was confusion.. we can not pass it and the person that was objecting to the conversation happening elsewhere can raise an issue.
… this is us stating this is where we expect the conversations to happen as a group so that anyone objecting to conversations happening in the CG would understand where group consensus is.

Brent Zundel: is there an intention, should we add normative guidance about the registries and how to add extensions to them to did core?.

Jonathan Holt: and also say what's the governance framework of adding extensions, who are the deciders?.

Orie Steele: i agree with both, the comment I have is that the did spec registries issue tracker, if you're saying that's where the conversation should be had it's not a good idea, it doesn't get enough traffic.
… I'd propose the answer to the first is yes we have to comment in did core about maintenance and governance or we're setting the registry up to rewrite chunks of did core in ways we don't want. DID core has to have some guidance for maintaining the registry.
… we should start the conversation in the did core issue tracker.
… if people want to talk in other places that's fine, but the WG needs to take responsibility and ownership of this registry.

Jonathan Holt: +1 to orie.

Orie Steele: and I'd prefer people not to comment on the did spec registries issues, nobody reads those.

Drummond Reed: I might have misunderstandings.
… let me pose a different path, for feedback.
… if we're talking about ongoing maintenance of the registries and ivan's proposal to have a WG continue that's got that function.
… it feels like that's the primary thing that's going to be going on there.
… so the did spec registries is its own spec.
… when I attended a meeting a year ago in Fukuoka and the w3c session on registries I think all of us, manu was there, we saw this is the model we can follow.
… the governance of that registry spec should be in that spec.
… the maintenance should be of that spec.
… we don't have to have any involve did core, that's separate, but that's about extending did core not maintaining the registries.
… putting the governance in the registries spec, and maintaining the registries spec on an ongoing basis should be the focus.

Joe Andrieu: +1.

Drummond Reed: if i've got that wrong please correct me.

Manu Sporny: that is what i thought too, I thought we had agreed to do that.
… I'm confused by suggestions otherwise.
… we've discussed it before, I guess people missed that.
… the reason it's not in DID core is DID core is going to be locked in stone.
… any suggestion we can put the registries in DID core or that that is a good place for the governance rules to be is deeply misguided, we're going to lock that and it is going to be very hard to update it.
… that is why it is separate.
… Orie, -1 for bringing any of that into did core.
… if you want it to move fast, moving it into did core will guarantee it moves very slowly.
… jonathan asked who gets to say what goes in the registries, it's the editors, that's the first line.

Drummond Reed: totally agree with Manu here - the DID Spec Registries is the place where we maintain the registries.

Manu Sporny: and the governance rules of what they have to follow should be written in the registry, that's what the process is and where it stands today.
… the scope opened on this conversation I was not expecting that, I thought we had decided to split the two apart because the registries need to move faster and have its own issue tracker.
… and it's own management process that was separate from did core.

Ivan Herman: I fundamentally agree with manu, but some additional facts.
… first, my understanding of what orie said is not that the registry should be folded into the core, it should stay as a separate document.
… reflecting to what drummond said, before this meeting I tried to talk to ralph to see where we are with the registry process development, hopefully it wil be part of process 2021, roughly when we end.
… and the approach which seems to develop is that to have a registry there has to be a clearly defined way of management or processing the registry.
… something which is now in section 3 which says how the registry is governed.
… in the new form of registry what should probably happen is that this governance is the only thing that the AC would review.
… and once it is accepted then it is cast in concrete.
… the rest of the registries, the effective terms you put there, would .. like today, you can put it there as long as the governance is followed.
… I have no idea whether that would require at that point to separate the governance into a separate document from the registry itself if the registry is like we hav enow, or if it can stay in the same document, that i don't know.
… my proposal is to leave everything in terms of docs as it is today because that's probably the best way of being future proof if the Process ends up providing a formal registry mechanism.
… the only thing from what orie said which is slightly separate is which repository we would use for issue discussion.
… whether we want to have registry relevant issues discussed in the core repo or not.
… I don't have a strong opinion on that.

Jonathan Holt: manu, I don't fundamentally disagree that the did core needs to be 'locked down', I was agreeing that issue tracking need to happen with as much contributors as possible..

Orie Steele: that's what I was about to say.
… I'm not proposing that we move the content of the registries into DID Core.
… I'm proposing we not use an issue tracker that sees no foot traffic.
… there are already sections of DID core that point to the registries.
… and when DID core is set in stone, those sections are set.
… what the registries WG decides to do at that point, there is a risk of privilege escalation.
… if they decide DID core was wrong and decide to take DID Core apart because they have a WG.
… that could be a thing.
… you can approve new terms and add new deprecation warnings.
… Registries maintained by editors in a new WG without the proper alignment with the DID WG that has ended, and the charter of the DID SPec registries maintenance group, I would fear privilege escalation and goes off and harms DID Core.
… I'm suggesting DID COre should have language about the responsibilities of the registries.
… and should have some guidance on governance.
… and propose we in the DID COre WG tighten that first and discuss it in the DID COre issue tracker.
… and to put the final point on it, definitely NOT merge the two documents.
… DID spec registries might two years from now say things that everyone who worked on DID core is going to be really unhappy with.

Ivan Herman: Orie, you misunderstood... nobody is talking to have a separate WG for the registries. The plan and practice is that this WG with an appropriate scope, would continue as a maintenance WG.
… that means the WG would have in its scope the maintenance of the Core as well as the registries.
… there is no separation of responsibility.
… the only difference between the current WG and the maintenance WG like we have now with VC, is that the Core document should consider to be essentially done, which does not exclude addition to its technical content, taking care of errata etc.
… and the continuation WG would have the right to do so.
… there is no problem there of what you were afraid of.

Brent Zundel: question - does registry governance need to be normative and how does that work if the registries are a non normative note?.

Ivan Herman: this is something slightly open. what probably the process 2021 will say is that the registry would represent a kind of document which does not exist today.
… it is a not a recommendation, there is no CR phase.
… it is not a NOTE because it is reviewed.
… but the only thing cast in concrete like a REC is the governance of the registry.
… that's exactly the problem that you are saying that this is the way it will work, there will be a review of the governance that cannot just change.
… and the content will obviously evolve.

Manu Sporny: I think we can put this in a proposal.
… hopefully that addresses both jonathan's and orie's concerns.
… I want to speak to why registries tend not to get a lot of discussion.
… stuff in registries tends to be extensions that people fundamentally don't care about unless it's theirs.
… people tend to not be too concerned about plumbing, it's somebody else's problem, i think that is what we are suffering from and every registry suffers from.
… moving the discussion into did core is not going to change that, people will continue to not care about plumbing.
… I also think let's keep the issue tracker separate. I think the reason the CDDL stuff didn't get a ton of review is people aren't depending on it yet.
… if people start depending on it or care about it you will see more feedback.
… I expect a very sharp uptick in interest when they can't pass the test suite because the CDDL is causing that.
… there's a timing aspect of this.
… everyone wants to get IDD Core done before they focus on the registries.
… it's frustrating but the reality is moving where people talk about issues rarely gets people to talk about issues they're not concerned about.
… I'm hearing there's a desire to have the maintenance process normatively defined in DID Core.

Drummond Reed: to clarify with orie that if we do this properly, as ivan says they're still putting the process in place at w3c, the goal is the registry becomes something we're maintaining and the maintenance WG can't turn around and change DID Core.
… it can only do what the WG is chartered to do.
… the governance of the registry, we need to decide on that and write it in now, we do that as this WG, and the registry has to be maintained that way, they can't arbitrarily change the governance.
… the way we set up the process those fears aren't going to happen.
… that will come down to each party a stakeholder that says I need a new extension will argue for it, folks who will enforce the governance rules, and away it goes.

Brent Zundel: I'm still wondering is registry governance NEEDS to be normative.

Proposed resolution: The DID Spec Registries maintenance process will be normatively defined in DID Core.. (Manu Sporny)

Orie Steele: +1.

Drummond Reed: -1.

Manu Sporny: +1 (with appropriate pointer from DID Spec registry to the process).

Amy Guy: -0 I think that's out of place in the spec.

Joe Andrieu: -1.

Ivan Herman: 0.

Jonathan Holt: +0, not sure what language would be.

Shigeya Suzuki: 0.

Joe Andrieu: it feels to me that the structure of the registry should be self defining.
… Orie, I don't know how to characterize your fears in a diplomatic way.
… the maintenance group needs to be able to change anything because we don't know what might happen.
… if it was literally locked down, we wouldn't have a maintenance group. There may be lawsuits.. it's the maintenance group's job to figure that out within the scope of what is chartered.
… I'm not worried about the fears because that's their job is to navigate those two tensions.

Orie Steele: I can get behind that.
… I think the concern here is that there's going to be a living thing with less eyes on it than the DID WG.
… everything method in there might get annotated with ethereum considered not safe, bitcoin considered not safe... who ever is merging those, are people watching it?.
… I agree it's plumbing, but if it's done wrong it can kill you.
… as long as there is enough structure in the registries and something formal that the registry editors can't just give themselves god privileges.
… it' can't be an unbounded authority.
… I agree we don't know what will need to be updated.
… we have to account for some of that.

Drummond Reed: +1 to defining the governance process for the registries in the registries spec since that's how the proposed process is supposed to work for registries at W3C..

Orie Steele: I just feel uneasy about the way that its governance is defined today.
… I'm not specifically seeing language to improve that which is why I'm concerned. but possible we can fix it.

Drummond Reed: The governance section of DID Spec Registries is an open action item..

Manu Sporny: the reason why we decided to put the maintenance process in the did spec registries doc in the first place, is we want people to read the process to add to the registry while you're looking at the registry.

Jonathan Holt: +1 to Orie, perhaps the language in did core points to the charter of the maintenance group for the governance.

Manu Sporny: so it's obvious, it's at the top of the document how to add stuff.
… with respect to Orie's concerns, you can't stop a concerted set of individuals of making the changes you disagree with, but you can put enough oversight over the doc, so it is hopefully prevented or if it were to happen there is a process to go through by appealing to the WG and if you're not happy then appealing to w3c staff.
… anything beyond there says you don't trust w3c process or any of the checks and balances.
… and there's not much we can do outside of that.
… If you want people to look at this stuff, you can't wish it into existence. It's only going to have as much people looking at it as care about it.
… the vast majority of people just do not care about the plumbing. I agree bad plumbing can kill you.
… people only pay attention when the pipes are bad. When they're good they don't care.
… It's specifically up to the editors to make sure people look at it when things come across to be merged.
… Eg. let's say somebody decided to register did:nike.
… the first thing the editors say is no that's trademark.
… and someone says no I want it in there, i'm going to raise it, they say talk to the DID WG, and they say no, and the person insists, an dthey escalate to w3c who has the final word.
… that gets more people looking at it, without needing a heavy oversight process.
… fundamentally to get people looking into it, it is the editors job.

Ivan Herman: I try to understand the worries of Orie.
… today, you are the editor of the registry document.
… you are part of the WG.
… and you know you don't have the right to accept any PR just out of your own judgement.
… and that pr can be merged only through the approval of the WG.
… there is a first level, the WG has the responsibility of what happens with the registry doc.
… this is exactly the same situation as what will happen with a maintenance WG.

Drummond Reed: +1 to document the governance in the DID Spec Registries. If possible let's agree on this call who is going to collaborate on the PR.

Ivan Herman: there's no change. The Editor of the registries whether it's you or someone else, should not have more right than what you have today.
… if you are not worried about this problem right now then why would you be worried about the problem with a maintenance WG?.
… And what's in section 3 which is the registration process, as far as I can read it, it's only a technical registration process, it doesn't have anything about governance. I would be fine if we want to put something into that section on the governance of the registration process.
… it is part of a note, section 3 will be something reviewed eventually when the new process comes into being, so section 3 of this document must not change... can only change as far as a REC can change.
… we sort of cast it in concrete.

Amy Guy: yeah... agreed we need governance in the registries, I think that's the core issue...

Drummond Reed: when we define the governance process in section 3, I always thought the biggest challenge was if we don't have a formal structure how do we arrange that governance to work.
… as soon as I heard the proposal of the maintenance WG, it gets much simpler.
… we still need to define the process, but now we have a WG who can appoint and maintain editors.
… the first line is the editors following the process.
… an appeal can go to the WG, then to w3c.
… I think that's all that's going to be necessary.
… if everyone is good with that let's make it so.

Brent Zundel: it sounds like it would be good if the governance principles or guidance for the registries were normative.
… but it would be better at this point if the guidance was part of the DID Spec NOTE so that when process 2021 exists with the registries portion, the maintenance group could then make that portion of the registries NOTE normative?.

Ivan Herman: yep.

Manu Sporny: to reaffirm that we are going to put this process in the DID SPec Registries document.
… that doesn't mean we can't change it in the future once the w3c process stuff is resolved.

Proposed resolution: The DID Spec Registries maintenance process will be documented in the DID Spec Registries document.. (Manu Sporny)

Orie Steele: +1.

Drummond Reed: +1.

Manu Sporny: +1.

Amy Guy: +1.

Ivan Herman: +1.

Brent Zundel: +1.

Shigeya Suzuki: +1.

Joe Andrieu: +1.

Jonathan Holt: +1.

Resolution #2: The DID Spec Registries maintenance process will be documented in the DID Spec Registries document..

Jonathan Holt: but, can we refer to it in did core?.

Manu Sporny: the next proposal has to do with who gets to add stuff to the registries and what they should consider.
… the who, the first line is the editors.
… they have to consider copyright, trademark, legal, security, privacy and other concerns.
… we are explicit about that because people are trying to sneak trademarks or racist or other harmful terms in, and it is up to the editors to decide what causes harm.
… but if the editors say no,t he person wanting to add the item, can say they disagree and want WG opinion or I want w3c staff to weigh in on this after the WG has been put forward.

Proposed resolution: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Entities registering items can challenge rejections first with the DID WG and then with the W3C Staff.. (Manu Sporny)

Orie Steele: I hope this isn't a can of worms, but the way it is phrased is that we're singling out the editors as being legally liable? if someone says no I'd be fine.

Ivan Herman: there is no legal liability.

Drummond Reed: right.

Joe Andrieu: are you sure?.

Orie Steele: I feel protected..

Joe Andrieu: we should have a moral clause.
… people could spam the system and make it look unprofessional with things that are not profanity or trademarks, and we should give the editors some way to engage with those issues.

Brent Zundel: i don't think this proposal limits us from adding that additional protection in the future.

Drummond Reed: my assumption is this proposal is an overall directive to the preparation of the governance rules that will go in section 3, an dagree with joe, we don't just provide a list of hey think about these things.
… we need to provide policies, they're not rocket science or hard to write.
… I'm positive with just the folks on this call we can arrive at something.
… if we've narrowed it down to this and the folks on this call care, we can nail it down.
… this is not the whole guidance.
… it's just the agreement we're going to go write that section and put guidance in it.

Joe Andrieu: @manu, can we add "moral" to that proposal?.

Jonathan Holt: i do like the way that ietf uses rfcs to formalise the process for comments rather than just the issue tracker.
… as well as aries and ethereum, where it's a document that has a structure to argue the case, and a formal process to review those documents, provide comments, and bubble up to PRs. I'd like to see that as part of the governance structure.

Drummond Reed: I like Jonathan's idea.

Proposed resolution: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, moral, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Considerations will be expressed as policies in the DID Spec Registries Process section. Entities registering items can challenge rejections first with the DID WG and then with the W3C Staff.. (Manu Sporny)

Drummond Reed: +1.

Orie Steele: +1.

Manu Sporny: +1.

Joe Andrieu: +1.

Ivan Herman: +1.

Amy Guy: +1.

Shigeya Suzuki: +1.

Jonathan Holt: +1.

Brent Zundel: +1.

Drummond Reed: this is productive and a good conclusion.

Resolution #3: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, moral, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Considerations will be expressed as policies in the DID Spec Registries Process section. Entities registering items can challenge rejections first with the DID WG and then with the W3C Staff..

Ivan Herman: this question of trademark, legal, etc, came up in issue 425.
… and I did ask wendy seltzer to comment on this, Joe, I don't know if you saw the reply it's in the issue.
… you may want to look at it, I can't judge it, she's referring to the iana protocol registry and registration procedures to be looked at and maybe use it as a guidence for what we want to do.

Proposed resolution: W3C Staff need not be consulted on changes to the DID Spec Registries, but do have the final say on registry contents. This is to ensure that W3C can adeqately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on them.. (Manu Sporny)

Manu Sporny: this proposal just makes it clear that we don't expect w3c staff to be consulted on every single change to spec registries, but they are the ultimate authority in this.

Ivan Herman: there is a staff contact in the WG anyway.

Manu Sporny: I expect you dont' want to be in every single decision in the registries and for us to be mandated to talk with you?.
… staff in general, whoever that is.

Drummond Reed: +1.

Manu Sporny: +1.

Orie Steele: +1.

Shigeya Suzuki: +1.

Amy Guy: +1.

Jonathan Holt: 0.

Joe Andrieu: +1.

Ivan Herman: +1.

Resolution #4: W3C Staff need not be consulted on changes to the DID Spec Registries, but do have the final say on registry contents. This is to ensure that W3C can adeqately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on them..

Drummond Reed: Nice job everyone.

Brent Zundel: we'll bring up these resolutions on the main call on tuesday. Thanks!.

Drummond Reed: And Amy, you are the best!.

---

[TallTed]

This and w3c/did-extensions#156 should be retitled with correct spelling for terminolgical (should be terminological).

(Noted in both issues.)

[msporny]

PR w3c/did-extensions#240 has been raised to address this issue. This issue will be closed when w3c/did-extensions#240 is merged.

[msporny]

PR w3c/did-extensions#240 has been merged, closing.