Slashdot Log In
AOL Now Supports OpenID
Posted by
Zonk
on Sun Feb 18, 2007 05:33 PM
from the making-progress dept.
from the making-progress dept.
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."
Related Stories
[+]
IT: The Case for OpenID 229 comments
An anonymous reader writes "VeriSign and NetMesh are making the case for OpenID, the grass-roots, decentralized digital identity system already supported by LiveJournal, Six Apart, Technorati, VeriSign and many startups, reportedly growing 5% every single week. They say OpenID 'is fundamentally different from other identity technologies' because it is a 'fully decentralized system' and has a 'much lighter cost structure' than any alternative, like Microsoft Passport, CardSpace or Liberty Alliance. Time to remove username and password from your site and add OpenID libraries instead, so visitors can authenticate with their blog URL?" From the article: "If tomorrow, for example, you decide you don't like the Diffie-Hellman cryptographic key exchange at the root of OpenID authentication, you can develop your own way of authenticating, and deploy it within the OpenID framework. If you have an idea for a new identity-related service that nobody else ever thought of, you can deploy it into the OpenID framework as soon as your code is ready. This radical decentralization on all levels of the stack, both technically and organizationally, is a very strong catalyst for attracting innovators and their innovations. This makes OpenID a superior choice for identity-related innovation."
[+]
Gates Says Microsoft Will Support OpenID 73 comments
An anonymous reader writes "In his RSA conference keynote today, Bill Gates announced that Microsoft will support the decentralized OpenID digital identity protocol, in addition to WS-* and CardSpace (transcribed notes, video). From its roots in LID, i-names, and Sxip, the first major deployment in LiveJournal, and now with support from Techorati, Magnolia, Symantec, a suspected mass-deployment by AOL, and a number of startups — using URLs as digital identities has caught hold."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
redundant acronym syndrome RAS (Score:5, Funny)
RAS syndrome and U.S. trademark law (Score:5, Informative)
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.
Re: (Score:3, Informative)
http://en.wikipedia.org/wiki/Spam_(food) [wikipedia.org]
Cool... (Score:4, Funny)
Re: (Score:3, Insightful)
Not cool (Score:4, Interesting)
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.
Why would we want OpenID? (Score:5, Insightful)
Re:Why would we want OpenID? (Score:5, Insightful)
Re: Why would we want OpenID? (Score:5, Interesting)
Of course, many here on Slashdot could probably set up their own OpenID server that has a unique identifier for each site, but how many do you think {are going to/are able to} do that -- especially among AOL users?
Re: (Score:3, Informative)
Re:Or: how is this different from Passport (Score:5, Informative)
Re: (Score:3, Informative)
Re:Why would we want OpenID? (Score:4, Funny)
From TFS:
Brings back thoughts of eternal september
-nB
The problem with single sign-on... (Score:5, Insightful)
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?
It's phishing time! (Score:5, Insightful)
Re:It's phishing time! (Score:4, Informative)
- use OpenID to verify those you know (or their membership in a community you trust) - don't use it for "verification" of a service you know nothing about
- Microsoft's CardSpace (InfoCard) protocol can provide a simple mechanism to support this verification
Once the trust is created, then you can use the XRI capabilities of OpenID 2.0 to provide sophisticated profile data sharing and/or service access authorization. But you are correct: if you're the kind of person who sends money to spammers, OpenID alone will not help you.Re: It's phishing time! (Score:3, Interesting)
Not just AOL users -- AIM users too (Score:4, Interesting)
Uh oh (Score:5, Funny)
I think I see the flaw in your plan.
Re: (Score:3, Insightful)
This is the whole point (Score:5, Informative)
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 [aol.com] ). 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.
Re: (Score:3, Insightful)
Re:Christ. We're all doomed (Score:5, Informative)
Re:This is a huge blow to privacy on the net... (Score:4, Insightful)
Re:OpenID vs OpenPrivacy? (Score:5, Insightful)
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.