How to handle duplicates

[jandrieu]

As I mentioned this on our call (last week?), there is no requirement in the DID Core spec that method names be unique. However, the current registry editors are following a first-come, first-served policy, which gives an unfortunate advantage to first movers, creating significant problems with name squatting, abandonment, censorship, and maintenance.

I suggest we follow the semantics of phone directories, aka white pages, which regularly list multiple entries for people with the same name. Sometimes they provide meta-data like an address for the reader to disambiguate. What they do not do is restrict listings based on the first to sign up with a particular name.

I realize this undermines the reasonable desire many in this work have, to create an automated discovery mechanism where you can programmatically depend on the method name itself as if it were unique. However, if we base the root of the DID namespaces on a centralized authority, we have merely recreated the pattern successfully implemented by DNS.

The hard problem is figuring out how to deal with the fact of nature that people can, and will, create DID methods that have conflicting human-friendly names (see Zooko's triangle).

IMO, solving this problem in a decentralized way would mean there is no single authority who

1. gets to/must decide who was "first" to register something,
2. gets to decide who can update a listing initially created by someone else,
3. gets to define or restrict mechanisms used by other's DID methods

What we MUST deal with in a centralized manner is the shared specification of how such systems interoperate. That's the URL syntax, DID document format, and the resolution API. That's it.

With consensus on what a DID URL means, what resolution provides, and the API for requesting DID Documents from conformant resolver, then we have an interoperable system that gives everyone the ability to pick and choose which methods they want or need to support, without deference to any centralized authority. Each method's resolvers provide the software component that enables a common interface and developers are free to build to that common interface when integrating different DID methods into their software stack.

That's the hard problem we are here to solve.

[wip-abramson]

This is related to #374, although the discussion is more around how to handle namesquatting.

[wip-abramson]

See also #304, which discusses allowing multiple registrations for the same name.

The issue makes me think that handling duplicates is not just about DID methods, but all properties in the registry. Is that reading correct?

[jandrieu]

@burnburn @msporny @ChristopherA Bumping as this came up at TPAC.

[w3cbot]

This was discussed during the #did meeting on 19 December 2024.

View the transcript

w3c/did-extensions#569

manu: If people are not in the same jurisdiction, then we would just keep the duplicate.

manu: this is the POLL we ran last week, with an addition suggested by Markus, to show people the order in which things were registered.
… In case of a conflict, one of the party may go to a court, and come back to us with a court order to remove the entry (if the other party is in the same jurisdiction).

<Phil-ASU> +1 looks reasonable to me.

smccown: I think that's a great proposal.
… From a practical perspective, what happens for implementers (e.g. the universal resolver) when there are duplicates?

decentralgabe: relates to my comments in the last meeting. If we are not the source of truth, other source of truths will emerge.
… I don't think we are the right people to be a source of truth.

markus_sabadello: that's why the registration order is important.
… If you don't know which one to implement, implement the first one -- unless you have good reason to pick another one.
… we should provide some guidelines.

Wip: if we decide to support duplicates, there will be other issues to deal with.

manu: +1 to markus_sabadello about providing guidelines.

<manu> PROPOSAL: 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 be listed in chronological order by date of initial listing.

<ivan> +1

<Wip> +1

<Phil-ASU> +1

<manu> +1

<JoeAndrieu> +1

<swcurran> +1

<TallTed> +1

<bigbluehat> +1

<decentralgabe> +0

<markus_sabadello> +1

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

<pchampin> +0.5

<Wip> be listed in chronological order by date of initial listing.

<Zakim> manu, you wanted to discuss next steps.

Wip: what are the next steps?

manu: I can raise a PR with updated text, so that we can review it.
… Some mechanical things need to be changed. Entries will need a "first registered" date, which we can derive from the github history.
… We need an issue marker for submissions and duplicates.

<Zakim> JoeAndrieu, you wanted to talk about rules

manu: The text must describe that we allow duplicates, with the appropriate caveat.

JoeAndrieu: wondering if the current rules as framed would satisfy the new Registry process?

pchampin: do we want to move to a W3C Registry?
… I would suggest that we don't call this a registry anymore, as the term comes with expectations of unicity.
… And therefore, that we don't migrate it to a W3C Registry.

manu: there was some confusion. My recollection was that we decided *not* to turn it into a W3C Registry.
… To JoeAndrieu, no the rules are not appropriate right now.

<Zakim> JoeAndrieu, you wanted to say we need to resolve this. I thought we HAD decided to make it a W3C registry, but not call it a "registry"

<Wip> here https://www.w3.org/2024/08/01-did-minutes.html#r01

Wip: we did pass a Resolution saying that our registries are *likely* to be managed as a W3C Registry.

JoeAndrieu: I hope we agreed to not call them "registries", they are friendly list.
… But it was also that we would be guinea pigs to push the W3C process to its limits.

<Zakim> manu, you wanted to note I'm happy to try to make it a registry.

manu: this is more work, and would be a bumpy ride.
… but I agree with Joe that if we are not part of the conversation, we might be imposed things from the outside.

---