To Home page
Not yet written
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.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License