Help get this topic noticed by sharing it on Twitter, Facebook, or email.
I’m redundant

Redundant OpenID

Has there been any thought to redundant openid, i.e. by providing a site with one provider it can learn that there are other valid openid providers, or that if I sign up to a site that provides and supports receiving openID logins, it would ping back saying "I can be a redundant provider"

Something like that, a friend thinks OpenID is login DRM because it's dependent upon another site to exist and stay up and keep passing on your login info, and what if one day it stops? Sure you could say "keep your domain up", but what if your domain supported travel to Cuba and someone disagreed?

Just tossing it out there. I'm sure he'll come comment eventually on his thoughts.
4 people like
this idea
  • I’m reticent to join
    I wrote up a potential solution:

    But I'll paste here:

    To start, I don't hate the idea of OpenID, I'm just passionate in my reasonings. As with everything else.

    It has been noted by various people, various people I will quote as soon as I can find them again, that OpenID is a nifty idea with many logic holes. And I personally get stuck on the DRM issue. For those that don't get what I'm saying, I'll lead you.

    OpenID is open source and can be installed on any server anywhere with no restrictions, it's "open" after all. You then can host anyone's account information for any server that supports OpenID. When logging into an OpenID-enabled site, you just redirect them to the proper URL. You log in with one username/password, and bam, you're in.

    Until your favorite Satellite OpenID server dies. See as stated numerous times on the OpenID website, all OpenID servers are decentralized. Meaning no connection to any other OpenID server. Meaning that when the user of a particular Satellite OpenID server goes bankrupt, gets busted for pirating the entire collection of Britney Spears, or just decides to throw the dead switch, your account is now gone.

    And any account that relied on it is now useless. This is where an OpenID supporter will say, "But you will just use your original login information to log in." And I would reply, "SO WHY DID I USE OPENID IN THE FIRST PLACE IF I HAD TO REMEMBER MY ORIGINAL PASSWORD?!" Seriously though, isn't having to only remember one account information is the whole idea of OpenID? Why yes it is!

    Therefore this is PassworDRM. Just like when a music DRM server goes down, you lose your music. If an OpenID server goes down, you lose your OpenID account. Man, you would think a FOSS operation would know better.

    What's to do about this conundrum? Well, a central server system! Something that the Satellite OpenID servers are instructed to communicate with and send back encrypted account information so that you would never lose your OpenID account.

    How it would work

    1. You go to login at X site.
    2. You click on OpenID link. You can either specify the URL of your favorite satellite OpenID server.
    2a. Or let send you to a random Satellite OpenID server.
    3. Log in.
    4. The Satellite OpenID server will send a small packet back to the OpenID server, checking the hashes of the accounts to make sure it hasn't changed.
    4a. If the account has changed, or was never on the Satellite OpenID server, that information is now sent it to be kept until the garbage collection date is reached.
    5. The Satellite OpenID server will then check the user's supplied information about the account against that which it has within its database. The pass/fail is sent back to the server.
    6. Done.

    That's it. Some developers would point out that this takes longer than normal to process. But yes, that's what happens when you use at least three different servers handled by three different groups. It isn't any better with two servers and two groups, but at least my one password works literally at every Satellite OpenID server that wasn't modified stupidly by its maintainer. Another benefit is that the burden is on the central OpenID server to maintain the account information indefinitely, not the individual satellite servers. Which is AS IT SHOULD BE. The satellites would only keep passwords while they are being used, if someone didn't use a password for three months, it would be deleted from the cache without worry of losing that account forever.

    I would have also it so you only changed your password on Why? So that you could have a hash that would be used by the satellite OpenID server to quickly determine if the account information has changed. Then the satellite would update it's database with the new information.

    Why is this a better idea? Because it allows for the entire system to work with one server or a billion servers. As OpenID is made more popular, they will get funding from the big companies, therefore the cost argument of running the central server is moot. (A side note to OpenID, if AOL isn't giving you any money to further development, you've failed yourself) It's better because my account truly will be one account that won't die because my original OpenID host liked to download movies a little too much.
  • (some HTML allowed)
    How does this make you feel?
    Add Image

    e.g. sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • I’m excited
    I like the idea of adding redundant IDs, but don't like centralizing this process - it needs to be done at the consumer, and maybe at the provider as well (an "AKA" field in the provider's database that gives alternate IDs?). A few consumers are already ahead of the game, and allow you to link multiple OpenID identities to an account on their site, so that you can log in with any of them.

    Redundant IDs also are only part of a solution - redundant IDs will save you if one of your providers go down, but they won't help you if one goes rogue and starts hijacking your identity at sites where you've used your OpenID.

    Some form of PKI (either centralized, WOT, or a combination of both) would be one way to prove who you are to recover your identity later, another would be a cryptographic commitment scheme, whereby you provide a commitment to a secret phrase, password, or other data when first using the site, and then may later choose to reveal that secret to the site if it becomes necessary to prove your identity (to recover from a hijack, or to recover from ALL your providers failing) This isn't strictly something that needs to be implemented in OpenID itself, although it very well could be, but it's something that any OpenID consumer, or indeed, any site that offers accounts should consider.
  • (some HTML allowed)
    How does this make you feel?
    Add Image

    e.g. sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned

  • So your solution to the problem of a having one user account for multiple applications on a single server that might fail is to have multiple user accounts on multiple servers. That sounds a lot like what we have now without OpenID. And without the "rogue" OID provider possibility. Unless a user was dumb enough to use the same username/password for all their applications.
  • (some HTML allowed)
    How does this make you feel?
    Add Image

    e.g. sad, anxious, confused, frustrated happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned