Re: Mozilla Formally Objects to DID Core

Steve! You are a mind reader! See this new PR from Joe Andrieu
<https://github.com/w3c/did-rubric/pull/49> on the DID Rubric repo that
proposes exactly that—turning the Rubric into a registry so it can get
smarter as implementations proceed about what criteria really matter in
evaluating a DID method. We spent half of Tuesday's DID WG call discussing
it and the response is very enthusiastic.

I predict that there will be multiple sites and services that will begin to
offer DID method evaluations under all kinds of business models. Ain't the
free market a wonderful thing?

=Drummond

On Wed, Sep 1, 2021 at 9:31 PM steve capell <steve.capell@gmail.com> wrote:

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