Working addressbook

The bikeshed is blue.

I have worked with Stefan and made this functional. I'll do some cleanup, documentation and work with Stefan on a "how to make all the moving parts work" but I wanted to get this in front of other people as soon as we can.
The key in there is fake data of a length thAt is interesting for barcode testing. 

I'll add a guid and fix what I broke this morning.  Then rerere view it with you ;)

Sent from mobile...

> On Jun 19, 2014, at 11:34 AM, yaronyg <notifications@github.com> wrote:
> 
> In Production/ThaliDeviceHub/apps/addressbook/js/app.js:
> 
> > @@ -0,0 +1,74 @@
> > +'use strict';
> > +
> > +var demoContacts = [
> > +        {name: "Rob Craft",     uniqueId: "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAgEAskOn5f/aRwWG8y+rcqhWLw5z7MBa3XRunle7PAYIfsMdnMjM71aBX+U7KEXR2PYhIrG5DKLvcB6X9tZy9AmEGS1+vLmKA7ldrmGHUVJNT0noesLSSXDe3vDe2fGxkpvYzbnptXhJsDzGa3A1nWfz9eBM8fqXNPWCgOcasmnTZFLvUydP95PGh2dtnT69aY6njdvSFCz7UJlGTmiEC8662R9x+lXVEvu0TZ5PpN6U3KgAF1p3AVPn2QAyWz0/oXoSWznpwf9N0DhMqqyChnDvgYzRsmO+YXyKuQ0mLAWGrZEu1g7+Z893LoD8tBZXr7FXAKQ1l80OuaTsMV7kvK2+jeNLRcddwPHLx1FGphwgH7M1ZkESyy1oq8qgzZ4/SHZeJC//SH+HIEFWus+cigH3xXKFrpa/iNv4j32eWl7qOvr1pb4m3wiE7dCIcLBT5QyBsvcbk085LfeavaE0VAvLp001GhFq6ABxGneDcSfXK6mTckNbfS9/xzU1sYu1NaZ8h+PcvasDB8Kr1epSApnIHlh1t4HyiEXYzvhffMTMh3UTiGZKcqYXNb06p1W7V6uhO5TtKTFulF7jKt1/4NTh/aGUGz8hq2ZOOz82RZsK4rTuEM7H42Hg2vyNs47STHCJGqNoV/jWbml2sb52fySDkkbt937SKke0JzvJMZGtp0E= rsa-key-20140610"},
> A couple of issues here.
> 
> Issue #1 - What is ssh-rsa?
> Issue #2 - It looks highly likely that a single user will have many keys. Imagine I set up my phone. It will generate an identity key for me and a device key. It will then (ideally in an offline process we haven't written yet) use the identity key to create a cert for the device key. From that point on the phone will only use the device key on network connected processes but will root up to the identity key. So we really just care about the identity key. It is the identity key that would be in the address book. Let's call that Identity Key - IDm (identity mobile)
> 
> Now imagine I buy a tablet. What identity key should be on the tablet? Remember, it's super bad mojo to ever move private keys on the wire. So one thing you could do is have the tablet create a device key and then send the public part to the mobile who could sign it with IDm. This will work but what happens if the mobile falls in the toilet? Now the user has lost their identity because the private key only exists on IDm.
> 
> So our thinking is that instead what we would do is when the user buys the tablet they will generate IDt. So now they have two different identity keys. But then each key would create an attestation (a signed doc, but this isn't actually a cert because it's not used in the SSL connection) that the other ID is the same person. In other words IDt says "I certify that IDm is the same person as me" and IDm says "I certify that IDt is the same person as me". This list of keys would then be put into a document in a database.
> 
> So now the identity exchange looks like:
> Step 1 - A user (say on their phone) tells the address book to display their QR Code. This would show IDm. It would also show the device's current onion address.
> Step 2 - The friend of the user uses the QRCode to capture IDm and uses the onion address to create a connection to the user's mobile phone. They would then sync the user's "about me" database. That database would contain an identity record which would contain a set of assertions. This creates a trust train. The friend knows they trust IDm (because they got it in step 1) and so when they see in the 'about me' database the assertion from IDm saying that IDt is the same person now the friend will also trust IDt.
> 
> Which means that we need to be able to have a single entry in the address book that is associated with multiple keys.
> 
> So what does any of this actually mean?
> 
> First - Each user should have a GUID that we generate locally to identify them. That way we can keep identifying them as their keys change (even if you have only device you still need to roll over your identity key every once in a while so an identity can and will end up associated with multiple keys no matter what).
> Second - We should change the structure so it can store a set of different identity keys.
> Third - Oh and um.... well.. then there are Tor Hidden Services. The problem with THS is that for reasons I can explain elsewhere we MUST use a unique (different) key for each device's onion address for Tor Hidden Services. So this means that each device will have a pair, an identity key and a Tor Hidden Service address. So each identity key needs at least a tuple, the identity key and the Tor hidden Service onion address.
> Fourth - You could potentially simplify the hell out of things by just generating the GUID to identify the user and then storing a set of httpkey URLs. That encapsulates both the user identity key and the onion address in one nice little package that all of our code knows how to handle.
> 
> As a side note (because obviously this comment isn't nearly long enough) it's tempting to argue that we should use the Pet Name as the index for each entry since Pet Names are required to be unique in the address book. But this isn't a great idea because realistically Pet Names can be changed. "Bob from work" can become "Bob from my old work". Hence the need for the GUID.
> 
> —
> Reply to this email directly or view it on GitHub.