A centralized authentication system designed for extreme ease-of-use to the end-user, and sufficient ease-of-implementation to the developer that he will want to use it as his only authentication system.
I hate logging on to multiple websites and I hate creating accounts and I hate keeping my passwords straight on all of them. It's very hard. Other users hate this too.
Yes, countless ones. This one's easier (on the users, and the Devs), and tries to do alot less. For instance, it's centralized, rather than distributed. It does not purport to define what the user is - not even their name. If you want that information for your application, you'll have to ask the user for it.
Passwords are MD5 encrypted in the system - so if someone breaks in, your passwords are at least safe.
In the event of a security 'incident' the public/private key can be changed. This would require that the developers download the new public key. We may wish to specify versioning information in the initial 'login' screen and choose public/private keys based upon that.
The cryptography used is pretty strong, and should be impossible to break with current technology. Again, if it does become feasible, the key can be changed.
Small goals - since the system only purports to tell you that the person you're dealing with is the person they claim to be, there's less of a security 'footprint' to manage.
Some possible exploits, and considerations -
You could concoct a misleading page and direct a user to log in - the url parameter could be set to some other site entirely, which the user hadn't intended to log in to, and now they're logged in.
Yes. Make sure a login has no side-effects - you can't be 100% sure that the end-user intended to do it. Another site could 'trick' them into it. Only use the url parameter to ensure the user is where they say they are, don't really rely on it for anything. Store any state for the user in the session for your server and website. The system requires an extra 'click' on login, and that is to ensure that the user has intended the action.
Phishing can become a problem - hence the avoidance of iframes (thus far) for login info. Also SSL with Real Certificates. edit - an iframe based model has been created.
What if you forget your email password?
What if you wanted to integrate this system with email - how can you have an email system authenticate! (extensions to API I guess, HTTP connections...)
It's so tenuous without much passwordery - someone's going to forget their password, and their email address will be not theirs anymore, and will be up a creek...And there' sno addiontal data to validate you - DOB, SSN, address, etc...
We won't disclose, sell, lease, or otherwise do anything with your email address. It's just how you're uniquely identified.
This service does not cost anything to anyone at this time. It's very unlikely it will - because if it did, developers would replace it with something that was free.
This is the hard one - why use an external service for authentication instead of building it yourself? At least if you build it yourself, you can be sure it will stay up - and if it's down, it's your own fault. The answer - first off, we intend to be reliable with redundant routing and such - but utlimitately, it's still out of your hands. It's important to note that an outage would only prevent new logons, not invalidate or change the people who are already logged in. And the end result is that if you think this level of service has utility, and can afford to pay the pric of less control, you should do it, but it may not be right for everyone.
I dont' yet know how to handle a 'logout' event - it should (maybe?) log you out of all of your signed-on-to web applications, but that's non-trivial to do...we'll ahve to see.