docs: Adds Peer-Identity document and images

[joaosantos15]

A proposal for an identity protocol to be used by peer-star applications. Peer-Pad is used as an example.

Pending:

• Avoid using passphrase (@satazor) Tracked in Identity - Using passphrase to generate temporary Key pairs. #10
• Change the terminology to match W3C's DID Spec. https://w3c-ccg.github.io/did-spec/#terminology (@pgte)
• Open a discussion as to what proofs of personhood should be, and which ones should be accepted in peer-pad identity. (@pgte) Tracked in Identity - Proofs of Identity and Verifiable Claims #11
• Add a chapter discussing how key rotation could be done. (@pgte) Tracked in Identity - Key rotation/recovery #12
• Complete mechanism of providing access to peer-pad document.(@pgte) Tracked in Identity - Modifying the Guest-List #13

[pgte]

This is a RFC, containing the snapshot of recent in-person discussions between @diasdavid @satazor and me. We're putting this out there as soon as possible so that we can discuss and iterate on this in public.
Thanks for this @joaosantos15 !

[satazor]

Next, in step 4, Alice retrieves her authorization from the Guest-list. She decrypts the message using TemPrivKeyDoc-Alice, and extracts the documents read and write keys. The TemPrivKeyDoc-Alice is generated using a user defined passphrase as a seed. This means that the user can reconstruct the private key, regardless of the device she is in

Regarding using a passphrase to generate the TmpKey:

The issue with a passphrase is that a malicious node may try to guess the password of a entry in the guest-list via a brute-force attack. The attacker has access to the guestlist because it's public. A successful guess would give access to the document keys, exposing the document contents.

I propose a different approach:

To request access, Alice would send her presentation package (DID + pubkey + pubkey signed with root private key) as well as the document id signed with her device's private key. After Bob verifies the authenticity of Alice as described in Step 2, Bob generates an entry in the guest-list for each one of Alice's devices present in his Address Book, by cyphering the document keys with each device's public keys.

If Alice tries to access the document in a device known to Bob, the access would be transparently given. But for a device unknown to Bob, Alice would not be able to retrieve the document keys because there's no entry for that device in the guest-list. Still, Alice could use one of her other previously authorized devices to authorized herself. This could be done in a nice UI/UX where we make it clear to Alice that her device hasn't yet been authorized but she can do so.

This solution does not have the downside of using passwords. In the best case scenario, Bob generated an entry for all of Alice devices and she is able to access the document in all of them. In the worse case scenario, Alice must "self authorize" all of her other device with the one authorized by Bob.

To further improve on this, Alice could have a list of devices associated with her DID. This would allow Bob to generate an invitation to all of her devices, hence always achieving the best case scenario. Still, new devices would have to follow the "self authorization" mechanism previously described.
Another improvement on top of the previous one, is that Alice could optionally and selectively enable the replication of keys that unlock resources. This way, any resource previously accessed in a device would be made available to any of her devices that have replication enabled. This would be useful to any kind of resources, like a peerpad document, a kipster page, etc. This would be a opt-in feature that would improve the user-friendliness but reduce security. I will create a separate issue in order to further elaborate on this.

[satazor]

Here's a small improvement on the paragraphs after the "DID resolver" image. I've just changed a few in things the initial phrases.

---

The entity in control of the identity has a pair of keys that should be stored in a secure endpoint. This can be viewed as the identity's root keys.

In the image below, Alice's root key is the same as her Ethereum account. The root public key is placed on Alice’s Ethereum Smart-Contract (in the image, Alice’s Smart-Contract), which is her DID-Document. Alice’s proofs of personhood are also maintained in the smart-contract (to reduce costs, the proofs can be pointed to using an IPFS link). Additionally, the root private key is stored and accessible in MetaMask.

Key point: At this point, anyone who verifies Alice’s proofs-of-personhood - that is, anyone who is convinced that Alice is indeed the owner of that smart-contract and has the identity she claims to have - now knows that PubRoot-Alice is Alice’s root public key.

Alice may wish to be able to authenticate herself using different devices. Currently, users of services such as Google Docs, are able to seamlessly use the services across all of their devices. The same should be possible with Peer-Identity. To achieve this, we propose a mechanism for device authorization depicted also in the image below. Looking at the case of authorizing a new smart-phone, she generates a new keypair for the device (the keys are generated locally in the device). Next, Alice uses her secure endpoint to sign the new public key, PubSmart-Phone-Alice using PrivRoot-Alice. The set of PubSmart-Phone-Alice and signature(PubSmart-Phone-Alice)PrivRoot-Alice is called the Presentation Package. Each device will have its own presentation package.

Key point: The presentation package is used to authenticate any device. Any entity can verify a presentation package, by checking the device key was signed by the user’s root key.

[joaosantos15]

Should we create issues to track the pending topics? I feel like most of them will involve some discussion.

[pgte]

@joaosantos15 yes, we should do that.

[joaosantos15]

Moved to #15