did-extensions
did-extensions copied to clipboard
w3c
Consider allowing multiple registrations by the same "name" in a given category
This would address the issue of multiple entities using the same "name", some or all without registering their use, when such use otherwise makes operational sense to them.
Importantly, this would encourage and support registration by all relevant entities, instead of locking out all but the "first to the gate".
Similar to overloaded TLAs, ETLAs, acronyms of all sorts, and even Wikipedia articles, this would enable stakeholders of all kinds to disambiguate between such overloaded "names" as needed by their use case.
This could be equally well applied to all entity types supported by the registries.
I have not fully considered all possible ramifications, but I am fairly certain that the benefits would outweigh the costs.
Wikipedia solves this problem not by allowing multiple entries with the same "name", but by providing a way for the same "name" to be mapped to multiple unique Wikipedia entry URLs.
IMHO, the solution is not to allow multiple entries under the same registry entry value (a more precise term than "name")—those MUST all be unique—but to allow the registrants to describe the entry with text that would do that "mapping".
To do otherwise would defeat the purpose of having a registry.
We had a case in the Universal Resolver where two different communities were using the did:trust DID method name, see here for a short discussion: https://github.com/decentralized-identity/universal-resolver/issues/186.
In this case, there was no bad intention, and there was a friendly resolution.
The issue was discussed in a meeting on 2021-08-24
- no resolutions were taken
View the transcript
8.1. Consider allowing multiple registrations by the same "name" in a given category (issue did-spec-registries#304)
See github issue did-spec-registries#304.
Ted Thibodeau Jr.:
… Allowing multiple registration by the same name...
… It's entirely likely people will create the same 3 or 4 character name.
Manu Sporny: https://github.com/w3c/did-spec-registries/issues/304
Ted Thibodeau Jr.: It seems worthwhile to let them all register, and let the collisions sort out naturally.
… It puts things in the open, rather than let collisions happen more later.
Markus Sabadello: For DID methods, or properties, or everything?
Ted Thibodeau Jr.: Initially I was thinking of methods, but I think it's worth it for all of them, really.
Manu Sporny: I get the philosophy, Ted, of why we would want to do this.
… I'm concerned that it allows bad actors to kind of mess with DID methods that they don't like.
… First come first serve... Second registration -> Have a discussion, could create problem for community.
… I'm concerned about saying we can have double registrations without something pushing back on it hard.
Ted Thibodeau Jr.: I think there will be a lot of those conversations.
Justin Richer: if we allow things to be registered twice what's the point of a registry?
Manu Sporny: agree with justin_r
Drummond Reed: Exactly
Daniel Burnett: agree with justin
Markus Sabadello: For DID methods, I think it's an interesting topic - I'm not sure I have a strong opinion. We did have a case in our Universal Resolver project where there were two different implementations of the same DID method - two implementations of two different DID methods with the same name.
… I think the argument could be made that there are different communities using the same name.
… For parameters, I think it would create problems for the data model and defeat the purpose of the registry.
Kyle Den Hartog: For methods, +0. As Markus highlighted.
… For properties...
Ted Thibodeau Jr.: just consider https://acronyms.thefreedictionary.com/DID
Drummond Reed: I think allowing this would completely defeat the point of the registry. If there's contention, we can have a process for handling that.
… The disambiguation on Wikipedia - which I love - resolves it by actually giving them different names. Is that's what being proposed?
… But the registry entries need to be unique, or what's the point of having the registry at all.
Ted Thibodeau Jr.: I'm hearing it, strongly disagreeing with all of you. It means a lot of people will not register what they are using.
Justin Richer: if they happen "in the wild" then people aren't using the registry
Ted Thibodeau Jr.: The collisions have likelihood of bad results in a big way.
Manu Sporny: We're saying it could theoretically happen, and we're disagreeing... I suggest we delay, come back and rethink it.
… If it's just 2 or 3, we talk to them and they change the name, fine. But if all of the sudden people try to registry, we tell them no and they use it anyway, that's a bigger issue we need to discuss.
Ted Thibodeau Jr.: I'm not so much thinking of people who register before they deploy, but people who try to register a test thing they have already deployed and it will just be that way.
… People trying to tell what they are dealing with by looking at the registry... it would be problematic.
Daniel Burnett: IANA has registries. Precisely this situation has occurred. Justin, could you talk about this?
Justin Richer: I am not a deep expert on IANA processes. But there is a long-standing formal process. It basically boils down to, if someone shows up with something already registered, IANA is going to say no.
… Unless they say it's an update to a thing we already know about.
… For example, HTTP URI now points to the newest HTTP specification rather than the historical ones from the late 90s.
… Things like that happen all the time. But those are cases where it's not two completely unrelated things trying to use the same name.
… In IETF, registry must be consulted. In this WG, not, despite my arguing for it.
… If people are going to collide in the wild, it means they're not using the registry to communicate.
… I could write a browser that does something weird with an HTTP URL. I'm allowed to, but it's not compliant and anyone using it will be confused. That's okay, that's supposed to fail - That's the whole point.
Daniel Burnett: Okay. Other comments?
Ted Thibodeau Jr.: I think the things supposed to fail in that way are different...
Justin Richer: completely disagree w/ted
Daniel Burnett: I think we are practically at the point, Ted, where if you can garner support for it, great, otherwise may just have to tell us I told you so.
Ted Thibodeau Jr.: I'll put a bottle in the cellar and wait.
Drummond Reed: "put a bottle of champagne in the cellar and wait" <== great remark
To elaborate a bit, my thought was to allow for registration of multiple methods named (for instance) did:trust, similarly to how we must sometimes handle multiple humans with the same name in live-space, perhaps with a new column for actually unique identifiers { did:trust_communityID1, did:trust_communityID2, etc. } or the like.
Yes, this means that Universal Resolvers may have to do some heavier lifting, perhaps enlisting human aid in choosing which uniquely-identified method should be applied to URIs with colliding methods. Those humans might need to see more of those DID methods' registration details to make the selection. That's OK, to me.
The working group discussed this and passed the following resolution.
RESOLUTION: Allow multiple registrations in the DID Methods extensions list but make it clear in the registration process that doing so is potentially problematic (due to interop concerns). Duplicates will have an issue raised to track the concern and noted in the list, with the registrants asked to address the concern. Duplicate registrations will
https://www.w3.org/2024/12/19-did-minutes.html#e64a
I suggest this can be closed.
