not a complete pic: "... already outsourcing your security"
Posted by
Leo
at
2007-10-02 01:50
Hi there,
Interesting article, and interesting first comment. It seems to me that is perhaps exactly why OpenID seems primarily used for blogs or other such "non-critical" (...you can argue anything, but bear with me) services. For example, to use online banking, or even PayPal/other such things, a little more verification of who you are than just an email is required. Where the value of the service is high - such as a paid service, or even a financial service, email just doesn't suffice. Email does suffice to get other things.
I'm looking at OpenID as potential for SSO, primarily because I think there is something really backwards in most online apps; however as I come near to actually using OpenID (I'm experimenting with it) - I find myself beginning to see it a little pointless in my case...:
- I don't trust some arbitrary OpenID server to tell my web app "this is John Smith (or at least that's the id he's choosing to release to you... or she for that matter...)
- So, I think, use a whitelist... but then the value is reduced to the user having an OpenID url (which I control, so I trust) - this is 1 piece of info instead of a user/pswd combo; but wait - user will now need some way of authenticating (probably a user/pswd), so really we end up with 3 pieces of info, all this really just to get SSO. No benefit.
It really seems more suited to two scenarios:
- "non-critical" services, such as free blogs, email account, etc.
- Internally used by huge enterprises where multiple logon is occuring within same or partnered companies/organizations/divisions and so this could reduce the shear number of logins a user would have to go through (if, say, everyone in the enterprise implemented authentication & authorization the same way & perhaps didn't even ask for the OpenID URL unless the domain changed where user surfed to).
Am I just not seeing something? I was really pumped about it, but it doesn't solve the problem (10's of emails/pswds/usernames/logins and security).
Interesting article, and interesting first comment. It seems to me that is perhaps exactly why OpenID seems primarily used for blogs or other such "non-critical" (...you can argue anything, but bear with me) services. For example, to use online banking, or even PayPal/other such things, a little more verification of who you are than just an email is required. Where the value of the service is high - such as a paid service, or even a financial service, email just doesn't suffice. Email does suffice to get other things.
I'm looking at OpenID as potential for SSO, primarily because I think there is something really backwards in most online apps; however as I come near to actually using OpenID (I'm experimenting with it) - I find myself beginning to see it a little pointless in my case...:
- I don't trust some arbitrary OpenID server to tell my web app "this is John Smith (or at least that's the id he's choosing to release to you... or she for that matter...)
- So, I think, use a whitelist... but then the value is reduced to the user having an OpenID url (which I control, so I trust) - this is 1 piece of info instead of a user/pswd combo; but wait - user will now need some way of authenticating (probably a user/pswd), so really we end up with 3 pieces of info, all this really just to get SSO. No benefit.
It really seems more suited to two scenarios:
- "non-critical" services, such as free blogs, email account, etc.
- Internally used by huge enterprises where multiple logon is occuring within same or partnered companies/organizations/divisions and so this could reduce the shear number of logins a user would have to go through (if, say, everyone in the enterprise implemented authentication & authorization the same way & perhaps didn't even ask for the OpenID URL unless the domain changed where user surfed to).
Am I just not seeing something? I was really pumped about it, but it doesn't solve the problem (10's of emails/pswds/usernames/logins and security).