search

w3c / did-extensions

Decentralized Identifier Ecosystem Extensions
https://w3c.github.io/did-extensions/
Other
120 stars 200 forks source link

How to handle duplicates #569

Open jandrieu opened 4 months ago

jandrieu commented 4 months ago

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 commented 4 months ago

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

wip-abramson commented 4 months ago

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 commented 1 month ago

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