The buzz around OpenID is becoming impossible to ignore. If you don’t know why, check out How To Use OpenID, a screencast by Simon Willison. As it’s used now (unless I’m missing something) OpenID seems pretty useless, but with only a little work (unless I’m missing something) it could be very useful indeed.

Problem: TLS · The first problem is that OpenID doesn’t require the use of TLS (what’s behind URIs that begin with https:). Doing anything remotely connected with authentication over an unencrypted link where you can’t be sure who you’re talking to seems all wrong to me. I see that this subject is under discussion (here and here) in the community.

The fact that apparently-sane people think it might sometimes be OK to not use TLS makes me think there’s something obvious I’m missing. In Simon’s screencast, the pages that you type your OpenID into are unsecured; hmmm.

Problem: What’s It Mean? · Another problem with OpenID is that, well, having one doesn’t mean very much; just that you can verify that some server somewhere says it believes that the person operating the browser owns that ID.

Unless I’m missing something, as a thought experiment I could set up a bogus OpenID server at, and arrange that when queried about any OpenID whatsoever beginning with that URI, it instantly provided a positive response. For example, or None of that nasty time-consuming authentication stuff; sure would speed up logging into OpenID-supporting sites.

Problem: Phishing · This is going to be a problem, but I don’t think it’s fair to hang it on OpenID, because it’s going to be equally a problem with any browser-based authentication. Since browser-based authentication is What The People Want, we’re just going to have to fight through this with a combination of browser engineering and (more important) educating the general public.

What Could I Use It For Today? · Here’s what I think I’d be willing to do: in the commenting system here at ongoing, I’d be inclined, if I had manually approved a comment with someone who’d authenticated via OpenID, to subsequently accept further comments from that OpenID, unmoderated.

I can’t think of anything else.

Solution: TLS · Just Do It. Create a culture where traffic is simply expected to be encrypted and secure for each step in the authentication chain. If there’s anything in the protocol that makes this hard, fix it. Yes, anyone offering authentication services will have to own and manage a cert. That is the entry-level price for me taking you seriously.

Solution: Meaning Something · I haven’t actually heard anyone argue that all OpenIDs should be considered equal to all others, which is good, because that would be a profoundly silly idea.

For some given application, I might be willing to support LiveJournal OpenIDs but not those from MyOpenID; or vice versa. There might be an opportunity for some sort of independent-security-audit business, rating quality of OpenID providers. Bruce Schneier, where are you?

Once again, maybe I’m missing something, but it seems obvious that if OpenID is ever going to be much use for real work in applications that matters, there are going to be whitelists of ID Providers. Does anyone see this as a problem? If not, all the libraries out there Ruby and Python and PHP and so on need to have the provider-whitelist feature built in.

The Real Problem · Of course, out there in the enterprise space where most of Sun’s customers live, they think about identity problems at an entirely different level. Single-sign-on seems like a little and not terribly interesting piece of the problem. They lose sleep at night over “Attribute Exchange”; once you have an identity, who is allowed to hold what pieces of information about you, and what are the right protocols by which they may be requested, authorized, and delivered? The technology is tough, but the policy issues are mind-boggling.

So at the moment I suspect that OpenID isn’t that interesting to those people. But Web-heads like me care about Plain Old Single Sign-on, and we like identifying ourselves by URI. So OpenID might scratch a pretty big itch.

Unless I’m missing something. The reason I keep saying that is that I really am an Identity newbie. I’m sure my commenters will be diligent in pointing out where I’ve gone off the rails.


Comment feed for ongoing:Comments feed

From: Rowan Nairn (Feb 24 2007, at 22:48)

You are missing something (at least on the "meaning" question). An OpenID is a global, unique username that cannot be used by other people if you don't want them to. It's also a single method of signing on to sites that support it. The main benefit is not to the site, but to the user: no need to go through that identity dance for every new site, no username to choose, no new password to choose, no new password to remember.

As you mention, you can now set up a white-list without requiring the user to choose credentials specific to your blog. For web apps that personalize more than a blog the implications are more profound.

