Re: DID Formal Objection Status Update (Dec 2021)

I'm familiar with the Howey Test, and some amount of securities law after
watching the space evolve over the past few years.

Here is an interesting article regarding the topic:

Stacey S. Chubbuck, Securities Law and Antitrust Law: Two Legal Titans
Clash Before the United States
Supreme Court in Credit Suisse Securities v. Billing, 62 OKLA. L. REV. 145
(2009),
https://digitalcommons.law.ou.edu/olr/vol62/iss1/5

One of the most relevant parts:

> The Court held that the 3 underwriters were entitled to implied antitrust
immunity because antitrust laws and securities laws are “clearly
incompatible,” and simultaneous application of them would detrimentally
affect the securities industry.

> IMHO W3C RECs, especially those pitching decentralisation, should avoid
recommending block chains that may not pass the Howey Test

I agree with the "especially those pitching decentralisation" part of this
strongly... but I am not sure that it is actually helpful to avoid
standardizing technologies that might be controlled (potentially via a
monopoly) by corporations that have securities.

https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.

> The case has been of significant interest within the tech and software
industries, as numerous computer programs and software libraries,
particularly in open source, are developed by recreating the functionality
of APIs from commercial or competing products to aid developers in
interoperability between different systems or platforms.

This looks similar to "standardizing" a "commercial product" that might
directly impact the price of a security.

I am sure a lawyer could smash this hand wavy argument to bits... but the
general idea that "SDOs should not standardize technologies associated with
securities" seems not great to me...

Sometimes a for profit corporation wants to encourage interoperability, and
take a piece of their technology platform through a standardization process
to encourage interoperability and for the benefit of users and
developers... The fact that they are a corporation should not be used to
attack the technology that they have built, particularly if they are trying
very hard to make that technology interoperable, directly substitutable, or
standardized...

Yes, they should not abuse the standards process, by inventing standards
that only they will implement, and thereby driving market consolidation...
But the W3C should also not be in the business of deciding if standards
exploitable for advertising should be approved at a rate higher than
standards approved for privacy / security... or maybe it should, and we
should consider the organization captured by the industry?

See https://news.ycombinator.com/item?id=27985783

In essence, I would argue that securities, market concentration,
interoperability, privacy, are all factors... and the W3C is made of
people, who are exploitable and have bias, some of whom rise above that
bias to defend the web and its users.

> The W3C operates, in general, on the principle that protocol layers
should be "unencumbered"

IMO this is insufficient, because while the protocol layers may be
"unencumbered", if they only connect you to encumbered operating systems,
it does not help much... and if the operating systems are securitized and
new web standards can be used to drive additional revenue to specific
operating system vendors... we have the same problem we were trying to
avoid.

In essence, when the W3C approves another standard related to advertising,
they are moving the price of all securities associated with advertising...
even if the protocol is "unencumbered".

It's possible that similar is true of "standardizing" DID Methods, and it's
a major reason why we decided NOT to do that as part of the first DID WG
charter.

I might even argue that the W3C should never standardize specific DID
Methods, based on this, in much the same way that they might standardize
web payment method identifiers but not apple or google wallet payment
method identifiers.

An "unencumbered" protocol on a network (blockchain or advertising) that is
controlled by a corporation / security is still a concern... But maybe
outside of the purview of the W3C... and we should strive for the process
to be applied consistently.

OS

ᐧ

On Tue, Dec 14, 2021 at 2:06 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Mon, 13 Dec 2021 at 19:20, Orie Steele <orie@transmute.industries>
> wrote:
>
>> 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.
>>
>
> Thank Orie, great points
>
> I think the ethos of the W3C is such that any "rent seeking", as you put
> it, should occur at a layer above the protocol layer.  So that means that
> W3C RECs do not reference for-profit protocols.  However, businesses can
> use W3C protocols in a for profit way, to achieve a competitive advantage.
> A classic example might be Google and the Web.  HTTP does not ever mention
> Google, but Google can use their advertizing model, in the free market.
> The W3C operates, in general, on the principle that protocol layers should
> be "unencumbered"
>
> You see this in the investor decks of some of the block chains.  "Imagine
> you could invest in owning a chunk of the internet back in the 90s".  Or,
> "the first generation of apps made profits at the business level, the next
> generation at the protocol level".  This is real, and people are investing
> large sums based on such promises
>
> That's all a bit abstract, so how can it be made practical and relevant?
>
> It seems to me that the relevant legislation that will be brought in, in
> the next 18 months, in this regards, pertains to the so-called "Howey Test"
>
> https://www.investopedia.com/terms/h/howey-test.asp
>
> "The Howey Test determines what qualifies as an 'investment contract; and
> would therefore be subject to U.S. securities laws.
>
> An investment contract exists if there is an 'investment of money in a
> common enterprise with a reasonable expectation of profits to be derived
> from the efforts of others."
>
> The Howey Test is important for situating blockchain and digital currency
> projects with investors and project backers.
>
> Certain cryptocurrencies and initial coin offerings (ICOs) may be found to
> meet the definition of an "investment contract" under the Howey Test."
>
> Some block chains, or ICOs, are actually unregistered securities.  And
> they are done in such a way that breach existing securities laws.  There
> are real questions over the legality of their day to day operations,
> including criminal penalties on the horizon.  It's a legal can of worms,
> and the danger is that the W3C could end up as some kind of human shield
> wrt future legal issues
>
> IMHO W3C RECs, especially those pitching decentralisation, should avoid
> recommending block chains that may not pass the Howey Test
>
> So for example did:key and did:web probably would pass this test, and
> did:btcr would probably pass the Howey Test, but perhaps did:bnb might
> require more scrutiny as it seems to be controlled by a for profit company
>
>
>>
>>
>> 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>
>>
>

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

<https://www.transmute.industries>