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.
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.
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?
----------
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.
Then as needed you allow this server to forward selected info to whoever you want.
...richie - It is a good day to code.
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.
...richie - It is a good day to code.
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.
Is he suggesting we eat Irish children for more bandwith???
(If you don't get the above, you have never read this.)
Try to hack my 31337 firewall!
...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.
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
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
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'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).
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?
...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.
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.
Troll Like a Champion Today
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.)
Troll Like a Champion Today
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?
Troll Like a Champion Today
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.
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?
The shareholder is always right.
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.
I browse Slashdot at +3, Funny
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
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 http://www.tux.org/~peterw/anon.txt
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.
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.
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 Freedom.net.
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
Your complaints about being offended offend me.
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<--
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).
If not now, when?
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.
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.
-foxxz
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
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?
-- Is "Sig" copyrighted by www.sig.com?
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.
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!
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
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"
Are you listening to me, Dave ? :^)
Are you, Dave ?
DotGNU.org 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...
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 ???
An Education is the Font of All Liberty
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.
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.
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.
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.
Nobox: Only simple products.
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
Rather than a (de)centralized authentication system, I'd just take a standard for automatically sending my personal data (or part thereof) to sites that need it and automatically creating a login with a given name/password combination. That would save me nearly as much time, with even fewer privacy concerns.
I think the argument that Microsoft's Passport system will inevitably triumph is not a good one. Their passport system is for their stuff, not everyone's. Won't the overhead of manipulating this member.xml file with permissions information and everything just be the process you have to go through with every membership system? If we are required to submit the goals of privacy to neccesity of convenience, count me out.
$45 per U Colocation Special
It's my private information, why should I give it to anyone for free?
It's kinda like what Microsoft Passport attempts to do, but without the centralized privacy concerns.
One of the first things that he gets out of the way is the fact that you can't really expect privacy with any membership system on a computer network.
Quoting from the real article:
On the other side, I don't think you can build a membership system in 2001 and make any guarantees of privacy. So once privacy is disclaimed, the problem is simply stated.
Now, that doesn't say anything about alleviating centralized privacy concerns, does it? Honestly, I wouldn't be surprised that someone sneaks an obfuscated link to goatse.cx into a Slashdot front page article with the amount of reading that the "editors" bother to do before posting.
Is your company running tools written by ma
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..
Why not:
a system that allows you to authenticate to one of many "Big" user Repositories, such as Yahoo, AOL, OSDN... whetever...
You would first choose a repository to authenticate to: eg. passport/yahoo/icq/whatever and you're redirected to a logon form that redirects you back if you have the correct password (with similar security mechanisms as passport)
_________________________________________________ Just another Crazy Linux/Perl Maniac
Try this on for size. Your own server at home w/your private information.
A bluetooth PDA or Portable Computer
A Unique ssl encryption w/digital signature
And wireless ethernet access points throughout the community.
This avoids centralized systems all together. You want my info? you have to send me a digital sig that is authenticated by my server. My server sends you the info on a unique ssl port, say a different ssl port for each country code.
The remote site accepts your ssl combined w/your digital signature and logs you on.
The trick, have different aliases on your HD and have a sym link connected to each of those ssl connections
For shopping at brick and mortar (a concept that microsoft is trying to implement w/it's .NET)
Your PDA/portable logs on to the 802.11 using bluetooth at your favorite restaurant. Now connected to the network on a limited port, the PDA contacts home and gets your info downloaded to the PDA.
Say you walk into Barnes and Noble once you log on to the network w/bluetooth and authenticate yourself with your ssl digisig, B&N offers you a cool book at a 20% discount. You accept, relay the info back to your server which contacts your account and deducts that from your checking, the inventory of B&N is reduced by one, that Barcode is deleted from the inventory stack, and you walk out without having to speak to a soul.
Now that would be cool
Who needs the stinking internet to house our info? We have the basic structure setup already on our boxen.....
http://cincyboys.blogspot.com/ Everything Cincinnati. Including the word 'Finnih'
and send the bill to Microsoft. Just how much would it cost for an attorney to do this type of work for us? Millions of US $? Wow, wait until Microsoft sees the bill for this one :).
"There ought to be limits to freedom"
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.
My terse view is that 'information' cannot be copyrighted, it's only the packaging of information that has this possibility. The biggest problem with all these schemes for paying for content is that the internet is just full of people trying to make money. The BIG boys, not just Microsoft, all want to establish a money pipeline to start a stream that eventually feeds into a roaring river of moolah. That's what XP and future versions of Windows and now 'content' is all about. On a practical level, why would you pay for content, if you can't see what you're paying for before you pay for it? You might do it for a very trusted source, but not with big chunks of money, only teensy ones. Everyone is too greedy -- Microsoft only serves as an obvious example. PS this content is free.