Standardize three "truly decentralized" DID Methods

[msporny]

This issue has been raised for discussion by the DID WG based on feedback in Google's Formal Objection to DID Core 1.0 (this is neither my or my organization's position -- I'm just the messenger):

https://lists.w3.org/Archives/Public/public-did-wg/2021Oct/0022.html

Google and Mozilla would like us to standardize three "truly decentralized" DID Methods to demonstrate practical interoperability. Google has asserted that did:web and did:key are not decentralized enough. The chartering question is then, if not those two methods, then what DID Method is capable of meeting the combination of requirements that Apple, Google, and Mozilla proposed, which are:

1. Must be "truly decentralized". Certificate Transparency was suggested as in the realm of possibility.
2. Must not be environmentally unsustainable, where proof-of-work consensus is regarded as environmentally unsustainable.
3. Must not be did:key or did:web, and presumably any DID Method that has qualities similar to those DID Methods as Google listed those as "not decentralized enough".
4. Must meet all criteria listed in DID Core: Method Requirements
5. Must contain a sustainability cost/benefit analysis in the DID Method specification.
6. Must specify (either directly or by reference to an external specification with the same level of expert review and process consensus) the consensus and gossip algorithm and demonstrate independent implementations of network software using a W3C test suite.

Should a future DID WG Charter standardize "more decentralized" methods? If so, which DID Methods would meet the requirements above?

[pchampin]

Could it be argued that, if more than one "not truly decentralized" methods were standardized, the overall DID landscape would be decentralized enough, as people would still have the choice of which kind of DID they use?

[msporny]

Could it be argued that, if more than one "not truly decentralized" methods were standardized, the overall DID landscape would be decentralized enough, as people would still have the choice of which kind of DID they use?

Yes, that's exactly right and is one of the conclusions the DID WG kept coming back to over the years this has been discussed in the community. It mostly boils down to choice and whether or not individuals and organizations have choice to pick a DID Method that works for them (this is why the DID Rubric exists, to help people weigh their options). So, being able to pick among a variety of "not truly decentralized" DID Methods that vary in the types of decentralization/centralization choices they make is better than picking a handful of "truly decentralized methods" for the general population. It's the same free market argument we apply to choice in browsers, or identity providers, or document editing software -- which started out with a wide range of choice and have consolidated over the years based on fair (and sometimes unfair) competition.

I put "truly decentralized" in quotes above because, as the group has experienced over the years, there are many aspects to decentralization (political, technical, operational, etc.) that need to be considered and the "right" choice tends to be use case specific.

What's being asked for is to take some of these DID Methods through the standardization process so people can see what an expert reviewed spec and method looks like. The challenge is that one of the "most decentralized" methods that the DID WG has identified (did:key) has been rejected by at least one of the objectors as being "not good enough because you can't do key rotation", which just goes to show you that people come to different conclusions based on the use cases they have in mind. did:key is vital for some deployments in IoT, privacy-preserving interactions, and other static or ephemeral use cases... so while some people believe it's an excellent candidate for standardization, other's don't.

[talltree]

I want to double down on Manu's answer. Among the DID community (and by that I mean not just the W3C DID WG members, but the larger global community building decentralized infrastructure and applications), a core principle of decentralization is "innovation at the edges". What will function the most effectively as a decentralized solution is still evolving and innovations like blockchain are only one piece of a larger landscape of approaches to decentralized technology. So enabling the market to complete on those innovations and yet enabling a layer of interoperability across all of them has been the whole purpose of the DID 1.0 spec — and the reason that we accepted the limitation in the original DID WG charter that we not standardize any DID methods.

That's why focusing on "standardizing a small number of DID methods" is pushing in the wrong direction. As Pierre-Antoine argues, multiple DID methods with different characteristics = greater decentralization any way you look at it.

On Fri, Oct 22, 2021 at 5:58 AM Manu Sporny @.***> wrote:

