Slashdot Mirror
OpenID - Open Source Single-SignOn
Nurgled writes "Danga Interactive, who created LiveJournal and memcached, is working on a new decentralized single-signon system called OpenID. Similar in principle to Six Apart's TypeKey or MSN Passport, OpenID will allow you to assert a single identity to any OpenID-supporting site. The difference here is that there is no central authenticating server: anyone can run one, and Danga's reference implementations will be open-source. The site you are authenticating with never sees your username or password, just a one-time token. You can read the initial announcement on LiveJournal, though some details have changed since that post, so be sure to read the information on the official site."
So this is a distributed ID system, that is open source. I'm not sure that this is a good idea, but am willing to try. Hell, anything beats Passport. I think that if Slashdot adopted this (OSDN), it would attain critical mass.
--sig fault--
I coincidently not long ago wrote a paper (ggogle cache) on how to implement RSA-based signle sign-on (using Python/mod_python). Using public key signatures seems like the most obvious way of implementing SSO. I'm surprised OpenID is using DSA though - AFAIK RSA (now that it's patent free) is a superior, more trusted and flexible algorithm.
I'm not a cryptographer by any means, but IIRC DSA was put together by NSA as an algorithm that was "crippled" to only do signatures, but not encryption, and there was some controversy because at first NSA wouldn't admit to being the designer, instead NIST was pretending to be one, and then later someone discovered a way to somehow leak bits and it is still a mystery whether this was intentional on the part of NSA or not.
Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?
Why is this in Hardware? Shouldn't it be... IT?
Now if my bank, my broker, and my webmail all did this I would be one happy person. But this sounds like this would do the same thing as stored numbers on the phone did to me I forgot almost everyones number.
The difference here is that there is no central authenticating server: anyone can run one, and Danga's reference implementations will be open-source.
But how are we gonna control the world? Palladium sounds like a better idea...
while it certainly would be nice to login to one spot and be logged into all my favorite websites, as a webmaster I use different information based on what part of my site the person is logging into. Their username/password might be the same for both pages but a cookie might be set on one that isn't on the other and doesn't need to be on the other or could be harmful if done.
Admittely, I need to read up on this, and it's definitly an interesting idea to have a single login but I think there are some behind the scenes issues that need to be worked out.
Also the decentralized nature of the servers has me worried/confused. So if I ran one, would I have everyones authentication information?
-Teiresias
yeah, Zonk, this really belongs in the "hardware" category. heh.
The demo didn't seem to work for me, but others are already playing with it. Kind of cool, really.
What would be *really* cool is if news websites would let us use something like this instead of having to create usernames & passwords for every news site we want to read (or w/o having to leech a login from bugmenot)
I'll authenticate with each and every site I visit...
Take MS Passport for example. I log on to MSN webmessenger. I chat with some friends, then I close it down. 3 hours later I decide to log on to MSDN to grab a file, I need to log in with a different account since my messenger account doesn't have the access... fine... I do that... then a few hours later when I go to webmessenger again, I'm auto-logged on with my MSDN credentials.
The only option I have is to force all passport sites to stop caching my username/password and make me type it in everytime, thus defeating the purpose entirely.
This sort of password system is open to all sorts of problems, and not just of spoofing, or somehow being hacked and having people impersonate you... I'm more worried about logging on to some place with the wrong credentials...
---
Programming is like sex... Make one mistake and support it the rest of your life.
Pay me 25 dollars (iname) to get a name is not the same as identity
Register with your 'name' and 'email' (typekey) is not the same as identity
Single sign-on (passport, openID)is not the same as identity
so, if it's open it's good but if it's M$ it's evil with regards to single sign-on? Aren't there a lot of other considerations with regard to security and single sign-on. Such as one login gets you into banck accounts, and pretty much everything else.
If you really want this use something liek keychain (on a mac) but in general one password to control them all isn't such a good idea.
Evolution or ID?
if anyone can set up a server authenticate does that mean they can access my information? or track my movements? i am thinking of abuses.
always mosh clockwise
Suddenly single-signon, long viewed by the open source community as evil because of numerous reasons, becomes the darling of the open source world.
Here's a clue. Novell has already mastered single-signon and federated identity management. They've had it for a few years now.
But, for the record, I hate Passport with a passion, and I also hate having to sign in to comment on blogs or journals.
In the business world, directory services are dominantly Microsoft's Active Directory, which is essentially a variant of LDAP, which is common in other operating systems. If this thing can't link up or mate to existing directory services, they're screwed. Very, very few companies will want to have to redo their entire directory service just for the fun of it. AD uses Kerberos to handle things, so it's not like there's not a possibility of linking Linux or other boxes to an AD tree in some capacity--if an AD plug in or process is available.
Not to mention that MS makes it worthwhile to move by allowing SSO functionality not only with their products but through support of third parties. This thing is bush-league in terms of what it can really do for folks now. Not that I wish them ill, but the winds of change are tornadic when you deal with the MS juggernaut. Metaphorically, you can't just offer a better butter like these guys, but you have to offer a better bread, how to bake it, steps on making your own butter, and new flavors. You have to offer a complete solution as well as a complete, hassle-free, and justiable means to move to your product. I know it's Open Source, but simply being "free" isn't enough incentive.
Hell, even Apple offers support for Active Directory in their OS.
Vos teneo officium eram periculosus ut vos recipero is.
I am not disputing the value of anonymity, but ID services that are open and free are need. Otherwise these services will gravitate towards Yahoo, Google, MSN etc. Make you choice, free or them.
You're not missing anything.
I believe this phenomenon is called a "mistake".
It happens every now and then when people do things, but end up with results that are unexpected and not satisfactory.
Depending on the level of damage that such a "mistake" causes, people have differing reactions.
Some people react quite analy to even the slightest of such perturbations, perhaps making a note in their daily blog, while others recognize them as being insignificant, and go on happily about their lives.
More information can be found here.
If you don't know what AltaVista is (was), get off my lawn.
when everyone can run a server? I can see this being used for signin across multiple websites run by the same company, but not much else. You certainly won't have a single pervasive ID.
I am trolling
What I want is a system where I go to a site requiring a login and it asks my browser to sign some data with my private key. During the account creation I send the server my public key and that's that -- no need for a password and the login could be done automatically using cookies or something. Then there is no need for a single sign-on provider and nobody can globally revoke my account at all sites.
You could still have an 'id provider' that could sign the data on your behalf if you are on a internet cafe for instance, but it would not be required by design. So in 'kiosk mode' the browser could just forward signiture requests to the authority after you logged into it (which could even be your home computer).
This should be pretty easy to do as a firefox plug-in.
I already have a working single signon. It's called Windows XP login, using IE with autocomplete turned on you never have to enter any passwords online. IE works better than Firefox; as unpopular as that is to say around here. I just can't subscribe to all the Microsoft Bashing.
Any reason to think this will be more widely adopted than liberty alliance initiatives?
The reason I ask is that the technology is a walk in the park compared to the much more difficult problem of trusting an external system to authenticate for you.
Given the amount of Microsoft, Apple, Google, and other big-name-company stories that, otherwise inexplicably, have been termed "news", and "stuff that matters", yes.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
This under the hardware category... am I missing something?
/. if you noticed/care about that.
Yes, a life. Hmm, that sounds much harsher than I intended it, but you may be paying a little too much attention to
Novell has provided a superior solution. Novell's directory is not only superior to Active Directory in almost every way, it also has the ability to provide universal single signon. It does this via federated identity management and has been available for several years and have proven to be more reliable and secure than any Passport solution.
Also, for those that already suffer under Active Directory and do not wish to rip and replace their directory infrastructure, Novell provides the tools to let eDirectory manage Active Directory and synchronize directory changes between the two.
Similar to what you stated, but better, Novell's eDirectory allows for easy integration of all systems including Linux, Mac OS all, Solaris, Windows, AIX and more. eDirectory is fully accessible via standards based LDAP and does not suffer from proprietary Kerberos extensions that impede cross platform integration.
http://lid.netmesh.org/ - I've heard good things about LID, and it supports SSO.
I hope it work with AdultPass sites too.... it's a nuisance to have to remember all those IDs...
Throwing one password around to control everything?
That's a fine example of putting all the eggs into one basket.
Count me out.
Did I read that right, that anyone can run one of these OpenID Servers. So now I can setup a server and have everyone's passwords and usernames filter into it. I'm not to sure about this.
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
How many want to bet if this takes off, Microsoft will EEP it (Embrace, Enhance, Proprietarize) and turn it into a closed "standard" and force it onto the Windows addicted populous (which at the moment is a large percentage of desktop users?)
This is yet another attempt at a SSO solution. It is not too hard to come up with a rough design for one. The main problem is getting a significant number of sites to use the same one. Otherwise, what is the use? Marketing/advocacy is needed for that.
Although I admit I have not tried it out yet, have people already forgotten about the Liberty Alliance Project? There already exists an open source implementation, SourceID. Why not contribute effort to working with that library? Or if you must have the enjoyment of writing your own implementation, why not at least try to be interoperable with an existing spec?
Passport didn't fail for lack of Microsoft's trying, or even all that much on (lack of) technical merits (it had flaws, no argument there, but for the most part it did work acceptibly well).
It failed because, on the corporate side, no one wanted to hand Microsoft another monopoly, over the "electronic identification" market - Thus, really only Microsoft-run sites and a handful of "partners" accepted it. On the personal side, those who actually care about such issues abhorred the idea of having a single, non-anonymous identity, and those with only little bit of a clue liked it but worried about how microsoft would treat their information (while the masses of lemmings out there use the same password for any website that asks, their ATM pin, and their email, so didn't have a problem keeping track of all those nasty passwords in the first place).
And what do we have with this new system, that will make it any better?
Companies might use it, but they'll each want to run their own server, making it no more useful than just having 200 accounts spread across as many websites, as we have now. Those who really understand all this still won't want to use anything that doesn't guarantee total anonymity, and those with a partial clue will still worry about who can do what with their info. And, of course, the lemmings will just see it as one more request for their ATM pin number, but otherwise won't notice the difference.
We need decent MS office import filters. We need a solution to spam. We need a cure for cancer. We need new games that don't suck. Please, people, if you code in your spare time, STOP WASTING TIME SOLVING NON-PROBLEMS!
This is a problem that already has a solution in production. Using pubcookie for the single sign on, and Shibboleth for the distributed trust relationships.
idiots (AKA teen girls)
You just sent LiveJournal's membership higher than that of AOL.
Gotta run. Gotta get over to LiveJournal and sign up!
I didn't RTFA, but ever since Passport came out I wondered why they would want to auth to a remote server when you could just auth to your key, then have your browser act as an agent(or forward to ssh-agent) and let the remote host auth via pubkey, exact way that works securely and easily for ssh.
The way my X11 is setup now all I have to do is startx, enter my password in ssh-askpass, then I can freely ssh to any server I want without entering a password. I can also ssh from there to another server, still passwordless, still based on my original authed key.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
This problem is best solved using standards, not by supplying a new software platform. SAML, Shibboleth, and Liberty have all been around quite a while, fill this need quite nicely and a number of different implementations of each protocol exist, including FOSS and commercial options. Features like pseudonyms and selective information sharing are already there. Why do we need another way to do this?
Delivering militantly anti-commercial music to all two people who care!
Well, if you prefer it, you can also read the IT version of the story. Or maybe you prefer Your Rights Online?
The Tao of math: The numbers you can count are not the real numbers.
Doesn't this make it THAT much easier for a break in, or identity-theft? Now if tons of sites and companies support this, hackers only need to break through ONE barrier to steal your identity. In general, anything that makes the user's experience easier, it also makes it less secure. But thats just my .02
Inexplicably, AD seems to interoperate with other Kerberoses. In my current contract a Generic Huge Financial Services Company we authenticate our Apache servers (internal, htaccess-type auth) running on Linux against AD. No reason why we could not add our Solaris and Linux login authentication to that.
I do not administer the AD boxes, those guys are on a different continent, so I don't know what kind of kludges those guys had to go through to get this to work. But in view of the recent Scott McNealy - Steve Ballmer kiss-fest over Solaris-Microsoft interoperability, yes it isn't much of a stretch anymore.
This is On Topic because I agree with the original poster - any SSO has got to work with AD to be successful.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Would you like to have one single key to open any door, lock, car or locker you have?
Single sign-on.... What's that? too lazy to memorize a bunch of passwords?
Yadis is correctly described as distributed single sign on, not decentralized single sign on. Everyone still has their dedicated central identity server, it's just that requests from other sites can be delegated to your server instead of requiring only one for everybody.
distributed != decentralized!
Can anyone tell me what the single signon hype is all about? How is single signon any different than using the same password for multiple websites?
That's a common misconception. We have no problem with people making money from your password. It's the attempt by some to restrict freedom and keep your password all to themselves that we are against.
We would support, for instance:
Your password wants to be Free. We urge you to set aside the bondage in which your password is held and join with us for a better community.
[Gnoll mode: OFF]sigs, as if you care.
I like this quite a bit. However, I think it's suffering from the same problem most people have with the term identity on the Internet -- binding.
"Identity," formally, means who you are -- the unique person with your identity. I'm not going to write my real name here, but that's my identity. No one else is me: my identity is bound to me, even if there are people with the same name.
"Identity," colloquially, means "that person I know." You may not know me by my name. You know me by "daedala." That's my handle. I always post here as daedala, so that's my consistent presense on slashdot (and my journal, and my email, and most other places I post...).
It's pretty difficult to establish a unique identity, bound to an individual, on the Internet. People screw this up all the time. It's not nearly as difficult to establish a consistent handle. From my review of this system, what it's doing is the latter.
So really, they should be calling it OpenHandle.
What I say does not represent the views of my employers, my friends, my cats, or myself.
Brad at LJ LOL
Authentication (username - password/tokencode/biometric/whatever) is generally the first step to establish a digital identity. This reqires some trusted source to be able to judge if the credentials are sufficient to establish the identity.
From my quick reading, OpenID doesn't try to do this and leaves this up to the "identity provider" which can be a centralized service or even my own home system. OpenID is more concerned with mapping whatever identity the user chooses to use consistently across the sites they visit.
This makes sense for sites that care more about consistenty mapping a user to an ID, but don't really care who the user is (like Slashdot), but makes absolutely no sense for any site that actually needs to know something about its users (banking, commercial, etc.) Until such time that there is a commercially trusted source of identity (yah right), sites that perform any type of regulated or high-risk activity will have the responsibility of identifying their own users or federating with other entities that they trust backed with legal/liability agreements.
IMO: This is doomed to blogspace and sites where liability is not an issue. If you're serious about SSO, look to SAML.
I don't think RSA is overall more trusted than DSA, and I certainly don't see a way in which it's more flexible for this application. It was designed only to do signatures, but that's fine, since only signatures are needed here.
When you say "leaking bits", you're probably thinking of subliminal channels, and you're referring to some rather out-of-date information in Applied Cryptography. It's now established that all secure signature schemes have subliminal channels; they have to be probabalistic for the security proofs to work, and that's enough to give a "low-bandwidth" channel for anyone who doesn't know the signing key, or a "high-bandwidth" chanel for those who do.
DSA is a perfectly good choice here.
Xenu loves you!
It's not helpful for e-commerce, corporate intranets, campus-level signons, online banking, or spam prevention.
How is this different from Kerberos? Why not just use kerberos?
It's fairly easy for Unix boxes to authenticate against AD. The reverse is not true for Windows machines.
"any SSO has got to work with AD to be successful"
Not true. The Internet and Intranet are entirely different environments. One is controlled and usually managed centrally, the other is uncontrolled and managed in a distributed fashion. A solution which is appropriate for one may not be appropriate for the other.
Deleted
This makes sense for sites that care more about consistenty mapping a user to an ID, but don't really care who the user is
Since sites like that have a real problem with identifying people so they can sanction spammers without making it too hard for regular joes to participate, this is a valuable tool. If it can be used more widely that's a bonus... and you have already suggested one way it COULD be used more widely:
sites that perform any type of regulated or high-risk activity will have the responsibility of identifying their own users or federating with other entities that they trust backed with legal/liability agreements.
For whatever reason (could someone wager a guess?) SAML has not been widely adopted (and don't try to argue this point). Maybe this will rectify whatever deficiency SAML has? Or maybe the project is just to create a widely-usable SAML authentication authority?
Doesn't multiple competing standards for single sign-on basically defeat the purpose of single sign-on since all the sites you visit will have all hop on the same bandwagon?
OpenID asserts a URL, and that the person using the browser has control in some way over that URL. How you are authenticated is up to your OpenID server's implementation.
It could be LiveJournal, TypeKey/TypePad, your corporate website using LDAP or AD, whatever.
A hypothetical example:
John Carmack forgets his password again, and wants to comment on a Slashdot article about rockets and Quake.
Assuming Slashdot has OpenID support, he can supply his URL: http://www.idsofwtare.com/~johnc/ and Id's OpenID server can assert that URL.
Slashdot can (if it chooses) do some autodiscovery and fetch a FOAF/vCard/hCard/whatever to fill out some user data so he's identified as "John Carmack" on the comment.
I mean, I shouldn't be surprised, but I am. It seems liek 90% of the people commenting didn't RTFA, or didn't have their brains installed at the time. This isn't a secure banking system - it is, as one person pointed out, probably better described as OpenHandle. You sign in ONCE, and from that site, you tell it which other sites can authenticate from your identity site. Then, these sites know who you are. They don't get your password, or anything, they just get a temporary key to verify that you're you. Any site can fake it, that's not the point. The point is that you have participating sites where you would want to now have to sign in every time you want to comment. It helps prevent lock-in to blogs etc - imagine, for example, you sign in to slashdot, and then you can use the same handle without having to create accounts and sign in at other blogging services. THAT's the idea. It's not a trust net, or a passport-like system, it's just so that sites that want to play by the rules can provide people with a convenient way to identify themselves. That's ALL.
This is explained on the Web page.
It's not single-sign-on beccause you have to fill in your homesite at every different site you log in to. But it doesn't claim to be SSO, either; the submitter mangled the story as usual.
As in "Gnomic Troll", maybe...
Why don't we just use a single password entered by the user (once per session or once per browser..depending how it's saved) to generate tokens unique to each site a user browses to. Pass those tokens to the site automaticlly as part of the http headers. No need to ever send any login data through a third-party. No need for any complexity on the part of the end-user or website designers. Just a small bit of extra code added to the browser and webserver (optionally). Firefox and Apache could do this easily enough.
Heck you could have the browser send these unique user and password tokens automaticlly whenever the website asks for http auth. Nothing would even need to change on the server side. Just a small change to the browser. The chances of two users both having the same username and password aren't that high unless they pick something really easy to guess anyway like a name and password they see in a movie.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Just thought I'd add that as of Jan 2005, Six Apart owns Danga, which is the parent company of LiveJournal.
We have this already, it is called digital certificates. I get one digital certificate that identifies me and I use it on multiple sites. Now if more sites just supported authentication by digital certificate, a process supported on all web servers already then we would be done. Why do so few webmasters understand digital cerficates? Do we expect them to understand this any better?
It looks like this system doesn't make an attempt to verify that the person attempting to sign on is actually the same person who was authenticated in the first place.
From the spec:
openid.is_identity -- The identity URL the client is asking the ID server to verify. The exact question is: "Is the user logged in to your site represented by this URL, and do they allow the trust_root (and therefore the return_to URL) to know that?"
So, Alice's identity is represented by a URL and the system doesn't verify that the URL submitter is actually Alice. All that is verified is that Alice is logged in and that she trusts the submitting site. So, what is to prevent Eve from making a request that verifies that Alice is logged in and then making a post that spoofs Alice? As long as Alice is logged in and Eve knows Alice's identifying URL, Eve can spoof Alice.
Unless I'm completely missing something, this (short) "spec" needs a little more work. Say what you will about PassPort, but at least it used PKI on the client to solve this little problem.
I RTFA'd and OpenID relies on a single host as an authenticator, just like Passport. Sure, you can have many single host authenticators with OpenID (whereas there can only be one with Passport), but at the end of the day, your credentials are only as strong as the security of that one box. Remember all the problems that Microsoft had with authenticating and authorizing Hotmail users? Single hosts make inadequate authenticators. The CorSSO folks fix that problem using threshold cryptography - in CorSSO, an attacker has to compromise a group of different hosts all at the same time to usurp someone's identity, which can be made much harder than compromising a single host in OpenID.
From the sound of this, you log in to one site (your homesite) with your real username and password, and after that it uses digital signatures and a list of trusted sites to prove to that site that you are the owner of the URL.
I see several problems with this, one of them being specifically that it doesn't require a password everywhere you login. I know the point of single sign-on is to have one username and password for everything. However, think about your average user: when prompted with a dialog box asking "Would you like to trust this site?" or "Would you like to install our malicious software?", they have an uncanny habit of clicking "Yes" without thinking. I think this will become a problem as well--people authorizing any site just because it asks, and not realizing what it means in the end. Requiring password entry and making the requesting site very clear would make it much easier for users to know what they are doing.
Tired of free iPod sigs? Subscribe to my blacklist
I don't like the idea of using URL's as an identification system. Sure, within the blogosphere, this is great since most people *are* identified by the URL's of their websites, but what about normal people? It's hard enough to explain the difference between an email address (username@host), a URL (host/resource), and a login (username and password), and it's worse that some sites use your email address to login and some use a username, but this is the worst. It means that URL's, which are supposed to represent a resource, can now be used as usernames. While it's a creative and practical solution, it will be really confusing to people. Jabber got it right with username@host usernames.
Tired of free iPod sigs? Subscribe to my blacklist
It seems like this is only half a solution. All it does right now is allow responsible sites to ensure that you are the owner of a URL. It doesn't have any way (yet) to prove that you wrote a comment, or that you didn't. Basically this means it will be useless, because unless a site operator blatantly forges identities, they can change individual comments to say what they want and there's little that can be done to disprove them.
Tired of free iPod sigs? Subscribe to my blacklist
I see one major problem with this, related to the fact that it uses URL's: it requires an HTTP server. By requiring an HTTP server, it requires you to either run your own server, get a free account somewhere, or pay someone for one. Running your own is beyond the expertise of many users, and even with a nice program for it, dynamic IP's and stuff will get in the way. The problem with offering this as a free service is that there is little incentive for a site to offer the service alone. There are few chances to display ads, and users won't stay on your site. Lastly, people probably aren't willing to pay for such a service, since it's only a minor convenience. I see two outcomes: it becomes an ISP-based service, like NNTP, or it becomes integrated into other free portal things like Yahoo! or the Google Non-Portal.
Public key authentication is better because it requires less infrastructure... all it requires is a place to store public keys (easier than the requirements of OpenID because they're static data).
Tired of free iPod sigs? Subscribe to my blacklist
I do wish the authors success but OpenID is simply another protocol for asserting identity information. What is fundamentally missing, especially in OSS, is a mechanism for implementing identity. In truth implementing identity is something that is also missing in the plethora of commercial products which are seeking to provide solutions in this space.
Globus/GRID, Shibboleth, PubCookie, LID and a legion of others are already implementing mechanisms for making assertions about an identity. The fundamental problem with implementing any of these technologies are the back-end systems for implementing and protecting identity and a manageable system for tracking differential acesss (authorization) at a high level of granularity.
The Open-Source community is currently lacking any respectable effort in this arena. All the basic pieces are there with LDAP, Kerberos, SAML and a host of other technologies. What is required is a coherent framework which implements all these technologies in a manageable package of infra-structure. It will be where the real war for control of information delivery gets won or lost for OSS technologies over the remainder of the decade.
As I noted in the first paragraph what is fundamentally lacking across the spectrum, commercial or otherwise, is a fundamental definition of identity. Its interesting to see that a couple of other posters have noted this as well. Our Hurderos Project is trying to address that with an OSS solution in an attempt to turn the tide of everyone inventing their own solution.
Getting that type of basic infra-structure laid down is key to unlocking an entirely new generation of application and information delivery architectures. It is also fundamental to addressing the intrinsic problem with federated or distributed identity systems which is the very real and very thorny problem of target sites asserting authorization over remotely authenticated identities.
In the brave new world of highly distributed information delivery systems with a mobile consumption (client) base the only important thing is 'who you are and what do you have access rights to'. He who controls that will control everything.
LID -- Light-Weight Digital Identity -- is an entirely decentralized digital identity system that uses URLs as identifiers. Yes, you can host your own. It's so simple, the average Slashdot hacker can probably implement from scratch in an afternoon, and it supports SSO, VCard-based contact management, FOAF-based social networking, authenticated messaging and many other applications.
http://lid.netmesh.org/
Disclaimer: I'm one of the people who came up with it. I also talk about it and other systems on my blog at http://netmesh.info/jernst.
Which would you prefer to be?
http://thinkinginbinary.webhop.net/
or
MooseGuy529
The problem with user@host is that it resembles an email address. OpenID asserts a URL, not a user, which is an important distinction.
That URL does not have to be http. It could well be mailto: or data: or gopher: or whatever.
I'd like to see an authentication system that used OpenPGP keys.
e.g. I go to the bank with my photo ID and my OpenPGP key fingerprint and say "this is my key".
When I want to autenticate with the bank, they use my public key (which they can get from a key server) to encrypt a secret and send it to me. I demonstrate I have the private key and know the pass phrase by decrypting the cypher and extracting the secret ... more hand-shake stuff and ...
... authenticated!
I don't need the bank to know my password, and I can have one password for everywhere that uses this OpenPGP based approach.
I can't imagine a Kerberos (or Kerberos-like) single sign-on mechanism would be a huge step (relatively speaking) from this point.
check out V-ID. They have an free to use single signon system running right now.
Also see SourceId and Shibboleth.
Admittely, I need to read up on this, and it's definitly an interesting idea to have a single login but I think there are some behind the scenes issues that need to be worked out.
Yes.
This system intends to provide provable same identity across multiple websites. However, it has some drawbacks.
* This is billed as a single-sign-in approach. There are technically superior approaches to single-sign-in, such as the Password Manager in Firefox. The PM approach does not leak your "real" identity to everyone. While Firefox does not (I think) support centralized storage of PM data, it's certainly possible for it to do so or use a system like this. The real benefits of this are that you can prove that your identity in two places is the same thing in a standardized fashion, so that we know that ltorvalds on slashdot really is Linus Torvalds.
* No support for progressive release of information. I don't want to tell every website (let's use www.trollnet.org as an example) that I'm "Michael Hotwitz", because they don't need to know that. All they need to know is that I'm User 3452351, and I want to be able to sign in using my single password. No information is leaked this way (other than what a cookie would already give them, that I'm the same user that visited their site before). If, at some point in the future, I decide that I want that website to know that User 3452351 is also mhotwitz@slashdot.org, the much famed GNAA poster, so that I can revel in the appreciation of my troll buddies on www.trollnet.org, I can tell them so. A simple form of this would be identity merging, where I simply prove that my two identities are the same, and they become "merged". A slightly more sophisticated approach would be to allow proving that an identity on two particular sites is the same, without "merging" the two, so that site A knows that ID1 == ID2, and site B knows that ID2 == ID3, but neither necessarily knows that ID1 == ID3.
* The auto-fill-in web page approach recommended by the OpenID people is a bad idea. If I make a form that I can convince a user to submit, and stick the auto-filled-in field at the bottom of a web page, I can harvest unique, cross-all-websites identities for each user.
* This system relies on DNS for the Availability security property. While, with root cert caching, someone attacking DNS can't fake your ID, if someone else gets your domain because it expires, you lose your identity. I've seen domains come and go, but I still use the same GPG key. Also, this puts Verisign back in the driver's seat for controlling identity management, and frankly, I and most techies trust Verisign to Not Be Evil about as far as we can throw them.
The main advantage of this system is that it doesn't take any client-side support to roll out.
I'd rather see someone write an Identity Manager extension for Firefox and a plugin for IE, a program that uses GPG as a backend and can sign a few standardized messages, like "You can trust this other ID to also be me" and "I'm compromised". No identity leakage inherent to the system, can have IDs stored on a server if you want but you don't have to, Verisign isn't involved in the system, no availability attacks on IDs through DNS registration expiry or DNS spoofing services. You could play each new MMORPG with a persona that enjoys the reputation that you've accrued in the past -- as being a helpful person. People who abuse systems and are no fun to play with don't build up a reputation and are easy to identify.
I just can't figure out why people are so damn eager to tie ID and trust systems to DNS -- one of the places that there really are some solid objections to DNS. It's like people have DNS hardwired into their brain these days.
We need new games that don't suck.
Take a look at the top-rated games on happypenguin.org recently? They still generally don't have the visual flair of a typical commercial product, but the games there have gotten pretty decent, without the incredibly steep learning curve that has generally associated the better open-source games in the past (like nethack). Try Battle for Wesnoth, for instance.
If this open, secure, distributed authentication scheme works, maybe it could be used to achieve the US RealID program's (stated) goals. I especially like the idea of allowing an authentication request only a boolean, rather than caching any associated info. Until such a system works, the US shouldn't create a monster that doesn't. Real world test iterations of OpenID might get us there.
--
make install -not war
That URL does not have to be http. It could well be mailto: or data: or gopher: or whatever.
Based on my (admittedly hazy) understanding, it has to be HTML over HTTP, because the web server that's identified has to include a special <link> tag in the web page that identifies the identity server that says who's authorized to "claim" that URL.
I'll admit, some of the cryptographic and network theory discussed in the proceedings on the Cornell site, but it looks pretty solid. I'd be interested in how the OpenID people respond to the radically different design direction the Cornell group took (for good reasons, it seems) while essentially solving the same problem.
What I like about the Cornell system is that Goal #2, which would be right after "Provide a single sign-on abstraction", is "enable applications to tolerate failed and compromised authentication servers." The idea of compromised authentication servers doesn't seem to enter into the OpenID framework. Maybe I'm missing their solution somehow.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
End-users can be protected from knowing about all this by their service, though. LiveJournal users, for example, can log in as "user.livejournal.com". This doesn't look like a URL, but it can be transformed into one. This does get tricky for established mass-hosting blog sites because they don't have such pretty-looking URLs already. A Xanga user would have to sign in as xanga.com/username, for example. Supporting whatever.xanga.com would require a DNS wildcard record, and they (like LiveJournal, in fact) might already be using some of their existing usernames as real hosts within their domain.
Hopefully at some point sites which only provide identities and no other service will spring up, and they'll provide URLs like that which don't actually go to anything except a blank HTML page with the right ID server link in it. I guess eventually anonymizing sites will appear which will allow anything.theirdomain.com and just approve it without question, though of course those sites will no doubt get banned from most sites pretty quickly because they'll be used for spam.
Not necessarily. The OpenID client can look at your URL and fetch the link tag just as easily:
mailto:foo@bar.com -> http://bar.com/ -> http://bar.com/openid/server
Or if you like, leave off the mailto: entirely, like you can with the http:/// and have the client assume user@host means "go fetch the OpenID server from the top level host."
The problem OpenID attempts to solve is "Is this person who claims to have been here a week ago really the same person?", coupled with "Is pla who posted on slashdot the same person as pla who posted on my weblog?". That is it, really. There is no profile information shared explicitly by this system, though from reading the mailing list they seem to expect that people will invent mechanisms for doing this to complement OpenID. Sites which implement OpenID but only allow their own identities to log in would have missed the point completely. Even if no-one else uses it, LiveJournal, many of the LiveJournal clone sites, TypePad and MovableType will all support it, and that accounts for a large chunk of the weblog and journal users online. Any other support is a bonus, really.
As for anonymity, all that's needed for that is an ID server which will approve any arbitrary user within its domain. A bit like Mailinator but for identities rather than email. It's likely that such a site would quickly get banned from everywhere due to the spam it would be used for, but that's no different than certain sites disallowing anonymous users.
Regarding coding in spare time, I code stuff that's interesting or useful to me. I probably wouldn't have written a distributed identity system, but I can see why the Danga folks did it: they scratched their own itch in a manner which simultanously scratched a few other people's itches. I have no use for any of the things you claim "we" need. Different people need or desire different things.
Cool, thanks for the briefing.
Ideally, wouldn't the identity authorities establish a web of trust amongst themselves, allowing a user to be authenticated by any one of them and then access any authentication consumer? Hell, I think most people would be more willing to grant Passport a monopoly if they were using open standards that would prevent lock-in.
So the real problem is that no one has figured out a business model for being an id authority other than to extend a monopoly?