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."
one password to root them all !
all these integrated ID schemes (MS passport etc) are good in theory but for a vital flaw, the bad guys only need to get your single password and from then on they have access to _all_ your "openID" websites
much better to have multiple passwords however hard it may be to remember them
The article is right, I don't like the Diffie-Hellman cryptographic key exchange, it smells.
I propose the slashdot implimentation of the cryptographic key exchange involve should double rot-13.
liqbase
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
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.
And more so with authentication. I don't want someone to be authenticating me using the new-fangled system they wrote during a drunken craze last weekend, when they had some flash of insight that led them to believe that Diffie-Hellman is a load of crock, and is much less secure than their "guess-a-number-between-one-and-ten" system.
> 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*?
Same reason people type PIN numbers into ATM machines. We simply don't care.
I think the primary reason we capitalize ID is to distinguish it from the id, ego, and superego. Flashing your id to get through an airport security station will likely land you in jail, or at least result in a sexual harassment allegation. Showing your ID will get you right through. Besides, grammar is evolving.
Can I wrote an app that automatically collect the credit card number of any subscriber of that service that is visiting my site (just to check they are 18, of course)? In other word, can anyone do whatever he want with the data or is there a good protection?
But OpenID isn't supposed to be a system that uniquely identifies a person on the internet. It's a system to provide multi-site logins without a large central repository.
/. account (which I'm not bothering to log into right now), a k5 account, an LJ account, two AIM accounts, etc. But with OpenID, I could just pick one and log into everything with it.
It's more useful to allow people to do things like make comments on many blogs (LJ, MySpace, DeadJournal, Blogger, whatever) using one blog account so that all their comments are tied together and to the one site they update. If they want to have multiple accounts they still can, and that's kinda the point. It's the same way I have a
Maybe later someone else will solve the problem you're describing. SixApart just wanted to let people comment on LiveJournals without an account on their site. And they found a way. It's pretty smart.
Regardless of whether it's an acronym or an abbreviation, it's customary to capitalize all letters if it's a word you say by pronouncing the letters rather than the word. Not capitalizing all letters implies that you simply pronounce it as a word, as in "laser." That's why it's OK to go to a Larp and show your scuba license as a form of ID.
"It's too bad that stupidity isn't painful." - Anton LaVey
If I have to setup several ID's, then why use OpenID in the first place?
This will never fly.
What if there is a rogue OpenID provider? What if someone sets up their own OpenID system to leave fake authenticated comments on a blog? I wonder why the OpenID project has not considered this.
But what if you live in OK (Oklahoma)?
I guess they still spell it Okay!
“PIN” is “personal identification number” and “ATM” is “automatic teller machine”. These are acronyms and correctly capitalized. However, I know that people would certainly find it weird if they saw “avenue” abbreviated as “AVE” or “January” shorted to “JAN”.
Why bother.
From the article:
Entrepreneurs and intrapreneurs, for whom OpenID provides a fertile ground for innovation, such as:
- reputation services, which help both end users and site operators and represent a major business opportunity in itself;
- open social networks that are not confined to a single vendor's site;
- more secure, efficient and accountable messaging systems that one day could replace the protocols that e-mail runs on.
Some have told us they consider the OpenID community to lack a clear process or structure, to not solve the "real" problems in identity (yet?), or to be only applicable for low-end problems. They are probably right; however, we think of it as the early days of Internet-scale innovation in action, where these characteristics are desirable, not detrimental.
What are the "real" problems? I'd like to hear what the author sees as the real problems in identity. I guess, at the end of the day, it would be easier to remember one username and password. I often use the same username and password on multiple sites anyway. But it seems like this leaves me vulnerable to identity theft. Then again, I don't enter my "real identity" information on non-critical sites anyway. So, this is probably about as useful as MS Passport...
Second, an acronym is ``a word formed from the initial letters or groups of letters of words in a set phrase or series of words''. Consider RADAR. RAdio Detecting And Ranging. If ID were a contraction of identifier it would be spelled id' not ID.
Lastly, whether acronyms are all upper case or not is entirely a matter of convention. ID is typically always upper case to avoid confusion with the Freudian term id.
I agree with “OK” since it is an acronym for orl korrect. Otherwise, why is it alright to remove proper case from “Larp” and “scuba” by not write “NASA” as “Nasa”?
i suppose ITS ok to Just ignore proper capitalizatioN in english Today.
Why bother.
Why do people insist on abbreviating the word "identification" as "ID". It is not an acronym but rather a shortened form of the word.
Actually, it's both. In the case of OpenID, you are right, it's just a short form of "identification". But in most cases, "ID" is an initialism that stands for "Identification Document" - you know, like passports, drivers licenses, etc.
The president of Sxip made some good points about personal identification and how it should work online, even if Sxip's implementation isn't perfect.
In the real world, we have organizations that create forms of ID, and other organizations that need to identify us. I have a birth certificate, a library card, a passport, and a credit card, for example. These all certify certain personal details about myself, and they don't all cover the same details. What's also important is that they're portable, they're secure to varying degrees (i.e. hard to duplicate or modify), and I control who sees them.
In the real world, I can use these IDs with third parties, removing the necessity for those parties to create their own IDs. A video rental store, needing to confirm my name is what I say it is, can decide it trusts the issuer of my birth certificate (the province of BC) or the issuer of my credit card (Citibank), and will thus accept those cards as proof of my identity in lieu of having to create its own identity system. A liquor store that ids customers won't care what my name is, but they might want to verify my picture and birthdate; there are several identity issuers they'll trust, and I can show cards from any one of them so long as it has the right information. Thanks to portable identity, the liquor store also has no need to maintain its own identity database.
So why can't digital identity work this way? I already have established, verified, trusted identities at several online institutions -- eBay, Amazon, Slashdot, my bank, etc. So when I go to a new website that needs to verify my identity -- an online store, a message board, whatever -- there should be no need to create yet another new identity. I should have some digital way to flash my eBay credentials, or my Amazon credentials, or credentials from any source that website chooses to trust. They should be able to create an account for me and everything, letting me log in with the credentials I already use elsewhere, just like the brick-and-mortar video store that lets me rent videos by showing my driver's license. An ideal digital identity would be portable just like the kind I carry in my wallet, except my control over it would involve password protection instead of physical possession.
There should be no need to create yet another catch-all ID system like OpenID. The dozen or so identities I already have should become portable, so I don't have to keep making more.
He who lights his taper at mine, receives light without darkening me.
Yes, giving out personal information on every page you want to comment on is much better. Don't use it for important sites. It's that simple.
It would also be nice if wikipedia would activate OpenID.
-----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-----
Its a great new system. Just turn around, pull down your pants, bend over, take a picture.
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."
My personal frustration is sites that don't let you use an email address as a username; an email address is pretty easy to remember.
If you're really worried about a low-security "single sign on" solution (which this article seems to suggest), why not just leverage one of the many cookie schemes advertisers use to track you all over the net? (The end result is the same.)
Hey, you forgot LASER! *pew* *pew* *pew*
It's not about blatantly ignoring proper capitalization. It's all about usage. For example, scuba and laser have been promoted to word-like status. Many people don't even know that they're actually acronyms. As these acronyms become used more often, they tend to be used like words, hence why many of them lose their proper case. You can probably add fubar to that list.
As someone has already explained, we probably capitalize ID (the abrv.) to distinguish is from the id (ego).
With their own registration system, site owners can add features that make spammy registrations difficult (I'm getting 10 or so daily spammy registrations). Blindly trusting OpenIDs and allowing them into a site, or giving them posting rights would be crazy. So what are the options for countering spam? Can you add extra checks and validation? User verification? Black/white/grey lists?
I know the OpenID folk say "this is not a trust system" and that is not the problem they are trying to solve. But it needs to be solved for it to be widely useful!
If it isn't solved we have a one-stop-shop for spammer IDs. If we "solve" it badly, it's nearly as bad as running your own registration system (from a site owner's viewpoint) or registering all over again (from a user's perspective).
Paul "Say no to feeping creaturism"
Thank you, that pretty much nails it for me.
Why bother.
The thing with frameworks ... is that over time implementation costs increase, and interoperability decreases, as you add more concrete stuff within the framework. They give the illusion of value.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
If you're writing an article dealing with issues of trust, especially if you're about to solicit the reader's trust in the subject of your article, make sure to start the article with the word "Verisign". You need write no more...
I love anonymity. I hate "identity management" which leaves the user with a single "approved and authenticated" online identity.
You don't know my flickr username. You don't know my Ebay username. You don't know my Friends Reunited username.
You don't know what I bought my family for christmas, what they look like, where I went to school, where I work know, where I live or what (or if) kind of car I drive. What you know about me is what I have chosen to let you know.
I like it that way.
They who would give up an essential liberty for temporary security, deserve neither liberty or security - Ben Franklin
Actually, it probably will. Most people don't care enough about security. If you don't care about security, these central password systems are great ideas.
When data is transferred over the OpenID network AS IT STANDS AT THIS MOMENT no encryption is required, thus all your userdata could be transmitted in clear text. This is a clear reason to steer clear of OpenID or at least put pressure on them to fix this.
well, can this help me to create a number of fake users (e.g. for all those stupid "please register" web sites), and help me to manage
who site gets which personality. I would really prefer if I could thus decrease the number of sites that know me, and instead use throw
away identities for "free downloads" and stuff like that.
You know, up until this point I've always had a moment of doubt when choosing between camel case names for a method like getUserID/getUserId. Your post has tipped the balance in favor of "getUserID".
After all, I wouldn't want anybody to think that "getUserId" returns the part of the user's psyche responsible for ego-gratification behavior.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There's some disagreement about the origin of OK. I think Woodrow Wilson used to say 'okeh' was from an Indian word.
I'd imagine you can ask for some CATCHA along with the URL.
"If anything can go wrong, it will." - Murphy
My non coder friends can't even register! You have to alter the HEAD portion of an HTML document that you own to authenticate yourself. People with just a myspace page can't do that!
-- these are only opinions and they might not be mine.
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.
There's nothing in the desription that would stop you from using those visual recognition techniques ("what letters do you see in this noisy field?") or any other further authentication. You could require an OpenID AND a local password that would be stored on your server if you wanted (though this extreme example would defeat the point entirely).
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.
Well, I had to login with user name and password to my blog url. :)
You know, it's acceptable to solve one problem at a time. It's how real engineering is done. Try to solve this entire thorny problem in one fell swoop and you get Microsoft Passport.
I am getting all of my data about this system from http://openid.net/about.bml. There it says that the foreign server B asks my local server A if server B is designated as "allowed." If A says that B is allowed, B believes that I'm me and lets me continue. Otherwise B says, "Uhm, A doesn't know wtf you're talking about. You'd better go register me on A."
So I go register B on A, right? And now all I have to do to login is type larko.A.com into the little login box on B?
Why can't SpammerX type in larko.A.com now?
Maybe there's more information about this deeper in the site that I didn't see, or maybe I'm an idiot. Anyone know?
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.
There is:
http://www.openidenabled.com/openid/php-standalone -openid-server/
Also, if you just want OpenID for personal use, you can use delegation to configure any URL you control to use any OpenID server you want.
I'm glad to announce, that I have installed a new OpenID Server for
/dev/null so that ;-) and
anybody to use. This is a supper-trooper and absolutely cool OpenID
server, since it doesn't require you to sign up, register or
anything...Total privacy! You can choose any user name and change the
name every time if you wish, all you have to do, is to provide at
LiveJournal or other blog/forum, a URI like
http://123.no-password.com...everyhting/ works, no questions asked! You
can even choose a user name somebody else used previously. This is
specially interesting, since viagra.no-password.com will become
reusable...
I simply downloaded one of the libraries from the OpenID web site and
removed any authentication checking (patch available), so that when you
have to authenticate with no-password.com the web site simply post's you
back to LiveJournal with is_valid="true". Also I removed the association
for shared secrets with the RP, since there is nothing here to protect
and completely optional
according to the specs. This makes no-password.com the fastest OpenID
server, since we don't use SSL and have no need to create the
assoc_handle. I'm sure we gained about 10 milliseconds on this! BTW, did
I tell you, that no-password.com is completely private and anonymous?
Any log files created by the server are directed to
any traces of your visit at no-password.com are destroyed immediately!
This is much better that the PiP offered from Verisign, since they
probably keep log files and make back ups of their databases
because according to the specs the IdP establishes whether the End User
is authorized to perform OpenID Authentication and wishes to do so and
the manner in which the End User authenticates to their IdP is beyond
the scope of the OpenID Authentication 2.0 Specifications, all users are
authorized at no-password.com without questions asked. Cool, isn't it?
I'm sure you now understand how useful the OpenID framework is and you
decided to add OpenID login to your forum immediately. There are no
requirements on your part, but you should....well, really you should
make a small form at your forum, so the user can enter the
no-password.com URI. It's also recommended that you place the OpenID
logo http://openid.net/login-bg.gif at the beginning of the form
field. Well, perhaps you just remove any authentication at your
forum...it's useless anyway...Count on no-password.com to always
authenticate the users of your forum positively!
However, I'm not sure, if I'll keep no-password.com, since I just bought
it and can return the domain within 10 days without getting charged.
Anyway, perhaps I'll get another one (no-questions-asked.com is free) in
ten days....I'll keep you updated on this!
I'm glad to announce, that I have installed a new OpenID Server for anybody to use. This is a supper-trooper and absolutely cool OpenID server, since it doesn't require you to sign up, register or anything...Total privacy! You can choose any user name and change the name every time if you wish, all you have to do, is to provide at LiveJournal or other blog/forum, a URI like http://123.no-password.com...everyhting/ works, no questions asked! You can even choose a user name somebody else used previously. This is specially interesting, since viagra.no-password.com will become reusable...
/dev/null so that
any traces of your visit at no-password.com are destroyed immediately!
This is much better that the PiP offered from Verisign, since they
probably keep log files and make back ups of their databases ;-) and
because according to the specs the IdP establishes whether the End User
is authorized to perform OpenID Authentication and wishes to do so and
the manner in which the End User authenticates to their IdP is beyond
the scope of the OpenID Authentication 2.0 Specifications, all users are
authorized at no-password.com without questions asked. Cool, isn't it?
r /000165.html
I simply downloaded one of the libraries from the OpenID web site and removed any authentication checking (patch available), so that when you have to authenticate with no-password.com the web site simply post's you back to LiveJournal with is_valid="true". Also I removed the association for shared secrets with the RP, since there is nothing here to protect and completely optional according to the specs. This makes no-password.com the fastest OpenID server, since we don't use SSL and have no need to create the assoc_handle. I'm sure we gained about 10 milliseconds on this! BTW, did I tell you, that no-password.com is completely private and anonymous? Any log files created by the server are directed to
I'm sure you now understand how useful the OpenID framework is and you decided to add OpenID login to your forum immediately. There are no requirements on your part, but you should....well, really you should make a small form at your forum, so the user can enter the no-password.com URI. It's also recommended that you place the OpenID logo
However, I'm not sure, if I'll keep no-password.com, since I just bought it and can return the domain within 10 days without getting charged. Anyway, perhaps I'll get another one (no-questions-asked.com is free) in ten days....I'll keep you updated on this!
Source: http://openid.net/pipermail/security/2006-Novembe
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
Noblesse Oblige? Yeah sure.
/.) but having not read anything
Follow the money, how do they expect to make a bundle on this? I'd
like to see their plan before jumping in too quickly. Will there be
an *upgrade* that all serious blogs need to make (only $99/year/cert)?
Sorry to be cynical (well not sorry on
about this my $$ filter was triggered. Sounds really cool, worth investigating,
but... pling pling pling...
When a web site has its own registration and login, it's able to keep me logged in between visits. I can quit my browser, shut down my computer and come back two weeks later, and I'm automatically logged in to Flickr. Zooomr, on the other hand, requires OpenID. If I so much as quit the browser I have to log in again the next time I come to Zooomr.
Now this might not seem like a big deal to some, but it's bloody annoying. I'm not opposed to the IDEA of a single password designed to give me access to every site I visit regularly. I'm opposed to one where I have to log in to EVERY SINGLE SITE individually every time I visit. It's actually the antithesis of what it should be doing. It's supposed to make things EASIER, not more convoluted.
So maybe I'm stupid and I'm doing it wrong. Damned if I can tell, because the OID site sucks major ass and doesn't seem to give me any control over how long I stay authenticated.
So I continue to use Flickr (which I like better anyway) instead of Zooomr, even though I've got a free pro account on Zooomr.
And who names these fucking sites, anyway? A three-year-old on ecstasy?
For me, the idea would have very limited utility. Right now, I have an encrypted file that contains about 50 usernames and passwords. When I need to log on to something, I view the file, and cut and paste. Let's say that 20 out of those 50 sites were using OpenID, and the other 30 weren't. Then instead of an encrypted password file with 50 entries, I'd have an encrypted password file with 31 entries: the OpenID password, plus the other 30. Cutting the number from 50 to 31 doesn't really make my life any easier. If it could be cut from 50 to 1, then yes, that would potentially make my life easier. However, I don't want it to be cut from 50 to 1. I don't want my slashdot password to be the same as my banking password. Even if every single site started using OpenID, I'd still probably have at least 10 or 20 different OpenID passwords, which I'd store in an encrypted file.
Find free books.
I had thought that integrating the shibboleth (also open-source) based protectnetwork.org into the sites I managed seemed to be the way to go. The protectnetwork people have a long list of open source software already integrated: http://protectnetwork.org/shib-sp.html, and also directions for rolling your own.
The way protectnetwork works, you can click on a "login with protectnetwork" link on the site, and it re-directs you to protectnetwork's site where you log in, and are then presented with a page showing you what information will be sent back to the first site, and you decline if you don't want to and decide to make up another identity instead (a key feature IMHO), and then you click yes it sends you back to the site logged in.
I can make the "log in with protectnetwork" button be an additional option to my own login with site user name, and then only switch fully to protectnetwork if I see that most people are using it.
One issue I see with OpenID is in that anyone can set up an identity server, and the blog spammers surely will -- will we need to maintain a list of "known good" identity servers and a "blacklist" ? On the other hand I like the idea of not forcing everyone to go through one site, like protectnetwork, which seems a little like Microsoft Passport stuff to me.
I guess what I am really looking for is more of a survey of the whole identity provider/server industry, to know what is out there. Also, as a person who runs these various web sites as a hobby, I can't really be paying lots of money for this -- which of course makes me suspicious of Verisign's involvement.
As far as I know, Liberty allows this as it is web service oriented... anyone can set up a Liberty server.. and anyone can set the trust on their web-app to accept any authentication server.
Give them the illusion of choice and they will blindly follow for they choose not to make one.
Is not possible to you run only with E-mail adresses as usernames. To post here, for example, your post is unmistakenly identified by your username, to refer to your posts. So, how to assign a post to you, if your username is your E-mail? How someone could to answer to you? You would like to post your E-mail address here?
I guess you're joking, but OpenID actually uses a scheme very similar to how advertisers track users cross-site. The difference is that OpenID is designed with your interests in mind rather than the advertisers, so random sites can't just track you without your permission.
Alas, many websites believe that '+' is an illegal character in e-mail addresses, and so disallow these extended addresses.
I've been using MyPW for a couple of months now its authentication service, where you can use the same two factor token on any other site that uses MyPW. Its pretty Cool, I've got it working at home and at work now.
Its cheap in comparison to RSA and Cryptocard only $1.00 a month per unique token used on your account and $14.95 for each token.
http://www.mypw.com/
No. That's what karma is for.
Intron: the portion of DNA which expresses nothing useful.
You are missing a certain amount of point here: not everybody has, or necessarily wants, their own website. People will be relying on third-party OpenID servers; LiveJournal, possibly the first and certainly the most well-known site to have adopted OpenID, is likely to be a fairly common choice. There already exist a handful of free OpenID servers on the net that are just that (i.e. not also a blogging service or anything else).
However, for those of us who do have their own website, I see OpenID's killer feature being delegation: a couple of meta tags in your site's front page, and you can authenticate as your own website without having to set up your own OpenID server. I have done this on my own blog, for which I have rolled my own mini-CMS - with OpenID identification for comments, natch.
Delegation in plain English:
* Johnny owns www.a.com. Johnny is lazy; he only wants to implement an ID consumer, not a provider.
* Kate runs www.b.com, a free OpenID provider; Johnny trusts Kate, so he opens an account there.
* By inserting delegation tags into the relevant page on www.a.com, Johnny can authenticate as www.a.com with any consumer, with www.b.com doing all the donkey work.
* If www.b.com goes belly-up or gets compromised, Johnny simply opens a new account elsewhere, changes his delegation tags to reflect the new provider, and keeps using www.a.com as his identity.
I have personal experience with OpenID, having both created and used an OpenID account, and of course running the aforementioned blog. It's very cool: I can post as mangobrain.co.uk to the LiveJournals I read, and people from LiveJournal can post as themselves on my own site, providing both fairly trustworthy identification and automatic linking for robots to pick up on.
This is a very important point, and the key to any notion of security surrounding OpenID. It is in essence a three-way handshake between the site you're logging in to, your browser, and your OpenID provider, with your actual username and password only ever being passed between the second to.
When I first heard about OpenID, I was highly skeptical - then I read the specs in detail, and came round to the idea.
His name is Scott Kveton and before he left/was forced out of www.osuosl.org at Oregon State he was heavily promoting openID.
http://kveton.com/blog/
I think this OpenID group is buying their way into state governments because the osuosl is run like a public profit cost center not a public non-profit supported by public funds and private donations as it should be.
Another software program originating from Oregon's osuosl is Maintain, a pervasive DHCP/dns upkeep program. It sounds like the centralized forms of recordkeeping used in OpenID are similar to Maintain's design.
There's got to be a better way to do it. We need transparent registrars, a good way to openly delegate DNS registries and competition between providers with open access private profit and public institution backbones.
If you're on Blogger and require a Blogger account for comments, what's to prevent spammers from getting hundreds of Blogger accounts? Nothing. Same goes for every traditional account system, same goes for OpenID. It's not a problem that can be solved with authentication alone.
- Singpolyma
As someone has already explained, we probably capitalize ID (the abrv.) to distinguish is from the id (ego).
I figured it was capitalized to reflect the way we say it (eye dee) - spelling out the letters instead of pronouncing it as a word. I guess the most correct way to do that would be to write it I.D., but people tend to drop those periods, hence "ID".
So, when will we see OpenID login on Slashdot? What about being able to use Slashdot accounts as identities on other sites?
Evan Prodromou | evan@prodromou.name | http://evan.prodromou.name/
>First, for passwords, you only need to remember *1* and have the following javascript (which runs client side) from this most excellent site:
GenPass.
Quite a few options for this functionality. Last time I reviewed them, my favorite was pwdhash.
Since we already rely heavily on the government to provide physical IDs (drivers licenses, passports, SS cards, etc), is it logical for next step to be the government to provide online ID identity verification? Much as I shudder at the thought of ecommerce sites depending on the reliability of the California DMV, it seems to me to be the obvious next step.
You still would need fewer IDs than one per website/blog, and you get increased security, so it's a win/win IMHO. How many different anonymous personae do you require? It allows you to build a reputation in one area with one ID while maintaining obscurity with others, if you prefer. In principle, having different, random user names and passwords at every domain is a relatively solid way to go, but the problem is, only a vanishingly small minority of internet users follow that practice.
This may be a good idea, if it turns out to be secure. In the meantime, I'll keep my encrypted text file (via vi) on my main server, and when I need to log in somewhere that I don't remember the password, I'll ssh in, open it, and get it. Kind of a low-tech solution, but with cron jobs automatically downloading updates to other machines I have, I have encrypted backups of the file that stay in sync each day, so little risk of losing them, and only one master file to update.
Too many points of failure. Too many places for abuse. Too much uncertainty in the trustworthiness of identity providers. If I use a compromised computer I loose everything at every site that accepts the openID. I don't yet know what the solution is, but this is not it, and I will not use it.
-John Fenley
For the security-minded readers here on Slashdot, it is pretty much certain that some have already been doing something like this in their heads, for years.
Sxipper just came out today in beta, it looks interesting. Sort of like a much nicer roboform with OpenID support baked in, and collaborative form mapping (and for firefox of course). Check it out.
Metamuscle.com - News in the Iro
Come to think of it, I probably have seen it written as I.D. in the past. You make a good point.
They may be able to "steal" an old OpenID URL in the sense that they are now able to identify themselves as owning it, where previously you identified yourself as owning it. However as I said in my original post, they do NOT automatically steal any more personal information you might have associated with your OpenID, such as financial details. This would only happen if your OpenID provider was hacked into, or if you were running the provider yourself, and they inherited the whole server - disk contents and all - rather than just the domain name.
If you want to keep your OpenID URL constant, then yes, you do need to maintain ownership of that URL, regardless of whether you're using delegation. However if you are using delegation, then you can lose your entire web hosting account and simply start using the non-delegated URL directly without having to re-enter any other information you had stored in your OpenID account.
I see two scenarios:
There is nothing to stop an OpenID-enabled site from taking simple details - such as name, email address, age - from your OpenID profile automatically, and allowing you access to features which simply require an identity (e.g. comment posting), but then optionally require some site-specific secret on top of that in order to use features which require trust (e.g. financial transactions). True, this goes against the holy grail of single sign-on, but it is one way to add a trust layer to a system which, due to its decentralised nature, can never guarantee that old identities do not get re-assigned. There may be other, more elegant solutions, but it is important to notice the need for such a layer.
Continuing on the theme of e-commerce, is there a need for a trust layer in the event that OpenID consumers never cache sensitive data? Someone could steal your OpenID URL and sign in to a shopping site you've used, but unless they have already stolen your credit card number by some other means, their OpenID provider will not be able to give that information out, because it won't know it (assuming your OpenID provider has remained secure).
Great idea! I just tried. Didn't work...darn it!
Back to practicing my light sabre skills and my Vulcan mind-meld technique.
That's a sensible point, and is part of what I was trying to get at (only much clearer).
My point was not that OpenID is useless -- I like the idea -- but that for widespread real-world adoption (and for me), it's only one part of an overall solution. I'm not sure what the other parts would look like, but you posted some interesting ideas later.
And solving one problem at a time is sensible -- after the problem has been broken down into clear and understandable parts. The Open ID article and the original summary could have done a better job as saying what it was and what is wasn't about.
Paul "Say no to feeping creaturism"