Why Decentralized Identity Matters
continuations.com
continuations.com
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.
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'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.
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.
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.
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).
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.
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.
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.
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.
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.
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?
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.
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?
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.
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.
To bring this back around, the identity does not require consensus, the naming does, and the claims about the identity does.
I still trot this link out as a primer whenever the subject comes up: http://stpeter.im/journal/1035.html
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?"
If I say: "Look over there, it's Elizabeth II, Queen of England", I am establishing the sameness of a person referenced by in three different ways:
by a geographical position, by a name, by a title (according to the arbitrary rules of British monarchy)
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.
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.
For example, how would you imagine a system could implement key revocation and signed statement revocation?
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.
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.
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.
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.
AFAIR they have moved from Namecoin to Bitcoin blockchain some time ago.
Checkout: https://github.com/blockstack
for implementation of different software components and protocol documentation!
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?
Alas it doesn't use bitcoin...
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.
1. User puts in their email address
2. Website does a lookup on DNS for the email to find an OpenID endpoint (via SRV or TXT or whatever else)
3. If OpenID connector is found, user gets redirected to authenticate
4. If not, generic create account method.
I'm very interested in the concept of federated identity and I would like to see where previous efforts have failed (and what they did well).
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.
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.
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.
How is that useful for this purpose?
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.
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.
To gain traction, you need to explain it to people, and not just techies.
And most people (even most techies) either don't get 1. why it matters or 2. what the heck it means.
It's usually also offered with a loss coherent and more confusing user-experience than the centralized options.
I'd love for more decentralized systems taking hold, but I'm not optimistic enough to believe in it yet.
http://www.fastcompany.com/3051088/elasticity/relateiq-sales...