[HN Gopher] Response to 'Call for Review: Decentralized Identifi...
___________________________________________________________________
Response to 'Call for Review: Decentralized Identifiers (DIDs)
v1.0'
Author : lorn3
Score : 66 points
Date : 2021-09-29 08:18 UTC (14 hours ago)
(HTM) web link (lists.w3.org)
(TXT) w3m dump (lists.w3.org)
| jude- wrote:
| 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
| junon wrote:
| 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).
| a_imho wrote:
| Maybe r9e s6e?
| MauranKilom wrote:
| 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).
| pwlb wrote:
| 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
| zcw100 wrote:
| 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.
| pwlb wrote:
| not yet, but identity giants like okta and ping are already
| looking at SSI very carefully. digital identity will be key
| in the next years
| csixty4 wrote:
| 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.
| still_grokking wrote:
| Is someone going to reinvent Namecoin1 and IPFS's IPNS2?
|
| 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.
|
| [ Source: https://www.w3.org/TR/did-core/ ]
|
| 1 https://www.namecoin.org/ 2 https://docs.ipfs.io/concepts/ipns/
| inter_netuser wrote:
| You are exactly correct. In fact quite a few implementations
| rely on IPFS.
|
| The hilarious part is that these supposedly "decentralized" ID
| systems pull data from the most centralized entity:
| government's civil register.
| zcw100 wrote:
| 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.
| fennecfoxen wrote:
| The link goes to a takedown of the idea, agreeing with you it's
| pretty half-baked. Lectures on its superiority seem unlikely.
| motohagiography wrote:
| 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.
| [deleted]
| inter_netuser wrote:
| Google stands to lose a lot if DIDs take off. They'll stop at
| nothing.
| geofft wrote:
| 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
| Celik'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 Celik'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?)
| inter_netuser wrote:
| mozilla conspiracy:
|
| 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.
| geofft wrote:
| 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.)
| vmception wrote:
| 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.
| user-the-name wrote:
| As usual with blockchain promotion, the word "can" is doing a
| whole lot of heavy lifting in that sentence.
| vmception wrote:
| 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.
| Communitivity wrote:
| It is much easier to destroy than to create.
|
| 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.
| dochtman wrote:
| Does anyone have links to the Google and Microsoft reviews
| mentioned in this email?
|
| Browsing the last 6 months of public-new-work archives doesn't
| seem to yield many other reviews of the DID proposal.
| dwaite wrote:
| Reviews may be public or private, Google and Microsoft did not
| make their reviews public.
| EGreg wrote:
| One of my acquaintainces at Microsoft worked for years to get
| this through: https://identity.foundation/sidetree/spec/
|
| 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.
| de_keyboard wrote:
| PoW is the only proof mechanism that has seen real world use
| for a significant length of time.
| geofft wrote:
| 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.
| EGreg wrote:
| 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.
| southerntofu wrote:
| 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.
|
| 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
|
| [1] https://reclaim.gnunet.org
|
| [2] https://taler.net/en/
| bmn__ wrote:
| Called it. https://news.ycombinator.com/item?id=27024026
|
| Feels good to be validated by someone like Tantek.
| todd8 wrote:
| From the article:
|
| > 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
| capableweb wrote:
| 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.
| PretzelPirate wrote:
| 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.
|
| https://mobile.twitter.com/csuwildcat
| capableweb wrote:
| 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".
| detaro wrote:
| 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.
| capableweb wrote:
| 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.
| dboreham wrote:
| 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.
| jonahbenton wrote:
| 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...]
| csixty4 wrote:
| 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.
| capableweb wrote:
| > 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.
| Noujin wrote:
| > if it's truly decentralized then there's no need to publish
| it.
|
| How do you come to that conclusion?
| inter_netuser wrote:
| 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.
|
| Funny how times have changed.
| capableweb wrote:
| 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.
| dwaite wrote:
| > 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.
| pwlb wrote:
| 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
| jude- wrote:
| 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.
| [deleted]
| chrisco255 wrote:
| 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.
| geofft wrote:
| > _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.
| eoo wrote:
| 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.
|
| [1]: https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot
| _of_...
| geofft wrote:
| 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?
| eoo wrote:
| 1. My point is that you lost me here:
|
| > 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)
| geofft wrote:
| 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.)
| [deleted]
___________________________________________________________________
(page generated 2021-09-29 23:01 UTC)