Logging In Without a Password

I probably have hundreds of online accounts: email, discussion forums, social networking, online shopping, server hosting, issue reporting, etc. Trying to remember all the passwords is a pain. Often, when going to a site I haven't been to in a while, I just reset it, or have it sent by email, or have a new one sent by email, or however the site in question works.

I might want to try something different for Names on Nodes. As hinted at in earlier posts, users will be considered "authorities" in Names on Nodes, along with publications, bioinformatics files, specimen repositories, nomenclatural codes, etc. All authorities are associated with one or more unique URIs, such as website addresses, ISBN numbers, DOIs, LSIDs, etc. For users, the primary URI will be an email address, in the form <mailto:myname@somedomain.tld>.

Why have an account? Well, because then, as an authority, you get to "authorize" your own datasets and taxon identifiers (and, by proxy, taxon definitions). Datasets and taxon identifiers are "qualified" objects, meaning that they each refer to an authority, and they each have a "local name" unique under that authority. A qualified name is formed by joining the URI of the authority and the local name. So, for example, if you wanted to create a new phylogenetic hypothesis about mushrooms, it might have the qualified name <mailto:me@myemailprovider.com::dataset:basidiomycota+phylogeny>. If you wanted to provide your own definition for the name "Eumetazoa", it would be attached to a taxon identifier with the qualified name <mailto:me@myemailprovider.com::Eumetazoa>. And so on.

How do you log in without a password? I'm thinking of a system involving IP addresses, the numerical code that identifies your computer's connection. For most environments, these are relatively stable, although if you use, e.g., a DSL modem it may reset once in a while. Here are some potential use cases:

Initial Login

Preconditions.—User has never logged in. User's email is unregistered. User is 13 years of age or older.
Trigger.—User tries to do something that requires login.
Course of events.

1. User is prompted for their email address. They are also prompted on whether they want to stay logged in across sessions.
2. User is prompted for their birthdate, full name, and family name.
3. User gets a notice telling them that they have been sent a confirmation via email. The notice includes an input field for a "key".
4. User checks their email, and sees an email message with a link. There is also a "key", a string of letters and numbers that they can copy and paste.
5. User clicks on the link.
6. Names on Nodes reopens, with the user logged in.

Alternate course of events.

5. User copies and pastes the "key" into the input field.
6. User is now logged in.

Postcondition.—User's email and current IP address is registered. User can perform the action that triggered this use case.

Subsequent Login, Registered IP Address

Preconditions.—User's email is registered. User is not logged in, having logged out or having declined to stay logged in across sessions.
Trigger.—User tries to do something that requires login.
Course of events.

1. User is prompted for their email address. They are also prompted on whether they want to stay logged in across sessions.
2. User is now logged in.

Postcondition.—User can perform the action that triggered this use case.

Automatic Subsequent Login, Registered IP Address

Preconditions.—User's email is registered. User indicated that they wanted to stay logged in across sessions the last time they logged in.
Trigger.—User visits website.
Course of events.

1. User is automatically logged in, and their name is shown in a "Welcome" message.

Postcondition.—User can perform any action that requires being logged in.

Subsequent Login, Unregistered IP Address

Preconditions.—User's email is registered. User has never logged in from their current IP address.
Trigger.—User tries to do something that requires login.
Course of events.

1. User is prompted for their email address. They are also prompted on whether they want to stay logged in across sessions.
2. User enters their email address.
3. User gets a notice telling them that they have been sent a confirmation via email. The notice includes an input field for a "key".
4. User checks their email, and sees an email message with a link. There is also a "key", a string of letters and numbers that they can copy and paste.
5. User clicks on the link.
6. Names on Nodes reopens, with the user logged in.

Alternate course of events.

5. User copies and pastes the "key" into the input field.
6. User is now logged in.

Postcondition.—User's current IP address is registered. User can perform the action that triggered this use case.

Unregistering IP Addresses

Preconditions.—User's email is registered, and user is logged in.
Trigger.—User decides to invalidate other IP addresses, perhaps fearing someone else may log in as them from another computer.
Course of events.

1. User selects the "Block Other Locations" option.
2. User is prompted to confirm this request.
3. User confirms the request.
4. User receives notification that other locations have been unregistered.

Postcondition.—User's current IP address remains registered, but all others are not. User must now register other addresses again if they try to log in from a previously-used address.

I'm not sure if this would be too convoluted in practice, but somehow I doubt it. If anything, it seems no worse then the usual type of system, except possibly for people who use laptops and are constantly on the move.

What do people think? Ideas, questions, concerns?