Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Internet

A Modest Proposal For Decentralized Membership 116

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.
This discussion has been archived. No new comments can be posted.

A Modest Proposal For Decentralized Membership

Comments Filter:
  • by Anonymous Coward
    heir passport system is for their stuff, not everyone's.

    Two problems with that statement.

    1. They aim to be a monopoly - more so than than they are now. (Bill Gates has been quoted as saying that a perfect world would be "MS software on an MS OS on every computer in the world.")

    2. MS's goal is to have Passport authentication with everything - anything that connects to the internet will need to authenticate with passport.. do you want to check your hotmail account? You'll need MS Passport. Do you want to access your bank account online? You'll need MS Passport. You wanna log into your ISP? you'll need MS Passport.

    MS is pushing Passport to be THE authentication service - and if nobody comes up with an alternative, they'll succeed.
  • by Anonymous Coward
    if you don't mind being bobmc199129812981928912 because of the unique name requirements.
  • by Anonymous Coward

    1. Users don't want to remember lots of passwords, re-enter personal info 10 times a day, etc.
    2. Users want privacy (only minimal and necessary info given out to each party)
    3. Users want the functionality to follow them across browsers, platforms, computers, physical locations, etc


    Design a protocol which is in essence a "memento" design pattern: all your personal info (including passwords, accounts, rules for which site can use what, etc) is stored in some standard xml blob, encrypted with your key (which is the only thing you have to remember), and given to an online entity (com, org, isp, free, commercial, whatever) for storage. This host only stores and CANNOT read your data - and it doesnt even have to know who your real identity!

    Every time you start a new browser session you request that data (have to provide your master password once) from which point you can roam the net without having to reenter any personal info - the browser will provide it to each site according to the rules you setup.

    All 3 problems above solved. Anybody see any holes? Has this been done?

  • by Anonymous Coward on Tuesday July 17, 2001 @06:05PM (#78349)
    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.
  • by Anonymous Coward on Tuesday July 17, 2001 @07:11PM (#78350)
    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.
  • Actually, that was my point. Microsoft pretends that they need to centralize these services so that the passport ids are unique, but in reality that particular problem is something that has already been solved. Email addresses are a prime example of this. They are all unique, and yet there is no central authority.

    Basically Passport is a service that aggregates information and associates it with a unique key. If Microsoft shared their protocols and schema with service providers then anyone could be a hailstorm host. Microsoft is intentionally designing the system so that it constitute a chokepoint. Microsoft has learned from experience that controlling the computing crossroads is a lucrative job, and so they designed their system not for technical excellence, but rather because it would allow them to eventually name their terms for use of their system.

  • by Jason Earl ( 1894 ) on Tuesday July 17, 2001 @10:25PM (#78352) Homepage Journal

    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.

  • by Millennium ( 2451 ) on Tuesday July 17, 2001 @05:57PM (#78353) Homepage
    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?
  • What Microsoft/Passport is trying to achieve is to create a database of users. Once they achieve that it will give them a great deal of power and profit potential. Anyone who believes otherwise is an utter fool.

    It doesn't matter what they say today, what matters is what they'll do with it 5 years down the road. And the problem isn't just Microsoft. Government agencies (driver's licenses) and other business have all demonstrated a lack of restraint in search of the almighty buck when it comes to finding new ways of using a database once it is created.

    Today they say they identifying information isn't needed. Tomorrow, they'll be filling in those blank fields by any means possible and selling custom dumps of the data to the highest bidder.

    What's needed is a _distributed_ authentication system. Yes it does bring some potential problems but having a single commercial entity be the choke point on internet authentication similar to the way Verisign also has a virtual hold of large parts of internet certs and DNS would be a large mistake.
  • Imagine a server appliance that you keep at home hooked up to your high-speed internet connection. All your personal info resides there, encrypted and protected by passwords.

    Then as needed you allow this server to forward selected info to whoever you want.


  • An idea I had was to start a company that is a data bank for people's personal info. The clients whose information is stored there pay a small fee and the bank makes sure that the data is safe and secure.

    This would work in a manner similar to a regular bank that keeps your money. You can imagine writing "info-checks" which pass your info to the people/sites that need it.

    You could also imagine a "certifying" service that such a bank could provide. It would verify, as much as possible, that the data you supplied is true. Of course some things are easy to verify, others harder.

    Naturally, having standard protocols for exchange this type of information would make it possible for many data banks to exist and compete for customers.


  • by Steev ( 5372 ) < minus punct> on Tuesday July 17, 2001 @05:34PM (#78357) Homepage

    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! []
  • by PureFiction ( 10256 ) on Tuesday July 17, 2001 @05:50PM (#78358)
    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.
  • Is he suggesting we eat Irish children for more bandwith???

    (If you don't get the above, you have never read this. [])
  • Yes, someone will follow this up with YHBT, but what the hell, I'll bite.
    Swift (also known for Gullivers Travels which is a brilliant satire) wrote "A Modest Proposal" as, you guessed it - Satire.

    Please look up Satire in the dictionary.
  • --rant mode on--

    ...has nothing to do with superior marketing. It has to do with the arm twist they put on manufacturers, the lies, broken business deals, and a host of other malicious business tactics they have used to try to damage any other competitor to their supremacy. Not to mention that the entire MFC is based on flawed code that is so byzantine and obscure that it really does give MS an inside advantage to be able to develop the next API in private in a way that gives them ways to essentially break any software they choose to attack during the inevitable service pack and OS upgrade processes.

    --rant mode off.

  • by cpeterso ( 19082 ) on Tuesday July 17, 2001 @06:27PM (#78362) Homepage
    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."

  • The only problem with storing information on freenet is that the information isn't guarenteed permenent. If the file isn't populair, then it gets removed from the system. Bye bye my xml data file.
  • How is this really much different then a cookie? Why not just allow the user to store his data locally and allow behind firewall distribution with a preexisting decentralzed server network (jxta.)

    While I'm at it, whats the big idea with User Location for user data and Instant Messaging. Why not just allow 128 public keys to be user location identifiers through a decentralized jxta real time location service. Chat - passport - decentralized. Am I missing something?
  • I think that this already exists - have a look at

    I'm not so sure...
    • doesn't actually have any code yet (other than some limited tools donated by OneName), so you couldn't really say that this 'already exists'
    • is based on patented technology which has been licensed to by OneName. The license is revocable in certain circumstances, and restricted to areas that do not compete with OneName
    • This is not a distributed platform like Dave is proposing, AFAICT. The proposal would allow any group of sites to communicate identity details amongst themselves, whereas the system requires a root server. This means a monopoly.

  • It's an open source project that hasn't released any code
    yet. Looks like DNS (which is already being 'evolved' to handle public keys and other such sign-on info). Do a DNS lookup on "your name" and get your email address & phone number. Thus, ONENAME is the ROOT SERVER.

    ONENAME have patented the web-agent technology that automates the exchange, linking, and synchronization of information between publishers and subscribers over digital networks (using XML).

    They have granted an exclusive royalty free license to XNSORG, and XNSORG is allowed to sublicense under an Open Source License. It looks to me like this is one of the good kind of patents -- it's also irrevocable. So it looks like they patented the technology as a defensive move to prevent the big nasty corps. from using it outside the open source license terms.
  • Firstly, kudos to Dave Winer for getting this discussion going. There's got to be a better alternative to decentralized membership than MS Passport, and why not Dave to open up the new Frontier ;)

    I don't understand why Dave poses the issue of privacy vs. publishing as mutually exclusive. Neither camp's advocates would be happy with an all-or-nothing solution. And even in selecting the "publishing" route, of course he's not throwing privacy concerns to the winds (I hope). If it's a matter of trying to set realistic user expectations, that's one thing, but I don't think choosing publishing over privacy makes the design/implementation problem significantly easier.

    That said, I think his description of a decentralized membership has some good things going for it. I just think it needs to address security issues/features at least in a way that security conscious users or sites/services can take advantage/require or otherwise use them. At least something like the xmlStorageSystem he describes *does* ensure that a public resource like member.xml is password protected. But of course, it doesn't attempt to address connection-level security (e.g. requiring SSL). Seems like you'd want to at least be able to require some minimum connection-level security.... Or otherwise fashion a system for the legacy server to encrypt the data using a public key from the requesting server.

    Also, I guess I'm not quite sure from a first reading if there's just supposed to be *one* legacy site, or multiple (if the former, then aren't you running very close the the Passport single-source concerns? if the latter, is there some kind of subscription/maintenance so data stays up-to-date?). And in any of these situations, without being to require some kind of security, would you ever trust your billing/credit card info to it? If not, that seems to be a big strike against the whole goal of increased user convenience for decentralized membership (at least for the joe-consumer audience).

  • Sort of. One identity, and several of you choose, or choose not to, accept the identity. Email address should be unique enough for a login, which then allows that user to create a different identity on each website. Now we just need a widget to pass keys. Should be able to do some nice handshaking here with public and private keys.

    The really scary part about this is, no matter how cool it is, and how much I'd like using it, the Feds' WILL get a vague warrant from one of those judges that loves passing them out, and then dig deeper into some poor sap's life than the Constitution intended.

    While the average person has nothing to hide, that doesn't waive fourth amendment rights.
  • by nakaduct ( 43954 ) on Tuesday July 17, 2001 @05:56PM (#78369)
    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.
  • by tosderg ( 44011 ) on Tuesday July 17, 2001 @06:55PM (#78370) Homepage
    you can find a copy of "A Modest Proposal" online at the following url:
  • Toysmart (in your link) was a for-profit company. However, the scary part is that this shit can happen to non-profits too: Scientology's revenge [], or How scientology drove the Cult Awareness Network into bankruptcy, and seized its assets (including highly confidential case information and member lists).
  • You can solve this problem easily using web services ( or any remote communications protocol ).

    Let's say I set up an LDAP server. Slashdot login has two buttons: one for local authentication (to their information) and another to authenticate to MY LDAP server.

    Let's say you set up another LDAP server. Slashdot adds another button to the login so that a user can now choose local, my LDAP server, or your LDAP server for authentication.

    Now a user can authenticate to any authenticator service, but never store the user information. In fact, a random user token could be generated the first time a new site asks a service to authenticate a user. The random token could then be used in a cookie for the site as needed, with no idea who the user is. To kill off the identity, the user could instruct the LDAP service to send out a new cookie when he logs into the service. This would create the appearance of the site seeing a new user, even though the user is actually an old timer with a new token.

    There is only one minor problem (of having many login buttons), but this is easily solved. This is fixed by allowing the authenticators to pass the login information to other authenticators through web services (or any other remote protocol). This would probably take place as a clearinghouse of sort, but still allow the same effect. Large sites (such as MSN, Yahoo, AOL, OSDN could be both authenticators and clearinghouses due to their rather unique needs.
  • I wouldn't have thought that this is correct solution to the problem. But a solution where information is stored in your browser would be good. Recent Mozilla's (and I assume IE) have the option of "remembering" your username/password for a site. I also seem to recall a "standard" for websites to request information from your browser (and allowing you to preview what information you are about to send to a site). I personally think that this is the best solution. Do other people have any ideas?
  • How would you transport a decentralized login system?

    What I'm guessing is that login/password requests are passed from system to system like gnutella.

    But to crack this, all you need to do is packet sniff just one of these computers, and pull all the necessary traffic. Even if encrypted, (would you use SSL or SSH, or some other encrypted TCP?) wouldn't it just be a matter of time until it's cracked, like 128bit encryption?

  • by volpe ( 58112 ) on Tuesday July 17, 2001 @06:01PM (#78375) 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. []
  • That sounds like a cookie to me.
    It would work fine if you are the only one who logs in, or you are the only who browses while logged in. You could just have a cookie standardized and sites could grab it whenever they wanted. Encrypt it and decide if you want to give them the key when you go to their site.
  • The catch here that saves some face for the scheme proposed is that you have to only have trusted sites get access to members.xml.
    To be a trusted site, maybe you have to agree to keep that data secure and private, and if you can track back where that marketeer got your info, take em to small claims court. It would be sort of like if a telemarketer calls you, and you say take me off of your list. Well what you need is a way to find out who gave them that info (let me see the hash id on the members.xml you got -- ok, now I decode that and figure out who gave them my members.xml, and its off to the bank.)
  • This is a great technology, anyone know about the iButton []. Have not used one, but they look neat.

    The whole problem with what you are proposing, I think, is that it still relies on a centralized server to hold the encrypted data. If you just hold the data on an iButton type thing, and send it in when a site requests and you allow, that seems like the same idea, but cutting out the middleman.
  • And thats why I said it sounds like a cookie. I will read the spec now and reply if I have a suitable reply. Sahala, did you go to CMU?
  • by mike_the_kid ( 58164 ) on Tuesday July 17, 2001 @06:07PM (#78380) Journal
    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.
  • by smirkleton ( 69652 ) on Tuesday July 17, 2001 @06:03PM (#78381)
    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?
  • There's an idea being passed around to tie an indentity system into jabber. Jabber's decentralized in a similar way to email. User addresses are user@host, so hosts are authoritative for particular user's identities. Users can set policies to decide who can access personal information (and exactly what information). Jabber servers would function as a sort of certificate authority, issuing identity certificates to it's users... the certificates can then facilitate strong encryption over the jabber protocol, as well as letting subscribed services authenticate simply by making sure that the certificate is signed by the user's server. This provides for decentralized (from the network perspective) but centralized (from the user's perspective) authentication.
  • Anyone titling an idea "A Modest Proposal" who still thinks it's clever and droll - two centuries after the original was published - should be shot on sight and eaten. Who's with me?
  • The main problem I have with maintaining memberships on multiple sites is not that I have to enter my personal information each time I sign up for a site, but that I have to remeber zillions of passwords. One of the entries in this year's 5K contest [], PassPal [], tries to solve this problem by giving you a new password for each site based on an MD4 hash of your SSN, your birthday month, a master password, and the name of the site you need a password for. Does that approach work -- is it secure? Should something like PassPal be built into web browsers?
  • by jesser ( 77961 ) on Tuesday July 17, 2001 @08:43PM (#78385) Homepage Journal
    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.)
  • Should it be mentioned that Microsoft has little part in manufacturing it's own hardware, save sticking their logo and drivers all over it?
  • What about the additional network traffic such a system would generate? Now instead of my login attempt and the server doing a local lookup, the server would have to contact yet another server to validate me.

    True you could cache the credentials locally, but for how long, and what happens in the event a user changes his information on the master server, or if his account gets revoked?

    I'm not saying it's a bad idea, in fact I would love to be able to forget all but one of my login passwords, but I think more thought needs to be put into such an idea.
  • Richard Heeks states [] that in dealing with information systems, there are eight areas of responsibility: information systems planning, organisational structures and staffing, data management, computing and data management architecture, information systems development, information technology acquisition, training, and technical support.

    In my mind, Heeks makes the point that it takes more than technology to make techology work. It is not a self-licking ice cream cone. Dave is really only talking about protocols and infrastructure. While I say bravo!, this is not enough. Microsoft has both technology and infrastructure behind Passport and .Net, but they also have an organization. Do not discount this. Also remember that they are motivated to win in the marketplace, whereas with a decentralized system, there is no such drive.

    While technology is the focus here, and while technology is crucial, I hope that people start looking beyond the walls. This is about economics, not technology. Remember that Microsoft wins not because of superior technology but because they have better marketing. Any attempt to "beat them" will only work if some organziation or some true movement competes against them. Since the forces are divided (because they are decentralized), it will be almost impossible to compete with Microsoft.

    Where will the marketing money come from to fight against Microsoft? Or, perhaps that makes no sense. Perhaps you expect there to be three or four authentication mechansism. I suppose that is possible, but where does that leave us? With choice? Don't fool yourself. Large corporations will invariably go with the Microsoft solution. Why? Marketing again. You will probably not be able to cleanse yourself of Micrsoft.

    Maybe you care, maybe not. Just remember this: The day will come when Microsoft drops the ball and your personal, private data will be exposed. You will wish you thought beyond the technology.

  • Look, what Dave proposes has a lot of very big problems. Nice idea, but the design needs a lot of work. I could talk about the API, SOAP, etc., and that stuff looks pretty goofy to me (I love methods with a fixed set of arguments: earth to Dave, if you're using XML, you should pass around XML objects, not individual fields).

    But the basic ideas have BIG problems. How does dependant server know that legacy server is giving it info for the actual user, number one. Unless dependant server sees you authenticate to legacy server, it can't verify squat. That's where your signing makes sense. But you're too optmistic to think that the decrypted data can be protected. The legacy server needs to read the cleartext, so they can always give the data away. Anybody who can see the cleartext data can give it away. That's life. But crypto can help dependant site verify the relationship between data and you. How? Legacy site identifies one or more public keys with your info. When you click "You Know Me" on dependant, dependant shows you what data it wants. If that's OK with you, your client/browser signs a request for those fields. Your client authenticates to Legacy, presents the request. Legacy verifies that the public key used to sign the request is authorized to see the fields. Legacy signs an affidavit including the fields you requested and your public key (or some other identifier!). Legacy gives that affidavit to your client. Your client verifies that only the requested fields are present. You can check the signature, and verify the data's veracity. Your client signs the affidavit and returns it to Dependant. So Dependant knows that Legacy and you agree the info is correct.

    Dependant subscribing to data from Legacy? That's a tricky one. What if Legacy decides that you've changed gender? Of course there's absolutely nothing preventing Legacy from giving *all* your data to Dependant if it wants to. But I think the whole notion of subscriptions is bothersome. Better to have Dependant site tell your client it wants to be updated when facts change. Your client (running in the background) can prompt you for your passphrase when it needs to obtain new signed fact affidavits for sites like Dependant that need/want to be kept up-to-date.

    So how do you keep Dependant from stealing unauthorized fields? More crypto, plus auditing. :-( Dependant keeps an Authorization Form that you sign, showing what fields/facts Dependant can collect. A third party auditing firm can check Dependant's database and verify that every non-NULL field for every user was explicitly authorized form that user. If you can trust the third-party audit, you're in good shape. Well, better shape. (Or, if the updating is done by your client, then Dependant could simply keep all the signed affidavits you sent it.)

    Simple one-way hashes can also be used to enable user-kept facts. Using hashes, a person can not only better control what facts Dependant sees, but can do so without any connection back to Legacy. So, yes, you'd have the ability to share data even when the network is down. Try doing that with Passort.

    For more on user-stored, signed facts protected with one-way hashes, see

  • One thing that sucks about my suggestion is the whole Legacy -> Dependant data xfer relies on the user doing some data signing. Wheich means having something like GPG on the user's client machine. Which makes this a bear to roll out with current infrastructures. You'd practically need a browser plugin to make it remotely user-friendly, and then you have the whole key security and "roaming" issue set that I fear many/most users are not prepared for even if the necessary plugins were available.

    So here's an alternative way of 1) allowing a user to see/control/verify the facts being revealed by Legacy 2) allowing Dependant to trust that the affidavit signed by Legacy actually applies to the user who clicked "You Know Me"

    Dependant gives you a one-time secret code when you tell it you want to share with it some info from Legacy. You authenticate to Legacy, give it the secret code from Dependant, tell it what fields Dependant needs (all that may be simply following a hyperlink from Dependant to Legacy). Legacy then shows you the facts it has for those fields. With your approval, it signs an affidavit with the facts and the secret code. You then pass that (clear) signed affidavit to Dependant. Dependant then knows that the person trying to sign up on Dependant is the one described by the facts sworn to in the signed affidavit by Legacy. Whew. No client-side crypto needed. Just keypairs for all the servers that take part in the data exchange. If the user did have a keypair, then the user could have (offline) a signed affidavit from Legacy linking the public key to salted hashes of the various facts. And the user could use the affidavit andtheir keypair to send facts to Dependant without Legacy needing to be available.

  • So they would be happy for me to create a token with the string "TomCruise@Actor" would they?

    No matter how you try and gloss over it, as soon as you start providing an authentication method that people rely on you must also start to perform real, and expensive checks.

    And if you think that there is a fuss about domain names just wait this is in use!

  • IMHO it's not very open if it prevents or deters other competing open source parties to use the technology. I don't think it's all too positive either, if the patent is used offensively (what you called: a defensive move to prevent the big nasty corps). It's a bit of irony if it works that way though.

    - Steeltoe
  • Good point. So such a system should include the option for the end-user NOT to spread the info around to other sites. Like advanced cookies. Of course, they can always decide to break that trust but then it's broken.

    Others have mentioned profiles. If you want, you could use your "Santa Clause" profile to automatically register as Santa. I don't really feel the need for sites to know who I REALLY am, ala credit card registration. Too much privacy-invasion.

    The true value of the internet was/is the openness and the fact that you can never really be sure who is who. Accountability is overrated, when it lacks, people have to start thinking for themselves more.

    - Steeltoe
  • my favorite idea would be a USB dongle-type device (or "token") that could be worn or carried on a keychain

    Dallas Semiconductor [] have (IMHO) the best of such devices, as part of their iButton [] product range. It's a USB fob for iButtons []. Hang it on your keyring and it's an iButton fob. Plug it into a laptop for a moment and it's a USB-connected authentication device (capable of running robust JavaCards). Plug it permanently into a desktop and it's a cheap iButton interface for static machines.

  • Firstly, kudos to Dave Winer for getting this discussion going.

    Winer didn't "get this discussion going". My cow-orkers have been very busy in this space for well over a year, and there's a huge pile of published work out there on far, far better ways of doing it.

    There's got to be a better alternative to decentralized membership than MS Passport, and why not Dave to open up the new Frontier ;)

    Because Winer isn't smart enough. He never innovates; he takes something with a pre-existing moderately high profile (like RSS, like XML-RPC, like Passport) which has something small broken in it, fixes up the most glaring holes and then starts to pass it off as his own original work. As he's the best self-publicist this side of Steve Bennet (the flying cement mixer, not the CTO), gullible people who know no better believe him.

    The trouble is that he's not bright enough to spot when something has a really major flaw in it. RSS 0.9 doesn't have semantics beyond the trivial ? - slap some extra XML on there. Server-based membership has a nasty link to M$oft ? - roll your own. Neither of these quick-fixes address the real underlying problem.

    I don't understand why Dave poses the issue of privacy vs. publishing as mutually exclusive.

    Because he can't see that publishing (and proof of rights, et al.) just doesn't require identification.

    At least something like the xmlStorageSystem he describes *does* ensure that a public resource like member.xml is password protected.

    How would that help in the Toysmart case? - the people who were entitled to have access to the data later sold it on. If you upload data, then it's no longer controllable. They'll either lose it through incompetence, or sell it for their own benefit.

    The solution isn't to try and impose your external requests on someone else's housekeeping practices, it's to build a system instead that doesn't rely on disclosure of this information in the first place.

    Information wants to be free
    Data fancies being tied up and spanked by Troi

  • All of these services; Hailstorm, Passport, Davenet, have it entirely wrong. We just don't need any form of identification service.

    Look at the "playing on-line media" scenario. The site operator needs to have proof that the consumer is entitled to the content. The consumer needs (sic) proof that the server is offering genuine RIAA-approved Metallica content, not that nasty communist MP3 stuff. The site operator also needs to obtain some token that proves they delivered content to the consumer (which the payment service will later honour). Neither of these requirements require anyone to identify themselves to another party. By PKI (which hasn't been rocket science for some years now) we can do all this.

    Think about proof, not about identification.

    #insert semantic_web.blah

  • Check out Zero-Knowledge [] and their [].

    You basically posit an automated (psuedo)Nym system. Zero-Knowledge did up the Nyms, you or someone can come up with the software & dongle/device/whatever/thingie
  • by steveha ( 103154 ) on Wednesday July 18, 2001 @12:33AM (#78398) Homepage
    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.


  • Actually, they mention this as one of the technologies being considered. I think that someone involved with it may be taking part in the discussions on the list as well.

  • Except not too many people are forced to authenticate for their SMTP. POP yes, but sending mail is completely unauthenticated in general. The way they keep riff-raff out is to only allow sending based on IP. If your IP is in their allowed range of IP addresses then you may send. And you can send with any email address you want.

    Try it out sometime, go into your mail settings and change your from address, send yourself a message. Just don't go spoofing to somebody that's going to turn you in to the authorities. While it may be harmless fun to send your parents a message from "their own account," most people won't appreciate getting virus hoaxes from a spoofed IBM or McAffee address, nor will those companies.

    It is incredibly useful when wanting to send mail from one account and you're on a different provider though. Like sending my university email over my DSL's mail server (since my university checks IPs and doesn't allow relay).

  • Okay, before you guys start saying that _____ is "just like a cookie" or start making comments about cookies, please read the actual spec []

    Among other things, in reply to a few comments above, cookies cannot be "standardized" so that multiple sites on different domains can grab it "whenever they want".

    From the spec:
    If there is a tail match, then the cookie will go through path matching to see if it should be sent. "Tail matching" means that domain attribute is matched against the tail of the fully qualified domain name of the host.

    Sorry for the off-topic post...but since we are talking about a possible unified web standard, other web standards such as cookies will inevitably come up.

  • This sounds like a pretty workable idea, especially with a standard USB device. One issue would be that if someone nabs the device without me knowing, they'd be able to view/modify my personal data.

    you could always re-encrypt a private key with password using some password based encryption, and have a tiny keypad on the device to type in the password (like a PIN, but maybe a bit better).

  • In a sense, this member.xml file he proposes sounds similar to a cookie.

    How is this similar to a cookie? A cookie resides on your local machine, and can only be accessed by the domain that issued it (see my previous post []). A member.xml resides on another remote machine and simply conforms to some defined schema.

    OTOH I do agree that there needs to be finer-grained access control. The personal data I want to make public does depend on what kind of "public" will be using it.

  • looks like the server that holds my viewing options died. i was only able to partially log on.


  • by intmainvoid ( 109559 ) on Tuesday July 17, 2001 @06:09PM (#78405)
    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.

  • The sites that use the tip jar do NOT get any information about your identity.

    The tip jar image contains personalized information because it is loaded from The sites simply has a standard IMG tag which makes your browser load a certain image from Amazon's servers. When loading that image, your browser also sends your user info cookie, so Amazon can see who you are and personalize the tip jar image.

    But that knowledge stays only between you and Amazon -- the site that uses the tip jar will not get any information.

  • I don't understand the whole distributed login idea (no, this is not a troll... I really just don't get it!). Does each machine have enough information to work on it's own? Or is it like a public key / private key in that each is completely worthless without the other? To my newbie mind, the first seems like it's only as strong as it's weakest link... and I'd rather have one or two systems than one or two thousand if it only takes _one_ to break (open, not down) to release my info to the world. If it's the second... how does reliability factor into this? Anyone care to enlighten me?
  • The key I think is not ever making passport or the other "free" services ever cost. Nor will they probably ever put wierd restrictions on them. The idea is to get everyone using passport and other free services and then lure them to other extra services for a fee.

    I guess the idea is that if you are already using a bunch of services if they say for $10 a month you get some extra things that enough people will bite, especially businesses.

  • So you'd trust Passport if MS "claimed" they kept the info encrypted?

    The problem with what you're proposing is that you still have to rely on MS (or any other Authentication Provider) not getting your pass phrase from some commercial site you trusted and using it to decrypt your info. You're obviously more trusting of corporations than I.

    It would be safer to either drop a step or add one:

    1. Drop the AP: Your scheme would work if you were the Authentication Provider. Data is stored on your system and you selectively give it out... a more advanced version of what most web browsers already do with remembering forms/passwords.
    2. Add a step: Instead of giving the pass phrase out to commercial sites and allowing them to get data from the Authentication Provider, you retrieve the appropriate encrypted data from the Authentication Provider (via some password) yourself, decrypt it, and forward it to the commercial site.

    The problem with option 1, of course, is that your info must be reentered into every device/system you use. The problem with option 2 is that you have to trust the device/system you're using to not do something it shouldn't with your data. But I think that's better than trusting some corporation. At least you can restrict yourself to devices/systems you trust, use open source code, etc., etc.

  • by small_dick ( 127697 ) on Tuesday July 17, 2001 @05:49PM (#78410)
    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.
  • by rgmoore ( 133276 ) <> on Tuesday July 17, 2001 @06:18PM (#78411) Homepage

    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.

  • Advogato creator Raph Levien is working on this for his thesis [].
  • Okay, this may sound a little Microsoftian, but I don't see why this couldn't work.

    First, as stated above, the "legacy site" referred to in the propsal could easily be your computer, eliminating the need for subscription services between sites, making the member.xml file a simple cookie.

    But why can't the browser build in the "You know me" button? The system could be done with a few simple cookies, built on a tier system.

    Netscape Communicator comes with a cheesy profile manager, which really isn't very useful unless it's tied to an LDAP server. But through the profiles, you could provide what information you wish to disclose, on a tier system.

    The browser could browse all sites at Tier 0, where your most public and non-identifying information is kept. If a site wants it, it might get your first name, for example, for a more personal touch. Say your name is Karen, it could say "Hello Karen!" but it wouldn't get any other personal information.

    The "You know me" button could increase the Tier level for the site that is being displayed, providing incrementally more data to the form you're filling out for ordering something, for example.

    So for the decentralized server, I have only one word: LDAP. It's currently in place, it's local, and you can have users that can set their own information or have it admin-maintained, and with some modifications to a browser it could easily be implemented.

    As for specifying the "URL to the XML data on the legacy site", that's as difficult as going to the preferences and specifying your ldap server, then authenticating with it.

    And you get your bookmarks too, for free! What a deal!

  • Firstly, kudos to Dave Winer for getting this discussion going.

    Agreed. Let's use some of the emotion that the "All your credit cards are belong to Bill" MS Passport ploy is bringing out to good effect. Winer is a high profile guy to bring this to mainstream attention, and will undoubtedly contribute ideas too.

    Also, please understand that the discussion and design issues around such a system have been maturing for quite some time (at least a year in public, and some small number of years prior to that privately) over at []. How does a legally enforcable privacy contract between yourself and any entity wishing to use your data stored on the XNS server strike you? Put contract law on your side, for once.

  • Uhm, I got it too... I didn't go to private school. If wittyness is all you got out of there, I suggest a refund is in order.
  • I haven't actually played with Passport, but I implmentented and used the original version (firefly) that Microsoft bought several years ago. At the very least, the original was designed to protect your privacy, and member web sites couldn't get at _any_ of your data without your explicit permission (even your username.)

    Basically firefly stored profile information in a central database. A new user a member web site could enter their firefly username and password and instruct the site to retrieve their information from the central server. The member site would get back only data that the user had previouslly specified to be shared (and this is where the P3P stuff started to come in, firefly met Microsoft and world domination was engendered.)

    The member site would then be able to synchronize certain subscribed data with the central server.

    As someone who runs a site with a half million registered users, I can tell you that a) I was pretty comfortable pushing ahead with firefly, and b) there's no way in hell I could ask my users to make there information available to Microsoft. Firefly provided an authentication and data storage service - Microsoft runs competing web services, advertising, software sales etc etc etc. Even if I trusted them, I don't think my users would.

    Anyway, there _is_ a place for a trusted third-party system. If Yahoo was smart, they would be rolling something like this out - mass matters and they are probably the only ones with enough existing mass to counter MS.

  • Right, so you're saying that non-profit organisations are non-existent?

    Your logic is flawed, and as my math professor used to say: start with an incorrect assumption and you can prove just about anything. I guess you just did that...

  • I've been using Netscape Roaming for almost a year now. It allows me to store my cookies,bookmarks and preferences on a server (in my case, a linux machine at home on my cable modem). My netscape profile is set to use the server (at home/work), or I can use the guest program at any other computer. I wish that other browsers had this feature.
  • What about the security risks of a centralized system? If it was was comprimized, what is the worst that could happen?
  • You are correct, the AP is a trust relationship. All authentication requires a level of trust, and I would trust a private company who mades it money by protecting my privacy and was contractually obligated to protect my data. If it were encrypted on their servers, it would be useless to them anyways, so the only option they'd have would be to protect my privacy.

    But you make an excellent point. Authentication is inherently based on trust.
  • Banks?

    Well, I dont have much respect for bankers these days. They are gaining a bad reputation for abuses and mistreatment of data.

    I would trust a bank-like instituion, Federally chartered, answerable to some serious looking MIB.

    I could see myself going to the First American Bank of Personal Data and giving them a blood sample, if I trusted that they wouldn't be giving it out to the wrong people. My doctor needs it yes - my employer no. That type of level of trust.

    I think its an interesting concept, but even as a libertarian I would agree that a very strong and very stringent regulation of these data-housing banks would be needed. A traditional 'banking' model probably isn't too far from what I would envision as necessary.
  • by danheskett ( 178529 ) <> on Tuesday July 17, 2001 @05:57PM (#78422)
    I read the article, and it sounds interesting, but i have misgivings.

    I've been playing around with a concept that might work. It goes something like this:

    What if these authentication services couldn't see your data, because it was stored encrypted on their boxes. Broken down a bit more, it goes like this:

    I have three levels of data I want to be able to give out: (a) full details and demographics - which include age, sex, real name, address, etc etc. (b) online purchasing requirements - basically name and address, with a CC or two and (c) slashdot\free membership data which provides a spam account, fake-user name, etc.

    When I go to my Authentication-Provider I enter the data and it is stored in encrypted format, each with its own key generated from my passphrase.

    Now when I go to slashdot or a store, I point to them to Authentication-Provider, give them a passphrase, and viola - it retrieves the information that it has access to.

    Better yet, the information at the main server could be stored anonymously - basically with no name or address, but just time saving and user preference stuff (a preferred stylesheet or font/color scheme) - then everytime you went to make a purchase you give demographics to the purchasing site (needed for shipping, etc) and the AP provides billing, sales history, etc.

    To me, something like this would be mint. The online places would not have access to any more information than needed to do business, and the AP would have sensitive but anonymous data. Of course, the AP would be ad-free and unable to capitialize on my data, so it would be a paying service. I would pay a nominal fee, perhaps $9.95/month for that ability IF it were implemented in a way that the AP didnt have specific data (name, address) and that the sites didnt store it locally but rather just stored my username/authentication key and provider address. If that were done, I could change my keys and effictively end any possible pirating or my data (because its encrypted).

    DaveCentral and Passport are a start, but I think that only a capitalistic but uninvolved third-party can provide anoymized yet encrypted and reliable authentication services.
  • When I sign up to a new site, call this the dependent site, I wish there were a You Know Me button I could click that would link membership in this site to some other site I am already a member of.

    Well, this is something that could be done via cookies, or something, although doing this via your generic web based profile in your local cyber cafe would be more problematic.

    Maybe they can take a cue from those famous "adult check" web sites or other similar technologies.


    It's a dog's breakfast.

    Check out the Vinny the Vampire [] comic strip

  • actually you can use any one of your existing email addresses as a Passport identifier, if you want. Initially it was limited to '', '' and '', but this is no longer the case. As i said in my original posting, you could use '' if you wanted (and it wasn't already taken). They said that they were going to add some feature to make sure that you didn't 'steal' other people's email addresses (based on domains) but that's not going to be in the first release.
  • Yes, you could except I just created '' as a passport account, so actually you can't. Why don't you just go to the passport site [] and try for yourself?
  • sure it's cheap. so is unsubstantiated FUD.
  • I just got back from Microsoft's ISV summit that they hosted in Redmond. It was very heavy on Windows XP and .NET (not surprisingly) and they also focused on Passport/Hailstorm. Here's a couple of points that they made that I think people here should know:

    1. The requirements for a passport identity are:
      • a unique identifier. eg: and this is the example they gave: "". it doesn't need to be your email address. it doesn't even need to be a real email address, just a unique string that looks kinda like an email address.
      • a password

      Optional data includes things like:
      • your actual email address
      • zip
      • age
      • city
      • state
    2. Microsoft won't use any of the information you give them for marketing purposes.
    3. the user can control exactly what information is given to which sites (through use of ACLs)
    4. microsoft won't do verification of any info that you send them - that is up to the 3rd party sites that you use.
    5. they made it pretty clear that security is a big concern for them.

  • Are you listening to me, Dave ?
    Are you, Dave ? [] as a decentralized id and all the web services on crapNET (tm) done the GNU way :^)
  • Don't read Dave's proposal without also giving XNS-org's [] a twirl as well. They seem to have thought out most of the obvious and many of the less obvious problems.

    Dave suggests that he's got XNS on his radar, so he might have some of this in his head, but not yet on paper...
  • Before passport becomes the only option on the table of the managers in the ether get some decent coverage puhleeeeeze !!!

    Wasn't there a call to make a mascot for linux that gave us tux and that fox thing? Would it be too much to ask for art peeps to rise to the occasion again and dignify this project with some innovative mascot or such ???

  • Forget the "dependant" and "legacy" jargon; I think I know what they're supposed to mean here, but they are confusing terms. All we are doing is asking one web server to fetch an XML page from another containing a user's information according to a set schema. Essentialy, the proposal is just fetching the XML equivalent of the "V-Card" many email programs generate with someone's phone, address, etc., and told to watch that document for any updates.

    The article explicitly says that the XML document accessed does not contain passwords. This is not .NET by any means; just a way to fill out registration forms quicker, and possibly giving a firm more information than they would have asked for otherwise.

    Marketers likely will send programs scouring for these files, or ask certain sites to sell them lists of where these files are. Your personal "public" record will be used to deliver a lot more than you ever intended.

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

  • It sounds neat, but thinking it out a little, it doesn't seem terribly useful. What good is authenticating the user if the original user information wasn't actually verified? Is my site to assume the information provided by "User X" at "Unknown Site Y" is valid?

    As someone already mentioned, this is just a way of reducing the amount of time spent on filling out forms when signing up at a site. How many sites do we really sign-up on? I sign up on several sites and then I'm done. I don't sign up at every site I visit, so filling out the form isn't that time-consuming.

    If the goal is reducing the amount of time to sign-up at sites, a better idea would be to have browsers able to automatically default fields of FORMs with a specific name (NAME=frmSiteSignup??) to the data you've previously configured the browser to return. When the browser sees a form named "frmSiteSignup" (or whatever the "standard" defines) it automatically looks for a text input field named REALNAME and automatically defaults that to the name you provided, same with email, etc. This would be the default and you could obviously clear any fields that you didn't want to provide to that specific site before submitting the form.

    Of course, I also agree with what someone else said: more than entering information at sign-up, the main hassle for me is remembering my passwords at each site.

  • Think FTP, HTTP and SMTP. Instant messaging needs to lose the we-rely-on-a-single-server complex

    Uhm.. Jabber is just as distributed as email. Delivery is even based on DNS and MX records.

    Use e-mail addresses as IM addresses, not a new ID per network

    Fortunately Jabber uses "user@host" for identification, which means any sane ISP would make your email and Jabber account the same.
  • by infiniti99 ( 219973 ) <> on Tuesday July 17, 2001 @07:39PM (#78435) Homepage
    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 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.
  • The reason MS is looking good to win this one is simple: they're up again ICQ, AOL, Jabber, and a host of other "standards" that aren't.

    MS is unable to usurp protocols that are global, standard and massively distributed. Think FTP, HTTP and SMTP. Instant messaging needs to lose the we-rely-on-a-single-server complex (don't bullshit me about Jabber and multiple servers - it doesn't get more distributed than IRC).

    If you want to beat MS at instant messaging, pioneer benefits for users. 1: Use existing support in SMTP for IM, or extend SMTP to do IM better. OpenSource mail software runs over 50% of the 'net -- MS can't fight that. 2: Use e-mail addresses as IM addresses, not a new ID per network.

    Relating that back to Passport & co: your e-mail address becomes your identity. If you can authenticate yourself to your home SMTP server (as you do to pick up POP mail, for example), then the SMTP server is "identified" by DNS, and able to vouch for the e-mail address user being consistent over time. Anonimity, privacy, and authentication (to some degree).

  • Wow. Thanks for that link. That pretty much shoots to hell Dave's credibility.

  • A question:
    Would you trust a bank to hold the data?
    What if a bank was offering a data system able to selectively release information, with your consent, to third parties, making the third party sign the confidentiality agreement with the bank (a federally insured institution) when they use your data. Misuse of the data would immediately consitute a federal crime, complete with FBI agents and all...

  • Well, I work at a bank.

    We're under the FDIC and another half dozen government agency. We get audited 2 times a year. We call the cops they're here before we can hang up the phone. The FBI is on our side. We just suspect someone of doing something fishy, the LAPD is all over them. We see a bank account doing something fishy, the FBI is all over it. We don't disclose unnecessary data with our vendors. They have to sign enormous non-disclosure agreements.

    Do you know what happens to someone who forges a check? It's a felony, with jail time (ten+ years) and a hefty fine. IANAL, (someone come up with the figures)

    Heck, banks already have people's information. Names, address, phone numbers, employers, dob, ssn, drivers licenses, credit cards, bank accounts, mother's maiden name etc... It doesn't get more private than that.
    Yes there's fraud, but not too much that the system isn't generally trusted.
    And banks never ever reveal that info to anyone except to law enforcement.

  • I can't really see why OSDN hasn't don't it already. It doesn't seems that complex: a large database somewhere, a simple API with Perl or Java and a secure connection between each web site and voila!

    I must say I don't know how it will scale.

    Microsoft problems come from the fact that they want to to everything for everyone. But I don't see the problem with sharing my Sourforge account and my Slashdot account, at soon as it is just that and well secured. I insist: well secured.
  • by derekb ( 262726 ) on Tuesday July 17, 2001 @06:26PM (#78441) Journal
    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 []
  • by vidarh ( 309115 ) <> on Wednesday July 18, 2001 @12:30AM (#78444) Homepage Journal
    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

  • by number one duck ( 319827 ) on Tuesday July 17, 2001 @06:25PM (#78447) Journal
    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..

  • by gfim ( 452121 ) on Tuesday July 17, 2001 @06:39PM (#78453)
    I think that this already exists - have a look at []

  • by jeffy124 ( 453342 ) on Tuesday July 17, 2001 @05:49PM (#78454) Homepage Journal
    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...... :)

Take an astronaut to launch.