LiveJournal Founder Launches OpenID System

geekdreams writes "Brad Fitzpatrick, the founder of LiveJournal, has launched OpenID, an 'actually distributed identity system' for websites that accept user comments. The system utilizes decentralized servers to authenticate users, and aims to replace centralized ID systems such as Microsoft's Passport and SixApart's TypeKey. The first implementation of OpenID can be seen on LiveJournal comments pages." Previously mentioned on Slashdot, now out of development.

A dupe with a note saying it's a dupe

is still a dupe, especially when the note wasn't part of the actual submission

We just need to kill passwords

Universal hardware tokens. Please.

Can hardly wait...

I can hardly wait if/when systems like this become popular, to be forced to register an id like Martian5576567567 due to every other numerical possibillity haven been already taken, due to alot of sites using such a system, and people forgetting about passwords or old accounts and re-registering multiple times.

Also isnt there an issue if somone discovers your password, they can "pretend" to be you on any site including sites with sensitive information such as paypal and the like...

Re:Can hardly wait...

I'm not addressing your security issue.. I think OpenID is not designed for secure applications (banks, credit cards, etc) - its more for bloggers, chatters, forums, etc etc.

Anyone can run an identity server.. so for instance each ISP could have one, or you could choose to use Google's, or Yahoo's, or Livejournal's.. or even mine, if I choose to run one for my website. In an ideal world, AOL could run one and integrate it with their AIM logins. Microsoft could run one and then Passports would work too.

Having a decentralized system allows you to avoid problems like this - it's kind of like jabber in my mind. I don't know *too* much about OpenID yet but this is the general idea.

A good Idea...

