I was looking at BrowserID which is an awesome decentralised authentication system that allows anybody with an email address to authenticate with a single identity. However, what if you don't want the service you are authenticating with to know your email address? What if you want several "single identities"? What if you want to be anonymous?
I've come up with a system which should help separate your personal identity from the account & data.
I pondered the idea of simply removing the email address from the User Certificate, but then I realised that the email address is essential for the RP (Relying Party, the service you are trying to authenticate with) to know which account the certificate relates to.
So then it hit me: just use Public Key cryptography (RSA keypairs, like SSH does) to authenticate. We will rely on the fact that you have the private key (and possibly also a password) to uniquely identify and authenticate you. Sure we could just use usernames and passwords for this (and never ask for an email) but that would be crappy. Why not build a system that supports encrypted messaging and supports secure management of keys from a personal repository?
Users can have complete control over what key repository they use - and users can use a single password for that key repository (or none at all!) to allow access and management for all their keys. Such a repository could be local or remote and could have any number of mangement features (at least key creation and deletion) and perhaps also provide APIs for existing authentication methods such as OpenID and OAuth.
But don't most web services also need your address to send you notifications? The proposed system also deals with that. Your private key could be used to encrypt notifications which can be thrown into a giant anonymous mixing bowl message store, or attached to an API endpoint (or PubSub node?) from which you can retrieve them and decrypt them using your private key.
The authentication process could go like this:
- A traditional HTTPS session is intialised.
- Client requests token encrypted with Public Key from RP (key selected by username).
- Client decodes encrypted token with Private Key and asks RP for validation.
- RP Accepts or Denies authentication based on if the decoded token matches the original unencrytped token or not.
This system has to be manageable and so nice keystore applications need to be made. Obviously, local keystores would be the most secure and anonymous but remote keystore services would be the most convenient. Wherever the keystore is located I think that the RP should not know where it is, as this may help give clues as to your identity (eg. "keystore.ddevnet.net" would be a dead giveaway).
To keep the location of the keystore anonymous, keys stored in a web application could be fetched for use in the login form using a JSONP AJAX request as a normal AJAX pattern would require CORS which would expose location of the keystore. Alternatively, if users used a browser extension to handle fetching/loading of private keys then the location of the keystore will not be discoverable.
This system also should be able to deal with 2-factor authentication (you have the key and you know a password) and I can't see why private keys can't also be password-protected client side as well. RP accounts could probably support multiple public keys so that users may have a recovery key option available to them. This key could be one which is kept offline for security reasons and off-site for disaster protection.
There are a few problems that I don't have answers for yet - but I know are dealt with in other authentication methods that I can research...
I am guessing that some will be wondering Why not use SSL PKI? - well that's because: