Diarmuid

I know it is not as secure, that you have to have an accessible email account, and that people are annoyed by spam, but I think for the VAST majority of sites out there that are just run of the mill, log in to make a comment, or leave a bookmark or whatever, it would be fine. I don’t mean do your online banking with email or “authmail” as I’m calling it (copyrighted in 38.5 countries).

BTW, this was my first use of digg ever. I had to sign in and wait for the verification email to my yahoo account. It was at least 2 minutes!!! Kinds of deflates my argument a bit. Still the user could indicate when they authenticate how long the cookie is to last for, so that might only have to be once a month or however long the user wants.

I have ordered 3 ruby on rails books from Amazon, so when I get those I’ll start on the website.

Thanks again for the comments

Diarmuid

It’s vulnerable to attack since email is typically neither encrypted in transit nor authenticated, so it’s possible for an attacker to see the plaintext of an email intended for another person just by running a sniffer and then access the login URL, logging in in their place. Ability to read unencrypted email traffic is no indicator that you are the legitimate owner of the account in question. Even trying to mitigate this risk with PKI would complicate matters since you need to verify your public key to the site you want to log into anyway. This is equivalent to the very problem we’re trying to solve.

Ultimately though your solution is actually too complex, since what you’re proposing is out-of-band authentication, you authenticate for web access with email access. What if you’re browsing the web somewhere where you don’t have access to your email? To log in to a website, you should only need access to the web. Many email providers offer webmail, but many don’t. Email delivery often has high latency as well, so you could wait 5-10 minutes to log into a website.

This also assumes that the website you’re trying to access has a hosting provider that lets them send email, probably not a good assumption. With OpenID you don’t need to do anything but be able to run scripts on your webhost to authenticate your users, certainly something which is already a prerequisite to offering the service itself that users are authenticating to.

1. In order to use it, it’s required that the use have an access to an e-mail account (and, preferably, to the one he/she would like to have registered with the service). This immediately cuts off several huge segments of users – for example, corporate users who cannot open a web-based email on their work PC, and who don’t want to use their work email on the site.

2. The solution requires that every time I have to log in to some site I have to receive a useless e-mail message, which I would have to manually delete afterwards. I don’t want this extra effort.

3. In my opinion, email accounts are less secure than standalone OpenID accounts.

Anyway, interesting reflexion.

So, in your example…
1. You go to iwanttousethiswebsite.com
2. User types in their OpenID URI
3. User is redirected to their OpenID URI
4. User types their login / password / whatever information (not standardized)
5. User is redirected to iwanttousethiswebsite.com with an authentication token
—

Now, if they want to go to iwanttouseadifferentwebsite.com, they don’t have to complete step #4, so steps 3 and 5 happen _very quickly_.

Now, I’m not sure if this is actually how it works, since I haven’t started using OpenID for anything, but this is in general the idea behind other SSO approaches.