Support account recovery via email? (email uniqueness)

[dmitrizagidulin]

Context

Account Names

A User Account is what gets created when a user goes through the signup process on a Solid server running in Multi-User (identity provider) mode.
A user account typically:

• Has its own subdomain (e.g. alice.databox.me). In that example, alice would be the account name -- uniquely identifies that user on a given provider.
• Has a corresponding WebID Profile and root storage

Also, (at least on node-solid-server), you can discover a user's WebID URI given their account domain name (see nodeSolidServer/node-solid-server#359).

Account Emails

The Signup app prompts the user to enter an account name, but also an email that's associated with the account, and used for account recovery. These are stored in the account's root ACL resource (e.g. https://alice.databox.me/.acl), as a statement acl:agent <mailto:alice@alice.com>.

Account Recovery

The Account Recovery page currently prompts the user to enter their account name. It then constructs and loads the root .acl, parses the account email out of it, and sends them a recovery email. (This is either to recover their WebID-TLS certificate, or in the upcoming WebID-OIDC feature, to recover their account passwords.)

If the account does not have an email associated with it (and stored in its root .acl), it cannot be recovered by the user (they must contact the service provider out of band).

The Problem

What if the user forgot their account name? (This has happened several times in practice, on databox). Should we support account recovery by the user entering their account email (if they forgot their account name)? This is basically the ubiquitous 'Forgot your username?' link on login pages everywhere.

If we do decide to support that functionality, we will also need to Enforce the uniqueness of account emails. Specifically, an email has to resolve to a unique user account. (Otherwise, if multiple accounts have the same email, how will the server know which account to send a reset link for?)

The other issue influencing whether or not we should enforce email uniqueness is the upcoming WebID-OIDC integration (which will involve users signing in with a username and password as one of their authentication options). If we are to support user logins with either emails or account names (as is the case with most modern service providers -- Yahoo, Google, Twitter, Facebook, Github, Dropbox, etc etc), we will also need to enforce that an email resolves to only one user account.

Open Questions:

• Should we support 'Forgot your username?' or Account Recovery via email functionality?
• Should we support 'sign in with your email' (in addition to 'sign in with username')?
• (If the answer to either of those two is yes, we will need to enforce email uniqueness for accounts.)
• If we do enforce email uniqueness, what is the server-side API for a Signup app to check whether an email already exists? (Similar to the way it currently checks whether an account name exists).

[tomasklapka]

If someone wants to register multiple subdomains it could be noted that with plus sign in email address it is possible to have multiple unique email addresses with a single mailbox (not all mail servers support this).
In a signup app there could be an option to enable comparing of addresses with stripped tags. Storage providers might want to restrict uniqueness to this level of a mailbox.

[dmitrizagidulin]

Ahh, good point. So then, uniqueness would only be needed in the case of oidc login with email (instead of username).

[timbl]

First of all , I would challenge an assumption..in """If we do decide to support that functionality, we will also need to Enforce the uniqueness of account emails. Specifically, an email has to resolve to a unique user account. (Otherwise, if multiple accounts have the same email, how will the server know which account to send a reset link for?)"""

a) Many users may end up with multiple accounts especially during testing and asking people to experiment.
b) You can either in the UI say "You have more tan one account, which one do you mean", or you can just send account recovery emails for each account.
c) When a used has more han one account, it is useful for them to be able to keep track of them. They may also need prompting that they have >1 and given an easy option to delete the one they don't use. They can end up with more than one because something in the account creation process prevents them from actually getting back confirmation that the account exists - like they get disconnected, or distracted, etc,

[timbl]

And yes I think we should provide login with email or username. That is the current thing to do. A username is faster for people who do it all the time, a email is easier for people who do this occasionally and can't keep track of all their usernames easily of their many accounts.

[bblfish]

What usually happens is that if one has a login with email then one gets a username/password to login to that server. In that case, in order to make things as machine friendly as possible, it would be good to have a username/password access control mechanism. There exists one already in the HTTP-Standard, namely WWW-Authenticate in Basic and Digest form. But it would be nice to be able to work out how to tie this correctly into the WAC ontology.

So for example, and as a first thought, one could have an ACL that is read only by the user of the password that contains something like

[] acl:accessTo <>;
   acl:mode acl:Write, acl:Read;
   acl:agent [ 
       foaf:account [ 
              foaf:accountName "alice"; 
              foaf:accountServiceHomePage <http://alice.databox.me/>;
              passwordHash "cafebabe" // <- probably not the right place to put this
         ]
      ].

For the password one could either:

1. store the password in a password file the way servers do it currently
2. or perhaps as shown above put it the ACL or even better link to it? In any case, as that password is a symmetric key, that file should ONLY be visible to the owner of that password.

Even if 2) does not work out, it would be good if a client on reading the ACL (when allowed) could work out that it can access a given file with a password.

First the client would know that he can log in with a password, because in addition to other modes of authentication, the server would return a WWW-Authenticate: Digest header in the 401). Then he could work out from the acl for that file (if it is readable) that the user allowed access to him because that user has that foaf:account and he has a password for that foaf account.

Perhaps this should be developed in its own issue... Let me know.