IDENTITY INITIALIZATION ======================= 1. A user name and password is requested. These credentials will be used by the user to login as the owner of the identity. 2. A URI consiting of the site root name followed by the user name as the last component is assigned. This is an internet facing web address that the user has control of (possibly through a service provider). It represents their identity. 3. An RSA key pair is created. The key has no passphrase. 4. The public portion of the key is made publically available. The key must always be fetched using SSL. This guarantees that a key has been provided by the server hosting the identity and has not been tampered with. OWNER LOGIN =========== User submits credentials via a web form underneath URI and recieves a session cookie that indicates to the server that the user is logged in. FRIENDSHIP REQUEST ================== The person requesting friendship is the friender, with identity URI. The person who is receiving the request is the friendee, with FR-URI 1. The friender fills in a friend request form at FR-URI a) friender answers a challenge (generic CAPTCHA, or personalized) b) friender submits URI 2. Friendee server processes the request: a) verifies challenge response b) fetches the public key for URI (using SSL) c) randomly generates a one-way relationship id (REQUESTED-RELID) d) randomly generates a one-way request id (REQUESTED-REQID) e) encrypts REQUESTED-RELID to friender and signs it f) makes message available to be fetched using REQUESTED-REQID to identify it g) redirects the user's browser to https://URI/return-relid?uri=FR-URI&reqid=REQUESTED-REQID 3. Friender server processes the return-relid request: a) verifies browser is logged in as owner b) fetches public key for FR-URI (using SSL) c) fetches encrypted REQUESTED-RELID from FR-URI using REQUESTED-REQID d) decrypts and verifies REQUESTED-RELID e) randomly generates RETURNED-RELID f) randomly generates RETURNED-REQID g) encrypts "REQUESTED-RELID RETURNED-RELID" to friendee and signs it h) makes message available at to be fetched using RETURNED-REQID to identify it i) redirects the friender to https://FR-URI/friend-final?uri=URI&reqid=REQID 4. Friendee server processes the friend-final request: a) fetches encrypted RETURNED-RELID using RETURNED-REQID b) decrypts and verifies message, must contain correct REQUESTED-RELID c) stores request for friendee to accept/deny FRIENDSHIP ACCEPT/DENY ====================== The next time the friendee logs in they are presented with the friendship request. They can either accept or deny the request. The acceptor sends accept notification with both relids. They are sent back indicating that the friendship was registered on the other end. The acceptor then registers the friendship and sends a registered message. It can can now send broadcast key and broadcast tree insertion messages. The other end can send these messages after it receives the registered message. PUBLISHING TO FRIENDS ===================== 1. Broadcast Encryption Keys ---------------------------- Use a broadcast key. Gives the sender some control over who can read broadcast messages. Requires sending out session keys ahead of time. This does not stop a bad friend from forwarding a session key. But the protocol doesn't have this feature. Session keys must be signed. 2. Distribution Tree -------------------- The most simple approach is to iterate through your list of friends and deliver broadcast messages. However, a large number of friends multiplied by lots of activity results in many messages. To mitigate this cost a user's set of friends is organized into a complete binary tree and broadcast messages are forwarded through this tree, resulting in log n steps to distribute a broadcast. Doing this means that each of your friends must know the server at which a couple of your other friends have their identity hosted. This revelation does not cross friend-partition boundaries, however. It is a minor weakening of the claim that your friend list is private. This reduces the time to get messages out, but complicates matters when a node fails to forward a message on behalf of a friend. The approach I'm considering is to send acknowledgment messages back up the tree of friends and back to the originator as confirmation. If the ack does not arrive back in time there is a distribution problem that needs to be corrected by discovering the faulty node and removing it or swapping it with a leaf node. The message can then be rebroadcast. A faulty node can be reported to the originator at the point of failure, either due to a timeout, or an inability to connect. 3. Tree Generaion Numbers ------------------------- To speed up the distribution of messages, a user's list of friends is organized into a tree. Each friend forwards broadcast messages on to other friends. This requires that there be agreement on the correct structure of the tree among a user's friends. Friends do not need to have a view of the complete tree, just their children. Another way to view the issue of agreement is that all operations that modify the friend's view of the tree need to be atomic across all friends that are involved in the modification. A message that passes through the tree must either see all of a change or none of it. When adding a member to the tree this is easy, the new member is added as a leaf node and just one node (its parent) needs to be modified. When removing a node from the distribution tree there is more than one modification that needs to be made among the friends. To ensure that these modifications are atomic, I am using a tree generation number. Each broadcast message carries with it the generation of the distribution tree that should be used to propagate the message. When the tree is modified, the generation number is incremented. Friend nodes that are modified keep the old tree generation data around during the modification process and continue to use it for any messages that arrive with the old generation number. When the changes are complete, new messages are sent with the new generation number, making the new tree effective. While this gives us atomic operations, it has the unfortunate property that all nodes need to have their generation number updated even if they are not involved in an update to the tree. To get around this, friends do not look up the exact generation number of messages to find forward information, but rather the youngest generation that is less than or equal to the generation number of the message. This lets us avoid updating the generation number with every friend. ++NOTE: Doesn't this break the whole guarantee in the first place? since then if someone was supposed to have had their number updated but hadn't yet, and recieved a message with the old number, then they would pick their highest number, which would be wrong.++ 4. Roles and Friendship Types ----------------------------- The different roles poeple play in their lives are often reflected in a categorization of their relationships. It would be useful in DSNP to support friendship categories. Each category should have it's own broadcast key and the distribution trees should not be disconnected. The categories should not necessarily be comprised of disjoint sets of friends however. Your brother can be both in your friend category and your family category. You grandmonther, however, can just be in your family category so you can shelter her from the details of that crazy weekend in Montreal. LOGIN AS A FRIEND ================= This allows people to login to a friend's page to see the content that has been summarized by their feed. It is an open-id style login. User: URI, RELID Friend: FR-URI, FR-RELID 1. User fills in a login-as-friend form a) User visits https://FR-URI/login-as-friend b) submits URI 2. The friend's server processes the request. a) verifies that URI is a friend b) randomly generates a token c) encrypts the token to the user and signs it. d) makes it available under to be fetched with FR-RELID as identifier e) redirects user to https://URI/return-token?uri=FR-URI 3. The user's server verifies the user owns the identitiy. a) checks that FR-URI is a friend b) if browser is not logged in, fails the process (possibly with redirect to loging screen) c) fetches the token using from FR-URI using FR-RELID to identify it d) decrypts and verifies the token e) redirects the browser to https://FP-URI/submit-token?uri=URI&token=TOK 4. Friend login final a) Verifies (URI, TOK) b) grants friend credentials to the browser using cookie-based session. CHARACTERISTICS =============== Your list of friends can be treated as private information. It is impossible for someone to probe your list of friends if you don't want to publish it. The list must be explictly granted, even to current friends (see next point for a minor exception). This makes it possible to partition your relationships into differnet groups, such as family, close friends, co-workers, and people you hardly know but might like to get to know better. The user must trust the server that is hosting their identity. But like email, blogs, and other forms of internet identity, we are free to choose our service providers and the truely paranoid and technically inclined are free to host their own identity on their own server. Perhaps a more difficult problem is that the user must trust the server that is hosting their friend's identities. However, this is not a problem unique to DSNP. This is true of email as well.