Re: Mozilla Formally Objects to DID Core

I completely agree with Christopher—who by the way was the one who proposed
DID methods as the solution to not forcing one way of doing DIDs but
instead enabling the market to innovate. The goal has always been for the
most successful DID methods to rise to the top by actually providing what
the market needs (which is also the point of the DID Rubric
<https://w3c.github.io/did-rubric/>—let the market make its own decision).

Now, here's the REAL irony. Mozilla and others are pointing to the URI spec
and existing URI schemes as the precedent without recognizing that in in
section 9.11 <https://www.w3.org/TR/did-core/#dids-as-enhanced-urns> of the
DID spec, we specifically compare the DID spec to the *URN spec*, RFC 8141
<https://datatracker.ietf.org/doc/html/rfc8141>. In fact we deliberately
patterned the ABNF for DIDs <https://www.w3.org/TR/did-core/#did-syntax>
after the ABNF for URNs—and patterned DID method names after URN
namespaces. And we set up a registry for the exactly the same way RFC 8141
establishes a registry of URN namespaces
<https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml>.

Now: guess how many URN namespaces have been registered with IANA?

*SEVENTY*. Count em.
<https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml>

I don't see anyone complaining about interoperability of URN namespaces.
Amd RFC 8141 was published over four years ago.

=Drummond

On Wed, Sep 1, 2021 at 8:24 PM Christopher Allen <
ChristopherA@lifewithalacrity.com> wrote:

> On Wed, Sep 1, 2021 at 7:17 PM Steve Capell <steve.capell@gmail.com>
> wrote:
>
>> Can’t help but sympathise with the concern around the cacophony of DID
>> methods
>>
>
> All I can say is the many examples of the success of architectures
> leveraging multiple methods based on history history. In my case, Microsoft
> would have blocked TLS if we (the TLS editors) didn't support their
> Kerberos cypher suite, (a "method"). Which of course, no one used, and I
> later heard from one of the engineers was known to be more market
> positional than any technical reality.
>
> But Microsoft would have bounced TLS and used their only embrace & extend
> (effectively SSL 2.1) fork if we didn't accept Kerberos. There were also
> many more ciphersuites that were never used except in POCs. I argued in TLS
> 1.3 that we should deprecate more of them by putting expiration dates on
> them, and I also requested that we learn from that lesson and do the same
> with DIDs, but there wasn't consensus for this.
>
> My opinion is most DID methods will evolve or disappear as the market
> matures. IMHO this is the whole reason why we elected to use methods in the
> DID architecture in the first place. It also allows for innovation while
> discouraging blocking.
>
> -- Christopher Allen
>
>