Response to 'Call for Review: Decentralized Identifiers (DIDs) v1.0'

From https://www.w3.org/TR/did-core/#design-goals

    Decentralization | Eliminate the requirement for centralized authorities or single point failure in identifier management, including the registration of globally unique identifiers, public verification keys, services, and other information.
    Control | Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities.
    Privacy | Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data.
    Security | Enable sufficient security for requesting parties to depend on DID documents for their required level of assurance.
    Proof-based | Enable DID controllers to provide cryptographic proof when interacting with other entities.
    Discoverability | Make it possible for entities to discover DIDs for other entities, to learn more about or interact with those entities.
    Interoperability | Use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability.
    Portability | Be system- and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID methods.
    Simplicity | Favor a reduced set of simple features to make the technology easier to understand, implement, and deploy.
    Extensibility | Where possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity. 

In short, if the large platforms like Facebook, Google, Apple, Microsoft et al started using DIDs, we could start using logins across platforms instead of creating new accounts for each one.

Basically, the specification is trying to come up with a way of offering federated authentication ala OpenID, but without locking down the storage mechanism of the ID itself.

The user problem- for those who see it that way- is that right now, digital stuff related to a person, is tied up primarily with the person's email address, or in some cases with the person's phone number.

(For the purposes of this discussion, call the email address or phone number an "identifier".)

Why is this a problem? Two reasons:

1. People don't "control" those identifiers

Many email addresses used in this context are controlled by employers, and the person's right to use them ends when they leave employment. Or they are controlled through expensive commercial arrangement between the person and the platform, and the person may lose access if they are no longer able to afford the platform. Or, they are free, offered by large data harvesting/advertising platforms, who mine data stored on the platform, and as below, linked to those identifiers from other platforms, to create advertising and propaganda targeting profiles.

2. Those identifiers are used by others to contact the person, and are therefore long-lived, which means they are also a vehicle for correlating an individual's activity across internet platforms who are necessarily presented with those identifiers by the person when they engage with the platform.

DIDs are an attempt to have identifiers that are controlled by people that:

  * are inexpensive
  * can be short-lived and "rotated"
  * can be specific to the relationship between a person and a particular platform
  * can support more tailored association of personal data to identifier
  * can better support the person's management and correlation of their platform relationships, while minimizing if desired that the correlation of identifiers back to a person by the platforms themselves
  * and support other use cases

In terms of "decentralization" and "publishing"- there is definitely a need to publish identifiers in some cases. People want to find others, and want to be found. Whether that publishing constitutes centralization is nuanced.

But the key issue is that right now it is hard to impossible for a normal person to engage with a small or large platform that does not involve a widely used identifier.

[EDIT: whether normal users consider this to be a problem is an open question, and as is whether they would if a solution existed to the problem...]

I didn't say 50%.

Simply, there is some level at which an attacker has enough computational power to pull off an attack, and such an attack is fought off by the legitimate participants in the network having enough computational power to make the attack unfeasible. Whether that's 50%, or even lower as the section you linked to suggests ("someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate"), or higher as you claim, that point exists.

The service of securing the network, as you put it, consists solely in having enough non-malicious computational power to make attacks unfeasible. Right? Or is it something else?

If it does, then my argument stands. In order to be secure, Bitcoin needs the legitimate participants of the network to out-compute the illegitimate ones. Whether that's a one-to-one race, or a ten-to-one, or anything else, doesn't matter. The euphemism "securing the network" means nothing other than amassing computational power.

If it is really true that attacks from attackers having lots of computational power are infeasible, and that it's not necessary for the network to have lots of computational power in order to "secure the network," then, quite simply, proof-of-work Nakamoto-style mining isn't necessary at all. You can do something like Stellar or (as I understand it, which I admit is not well) Lightning where transactions are confirmed and protected against double-spend by defining the problem in a different way that doesn't require mining. If that approach indeed works, then the objection in TFA stands - the spec should not encourage proof-of-work systems.

Frankly, given that we're talking about decentralized identity and not about currency, and there's no double-spend equivalent in proving one's identity (I think?), it seems like Nakamoto consensus should be totally irrelevant here. Maybe inflationless, politically-neutral money is a great thing to have as a form of money, but what makes it a great form of decentralized identity?

Google stands to lose a lot if DIDs take off. They'll stop at nothing.

This response is full of mostly terrible, uninformed takes.

> No practical interoperability. As Microsoft & Google expressed, the DID “Core” spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ “methods”, none of which themselves have interoperable implementations.

While there are 50+ DID methods, they're all trivially made accessible via a uniform API [1]. DID method specs and implementations are service-specific drivers, which are meant to plug into a generic resolver and registrar service endpoint which anyone can run.

The point of the DID W3C spec is to provide a standard for creating individual DID methods. It is not, and was never about, creating a uniform API for using them.

> Encourages divergence rather than convergence. The DID architectural approach appears to encourage divergence rather than convergence & interoperability.

Again, the author misses the point. DID methods are service-specific drivers; providing a uniform API is the responsibility of the layer above them. The "divergence rather than convergence" dichotomy here is absurd -- it's like saying that the proliferation of link-layer protocols encourages divergence rather than convergence in networking protocols, while completely ignoring that IP exists and is meant to provide a uniform narrow-waist protocol for using them. Obviously, link-layer protocols don't implement IP, nor are they expected to. Similarly, DID methods are not expected to implement the higher-level universal resolver and registrar protocols.

> Centralized methods allowed, in contradiction to WG & spec goals & name.

This I think is the only fair point in this email. Why the fuck is did:ccp considered a good-faith DID method?! It's a DID method for Baidu Cloud.

> Proof-of-work methods (e.g. blockchains) are harmful for sustainability (s12y). Also as noted by Google, the registry contains methods which rely upon proof-of-work which is wasteful. “Successful” proof-of-work systems waste a staggering amount of electricity world-wide (e.g. Bitcoin consumes more energy than most countries.

The amount of electricity PoW blockchains spend is orthogonal to the worthiness of the DID spec. That PoW spends a "staggering amount" of electricity is not a consequence of PoW blockchains' designs; it's a consequence of the governments of the world permitting it to happen. The absolute energy use is not an intrinsic requirement for these systems -- PoW blockchains would work just the same if the world's budget for mining was only 1 KW.

I expected better from the W3C.

(Disclaimer: I am the author of one of the DID method specs).

[1] https://github.com/decentralized-identity/universal-resolver