|
This comes down to the contention between, using the terms I'm going with, a Customer and a User. Let's say you're logging into soawesome.com as a User of soawesome.com. That makes soawesome.com the "Customer", and you the User. Just to setup some terms. Also, let's say I'm not picking on OpenID but really any of the "redirect based" auth methods that transfer ownership of users to a 3rd party. The difference in design is that OpenID assumes that the Customer is less trustworthy than the OpenID Provider+User. They've done a good job marketing this idea that you can't trust sites and so you, the User, should use OpenID. If you think about that it's kind of idiotic to assume that you're going to log into an untrusted site using another site (which could also be untrusted). It also assumes that most web users are savvy enough to know what this is, but if you were up on the ReadWriteWeb/Facebook fiasco you know most users can't tell their ass from a hole in the ground. OpenID is just confusing to them. The truth is, if I can phish and XSS one site I can do it to another site. If someone can hack soawesome.com, they can hack your OpenID provider of choice too. All the attacks you have against one auth system apply to all auth systems because security in the browser is fairly broken. It's really completely a usability problem, and no amount of redirecting and bouncing around with crypto is going to solve that. However, this mistrust of the Customer means that there's a huge risk for the Customer against the Provider. At any moment the Provider can decide they hate the Customer and turn off all the users. This actually happens often enough that it worries people to the point they put links to about 10 OpenId sites. I'm trying to offer a solution that assumes the Customer is trusted and should own their Users, but that gives them a simple enough setup process that it competes with OpenID for simplicity of configuration (which isn't hard because OpenID is a pain in the ass). It should also give the Customer plausible deniability on password storage so, in the event of a breach, they don't lose anything. I'm also focusing on making this mobile/desktop device friendly, something that OpenID and OAuth totally fail at. This Customer v. User contention is the most likely the point of contention you have in your comment: you believe you own your user account, but customers believe they own it. I'm actually not sure what's the answer, but autho.me is kind of an experiment in doing it the other way. |
[edit]PS. Also, on a different subject, just to see if I got autho.me straight: in the SRP protocol description [1], autho.me would be Steve, correct?