Re: DID Formal Objection Status Update (Dec 2021)

On Thu, 16 Dec 2021 at 17:03, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:

> > to encourage the creation of hundred and thousands of DID name spaces
> ...if you buy into the concept of DID name spaces representing a name space
> scheme for Every Little Thing on the planet.
>
> Michael, that is explicitly not what DID name spaces are for.
> DID methods are a combination of protocol and (profile of) data model.
> They are not domain names.
>
> Do you want your browser to have to support hundreds and thousands of
> different formats for images?
> Do you, as a developer, want to have to maintain and test a DID resolver
> library with hundreds and thousands of different DID method drivers?
>

I think that's right, did methods are (sub) protocols, domain names are a
different layer

If you think about it, it makes sense.  Because the W3C is a vendor neutral
consortium

So the methods should not be tied to any one company.  But any company can
use a method


>
> On Thu, Dec 16, 2021 at 10:53 AM Michael Herman (Trusted Digital Web) <
> mwherman@parallelspace.net> wrote:
>
>> Per my earlier comments, I believe the DID Method Registry shouldn't be
>> managed any differently than a DNS Registry (except for the time being the
>> former should remain free) ... to encourage the creation of hundred and
>> thousands of DID name spaces ...if you buy into the concept of DID name
>> spaces representing a name space scheme for Every Little Thing on the
>> planet.
>>
>> A use case: Musician Use Case @ time code 4:15 into
>> https://youtu.be/J6n9TvxA93I?t=255
>>
>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>> ------------------------------
>> *From:* Orie Steele <orie@transmute.industries>
>> *Sent:* Thursday, December 16, 2021 7:28:20 AM
>> *To:* Melvin Carvalho <melvincarvalho@gmail.com>
>> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG <
>> public-credentials@w3.org>
>> *Subject:* 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>
>>
>