Better imho to ask: what user problem is DID solving?
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.
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.
> 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.
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.
First,which DID methods will be successful is a question of time, additional your wallet app could support multiple of these DID methods.
Second, DID and the corresponding keys are supposed to be owned by the user or managed by a platform, any indivdual can make the choice whteher he wants convience of managed keys or full privacy under his own control
Third, you can have a seperate DID for every service and they issue you an login credential for that particular service.
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...]
Somebody introduces a new technology to address these concerns every couple years and it doesn't go anywhere. These aren't actually problems to a lot of users. That's the real problem that needs to be solved - awareness. And that's a lot harder than taking the identity solutions we came up with in the Identity 2.0 days and adding a blockchain.
> Somebody introduces a new technology to address these concerns every couple years and it doesn't go anywhere.
That's the problem, we need protocols and standards, then laws to enforce those, not _technology_. The DID specification is a "old" attempt at this, I remember first coming across DIDs back in 2015-2016 sometime, so DIDs are hardly new.
> we came up with in the Identity 2.0 days and adding a blockchain
Good thing no one has suggested to add any blockchains! Commentators here on HN would do themselves a service by reading the actual specification before commenting, seems to be a common misconception that DIDs has something to do with blockchains.
While of course it is just one of many (alongside e.g. “just use a public key”(or hash of one or something. I don’t know the details), and “just use a github username”, when looking at the example resolver, and trying to read the docs, my impression was that a fair proportion of the examples given were blockchain related?
So, that could be part of the reason for the misconception.
I was first introduced to it by the, bold post on the Protocol Labs (the people behind IPFS) blog, about ION as a particular type of DID (sorry, “type of” is probably not quite the right terminology, but I’m not sure what the preferred terminology is) which appears to use the Bitcoin chain (but in a way that involves only very few transactions and very little on-chain data).
Personally I found the FAQ page for DIDs to be a little,
well, it isn’t particularly focused on assisting the reader in evaluating “should I care about this”?
I guess in some ways it seemed a third of the from being a normal FAQ and being a specification, or, not a specification but a, documentation of policy and plans etc.
> Somebody introduces a new technology to address these concerns every couple years and it doesn't go anywhere. These aren't actually problems to a lot of users.
> 2. Use Cases: Online shopper, Vehicle assemblies, Confidential Customer Engagement, Accessing Master Data of Entities, Transferable Skills Credentials, Cross-platform User-driven Sharing, Pseudonymous Work, Pseudonymity within a supply chain, Digital Permanent Resident Card, Importing retro toys, Public authority identity credentials (eIDAS), Correlation-controlled Services
And then, IIUC W3C Verifiable Credentials / ld-proofs can be signed with W3C DID keys - that can also be generated or registered centrally, like hosted wallets or custody services. There are many Use Cases for Verifiable Credentials: https://www.w3.org/TR/vc-use-cases/ :
> 3. User Needs: Education, Retail, Finance, Healthcare, Professional Credentials, Legal Identity, Devices
> 4. User Tasks: Issue Claim, Assert Claim, Verify Claim, Store / Move Claim, Retrieve Claim, Revoke Claim
> 5. Focal Use Cases: Citizenship by Parentage, Expert Dive Instructor, International Travel with Minor and Upgrade
> 6. User Sequences: How a Verifiable Credential Might Be Created, How a Verifiable Credential Might Be Used
There's probably already a good way to bridge between sub-SKU GS1 schema.org/identifier on barcodes and QR codes and with DIDs. For GS1, you must register a ~namespace prefix and then you can use the rest of the available address space within the barcode or QR code IIUC.
DIDs can replace ORCIDs - which you can also just generate a new one of - for academics seeking to group their ScholarlyArticles by a better identifier than a transient university email address.
It solves the problem of Microsoft not having a mobile platform in which to lock you in. Unlike their competitors in identity: Apple iOS and Google's Android.
Therefore MSFT now needs an open-ish standard so that it's not dead in the water.
It's a way for a decentralized service to provide a publicly-resolvable self-sovereign identifier for a user. "Publicly-resolvable" means that anyone can query your public identity state, given your DID. "Self-sovereign" means that you and only you can alter your public identity state (i.e. you own the private keys).
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.
Not necessarily is DID connected to publishing something on a blockchain. First: DID does not make any statements to the underlying infrastructure, this can be a completely decentralized public, permissionless blockchain but also public, permissoned ledger(also decentral but a little less) or the did Methods using a central server as referenced in the w3c mozilla response.
DID for example solves/enables some aspects of the 10 principles of SSI, e.g. portability
Self-Sovereign Identity and DIDs are a very fast moving train. People argue that in the early internet days there was a similar competition between new protocols(compare with DID methods) before we arrive in our todays HTTP(S)-only world. Similarly DID methods will probably consolidate to a handful within few years and DID Core is only a first step to get a minimal common denominator.
Also its questionable if Microsoft&Google and the others are fearing a rapidly evolving ecosystem that they can not jump on as fast and therefore remain sceptic in any case
This is probably the last thing that the likes of Microsoft and Google are worrying about right now. I'm sure it is fun imagining being the lone hacker keeping them up at night.
Microsoft hired Kim Cameron at the tail end of the last decentralized digital identity craze and once built an OS feature (CardSpace) to support it. I really doubt anyone there is afraid of sovereign identity.
> 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
What are these people smoking? DID has nothing to do with PoW, it's merely one of the methods you could use to timestamp when a signature was made. There are plenty of other ways (centralized too, since that's probably what Microsoft and Google care about) to do this, so not sure why sustainability is being brought up as a counter-point to the DID specification.
As someone who has attempted to follow a few events in this space, there was massive presence of PoW blockchain advocates, underlying assumption that everything is blockchain, ... and it very much felt as if other things were very much an afterthought (EDIT: and sadly such afterthoughts in theory being in the spec but useless/not really wanted is not entirely uncommon in specs). If that was a common impression others got, don't be surprised by the reaction.
As another person who've followed DID closely, where is the "underlying assumption that everything is blockchain" part coming from? The specification has one mention of "blockchain" and many parts of the specification leaves the storage part free for implementors to decide freely how it works.
Daniel from Microsoft’s Identity team has been driving the Microsoft DID effort for years and has been pushing Bitcoin as the storage layer for that entire time.
Daniel can fight for whatever storage mechanism he wants, it's not defined how the DID should be stored in the specification so people are free to store them however they want.
Then some group comes along and uses sustainability as signal against DIDs, when DID has nothing to do with Bitcoin or blockchain? Feels like the motivation for this "response" comes from somewhere else than "please think of the planet".
Sure, and in the 50s, vacuum tubes were the only mainstream computing mechanism that had seen real world use for a significant length of time. Same goes for all other outdated technologies.
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.
What kind of proof mechanism are you talking about? Do you mean PoW can prevent an attacker spawning many identities? That's certainly not the case, because bad actors have plenty of resources.
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.
All the more reason to incentivize real-world use of other approaches. "This is how we've always done it" is poor reasoning, whether it's about blockchain or lead pipes or asbestos.
Is someone going to reinvent Namecoin¹ and IPFS's IPNS²?
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.
First time I've seen "s12y" (sustainability) and while I'm usually averse to new buzzwords I quite like the association with "i18n" (internationalization) and "a11y" (accessibility).
Somehow feels like the trinity of responsible software ("responsible" probably isn't the right word here).
Thanks for providing this context. I didn't know s12y stood for sustainability, and I also only now realized that the number in e.g. i18n is the number of letter omitted (and not leet speak or some "sk8er"-like abbreviation).
A framework of responsible software isn't complete unless it includes security (s6y?), given the rampant breaches, data theft, and cyber war these days.
It's interesting to me the amount of energy people spend on convincing themselves that a technology (POW) that didn't even exist 12 years ago and ran on home PCs up until 7 years ago is somehow responsible for wildfires in California or deforestation in Brazil. DID has little to do with Bitcoin. I don't even know if it's the best option, but clearly the lack of decentralized identity on the web has been significant in propagating corporatist monopoly ownership and influence over the web. Nitting about an integration with one particular blockchain (DID works with multiple) is not productive and it's a distraction from the core point of the proposal.
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.
> It's interesting to me the amount of energy people spend on convincing themselves that a technology (POW) that didn't even exist 12 years ago and ran on home PCs up until 7 years ago is somehow responsible for wildfires in California or deforestation in Brazil.
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's a non-sequitour in your depiction of an attack. Gaining 50% of hashing power is not that interesting unless you really want to prevent someone from using their Bitcoin. And you can only prevent them from using it while your attack is sustained. When someone has gained ~50% of the hashing power, they only can do a small number of attacks [1], that are only profitable under external conditions, and even then, extremely risky unless you have a lot more than 50%.
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.
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?
> 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
This seems false to me. Could you elaborate on what incentives you see at play here?
On another note, I feel one of the finest design details of Bitcoin is that its "decentralization-failure-mode", a.k.a. under a 50ish-percent-attack, is technically indistinguishable from normal operation.
2. The DID spec doesn't require the use of Bitcoin. So we agree with your last statement-disguised-as-question. Thus, it shouldn't have been listed as a reason for the rejection of the proposal (which spawned this thread)
1. Are we agreed that "securing the network" means "having enough computational power that an attacker cannot out-compute us," and conversely that the security threats that Bitcoin protects against are via attackers out-computing the legitimate network? And that these measurements of computational power are opposed to each other (i.e., if the legitimate participants have more and more computational power, attacks are harder, and if an attacker has more and more power, the network is less secured)?
If yes, doesn't it follow that there's an incentive for the people who want a secure network to secure the network - by gaining more computational power - and for the people who want an attacked network to prepare to conduct attacks - by gaining more computational power?
(If no, again, why Nakamoto consensus instead of something else?)
2. Correct, but there seem to be multiple "blockchain" methods listed at https://w3c.github.io/did-spec-registries/#did-methods , and the spec itself suggests that you can verify a signature from a revoked key if the signature was timestamped via a ticking blockchain (like Bitcoin's).
If it's true that the spec doesn't require the use of Bitcoin or other Nakamoto-style blockchains, which I agree seems to be the case, then I agree with you that it shouldn't be a reason to reject the spec - but also it seems like the reviewer's comment could be easily addressed. Just say that the W3C won't standardize any Nakamoto-consensus-based specs because the technology is wasteful and not specifically helpful for this particular purpose. (The reviewer is also asking the W3C not to standardize any centralized specs, like the ccp/Baidu one or the GitHub one, which also seems like a reasonable request and an easy thing to fix.) Then the reviewer could withdraw those objections.
(Note that for timestamping, Certificate-Transparency-style logs can address that without mining: https://transparency.dev/ Right now the spec says "for example, it was anchored on a blockchain," without defining the word "blockchain," which most people interpret as a Nakamoto-style one. IMO it would be good if the spec instead mentioned CT-style logs. It's a small change, it wouldn't change the semantic content of that sentence, and it would address the objection that the spec encourages technologies that require mining - it's the only mention of blockchains in the core spec.)
1. I'm not sure we agree on that... Bitcoin doesn't protect against attacks, it provides you with a relatively simple model to measure the cost of attacks.
At equilibrium, any Bitcoin network participant will look for two fundamental things: (a) being able to move their own assets and (b) relative market price stability of their bitcoin. In case of a sustained 50% attack, both properties start to crack, but not completely. But after the attack, they are regained -- (a) immediately, and (b) eventually.
Consider the attacker to be a government, for example, an actor with a relatively high amount of resources, and the Bitcoin participant a dissident citizen of such government. The dissident wouldn't like to have its assets frozen by the government (through strict censorship of the dissident's transactions), so the market value for Bitcoin drops comparatively to how wealthy was the dissident selling its bitcoin savings. But, also, the dissident might avoid selling if they have enough financial capacity to withstand the attack.
In order to carry out such attack, the government needs to increase its energy spending on Bitcoin, up to the point where the attack is successful for a prolonged period of time. Bitcoin production is intrinsically bound to energy generation, thus to its economic realities (variability of demand, climate conditions, political affairs, just to name a few).
It would cost a government X dollars a day, or Y watts a day, every day, minus the price of the coins generated to attack the network. I estimate X to be the total miner rewards: at the time of writing, 38M USD [1]. Y seems to be at around 456 GWh [2]. Is it worth it for your adversary? That number is the dissident's security parameter. As long as their savings are less valuable than the cost of the attack and they can sustain the attack financially, the dissident should be fine (or really scared about an enemy irrationally spending a lot of energy/money with the purpose of just preventing them to access their money temporarily).
In the end both miners and users just want the chain to move forward. If one particular actor or coalition potentially prevents it, users/miners outside the coalition (if they detect it) would raise their investment to continue chugging blocks.
I think there are no "legitimate" vs "attacker" uses of hashing power. It's more about coalitions between miners and how costly/profitable would it be for them to centralize the network, and how hard is it on the other participants to coordinate a decentralized counter-attack (which ends up profiting them). But eventually, the equilibrium between all participants is to spend as little money/energy as possible. And if it's not decentralized it becomes censorable: next, it loses its value: now who's gonna want to mine something worthless?
2. We see it the same way. I'd add that if Bitcoin is staying around (I don't think it can be shut down), one solution is to use Open Timestamps or other hacks that don't require "block real estate", thus in no way compete with transactions, essentially piggybacking the PoW and getting the timestamp for free.
Which is why, almost tautologically, it doesn't matter the power expense of blocks or even individual transactions.
If a micro-coin becomes possibly promising, someone will dump 12gW into it a year until the consumption matches it's appreciation. May as well have the work be useful or artificially difficult for good or better reasons.
I don't really like ENS (or any of the blockchain DNS facsimiles) for decentralized identity. ENS doesn't really have a story for verification of socials or other wallets, and there's no way to look up your ENS domain or eth addr from any of those other identities stored as records on an ENS domain.
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.
Proof of Work (POW) solutions can be equally deployed on other consensus protocols that don't have unbounded energy demands, given the ways the platforms function. Proof of Stake (POS), Delegated Proof of Stake (DPOS), etc.
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.
It is database state consensus acknowledgment, not blockchain promotion.
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.
The energy argument seems like a disingenuous signal to dilute the discourse into a political one instead of examining the architectural merit. If the best argument they have against decentralization is that proof of work uses electricity, it's a red herring holding a dog whistle in front of a motte and baily while it asks whether anyone will think of the children.
Before the argument against blockchain methods is an argument against centralized methods such as "did:ccp", which seems to be an identity mechanism backed by Baidu accounts: https://w3c.github.io/did-spec-registries/#did-methods
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?)
Mozilla referenced quite openly "Google sez PoW bad", idk if something this open is a conspiracy.
"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 ..."
Google simply wants to own the entire identity stack end to end, and they can, because they own Android. Same with Apple. Apple is canvassing various jurisdictions right now with their Digital ID, and demands internal govt discussions use a codename and that nobody mentions Apple by name, and also try to restrict who gets to know, gonna be one anti-open standard if they get their way. Google is likely doing the same, haven't been following this stuff too closely these days, but their ventures arm has made investments all over in identity in the last decade.
centralized objection:
The DID push from Microsoft hinges on their ability to route around the mobile platform control (because they don't have a mobile platform), so that they can even begin to compete with Apple/Google here. I'm sure Apple and Google just love the idea of being cut out and commoditized.
That's all this is about, Microsoft not having a mobile platform. so now MSFT is fighting for an open standard, which is hilarious. They don't care if it's centralized on some identity provider like github or whatever. If you dig deep enough all identity is centralized in the end on the most authoritative source of identity: government. "decentrablazed" is just a window dressing.
I concede that this doesn't explain Mozilla actions very clearly, but they are at this point a mostly irrelevant player in the identity market anyway, nobody except their 3% of marketshare cares what they think. Mozilla just renewed their deal with Google for 400mil, so it could very well be an executive decision that "DID very bad, no matter what", and how their standards architects have to contort themselves into pretzels on mailing lists and invent new catchy acronyms. The mozilla-google contract terms haven't been published even in the roughest approximation, make of that what you will.
Right, it's not a conspiracy. When there are multiple participants in a forum, and one participant has already raised a point that you agree with, saying "I agree with so-and-so's point about..." is the normal way to do things.
What would be a conspiracy - and a genuine problem - is if Mozilla were repeating Google's line because they were there to advocate for Google's beliefs instead of what they thought was best, i.e,. the group was stacked in Google's favor. But the evidence we have doesn't permit us to conclude that this is happening or even likely.
As a simple example, Mozilla and Google tend to reach the same conclusions about whether a new CA should be trusted or an old CA should be distrusted. But this isn't because one is telling the other what to do; it's because they have similar standards and expectations of CAs.
(It would also be weird, and perhaps a conspiracy and a problem, if Google were not a participant in the W3C and Mozilla felt that its role was to represent Google's thoughts instead of its own. But that's not what's happening here, either.)
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).
Snooze. Yet another half baked idea from the W3C. Remember WebID? Probably not because it went nowhere after repeatedly ignoring major weaknesses. What did they do? Address them with well thought out solutions? No, they did exactly what they always do, ignore it until they can't and then bolt on some actually implemented solution hoping to ride their coat tails. Sort of like what we've got here with JSON-LD. So now we can be lectured to for a decade about how superior their DID solution is if only we would listen.
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.
I'm not going to give bigcorps a pass, but the thing with specs is that it is hard to criticize it until the spec is, you know, published in many cases, especially if you aren't in the committee.
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.