...but a questionable implementation. This is very utopic in nature (not having a centralized server storing everyone's data) but it doesn't feel feasible to just "trust" a decentralized architecture to hold/store my personal information without designing it from the ground up with security in mind.

Just my 2 cents...

Self Obsessed ID system?

If it is like LiveJournal, I am sure lots of self obsessed people will want to use the ID system.

The point?

On the one hand:

Sites that let you enter your name/URL/email/etc and show it without verifying you're you are lame.

On the other:

Somebody could run their own identity server that says they're http://spammer.example.com/000001/ [example.com] all the way to http://spammer.example.com/999999/ [example.com] and that's not a goal of this system to prevent.

If anyone can run their own identity server, then why use this rather than a (probably more user-friendly) Captcha [wikipedia.org] system?

Re:The point?

Captcha solves a different problem. Captcha proves that you're a human (more or less). OpenID proves that you are you. That doesn't prove that you're a human; it just proves that you know a password. But since you're the only one who knows that password, you're uniquely you and you don't have to create a separate account on each system you visit.

So it's a convenience for users, not to prevent spammers. This does have spam implications: you can blacklist/whitelist ID servers and you don't have to give your email to every site you visit, but it's not really about preventing spam. It's about simplifying the mass of passwords and accounts you have.

DOA

Something like this is simply DOA. Few content providers will take advantage of this because they have their own in house and/or have never heard of this guy or his company. If say, Yahoo was to do it, it'd take off like wildfire. But Yahoo's a perfect example... their one id system is and has been in place all throughout their growing universe of web content. As is, does the creator really think that people will be clamoring for one for a blogging site? c'mon... blogging is still quite the ego-centric niche.

What this is actually good for

Many blogs require you to register in order to be able to comment so that the person who runs them can control trollish behavior. This sort of system is good for letting people avoid having to register to be able to post on dozens of blogs.

Registration is mostly good for keeping away trolls who can't even take the time to learn their native dialect of English well enough to write a coherent and grammatically correct post. Sometimes it's horrifying to read the structure of such posts because you realize how far our schools have fallen. I've gotten ones that if I didn't have a college-level grasp of English, I'd have no idea what was being said.

As long as security is the first priority, this is a good thing. What I wonder though, is how secure this could really be without centralization. The appeal of SixApart's service is that SixApart is guarding it aggressively from being cracked... so who runs this service? I'm not sure how well you could trust a P2P system like this since you have no definitive authority to say "this user is who he/she says they are."

All that jazz

About openID
Sometimes i wonder
Why we don't have it shut
Closed ID seems smarter
Burma shave

Seriously all this jazz about the OpenID systems left right and centre from so many sources , yet non of them work , perhaps a new vector is required

It looks vulnerable to spoofing

On the http://openid.net/ [openid.net] page, it suggests that untrusted websites might popup a login dialog for your own trusted server. That would open a huge hole for man-in-the-middle attacks based on the various browser "url hiding" vulnerabilities. The fact that that behavior is suggested as canonical seems unwise.

This is a good step

Taking the items one by one:

1. XML-RPC had a recent exploit that could be revisited in a very nasty way. Even though this appears to use POST, it's still looking pretty complicated from my perspective. I think the same results could be achieved in a much easier way.

So your first argument is that one of the components involved had a security problem? You'd better stop using the internet then, or maybe even your own CMS.

2. I think the motivation for this service is skewed. The only motivation I can detect for Open Id is to save people FIVE SECONDS by logging into a new forum, website... etc. People already have their own methods to achieve this kind of simplicity in their lives.

The end goal of this is much more grandiose. One thing that is both a strength and weakness of the Internet is anonymity. Blanket anonymity has no doubt been a plus for many people over the years, but it's now much more of a problem than it's worth. The Internet in general needs a way for the average user to present credentials to internet services that is automated, fast, and simple. This would be a building block for validation of web sites, e-mail messages, decentralized public key distribution, and a lot of other useful (and badly needed) services. Removal of blanket anonymity (but not elimination of all anonymity) will improve the signal to noise ratio of internet data by several orders of magnitude.

3. Tools like Firefox's "remember password" make these kinds of shared identity systems obosolete, don't they? Who cares how many passwords you have to remember? You don't have to remember ANY of them anymore, really.

That's why that feature of firefox gets disabled by many corporations. It's very insecure. Other options for storing long, non memorable passwords include palm pilots, dedicated password PDAs, and such. They're clunky and sooner or later passwords will become too long to type in anyway. Being able to reference the place to *get* the user's password (along with their encryption settings, public key, etc) is actually more secure.

4. Caution should be applied when linking with systems using any kind of third party medium. KISS.

The Internet is by its nature much more interdependent than you know. It's impossible to do anything online without using at least a few dozen interlinked systems and standards. In general, keeping it simple is a good design rule but it tends to produce simple, monolithic system designs that are unsuited to Internet scale activities. For an example of a large scale distributed service that is as simple as possible on the Internet, check out the DNS design RFC.

5. A system should rely on as few other systems as possible. Minimalism will make a web experience a happy one.

This is an over-generalization. True that dependence on proprietary systems is generally bad because proprietary systems are usually not subject to the public evolutionary process applied to open standards, and therefore can have more problems. In general, simplicity triumphs over complexity when two ways of doing the same work are compared. Complexity wins out if a better (faster, easier) way of doing the work happens to be more complex.

6. This could be ripe for phishing.

I'm presuming you mean people could send e-mails saying "go to this URL". They can do that now. This would actually help with Phishing deterrence if users learned to only trust "verified" e-mail sender identities.

7. Lag. If systems must cooperate, they should do so passively. Most XML-RPC calls, for example, will put the lag on the end-user. This should become a passive cron job or something like it, if it must be used. Make the user "temporarily unverified" until he/she/it can be verified at a later date by an automated process. Let the lag be placed on the system, no

Easy Identification Across Web Sites

A big reason for me like this (and dislike it at the same time for security reasons) is that with a widely distributed system like this is will make it easier to keep track of who said what, even across multiple web sites. Each person would have the same name across many web sites, so those of us who are involved in multiple online communities can more easily keep track of people that share more than one common community with us. For example, I could identify Slashdot posts by people that go to the iDevGames forums like I do.

public PGP key repository

Forgive me if I'm being naive, but couldn't we have more or less open posting if whatever bulletin board system required a PGP encrypted post, and checked it against a central authority, or even several authorities?

NoCatAuth

There seems to be quite a proliferation of these services, eg. NoCatAuth, which is used in several projects.

Interesting

Providing you actually have a URL, this may be slightly better than the existing typekey technology. However, only 1 in 14 internet users has their own blog or website. The more options the better I suppose, but this is really an evolutionary step rather than a revolutionary one.

Universal Authentication?

I am treading out in unknown terriroty here, but is it not possible to use some authentication mechanism on a central server, and verify it, u know like Kerberos/Passport/alternative? Or is open-id trying to do exactly that?

Self-Identification

A few days before the LiveJournal system came out I released something very similar (this is not sour grapes; they have very generously acknowledged my work) called mIDm. You can view it here: http://www.downes.ca/idme.htm [downes.ca]

I was very pleased to see the LiveJournal system because it acknowledges what no system has done before: that identity belongs in the hands of the users.

This has two major aspects:

First, as argued over and over on the LiveJournal site, this is not an authentication system, it is an identification system. You are not being required to prove you are who you say you are, you are instead being given a mechanism to declare who you are.

It is, in purpose and intent, as secure - and no more secure - than filling out a web form. But the idea here is that you fill out the form just once, and then using a system of call-backs (to ensure your personal information isn't spoofed) you can use that information anywhere on the web.

Let me repeat that, in case you didn't get it: anywhere on the web.

The idea is, if you want, you can have the *same* identity on each of dozens of websites. Which means, say, if your email address changes, you change it once, and this information is now available (if you want it to be) to all of your accounts. Ditto your home page.

I will leave the many many applications - such as web-wide peprsonalized display, in-page messaging, multi-site social networking, and more - as an exercise to the reader.

Second, what it means is that the system is distributed. This means that there isn't some centralized grand poobah of identity (the way Passport tried to be, the way Sxip is trying to be). It means you can choose any system you want to host your identity or you can build your own.

Let me repeat that: you can build your own.

Don't like their security. Make yours tighter. Too much lag on LJ. Host it yourself. Want to send different emails to different types of site. Code it.

One of the mistakes made in previous system was in the use of a one-size fits all model, which meant that the level of security had to be at the highest possible - which is orders of magnitude more than someone needs merely to write blog posts and comments. Building a distributed system allows each person to decide how much - or how - security is appropriate.

Having made these two points, I would like to mention briefly where my system goes beyond LJ's. In their system, you are still typing your home URL at each site you visit. In mine, you don't ever have to type your home URL - it is stashed in the browser agent environment variable, where it can be picked up by any site that needs it. Oh I know, you probably shouldn't do that - but I've been testing this for months with no ill effects. YMMV, and if you have a better idea, I'm all ears.

Despite the naysayers here on Slash, this system - or something very like it - will become the norm on the internet very soon.

Why?

- Because it will be very simple to install for websites, especially after things like Drupal and Wordpress modules are built.

- Because it will be very simple for the user, because they just need to type one thing in (or extensions will be built for my type of system).

- Because it will work.

- because it will be no less safe, and probably more safe, than filling forms willy-nilly everywhere you go.

xdi.org and I-Names??

this sounds like the stuff XDI.org do. with i-names and so on...

Sold!

Ok I'm sold! I already thought it was a good idea, but the best part is, if you are worried about the stability of an OpenID server [and want your personal URL] it is convenient even if you don't have the ability to run your own OpenID server! You can just DELEGATE [openid.net]! Enter your personal URL, but it will do the actual identification from whatever OpenID server you point it to [say livejournal]. That way, if LJ [or your chosen OpenID server] goes away, you simply change your delegation to point to another OpenID server [where you will need an account of course], but you will still have your own URL as your identity. You don't have to change it just because your OpenID server doesn't exist anymore. Very nice!

Taking it a step further

What if we took this idea a step further and added a form of authentication, namely, signing of messages?

Here's what I have in mind, please point out any flaws in my logic:

• I log into livejournal.com using my id, "hisham".
• I post a message at foo.com using my OpenID, [e-mail].
• foo.com sets a cookie in my browser, and issues a request to livejournal.com, with the cookie and the message.
• livejournal.com receives the request, verifies the cookie (confirming that the request from foo.com was posted by a browser who's actually currently logged as hisham in livejournal).
• livejournal.com then signs the message and sends the signature back to foo.com.
• foo.com posts the message saying that [e-mail] posted it, with the signature in the end (or most likely, accessible through a link).
• If anybody wants to verify if the message is legit, they can copy-paste the message and the signature and check it in a verification form in livejournal.com.

The system is still fully decentralized (anyone can host their own "OpenAuth" servers) and you only need to trust one of the sites (the signer), not both as in OpenID (though "trust" in the sense of OpenID means just identification, not authentication -- and I'm fine with it since that's its purpose).

Off the top of my head, the only two potential issues I see are:

• the signer server would see everything you posted anywhere -- but anyway, Google see all my emails... if this is a concern, host your own server;
• the load on the servers -- would this be a big problem? most sites could use lighter, less CPU-intensive cryptography... again, if this is a concern, host your own server with 1024-bit crypto.

What do you people think? Could something like this work??

Problems with OpenId

I've expounded on [livejournal.com] why OpenID is insecure and I believe it is unnecessarily complicated.

Problems with OpenIDI put off reading the OpenID [openid.net] spec [openid.net] because I though it was probably flawed. Now I just feel applying my head to my desk.

OpenID is led by with this philosophy:

The point of OpenID is to be dead simple, short-comings and all, so it's actually adopted.

The above is taken from a discussion [danga.com] of vulnerabilities. The problem with this lowest common denominator approach is that it's horribly broken. OpenID is currently no better than just giving the URL of your blog.

The number one problem is the complete lack of integrity checking. Everything in OpenID seems to be perfectly happy to let their requests be modified in transit. I think the problem with this are pretty damn obvious: nothing can be trusted. Fortunately, fixing this is pretty simple: use TLS [ietf.org]. In today's shared hosting environment, you probably want to require support for server name indication [ietf.org].

Another brilliant idea: transmit the key that you'll use for signing later in plaintext.

Yes, you can ask for DH-SHA1 encryption and get back a plaintext secret. If this troubles you, don't use the handle and instead use dumb mode with that server. (and if somebody sniffed the plaintext secret, it won't matter, since you'll never accept queries using that assoc_handle). If the server can't do DH, it's probably limited in some way, but using dumb mode is still safe, if not a little slower.

I believe "limited in some way" means "completely insecure." "Dumb mode" is not safe because there's no key associated with the server, so there's no way to ensure you're talking to the same one or that someone isn't tampering.

I also don't see much point in using a symmetric key for speed and security when you're just encrypting a short string. It's so tiny that both improvements are similarly small.

Perhaps the biggest problem with OpenID is it's reliance on sending a user to another page to login. It's just too easy to spoof a page and fool most people. Even better, you can open a window using Javascript and hide the location bar. Even if you normally use TLS, most people probably won't notice if it's missing or the certificate is different. Also, most sites (including LiveJournal) include a completely insecure assurance that you're secure. For example, LiveJournal [livejournal.com] says "LiveJournal Secure Site "

A simpler and more secure alternativeThe only way to fix this is (gasp) get users to carry their own keys. If you stored your key in a bookmarklet or extension, you could sign something with it. This is completely feasible because Javascript cryptography implementation [zonnet.nl] is done. You could submit your public key with the signed comment. If you wanted to associate yourself with a URL, all you need to do is link to a page with the public key. If the same public key can be used for the signature.. That's right, no special identity server is needed. The public key could be submitted directly or it can be linked to. It might be a pain to write out the entire URL to the key, so perhaps autodiscovery-from-HTML should be supported:
<link rel="openpgp.key" href="http://www.livejournal.com/pubkey.bml?user=a trustheotaku" />
Note that no TLS is needed. The signature is secure in and of itself. If you want to support all the fanciness (e.g. revocation) of OpenPGP [openpgp.org] (spec [ietf.org]), then you just need the

Hmmmm

So one could almost say that it's like a passport that allows you to "log on" to lots of different sites...

How does this prevent you from saying you're me?

How does this prevent me from saying I'm, for example, the previous user that posted a comment? He has his server set to trust the site I am posting on, and I'm using his name, so shouldn't the server accept my comment, since it doesn't know who's posting? I know this is not supposed an authentication scheme, but an identification scheme where everyone can claim to be anyone else isn't that good, IMO.

Re:Not really that good, IMHO.

step 11. profit!

Re:Not really that good, IMHO.

Just as an aside, the XML-RPC vulnerability was based on items in the PHP community, and not in the module used within Perl. Danga and the LiveJournal team have been working with XML-RPC for quite some time, and they tend to be nazis about the security of their implementation.

Re:Not really that good, IMHO.

Tools like Firefox's "remember password" make these kinds of shared identity systems obosolete, don't they? Who cares how many passwords you have to remember? You don't have to remember ANY of them anymore, really.

Not really.. if you aren't remembering passwords, you're pretty much out of luck when you go to another terminal, or forget to backup your firefox directory and lose your data.

Maybe this type of system isn't for you, but I can definitely see some use for it.

Also, just because something is complicated doesn't mean it'll eventually get exploited. Things can be complex, yet well thought out and secure.

Re:Obligatory

No, this is not obligatory. You chose to continue the trend...

*sigh* oh slashdot...

Not that bad, either

The only motivation I can detect for Open Id is to save people FIVE SECONDS by logging into a new forum, website

I'd have thought the motivation was to limit the number of separate accounts you need. Having a billion accounts running around is a massive security nightmare. Either you're using the same password everywhere (and telling every web site owner your password) or you're wandering around with a notebook of thousands of passwords.

Firefox won't remember your password if the computer is a public terminal, or if you use multiple computers (e.g. at home and at work.)

No, this isn't the ultimate solution (which involves encryption, a portable very strong crypto key time-based challenge-response, and perhaps biometrics), but it could be a good half-measure.

Re:Not that bad, either

There aren't central servers. This is DECENTRALIZED. Run your own OpenID server. Now you control EVERYTHING about validating that you are you. This does NOTHING else. There is no profile exchange, there is no password exchange. All this does is says that someone using OpenID [e-mail] (if slashdot ran their own, for example) on Livejournal is the same person that is claiming to be [e-mail] on slashdot, and [e-mail] on Deadjournal, and [e-mail] on any Moveable Type journal, and [e-mail] on (whatever implements this system).

This is a means of identification. You log in to a site. The site passes off a redirect url, of sorts, to the OpenID server (the part after the @), and asks THEM to verify who you are. The OpenID server does this, and either goes to the URL it was directed to, and now you're 'identified' to the original site, or says no .. and you don't go any further.

So, what if they spoofed the OpenID server, made it always say yes? Then now you have anyone @that_openid_server can ident as anyone else. This doesn't compromise me@some_other_server. I'll probably end up running my own OpenID server, and having my account on it. Or maybe get my friend to, and we'll all share. Small and localized, one password to remember, and works anywhere (home, work, laptop, desktop, friend's house..) and the authentication goes away when I close the browser window.

What, exactly, is wrong with this ... except now I can Identify myself to websites without needing to worry about whether or not they're going to steal my password and try it on every website that's popular?

Re:Not really that good, IMHO.

It's not necessarily about the passwords; would you want someone over on k5 or livejournal posting about their double life with a mistress and a secret cave where they crossdress and watch old Three's Company episodes using your username? "h@@@@@y, I'm mfh and I was jsut wondrin how 1337 i have 2b to g4t ino yor haxxxxxx1ng growp? -- mfh"

It would be easier to identify someone (and harder to spoof someone) if their ID information carried across multiple sites.

Re:Rivalry

Although he's competing it sounds like he's also willing to cooperate with SixApart

TypeKey -- Centralized registry. Not everybody trusts SixApart to control their identity. (But if you already use TypeKey, there's a good chance a future version of TypeKey will also be an OpenID server... I'm pushing for it at least, and volunteered to do the work.)

and his comments about spam and trust lead one to believe that these are area's SixApart's service could fill.

Re:Not really that good, IMHO.

2 I think the motivation for this service is skewed. The only motivation I can detect for Open Id is to save people FIVE SECONDS by logging into a new forum, website... etc. People already have their own methods to achieve this kind of simplicity in their lives.

3 Tools like Firefox's "remember password" make these kinds of shared identity systems obosolete, don't they? Who cares how many passwords you have to remember? You don't have to remember ANY of them anymore, really.

One of the things I hate about internet is precisely this. Face it, how do you feel when some links in slashdot to a "register for free!" kind of link? I also hate when I go to a blog or a online forum and I'm forced to register, wait for email, login, etc. Most of the time I give up - this thing would fix those problems.

Re:Not really that good, IMHO.

One of the things I hate about internet is precisely this. Face it, how do you feel when some links in slashdot to a "register for free!" kind of link? I also hate when I go to a blog or a online forum and I'm forced to register, wait for email, login, etc. Most of the time I give up - this thing would fix those problems.

On the surface you might think that this thing would fix those problems but I highly doubt that it will change anything.

Think about it: If the New York Times wouldn't adopt Microsoft's Passport solution do you really think that they are going to adopt this solution by a (in their eyes) virtual nobody? If something with the backing of the largest software company in the World couldn't take off then I don't hold out much hope for this except perhaps for some blogs here and there -- but that hardly solves the NYT problem.

Re:Not really that good, IMHO.

[OpenID] hardly solves the NYT problem

Well, assuming this OpenID thing is really great and wonderful and doesn't make the baby jesus cry, then perhaps a lot of small sites will use it. And if a lot of small sites are using it, it might trickle up to a decent amount of medium sites, which might get noticed by a few large sites.

No one liked Passport so that's why it didn't get used. This is a different idea which has a slim, but possible, chance of success.. even on large sites.

Re:Not really that good, IMHO.

What do I win?

Being modded down?

Re:Not really that good, IMHO.

For 2, it does get to be a pain when you are signed up to 20 or 30+ forums. Example? these days, a lot of software support and bug reporting facilities are on a forum. It's a bit of waste of time if you have to sign up just to make a couple posts.

I'm not saying that we need more services like the one in the article, but it would be nice to have some sort of simple way to fix this.

Re:Not really that good, IMHO.

For myself, i don't think it's the fact of having to spend "5 seconds" logging into different sites. I think it's more so the fact of the number of different passwords/usernames i have in use on different forums. For the most part, i try to use the same username/password on most forums, but sometimes my username is taken, or something like that, then i have to try and remember what the username is, etc. I like the idea of this, and hope to use it in the future.

Re:Insecure by design

And Centralized systems are inherently insecure because your single point of failure is your system. The whole thing can crumble if one mistake is made. You have to build in redundancy and round-robin DNS is simply not redundant for a very large scale.

There are many fun topologies out there like Decentralized Ring (ala Gnutella2; don't knock the design just because the inventor was controversial) which work around issues in simple systems such as Distributed or Centralized. Ultimately your application will decide what the best topology to use is. Authentication is debatable but i've always found it easier to deal with differing systems for different levels of trust in the authentication (for example, to get into your bank 3 levels of authentication would be more ideal than the username and password you use for your Blog, and neither system -needs- to have the same authentication system as the other).

Re:Not really that good, IMHO.

I think the motivation for this service is skewed. The only motivation I can detect for Open Id is to save people FIVE SECONDS by logging into a new forum, website... etc. People already have their own methods to achieve this kind of simplicity in their lives.

5 Seconds? Where did you get that benchmark?

I'm a CMS designer,

Ah, that explains it.

If I'm on a computer I trust, I might allow it to save my password. If I run accross a forum that requires a login, I'm more than likely not going to take the time to create a login, just so I can participate. Why? because I've never seen one that only takes 5 seconds. Most send emails, which add considerably more time and pain (I gave up using POP email when I changed my email for the 10th time (@home failed, to be exact).

Not that his solution is perfect and that all of you points are not valid. Just that its not such a bad plan at its core.

Re:useless

Of course, when I find/steal your wallet, with the tattered but legible cheat-sheet with all your IDs and passwords written down, 'cause you can't keep all fifty of them in your head, I'll bankrupt you in 24 hours.

Re:Not really that good, IMHO.

First of all, look at the reason this was created. There are hundreds of livejournal clones out there, and a lot of them run the livejournal software (deadjournal, blurty, etc.). I'm not going to create a new journal on each one of those sites just so I can view the friends-only posts of my friends on those sites, and especially not just so I can comment. This provides a way to link all of those sites together, and it does it openly, in a way that sites that don't use LJ's software can use.

Secondly, addressing your remember passwords comment, it's a complete waste of resources for the system for these users, who just may want to leave a comment, to force them to sign up for an account. Why not just let them provide a reference URL which represents them, and let that server verify that the provided URL is the user's?

Many of your points were simply "This is complex", or "This requires relying on more systems", and conclude that it's bad. Firstly, I think 'rely' is the wrong word for this. You're using these other systems, yes, but if these other systems go down, it doesn't stop you from doing anything. It's similar, though not a perfect analogy, to saying that having more IRC servers in a given network is bad because you're relying on more servers.

Also, imagine the advantages this gives when designing around this system. Forums which are really only for one topic, such as an official forum for a specific piece of software, don't even need to store any user or password information (and therefore don't have any sensitive data). The forum can simply store the OpenID URL for the admins and allow anyone who can verify with that URL do all of the admin work.

It's the first step to providing a true roaming profile, and single sign-on for the web, and it's done in an open manner. I think it's a step in the right direction.

Re:Insecure by design

I am in total agreement with you, but such a system would be a frequent target for identity theft attacks. Therefore such a system should have multiple biometric security measures, including fingerprints, DNA, retnal scans, and voice samples.

Such a system would be the foundation of a new set of services as well. For example, if all the citizens of the world would wear a GPS transmitting necklace or under-the-skin implant no one would ever be wrongly accused of a crime or be accidentally lost in the wilderness. With bio-scanning technology the government could ensure that you're vital signs were normal and if they became erratic they could send aid.

Only with a wonderful benevolent government like the United Nations can we ever begin to see the wonders of these technologies and rid ourselves of all the risks of the dangerous ideas of freedom and privacy.

Re:Not really that good, IMHO.

1. Not relevant. It is _not_ complicated. There will be libraries (that do not use eval()) that handle all of that "complicated" (http?) stuff. 2. Five seconds if you have an account. 3. Doesn't give you a single id. 4. Email? DNS? 5. ? 6. Conceded. This isn't targeted at banking applications though, still, it's something to watch for. 7. OK. 8. Once again, it's not foolproof, but it fills a niche. 9. CMS designers are often morons. Get a real job.

Re:Not really that good, IMHO.

1. if it is a problem... they'll patch it
2. No... it's to save you remembering which login (hmm... was this nick? or email address?) and which password (These !@!#s don't allow periods?)
   
3. Although 'remember password' is nice... how many people truly trust that local database to be secure? Even if you are not paranoid... how many people hate it when they are on another machine that doesn't have it remembered and they can't remember even more passwords because they don't usually use them
   
4. Yes you should always be careful with 3rd parties in trust relationships... however all this service does is lets another site say 'With those credentials I will vouch for them being this person on my site'. It doesn't prove they are Joe with bank account number xxxxxxx... it proves they are [e-mail]
   
5. Granted... outside systems always leave you open to failures beyond your control. But... it is a ton easier to say 'livejournal users arn't working because livejournal is broken' than saying 'ohh shoot.. we're sorry our database died and we lost all the users'. Both situations will RARELY happen... and if a user can't login cause their verifier sucks they will get a new one.
   
6. The phishing only works if you have their password... which... why would you phish then?
   
7. Nothing comes for free... but I think most users would take 3-5 seconds of lag on first login to save the setup/remember torture
   
8. This system is designed to let you prove you are the user of another system... and it does it securely... this isn't something to use to login to your bank account with... yet... :}
   
9. That infers you are within one CMS...
   
10. There is no #10 ;}
    

11. Profit!!!

11. Profit!!!

(Sorry, had to!)

Re:Insecure by design

And they will conveniently have a full and complete list of "nice people" for whatever re-education program the UN comes up with...

No thanks. I barely trust my government, and I vote for the suckers.

Re:Not really that good, IMHO.

1 I think the motivation for this service is skewed. The only motivation I can detect for Open Id is to save people FIVE SECONDS by logging into a new forum, website... etc. People already have their own methods to achieve this kind of simplicity in their lives.
There are many uses... who really wantes to have to register to 50 sites, just because you wish to post a comment or two, or ask a question at a site?

2 Tools like Firefox's "remember password" make these kinds of shared identity systems obosolete, don't they? Who cares how many passwords you have to remember? You don't have to remember ANY of them anymore, really.
If you are really concious about security, you NEVER use these "I will remember your password..." becuase if someone gets physical access to your system, you are screwed.

3 Caution should be applied when linking with systems using any kind of third party medium. KISS.
How is linking a URL security-prone? You are NOT showing your password to anyone, at anytime.

4 This could be ripe for phishing.
Phishing what? Your ID?

5 This system provides a false sense of security. You will never know exactly who you are dealing with over the internet. Behavioural tests should be part of this system and they are lacking. Also, nobody is going to use a secure pipe at both ends to handle this kind of data, are they? Uh...
Once again, they DO NOT REQUIRE PASSWORDS So why use a secure pipe FOR A URL?

Personally, I belive that this is a great service, and will be welcomed by myself. The genius of the idea, and let me note one last time, the non-need of a password is a key feature of this idea.

Re:useless

this further propagates the idea of centralized identity management.

Christ on a cracker, I know this is Slashdot, but could you at the very least read the summary?

The system utilizes decentralized servers to authenticate users, and aims to replace centralized ID systems such as Microsoft's Passport and SixApart's TypeKey.

Re:Not really that good, IMHO.

2. It takes a little longer than just five seconds to register for a new service. First you have to spend at least five seconds filling out a form and squinting to read the CAPTCHA. Then you have to wait a few minutes for the email to finally arrive and then confirm it. Of course, I'm only talking about the majority of services here. Clearly there are one or two (total) services in the world which actually take five seconds to sign up for.

Furthermore, that's not the only reason they did it. Suppose John Smith registers on 5,000 web sites. What says that JohnSmith at Slashdot is the same john_smith at LiveJournal? OpenID solves that part of the problem.

3. Last I checked, Firefox's "remember password" feature didn't help my home browser remember passwords entered at work. Furthermore, this feature doesn't magically register new accounts either.

4. I agree, and not having to register on 5,000 web sites is minimalism for most people.

6. If you'd bothered to read their documentation, they actually admit that rogue sites can do whatever they want, including simply not handling the OpenID information at all. What OpenID does is makes sure that sites which _do_ play by the rules have a consistent view of identity.

7. I'm sure most users would love to have to manage a cron job just to do something that web sites can do for them.

9. Let's see how.

Re:We don't need single sign-on!!!!!!

We don't need single sign-on to fill in a few form fields for banking, ecommerce, or blogs. The risks-to-benefit ratio just never works out. Its a few fucking form fields for Christ's sake!

Says the person who couldn't even be bothered to sign up to Slashdot...