OpenID is a cool idea, but it seems so complicated. 169 KB of spec:
http://openid.net/specs/openid-authentication-2_0.html
Anyone flirted with implementing this beast?
Personally I would rather use a library. When it started it, it seemed like something easy to do. Now it certainly isn't easy.
I agree that it seems to be over-engineered / suffering from second-system syndrome; however, I think the concept is far better than tripcodes, which are not user friendly in the least.
One dubious benefit to the tripcode system is, once people have gotten their head around tripcodes, that little random string attached to a name can be quite entertaining. OpenID et al are very boring in comparison. I've never seen another identification system that has provoked quite so much obsessive interest as with people trying random tripcodes in attempts to spell out words, or even using specialised programs to do so. There's probably a doctorate paper or three waiting to be written on creating interest in a system by injecting entropy into its output.
Well, I like OpenID's concept a lot, so what's the solution?
1) put up with the complexity, just deal with it?
2) make my own competing system that works the same basic way but is simpler?
3) any other ideas?
Unfortunately, stuff just naturally tends to get overcomplicated when lots of important people (who take themselves seriously) are involved, it seems like. You can't fight sociology.
Um, tripcodes aren't guaranteed to work across different sites, and furthermore they're much MORE difficult to use than a simple username and password box.
> tripcodes aren't guaranteed to work across different sites
Because there aren't any standards. Everyone implements them as they see fit.
> they're much MORE difficult to use than a simple username and password box
That doesn't make sense. In both cases you type your name and you type your password. With tripcodes you don't need to register and name is optional (usually).
>>8
I think >>7 means that the lone "Name" box isn't obvious that it is both a username and a password box.
>>7
The problem is that you're not supposed to put anything in there anyway. Nobody cares what your name is, so maybe the field should be labelled "Password" instead of "Name" in order to reduce confusion.
> The problem is that you're not supposed to put anything in there anyway.
Says who? The 4chan police?
If you're not supposed to put something there, why does the field exist?
Also there is a "standard" for tripcodes, at least a de-facto one. If your tripcode encoder does something different than what 2channel does, it's wrong.
In any event, this is swaying well off topic.
>>9
Corrrect, having a separate password box makes it obvious what it's for. Requiring "magic syntax" in a username box is a design flaw IMO.
But yeah, maybe just having a password box would be more useful, and leave everyone as "anonymous" with some mangled version of the tripcode. Although I get the feeling that this too will become a kind of username, and therefore people who use it will continue to be tripfags.
> If you're not supposed to put something there, why does the field exist?
The field exists because it is sometimes useful to identify yourself. But because it is sometimes useful to identify yourself doesn't mean it's always useful to identify yourself. Most of the time, it's just pretentiousness.
Most web-based applications that ask for identity, do it without valid justification, which significantly reduces the need for something like OpenID.
In fact, what most web-based applications need is an authenticator.
If the user creates a resource, maintaining authorization to manipulate (delete, edit, append, etc) that resource later is obviously valuable. The application doesn't need to know who I am in order to do that, they just need to know that I created that object. They can do this with an authenticator- say by recording an encrypted capability string with the object.
If the user needs to prove that they created that resource, they can do so easily. They can also publish the authenticator (or destroy the authenticator) so that nobody can claim to have created the resource.
>>13
That's clever thinking, I like that. Though if you don't religiously oppose pseudonyms (and I think some of us here are not dogmatic on the matter, myself included), then you can use OpenID for that.
>>14
You could use PGP for anything OpenID is designed for, and while I think something similar to OpenID could be useful for making authenticators, I don't think using an authenticator for identification is a good idea. In OpenID's case, it just shifts the authority onto DNS- something that can and still is broken regularly.
If a message board wants users to identify themselves, they should do the exact opposite and use an identification system as an authenticator. For example, it can require PGP-signed messages. If the user wants to delete the messages (or edit them) they can simply encode the change-request as a unified-diff that has been PGP-signed. Anyone can create a PGP-key, and despite convention, they don't have to be tied to an email address and could easily be used for pseudonyms.
I am extremely nervous about security protocols that are complicated, and opposed to security protocols that don't offer any value. Anything that starts talking about "credibility protocols" sets off red flags for me. In short, OpenID looks to me to be a bad idea.
>>15
True, DNS isn't secure. But OpenID is neat because (assuming the DNS hasn't been broken) it lets you say for sure, "This comment was posted by the guy who owns that web page." Could there be a secure way of doing this?
Possibly with browser PGP support, the comment/post/whatever could be required to be signed with the same PGP key as the web page linked to? This could still break if someone else got control of the DNS later, though, unless the browser can also verify it.
But this can't be done with current browser software, while OpenID can. Most websites' proprietary authentication systems are not secure either (they work over cleartext HTTP), so this is a functionality improvement, not a step back in security.
> OpenID is neat because (assuming the DNS hasn't been broken) it lets you say for sure, "This comment was posted by the guy who owns that web page."
You could simply put a file called posts.txt on your server that contained a list of SHA1 hashes of comments that you've posted on other sites, and include the URL to it in the "link" field. This would accomplish everything that OpenID can, and be far easier to implement than OpenID.
If the server checked that url periodically, messages could be redacted simply by removing the hash from the list.
> Possibly with browser PGP support, the comment/post/whatever could be required to be signed with the same PGP key as the web page linked to? This could still break if someone else got control of the DNS later, though, unless the browser can also verify it.
Oh, the point of using PGP wasn't to indicate who owned a website. There isn't any value in that and that knowledge is invalidated by breaking DNS anyway.
The best you can do is prove that DNS has been broken, which is done by supplying a secret (password) along with your signed message, or your url to posts.txt that you can supply to the applications you visit.
If DNS is broken, simply publish the passwords which makes any invalid entry easy to spot (because it's using a different password).
With OpenPGP you wouldn't need the web site at all, as the identity would be the owner of the key, identified by their email address (which is just as good IMO.)
>>18 You don't even need them identified by an email address- because even that is subjective.
Yep. The email addresses (identities) are optional aren't they.
>>20 Sort-of. There's no way to verify that the PGP key belongs to the person who reads mail at that address. Of course with PGP you simply send them an email and if they can follow the (PGP-encrypted) directions, you have your answer- but what good does that knowledge do the other party? I mean, they know that the person at the website controls that email address- but that doesn't add legitimacy in a world with hotmail and mailinator.com
The knowledge that someone controls a website or an email address simply isn't valuable in authentication protocols unless an existing trust relationship exists which simply isn't the case with the majority of web applications.
The people developing OpenID don't seem to realize this, which is why I don't recommend anyone deploy OpenID... Credibility protocols can always be gamed, which is why SEO is a market. Google can always change their credibility protocol quickly, but if a flaw is found in OpenID's credibility protocol, it'll just mean more spam for your additional efforts.
OpenID isn't a means of reducing spam anyway. It's merely a means of identifying that a guy on one page is the same guy on another page.
Sadly, it doesn't do this particularly well. It only proves that the guy who made the first post owned the same domain as the guy who made the post later -- not even at the same point in time, which means that a hostile takeover leaves all prior comments up for spoofing. :-(
>>23 I just saw that. Are you familiar with MSIE's xenroll (now certenroll on Vista) and Mozilla's crypto interface? See: http://developer.mozilla.org/en/docs/JavaScript_crypto
You could implement it- with authentication using Javascript right now. Of course, you could fall-back on GPG if you really think it's available in more places than Javascript...
Isn't the point of OpenID that you can easily register on a website by only typing your username/password and that you can log in to all websites using the same username and password, instead of having to remember many different combinations?
But even then I wouldn't want to use a lot of bloated libraries and depencies just to implement something as simple as cross-site user identification.
>>25 No. The point of OpenID is that instead of answering a bunch of questions (like name, email address, etc) you only answer one: the url to an OpenID agent. It's about as secure as <input type="vcard"> and about a thousand times more complicated.
practicality lol: would a random european or american internet active person ken using gpg keys to authenticate an identity or removing identity all together or some crazy decentralized identitymajig or hell even vcards?
for serious i can't think of any use cases for confirmable portable online identity save internet superstars, and no one should care about what they want.
Except that there is no <input type="vcard">
>>28 That's because there's very little need for <input type="vcard">.
Maybe.
I mean it would be useful for solving this particular problem but blog comment fields are, at the end of the day, such a tiny part of the WWW.
There are much bigger problems, like how to comment on a page which has no comment field (solved by Annotea and variants thereof, clients of which use dedicated UI to add comments anywhere on the page.)
I'm not sure this settles all the security concerns raised in this thread, but https://certifi.ca/ is a really neat thing.
You get a client-side SSL certificate for your browser, and certifi.ca securely identifies you using that. There is no password.
The OpenIDs it provides are still http://, not https://, though, so it seems vulnerable to certifi.ca's DNS being hijacked. I wonder why that is; maybe most OpenID consumers out there don't understand HTTPS? If the OpenIDs were https://certifi.ca/username, then would this not be totally secure?
I wish we could directly use a client SSL certificate on arbitrary blog comment sites so that we didn't even need OpenID as the intermediary.
But that's not realistic.
Only if OpenID agents checked SSL certificates. I don't think PHP does, and I'm pretty sure that Perl's LWP doesn't by default. I'd have to check implementations at that point.
A bigger problem is that OpenID even if the integrity is maintained still offers no identity-information.
I've thought about implementing OpenID on my imageboard. OpenID sounds great in concept and then I watched a screencast on how it works and was sort of overcome with its complexity. Not that is outright baffling, it's just that I expected something far more simplistic. I'll probably rely on a plugin for implementation, when I get around to it. And when I get around to implementing it, it'll probably be for my own amusement/trendiness since as far as I can tell not that many people even use OpenID yet.
As for tripcodes, besides the "magic syntax" argument someone already brought up, another problem with tripcodes is that they are (usually) unreadable and as result unmemorable. I've always wanted to design a readable tripcode system but never got around to it.
>>34
It conveys no identity information? Huh?
Okay, Mike Linksvayer's blog is at http://gondwanaland.com/mlog/. If someone identifies using the OpenID URL of http://gondwanaland.com/mlog/, we then know that person is Mike Linksvayer. Therefore we know that person's identity.
What part don't you agree with?
>>36 You're confusing identity with authentication. The OpenID spec-writers did the same thing.
Here's a trick: What is the value of knowing that person can authenticate as Mike Linksvayer? Versus the value of knowing that person is Mike Linksvayer?
It proves that the user has control of (or can read) Mike's email, can send DNS packets, works for AT&T, PAIR, or any of a dozen other single-points-of-failure. It doesn't prove that this person wrote other blog entries, or that they used another service previously. Only that they have (access to) the same authenticators. Mike retains plausable deniability- if he eats your babies, you probably won't be able to sue him because you won't be able to prove that he actually did it.
An Identification protocol necessarily prevents the user from disavowing their own identity (or without some well-understood cost). That means that if Mike identifies himself, and does wrong, you can prove it was him.
SSL is supposed to be an identification protocol, but nobody actually goes through the work of checking the identity of SSL subscribers, and QuickSSL is cheap. As a result, if you get scammed by a website, there isn't a lot you can do- even if they got an SSL key.
OpenID is an authentication framework. It theoretically could be used in combination with some use-policy and an identification protocol, but OpenID punts on these things in an effort to get deployment/popularity.
An anonymous system avoids these things: You don't know who I am, and you don't have any expectation to know who I am.
>>37
OK, I guess I see whatcha mean, but it does still solve the "HAHAHA DISREGARD THAT, I SUCK COCKS" problem, for all practical purposes, and there's something to be said for that.
>>38
disregard that, I suck cocks
>>38 It's an important problem, but identity only solves it if the user risks something by destroying their identity. Making it easy to sign up for "free identities" kindof defeats this, don't you think?
>>40
Identity is subjective. I'm not sure of the problem you're seeing.