To Home page

Functional Specification

A functional specification is a pile of mockups of the user interface, telling a story of what the software will do for users, explaining how the program will behave externally.

Humans have been identifying themselves with shibboleths for thousands of years, and frequently killing each other in large numbers on the basis of shibboleths.

So it seems to me that the way to go is to have the front end, the user interface for most users, shibboleth based (username and password), while the backend uses public keys, and all the other tools at our disposal, to make shibboleths resistant to dictionary attacks and man in the middle attacks. The user, therefore, should ordinarily control the private key by username and password.

Here is one such proposed system, intended to implement Zooko's triangle:

The end user creates an account with username and password on an identity server, which may be running on the cloud, or on his company server, or on his home network. He gets the hash of a rule identifying public keys that are valid for him, and his username, and how to contact him while he is logged in.

Now if any user actually sees that hash, contact information, and so forth, they will reel back in horror.  It absolutely has to be hidden, or else users will boggle.  We stick it in the avatar icon, and/or reference it by the petname.

Many people can have similar or seemingly identical avatars, and people on different servers can have the same nickname, one's nickname being one's username on a particular identity server.

When he is logged in to that identity server, he can message other people, and other people can message him. To message someone, you need their avatar containing their public key. Any such avatar will be assigned a petname that is unique for any end user, so if someone communicates with two different people, with two different public keys, they will always be identified as having two different names, even if they both have same nickname.

So if I get two people whose nickname is Bob, my software will insist on me differentiating them with different names before I can message them.

The end user should have on his local computer and on his identity server data structures that looks like a browser bookmarks list, except that the favicons can be quite large (can be user avatars), the entry generally contains public key information about the target (or the hash of the rule identifying public keys valid for the target), and the entry may contain username and password information for mutual identification, after the fashion of otr.

Communicating public keys:

The problem is that you want to tell someone over the phone, or on a napkin, or face to face, information that will enable his client to securely obtain your public key and network location so that end to end secured communication can take place.

Also a chatroom's public key and network location.

We do not necessarily protect against security agencies figuring out which public key is talking to which public key.  That issue is out of the scope of a functional specification, but we somewhat reduce the usefulness of this information by allowing people to have lots of public keys.  So you probably have one key for activities that show your unusual sexual preference, another key for job related activities, another key for tax evasion related activities, another key for gun running, and yet another for attempts to overthrow the regime.

The ordinary user by default finds himself using at least one key for face to face key introductions, a different key or keys for phone introductions, and yet more for web or email introductions.  If he is clever and reads the manual, which no one will ever do, he can use the same key for multiple purposes.

All of these named keys have the same behavior when you click on them, they are intended to be perceived by the user as being the same sort of thing.

He can use the link, the named key, to attempt to contact, or buddy it, or bookmark it.

The identifying link information looks like a web link, and is the nickname of the public key.  By default the nickname is the petname.  The user is free to edit this, but usually does not.

When he attempts to contact, this automatically buddies it and/or bookmarks it.

When he finds a named key, he may "bookmark" it, together with one of his own private keys - it goes into a datastructure that looks like, and works like, browser bookmarks.  He can also put it in his buddy list.

When you look at an item in your buddy list or bookmarks list, You see a pair, the other guys key identifying information, and your own key identifying information.  You don't see the keys themselves, since they look like line noise and will terrify the average user.

When you click on one of these bookmarks, this creates a connection if your key is on the other guy's buddy list and he is online.  You can chat, video, whatever, end to end secured.  Otherwise, if you are not on his buddy list, or he is not presently online, you can send him something that is very like an email, but end to end secure.

When you send a bunch of people a text communication, chat like, chatroom like, or email like, they are cc or bcc.  If cc, all recipients of the communication get links, which they can, if they feel so inclined, message, bookmark or buddy.

Text communication software vacuums up and stores all links, so if you get an incoming communication from someone whose public key you have not buddied or bookmarked, the software will tell you any past contacts you may have had with this public key.

Buddied public keys are white listed for immediate online communication, Bookmarked and buddied public keys are white listed for offline text communication, public keys with past information about contacts are grey listed, public keys with no previous contact information are blacklisted.

Because of automatic blacklisting, to contact, you have to exchange keys.

These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License