Comments on: Thoughts on OpenID

By: Tony

Tony — Mon, 05 Mar 2007 08:08:34 +0000

Ah — you’re right regarding certificate authorities — I was misinterpreting what was going on in my browser.

Following on what you said though, could/should it be time then, to consider rules for how an ID provider is operated?

I think the SSL world, they probably instantiated rules since they were dealing with super secure things. Business had a profit motivation to making sure the system could be trusted, and that people would trust it.*

Is this motivation as strong in the ID world? I guess so, otherwise folks like Passport wouldn’t be working on the problem.

*Actually, in some sense, I suppose a debit card number/password pair actually do provide some notion of identity (though different from what you’re talking about, of course).

By: Trevin

Trevin — Sat, 03 Mar 2007 23:25:59 +0000

I don’t see chains of trust that exist in certificates and certificate authorities to address the authentication space as completely as you describe. The only way this would work is that the equivalent of the CA in this case, would have to certify that a given ID provider is legitimate. In the certificate world, there are very well defined guidelines on certificate issuance, handling and revokation that don’t exist in the identity space.

Because of this, it would be fairly meaningless for one ID Provider to indicate the “trust” of another more-well known (and trusted) ID Provider, because the guidelines for why that trust exists would vary wildly across the industry.

If there were well-defined “rules” for how an ID Provider was operated at different levels of security, I agree with you that this could solve many of the issues that exist today in the authentication space.

By: Tony

Tony — Mon, 26 Feb 2007 06:45:49 +0000

I was just thinking about decentralized and tiered authentication, and was reminded by how they addressed (I’m deliberately not using the term “solved”) the certificate authorities problem. The certificates I’m talking about in particular are the certificates used to certify that certain websites are certain websites (e.g. I go to http://bankofamerica.com/, and the little keylock appears, telling me that someone has said “this is definitely bankofamerica.com”). It /looks/* like they do this by: (1) having lots of certificate authorities, (2) having chains of authority (I trust A, so if A trusts B, then I trust B, too), (3) I can elect to trust certain people (via importing, or accepting on the fly), and (4) my browser automagically shipped with people I (should/can) trust.

(1)+(3)+(4) seem to address the decentralized thing, and (2) seems to address the tiered thing.

Did they solve the problem here? From the perspective of the end-user, I think so. The majority of the time, this approach probably works well.

Are there breakdowns? Most certainly: many webpages I visit in the academic environment cannot afford to actually have their certificate authorized by an authority. I can deal with this by “accepting” the certificate (i.e. (3)). There is the possibility of this failing of course (i.e. I trust a bad guy by accident), but the end user probably doesn’t think about this happening or really care — the “do you accept this certificate” dialog box probably seems more like a nuisance (e.g. “Really delete these files?).

You might also run into people having issues with (4): my browser ships with people I (should/can) trust. Practically, this is probably not a problem, but of course, there are people that don’t trust what they are told to do or trust. That said, the certificate thing works most of the time, and I’m pretty sure most people who do their online banking have never even thought about their security.

What’s the point of this comment? I think there are parallels here to the certificate problem (it’s not the same, but there are parallels). I just wanted to point to a parallel approach that we can think about with regard to this particular problem.