Re: DID Formal Objection Status Update (Dec 2021)

There is a bit of an multi-organization-specific complication here:
- how are ABC Grocery's purchase orders (identified by a simple integer PO number) to be differentiated from David's Cabbages purchase orders (also identified by a simple integer PO order number from a potentially overlapping range of PO numbers)?

In the real world, we need to work with overlapping sets of basic identifiers that are only unique within a specific realm, for example...
- purchase order and invoice numbers from multiple organizations,
- waybill numbers may already have an industry solution,
- part numbers from different manufacturers,
- objects and collections of objects identified by a GraphQL or OData query sourced from different realms or collection of realms based on the same underlying query string
- in-house enterprise application developers, DBAs, and data modelers creating object name spaces for every object in their enterprise architecture ... similar/same challenges Implementors currently have selecting name spaces for their C#, Java, etc. application components.
- etc. etc. etc.

Apologies if I've ruined your "morning"... 😉🙂,
Michael Herman

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Friday, December 17, 2021 5:22:55 AM
To: Dimitri Zagidulin <dzagidulin@gmail.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
Subject: Re: DID Formal Objection Status Update (Dec 2021)



On Thu, 16 Dec 2021 at 17:03, Dmitri Zagidulin <dzagidulin@gmail.com<mailto: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<mailto: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<mailto:melvincarvalho@gmail.com>>
Cc: Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>; W3C Credentials CG <public-credentials@w3.org<mailto: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



[https://mailfoogae.appspot.com/t?sender=ab3JpZUB0cmFuc211dGUuaW5kdXN0cmllcw%3D%3D&type=zerocontent&guid=c3d970fe-a049-4add-b282-374b315e840f]ᐧ

On Thu, Dec 16, 2021 at 3:10 AM Melvin Carvalho <melvincarvalho@gmail.com<mailto: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

[https://mailfoogae.appspot.com/t?sender=ab3JpZUB0cmFuc211dGUuaW5kdXN0cmllcw%3D%3D&type=zerocontent&guid=1bd8f5bf-4ae6-4170-9a9d-772ef9ae96f9]ᐧ

On Wed, Dec 15, 2021 at 3:41 AM Melvin Carvalho <melvincarvalho@gmail.com<mailto: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

[https://mailfoogae.appspot.com/t?sender=ab3JpZUB0cmFuc211dGUuaW5kdXN0cmllcw%3D%3D&type=zerocontent&guid=e2f9ca16-afad-4362-bdb8-9cd279b26ed4]ᐧ

On Tue, Dec 14, 2021 at 2:06 AM Melvin Carvalho <melvincarvalho@gmail.com<mailto: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
[https://mailfoogae.appspot.com/t?sender=ab3JpZUB0cmFuc211dGUuaW5kdXN0cmllcw%3D%3D&type=zerocontent&guid=45803f89-e26a-4883-bf96-0e68b43bc550]ᐧ

On Fri, Dec 10, 2021 at 3:52 PM Melvin Carvalho <melvincarvalho@gmail.com<mailto:melvincarvalho@gmail.com>> wrote:


On Sat, 4 Dec 2021 at 17:42, Manu Sporny <msporny@digitalbazaar.com<mailto: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://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries>


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

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries>


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

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries>


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

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries>