If you want to have a decentralized DNS, a blockchain might make sense. However, a global consensus on who controls what name isn't as relevant as one would think. As more and more interactions are initiated online, the SSH model of accepting the key on the first connection becomes better suited.
How do I know I am connecting to my bank's website and not some phishing website? Because it presents me with a proof that it controls the identity of the website where I initially opened my account.
My point is that decentralized identity does not require a blockchain. This is the result of people thinking: "hey, what can I do with a blockchain?" rather than "How do I build a decentralized identity system".
The supreme irony is that Satoshi Nakamoto is the perfect proof that a secure online identity needs not depend on a central authority, or a blockchain.
Agreed 100% that this is someone looking for a problem to fit their solution. All you need for decentralized identity is a (collection of) public key(s) that can be referenced and cryptographic enforcement of authenticity+integrity. Although I might be a bit biased, because I'm working on a project that does this.[1] Such an identity system is simple enough that you can layer any naming mechanism on top of it without appreciable extra cost compared to a unified approach, at the advantage of not restricting yourself to a specific naming architecture. By all accounts, a blockchain is a tremendously inappropriate amount of bloat for the purpose of identity authentication.
I wouldn't say that naming requires consensus though. Naming requires a degree of trust in the entity declaring the name. Consensus is only one way to arrive at that trust. And different organizations will have different requirements for trust: for example your bank is going to have very different requirements to "name" your account than, say, Facebook. Informally I've called this the difference between identity authentication vs identity verification, but I know that's not ideal terminology -- does anyone have a better suggestion?
It depends what properties you want for your names. If you want everyone to recognize your globally unique name, then it behaves like a piece of property and a blockchain is indeed appropriate. Otherwise, web of trust models, pet names, centralized providers etc are by and large fine.
That's what's being argued here--it's valuable to both users and services like GitHub for everyone to have globally-unique names that everyone can recognize.
> Identity does not require consensus, naming does.
It's not just about global consensus on naming, but also global consensus on data associated with that name (which includes proofs/verifications/signed-statements etc). In other words, the system described in that post is not just "DNS for people", it is "DNS + PKI for people".
> Satoshi Nakamoto is the perfect proof that a secure online identity
The Satoshi Nakamoto secure identity you're describing is missing the human-readable part of Zooko's triangle. Not having human-readable names is a major limiting factor for practical adoption.
"Satoshi Nakamoto" is human readable. The fact that a train model hobbyist shares that name only seems to be confusing to a Newsweek reporters. What people care about is: the Satoshi Nakamoto who created Bitcoin, and his public key is well known. Name is a property of identity, not a pointer to it.
What I think GP means is that "Satoshi Nakamoto" fails the "secure" point of Zooko's triangle: there are two or more entities to which "Satoshi Nakamoto" maps. Human names are decentralized and human-meaningful, but not secure.
This is where the blockchain (or some other log-like data store) becomes important. By giving you a total ordering of which principal has written a claim on a name, you can achieve the "secure" property by applying a validation policy as a function of claim order to determine which principal the name points to. For example, you might say that "Satoshi Nakamoto" shall refer to the first principal to claim it in the blockchain, and subsequent claims by other principals should be treated as invalid.
The reason to use a blockchain to store the history of name claims is simply because the blockchain is a trustless, decentralized data structure (achieving the "decentralized" point in the triangle). If this property isn't important to your use-case, then other log-structured data stores will do just fine.
My point is precisely that this property isn't critical for identity.
And no, blockchains aren't trustless, at least not in the sense in which trustless is generally used. In the case of Bitcoin, you have to trust that the miners will behave in a certain way. There are no mathematical guarantees.
> My point is precisely that this property isn't critical for identity.
I don't know what you mean. I think you'll agree that it would be undesirable for me to insist being called by the same name as one of my coworkers, for example. Name collisions are definitely a problem for identifying people in practice.
> And no, blockchains aren't trustless, at least not in the sense in which trustless is generally used. In the case of Bitcoin, you have to trust that the miners will behave in a certain way. There are no mathematical guarantees.
We might have different meanings for "trustless." Can you give an example of a non-trivial PKI system or protocol that you consider "trustless?"
I consider the blockchain to be "trustless" because it's extremely hard to make a convincing forgery of one, and because I can verify with high probability that the blockchain I have is the "right" blockchain. I can verify that a blockchain is well-formed, I can calculate a highly-probable lower bound on the number of compute cycles needed to generate it, and I can compare this lower bound to an expected value based on my external knowledge of electricity costs, semiconductor costs, history of Bitcoin's compute capacity, and so on. The only thing I need to assume is that the blockchain I received was generated by a set of peers who spent the majority of their combined cumulative compute power to mine it honestly. However, I'd argue that this assumption holds true in practice, because the amount of compute power an adversary would need to use to generate a valid but wrong blockchain is enormous and costly (it may very well be cheaper for the adversary to achieve its goals via some other route).
First of all, you can insist all you want, it won't make it so, people will call you what they want. Second, I can insist on being called "Warren Buffet", and people may even humor
me, but that won't let me sign checks from his bank account, or give commencement speeches.
Regarding trustlesness: the onion hidden service model (domain is hash of key) is trustless in the sense that, according to very strong mathematical conjectures, it would require astronomical power to break.
There are no mathematical guarantees at play at all in Bitcoin. You're assuming that miners are solely interested in earning rewards and not in bringing down the chain. You're assuming they're not colluding with each other.
And no, breaking bitcoin doesn't entail spending hundreds of millions building up mining capability, that is complete wishful thinking. It entails spending a couple millions to kidnap the families of a few mining pool operators.
> First of all, you can insist all you want, it won't make it so, people will call you what they want. Second, I can insist on being called "Warren Buffet", and people may even humor me, but that won't let me sign checks from his bank account, or give commencement speeches.
You've proven my point that name collisions are undesirable.
> Regarding trustlesness: the onion hidden service model (domain is hash of key) is trustless in the sense that, according to very strong mathematical conjectures, it would require astronomical power to break.
I'd say this is a bad example of "trustless." As an adversary, I don't have to break your onion service's private key to break the security of the system. All I have to do is trick users into accepting the wrong public key. The user must therefore trust that the public key hash (s)he learns is the "right" public key hash.
The choice of names becomes important when you consider how a user learns the legitimate public key hash, especially if you consider the problem from the perspective of a non-CS user. Name memorability is important for discovery. Two public key hashes are distinguishable, but they look like gibberish and are hard to memorize, meaning that it's hard for users to propagate their knowledge of the right public key hash. However, "bankofamerica.com" is memorable, is easily conveyed in verbal, written, and electronic communication, and is easily distinguished from "bank0famer1ca.com".
As mentioned in another comment, the problem I'm trying to solve is not proving whether or not the name owner actually is Bank of America. I'm only trying to bind human-meaningful names to public keys in a decentralized but hard-to-break manner.
> There are no mathematical guarantees at play at all in Bitcoin. You're assuming that miners are solely interested in earning rewards and not in bringing down the chain. You're assuming they're not colluding with each other.
The blockchain itself uses strong mathematical conjectures (i.e. the hardness of calculating a partial preimage of a double-SHA256) to place a huge lower bound on how much CPU was used to produce it. As explained earlier, this is important because it's also the lower bound for an adversary to overcome to create a plausible blockchain with the wrong data.
> And no, breaking bitcoin doesn't entail spending hundreds of millions building up mining capability, that is complete wishful thinking. It entails spending a couple millions to kidnap the families of a few mining pool operators.
Miners can and will switch pools if a pool operator starts to misbehave, so kidnapping all the pool operators' families won't gain you much. Moreover, the amount of work you'd have to do to retroactively alter the transaction history to change my transaction's (name, pubkey) is bound below by the amount of work to mine each block between my transaction and the current block (you'd have to re-mine the transactions faster than the rest of the network; otherwise you'd never catch up to the longest fork). Kidnapping pool operators won't help you recalculate these partial double-SHA256 preimages.
> You've proven my point that name collisions are undesirable.
But there is no collision. In the example I'm making, the people chose to humor me, they chose to introduce a collision because they always have context information.
> I'd say this is a bad example of "trustless." As an adversary, I don't have to break your onion service's private key to break the security of the system. All I have to do is trick users into accepting the wrong public key. The user must therefore trust that the public key hash (s)he learns is the "right" public key hash.
How do you learn about the website in the first place? Most likely online.
> I'm only trying to bind human-meaningful names to public keys in a decentralized but hard-to-break manner.
Yes, I get that. The point is that there's not much of a point in doing that.
> Miners can and will switch pools if a pool operator starts to misbehave
That depends. They may be enticed to follow the attack chain.
And by the way, even if you really, really insist on binding human meaningful names to keys, all you really need is a Haber Stornetta timestamping service. No need to bother with proof of publication, which is where the blockchain gets most of its bloat from.
> But there is no collision. In the example I'm making, the people chose to humor me, they chose to introduce a collision because they always have context information.
Collisions are allowed precisely when other parties humor you. Warren Buffet's bank did not do so; it resolved the collision. I'll bet that you can come up with many examples where people will not humor you if you introduce yourself as Warren Buffet, so I'll not belabor this point further.
> How do you learn about the website in the first place? Most likely online.
Actually, my parents told me.
Look, if you'd rather assign non-human-meaningful names to principals instead of human-meaningful ones when the security of one approach versus the other are otherwise sufficient, then please don't let me get in your way. However, I think your preference is in the minority, and I think there is plenty of historical data on things like domain name prices that backs my opinion up.
> And by the way, even if you really, really insist on binding human meaningful names to keys, all you really need is a Haber Stornetta timestamping service. No need to bother with proof of publication, which is where the blockchain gets most of its bloat from.
That's effectively what the blockchain already does, no? It provides a hash-linked list of all blocks, which in turn must contain a set of well-formed linked lists of of signed transactions consistent with Bitcoin's protocol rules for each key with a non-zero balance. The proof-of-work scheme stops weak adversaries from doing the equivalent of (1) publishing an adversary-chosen hash in the newspaper, and (2) replacing some of the archived copies of the library with different ones with invalid hashes, all in order to trick you into trusting the wrong documents. Also, if it wanted to do so, a newspaper could publish every kth block's hash to help lend credibility to the longest chain.
Personally, I don't agree with your assumption. It is totally fine for 2 people to have the same globally recognized name because the people who need to differentiate between them will spontaneously invent a system to do so.
In Japan nobody has middle names and family names in some areas are very common. For example, where I live Suzuki is ridiculously popular. At the school I taught at, 10 of the 80 teachers had the last name Suzuki and 3 of them had the same first name. It was absolutely not a problem.
These teachers responded to many names. Sometimes their first name, sometimes their last name, sometimes their home room class number and their last name. The name that was used depended on context. There was absolutely no reason to have a globally unique name for them. Their family called them something, their friends called them something else, their colleagues called them something else, their students called them something else.
The important part is that the person interacting with someone has a distinguishable name for that person. However, they do not need to share that name. I don't need to know that my colleague's wife calls him Pooky, while I call him Tarou, while his students call him Mr. Suzuki (if they can even remember his name at all -- quite a lot of the students will just call him "teacher").
This is also true of computer systems, from my experience. You need a globally identifiable identity (like an SSH key), but you do not need a globally identifiable name. The people who interact with the identity can choose any name they wish. The name is not important.
Sometimes you have 2 or more people who know the same person and want to reference them. As long as they have a globally recognizable identity, then it's fine. So if person A says "Pooky (who controls ssh key 1234) is a very kind person", I can easily identify the person that they are talking about (or verify that I don't know that person). My determination of whether the person is kind or not will depend on how much I trust person A.
As the other poster mentioned, in virtually every case, web of trust, and nick names are exactly what you want. The only time you need a globally identifiable name is if you are interacting with someone that you have never had any dealings with before (and none of your acquaintances have had any dealings with before) and you want to be assured that they are who they say they are. But in this case there is still a gap -- you will need some kind of authority to vouch for their identity (like a government with a passport number or something like that). A block chain will not do that for you.
Like the other poster, I can see no utility in this. It's technologically interesting, but there are better ways to disambiguate names.
Edit: Reading further in the comments, key revocation is an interesting problem which I hadn't considered. I can see a use for a ledger in that case.
> The important part is that the person interacting with someone has a distinguishable name for that person.
I think your example actually proves my point. In the limit, how does one tell apart all of the people with the name Tarou Suzuki's? Contextual hints aren't always useful to the identifying party (in the limit, none are), so ultimately a globally unique name such as a passport number or an SSH key must be used instead.
We seem to disagree on two points: on the utility of a globally-unique name being human-meaningful, and on whether or not these names need to be issued by a centralized trusted party. Regarding the former, I think there are many obvious cases where a globally-unique but human-meaningful name is preferred to a globally-unique but non-human-meaningful name. Examples include DNS name versus IP address, and Twitter handle versus user ID. Giving a user a globally-unique human-meaningful name already has proven applications for things like SSO (e.g. Facebook Connect), and has hypothetical benefits like allowing the user to share information across services seamlessly. This article makes the case for a decentralized implementation. Am I to understand that you believe this has no utility?
Regarding the second point, if you take a simple DNS-like policy of "first person to claim a name gets it, and has to renew it periodically to keep it", you can absolutely use a blockchain to vouch for bindings between human-meaningful names and humans. It's no different than binding an address to an unspent output in a transaction. As mentioned above, the caveat is that you have to trust that the peers mining the blockchain dedicate the majority of their cumulative computing power towards playing by the blockchain's rules, but I have argued that this isn't an unreasonable thing to do, due to the difficulty of creating a plausible but wrong blockchain. The reliance on a central party like a government isn't without its own issues, after all (even mundane ones, like sending the passport to the wrong address, or mistyping the owner's name).
I wholeheartedly agree that contextual clues and nick names are highly desirable. However, the fact that they don't always work means that we need a fall-back mechanism for identification. Why settle for a meaningless string of digits and characters, when it can be something easy to remember and meaningful to the owner?
I'll try to respond to this without writing a book ;-) It's hard because I think you are missing the point that the things you want are possible without the solution that is presented here. The other solutions are also simpler.
There are 2 scenarios. In the first scenario, I have a pseudonymous interaction with someone/something and I simply want to ensure that every time I interact with that person/thing it's the same one.
For example, if I am a store, I want to make sure that my repeat customer is actually the repeat customer. If I am talking on HN, I want to make sure that the jude- that I am talking to today is the same jude- that I talked to yesterday. I really don't care who that person is. I may also care that jude- is the same jude- (or some other name) on another system. Or perhaps I want to be alerted when that person is confusingly different.
All of those things can be done without a centralised ledger. They simply require a public key that is signed and distributed appropriately.
I will also add to this scenario the situation where you actually need to know the real identity of the pseudonymous entity (say if you are a bank). This requires a central authority who can verify the identity (this is required in every case), and that the central authority signs keys appropriately and makes those signatures available.
The other scenario is when I want to contact a specific entity and I don't trust any intermediary to give me the correct information. DNS is perhaps a decent example. I want to contact a IBM's web server and I don't know where they are. I don't necessarily trust the providers.
Now, I think you will agree that in the general case this is impossible. The best I can do is go there once without trusting it and then build up a relationship with that entity to the point that I trust it is the real IBM.
Unfortunately, the current tools do not even allow us to do that easily. However, you could imagine a system where if IBM wanted to change their DNS, they would have to sign the change and if I was a repeat user of their site, I would have their public key to verify the change. This part of the scenario is just like the pseudonymous one.
There isn't much we can do to actually verify that the DNS entry for IBM actually leads to IBM if we don't trust the DNS system, but we can at least monitor if the DNS entry has changed. That way if millions of people are happy and not complaining, we have some confidence that it is the real IBM.
This public ledger is useful (as I pointed out in my edit) if a key gets revoked (so if you meet the imposter after the key has been revoked, you can discover it). It is similarly useful if something has changed before you had a chance to contact it and get it's public key (essentially same scenario as key revocation).
However, even this scenario has simpler implementations than the one suggested.
Finally, you suggest that having a globally unique name is useful because it could be meaningful. What shall we call the 3 teachers who work in the same school and live in the same town and have the same name? Shall we call them Tarou Sukuki 1, 2 and 3?
There is a reason why IPV6 is so huge. We need a lot of addresses. We will not be able to make them all meaningful. You need a map, but that map will necessarily have to be of the 1->N and context based.
> In the first scenario, I have a pseudonymous interaction with someone/something and I simply want to ensure that every time I interact with that person/thing it's the same one.
> All of those things can be done without a centralised ledger. They simply require a public key that is signed and distributed appropriately.
Who signs and distributes the key, and why do you trust them to do so? This sounds a lot like the CA model, which I am trying to avoid using.
Even if you went without a CA and relied on TOFU semantics, using the blockchain to distribute your public key is still a better choice than sending it over the wire to each requester because (1) when creating my name/pubkey pair, I will notice very quickly if the (jude-, pubkey) record in the blockchain is wrong, and immediately claim a different username; (2) once (jude-, pubkey) is published in the blockchain, it is extremely hard to change, so our adversary can't send you a different public key if you're on the same blockchain as me; (3) it is extremely hard for an adversary to make a separate plausible blockchain with the wrong (jude-, pubkey) transaction, since that would require a tremendous amount of CPU time to calculate all the necessary partial double-SHA256 preimages in order to re-write the transaction history back to the block where I registered (jude-, pubkey).
> I will also add to this scenario the situation where you actually need to know the real identity of the pseudonymous entity (say if you are a bank). This requires a central authority who can verify the identity (this is required in every case), and that the central authority signs keys appropriately and makes those signatures available.
I think this is a different problem than what I was trying to solve. It sounds like you want to have a high degree of confidence that the DNS name "ibm.com" points to web servers belonging to the actual IBM, and not a squatter or phisher. If so, then I agree that a blockchain will not help you there. The problem I've been trying to solve is using my out-of-band knowledge that "ibm.com" is the name for IBM's servers to obtain IBM's public key, without having to trust DNS, a CA, or some other centralized entity. I apologize that this was not clear earlier.
> Shall we call them Tarou Sukuki 1, 2 and 3?
Why not let them choose their own globally-unique names, and use a first-to-claim policy to resolve collisions?
Decentralized identity revocation requires a blockchain. It's easy enough to give people statements that you control a given public key. It's hard for them to know whether they should still trust that key. Blockchains are the only systems that are censorship-resistant enough for us to rely on for this purpose.
Sure, lots of people have done lots of thought experiments about what to use blockchains for, some of which weren't the best. However, if you haven't gone through that period yourself, your blockchain use cases are probably too narrow.
Anyone can get Edward Snowden's public key on the Internet, so no, Blockchains clearly aren't the only system which is censorship resistant enough to achieve this goal.
I've been thinking about blockchain use cases pretty extensively for the past two years and written extensively both personally and pseudonymously on the topic. That doesn't mean I have to be right, but if I'm wrong, it's not for a lack of reflection on the matter.
You write a revocation message to the blockchain signed by your key. Now anyone who is trying to verify your identity can prove that it has been revoked.
To add to this, the author brought up another interesting point, the organization you belong to should not own the identity. This will allow the identity to be associated with 0..* organization and the data associated with your identity can travel, be shared, etc. This can be supported with a good authentication / authorization data model without decentralizing the identity.
To bring this back around, the identity does not require consensus, the naming does, and the claims about the identity does.
Satoshi Nakamoto is a case study in how confused everyone is about the concept of identity. Many of the engineers I talk to are at the point where they refuse to even use the term "digital identity" at all. (I think this is mostly what you are saying.)
I like the working definition "set of identifiers" because it frames identify an externalized bunch of labels, understood as relational propositions - truth uncertain - distinct from the purely internal concept of "self".
Works in a non-digital setting too: "name? dob? employer? nationality?"
In your example, we might be able to say that the speaker is referencing one person with a variety of identifiers. The sentence does nothing to establish the "sameness" of a person, but it is a good example of how relevant who makes the claim is. If I randomly uttered that sentence, it'd either be weird or obvious, or maybe a non sequitur. If the Lord High Chancellor says it in 1952, that causes the statement to become true.
But in the more usual sense, if one wishes to evaluate the truth of that statement, where do you start? The "over there" maybe establishes the referent to a person. The name and title then clarify a commonly understood identity for the person. We can then decide if it is, in fact, that person.
But say we already knew that we were looking for that specific person, the Queen of England. Then, the only fact we're trying to evaluate is the current location of Elizabeth the Second. Is it over there? Why yes, yes it is. Hellooooooo!
The mathematical concept of identity is not nearly that simple. Under multiplication, the identity element of the integers is the number 1. And many mathematical expressions share equivalence relationships, which is more in line with your notion of sameness.
Unfortunately (or perhaps fortunately), we can't rigorously encode the relationships you've described with any known mathematical techniques.
>Because it can present a proof it controls the identity
Which proof are you referring to?
As far as I know, there is no way to prove that someone else doesn't have the same number as you (they may have even pilfered the number from you without your knowledge).
>There's not need to prove to anyone that someone else doesn't have the same number as you, I have no idea where this is coming from.
How can you trust an identity, if anyone can claim that identity?
You said that you could know that you were connecting to your bank's website because it would present you with a proof that it controls a particular identity.
Now, I am assuming that you mean a proof of "exclusive control", because unless something has exclusive control over an identity, there isn't really any way to know that some other entity isn't controlling the identity (which would violate your argument's conditions).
I maintain that there is no proof of exclusive control, as there is no way to know you (or someone else) has exclusive knowledge of the appropriate numbers.
You publish a signed statement revoking your key. Publications are kept and replicated by volunteer nodes or in a DHT.
There is no need for consensus or coordination, which is what a blockchain achieves because you act as the central authority regarding your own identity.
Order matters. Suppose my key is compromised, stolen, or lost. If my revocation preceeds a subsequent signature from my key, then the subsequent signature can be considered invalid as well. Unlike a DHT, the blockchain provides everyone with my key's history with respect to every other key's history, so my stolen key cannot be used to impersonate me after I revoke it. Moreover, the blockchain grows at a constant rate, so attempts to censor the revocation will get noticed quickly, since I will notice when my transaction does not get accepted, and other principals will notice when blocks are not propagated.
Once you lose a master key, blockchain or no blockchain, your identity splits. The person who stole your key can impersonate you perfectly.
Having a blockchain does not help at all in telling the attackers from the honest party. What a blockchain lets you do is arbitrarily decide on a single one of the parties as the canonical branch.This is crucial for money, but of no practical value for identity.
> Once you lose a master key, blockchain or no blockchain, your identity splits. The person who stole your key can impersonate you perfectly.
I agree that there is a race between you broadcasting your revocation and the attacker using your key. Until all relevant parties receive your revocation, your attacker impersonates you perfectly.
However, using the blockchain as a broadcast medium for revocations places an upper bound on how soon your revocation will received by the rest of the these parties (assuming the blockchain itself remains available during the compromise). This is not the case with existing PKI systems, which make no such provisions at the protocol level beyond a simple (and usually optional) key expiration. Moreover, the fact that blockchains are extremely difficult to convincingly forge means that your well-formed revocation transaction would be hard to censor in a way that you could not detect, so an unavailability attack would not leave you falsely believing that your revocation has been sent.
I think BlockchainID is a step in the right direction but is it even alive still? The only specification I know of is a draft that's now 9 months old and leaves the question of security up to users having a strong password. Beyond that I thought it was just proof of concepts.
As someone building an identity system on Ethereum, I'd like to remain interoperable, but I don't know where I would find info unless I dig through blog posts.
So, the linked BlockchainID, publicly stores all secrets in an encrypted format. Why would that be good, and even necessary for a decentralized identity?
It is trying to solve key storage and public identity at the same time. How could it possibly be a good idea to store secrets publicly?
Such a system exists for years and is called OpenID. You can use your own openid provider, or choose from an established provider —which is precisely what you do every time you login to a site with google or github for example.
OpenID has some fundamental problems that Mozilla tried to address somewhat with its Persona API, and was marginally successful until they decided to stop working on it, sadly. The fact that it doesn't use Bitcoin has almost nothing to do with OpenIDs flaws, though.
I've heard vague mentions of OpenIDs fundamental problems, but is there a breakdown somewhere? I've had a hard time finding a detailed technical description of why OpenID failed.
I do understand that it confused the hell out of users that they had to login in with a URL, but that seems like branding and education more than a technical flaw.
I think that's essentially Persona, except they do some extra work to avoid informing the Authentication endpoint about the sites you're logging in to.
That confusing part is not just a technical problem. OpenID basically teaches users to be phished, for one. But this has been discussed elsewhere, by yt, on HN.
The biggest thing I see standing in the way of this vision of the future is that it seems to actively go against IT best practices that medium/big orgs have in place.
For instance, the github example in the article is cool but it seems like every company over ~100 employees switches to github enterprise or a similar self-hosted tool where every employee has an isolated account and it's only accessible on the corporate network/VPN.
I've looked around out of curiosity and I haven't really found any good information about building a secure IT organization while taking advantage of modern SAAS products (e.g. github, slack, circleci, docker hub, whatever else). It's basically taken as a given that if you want to be secure you'll have a corporate network in your physical office and all your important internal tools will be on that network (or an even more tightly locked down subnet). I'd love to read any resources to the contrary.
Medium and large organizations should just run their own services that parse the blockchain and turn the data embedded in to Bitcoin transactions in to the state of names and owners. This service would read from the public network and but could itself be only accessible on the corporate network/VPN.
This applies to all sorts of Bitcoin metadata protocols beyond just Blockshain ID, such as Open Assets, Blockcast, and Open Publish.
All of these systems use the public key infrastructure of native Bitcoin wallets for identification and authorization so it's in the ballpark of SSH, a proven approach in corporate settings.
There's a big gap in parsing the bitcoin blockchain vs parsing a local database.
The blockchain is a public ledger so any (encrypted or not) information you store there can be retrieved by anyone. Downloading it is very slow, and parsing it in a reliable way, i.e. using bitcoind's rpc, is even slower. So you'll want to build an index from it, which you'll happen to store in a local database. So after all that you end up with a local database and public information that anyone can access.
Most companies will, understandably, shy away from letting you take your Salesforce info with you. Closed systems are beneficial to employers. Telling companies to throw away some of their competitive advantages (e.g. distribution lists, best customers, etc...) in the name of open-source, decentralized identity is, I believe, an impossible sell.
"Most companies will, understandably, shy away from letting you take your Salesforce info with you. Closed systems are beneficial to employers."
This is an old issue in sales. When a sales rep leaves, do they take their customers with them? It varies with the industry, and it's something that top sales people negotiate when they take a job. Since they will be bringing in customers, they insist on taking them when they leave.
While this is specifically referring to statistics in the OP:
This new setup makes it possible to take something with me. Github doesn’t exploit this yet (as far as I know), but for instance, it could allow me to keep some statistics, such as how many commits did I make to code of an organization. Or in the case of Salesforce, how much did I generate in leads or revenues.
it doesn't mention taking distribution lists or best customers, although nothing is really stopping you from taking those things even without distributed identity.
However, distributed identity is more valuable from the standpoint of authenticating someone. It is still up to the company/organization to manage the authorization aspects of their resources, binding specific capabilities and authorizations to their employees/users authentications.
Agree. But what if the concept is too important to be allowed to be owned by a company? What if TCP/IP were AOL/IP? Would we even be here now? I doubt it.
If you want to have a decentralized DNS, a blockchain might make sense. However, a global consensus on who controls what name isn't as relevant as one would think. As more and more interactions are initiated online, the SSH model of accepting the key on the first connection becomes better suited.
How do I know I am connecting to my bank's website and not some phishing website? Because it presents me with a proof that it controls the identity of the website where I initially opened my account.
My point is that decentralized identity does not require a blockchain. This is the result of people thinking: "hey, what can I do with a blockchain?" rather than "How do I build a decentralized identity system".
The supreme irony is that Satoshi Nakamoto is the perfect proof that a secure online identity needs not depend on a central authority, or a blockchain.