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.
Re:Why is Unified Membership Needed? (Score:1)
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.
Yeah that's great... (Score:2)
Why not do it like this... (Score:2)
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?
Whose problem does this solve? (Score:3)
and we're listening to WHO? (Score:5)
Re:Privacy concerns (Score:2)
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.
Re:Privacy concerns (Score:3)
In other words, Microsoft is simply creating a chokepoint for information. Seriously, Internet users generally already have a unique identifier (or two), an email address is the perfect example. Microsoft is going to add one more, and then they are going to create a list of "other" pieces of information that you can aggregate with this unique key.
However, instead of turning Passport into a service that can be distributed Microsoft has specifically created a centralized service that puts them in control. At first this control won't be too big a deal. They will probably charge those passport users that want more than the "basic" services. The idea, however, will be to get as many people to sign up as possible. Both websites and web users will be able to use this service basically free of charge.
Once Microsoft has all of the users, and a good portion of the websites using passport, they will start to reel the suckers in. Businesses will find that they can't access Passport without paying a fee. Users will find that they can't access their data without paying a fee etc. Microsoft will have succeeded in building a toll bridge for the information super highway.
Of course, it doesn't have to be this way. Since Microsoft isn't double checking any of this user entered information it could just as easily reside on a server at my ISP (or my authentication provider of choice). Email addresses have already shown a way to allow for unique addresses without namespace collisions. ISPs could similarly hand out "identity keys" (that may or may not be the users actual email address). Each ISP could then function as a mini-Passport site, all that would be necessary is an agreed upon protocol and a set of XML schemas (you could borrow Microsoft's work).
Of course Microsoft promises that they aren't going to use the information for marketing purposes. It is even possible that they will live up to their part of the bargain. They almost certainly will use access to this information in the same way that they use their current control of the desktop. ASPs and web sites that don't follow the Microsoft line will find that they are unable to use the Passport service. This might not seem like a big deal now, but if Passport becomes what Microsoft hopes it will be the de-facto method of sharing personal information and authentication for the web. If Microsoft were control how you share your information and how you authenticate then they could dictate terms in much the same way they bully the hardware OEMs currently.
It's not a privacy issue. That's a complete red herring. Of course Microsoft is going to say that they aren't interested in mining Passport for marketing data. They probably even mean it. Microsoft wants control and Hailstorm will give it to them in spades.
Interesting... (Score:5)
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?
----------
It doesn't matter what they say now (Score:1)
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.
Your own server (Score:1)
Then as needed you allow this server to forward selected info to whoever you want.
A data bank (Score:1)
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.
Privacy concerns (Score:4)
I think the real issue here is who's holding onto your information. Would the privacy concerns be as great if it wasn't Microsoft (or some other equally malevolent corporation) doing it? I believe the concept is sound. It's just the intentions of our generous host that's in question. If there was a benevolent body willing to do this sort of thing, and *not* sell or trade any of people's private information, it wouldn't be such a big deal for them to have access to it.
I, for one, use the passport system (all my spam goes to my hotmail account
--
Join my fight against Subway's new cut!
http://spine.cx/subway/ [spine.cx]
Re:Security (Score:4)
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.
A modest proposal?!?!? (Score:1)
(If you don't get the above, you have never read this. [art-bin.com])
Re:A modest proposal?!?!? (Score:1)
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.
Why Microsloth wins... (Score:1)
...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.
Byzantine Generals Problem (Score:5)
The Byzantine Generals Problem [cornell.edu]
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."
Re:Interesting... (Score:1)
yah, like a cookie. (Score:1)
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?
Re:already exists: xns.org (Score:2)
I'm not so sure...
and they have a patent on it, too (Score:2)
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.
privacy vs. publishing (Score:2)
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).
It's called PKI (sort of -- but not really) (Score:2)
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.
Hemos says: (Score:5)
And when writing a book, the issue would be what words go where and such.
Jonathan Swift is the name you're looking for (Score:3)
Our friends, the clams... (Hello Xenu!) (Score:2)
LDAP & Web Services Solves the Problem (Score:1)
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.
Re:Hashed passwords? (Score:2)
Trasnporting info (Score:2)
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?
But a benevolent body... (Score:5)
Re:Hashed passwords? (Score:1)
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.
Re:Why use another commercial web site for this? (Score:1)
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.)
Re:Interesting... (Score:1)
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.
Re:Hashed passwords? COOKIE DEFINITION (Score:1)
Trusted Audits (Score:4)
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.
Solution in search of a problem? (Score:3)
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 [andrewsullivan.com] or Modern Humorist's site [modernhumorist.com] 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?
Jabber use (Score:2)
A modest proposal (Score:1)
Hashed passwords? (Score:2)
Re:Hashed passwords? (Score:3)
So go vote for bug 58647 [mozilla.org]
(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.)
Re:Privacy concerns (Score:1)
additional network traffic? (Score:1)
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.
Random Thoughts on Decentralization (Score:2)
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.
Re: user-stored data, offline xfers, more fixes (Score:1)
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
Re: xfers without user-owned keypairs (Score:1)
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.
Re:Privacy concerns (Score:1)
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!
Re:and they have a patent on it, too (Score:1)
- Steeltoe
Re:Solution in search of a problem? (Score:1)
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
Best USB Dongle (Score:1)
my favorite idea would be a USB dongle-type device (or "token") that could be worn or carried on a keychain
Dallas Semiconductor [dalsemi.com] have (IMHO) the best of such devices, as part of their iButton [ibutton.com] product range. It's a USB fob for iButtons [ibutton.com]. 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.
Re:privacy vs. publishing (Score:1)
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
We don't NEED identification services. (Score:2)
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
Sounds a bit like "Freedom" (tm) (Score:1)
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
Re:Trusted Audits (Score:3)
You can do something like this if you have an American Express card.
American Express has a service called Private Payments [americanexpress.com] (there is a FAQ [americanexpress.com] 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 [americanexpress.com] card, which has a Smart Card chip onboard, you can get a reader [americanexpress.com] that will let you use the Blue card as a security token! I need to think about that one... Anyway, a serial port reader is free and a USB reader is $25. And Compaq makes a keyboard with a reader built-in, probably intended for use in a POS setup.
steveha
Re:already exists: xns.org (Score:2)
--8<--
Spoofing (Score:1)
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).
Re:Hashed passwords? COOKIE DEFINITION (Score:1)
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.
Re:Interesting... (Score:1)
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).
Re:I still see a potential privacy issue... (Score:2)
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 [slashdot.org]). 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.
Partially Logged in.. (Score:1)
-foxxz
Getting more users than Hailstorm (Score:4)
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.
Re:Solution in search of a problem? (Score:2)
The tip jar image contains personalized information because it is loaded from Amazon.com. 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'm a little confused here.... (Score:1)
Re:Privacy concerns (Score:1)
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.
Are you sure..? (Score:2)
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.
oh boy, here come the authentication wars (Score:3)
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.
Re:Hashed passwords? (Score:4)
The problem with the "your browser remembers everything" system is that it assumes that you always use the same browser. That just isn't the case, though. I have several browsers on my home computer- I dual boot, for instance, so I can't always use the same browser, even if I had a specific favorite- so I'd need to have the information stored in each browser. I also sometimes browse at work, where we have several shared computers, and I'd need information on each of those computers. The latter is particularly scary, since it would be comparatively easy for a coworker/ITS person to get my information from the computer. This kind of thing is not atypical, either. It might very well be more practical to have a networked server of some type that I could log onto from any browser for data storage and authentication.
Re:Current research... (Score:2)
Integrate it into the browser, and use LDAP (Score:1)
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!
Kudos to Dave, yes, but this is not new. (Score:2)
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 [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.
Re:A modest proposal?!?!? (Score:1)
Passport evolution (Score:2)
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.
Re:But a benevolent body... (Score:1)
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...
-----
Re:Hashed passwords? (Score:1)
Security (Score:2)
Re: (Score:1)
Re: (Score:2)
Comment removed (Score:4)
cookies (Score:2)
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 [eplugz.com] comic strip
Re:Privacy concerns (Score:1)
Re:Privacy concerns (Score:1)
Re:Privacy concerns (Score:1)
Re:Privacy concerns (Score:2)
Optional data includes things like:
- your actual email address
- zip
- age
- city
- state
etc..Why not DotGNU, Dave ? (Score:1)
Are you, Dave ?
DotGNU.org [dotgnu.org] as a decentralized id and all the web services on crapNET (tm) done the GNU way
XNS (Score:2)
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...
I would suggest a good advertising campaign (Score:1)
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 ???
Why use another commercial web site for this? (Score:2)
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.
I still see a potential privacy issue... (Score:4)
In a sense, this member.xml file he proposes sounds similar to a cookie. Something would have to be in play to ensure that all the sites don't have access to the all the data in that file.
Phrased another way, I think the problem (though not an insurmountable one) in the this plan is that the file "contains all the information I wish to make public." This assumes that I wish to make the same information available to different groups.
So while I'm open to giving out my real name and official email address to, say, a job search site, I'd rather not make that available on slashdot. (Not that it's hard to figure out.) Similarly, many people -- myself included -- may be willing to give out information such as gender, race, etc., in some places, (for example, an online dating service), but would not want that information available to potential employers.
Yes, measures could be put in place to ensure that access is restricted, but keeping all that info in one file makes me a little uneasy -- too much like a cookie for comfort. I'd like something stricter.
Not very useful (Score:1)
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.
Re:Jident (Score:2)
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.
Jident (Score:4)
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 [madasafish.com]. This would be ideal IMO, and Jabber+Jident could be a perfect counter to Hailstorm+Passport.
Re:Jident (Score:2)
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).
Re:and we're listening to WHO? (Score:1)
Wow. Thanks for that link. That pretty much shoots to hell Dave's credibility.
Re:Are you sure..? (Score:1)
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...
Re:Are you sure..? (Score:1)
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.
Can really see the problem (Score:1)
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.
decentralized login? I'm missing something (Score:3)
It's also good because it is trivial to allow particular authentication domains while rejecting others.
Derek [maplesearch.com]
Re:Are you sure..? (Score:3)
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
Without the scary stuff??? (Score:4)
I cannot remember the author offhand, though, can anyone help me out with that? Or a link? I'd like to read it again..
already exists: xns.org (Score:5)
Graham
Current research... (Score:4)
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...... :)