RFC: Users

[dirkmc]

Users should have

• unique id
• set of private/public keys
• username
• avatar (optionally auto-generated from id)

These fields can be stored in an IPFS object referenced by an IPNS key Ideally keys can be abrogated, username is unique and dynamic

Usernames

Decentralized unique usernames are difficult as described by Zooko's triangle. Could be achieved using

• blockchain (eg Ethereum / Namecoin / Filecoin?) Relatively slow to create and requires spending some resources / money to get a username
• Federated model Similar to how email addresses work, where a username is attached to a domain eg [email protected] The domain takes care of ensuring uniqueness, authentication, and password recovery etc Domain is somewhat centralized
• Nicknames User chooses a username, and if there's a conflict on some page (eg two users with the same username make comments on a PR), UI highlights the difference (eg different avatars or colours) and possibly allows the client to assign her own nickname to that user. Spoofing can be somewhat mitigated by the UI using unique visual cues (eg auto-generated avatar, append shortened id to username)

Authentication

• hash(username || password) => secret key => IPNS key Username and password are static No password recovery mechanism or abrogation
• Federated model username@domain Authenticate against domain, responds with secret key => IPNS key Private key is kept at domain Username and password can be dynamic
• Attestation Public key is stored in some publicly accessible place with an associated username (eg keybase.io, github gist, tweet, blockchain) Username format is eg [email protected] or [email protected] Private key must be manually transferred between devices

[magik6k]

How about a model where user has 2 sets of keys:

• 'Account Key' - generated from entropy, kept locally (even offline), basically defines the account
• 'Name+password' - from hash(username || password)`

In this setup we should be able to change passwords, the hard part though is ensuring we can revoke access from the name+password keys. This could be implemented as a mix of blockchain (or federated, or with acl-crdt - https://github.com/ipfs/dynamic-data-and-capabilities/issues/25) and name/password key approach.

cc @pgte - Is there related research I missed?

[dirkmc]

@magik6k could you explain a little more what each key would be used for, and how to update passwords?

[dirkmc]

Ah I think I understand what you're saying - the Account Key is used as the "master", for example it is used to derive an IPNS key that points to an IPFS record containing the other keys.

Revoking access should be fairly straightforward if the other keys are stored with associated data indicating whether they are still valid (for example they may have expired or have been revoked)

For example let's say a user wants to sign a comment she has written on a Pull Request. The comment signature could be composed of cert sig + cert ref where

• cert sig is the cryptographic signature of the data using a Certificate key The Certificate key is derived from
  • username
  • password
  • create timestamp
• cert ref is the IPFS hash of a Certificate record The certificate record contains
  • username
  • create timestamp
  • expiry
  • (Account key).public
  • (Certificate key).public

The Account key derives an IPNS key that points to an Account record on IPFS. The Account record contains a list of tuples certificate IPFS hash / isRevoked.

In the case where a user wants to

• change their password They create a new certificate and add it to the Account record using the Account key.
• revoke their certificate They set the isRevoked flag in the Account record for that certificate.
• make changes to their comment from a different device They either
  • enter the username, password and create timestamp to recreate the certificate key
  • create a new certificate and add it to the Account record using the Account key (they must have access to the Account key on the new device)

The renderer of any signed data (eg a Pull Request comment) must

• Fetch the associated certificate
• Check if the certificate is expired
• Fetch the associated Account record
• Verify that the certificate has not been revoked
• Verify the Certificate signature over the data

This system depends on ensuring that the Account key is never compromised. This could be mitigated by having an expiry and renewal mechanism for the Account key.

[dirkmc]

I'm planning to read through a bunch of these for more ideas: https://github.com/WebOfTrustInfo/rwot7

[dirkmc]

The peer-star team are working on peer-star-identity which should take care of a lot of the requirements for Users on IGiS.

Unique usernames would still be an outstanding issue. Filecoin will likely have naming, or alternatively we could go with local names

[dirkmc]

With respect to the unique usernames issue, the handshake project is attempting to replace DNS root servers / zone files with a blockchain. The project paper mentions a strategy for mitigating squatting that we could make use of - they reserve the top 100k domains in Alexa for entities that can prove ownership using DNSSec (eg coke.com). We could similarly reserve usernames that existed before a certain date on github / twitter / etc for users who can prove ownership through verifiable claims (attestations). peer-star-identity will provide verifiable claims management for DID