Just a note. Fragmentation shouldn't be confused with decentralization. Today we are in the strange point where organizations define even their own "version" or "profile" of the same DID methods (see for example ebsi's did:key version)
Best,
Nikos
--
Nikos Fotiou - https://www2.aueb.gr/users/fotiou/
Researcher - Mobile Multimedia Laboratory
Athens University of Economics and Business
https://mm.aueb.gr
> On 6 Nov 2023, at 6:54 AM, Ryan Grant <w3c@rgrant.org> wrote:
>
> On Thu, Nov 2, 2023 at 3:29 AM Jeffrey Yasskin <jyasskin@google.com> wrote:
>> On Wed, Nov 1, 2023 at 4:22 PM Ryan Grant <w3c@rgrant.org> wrote:
>>> What's your response to the problem that picking winners and losers
>>> directly diminishes the decentralization of the protocol?
>>
>> Standardizing some methods doesn't pick winners.
>
> Unfortunately, your argument is based on an equivocation between
> standardization here and standardization elsewhere.
>
> I simply refuse to allow **this WG** to pretend that it could ever
> have consensus on what DID Methods to standardize. So I would agree
> with you that standardizing some methods (in some **other WG** or
> standards body) doesn't pick winners.
>
> This WG picking winners and losers for standardization would directly
> diminish the decentralization of the protocol because it would present
> the WG's efforts as coming to a centralized decision about which DID
> Methods were preferred for standardization.
>
>> Look at the initial set of standardized URL schemes: ftp, http,
>> gopher, mailto, news, nntp, telnet, wais, file, and prospero. There
>> were certainly some in that set that won, but more of them lost a
>> long time ago.
>
> Yeah, let's look at that list but look at the underlying protocols.
> They all have different people who edited and authored them over a
> span of time larger than a decade. They didn't try to force an
> impossible consensus between each other's goals. The result was good
> for innovation.
>
>> Failing to standardize (and markets, for that matter) can also cause
>> centralization: Say Google hands out DIDs with gmail, and then oops
>> their method turns out to be patented so nobody else can implement
>> it.
>
> That wrongs can occur another way does not excuse promoting this
> wrong.
>
>> I worry that _partial_ standardization is the easiest way to this
>> sort of centralization: one could sell to organizations saying
>> "look, DID (core) is standardized", but part of the critical path is
>> something only the seller controls.
>
> What clever worries you have. You are arguing that since the
> inevitable "partial standardization" that must arise if different DID
> Methods standardize at difference paces and in different places - as
> fully foreseeable in the decentralized specification that Google
> approved the initial charter of - is "the easiest way to this sort of
> centralization" therefore decentralization should be stopped early.
>
> Let me boil that down to its essence so you can hear your own words
> back: you worry that decentralization is the easiest way to
> centralization therefore we shouldn't even try for decentralization.
>
> Well, I'm here trying!
>
>> If the Resolution spec prevents that, I'm all ears.
>
> No sub-specification supporting the Decentralized Identifier
> specification will prevent decentralization. None will prevent
> the different DID Methods standardizing at their own pace and in
> their own forums.
>
> Picking winners and losers directly diminishes the
> decentralization purpose of the working group's output. It's in
> the name. Decentralization deserves respect as a core value of
> the W3C:
>
> https://www.w3.org/TR/ethical-web-principles/#control
>