Re: DID Formal Objection Status Update (Dec 2021)

I agree with a lot of Melvin's points.

There are a number of ways of seeking rent in a standards compliant
ecosystem, including implementing standards faster than everyone else and
then building dependencies on them as a way of driving market consolidation
or concentration.

The W3C process can be thought of as an attack vector regarding the
concepts of "decentralization" or "competitive markets" from this
perspective.

I think the best measure of success with respect to W3C RECs is diversity,
and measuring where most of the value of implementing the standard is
accrued, and aiming for a higher number than 1, 2 or 3 companies.

The important thing is that W3C RECs are not used to perpetuate
unsustainability, inequality, or violate ethical web principles, but I
suspect that this will also always be subjective.

One could argue that anything built on a payment system that is not crypto
currency based also suffers from these same challenges...

Imagine trying to use a payment system without feeding one of a small set
of established businesses..

It's a similar problem as trying to use a token without feeding the
pre-mine.

There are cases where we might prefer to seek federation over
decentralization...

Centralization ( or federation) isn't always a bad thing, see
https://en.wikipedia.org/wiki/Visa_Inc.

OS
ᐧ

On Fri, Dec 10, 2021 at 3:52 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Sat, 4 Dec 2021 at 17:42, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> Hi CCG-ers,
>>
>> This email contains the full-text of a "status update" letter that I sent
>> to
>> the W3C Advisory Committee (all 450+ W3C Member company representatives)
>> earlier this week, on behalf of the DID WG.
>>
>> As a reminder, we have a DID Formal Objection FAQ that goes into more
>> detail
>> on each item below:
>>
>> https://msporny.github.io/2021-didwg-formal-objection-faq/
>>
>> -------------------------------------------------------
>>
>> Dear Advisory Committee Members,
>>
>> Most of the DID Objectors and a number of Members of the DID Working Group
>> have been in communication with each other over the past few months in an
>> attempt to understand the Formal Objections in depth and produce concrete
>> proposals that might achieve consensus. We have made some progress, and
>> this
>> email summarizes the current state of the discussion.
>>
>> Below are described the current points of contention, addressing which
>> will
>> require additional concrete proposals:
>>
>> Standardizing "Truly" Decentralized Methods
>> -------------------------------------------
>>
>> There seems to be general agreement among the objectors and DID WG that a
>> good
>> future state would be to have a handful of "truly decentralized methods"
>> that
>> are standardized and broadly adopted. The challenge is that there is no
>> concrete proposal among the objectors or the DID WG that would achieve
>> standardizing a set of "ideal" DID Methods in the near term, because
>> there is
>> no agreement on what "truly decentralized" means. This challenge was one
>> of
>> the reasons why standardizing DID Methods was explicitly out of scope for
>> the
>> first iteration of the DID WG. At least one of the objectors believes
>> that to
>> have been a mistake, but will have to concretely articulate how whatever
>> alternate path they propose will lead to a better or more guaranteed
>> outcome.
>>
>> The definition of "truly decentralized methods" was a topic of discussion
>> for
>> much of the DID Working Group's lifetime, and the discussion produced the
>> DID
>> Rubric which lists over 36 different types of decentralization that one
>> might
>> consider when selecting a DID Method. The WG asks that the objectors be
>> concrete in defining which types of decentralization matter to them in a
>> way
>> that will result in consensus for the DID WG re-chartering process.
>>
>> Usefulness of DID Core, by Itself, as a REC
>> -------------------------------------------
>>
>> At least one of the objectors believes that the DID Core specification by
>> itself is not useful enough to publish as a REC because it does not
>> standardize at least a few "truly decentralized methods". The DID WG
>> believes
>> that DID Core by itself is useful as a REC today because it enables
>> software
>> libraries to be written that conform to the DID Document data model
>> (rotatable/revokable public key expression and service descriptions) as
>> well
>> as the interface for resolving a DID Document using a DID Document
>> Resolver.
>> This is the sort of interoperability that the WG targeted and what the
>> test
>> suite demonstrates today. Standardizing the interfaces that the DID
>> Document
>> provides is useful in and of itself. Further standardization of "truly
>> decentralized methods" will also be useful for instructing implementers
>> on how
>> to interact with the ecosystem, but that must be done with great care to
>> ensure that we do not prevent other decentralized methods. It's not that
>> we
>> don't have options; it's that consensus around those options remains
>> elusive
>> for a variety of political and technical reasons as demonstrated by the
>> formal
>> objections.
>>
>> The DID WG asks that at least one of the objectors be concrete about why
>> they
>> don't believe it is useful to publish DID Core as a REC. The DID WG
>> understands that at least one objector wants us to show "more" interop,
>> but
>> concretely articulating that more interop is possible at this time is
>> challenging because 1) the objections contain conflicting requirements,
>> and 2)
>> there is no consensus around what "truly decentralized" means; those that
>> utter the phrase appear to mean it to be an objective measure, but upon
>> analysis, it tends to turn into a subjective one. Nevertheless, the
>> objectors
>> will need to make the case why the DID WG and implementers are misguided
>> in
>> their request for publication as a REC and why DID Core, by itself, is not
>> useful enough for it to become a REC.
>>
>> Practical Usefulness of did:key and did:web
>> -------------------------------------------
>>
>> At least one of the objectors does not believe that did:key and did:web
>> demonstrate the sort of utility that is practically useful. The DID WG
>> believes that did:key and did:web are useful. A number of implementers
>> make
>> use of did:key for ephemeral DIDs in production settings, while did:web
>> offers
>> large institutions an on-ramp into the DID ecosystem without having to
>> commit
>> to a "truly decentralized" DID method.
>>
>> The DID WG was planning to standardize did:key and did:web for practical
>> reasons (people do use these DID Methods, which do exercise most features
>> of
>> DID Core), but the Formal Objections have made us question whether we
>> could
>> put those DID Methods into a charter that wouldn't receive further Formal
>> Objections because they're "not decentralized enough". The DID WG asks
>> that
>> objectors propose concrete alternatives to did:key and did:web that will
>> achieve consensus during the rechartering process of the DID WG.
>>
>> Centralized DID Methods
>> -----------------------
>>
>> Many of us (objectors and DID WG members) do not want to support the
>> registration of "centralized" (by some definition) DID Methods. However, I
>> expect that we all understand that we can't stop centralized DID Methods
>> from
>> existing, just as we cannot all agree on which factor(s) outlined in the
>> rubric define "truly decentralized" methods, and it's better to document
>> the
>> reality of the entire ecosystem than pretend that part of it doesn't
>> exist. We
>> could refuse to register centralized DID Methods, but then we must make
>> the
>> whole "is it decentralized enough" value judgement when people try to
>> register
>> their DID Methods, which often does not come down to an objective measure.
>>
>> If any of the objectors would like to pursue this, the DID WG would need
>> to
>> understand what concrete set of objective requirements we could apply to
>> all
>> DID Methods to draw a clear line between "centralized" and
>> "decentralized".
>> Given the hours of discussion this topic has received in the DID WG, I
>> expect
>> it will be difficult for the objectors to put forward concrete objective
>> criteria that the group has not already considered.
>>
>
> Great post, thanks for sharing
>
> I think "truly decentralized" will always be a subjective call
>
> Stating the obvious, decentralization is a spectrum rather than an absolute
>
> That being the case, what objective questions could be asked in this regard
>
> The solution is fairly clear in my mind.  And that is:  if the system has
> monetary tokens, and those tokens were part of a centralized premine, it's
> centralized
>
> ie it's an aim to extract royalties at a protocol level, not through
> patents, for which the w3c is quite bullet proof, but by other means
>
> W3C RECs, IMHO, should act in terms of royalty free protocols, and act in
> that spirit
>
> So in that respect did:web and did:key AFAIK pass this test.  Some of the
> did: methods in the registry would require more scrutiny, to test whether
> they really are as decentralized as claimed
>
>
>>
>> Sustainability and Conflict Within Ethical Web Principles ("EWP")
>> -----------------------------------------------------------------
>>
>> As a general rule, the objectors and the DID WG care about sustainability
>> and
>> the W3C Ethical Web Principles[1] (EWP). The DID WG would like concrete
>> guidance from the W3C TAG, such as updated sections in the Web Platform
>> Design
>> Principles[2] that are more thoughtful about balancing conflicting EWP
>> requirements, such as may arise between sustainability and innovations in
>> PKI[3] to support digital human rights. Part of this discussion mirrors
>> the
>> "decentralized enough" issues highlighted above. What is "compliant
>> enough"
>> from an EWP sustainability or EWP freedom of expression perspective?
>> When a
>> solution exposes conflict between various principles, then what is the
>> priority of each principle? What is the burden of proof to demonstrate the
>> magnitude of the effects of any concerns? These questions are larger than
>> the
>> DID WG.
>>
>> Our hope is that the objectors' concrete guidance here is going to be the
>> same
>> as ours — create guidance that firmly addresses how EWP are to be measured
>> across all W3C specifications and then apply that evenly to all W3C
>> specifications. This is too important to be done piecemeal in a single
>> W3C WG
>> that is not holistically focused on the EWP or the Web Platform Design
>> Principles.
>>
>> --------------
>>
>> I hope this summary of the current state of discussion helps those that
>> have
>> an interest in the DID Core Formal Objections. Corrections, comments, and
>> questions are encouraged.
>>
>> On behalf of the W3C DID Working Group,
>>
>> -- manu
>>
>> [1] https://www.w3.org/2001/tag/doc/ethical-web-principles/
>> [2] https://www.w3.org/TR/design-principles/
>> [3] https://en.wikipedia.org/wiki/Public_key_infrastructure
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> News: Digital Bazaar Announces New Case Studies (2021)
>> https://www.digitalbazaar.com/
>>
>>
>>
>>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>