Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet Networking Security

OpenID - Open Source Single-SignOn 209

Posted by Zonk from the throwing-your-name-around dept.
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."
This discussion has been archived. No new comments can be posted.

OpenID - Open Source Single-SignOn More

OpenID - Open Source Single-SignOn

Comments Filter:

  • Hosting Servers (Score:3, Interesting)

    by NETHED ( 258016 ) on Thursday May 19, 2005 @12:40PM (#12579708) Homepage
    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.

    • Re:Hosting Servers (Score:4, Insightful)

      by Turn-X Alphonse ( 789240 ) on Thursday May 19, 2005 @01:16PM (#12580113) Journal
      you forget something.

      Slashdot maybe large but live journal's user base (myself included) is also very large. Most of them are idiots (AKA teen girls) so they would instantly start using it and think it was a great idea to only need to sign onto one site ever.

      If "average whiney girl mark 3" thinks it's a good idea she will tell her friends and it'll spread like wild fire through the mass market. The geeks can't control this only choose if we listen to the cries or get snowed under with them if this happens.
    • We'll definitely give it a serious look!

      Yeah, Slashdot might help raise awareness in the geek community, but as far as general "critical mass" goes, LJ has zillions [livejournal.com] more active logged-in users than we do :)

      • Re:Hosting Servers (Score:5, Insightful)

        by soupdevil ( 587476 ) on Thursday May 19, 2005 @01:44PM (#12580448)
        But Slashdot readers are more likely to manage their own sites which would be candidates for using Open ID, which makes Slashdot potentially more valuable.

        • Re:Hosting Servers (Score:3, Insightful)

          by Nos. ( 179609 )

          And this is the important point. For some reason, users of web services don't typically demand features like consumers do in other markets, at least not to the same degree. New features usually are first designed by site/owners/programmers/designers/masters/etc and then copied by countless other sites.

          So, having a large population of readers that also maintain or run sites see and believe in an open system like this is probably more important than the user base knowing about it. Lets face it, if everyon

          • And you say that because putting Microsoft technologies out of business has already proven to be so simple?

            No, I'm afraid the only way to make Pi$$port go away is to keep it out of sight. It pops up right away after any user logs in initially (in XP). That's why people sign up for that service. They see it pop up, so they immediately fill out the form, like good little form-filler-outers. And web sites see their subscription numbers, and then adopt Pi$$port. Can you say "Court injunction"?

    • 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 e
    • There was a recent paper [cornell.edu] at IPTPS on this problem last year.

      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

  • Why DSA? (Score:5, Interesting)

    by gtrubetskoy ( 734033 ) * on Thursday May 19, 2005 @12:40PM (#12579711)

    I coincidently not long ago wrote a paper [72.14.207.104] (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.

    • I am a cryptographer, and this isn't so. (Score:4, Informative)

      by Paul Crowley ( 837 ) on Thursday May 19, 2005 @01:50PM (#12580506) Homepage Journal
      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.

    • Can you please put a few more acronyms in your post next time? ;)

    • Re:Why DSA? (Score:3, Informative)

      by nickovs ( 115935 )
      I'm surprised OpenID is using DSA though - AFAIK RSA (now that it's patent free) is a superior, more trusted and flexible algorithm.

      As a professional cryptographer I certainly don't think that DSA is in any way inferior for the task in hand. It is however superior in one significant way: if you use a 1024 bit key then the RSA signature is 1024 bits, which takes 171 bytes to base64 code, while the DSA signature only takes up 54 bytes.

  • Open (Score:5, Funny)

    by callqcmd ( 868085 ) on Thursday May 19, 2005 @12:41PM (#12579716)
    Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?
    • Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?

      Yes. And if you with hold your password, that is like withholding propritary info and not opening it up.
    • your password is already being distrubited

      just
      cat /dev/random | grep yourpassword
      itll show up eventually, after some 31337 h4x0r posts it

    • Re:Open (Score:2, Funny)

      by mazarin5 ( 309432 )
      I've forked your password:

      *****+

    • Free as in Freedom (Score:5, Funny)

      by RealProgrammer ( 723725 ) on Thursday May 19, 2005 @01:43PM (#12580438) Homepage Journal
      Does it mean I have release my password per GPL and anyone is allowed to modify and distribute it for free?

      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:

      • sending your password out on a tape and charging $100 for the tape.
      • charging you $100 for your use of the computer resources on which your password is stored
      • charging you $100 for the support of your password
      • charging you $100 for this response

      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]

  • Wrong category? (Score:2, Insightful)

    by Anonymous Coward
    Why is this in Hardware? Shouldn't it be... IT?

  • Certain Information (Score:4, Interesting)

    by teiresias ( 101481 ) on Thursday May 19, 2005 @12:43PM (#12579740)
    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?

    • Re:Certain Information (Score:2, Insightful)

      by alecks ( 473298 )
      So if I ran one, would I have everyones authentication information?

      No. Just a token. SHeesh.. i didn't even RTFA

    • Re:Certain Information (Score:4, Informative)

      by Doctor Crumb ( 737936 ) on Thursday May 19, 2005 @12:55PM (#12579875) Homepage
      You are confusing Authentication with Authorisation. Authentication is proving that You Are Who You Say You Are, i.e. the purpose of systems like OpenID. Your cookies/etc would be involved with Authorisation instead, deciding what that person is allowed to do on your site.

      Of course, if a central signon system doesn't work for you, then don't use it.

    • Re:Certain Information (Score:5, Insightful)

      by sydney094 ( 153190 ) on Thursday May 19, 2005 @01:01PM (#12579945)
      The decentralized nature of this is the problem. It is impossible to securely authenticate a person using an untrusted server.

      If you ran one, you'd have only your authentication information stored on your server. Then, to authenticate to a remote server, you'd point that server to your server. The remote server would ask your server who you are, and then authenticate you (log you in). The biggest thing is that the remote server has to trust that what your server tells it is correct.

      This may have a place in the blog world, where you're mainly looking for an easy way to keep your user profile the same across many blogs, but certainly not anywhere where you'd have sensitive data.

      Another point, this is supposed to be authentication and not authorization. But actually, this isn't really authentication either... The difference between the two is really the question the server is asking. In authentication, the question is "are you who you say you are?". In authorization the question is "do I have the rights to perform a task?". With OpenID, the question is "who are you?". There is no verification to see if you are who you say you are (from the remote server's perspective, since there is no trust between servers), so you aren't actually authenticated.

      It would be up to your server to determine what rights an open-id authenticated user would have.

      • That doesn't make any sense at all. The point of OpenID is that you can say "I'm Brad Fitz from Livejournal" and it would check with Livejournal. Isn't that exactly authentication?

        Sure, you could lie about being Brad Fitz by saying "I'm Brad Fitz from Deadjournal" but then... those are two separate identities.
        • Isn't that exactly authentication?

          No, authentication is "I am Nicholas Harmon, and to prove it here is my password, secure certificate, and/or biometric signature".
          • Right. And you do that with Slashdot, just like you have in the past.

            This, distributed authentication, lets other sites agree that you are Nicholas Harmon from Slashdot.

            What have I missed?

      • Re:Certain Information (Score:3, Insightful)

        by iabervon ( 1971 )
        There isn't any trust between servers, but a server knows that any identity at a particular server trusts that server, and therefore that the remote server is sufficient to authenticate that identity. If I claim to be iabervon@slashdot.org, and slashdot.org agrees, that should be enough for anybody. Of course, some other site is unlikely to care if I'm iabervon@slashdot.org or not, unless, during an interaction with the site, I tell it to authorize iabervon@slashdot.org as me, because I (the user in the int

    • Re:Certain Information (Score:5, Insightful)

      by Nytewynd ( 829901 ) on Thursday May 19, 2005 @01:02PM (#12579955)
      You could still use cookies based on the sign on. Instead of getting the sign-on data from the user typing it, you would be getting it from the token and perhaps looking it up on the backend. It makes it easier for the user, and is about the same amount of programming for you. You can still set and delete cookies accordingly.

      Decentralized servers are no less secure than if you had a database table of your user authentication information for your application. With SSO, you actually don't need to know the password since it has already been handled. All you need back is the user ID and that they have been authenticated. If you choose to set one of these servers up, it isn't like people are going to start using your server to store their Online Banking information. They will be using your server only to access sites that you run.

      On the flip side, if you choose to latch onto someone else's server for authentication, all you will be doing is specifying that you allow anyone authenticated by that server to access your site. You wouldn't even have as much knowledge of those users as you would if you ran your own security.

      For the most part SSO is only really usefull within a small environment. Very rarely do I see a need to allow people to access more than one application with the same sign on. Something like passport is nice for the general user, but why would I want the overhead of something like that for my own applications? I'd rather have more control over things. That sort of makes this new product interesting to me, but on the other hand, most of my applications have distinct user sets anyway.
      • "For the most part SSO is only really usefull within a small environment. Very rarely do I see a need to allow people to access more than one application with the same sign on. " Most IT Security standards require users to use DIFFERENT passwords for each application, of course this is very hard to police. The idea is to prevent loss of the password for one application to give unauthorized access to ALL applications. That problem is inherent in the system described in the article, if a "black hat" steals
      • For the most part SSO is only really usefull within a small environment. Very rarely do I see a need to allow people to access more than one application with the same sign on.

        I'm one of the authors of CoSign [weblogin.org], which is a "traditional" Web Single Sign-on system. Really, SSO is explicitly not very useful in a small environment. SSOs are particularly useful in medium to large enterprise environments, primarily because identity needs to be tracked across many different application -- for provisioning, audit

  • 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)

  • No thanks (Score:4, Interesting)

    by Quasar1999 ( 520073 ) on Thursday May 19, 2005 @12:45PM (#12579763) Journal
    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...
    • Wait are you for or againist Single Sign on?

      I'll authenticate with each and every site I visit...

      and

      I'm more worried about logging on to some place with the wrong credentials...

      Are contradictory statements. You can't have both be true.

      Single Sign On is nice because authentication is easier. I didn't like passport cause I don't trust MSFT, or any single vendor. Open ID once it has stablized and been tested is a better way in theory.

      So who do you trust a dozen or two different companies with variou
      • No, the problem is that many of us have, and want, separate accounts; the parent mentions MSN and MSDN, maybe the first is personal account and the second from work, and he doesn't want to mix the two. The problem is the cookies; when you hit the Passport sites it just recognizes the last used cookie, so you have to clear that user and log in as another.

        Single Sign On sounds really cool, and maybe for the majority of people it's a Good Thing (TM). But for some of us, we have multiple accounts that we lik
        • The core issue here is that the current paradigm directly ties accounts, identities, and privileges.

          What we need is a system that every person has one identity, with multiple persona. Each persona would have privileges and accounts tied with it. Your identity should be available only to those to which you trust it, and persona as well.

  • Lame (Score:2, Interesting)

    by pHatidic ( 163975 )
    How is this ID? It doesn't identify the person, nor does it even make the claim that it is a unique person. It is just the next in a line of doomed to failure solutions for the lack of Identity on the Internet. Repeat after me:

    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

    • From what you are saying, it sounds like you think that only a SHA hash of some biometric information that doesn't change could be the way to identify someone.

    • Re:Lame (Score:3, Interesting)

      by iabervon ( 1971 )
      There is no feasible way of identifying a unique person presently. Fortunately, few entities care (one is the IRS, which wants to prevent individuals from splitting their income and lowering their tax brackets; another is law enforcement, which doesn't want people to be able to start over with a new identity).

      For most things, the only thing that matters is that the site can determine that some entity that claims to have been there before is back. Identity
      is about telling that things are the same, not about

  • will this work? (Score:3, Insightful)

    by millahtime ( 710421 ) on Thursday May 19, 2005 @12:47PM (#12579788) Homepage Journal
    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.
    • If you had RTFA, you would know that this is not a
      Single Signon. It is a Set Of Single Signons. You can have as many identities as you want. The difference is that without something like this, you are forced to have one identity per site, or one Passport ID. With an openID implementation, you can have any number of accounts as fit your needs. One potentially useful scheme is to have one signon for blogs and news sites, and then individual identities for each bank/etc.

  • yes but (Score:2, Interesting)

    by zxnos ( 813588 )
    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.
    • or track my movements

      they could track your movements and sell that info to marketing compaies in the same way that credit card compaines do that.
  • 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
    • There is, in fact, such a way to hook up linux boxen to an active directory server. Samba's pam_auth_winbind is working like a charm on my Fedora FC3 box; it maps DOMAIN\user to the unix user "domain_user", auto-creates your home directory, you can use your AD login to check mail, etc.
    • 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 - St
      • 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.

    • I think you misunderstand the purpose - this isn't for providing authentication/directory services within an organization, it's for doing something similar to Passport - allowing someone a single sign on to a large number of different web sites.

    • 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/ [idsofwtare.com] and Id's OpenID serv
  • 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.
    • Because if you log onto a foreign web site, it says, "Ah, this person is giving me an id which is stored on another server. Let me ask that other server if this person is known to them". If the other server knows this, it returns a token so now you know that the other server authenticated. (You can then associate things with this token for when the user next visits your server).

      So basically, if you're logging onto the web site where you are registered, it simply makes a local call to a local database. if y
    • 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.

  • Single signiture sign-on (Score:4, Interesting)

    by 0xABADC0DA ( 867955 ) on Thursday May 19, 2005 @01:00PM (#12579934)
    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.

    • The problem with this is that really security conscious sites (like your bank) won't go for it. The reason is precisely the bit you put in italics. Financial institutions want, as much as possible, to authenticate actual people, not computer programs.
    • You could get some of the benefits of such a system by hosting your own OpenID server.

      It sounds like the features of OpenID are bound up in the features of FOAF, so I think the alternative you are describing is more of a tradeoff than a plain improvement.

      Maybe OpenID could be designed so that ID providers are not necessary if you handle your own key pair, but it wouldn't be all as simple as you put it.

    • 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.

      Interesting...That sounds a lot like what client-side SSL certificates can already do in most web bro

    • Denmark (!) has this feature. As a Danish citizen, I have acquired a SSL client-side certificate which I've installed into my browser. It is protected by a master password of course, but using it I can go to any site (mostly governmental services but also e.g. my cell phone provider lets me log in with it so I can check my cell phone logs or buy talk time) and be securely logged in, or use it to sign my email with a key verified by a government-sponsored organisation.

      If permitted sites can access your info
  • 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.

  • LID (Score:2, Informative)

    by ibku ( 735269 )
    http://lid.netmesh.org/ [netmesh.org] - I've heard good things about LID, and it supports SSO.
  • 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,
  • 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

  • Why not just use SAML? (Score:3, Insightful)

    by ProgressiveCynic ( 624271 ) on Thursday May 19, 2005 @01:23PM (#12580209) Homepage
    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?
    • 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?
      • Call me perverse, but anytime someone tells me not to argue a point I just can't resist. ]=D

        SAML has been widely adopted, just not in the use case you're imagining. For B2B scenarios it is actually taking off quite well, and the US federal government is standardizing on it. [cio.gov]

        Now, it hasn't caught on in the world of consumer focused web sites, which is understandable given the architecture - no consumer authenticates at an authority before accessing sites, so it only makes sense for co-ordination between

    • This is explained on the Web page.
      • Their arguments strike me as rather unconvincing. There is no reason that the existing SAML profiles could not be used in an AJAX application, and I'm very interested to hear how they are going to securely exchange identity tokens without using SSL or duplicating its functionality. These are their only two arguments against SAML. You are correct that I have not read further to understand the whole spec which may indeed answer these questions.

  • distributed != decentralized (Score:4, Insightful)

    by PureFiction ( 10256 ) on Thursday May 19, 2005 @01:37PM (#12580371)
    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?

    • 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?

      Well, for starters you don't have to worry about different sites knowing your username and password on other sites. If you use the same username and password on all sites a sysadmin at one site can go to another (popular) site and try all their saved userids/passwds against it and will probably get access to a number of accounts. With OpenID they get a one t

  • Why are they calling this identity? (Score:3, Insightful)

    by Daedala ( 819156 ) on Thursday May 19, 2005 @01:43PM (#12580440)
    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.
    • An identity is a (person,role) pair, such as "daedala that posts on /.", or "daedala who runs a particular website", etc. The real world is no less prone to the same problem: "Fred who pays his taxes" and "Fred with a particular driving licence" normally tally - but they don't, otherwise we wouldn't have a bunch of problems with forged ID documents of various kinds.

      I'd go so far as to say that getting to know someone is the same as piecing-together a sizeable number of these facets about them, but at the e
    • What is self?

      Isnt self your real identity? Does it really matter if you're Paul Whackabee, Jonah Jackson, or Jason Voorhees?

      We could argue that your DNA is self, but it isnt. When you bleed (from an injury), does your self leave there? Or on surgery, does your self go away there? Of course not.

      If you were a perfect twin, are both of you the "same self"? Nope.

      Logically, we must conclude your self is actually some instantaneous moment of your crystallized product of your knowledge.

      That goes deeper in.. D
  • 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 s
    • 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 responsibili
  • This is just LiveJournal's answer to EZboard's single signon. You can register for any EZboard blog, and reuse the registration information with other EZboard blogs. It's centralized, but it's a feature that LiveJournal and its affiliates don't have. Google and Yahoo also have common sign-ons across their various services. So the LiveJournal people had to do something to keep up.

    It's not helpful for e-commerce, corporate intranets, campus-level signons, online banking, or spam prevention.

  • 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?

  • Wow. (Score:3, Informative)

    by yitzhak ( 720512 ) on Thursday May 19, 2005 @02:07PM (#12580750) Homepage
    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.

  • Digital Certificates (Score:2, Interesting)

    by infohord ( 311979 )
    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?

  • 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.

  • 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 rep

  • 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.

  • 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 ch

  • 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

  • RealOpenID (Score:3, Interesting)

    by Doc Ruby ( 173196 ) on Friday May 20, 2005 @12:23AM (#12585955) Homepage Journal
    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.

Slashdot Top Deals

E = MC ** 2 +- 3db

Close