Could it be argued that, if more than one "not truly decentralized" methods were standardized, the overall DID landscape would be decentralized enough, as people would still have the choice of which kind of DID they use?

Yes, that's exactly right and is one of the conclusions the DID WG kept coming back to over the years this has been discussed in the community. It mostly boils down to choice and whether or not individuals and organizations have choice to pick a DID Method that works for them (this is why the DID Rubric exists, to help people weigh their options). So, (to take the argument to the extreme) being able to pick among a variety of DID Methods that vary in the types of decentralization/centralization choices they make is better than forcing a handful of "truly decentralized methods" on the general population. It's the same free market argument we apply to choice in browsers, or identity providers, or document editing software -- which started out with a wide range of choice and have consolidated over the years based on fair (and sometimes unfair) competition.

I put "truly decentralized" in quotes above because, as the group has experienced over the years, there are many aspects to decentralization (political, technical, operational, etc.) that need to be considered and the "right" choice tends to be use case specific.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/did-wg-charter/issues/14#issuecomment-949607880, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZOITMFVAHQ4DP6H2DPHBLUIFNYPANCNFSM5GPERMQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mprorock]

enabling the market to complete on those innovations and yet enabling a layer of interoperability across all of them has been the whole purpose of the DID 1.0 spec — and the reason that we accepted the limitation in the original DID WG charter that we not standardize any DID methods. That's why focusing on "standardizing a small number of DID methods" is pushing in the wrong direction.

big +1 to this. We really should be facilitating interop not picking winners here, especially if we are truly interested in decentralization, otherwise if we go down standardizing specific implementations we are by design bringing things back to centralized approaches.

There are some exceptions that arguments could be made for in this regard, did:key being one as it is somewhat of a de facto for interop testing, use independent of any required ledger, etc, and did:web being the other as it can act as a bridge between existing more centralized infrastructures and decentralized tech, and as such is a core component for integration with existing trusted parties, etc.

Beyond those two methods, I have strong reservations on building any other DID methods into this standard body at w3c. Data model conformance testing, ability to evaluate and select a method based on criteria, guidance on did method implementation, these seem natural for w3c, but going after implementation details seems a bit out of band, in addition to being possibly viewed as promotion of one particular tech or another, which we should not be doing.

[ChristopherA]

I’m curious what people think.

I consider did:onion to be a decentralized version of did:web. It lacks only key rotation to be a full DID method, but also adds an integral property of proof of key possession (you can’t reach the website unless it as the private key).

Could it meet the needs of one of these “truly decentralized” DID methods while leveraging the experience from did:web?

[jyasskin]

Note that standardizing a few (or lots of) DID methods still allows different winners to appear, and for the standardized methods to lose. If you look at the example of URLs, of the 10 schemes standardized by RFC 1738, only 3 (http:, mailto:, and file:) are still in widespread use, and I believe https: has eclipsed all of them. Nothing in the future will require all standardized DID methods to go through W3C standardization, any more than all URL schemes are IETF specifications.

Standardizing some schemes accomplishes two things:

1. It gives organizations trying to adopt DIDs the ability to pick ones that have demonstrated interoperable implementations. As @mprorock said, to have verifiable-credential implementations interoperate, the VCs have to use a DID method that all of the implementations understand. Without those commonly-implemented DID methods, the VCs aren't interoperable either, even if all the DIDs share a common data model.
2. It shows that the complexity involved in having an abstract DID-method interface is needed and beneficial, to the standards of the W3C community.

---

I've also seen arguments that standardizing some DID methods would increase the centralization of the system, and that doing so would be bad. Presumably standardizing the DID data model also increases centralization in the same way? Why was that desirable if coordinating on some common DID methods isn't?

[rxgrant]

@jyasskin

As @mprorock said, to have verifiable-credential implementations interoperate, the VCs have to use a DID method that all of the implementations understand. Without those commonly-implemented DID methods, the VCs aren't interoperable either, even if all the DIDs share a common data model.

