Identity - Modifying the Guest-List

[joaosantos15]

This issue tracks a modification to the PR #9 which deals with Peer-Identity.

Problem

In the following paragraphs of the document, a Guest List is mentioned.:

Next, in step 3, Bob generates an access key for Alice for document pp-doc-12345. This is done by encrypting the document’s keys [readKey,writeKey] with the temporary public key generated by Alice. Finally, Bob adds the access to the document’s guest-list. The guest list is a data structure kept in a CRDT embedded in the shared document (a CRDT is being used here to allow concurrent edits).

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.

This guest list would be a permissionless data structure where new users could write requests to access a document, and users with access could provide access to new users.

In a discussion with @satazor and @pgte , it became evident that this guest list was vulnerable to DDOS attacks. This is the case because anyone with access to the document's ID (which is the pub sub topic) could write arbitrary data to the guest list.

There was a desire to pursue an alternative where new users could make requests even if old users were offline. A new user who wanted access would place a request for access to the guest list. Later when a user with document access came online, he could analyze the requests in the list and decide whether or not to approve the requests.

Solution

We were unable to find a solution for offline access requests and grants which relied only on peer-star infrastructure (there were ways of doing using off-band communication).

We updated the access requests and grant procedure to one that works when both parties (user requesting access and user granting access) are online. This solution uses pub-sub. And works the following way:

1. Alice knows the document ID (Bob might have shared it via email or through some other channel), and joins the pub-sub channel.
2. Alice publishes her presentation package.
3. Bob is listening on the channel and notices that a user whose DID is known to him (Alice) has posted a presentation package requesting access to the document.
4. Bob proceeds to generate an authorization for Alice (as described in step 3 of the excerpt at the beginning of this issue) and sends it directly to Alice, using libp2p.
5. Alice decrypts the document's keys and can now access the document.

The problem with this design is that the pub-sub channel is also vulnerable to DDOS. This can be solved by using a separate pub-sub channel which can be flagged and updated in the case of it becoming a victim of DDOS. Users with access to the document would elect a leader and create a new pub-sub channel for access control.