Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lists.w3.org

Post reply on HN
Print view View original

41–50 of 66 posts

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

#41

Post by capableweb »

PretzelPirate wrote: post #26
capableweb wrote: post #11

Earlier quoted context omitted.

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.

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

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".

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

#42

Post by jude- »

dboreham wrote: post #23

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.

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.

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

#43

Post by MauranKilom »

junon wrote: post #2

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).

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

#44

Post by [deleted] »

jude- wrote: post #42
dboreham wrote: post #23

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.

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 t…

[deleted]

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

#45

Post by still_grokking »

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.
[ Source: https://www.w3.org/TR/did-core/ ]

¹ https://www.namecoin.org/ ² https://docs.ipfs.io/concepts/ipns/

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

#46

Post by eoo »

geofft wrote: post #36
eoo wrote: post #29

Earlier quoted context omitted.

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, e…

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 confi…

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)

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

#47

Post by inter_netuser »

still_grokking wrote: post #45

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…

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.

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

#48

Post by [deleted] »

motohagiography wrote: post #37

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]

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

#49

Post by geofft »

inter_netuser wrote: post #38
motohagiography wrote: post #37

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.

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

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?)

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

#50

Post by geofft »

eoo wrote: post #46
geofft wrote: post #36

Earlier quoted context omitted.

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 confi…

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 i…

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.)

Post reply on HN