Your hypothetical silly-id server is the OpenID equivalent of BugMeNot, which can be used eg for accessing NYT content - when you just want to get quick access to a site and don't mind being identified as someone else.


From: Stuart Langridge (Feb 24 2007, at 23:29)

You're broadly correct on the points you mention, but I'd suggest that not all of them are as critical as you might think.

"What’s It Mean": yes, you can indeed set up an auth-anybody OpenID server, and someone's already done so if I remember correctly. This means that if Alice decides to use as her OpenID then there's nothing stopping Bob using it too. So the answer here is: Alice, don't use that. You have to trust your OpenID provider, certainly, and one way of doing that is to run your own rather than delegating it to somewhere else like myopenid or idproxy or The fact that it's possible to have such a provider isn't, to my mind, a problem; I can set up a bank where I don't bother to check your ID before I let you withdraw money from an account too if I want to, can I not?

TLS: hm, sorta kinda. My issue there is: people don't read certificates, generally. Some people do, certainly, but not most, otherwise every web shop that have do all their SSL stuff wouldn't do any business. People should look at the certificate on that site and say: hey, I'm trying to buy something from Widgets, Inc and this certificate is signed by Cheap SSL Servers For U, Inc, and I'm therefore not going to buy this product. And they do not do so, to a first approximation. This isn't particularly an argument against OpenID's use of TLS, of course; it's an argument against TLS generally. Without people checking the certificates, TLS gives you security on the wire but doesn't give you identification of the endpoint as what you think it is, and that's precisely what you're suggesting TLS is needed for in the OpenID process. So I'm not clear in reality that it'd buy anything to use it.

"What Could I Use It For Today": one of the best uses is for sites which already have an account signup process; instead of having to fill in *another* form with a username and a password and the password again and a real name and a location and an avatar, just fill in your OpenID and then the server creates an account tied to it, so all you need do is use your OpenID. It looks like single-sign-on to the punters, even though you've actually got separate accounts everywhere, and that's what counts.

"Meaning Something": I'm not sure why you think you'd want to blacklist or whitelist providers. Say you use it for comments here at ongoing: what do you care if someone's using as their OpenID? That's their choice, no? There's a separate and parallel education thing that needs to go on about "how to choose an OpenID", but that's at least starting to go on right now. You don't, currently, stop me putting "Bill Gates" and "" into the fields for this comment.

Agreed entirely on the points about attribute exchange. OpenID isn't really meant to be the One True Solution To All Identity Problems. I do have something of a fear that if it takes off then people will try and trick it up into such a solution, though, which will be a problem and needs to be watched for. But it'd make a pretty high proportion of all the signup forms currently on the web go away, and that's a valid and valiant goal in itself.


From: Colin Jeanne (Feb 24 2007, at 23:36)

It is true that you could create an OpenID server to authenticate but the problem with that is that you will need to convince others that Bill Gates actually uses that as his OpenID. If it is common knowledge that he uses as his OpenID then no one is going to believe that is actually Bill Gates.

In a similar vein, somebody could easily start using Bill Gates as an AIM screen name or as an email address and then try to use it to impersonate him but that doesnt seem to occur too often.


From: Robert MacCloy (Feb 25 2007, at 00:13)

'Here’s what I think I’d be willing to do: in the commenting system here at ongoing, I’d be inclined, if I had manually approved a comment with someone who’d authenticated via OpenID, to subsequently accept further comments from that OpenID, unmoderated.'

I could be wrong, but I recall Brad Fitzpatrick saying that's /exactly/ the usecase for OpenID. It's not supposed to be a web of trust or anything, but maybe a layer to build one on top of.


From: beza1e1 (Feb 25 2007, at 00:39)

To the meaning and the phishing problem: OpenID is about identity, not about trust. Identity has to be there before trust.

And i don't think whitelisting should be the default (and be in the libraries) for the same reasons we don't do it with email.


From: Paul Downey (Feb 25 2007, at 02:11)

