forked from cheng/wallet
159 lines
8.7 KiB
HTML
159 lines
8.7 KiB
HTML
|
<!DOCTYPE html>
|
|||
|
|
<html lang="en">
|
|||
|
|
<head>
|
|||
|
|
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
|
|||
|
|
<style>
|
|||
|
|
body {
|
|||
|
|
max-width: 30em;
|
|||
|
|
margin-left: 2em;
|
|||
|
|
}
|
|||
|
|
p.center {text-align:center;}
|
|||
|
|
</style>
|
|||
|
|
<link rel="shortcut icon" href="../rho.ico">
|
|||
|
|
<title>Functional Specification</title>
|
|||
|
|
</head>
|
|||
|
|
<body>
|
|||
|
|
<p><a href="./index.html"> To Home page</a> </p>
|
|||
|
|
<h1>Functional Specification</h1>
|
|||
|
|
<p><br/>
|
|||
|
|
</p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
Humans have been identifying themselves with shibboleths for thousands of
|
|||
|
|
years, and frequently killing each other in large numbers on the basis of
|
|||
|
|
shibboleths.
|
|||
|
|
<p> 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. </p>
|
|||
|
|
<p> Here is one such proposed system, intended to implement Zooko’s
|
|||
|
|
triangle: </p>
|
|||
|
|
<p> 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. </p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p> 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. </p>
|
|||
|
|
<p> 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. </p>
|
|||
|
|
<p> 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. </p>
|
|||
|
|
<p> 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. </p>
|
|||
|
|
<h3>Communicating public keys:</h3>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> Also a chatroom’s public key and network location.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<ul>
|
|||
|
|
<li>
|
|||
|
|
<p> Face to face:</p>
|
|||
|
|
<blockquote>
|
|||
|
|
<p>Identifying information is nym, face, and location.</p>
|
|||
|
|
<p> Recipient looks up the nym, sees a bunch of faces grouped by
|
|||
|
|
geographic area. Geographic are usually, but not necessarily,
|
|||
|
|
has some relation to users actual location, and may be very
|
|||
|
|
specific, or very broad. It is a tree. One guy may
|
|||
|
|
locate his face at the node "North America", another at the node New
|
|||
|
|
York, North America. You may, of course, employ a well known
|
|||
|
|
cartoon character or movie star as your avatar instead of your
|
|||
|
|
actual face. Fictional places are permitted, but to
|
|||
|
|
avoid filling the namespace, not on the tree that represents the
|
|||
|
|
real planet earth.</p>
|
|||
|
|
</blockquote>
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
<p>Over the phone.</p>
|
|||
|
|
<blockquote>
|
|||
|
|
<p>Recipient looks up phone number. Finds a bunch of named keys
|
|||
|
|
associated with the phone number – usually one key or a quite small
|
|||
|
|
number of named keys.</p>
|
|||
|
|
</blockquote>
|
|||
|
|
</li>
|
|||
|
|
<li>
|
|||
|
|
<p> Web or email.</p>
|
|||
|
|
<blockquote>
|
|||
|
|
<p>Send a link that contains a 256 bit identifier, but the UI should
|
|||
|
|
not show anyone the identifier.</p>
|
|||
|
|
</blockquote>
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> He can use the link, the named key, to attempt to contact, or buddy it,
|
|||
|
|
or bookmark it.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> When he attempts to contact, this automatically buddies it and/or
|
|||
|
|
bookmarks it.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p> 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.<br/>
|
|||
|
|
<br/>
|
|||
|
|
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.<br/>
|
|||
|
|
<br/>
|
|||
|
|
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.<br/>
|
|||
|
|
<br/>
|
|||
|
|
Because of automatic blacklisting, to contact, you have to <i>exchange</i>
|
|||
|
|
keys.</p>
|
|||
|
|
<p style="background-color : #ccffcc; font-size:80%">These documents are
|
|||
|
|
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
|
|||
|
|
Commons
|
|||
|
|
Attribution-Share Alike 3.0 License</a></p>
|
|||
|
|
</body>
|
|||
|
|
</html>
|