Slashdot Mirror
A Modest Proposal For Decentralized Membership
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.
if you don't mind being bobmc199129812981928912 because of the unique name requirements.
Problems:
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
Solution:
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?
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.
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.
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.
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?
----------
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
--
Join my fight against Subway's new cut!
http://spine.cx/subway/
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.
.NET
Not a trivial matter. Passport is intended to be THE identification and authorization checkpoint for every service in
A breach of security at this critical juncture would have many severe repurcussions.
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
I'm not so sure...
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.
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.
you can find a copy of "A Modest Proposal" online at the following url: http://art-bin.com/art/omodest.html
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).
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?
...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.
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
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.
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?
The shareholder is always right.
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.
.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.
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
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.
How to Download YouTube Videos
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
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.
--8<--
--8<--
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.
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
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:
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.
You can't study the darkness by flooding it with light. --Edward Abbey
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.
Advogato creator Raph Levien is working on this for his thesis.
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 xns.org. 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.
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.
+--------------------- You idiot! I told you we were facing the wrong way!
What about the security risks of a centralized system? If it was was comprimized, what is the worst that could happen?
I use Macs to up my productivity, so up yours Microsoft!
Comment removed based on user account deletion
Comment removed based on user account deletion
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.
feh.
It's a dog's breakfast.
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
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...
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.
I can spell. I just can't type.
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.
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.
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
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..
I think that this already exists - have a look at xns.org
Graham
Graham
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.