There is more of a spectrum of trust models open to implementations than your statement leaves obvious room for. It's unclear whether you're aware that implementations can, for DID resolution, mix native DID Method libraries and DID Document retrieval from a chosen resolver. Any implementation that understands the common data model (including the signature suite) can verify a credential once it has a trusted DID Document. This means that implementations can express to the user a variety of trust levels:

• this implementation stores data from this VDR and has retrieved the DID Document according to its own understanding of the DID Method specification, and the DID Document parses correctly according to the data model, and the verifiable credential verifies correctly;
• this implementation stores data from this VDR and has retrieved the DID Document according to an industry-standard library, and the DID Document parses correctly according to the data model, and the verifiable credential verifies correctly;
• this implementation sends data retrievel requests to the VDR's native node-network, and has retrieved the DID Document according to an industry standard library, and the DID Document parses correctly according to the data model, and the verifiable credential verifies correctly;
• this implementation sends a request for a DID Document to a trusted many-did-method DID resolver, and the DID Document parses correctly according to the data model, and the verifiable credential verifies correctly; and
• a trusted web service will answer queries about the DID Document and the Verifiable Credential.

When you apply the spectrum of options, using more transparent verification libraries for more respected DID Methods, and allowing other DID Method verifications to get proxied off to a resolver to return the DID Document, then you can see that the decentralization allows market-based feedback on what is important, and the data model allows an architectural minimization of trust. Proxying allows an implementation to answer questions about other DID Methods, though with that third-party involvement caveat.

I've also seen arguments that standardizing some DID methods would increase the centralization of the system, and that doing so would be bad. Presumably standardizing the DID data model also increases centralization in the same way? Why was that desirable if coordinating on some common DID methods isn't?

VDRs are competing on how they answer the question about what the current active DID Document is. The standard focuses innovation and freedom in that area, based on years of developement and what the working group's implementors were willing to agree on. It's a type error to mix standardization when there is voluntary consensus with centralization of outcomes. The architectural choices listed above help trust minimization and gradual implementation as DID Methods mature in the marketplace.

[dlongley]

@jyasskin,

It shows that the complexity involved in having an abstract DID-method interface is needed and beneficial, to the standards of the W3C community.

I think there's an element of this that some people who haven't been in the WG may have been missing.

The main point of DID core is to enable applications that consume DIDs and DID documents to switch out DID methods and resolvers without having to make significant code changes (in some cases, none at all). One can think of this like creating a Web site -- the same bundle of JS/HTML/CSS should work the same in any browser (with some caveats).

This means getting interoperability around DIDs and DID documents (the identifier format and the data model) as well as laying down some requirements for what DID methods must provide in order to guarantee this is possible, such as some basic interfaces / contracts for resolving DIDs. These interfaces / contracts are already useful today (and a number of other people have pointed to evidence of this).

This approach enables there to be competition amongst DID methods -- with an eye toward allowing more decentralized DID methods to rise on their own merits. "More decentralized" DID methods, to me, refers to those where control over one's own DID and DID document is maximized and changes to any associated VDR (the "Verifiable Data Registry" or "source of truth" for a DID document's history) requires the consensus of multiple parties; it is not too concentrated.

It may be helpful to standardize certain DID methods as well -- or perhaps some common aspect of some particular set of DID methods. I would expect that standardizing something like the "sidetree protocol" (a protocol used by a number of DID methods) could make sense. But, in other cases, this is like saying we should standardize Safari or Chrome or a particular Web application or component.

