Re: DID Formal Objection Status Update (Dec 2021)

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