I think OpenID will evolve to something more secure, TLS is one obvious requirement. I worry about how dependent on DNS we have bcome, so adding certificates or tokens is another step, I'd guess - see - but the infrastructure isn't really there, yet.

Your use-case of allowing commenters to return is all that OpenID does for you. But at least it's a step in the right direction. I've been allowing OpenID's on my blog for a while now, and a lot of people use it in preference to "Your Name", "Your Email", "Your Blog". But I'd be happy to use my OpenID most anywhere I'm asked for a user/password. Sites can still ask for further authentication, like my bank's site which demands "letters 2 and 5 from your magic word".

Identity does not imply reputation or trust, that's value a separate provider can add, and could become an interesting new business, like banking, one which would benefit from regulation. I guess that's where you are going with whitelists?

One thing I'd really like to see from OpenID is more support to use it within a client other than a browser. That seems to be missing AFAICT.


From: Benja Fallenstein (Feb 25 2007, at 03:09)

It seems obvious to me that, unless I'm missing something, the point of OpenID is to solve the situation where the *client* wants to be the only one who can access a particular account, not where the *server* wants to know something about the client.

Sure, if you want to be sure that the person behind an account is a certain person, or even a real person at all, OpenID does very little for you. But if you want to be sure that nobody else can read your private messages on a message board system -- not even the admins of the 500 other sites where you've been using the same password -- OpenID may be just right for you. Same if I want to be the only one who can post as

It seems to me that it hits a sweet point. To ask it to also provide assurances about who the user is smacks of Solving the Whole Problem to me.


From: Jacek (Feb 25 2007, at 04:27)

There is a clear difference between and Computer doesn't see it, but OpenID is for authentication, not directly for authorization. On a blogging system, if you moderate by default, whitelisting known OpenIDs is your authorization decision. Whitelisting OpenIDs from, LiveJournal is also an authorization decision. The OpenID gives you identity.

I see the power of OpenID in that if I'm setting up an account somewhere (eBay, gmail, amazon etc.) I should be able to provide my OpenID as my identifier, then the system would not keep a username and password for me, instead it would know that I authorize that OpenID to work with my account there. It's my responsibility to ascertain that it cannot be hacked/spoofed etc, but that's the same degree of responsibility as keeping my password secret.

Of course, when setting up an account, an identifier and password are seldom the only necessary pieces of info, and OpenID only replaces those.


From: Morten Frederiksen (Feb 25 2007, at 04:58)

As for the "What Could I Use It For Today?" part: You're right on the money.

OpenID isn't about trust, it's about identity assurance. Once you add trust, you get something that's actually useful. In the example, you add the trust by approving the first comment. OpenID supplies the identity assurance part for the subsequent comments.

That combination seems like a pretty big step forward.


From: Darren Chamberlain (Feb 25 2007, at 05:04)

You should take a look at []. They attempt to solve some of the problems that you're describing by issuing client-side SSL certs, and then acting as an OpenID server. When you use your prooveme identity, prooveme authenticates you based on the SSL cert it has issued to you. (Or more correctly, it authenticates your browser.) This doesn't address the trust or why issues you raise, of course.


From: Janne (Feb 25 2007, at 05:14)

Who is going to decide what servers end up on the whitelist? Who decides when to remove an entry? Where is the whitelist fetched from?

How can you make a reasonable assumption on the whitelist being managed in a fair and unbiased manner, updated in a timely fashion, be available when you need it, and be sure the whitelist you've just fetched really is the original, not one that has been tampered with? How, in short, do you make sure you've not just created a single point of failure, a one-stop shop for security breeches?


From: Kragen Sitaker (Feb 25 2007, at 05:27)

I think your use case is pretty much correct. An OpenID is just like a password --- it's a way of authenticating that you're talking to the same person twice.

There is one difference, though: an OpenID doesn't have to be secret. So, for example, you could browse through a dozen of your friends' homepages and, if they already have OpenID, add them as authorized commenters even before they had commented.

Here are a couple of other use cases that are variants of yours:

