Re: DID Formal Objection Status Update (Dec 2021)

> But I think the registry would benefit from some cleaning up and curation

I strongly agree with cleaning up (PRs are welcome), but disagree with
curation... and so do many other WG members (which is why it is the way it
is)... The registry is not currently, and I hope for it to never be, a
"curated list of DID Methods meeting the approval of some council"... I
think such lists are very valuable, but we should not mix the purpose of
registering names to avoid name conflicts with providing financial, ethical
or social advice... especially if it might look like the W3C is endorsing
specific methods that might not align with EWP.... Some folks will
argue strongly for endorsing BTC based DID Methods, others will argue for
endorsing some alternative that is "more sustainable"... these arguments
should be had in a place that is more appropriate, and were the care and
time to cultivate the arguments can happen.. the registry is for
interoperability and naming conflicts... It's not the right place to try
and embed a subjective application of EWP as a score or rank or curation of
the registered methods... but if the WG decided I was wrong about this, I
would happily step aside so that a more opinionated curator-editor could do
a better job.

There is also https://www.w3.org/TR/did-rubric/

Which I am not an editor of, but which has the much harder challenge of
assisting in the evaluation of "registered" or "unregistered" DID Methods.

The rubric is a much more natural place to discuss the Howey Test, IMO,
especially since it's not relevant to all verifiable data registries, but
really relevant to some of them.

I don't think "centralization" or "decentralization" have clear boundaries,
and I don't think the registry needs to take a stance on this topic...

I do think the rubric, or other (external to the W3C) ways of labeling,
ranking, judging, evaluating are the right way to handle this... and it
seems to be the direction the WG is headed.

OS



ᐧ

On Thu, Dec 16, 2021 at 3:10 AM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On Wed, 15 Dec 2021 at 21:09, Orie Steele <orie@transmute.industries>
> wrote:
>
>> 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.
>>
>
> Thanks for raising lots of good points.  You are darting about a bit.
> I'll try and respond to the substance of your thread
>
> It was Joseph Campbell that said, "The only difference between a religion,
> and a neurosis, is that the religion is more popular".  Yes, there are some
> people that think BCH is the "real" bitcoin, and some people think the
> world is flat.  However, we know this not to be the case.  Observation
> tells us otherwise.  We have common understandings based in pragmatism.
>
> I've spent some time reading through the formal objection FAQ, including
> the linked discussions, trying the demos etc.
>
> I personally find the objections quite nebulous.  I support DID Core as a
> decent piece of work, but the registry remains slightly problematic
>
> The "first come, first served" approach sounds reasonable, in principle.
> But in practice, sometimes it works well (e.g. URI schemes) and sometimes
> it works less well (e.g. domain names)
>
> This has lead to, IMHO, is a largely centralized set of block chains in
> the registry, as it currently stands
>
> I'll note that URI schemes, to which the did registry have been likened,
> have two statuses.  The first is provisional, after that, it's accepted.
> This two step approach could be a possible way to improve the registry
>
> There's good text around avoiding racism et.  However, text around
> centralization in block chains, and abiding by securities laws, are
> lacking.  Gary Gensler has recently given a lot of guidance on this.  Not
> only is he head of the SEC, but he lectured on block chains at MIT.  His is
> the kind of pragmatic guidance, on the topic of centralization, that I
> think is useful.  He also mentions the Howey Test
>
> DID Core seems like a valuable piece of work.  But I think the registry
> would benefit from some cleaning up and curation
>
>
>>
>> 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>
>>
>

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

<https://www.transmute.industries>