Because: if it's truly decentralized then there's no need to publish it. But publication is a core aspect of DID. That it must be published is a jedi mind trick that allows in "on a blockchain". Now we see the real problem being solved (not a user problem): need something published on a blockchain.
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.
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.
Not a chance really.
First, DIDs define a method behind resolving data be it use a website, use bitcoin classic, etc. There are over 100 defined, and only "web" and "key" (inlined data in the URI) have achieved interoperability.
Second, if DIDs define authentication then your Apple/Facebook/Google account will require to own the DID so that they can make sure the authentication requirements aren't rewritten to be too weak to qualify.
Third, DIDs used in that way are less privacy preserving than the existing system, since it is now a global identifier shared with everyone.
(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
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...]
Therefore MSFT now needs an open-ish standard so that it's not dead in the water.
Funny how times have changed.
A blockchain isn't strictly necessary. You could build a DID method for your PGP key that relies on the world's set of keyservers to resolve your DID's state, for example. You could similarly have DID methods that resolve your public key via Keybase, via DNSSEC, via certificate authorities, and so on. As long as the underlying system is decentralized -- i.e. it spans multiple peer administrative domains -- it doesn't matter whether or not it's a blockchain.
How do you come to that conclusion?
DIDs built as a Sidetree on top of Bitcoin. At least they don’t require everything being on-chain, but securing with proof-of-work is unfortunate.
When you have a distributed system, it really isn’t hard to “retain” information in a byzantine fault tolerant way. Proof of Work is mostly used to help with liveness, not persistence.
PGP signatures + Web of Trust have been in use for about two decades now and have proved robust over time (can't say the same of all PGP implementations unfortunately), but at the cost of revealing (parts of) the social graph which is an anti-feature for privacy.
I've heard the word Fog of Trust employed by GNU/Net project to refer to research projects on zero-knowledge proofs for a Web of Trust, so you can infer trust relationships without exposing the social graph. But i can't vet for the math behind that.
I'd be happy to have more alternative patterns explored, instead of insisting on the aspects that made Bitcoin a failure. Bitcoin was a revolutionary PoC for replacing centralized trust with trust in the majority of global computing resources allocated to the network. But that model has shown its limits and weaknesses (high economic/environmental cost, vulnerability to advanced actors like Bitmain, low transaction throughput) so we can research other approaches.
So far, the most advanced/consistent proposal i've read on decentralized identity, which is not based on monetary speculation or proof-of-work, is the GNU Name System [0], which features recursive resolution of zones (retro-compatible with DNS) via a global DHT, crypto-secure zone delegation (retrofittable into existing ICANN infrastructure), hyper-hyper local root (like /etc/hosts but with recursive resolution), query privacy (client requests don't leak), enumeration-proof zones (private zone entries).
Alongside the reclaim:ID [1] self-sovereign identity scheme, that looks like the most solid proposal for replacing both insecure DNS infrastructure and cracking the decentralized identity problem. Alongside the Taler [2] privacy-friendly payment platform, that looks like the most solid proposal for enabling fully-decentralized pseudonymous electronic transactions.
See also this somewhat recent article on the topic: https://gnunet.org/en/news/2021-05-DISSENS.html
[0] Some video presentations: https://gnunet.org/en/video.html
Somehow feels like the trinity of responsible software ("responsible" probably isn't the right word here).
I agree with you, I just don't think your stance is radical enough :D
> We (W3C) can no longer take a wait-and-see or neutral position on technologies with egregious energy use. We must instead firmly oppose such proof-of-work technologies including to the best of our ability blocking them from being incorporated or enabled (even optionally) by any specifications we develop. If anything we should pursue the opposite: develop specifications that supersede existing specifications, but with much less power consumption. We believe this is consistent with the TAG Ethical Web Sustainability principle
At any rate, I've become fairly convinced at this point that something like ENS (https://ens.domains/) is better suited for a decentralized identity. Optionally registering a simple domain name via a smart contract and signing in to services with a public-private key pair (such as an Ethereum address) is a far superior experience to anything I've seen as far as simplicity goes. I don't need to give up personal contact info. I have ownership of my address. I can create new addresses if I need. I can augment my ENS-linked domain with social media info or website info and that is all stored on-chain. However, one-click sign in doesn't require hitting the chain, just requires signing a message. It's pretty elegant. I just think it needs more standardization.
I'm not sure why years of time matters. Rapid growth is extremely common in technology.
How much time did you need to spend convincing yourself that a microblogging website that didn't exist 12 years before 2016 and was constantly crashing 7 years before 2016 had become a major influence on world politics, up to the level of the US presidency? Hopefully not more than a few seconds.
How much time would it take to convince you that one BTC, which did not exist 12 years ago and was worth $300 7 years ago, hit more than 200 times that amount this year? Does it seem impossible?
The ecological argument against Bitcoin-style consensus is short and fairly obvious from Satoshi's paper. The innovation in that paper (compared to existing techniques like Merkle trees) was the ability to stop double-spend attacks by "mining" chains of transactions. This requires making sure that no single participant - not even the financially-meddling central banks that Bitcoin is supposed to provide an alternative too, and the might of their governments - can mine at a rate higher than the network. This immediately produces an incentive for both the network to make use of as much computational capacity as possible to keep itself safe, and for any attacker to amass enough computational capacity to mount an attack.
The incentive goes up as the block reward goes up, which it has been doing in terms of real value (e.g., number of Big Macs you can buy with a reward), even though the reward denominated in BTC goes down over time.
Therefore, Bitcoin-style consensus, if it works, is necessarily a major consumer of worldwide computational power, and as long as computers require energy, it is a major consumer of worldwide energy, which isn't really a thing we have an excess of.
That's the entire argument. It doesn't take you very much time - unless, of course, you're incentivized to keep trying to find counterarguments.
There really are no arguments for a race-to-the-bottom boundless energy spenditure. The equilibrium point is the market's appreciation of the service of securing a network of inflationless, politically neutral money, which is a pretty cool thing to have in our world of tyrannic governments.
[1]: https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_...
Ceramic[0] (a sort of mutability layer on top of IPFS) solves this off-chain by using your crypto wallet to authenticate a DID (their DIDs are known as 3id[1]) which can have a list of socials and crypto wallets associated with them (using their IDX[2] system and the schemas called alsoKnownAs[3] and cryptoAccounts[4], respectively), and the validations are made possible by systems called IdentityLink[5] (verifies similar to Keybase) and Caip10Link[6] (sign a message with your wallet) (respectively). The Caip10Link also allows reverse lookup of a DID from a blockchain address. A reference implementation of these systems in action can be found at https://self.id/ .
Grain of salt: I'm working on a project that makes heavy use of Ceramic.
[0] https://developers.ceramic.network/learn/advanced/overview/ [1] https://github.com/ceramicstudio/js-3id-did-provider [2] https://developers.idx.xyz/learn/overview/ [3] https://github.com/ceramicstudio/datamodels/tree/main/packag... [4] https://github.com/ceramicstudio/datamodels/tree/main/packag... [5] https://developers.ceramic.network/tools/identitylink/overvi... [6] https://developers.ceramic.network/streamtypes/caip-10-link/...
There should be standardized education in this field if standards communities themselves can be so reactionary, equally missing that decentralized identifiers have nothing to do with blockchain, and even if they did that they have nothing to do with POW.
If you deploy a development environment where certain functions can run, it doesn't matter if the underlying hardware is using 1% of global emissions, or a couple households worth. This post is acknowledging that the "nearly none at all solutions exist" and are good enough for some purposes, while also acknowledging that it is weird that a standards committee did not acknowledge them but reacted to the global emissions one.
If this were a Google conspiracy using Mozilla sock puppets, why would they bring that up as an objection, and ask to move the spec back to the discussion phase explicitly forbidding such mechanisms? It would be extremely straightforward for Çelik's handler at Google to ask him to remove that paragraph before publishing it.
(There are more centralized identity mechanisms there, including a proposal to use Microsoft GitHub. That spec doesn't even have the veneer of distributed ledger that Baidu's one does, and it was added by Transmute, one of the authors of the DID spec. How do we know Transmute isn't a Microsoft sock puppet, helping them "embrace, extend, and extinguish" this spec? It seems like Çelik's concerns are all reasonable and it would be entirely possible to make a DID spec that satisfied all of them - is the reason that we ended up with this DID spec that Microsoft and Google are deliberately producing a bad version?)
Browsing the last 6 months of public-new-work archives doesn't seem to yield many other reviews of the DID proposal.
At least the abstract of the spec reads like that to me:
Abstract
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized
digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract
entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers,
DIDs have been designed so that they may be decoupled from centralized registries, identity
providers, and certificate authorities. Specifically, while other parties might be used to help enable
the discovery of information related to a DID, the design enables the controller of a DID to prove
control over it without requiring permission from any other party. DIDs are URIs that associate a
DID subject with a DID document allowing trustable interactions associated with that subject.
Each DID document can express cryptographic material, verification methods, or services, which
provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable
trusted interactions associated with the DID subject. A DID might provide the means to return the
DID subject itself, if the DID subject is an information resource such as a data model.
This document specifies the DID syntax, a common data model, core properties, serialized
representations, DID operations, and an explanation of the process of resolving DIDs to the
resources that they represent.
¹ https://www.namecoin.org/ ² https://docs.ipfs.io/concepts/ipns/
The hilarious part is that these supposedly "decentralized" ID systems pull data from the most centralized entity: government's civil register.
The attack on DIDs is the same pattern of attack on Extensible Resource Identifiers (XRIs), one of the standardization attempts along the path to DIDs. Politics and soundbytes popular at the time are used to garner a boost in public opinion, or to defeat something that may threaten the status quo, or to just defeat the efforts of someone disliked by a group (some of the same people in DIDs were in the XRI effort).
DIDs may not be the best technology to solve decentralized identity, but it is the best technology we have right now. ENS is great, but completely tied into Ethereum.
I am horribly disappointed in Mozilla in general, and Tantek in particular. For me this is the last signpost on Mozilla's road from being a bastion for Open Source to being a JACM (Just Another Corporate Monolith).
Why the big-name detractors coming out the woodwork now for the review did not take part in the DID standardization effort is unclear to me. They could have influenced its growth and helped it mature into something they could live with - proper pre-natal care for standards and by those involved with Standard Development Orgs.
Instead they have sent corporate hatchetmen to abort DIDs stillborn at birth.
Feels good to be validated by someone like Tantek.
> 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