- you want somebody to read over a blog post before it goes public. You grant their OpenID read access to the blog post and send them email.

- you want to schedule a meeting on a day when everyone is available. You set up a dumb little CGI script to ask people when they're available, email them, and use their OpenIDs to authenticate their accesses to the CGI script.

- you want to poll your friends about your new hairdo, but you want to make sure they can only vote once. This is the same case as the scheduling app.


From: Simon Willison (Feb 25 2007, at 05:48)

On the TLS thing: I am by no means an expert on encryption, but the OpenID protocol has a bunch of encryption stuff built in to it (based on Diffie Hellmann shared secrets) that should work fine over regular HTTP - they've thought long and hard about this. As for logging in to your OpenID provider itself, OpenID deliberately avoids specifying how authentication should be carried out. Sites can use usernames and passwords, or usernames and passwords over HTTPS, or things like client-side certificates, browser extensions, SecurID fobs and so on.

I addressed some of the things you can do with OpenID in my recent talk at the Future of Web Apps conference:

I'm going to be writing up some of those ideas in more detail today.


From: Chris Johnson (Feb 25 2007, at 07:01)

As others have said, OpenID just gives us a way to talk about users. What we do with that is a separate issue.

Here's something more you could do with OpenID today:

Every Livejournal user has a FOAF profile which encodes, among other things, their Livejournal friends list. So, if you wanted whenever you manually approved a comment from a Livejournal OpenID, you could approve all the comments of the OpenIDs they listed as 'friends'. Or greylist those comments in some way or the like.

Right now that's a site-specific thing, but in time as we get standards for profile exchange, you could more generally build a web of trust. This guy's not a spammer, so the people he trusts probably aren't either.

But before we get any of that, we need to be able to talk about people. That's OpenID.


From: Mark (Feb 25 2007, at 07:05) is a one-user OpenID server that I can install on my blog's web server. It uses HTTP digest authentication.

Simon wrote an OpenID server proxy that uses Yahoo's browser-based authentication API, which is worth your time to read about.


From: Simon Willison (Feb 25 2007, at 08:21)

Here's a write-up of the ideas from my presentation:


From: Brian Fitzgerald (Feb 25 2007, at 09:49)

beza1e1 (Feb 25 2007, at 00:39) wrote in the comments to this post:

>To the meaning and the phishing problem: OpenID is about

> identity, not about trust. Identity has to be there before\

> trust.

Ahhhh yes! Way to go beza1e1 !!! You nailed it and guess what? The guys at the good ol' committee known as the W3C *forgot* to put Identity on the top of Trust on the W3C Semantic Web Layer Cake. Can Tim Berners-Lee say "oopsie daisy"?


From: John Ward (Feb 25 2007, at 09:50)

Although OpenID solves the SSO piece, it is missing the identity assurance/assertion piece. Thats the process by which an individuals proves their real identity when obtaining a digital identity. Getting an SSL certificate requires the applier to go through certain verification checks etc...

I see that Verisign are working with OpenID, it will be interesting to see if they merge their verification process into OpenID to ensure strong identity internet wide.


From: Brian Slesinsky (Feb 25 2007, at 23:32)

I started to write a comment here but it turned into a full-blown essay:

Should we support OpenID?


From: Paul Doerwald (Feb 26 2007, at 03:24)

I've been fascinated by this whole OpenID thing. The commenter above me, John Ward, hits it when he says that OpenID is a SSO solution. That's all it is, which is really too bad. OpenID, the way it's been envisioned so far is ill-equipped to handle identity. I suspect that into the future providers will try to add features on top of an OpenID implementation just as Simon Willison has done with where he added phishing controls by showing a picture of a monster customized to the individual.

I also worry that OpenID is a bit non-intuitive for non-technical users. Being passed back-and-forth from server to server is a bit jarring, especially when the different systems look so unfamiliar.

I am optimistic that OpenID can overcome these limitations, but I worry that it's going to happen in a very fragmented way. People will have to choose an OpenID provider that helps prevent phishing, rather than being able to assume that all providers will have this level of support.


