Re: Mozilla Formally Objects to DID Core

Thanks drumond - is good ;)

I suppose the next step is some kind of registry that applies the rubric to
the actual collection of DID methods?

On Thu, 2 Sept 2021 at 14:23, Drummond Reed <>

> 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
> <>—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 <> of
> the DID spec, we specifically compare the DID spec to the *URN spec*, RFC
> 8141 <>. In fact we
> deliberately patterned the ABNF for DIDs
> <> 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
> <>.
> Now: guess how many URN namespaces have been registered with IANA?
> *SEVENTY*. Count em.
> <>
> 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 <
>> wrote:
>> On Wed, Sep 1, 2021 at 7:17 PM Steve Capell <>
>> 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

Steve Capell

Received on Thursday, 2 September 2021 04:32:07 UTC