Userlist

Simple identity and signing.

Q: What does userlist enable?

• Nearly-free permanent verifiable identity
  While initially a domain name and basic hosting is required, as identity providing domains begin to adhere to the userlist spec and allow registering usernames, the system will become nearly free.
• Website registration without exposing PII
  Unlike email and phone number, which can likely be traced to PII, userlist does not require anything that cannot be done nearly ( or actually ) anonymously.
• Air-gapped identity
  Userlist is designed to make the use of identities stored on air-gapped devices doable. By allowing subkeys to be used, root keys can always be stored in an actually secure fashion.
• Website login fully owned/controlled by the user
  Unlike most federated login systems ( such as any of the "login with" systems ), userlist is completely controlled and owned by the users of the system.
• Fully open / decentralized
  Userlist isn't controlled by us ( userlist.org ) beyond publishing of the spec itself and example code. Anyone and everyone is free to use it, and it is designed that there is little to no benefit for any company ( or companies ) to attempt to control it. This is part of what makes and keeps it free.

Userlist is a simple solution for user identity and content signing. It is designed to replace the need for email or phone number in order to prove identity / ownership of an account. Both of those are suboptimal because they are very expensive and complex to exist and verify.

At the core, a userlist identity is just a ed25519 keypair. In order to identify a keypair, a username at an internet domain name is used, similar to email but without the overhead of an email server.

To create a userlist identity, the following can be done:

1. Register a domain name ( ex mydomain.com )
2. Create an ed25519 "owner" keypair
3. Setup https for your domain
4. https serve the public key of your keypair at https://mydomain.com/userlist/owner

How should user keys / records be server? They should be served as a block of JSON:

    Served from https://mydomain.com/userlist/owner:
    {
      "user": "owner@mydomain.com",
      "keys": [
        {
          "key": "54D78DE...",
          "valid": [ [2022,1,10], [2023,2,5] ]
        },
        {
          "key": "54D78DE...",
          "valid": [ [2022,1,10], [2023,2,5] ],
          "sig": {
            "signer": ":0",
            "sig": "54D78DE..."
          }
        }
      ]
    }
    
    Served from https://mydomain.com/userlist/bob:
    {
      "user": "bob@mydomain.com",
      "keys": [
        {
          "key": "54D78DE...",
          "valid": [ [2022,1,10], [2023,2,5] ],
          "sig": {
            "signer": "owner:54D"
            "sig": "54D78DE..."
          }
        },
        {
          "key": "54D78DE...",
          "valid": [ [2022,1,10], [2023,2,5] ],
          "sig": {
            "signer": ":0",
            "sig": "54D78DE..."
          }
        }
      ]
    }
    

The first key for any user will be called the "root key". Keys beyond that will be called "subkeys".

Multiple keys are allowed so that the root key can be kept as protected as possible, preferably on an airgapped system ( such as an old phone with no network access ). Keys beyond the first are all signed by the first key, and their periods of validity should be kept shorter so that if a key is exposed it can be discarded.

The period of validity for the root key is only present to tell caching systems when they should discard that key and re-fetch a new one from the source.

Systems should continue to accept root keys even after their valid period has passed, as there are situations where a domain may be down or access to download an updated root key is not available. If we demand that root keys past validity must be expired, this enables lack of network access to break validation after a time period.

Owner of a domain has the following permissions / responsibility:

• Can issue users at the domain
• Signs root keys of users at the domain

A user has the following permissions / responsibility:

• Always provide their identity along with the domain owner signing of it
• Can issue and use subkeys. Any such subkey, when used, must be provided in a form signed by their root key.