From: Preston L. Bannister (Feb 26 2007, at 09:05)

As prior comments have noted, identity and trust are distinct concerns. You have one identity (or at least should), but the sort of trust granted you is going to be unique for each application. It does make a great deal of sense to separate identity from trust.

Phishing is the main failing of OpenID as presently defined. As long as the OpenID login is presented *after* the random-new-site login, your average user is going to fall for phishing attacks. Maybe this could be made better with some form of browser integration, but I doubt this can be near enough to foolproof.


From: Michael Dickey (Feb 26 2007, at 09:47)

"The Real Problem:" The OpenID people are working on an "Attribute Exchange extension (see This problem isn't only applicable to enterprises. For example, there are many sites I have accounts with that only know me by username (or email) and password (I know it's bad, but like most people, I use the same password for all these "who cares if someone steals my identity" sites). Other sites I may also allow to know my "web address," telephone number or mailing address. For sites that currently use email to validate my existence, I would greatly prefer that this also be an attribute I can choose to provide them with (or not).

OpenID allows us to have an online identity as a URI, and gives individuals more control over their privacy. You can choose to be mostly anonymous. You can choose who has your email address and other personal information. You can choose who knows what your favorite color is or your mother's maiden name. These attributes can layer on top of a polymorphic URI which points to different personas.

The extent to which your online identity relates to your real identity is adjustable, without loosing the benefits of having a common identifier. Should you choose to link the two together, you can. For example, by adding an attribute for your public key or client certificate. Decoupling these allows the individual to choose what to do.


From: Pat (Feb 26 2007, at 10:30)

Re Simon Willison's "On the TLS thing: I am by no means an expert on encryption, but the OpenID protocol has a bunch of encryption stuff built in to it (based on Diffie Hellmann shared secrets) that should work fine over regular HTTP[...]"

The issue here is that you know you made a secure assocation via DH with someone addressable at that URL, but, without TLS, you're not really certain who. There are no shortage of attacks on DNS: cache poisoning, tampering with the client's host file and, the latest, hacking the broadband router to point the user's DNS client at a rogue server.

The broader issue is that you need some trust root - some information exchanged out-of-band that you can rely on. For TLS, these are the root CA certs. Yes, we can debate about certificate issuance practice and users accepting certs that don't match the URL, but at least there is a cryptographic basis for trust. In any case, the RP can be much more picky about the certs it accepts when doing TLS with the OP (match URLs, control the root CA list etc). You could even have whitelists that contain secrets exchanged offline - no TLS required, but still an offline step of (securely) getting some credential from the OP to the RP.

Without any of this this, I don't think it's possible for an RP to have enough confidence that is the same user that presented that URL last time to rely on OpenID in its current form for anything more than blog comments.

[Tim - can we have some markup in comments, please? It would have been nice to have some bold or italic in that...]


From: Michael Dickey (Feb 26 2007, at 10:41)

I'm sure someone will pick this up since I wasn't clear: adding a client certificate as an attribute certainly does not in itself verify someone's identity (these are public). The site would have to take an additional step to do that, such as checking the certificate with an Authority (Verisign or a corporate one) and requiring the client to establish an SSL/TLS connection using the certificate as credentials. Perhaps this would be a good extension, but it is not appropriate for the base protocol. The method would likely vary depending on what you were trying to verify (human or bot? employee? customer?), and it is unnecessary for most use cases.


From: Nic Ferrier (Feb 26 2007, at 11:18)

