Slashdot Mirror

← Back to Stories (view on slashdot.org)

A Modest Proposal For Decentralized Membership

Posted by ryuzaki0 on from the passport-without-the-scary-stuff dept.

There's an interesting proposal on DaveNet about creating a decentralized system for membership in different websites. It's kinda like what Microsoft Passport attempts to do, but without the centralized privacy concerns. It's a concept that we've talked about within OSDN - a decentralized login service - and it appears that the protocols are reaching the point that it'd possible and useful. I guess the issue would be what data gets passed around and such.

25 of 116 comments (clear)

  1. Whose problem does this solve? by Anonymous Coward · · Score: 3

    I don't understand the interest in this. I use a fairly standard name and password for many of my "accounts". I have no problem remembering them. I am not bothered by entering my credit card information when I purchase something. It's a useful reality check. "Do I REALLY want this?" The auto form fill-in features in Moz do a good job of eliminating the tedium of typing my address over and over. Passport and it's competitors aren't solving MY problems, they are focused on solving marketing and sales peoples desire to have a better handle on who their customer is. I'm not interested in signing up for that. By being so focused on Passport the free software community is giving this silly marketing scheme greater legitimacy than it deserves. I suspect that consumer apathy/antipathy towards the "value" of having this Passport account will hilight it's irrelevance and general lack of utility.

  2. and we're listening to WHO? by Anonymous Coward · · Score: 5

    This article was written by the guy who knew that he left several thousand of his user's email address in a bunch of world-readable directories, as well as all their sites' stats, etc, and did nothing about it for months? Yeah, sounds like the guy I want planning how to deal with my personal info.

  3. Re:Privacy concerns by Jason+Earl · · Score: 3

    In other words, Microsoft is simply creating a chokepoint for information. Seriously, Internet users generally already have a unique identifier (or two), an email address is the perfect example. Microsoft is going to add one more, and then they are going to create a list of "other" pieces of information that you can aggregate with this unique key.

    However, instead of turning Passport into a service that can be distributed Microsoft has specifically created a centralized service that puts them in control. At first this control won't be too big a deal. They will probably charge those passport users that want more than the "basic" services. The idea, however, will be to get as many people to sign up as possible. Both websites and web users will be able to use this service basically free of charge.

    Once Microsoft has all of the users, and a good portion of the websites using passport, they will start to reel the suckers in. Businesses will find that they can't access Passport without paying a fee. Users will find that they can't access their data without paying a fee etc. Microsoft will have succeeded in building a toll bridge for the information super highway.

    Of course, it doesn't have to be this way. Since Microsoft isn't double checking any of this user entered information it could just as easily reside on a server at my ISP (or my authentication provider of choice). Email addresses have already shown a way to allow for unique addresses without namespace collisions. ISPs could similarly hand out "identity keys" (that may or may not be the users actual email address). Each ISP could then function as a mini-Passport site, all that would be necessary is an agreed upon protocol and a set of XML schemas (you could borrow Microsoft's work).

    Of course Microsoft promises that they aren't going to use the information for marketing purposes. It is even possible that they will live up to their part of the bargain. They almost certainly will use access to this information in the same way that they use their current control of the desktop. ASPs and web sites that don't follow the Microsoft line will find that they are unable to use the Passport service. This might not seem like a big deal now, but if Passport becomes what Microsoft hopes it will be the de-facto method of sharing personal information and authentication for the web. If Microsoft were control how you share your information and how you authenticate then they could dictate terms in much the same way they bully the hardware OEMs currently.

    It's not a privacy issue. That's a complete red herring. Of course Microsoft is going to say that they aren't interested in mining Passport for marketing data. They probably even mean it. Microsoft wants control and Hailstorm will give it to them in spades.

  4. Interesting... by Millennium · · Score: 5

    I'd make a modification to it, though. One which would, at least hopefully, ensure that my personal data got out only to who I wanted it to.

    The basic idea is that the data is stored on a central server (or perhaps even a Freenet-like network) and encrypted. However, only the user has the decryption key. This key could be generated and/or stored in any number of ways; my favorite idea would be a USB dongle-type device (or "token") that could be worn or carried on a keychain. When a server requests a pieve of personal info, it sends a key I can use to encrypt it. Then, if I accept, I pull my personal data (still encrypted) from the "holding" server, decrypt it, re-encrypt it using the recipient's key, and send. Theoretically, if this were implemented right, the encryption and decryption could be handled right in the token, so that the decrypted data never even touches an untrusted hard drive or enters an untrusted computer's memory.

    There is, of course, the problem of a token being stolen or lost. In this case, give the user the option to delete his personal data from the holding server, generate a new personal key, re-encrypt, and re-upload.

    There is one chicken-and-egg point: getting the original personal data onto the token.

    The big problem with this system: making the tokens and distributing them. But I think this could really work, if those two problems were overcome. Anyone else have any opinions on this one?
    ----------

  5. Privacy concerns by Steev · · Score: 4


    I think the real issue here is who's holding onto your information. Would the privacy concerns be as great if it wasn't Microsoft (or some other equally malevolent corporation) doing it? I believe the concept is sound. It's just the intentions of our generous host that's in question. If there was a benevolent body willing to do this sort of thing, and *not* sell or trade any of people's private information, it wouldn't be such a big deal for them to have access to it.

    I, for one, use the passport system (all my spam goes to my hotmail account :), and some of the web applications that Microsoft makes available for free are great. I'm not evangelizing Microsoft; far from it, I'm a die hard Slackware user :) But I do think that they do some good stuff. They make wicked awesome keyboards (not those small cursor key ones, the other ones).
    --
    Join my fight against Subway's new cut!
    http://spine.cx/subway/

  6. Re:Security by PureFiction · · Score: 4

    In the case of M$'s Passport the worst that could happen is online identity theft, where your reputation is soiled, your bank account drained, and your accounts/data for the online services you use are destroyed or corrupted.

    Not a trivial matter. Passport is intended to be THE identification and authorization checkpoint for every service in .NET

    A breach of security at this critical juncture would have many severe repurcussions.

  7. Byzantine Generals Problem by cpeterso · · Score: 5

    This is exactly the classic computer science problem called the "Byzantine Generals Problem". Here's summary of an article from a 1982 ACM Transactions on Programming Languages written by Leslie Lamport of LaTeX fame:

    The Byzantine Generals Problem

    Lamport describes his paper saying, "There is a problem in distributed computing that is sometimes called the Chinese Generals Problem, in which two generals have to come to a common agreement on whether to attack or retreat, but can communicate only by sending messengers who might never arrive. I stole that idea and posed the problem in terms of a group of generals, some of whom may be traitors, who have to reach a common decision. I wanted to assign the generals a nationality that would not offend any readers. At the time, Albania was a completely closed society, and I felt it unlikely that there would be any Albanians around to object, so the original title of this paper was The Albanian Generals Problem. Some time later, the obviously more appropriate Byzantine generals occurred to me."

    --
    cpeterso
  8. Hemos says: by nakaduct · · Score: 5

    When designing a protocol, I guess the issue would be what data gets passed around and such.

    And when writing a book, the issue would be what words go where and such.

  9. Jonathan Swift is the name you're looking for by tosderg · · Score: 3

    you can find a copy of "A Modest Proposal" online at the following url: http://art-bin.com/art/omodest.html

  10. But a benevolent body... by volpe · · Score: 5

    ...is not likely to operate under a profit motive. And therefore they are not likely to be profitable. And therefore they will eventually go bankrupt. And therefore the courts will liquidate their assets. And we know what happens then.

  11. Trusted Audits by mike_the_kid · · Score: 4

    So the article says that you should have trusts between sites, and a common format to interchange membership info with each other. That in and of itself is not bad, but there has to be some sort of scheme in place, maybe with a pgp style signature to make sure that just because someone can break into one site, they can not alter then information in my file.

    The idea pitched by the article is that you should assume the information you put on the web is insecure, so do not put anything on one of these sites that you do not want spread around.
    It seems to me that if there was some auditing of the transfers of these files, and that trusted sites could be trusted, it would be feasible to have secure information on there.

    The real trick would be unique credit card numbers for each site, so if I get an illegit charge, I can trace it back to see where it was insecure, because there is a record of who accessed my membership information, and which one of these accesses was bad.

    There. Food for thought.

    This comment has been submitted already, 276506 hours , 5 minutes ago. No need to try again.
    So if you see this comment twice, it complained about no subject the first time, then that line the second time.

    --
    Troll Like a Champion Today
    1. Re:Trusted Audits by steveha · · Score: 3
      The real trick would be unique credit card numbers for each site

      You can do something like this if you have an American Express card.

      American Express has a service called Private Payments (there is a FAQ here). With this service, you can get a special credit card number with a very limited lifespan (number will expire after 30-67 days). You can get as many special credit card numbers as you like; it's free to anyone with an American Express card.

      And, check it out--if you get a Blue card, which has a Smart Card chip onboard, you can get a reader that will let you use the Blue card as a security token! I need to think about that one... Anyway, a serial port reader is free and a USB reader is $25. And Compaq makes a keyboard with a reader built-in, probably intended for use in a POS setup.

      steveha

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
  12. Solution in search of a problem? by smirkleton · · Score: 3

    How exactly does this translate into value for the end user of such a network of affiliated sites? I'm not trying to be contrary, I just don't think I understand what meaningful advantages are derived at the end-user perspective? Convenience of some sort?

    The one area where I something like this at work in my own day-to-day, to my displeasure, is in the Amazon Tip-Jar system.

    I don't like going to Andrew Sullivan's site or Modern Humorist's site and seeing, at the top of the page, "Hi there, Smirkleton (insert my real name here)". It bugs me to see my identity is immediately known to these sites by-way-of their using Amazon's TipJar system.

    I understand how it benefits affiliated sites, but not how it benefits end-users. Anyone got any insights here?

  13. Re:Hashed passwords? by jesser · · Score: 3

    I dual boot, for instance, so I can't always use the same browser, even if I had a specific favorite

    So go vote for bug 58647 :)

    (My original suggestion could be implemented in a browser-neutral way, or at least in a way that you could use a web-based version of the password generator when you're using a different browser.)

    --
    The shareholder is always right.
  14. Getting more users than Hailstorm by intmainvoid · · Score: 4
    The real battle here is going to be for users, and Microsoft really does have all the cards - Hailstorm is going to be installed by default on 90% of the desktops out there. But if the open alternative can get critical mass, then we're in with a chance!

    OSDN must have about half a million users, all the userland sites probably have a few more, so that could be a million users for starters if OSDN links up with userland. Then you just need to add a few corps that have a lot to lose from hailstorm (the AOL userbase would be nice!) and all of a sudden hailstorm is behind the eight ball.

    There really is only room for one player in the distributed membership field, so we should do what we can to make it an open system.

    --
    Drag n' Drop DVD Recommendations
  15. oh boy, here come the authentication wars by small_dick · · Score: 3

    OSDN, Mono, .NET, dotGNU...

    Please, not another plethora of schema.

    My dream would be to see a major commitment to dotGNU develop, but I keep waking up and reading about many different authentication shemes.

    Please, please, consider a rallying point for this before starting any design or even discussing a split.


    Treatment, not tyranny. End the drug war and free our American POWs.

    --


    Treatment, not tyranny. End the drug war and free our American POWs.
    See my user info for links.
  16. Re:Hashed passwords? by rgmoore · · Score: 4

    The problem with the "your browser remembers everything" system is that it assumes that you always use the same browser. That just isn't the case, though. I have several browsers on my home computer- I dual boot, for instance, so I can't always use the same browser, even if I had a specific favorite- so I'd need to have the information stored in each browser. I also sometimes browse at work, where we have several shared computers, and I'd need information on each of those computers. The latter is particularly scary, since it would be comparatively easy for a coworker/ITS person to get my information from the computer. This kind of thing is not atypical, either. It might very well be more practical to have a networked server of some type that I could log onto from any browser for data storage and authentication.

    --

    There's no point in questioning authority if you aren't going to listen to the answers.

  17. Comment removed by account_deleted · · Score: 4

    Comment removed based on user account deletion

  18. I still see a potential privacy issue... by RhetoricalQuestion · · Score: 4

    In a sense, this member.xml file he proposes sounds similar to a cookie. Something would have to be in play to ensure that all the sites don't have access to the all the data in that file.

    Phrased another way, I think the problem (though not an insurmountable one) in the this plan is that the file "contains all the information I wish to make public." This assumes that I wish to make the same information available to different groups.

    So while I'm open to giving out my real name and official email address to, say, a job search site, I'd rather not make that available on slashdot. (Not that it's hard to figure out.) Similarly, many people -- myself included -- may be willing to give out information such as gender, race, etc., in some places, (for example, an online dating service), but would not want that information available to potential employers.

    Yes, measures could be put in place to ensure that access is restricted, but keeping all that info in one file makes me a little uneasy -- too much like a cookie for comfort. I'd like something stricter.

    --

    I can spell. I just can't type.

  19. Jident by infiniti99 · · Score: 4

    This is similar to the Jabber battle. "Windows Messenger" is going to be installed by default on 90% of the desktops out there in the near future. We need to win over users NOW, or everyone out there is going to get way too comfortable using the centralized Microsoft alternatives.

    Btw, on topic, there was mention in the jabber.org forums of a Passport-like identification to layer that could be used over the already working decentralized Jabber network: Jident. This would be ideal IMO, and Jabber+Jident could be a perfect counter to Hailstorm+Passport.

  20. decentralized login? I'm missing something by derekb · · Score: 3

    What about Radius?? Radius is perfect for handling multiple providers / authentication points and can run off mysql, ldap, flat files or whatever the particular authentication point decides to use.

    It's also good because it is trivial to allow particular authentication domains while rejecting others.

    Derek

  21. Re:Are you sure..? by vidarh · · Score: 3
    In my case I'd want the authentication provider, because I move between lots of machines. I don't want to have the data stored locally. However I would want to be able to choose the authentication provider myself, based on trust. If I felt the security of my data warranted paying extra for a provider that use multiple external auditors to verify security and integrity, then so be it, and if I don't value my data, I could leave it with Microsoft.

    But keep in mind that if the data is encrypted properly, you could have a system where you tell the authentication provider to provide the data to site X, and then tell site X your passphrase - no need to every send that phrase to your authentication provider.

    --

    Remove Trash+ to reach my actual inbox

  22. Without the scary stuff??? by number+one+duck · · Score: 4

    Hemos! Never *ever* use the term 'A modest proposal' when talking about something you think is a good thing. Much too well associated with a certain infamous article espousing the cultivating of the irish people for meat. (And implies sarcasm against whatever one is talking about just by the very title)

    I cannot remember the author offhand, though, can anyone help me out with that? Or a link? I'd like to read it again..

  23. already exists: xns.org by gfim · · Score: 5

    I think that this already exists - have a look at xns.org

    Graham

    --
    Graham
  24. Current research... by jeffy124 · · Score: 4
    I've heard about current research from colleagues into the topic of decentralized authentication. The notion is several parties "vote" on whether or not an entity is who they say they are. When querying for a request to authenticate a user, multiple parties reply saying yeah or nah based on the credentials given. A yeah majority means the user can reasonably be certified and granted access to the resource. Generally you ask for a large number of votes or a certain percentage of majority depending on how you want to enforce your security.

    But what about bogus certifiers? Servers that always reply yeah or always nah, or always seem to go against the mainstream. Several methods exist. One is to give out bogus requests. If you send out 100 fake authentication requests and the same server returns 99 yeahs, you can assume that server doesnt know what it's doing and stop sending requests there. Other techniques like repeating requests (asking for authentication of the same subject more than once) and checking for consistent results is also common to weed out bogus servers and enforcing the integrity of the others.

    Keep in mind this is a fresh topic for researchers. I dont have many more details other than that. I might be able to fill in gaps if questions arise...... :)

    --
    The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.