Another way of putting it is: Should we have standardized some commonly reimplemented map or online ordering/delivery Web app before we standardized the geolocation API? Should we have held up standardizing video / audio tags and APIs until we standardized specific video / audio players? W3C did not. The alternative approach is to take what appears to be common in the ecosystem and standardize those parts. The members in the DID WG are very familiar with the DID ecosystem -- and, as experts in the area, they believe that's what has been done with DID core. Mistakes are always possible, but there's a process for dealing with them in the future (and I understand that it's not "free", but at some point you have to ship). This approach seems to be analogous to me to what happens with browser vendors and many browser APIs.

So, IMO, the DID core spec should not be held up for discussions around potentially standardizing DID methods (and the subsequently required standards work). DID core is useful today to many people who have already created applications that consume DIDs and to DID method creators that may never seek for their methods to be standardized. Indeed, some DID methods may not be able to achieve the required consensus to be standardized. All of this is to say that the core work is already useful whether or not we can find N many DID methods upon which there is consensus to standardize.

[pchampin]

@dlongley

The main point of DID core is to enable applications that consume DIDs and DID documents to switch out DID methods and resolvers without having to make significant code changes (in some cases, none at all).

As someone who has not been involved in the group's work, I can confirm that I mostly missed that point. :confused:. That makes DID methods quite different from URI schemes, in my opinion, and therefore the parallel made in Section 8 of DID-CORE can be misleading. I am not implying that this parallel is not useful, but its limitations should be emphasized a little more...

[jyasskin]

I think the WG and I are using the term "decentralization" differently... Take an arbitrary DID URI being used in a Verifiable Credential, say did:arglebargle:whatever. How centralized is the meaning of that DID URI? We have 3-ish possibilities:

1. There's a web service that resolves did:arglebargle: URIs to documents. This is very centralized. That server could choose to return the wrong document arbitrarily.
2. There's a library available to resolve did:arglebargle: URIs to documents locally. This is less centralized, but there's still 1 group of developers who could make mistakes or embed backdoors into their resolver.
3. There's a standard definition of did:arglebargle: URIs and a test suite to help several groups of developers create independent implementations. This is even less centralized, since you have to compromise a consensus-based standards process to inject bugs into the test suite and specification that could make a URI resolve to an unintended document. It's still possible — see Dual_EC_DRBG — but harder than the first two.

Two DID Methods at the same level of standardization can also differ in how decentralized they are along other axes, and the WG is correctly interested in encouraging the invention of new Methods that improve along those other axes, but I don't think that means it's good to keep the existing ones at the more-centralized levels of standardization.

@rxgrant waved in this direction by talking about "more respected DID Methods". That's the group that Google's formal objection suggested standardizing. The market would remain free to pick non-standardized methods if their benefits along other axes outweighed their centralization along the standardization axis.

[rxgrant]

@rxgrant waved in this direction by talking about "more respected DID Methods". That's the group that Google's formal objection suggested standardizing. The market would remain free to pick non-standardized methods if their benefits along other axes outweighed their centralization along the standardization axis.

I'd like to see as informed a marketplace as possible, for the ease of implementors deciding what to implement and end users picking trustworthy tools. Some user choices of DID Method are going to seem unnecessary when looking in from the outside, but will have at their heart intricate reasons like tool experimentation or custody features.

We've done a lot of work to define criteria in the Rubric that will resonate with different people. One of those criteria (whether it's listed yet or not) will be widespead support (with support helped along by its cousin: widespread use of trusted models like external resolvers). One of the consequences of not picking winners in the spec is that clarity may take time.

I think the decentralization needs of the users outweigh the clarity needs of implementors, in this case.

[jyasskin]

Standardization can also help with patent claims, which seem to be missing from the Rubric (https://github.com/w3c/did-rubric/issues/65).

[peacekeeper]

did:web is always a great example. This method is based on domain names, which in the classic sense and by most definitions is not "decentralized" (see https://en.wikipedia.org/wiki/Zooko's_triangle). One of the main reasons why work on DIDs started was that identifiers were needed that are NOT dependent on central authorities like domain names are.

BUT: did:web shares its syntax, data model, and resolution interface with all other compliant DID methods, and that's why people in this community often prefer to use did:web over https:// nowadays.

As others have said, this makes it possible to build applications and services that work with many different types of identifiers, and to easily switch out identifier and resolution systems. It has been argued that this aspect by itself is also a form of decentralization.

[brentzundel]

Beginning standardization of DID Methods was added to the charter in #20