Re: Mozilla Formally Objects to DID Core

Thanks drumond -   https://w3c.github.io/did-rubric/ 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 <drummond.reed@evernym.com>
wrote:

> 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
>>
>>

-- 
Steve Capell