Slashdot Mirror
The Case for OpenID
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."
Urgh, no way! I do not want all my identities to be tied together through one system. My actions on one site should in no way, shape or form be able to be tied in with what I do on other sites. Compartmentalizing my online life is the best remaining way to remain a modicum of privacy and stave off easy identity theft.
Any website switching to openID exclusively will lose my business. (Of course, if they offer it in addition to a standalone u/p, I'm fine with that, although I do fear that once it gets enough momentum, the standalone u/p will disappear after all.) :/
...but there's no real easy server implementation on Linux (or any other OS) that doesn't require you to do a decent amount of interfacing with the libraries. In other words, if you have time, it works great (ie, your employer wants you to work on an OpenID implementation project). If you just want to host some IDs on your personal box, there's no easy drop-in server software, or even reference software; my non-coder friends can't even begin to use it. I mean even Jabber has jabberd that you can build on.
Anyway I'm sure that'll change in the future, but it'd be nice to have now. Or maybe I'm completely blind and there's a reference server implementation hanging around somewhere?
reportedly growing 5% every single week.
Translation: last week the install base consisted of his algebra class. This week he installed it on his mom's computer. Next week he's going to grandma's house and he'll install it there too.
Now if they only leverage their know-how and implement top-of-the-line solutions thanks to their syniergies, they'll be buzzword 1.0 compliant, too! I can't wait!
Global warming is a cube.
It's all well and good that I can write my own implementation of Diffie-Hellman key exchange, but if my mother can't go to a site and quickly and easily create a login, it's not going to work. I'm not at all saying it's a bad idea. Technically, it's a wonderful idea, but it has to be made so simple that anyone can access it, otherwise people are going to continue to use stupid services list Microsoft Passport.
-Arthur
Cave ne ante ullas catapultas ambules
I'm sorry, I couldn't read your post. Would you mind decrypting it? This truly is a remarkable method.
The problem though is that OpenID is currently just a framework. There is no way to prevent people from making 100 accounts, which is still the problem. Once we have a way of making sure each person only has one account, even if we don't know who that person is and can't identify them in any way, then and only then will social software be able to break through this quality barrier that it is currently capped it. I wrote about one way of doing this here, and there are other ways. Hopefully within the next ten years we can have this problem solved, to enable the next generation of web apps that aren't even possible today.
Any website switching to openID exclusively will lose my business
There's no need to abandon a place just because they use openID. Why not setup multiple IDs with different user names, passwords, and email addresses? (I assume that's possible under OpenID?).
I agree that a single collection of IDs (all-eggs-one-basket) represents a dangerous single point of failure. But just because someone implements a new potentially better basket doesn't mean you have to put all your eggs in that basket or avoid using sites that use that type of basket.
Two wrongs don't make a right, but three lefts do.
> reportedly growing 5% every single week
And WTF does that actually MEAN?
It superifically appears to assert that the number of people using OpenID is growing each week by 5%.
Is this the number of people *actively* using OpenID, or the total number of ALL users ever, e.g. including those by people who've used it once and then walked away?
Is this the totaly number of people across ALL OpenID service providers? this seems unlikely, since someone would have had to have done the work of collating all the stats from all those providers.
If it is then just a sampling of providers, how was the sample chosen? is it representative? or was it opportunistic, e.g. those OpenID service providers who are loudest about OpenID and so could be expected to tend to be those who see the largest growth rate in users?
Also, 5% each week sustained actually means an ever increasing absolute number of users, since it's 5% of an ever larger user base. When your user base is 100 people, 5% is five 5 new people, which isn't hard to sustain on a week in, week out basis. So what is this 5% - which could be completely inaccurate anyway, since we've no idea of the sample it's based - 5% *of*?
Multiple passwords? Are you saying I shouldn't use the same password at my bank that I use on bustybabes.com?
-----BEGIN PGP SIGNED MESSAGE-----
f xLrtlKGDHcrIp7jidODlrTQCgqCPxr rPJA=
Hash: SHA1
OpenID seems rather complex. There are already decentralised systems for authenticating a user's identity. But, if it gains momentum I would be happy to use it. One thing I can't work out is how I can create an identity. I have my own domain name and web site; I don't want to rely on Livejournal or another third party to maintain the notion of my identity.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFdYQlshl/216gEHgRAk00AJwLvC
czXJO4lwp5Znr+A7sS
=MeMH
-----END PGP SIGNATURE-----
I think the other respondent hit the nail on the head.
Most people (aka, 'your mom') won't know that they're using an OpenID at all. Instead, they'll probably just think of it as the ID of whatever service provides the OpenID authentication. So LiveJournal or whatever, but potentially in the future a more mainstream provider like Yahoo. I'd expect that sites which used OpenID and catered to a non-technical audience might even disguise the fact that it's OpenID (instead, "Sign in with your LiveJournal ID here!").
To a user, logging in with an OpenID should be just as seamless as logging in using their Microsoft Passport or Yahoo ID, except that it would work at more sites. There's no reason for the backend infrastructure to be exposed to a casual user. One of the criteria for success of any authentication system ought to be transparency and ease of use. If it doesn't offer that, it's a failed system by virtue of irrelevance.
As I was writing, a thought came to mind. These OpenID/cross-site-ID systems seem like they'd be a huge avenue for phishing attacks. How do you prevent someone from setting up a blog, and putting a Login field on it ("Sign in to comment with your LiveJournal/Bloglines/WhateverID!") and just harvest people's L/Ps as they're entered? Maybe I'm missing something about the system but if all the libraries for authentication and communication with the OpenID user's authenticator (whoever is 'vouching' for the OpenID user, e.g. LiveJournal) are done on the server, then the server has to be trusted with the user's OpenID username and password, or at least it would look like that to the user. It seems like there might have to be quite a bit of interface design and user education to keep people from blindly typing a master password into untrusted forms that would result in their whole identity being taken by a spammer.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
A number of other posts have alluded to 'whats the problem with identity'. In the FWIW department a summary of the important issues from someone who has spent a long time working in the field:
1.) There is no standardized method for defining identity.
2.) Services of value impose the Reciprocal Identity Management (RIM) problem.
With respect to point 1, is your identity?
mdoe
112233
Mary Doe
mdoe@SOMETHING.ORG
http://www.something.org/mary_doe
All of the above 'representational identities' are very useful in different contexts. None of them are your identity. For better or worse your identity is ultimately a token, lets call it an 'intrinsic identity', which has a fiduciary or contractual value associated with it by a third party.
Examples of intrinsic identities are things like social security numbers, credit card numbers, employee identification numbers, visa numbers etc. Such tokens are extremely useful in information technology since they serve as unique and definable 'keys' for who someone is. They are also extremely dangerous since possession of these tokens allow the implementation of an identity.
Systems such as OpenID, Shibboleth, Liberty Alliance and a bunch of OASIS standards seek to solve the problem of 'identity assertion'. While useful in and of themselves they don't provide a fundamental definition for identity.
Federated identity systems solve a very useful and important problem but impose problem number 2 which is the RIM problem. If the service being vended has any value a system for authorizing access to it must be in place. If the identity assertion comes from an external site the accepting site needs to instantiate or manage the identity in order to regulate the use of the service by the requesting identity. One class of problem is addressed but a second and equally important problem still exists.
In the case of the 'real world' - blog and social networking sites notwithstanding, where one organization is asserting identity for the actions of one of its employees there is a need for the identity asserting site to regulate the actions of the identity on the remote site as well. The management problem becomes quickly apparent if there are hundreds of partners in a federated identity environment.
Getting the right answer to the identity definition question is actually very useful. A number of very important issues in information delivery tend to 'fall out' when the question gets answered properly. Unfortunately the field of identity theory is abstract, poorly defined, difficult to understand and laden with socio-political and privacy issues.
As is typical with most problems the low hanging fruit gets picked first. Various schemes such as OpenID for attacking the identity assertion problem are emblematic of those types of effort.
It is possible, you know, for a technology enthusiast to have some understanding of the fact that most people who use the internet are NOT technology "enthusiasts" (your term).
Expecting actual humans to remember a host of usernames and passwords just to be able to participate in online discussions and shop for a book is not acceptable. Why can't techies get it through their heads that user friendliness is an important part of elegant software design? Security people seem to have the hardest time with this concept.
On the flip side, I don't expect my car, my house, my office and my bicycle all to be unlocked with the same key, so the notion that one U/P combo should take care of all internet security needs is silly. But that doesn't mean that I should have to actually type in my key every time I want to use a secure site.
In the middle of the 20th century, there was a revolution in industrial design. People like Raymond Leowy taught the world that manufactured goods can be made much better by putting some thought into the way people use them and look at them. Something similar has to happen to the world of digital tools in a big way. It's not enough to make it look pretty. It has to WORK pretty, too.
Everyone has an experience with software where the design was so good that it was a revelation. Mine was with Logic Audio Platinum, by emagic. I'd been doing digital music for a long time, using Pro Tools, Cubase, etc, mostly on PCs. When I first sat down with LAP on a Mac, I immediately noticed that everything was easier. Less fatigue. Every tool seemed to simply be there when I needed it. If I clicked on something, the thing that happened was what I expected to happen.
If you are a software engineer and you don't think this same concept applies to the area of software security, you aren't doing your job right.
You are welcome on my lawn.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
So then change your password daily.
Or, you know, since it's OpenID and you have complete control over the server, have it set up in such a way that only your IP address can see the password in plain text when you want to log in.
Here's how it works:
You go to a site that uses OpenID. You enter the address of your site to authenticate. You are then redirected to your own website to authenticate (unless you're already logged in.) At this point, the server you set up should ask you if you really want to trust this other site with your identity. You can trust it once and post your new comment, or trust it always if you plan on posting frequently and have that info saved on your server somewhere. Or you can change your mind and not trust it at all.
If you want to implement a password system that nobody can ever figure out, then have it automatically generated and maybe sent to you via email every day in some encrypted format that only you can figure out.
Do you really want your registration for eBay, Amazon, the communist party website, your Christian youth club forum and this bondage fetish site that you frequent to be tied together?
Actually, this is probably not a problem! Presumably, if you're into bondage, you don't mind things being tied together...
This is a generalized reply to a number of comments that are either reflexively nay-saying the entire idea or are not understanding what this really means.
The intent of OpenID (as I read it) is simply to provide an identity. An identity is just a name that at least one person has permission to use, and no more. Multiple people may be able to use the identity. Perhaps some aren't "authorized" (a vague, undefined term in this case), and obtained the credentials by hacking. Maybe one person has a thousand OpenIDs. It really doesn't nail you down, break your anonymity any more than posting with a Slashdot account that has no URL, email, or distinguishing username characteristic, or give the One World Government an ID to tattoo into your arm.
The reason this is useful is that it gives further layering something to talk about. I can't tell my blog system "John Milquetoast Xavier is allowed to post on the front page", because the blog system can't understand "people". It needs "identities". But I can say "this OpenID is allowed to post".
And all the OpenID system will tell me is that some person has authenticated with that ID. I can further restrict their activities; I can still require a CAPTCHA, I can require a paid account, I can do all kinds of things. There's no law that says I have to let everyone with an OpenID have full permissions on my site. (When I say that, it's obvious, but based on the comments clearly some people have this idea in the back of their head.)
I can also go the other way; if your OpenID is from a site that I trust to verify you are a real human for some reason, I might allow OpenIDs from that site more permissions than one from the random internet. If my company sets up an OpenID server that we control and allow only our employees on, I might be able to trust OpenIDs from that server more than random strangers. (Assuming good security for the sake of argument.)
You could set up your own OpenID server to do whatever. I'm sure that if this takes off, there will be OpenID servers that people choose to leave wide open to allow anonymous OpenIDs to be created by anybody. Maybe it'll simply say "Yes, that person exists" to any query with any password, if the API allows it. Using one of those won't tie you to anything.
What you are worried about shouldn't be "identities", you are worried about "identities that can be tied to you". The generic OpenID specification can not provide that, since in the general case the OpenID server could be anything, including a compromised box, and you therefore can not trust it a priori. All it can do is provide a label. Excessive trust in an identity system is the real problem, not an identity system.
I've been creating a weblog for myself lately that includes comment posting, and while I don't think I'm quite ready to jump to OpenID, it's actually exactly what I'm looking for. My spam-control solution will be to moderate every comment posted, but once an identity proves its bona fides, I'll whitelist it. All I want is an identity. I don't really care if I can map it back to a person, I don't care if 10 people are using it, I just want an entity that I can deal with in my database and grant it permissions to above and beyond what an anonymous user gets. OpenID would solve that problem nicely, because I have no intention of farming out to OpenID the question of how much I trust the identity, merely the existence of an identity.
ILUVTITS
LVTT
5888
I was also the one who made the "5% a week growth" claim (at the Internet Identity Workshop this week) and unfortunately it was not clearly quoted. "5% a week" describes the growth we are seeing in new relying parties (aka sites-that-support-OpenID). Yes, its impossible for this growth to keep up over time but its still a valid data point. Graph is forthcoming.
I'm shamelessly linking to my own blog here but I think there are a few answers to the questions people are posting on this thread:
* How do I choose a third-party OpenID provider?
* Converting your existing site to OpenID
* How do I use my own domain as my OpenID?
* OpenID and Phishing
If it is possible to easily change the password to ALL THE SITES to which I login, then I am going to be MUCH, MUCH more likely to actually change my passwords on a regular basis. This is especially true when I embrace the "new" system. The benefit to me is one username and one password, wherever I go. The cost is that I need to change that ONE password more regularly. This seems like a good, and easy, tradeoff.