Slashdot Mirror
AOL Now Supports OpenID
Nurgled writes "On Sunday John Panzer announced that AOL now has experimental OpenID server support. This means that every AOL user now has an OpenID identifier. OpenID is a decentralized cross-site authentication system which has been growing in popularity over the last few months. AOL is the first large provider to offer OpenID services, and though they do not currently accept logins to their services with OpenID identifiers from elsewhere, they are apparently working on it. The next big challenge for OpenID proponents is teaching AOL's userbase how to make use of this new technology."
I'll have a personal Identification PIN number please, what the hell is an OpenID identifier if not an OpenID ID?
People who don't want to manage 5000+ usernames.
So the idea is pretty cool... Now that you've got an OpenID, you could go ahead and use that login on whatever else supports OpenID. The problem lies with the fact that 50% of AOL's userbase doesn't even own a computer. According to some stats that AOL released some time ago...
Single sign-on across the internet is a bad idea. As more sites require it, people's web browsing habits will be tracked on an unprecedented scale. Seriously, what benefit does it provide? I certainly don't want to log onto my bank's website automatically. And in general, I don't want to reveal anything about my identity unless there is a very good reason to do so. The whole purpose of OpenID and similar technologies is to make it easier to track people. This is not the way I want the internet to develop.
It's a last ditch effort by AOL to stay relevant to the rest of the InterWebs.
Signature applied for, Patent Pending
One major problem I see with this sort of initiative is spoofing of your provider's sign-in page. Unlike spoofing in its current form, if someone was able to get the password for your OpenID provider, he'll have access to every single one of the accounts you've used that ID with. It's putting all your eggs in one basket -- with the way everything is currently handled, your sign-on information to an individual site may be compromised, but you won't lose everything else.
Is there a solution to this kind of problem, or is OpenID really only targeted to low-risk authentication; i.e., for forums and social networking sites?
No comment.
OpenID is the phisher's dream. I honestly don't get what would motivate someone to implement this specification.
Well, anyone can run their own OpenID server to authenticate against, but to use Passport, you rely upon Microsoft's passport.net servers no matter which email address you associate with it.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
But it doesn't have to run on some big evil corps servers. It's open in the sense that you can run your own server and track all of your own web surfing habits.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
AOL's openID's are all in AOL's namespace; DirtyTurtle278346812376.aol.com isn't going to prevent you having DirtyTurtle278346812376.myopenidserver.org.
I am TheRaven on Soylent News
The story is even bigger than the summary makes it out to be. It's not just AOL users who have an OpenID -- anyone who uses AOL Instant Messenger is included, too, as is anyone who uses AOL's "Journals" blogging platform. Both these services are free, and AIM especially is used by a far wider and more technical group of users than the term "AOL users" would suggest. (You /.ers who use AIM via Gaim, for example? You've got OpenIDs now.)
Read my blog.
The next big challenge for OpenID proponents is teaching AOL's userbase how to make use of this new technology.
I think I see the flaw in your plan.
Technoli
The joke is often repeated. But U.S. trademark law may help explain RAS syndrome. Trademarks are adjectives and should be used with a generic term, even if they contain an abbreviation of the generic term. Hence "TCBY yogurt" even though "TCBY" is "the country's best yogurt", "DC comics" even though "DC" was "detective comics", "SAT reasoning test" even though "SAT" was "scholastic aptitude test", and "SPAM luncheon meat" even though "SPAM" stood for "specially processed assorted meat" at one time. Writers pressured by trademark owners to include the generic terms in their copy tend to overextend the habit of abbreviation + generic even to cases where the abbreviation is not a trademark.
Another cause is to disambiguate homophonic or homographic acronyms. "Put your PIN in the computer" could be misheard as "put your pin (or pen) in the computer", which could damage the machine. "Put your PIN number in the computer" has one interpretation.
"OpenID is a simple single sign-on mechanism advanced by Brad Fitzpatrick of LiveJournal. In OpenID, your identity is a URL." - http://en.wikipedia.org/wiki/OpenID
Basically, OpenID provides for distributed authentication.
IMO, what makes OpenID interesting is that in the 2.0 protocol, XRI (i-names) have been included, which opens the door to enabling selective, authenticated authorization of access to services, be it as simple as the ability to contact me (I would allow any parent of a child in my kid's pre-school class to phone me) or as complicated (eventually) as any contract you can imagine.
OpenPrivacy, on the other hand, assumes such services as a starting point, which is why I suspended development of OpenPrivacy in 2002 and began working on XRI/i-names. OpenPrivacy will use sophisticated techniques such as zero-knowledge proofs to enable distributed reputation providers and truly pseudonymous identities that cannot be traced to their owner (unless such verification is mutually requested), but it requires strong, secure identity as a starting point.
I look forward to creating grassroots i-names-enabled communities soon (starting in March, if all goes well) and eventually getting back to my OpenPrivacy roots - which is where (IMO) things start getting really interesting.
The antidote for misuse of freedom of speech is more freedom of speech.
-- Molly Ivins
If you don't want to be tracked, don't use OpenID.
If I go to a blog and enter a comment with the name Kelly Clowers and give my website as www.clowersnet.net/~krc/, how do you know that I am really the Kelly Clowers who owns that website? This example is one of the original use cases for OpenID.
Now anyone can google Kelly Clowers and if an OpenID post turns up in the results, you can be fairly sure it was really the owner of www.clowersnet.net/~krc/ (which is presumably me, since that website specifically mentions this account (which is a solution that can work for main accounts, but I don't really want to list every one-off comment I ever made on random blogs)). Of course, a page could be hijacked, but the point is that imitating someone is not as trivial as entering someone else's name and website.
Not being tracked when you don't want to be tracked could be an issue if websites started accepting *only* OpenID, but I haven't seen anyone do that yet, and I doubt many will ever do that. And I don't think OpenID is really intended for online banking and shopping and the like. Also, if you don't want to be tracked, you could set up a second OpenID account that does not link to your primary account or to your real name.
Climate Progress - Hell and High Water
No one is pushing it as a trust mechanism. It is being pushed as a unique identifier. The idea is that if you start up a zippy website where there are some additional features if I create an account, you can let me use an OpenID to identify myself, rather than having me create a user/pass just for your site. I provide a url, and your server does some stuff to find out if I own that url, and if I do, it can use that to identify me.
You don't end up with any more reason to trust me than if I had used a random hotmail email address, but I avoid creating another damn sign in just to get 'account' features on your service.
Nerd rage is the funniest rage.
It seems OpenID prevents this problem. With OpenID the only thing you give to the websites you login to is your URL (such as https://aol.com/cooldude ). You can even give your URL to your enemies. You never give your OpenID password to any site except AOL, or if you run your own OpenID server, you never give your password to anyone at all. If I understand it right the whole encrypted procedure goes something like this:
You're trying to login to example.com
Example.com says: Who are you?
You say: I'm "https://aol.com/cooldude"
Example.com asks AOL: Is this guy really cooldude?
AOL sends a message to you asking: Example.com says you're trying to log on, is it really you?
You say to AOL: Yea it's me, here's my password to prove it.(AOL doesn't tell example.com your password. Also you save the hassle of entering your password for any site if you already logged in to AOL, like at the beginning of each day.)
AOL says to Example.com: Yes we verified it's cooldude.
Example.com says to you: Hi cooldude from aol.com, we've verified it's you again. Welcome.
Note that if you log into AOL at the beginning of the day, then for you this whole procedure boils down to you just entering your URL to login and then pressing a button from AOL to authorize the login.
Some advantages and disadvantages are:
You can use one username and password for every site and you only have to enter your password once a day.
If you used the same username and password at a lot of sites before, then with OpenID you don't have to worry about your password being compromised on one site by lax security or a crooked site owner(like a phisher) and then having your accounts compromised at all the other sites.
I'm not sure about the privacy issues. If your OpenID provider allows it(or if you set up your own server) you could set up an unlimited number of ID's (eg cooldude2, cooldude3, etc.) I don't see how you would be giving up any more privacy than any other system. And if your provider allows it you could save a lot of trouble and use the same password for all your IDs. Your OpenID provider could track which sites you log into, but you could just be your own provider or choose one you trust not to track you. Of course the sites you log into could require only certain OpenID providers like AOL, Microsoft, Verisign, etc. You might not be able to use your own server. Sites might only accept OpenIDs from providers that use strong identification, like Paypal's requirement that you control a checking account to be confirmed, because banks in the US are required by law to get ID before opening a checking account(says Paypal).
If sites only recognize OpenIDs from certain providers, at least the list of providers would likely be more inclusive than something like Microsoft Passport which has only one provider.
OpenID providers might differentiate themselves on their security. Verisign for example may try to claim that their OpenID service (if they had it) is secure enough to use for bank logins.
Actually, the problem is that the OpenID specification is very poorly written and is extremely complicated. It's as though a couple of kids wanted to put together an RFC but didn't really understand how to express a specification is a logical form. If you don't believe me, just take a look; you'll see what I mean just by glancing through it: http://openid.net/specs/openid-authentication-1_1. txt
Anyway, then, as kids are wont to do, they have followed it up with a series of new specifications, each one more complicated than the last. There are five specifications in draft form right now, each to cover some different aspect of what should be a fairly simple protocol. They reference and make use of HTTP, HTML, XHTML, XML, XRIs, XRDS, S/MIME, XSLT, and some other, similar ID specification called Yadis. Implementing all this thing requires gobs of software libraries (each with security holes and bugs) and expertise (and who has time to learn the latest X??? spec?). And we're supposed to believe that it's possible to do this securely? We can barely make secure web servers, much less SSI systems which require almost 100 pages of specifications, plus thousands of pages of supporting specifications!
What's sad is that the authors are not just a couple of kids that discovered XML and had a field day. The authors are associated with companies. The primary author works for VeriSign. Presumably, he should know better than to make such a jumbled mess.
But I think we all know what's really going on here. These idiots put together an incomprehensible specification. It is poorly defined, ambigious, and relies on lots of supporting technologies. It is impossible to implement securely, completely, and correctly. Security holes and interoperability issues will be the only real standard. And guess whose jobs are secure? Guess who gets lots of contracting jobs? Guess who is needed to write new specifications so that they can get it Right the next time?
It's too late to turn this one around. Hopefully OpenID will die a horrible death and we'll never hear of it again. But please, please, if anyone else reading this feels compelled to write a specification in the future, learn from OpenID's mistakes and keep it simple, stupid. Because OpenID is setting itself up for disaster.