18 KiB
| title |
|---|
| Zooko’s Triangle |
Zooko Identity
In a decentralized system with no trust anchors how do you figure out which name is the right one with any certainty. If you are texting to “Bob”, how do you know you have the right “Bob”? There are a lot of Bobs.
Zooko’s triangle is the solution to this problem. It is explained in several places
Each identity, whether a human, a server, or something else, has a globally unique cryptographic identifier, which is not human readable or human memorable, a title or display name, which is human readable but not necessarily easy to type correctly or reproduce exactly from memory, a nickname, which is not globally unique, is likely to be unique among the entities that you are dealing with, but not necessarily unique, even among them.
The petname is the name that your system calls this entity, not necessarily what any other system calls this entity, a name constructed by or your computer, typically constructed from, or identical to, the nickname.
The petname is locally unique, human readable, and human typeable. It is how you know this entity and reference it.
The computer is responsible for doing the mapping as needed, and makes sure that when you connect to Bob, you are connecting to the right Bob.
Typically the globally unique cryptographic identifier is a public key, and only Bob knows the correct corresponding secret key. If the thing identified is an immutable data structure, the globally unique cryptographic identifier is a hash of that data, according to the hashing rules for that data type and data structure, which type and structure you very likely do not know and will not learn until you contact the system that has the data.
Zooko’s triangle today
We now have a lot of systems that to a greater or lesser extent implement Zooko’s triangle, and while they are frequently incomplete and unsatisfactory implementations, they all do a sufficient job of making sure you are talking to the right Bob.
The way it works as (more or less) implemented today (frequently less) is as follows:
In private messaging, there are separate message threads for each public key, just as when you text on a phone to and from a particular person, there are separate threads for each phone number, unless you have manually associated two different phone numbers with the same identifier, and where the name appears in text in public or private messages your local computer should associate a unique local petname with each public key. And mostly they do, though existing software is frequently half assed about this.
The petname is generated by mangling the nickname (and possibly part of the display name) down to a valid locally unique identifier, unique on your computer and following your computer’s local rules for valid identifiers, which rules might well depend on the language locale in which the computer is running.
Existing software fouls up on the local petname issue in a variety of ways, but does a sufficient job to ensure that one person cannot impersonate another person
The petnames appear in the text, and in the equivalent of reply-to and cc fields, as @petname, but if “petname” is a local petname corresponding to a public key that corresponds to the other party’s private key, it is colored differently to the text and/or looks like a link in html. If you hover over the link, you see the other party’s display name and nickname, and if you click on that link, you go to data about that person.
What actually gets sent, computer to computer, when Ann mentions Bob in a message to Carol, is not the the local petname that that Ann typed into her text, but the globally unique identifier, which should be, and usually is, the public key or information uniquely identifying the public key, and possibly the nickname, the display name, and information on how to direct a message to that party.
The display name is long, humanly meaningful, and usually probabilistically unique to humans, but inconvenient for typing in full in text, unlikely to be typed correctly, likely to be incorrectly formatted for reply-to and cc fields, and often likely to disrupt the flow of text were it to be directly typed as part of a paragraph.
The nickname is a potential petname, or can be mangled into a locally valid petname without too much mangling.
Display names and nicknames are unique on any one forum If one public key, one nickname and display name on any one forum. Different people can have the same nickname and display name on different forums on different forums. But if they do, if there is one Bob on one forum and a different Bob on another forum, they are going to nonetheless have different local petnames on your computer, and if one Bob sends you a private message, it will appear in a different message thread to that other Bob’s message thread.
What appears in the address fields, and in references to particular people in the middle of a paragraph, is always locally unique, one distinct local petname for each globally unique public key.
In practice, you don’t rely on petnames to distinguish people, though they are quite adequate for distinguishing people, but on the fact that the threading software associates messages coming from the same public key, just as when you see text messages coming from the same phone number on your phone, you see them displayed with previous text messages and replies to that phone number, and pay little attention to the phone number.
In most contexts, you don’t actually need to look at, or even remember, the phone number, and you don’t actually need to look at, or even remember, the petname. You click on the “reply to” button, and the software fills in the appropriate local petnames, which become the appropriate global identifiers when the message is sent, and when the parties receive the message, it gets threaded according to global identifiers, and they see their local petnames for people. Same as with phone numbers on your text messaging application on your phone. No one needs to see phone numbers these days, and even less do people need to see public keys, and seldom need to pay attention to local petnames.
The full and correct implementation of Zooko UI
All existing systems are half incomplete and unsatisfactory:
Bitmessage will never be popular, period. The common pleb doesn't give a shit about privacy or anonymity or security, and just happily uses Fecesbook. The slightly advanced computer user uses the "more secure" instant messengers, that offer a proper GUI and easy usage. The only people using bitmessage are literally some groups of nerds, the unfortunate few, who have coriously stumbled here (for a minute, until they realize what the public channels look like), or trolls that need an outlet for their mental diahrea.
As much as I think BitMessage is an interesting concept, you cannot avoid realizing that it's massively unattractive for wide adoption.
The Bitmessage UI is unbearable. What is needed for it to be popular is a full Zooko name system. With a full Zooko name system, it is going to feel much like one of the more popular apps.
A Zooko name consists of
-
the Guid, the Globally unique identifier, for example the bitmessage Guid, "
BM-NB5cJuoFTkcmNEKDcBwn1RDxYDX3gGbq", which represents the public elliptic point of a secret scalar known only to the sender. -
the nickname, which is global and chosen by the entity named, but probably not unique, Many people can, and usually do, have the same nickname. The nickname starts with a letter, and is composed of letters, numbers, and underscore characters, for example "John_Smith".
-
The full name: The full name is likely to be unique, but only if the entity named chooses it to be likely unique, for example {John_Smith, Dark Lord of attack resistant cryptography}. The full name can be any sequence of unicode characters that does not contain unbalanced curly brackets, and the nickname is the first sequence within the full name of three or more alphabetic, numeric, or underscore characters starting with an alphabetic character.
-
The petname, which is the local name of someone else on your computer. This is locally unique, and defaults to the nickname, or a name constructed from the nickname, unless that petname already exists and names a different guid.
When your system locally constructs a default petname from a nickname, it may mangle it in such a way that nicknames that look similar do not have petnames that look similar.
When sending a message, you can reference a guid by the petname
For example, if Bob's petname for John_Smith is John_Smith71 (because he already had John_Smiths one to seventy as petnames on his computer), but Carol's petname for John_Smith is JohnSmith, and Bob sends a message to Carol containing the the text
remember when @John_Smith71 said ...
then this gets translated on sending to
remember when @{John_Smith, Dark Lord of attack resistant cryptography} #
BM-NB5cJuoFTkcmNEKDcBwn1RDxYDX3gGbqsaid ...
and when displayed to Carol, gets represented as:
remember when @
JohnSmithsaid ...
because the guid is already defined on her computer as the local petname JohnSmith.
If it is not yet defined, then she sees the full set of Zooko names, as sent:
remember when @{John_Smith, Dark Lord of attack resistant cryptography}
#BM-NB5cJuoFTkcmNEKDcBwn1RDxYDX3gGbqsaid ...
Petnames preceded by the '@' symbol get translated to the full Zooko nameset on being sent from the local context where the petname is defined, and the guid gets translated back into the corresponding locally defined petname on entering a local context where a petname is defined for the guid of that nameset.
When receiving a message that references a known guid, the same guid always translates to the same local name, even if the nickname and fullname is different.
The same guid can have many nicknames and full names, and the same nickname and full name might by used by many different entities with many different guids. But people should try to avoid that, by choosing full names likely to be globally unique, and nicknames likely to be locally unique on the systems of the people they communicate with.
If someone maliciously chooses the same full name as someone else, in order to deceive the recipient of the message, the computer will see the guid, and assign him a different petname. To protect oneself against against people pretending to be oneself, one should choose a nickname likely to get a short and distinctive petname assigned on the recipient's computer.
Everyone's system will record each association between a full name and a guid that is sees, the time at which it saw that association, and the guid asserting the association. If it sees a later guid claiming a nickname that corresponds to an existing petname, it treats this as strong reason to suspect the entity who knows the secret key corresponding to the guid making the assertion of scamming, spamming, and shilling. If it sees two different guids with the same full name, also strong reason for suspicion Two guids with the same nickname, weaker reason for suspicion.
If you send a message to an entity defined by a guid, or add a guid to your address book, or if you compose a text containing a full Zooko nameset, perhaps because you are replying to a message that references an entity that has no petname on your system, you will asked to whether you want to store that full Zooko nameset under a local petname on your system.
Moving to a global Zooko system
Zooko’s triangle is, among other things, a user interface concept for storing, managing, and communicating, cryptographic capabilities.
Zooko’s triangle solves half the problem: provides a trusted path. If you trust Bob, and Bob trusts Carol, you can trust that Bob’s introduction to Carol will in fact bring you to the correct Carol.
This, of course, assumes a browser is somehow able to use Zooko style links, rather than PKI links.
The problem then becomes having large number of trusted introduction – a map between human phrases, and documents containing information about globally unique identifiers that are relevant to that phrase: Something like Wikipedia, but without centralized authority forbidding “original research”, aka any deviation from official government truth, and something like a search engine.
To solve the problem of making Zooko style links useful, we have to solve the problem of providing global data that is not state dominated.
Past experience with cryptographic capabilities is that if users are expected to consciously and intentionally use them, they screw up, that even experts screw up, and that end users are not only reluctant to use them correctly, but find it profoundly difficult to use them at all that even expert users find them a pain, as for example the regular unpleasantness of installing a certificate on a web server so that it can do https.
Zooko’s triangle, correctly implemented, should hide from users that they are using cryptographic identifiers, or indeed any globally unique identifier.
Because globally unique identifiers have become almost as ugly as cryptographic identifiers, we have already implemented interfaces that hide globally unique identifiers, for example the bookmarks folder, the buddy list, and the email contacts list. And since those identifiers are already hidden, they can be cryptographic, giving the user many benefits, and no extra grief.
We can do this with not one extra click for security, and indeed will have to do so, for experience has proven that if we ask the user for extra clicks for security, the user becomes frightened and confused, and even supposedly expert users do not provide those extra clicks.
In order that references to objects can be securely transmitted across trust boundaries, they need to be cryptographic capabilities
You don’t want people sending you spam pretending to be your webmaster, or your email host, or your employer, or your bank. You want to share files with certain people, but not always with the entire world, you want to give some people, but not others, the ability to edit particular files. When someone trusted recommends a bank, or a firm, you don’t want some scammer connecting you to himself, instead of the bank you are trying to connect to.
IM buddies, email contacts, and important web pages should be cryptographic capabilities. When you click on a link, it should take you to the web page the author you are clicking on intended. When you receive a message that purports to be from an entity you have a relationship with, it should be from that entity, and when you receive a message from an entity you do not have a relationship with, it should be obvious you do not. All messages should have in the headers “Regarding .....”, which refers to a particular capability to contact you – which usually is the particular capability to contact you contained in some previous outgoing message sent by you.
Further, if we had a way of routinely and easily handling cryptographic capabilities, lots of things that are now inconvenient and unsafe, such as web money, could be made considerably easier and safer.
Monetizing a system of Zooko identity
Information wants to be free, but programmers want to be paid. The primary reason for centralized name systems is that people can make money off other people's internet and corporate reputations.
Names have value, when embedded in a network of names linking to names, because reputation has value. We can create secure pseudonymous payment using cryptography, but cannot create secure delivery of goods and services using cryptography. The other side of the transaction needs reputation.
So the other side of the transaction needs to be authenticated by a secret that he controls, not a secret controlled by registrars and certificate authorities. Enabling people to own their own names is an important step towards enabling sovereign corporations.
Most of the value in the world is not in productive machinery and land. It is in “goodwill” – the value of names linked by names. And governments registrars, and so on and so forth keep skimming that value, and from time to time recklessly destroy it.
But someone has to be paid for enabling people to own their own reputations.
How do we make money out of enabling people and groups of people to own their own reputations?
The easiest and most obvious way is if we issue the money that they use to transact on these reputations. Cryptographic transfer of funds is one half of the problem. The other half is wondering whether the person you are transferring it to will hold up his end of the bargain. Both parts need to be integrated.
Reputations have value by being embedded in a network of reputations. Google made a lot of money by analysing the network and making the information readily available. My fundamental plan is that the keys used for identity will be rooted in the same wallet as the keys used for cryptographic coins, and thus communication carrying metadata about transactions rooted in that wallet, resulting in an intimate linkage between the crypto currency being valuable, and the information about reputation secured by the same wallets being readily available.
And to make reputation embedded in the network of links from reputations to reputations valuable, we are going to eventually need network analysis systems similar to that provided by Google and others.
First mover providing such analysis will have a substantial first mover advantage, as Google has and still enjoys to this day, but the first mover advantage is likely to be less valuable, since lots of search companies will simply add analysis of secure links, links rooted in secrets that are controlled by the owner of the name to their analysis of links rooted in government authority, rooted in certificate authority secrets answerable to registrars. On the other hand, being the source of the wallet software is likely to be a substantial and lasting advantage in being source of the network analysis.