Re: DID Formal Objection Status Update (Dec 2021)

I agree with pretty much everything you have said, especially the premine /
securities related comments.

> As an editor of that registry, what's the view on accepting chains that
are, in fact, centralized and unregistered securities?

I am not a lawyer, and as editor of the W3C note you are referring to, I am
required to implement the consensus of the WG, I do my best.

My current interpretation of that consensus is that any/all
currently registered methods may be removed in the next WG charter, the
rules for registration may be updated to account for ethical web
principles, which might speak to securities or environmental issues....
changes to the registration process might prevent current
registered entries from being included in the future.

I would say that discussions of sustainability, and securities / antitrust
issues seems to be a growing political problem for W3C members
interested in developing technical specifications... and it's not clear to
me if the W3C has the authority or membership to appropriately address
social or ethical concerns on that scale, but they appear to be recruiting
for / heading that direction based on the recent conversations I have seen.

I hope that the W3C will remain focused on technical standards and not be
eaten alive by politics, documents such as
https://github.com/w3ctag/ethical-web-principles that attempt to capture
"consensus on ethical considerations" run the risk of becoming flashpoints
that jeopardize the mission of the W3C, but others would argue that without
these documents the W3C is in jeopardy of a different kind of failure, as
it may become captured by "privacy" or "sustainability" destroying
"ad-tech" or "blockchain" specs.

The W3C should avoid attempting to do the job of the EPA, SEC, CFTC, DHS,
DOD, IRS, DOJ or any other US or non US government agency.

Regarding registering centralized did methods that may be built on tokens
or normal securities, either registered correctly or incorrectly in all
jurisdictions:

That some securities are registered incorrectly does not mean securities
are bad.

That some http traffic is malware does not mean that all http is bad.

Web2 is filled with fraud, illegal activity, malware, scams, advertising,
child porn, racists and degrading content, the accumulated knowledge of
humanity and cat pictures.

Maybe Web3 will be the same? What other prior might we use to predict its
future?

Perhaps W3C / IANA should be held accountable for enabling all these "bad
things"... or maybe it's better to leave law enforcement up to the
professionals.

I don't think the W3C is in much of a position to control the web, but
carefully shaped principles could shape the next version of it, and maybe
censorship and safe space are more important than freedom of information,
maybe tracking users is more important than saving power... If the
principles have a bias and we use them as tools, they will shape us and our
future.

One group's dystopia is another's utopia...

To answer your question concretely:

- https://www.sec.gov/news/press-release/2020-338

Acknowledging that XRP is a name for a thing that is or is not a security
is probably not a problem (AFAIK registering the string XRP is not bad by
itself... the same goes for DIDs based on XRP, some folks might think BCH
is the real BTC... these are just names....)... violating laws, no matter
what you call the thing, is probably a problem, but it might depend on your
jurisdiction and time... The SEC is allowed to change its mind, just like
everyone else is... maybe one day ETC will become ETH again... who knows.

DIDs are the same... my advice (this is not financial advice) would be, if
you are not sure, don't risk it...

- don't use a DID Method you think might have legal problems...
- don't use a token you think might have legal problems...
- and don't use a service from a corporation that might have legal
problems, or not reflect your standards, ethically, socially or fiscally.

I would add, that if you have concerns about a standard that might be at
odds with your values, like:

- https://www.w3.org/TR/encrypted-media/

or

- https://www.w3.org/TR/did-core/

You should probably show up and advocate for why you think there is a
problem as early as you possibly can, with clean arguments that avoid
personal attacks or triggering political language... stick to the facts and
make your argument as best you can... but remember that nobody is required
to agree with you.

As editor, it's my job to implement the WG consensus, and the current
consensus seems to be that the registry should mostly be a first come first
serve, "no values included" thing.... and that the next wg charter will
probably have stronger opinions.

OS

ᐧ

On Wed, Dec 15, 2021 at 3:41 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Tue, 14 Dec 2021 at 17:24, Orie Steele <orie@transmute.industries>
> wrote:
>
>> 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.
>>
>
> Thanks for sharing the links to these court cases, they are interesting
>
> Centralized premines or token offerenings have a couple of consequences:
>
> The first is, that it acts as a centralized tax on anyone that uses that
> protocol/chain, it becomes proprietary (as in the property of) a group of
> insiders, who own a certain % of the tokens, held and sold for profit
>
> The second is, that it becomes a security in the eyes of the financial
> system (eg using the Howey Test).  And if not registered (which could apply
> to some in the did method registry) could be illegal, to trade or use
>
> It seems clear that the did method registry is selective on what should go
> in, and what should not, since there is already stating the criteria.
>
> As an editor of that registry, what's the view on accepting chains that
> are, in fact, centralized and unregistered securities?
>
>>
>>
>> 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>
>>
>

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

<https://www.transmute.industries>