Fair points all. (which I'm responsible for) is already doing OpenID authentication using client certificates. I think there's an opportunity to make SSL/TLS much more understood by the average user. We're looking to do browser extensions that make owning and managing client certificates much easier.

We're also looking to degrade to less bullet proof methods of security when our client want us to.

We've also considered your point about whether all OpenID providers are equal. It seems to me that there might be a whole lot of good ways of getting secure OpenID other than what we're doing. But some OpenID consumers might want to request that their users login with a totally secure option. An OpenID provider based on SecurID cards would be popular with banks I'd have thought.


From: Jason Shao (Feb 27 2007, at 14:24)

No trackbacks?

While it's true that OpenID doesn't really deal with attribute exchange (and usage, etc -- yet) I think what it really does is standardize a user-controlled request process. So... just like restful proponents seek to standardize the semantics of acquiring resources and interacting with them, OpenID provides a simple, standard authentication channel. An application could be locally configured to only accept OpenIDs from certain IdPs (e.g. a University's OpenID server, federated partners, AOL) or have some kind of assurance checking mechanism, but that's *optional*. Whereas, for the common internet case of just wanting a persistent handle so people can come back to the same account again (low assurance).

In terms of attribute release - just like DRM, I have yet to really see a workable attribute usage and release scheme that doesn't require you to trust recieving parties anyway. And the OpenID approach of having the user approve the IdP's release of particular attributes seems just as reasonable (and much more scalable) than an institution trying to build a policy with tiers or permissions as to who can get data. Requiring user release seems to solve lots of problems, actually.


From: Richard M. Conlan (Feb 28 2007, at 00:38)

OpenID in its current form is workable, but not what I would want in an identity standard. I seriously hope OpenID 2.0 fixes the glaring shortcomings in the current standard.

In response to the entry and some of its comments:

OpenID requires TLS for authentication, and to protect the initial OpenID Consumer request (see below). OpenID phishing is definitely a concern because of the user behavior it encourages (an interesting essay: (and see below). OpenID will only work reliably if OpenID Consumers employ whitelists (also below).

"You are missing something (at least on the "meaning" question). An OpenID is a global, unique username that cannot be used by other people if you don't want them to. It's also a single method of signing on to sites that support it. The main benefit is not to the site, but to the user: no need to go through that identity dance for every new site, no username to choose, no new password to choose, no new password to remember."

This makes certain assumptions about the OpenID Consumer. A lot of the responses here seem to miss this critical point (I chose the quote above because it was the first such response). There are two separate concerns:

1. OpenID Provider

It is important that the user choose a good OpenID Provider. This is definitely true. The very best providers might even employee smart cards and the like, but most will not. For the average provider, we can assume that username and password is still the norm.

This is part of where the phishing concern comes in. The problem is that for years we've been telling users, say, that when you want to log into your bank's website you have to make sure it is valid by looking at the URL. OpenID breaks this, because you'll always be getting redirected to the same place for any site. Now, if your OpenID Provider isn't one of the snazzy smart card places you have all the traditional phishing problems, but in this case the user learns it it common to be redirected off the site you're on to some other site on which you validate your identity. This is something of a problem, because it might be bad for OpenID, and it hurts general user behavior outside the immediate vicinity of OpenID.

2. OpenID Consumer

If your Consumer doesn't have a whitelist then you might be screwed.

If your Consumer does not have HTTPS then it doesn't matter who your Provider is because an attacker between your and the Consumer can fiddle with your identity submission and change the server. If the Consumer is restricted to a whitelist of good HTTPS-protected servers and the attacker cannot get on that list or hack those servers, you might be okay; elsewise you're screwed (see below). If you have a HTTPS Consumer you're looking much better because an attacker cannot trivially fiddle with your submission. In this case we have to hope that your Provider is HTTPS, or else the Consumer could be fooled by anybody between the Consumer and Provider into interacting with a bad Provider. If both Consumer and Provider have HTTPS we're looking much better, as long as the user doesn't get phished.

"I am by no means an expert on encryption, but the OpenID protocol has a bunch of encryption stuff built in to it (based on Diffie Hellmann shared secrets) that should work fine over regular HTTP..."

This is incorrect. As far as I can tell the Diffie-Hellmen is used between servers. However:

1. DH does not provide authentication, so the OpenID Consumer has no idea who it is talking to if TLS isn't included.

2. The initial step of the OpenID protocol is a message to the OpenID Consumer. If the OpenID Consumer is not HTTPS protected then this goes in the clear.

This means that because of 2 an attacker can change the URL of the OpenID Provider you submit, and because of 1 there is no validation of that Provider.


Responses to Brian Slesinsky's blog entry:

"We hope our friends choose good email providers and their email accounts don't get hacked, but it's really up to them to practice good security. Similarly, it will be up to our friends to pick good OpenID providers."

Picking a good OpenID Provider is probably hard. That aside, your friends also have to book good OpenID Consumers who practice due diligence in establishing their accepted Providers. People don't do a good job at assessing risk or picking a good anything - I'd assume most people will use whatever Providers are cheapest.

"Requiring https to post is sort of like refusing to accept your friends' email unless they use PGP."

I think requiring HTTPS in this case is marginally more important. It might be like requiring PGP on e-mail validations...but I'd totally consider that a good thing for any standard hoping for wide adoption to require.

"You can still create throwaway OpenID's, just as it's possible to create throwaway email addresses."

If it were to become an identity standard I would be concerned of laws coming into effect trying to curtail this. Similar legislation sometimes surfaces concerning e-mail addresses.


From: Jonas Bofjall (Feb 28 2007, at 13:20)

There are some basic issues with OpenID I'd like to know more about before jumping on this particular hype:

1. Why does it seem to take off with blog comments? Validating an unknown user is pretty pointless to me. Whereever you let someone in just because they have an OpenID identify there is going to be a spam problem.

2. We have silos in the web today because companies just LOVE to own information about their users. The simplest use cases of OpenID is where you today provide your email address (which already is a globally unique identifier, nicer than a URL). Companies love them as they get to file them away for later use. Why should they accept OpenID instead?

3. I'd like to propose a much simpler web ID and SSO standard: You use an unsigned client SSL key, and your identity is the URL to where you have your public key stored. Voilà, works out of the box with today's tech. It's even easy to revoke keys, just upload a new one.


From: Henry Story (Feb 28 2007, at 14:27)

OpenId is simple to understand and looks easy to implement. It certainly helps solve a serious pain point. I can't remember how many accounts I have online with silly passwords, nor how much time I waste trying to remember which silly password I used. It would be nice to add this to as I argue in my recent blog, where I try to summarize all I learn here. I have been made aware of an interesting blog that compares SAML and openid. Still a lot to learn...


From: Evan Prodromou (Mar 01 2007, at 05:57)

I think the problems with phishing are going to correct themselves. The first generation of OpenID providers use password authentication, which is bad, but a browser-certs-based ID Provider like can work well within the current OpenID framework.

I use for my main OpenID delegate (well, I started the project, so I should), and I find it considerably faster and easier to use than password-based systems. There's some more setup on the front end, but I think the long-term user experience is better.

Not to mention that I finally get a chance to use my browser cert for Internet authentication. I've had one for years, and I've never found a public site that supports them. Even my bank and my credit card accept only credit-card authentication.

Also, OpenID 2.0 has an extension for requesting more information on the authentication method ( ). I think as that comes on-line, it's going to favor certs-based authentication over passwords, especially for financial transactions.

Here's my prediction: the ease-of-use of first-generation OpenID providers will be the entryway for more sophisticated and more secure authentication systems, like And certs-based authentication with OpenID will make certs more useful for the average user -- probably increasing the use of S/MIME and other certs-based authentication in other protocols.


From: Robin Wilton (Mar 07 2007, at 02:27)

Really interesting thread.

Just a tangential response to a small part of Stuart Langridge's original comment. Stuart said:

"I can set up a bank where I don't bother to check your ID before I let you withdraw money from an account too if I want to, can I not?"

Actually, probably not. If you did that you would almost certainly fall foul of your local Anti Money-Laundering (AML) legislation, which is likely to include strict "Know Your Customer" (KYC) rules about establishing the identity of account-holders before giving them access to banking services.


author · Dad · software · colophon · rights
picture of the day
February 24, 2007
· Technology (77 fragments)
· · Identity (41 more)

By .

I am an employee
of, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.