Savvy users are not really the problem I’m concerned about, so the two OpenID providers you mention are probably OK (i.e., Verisign and Shannon Whitley, Identity Provider). There is one particular problem with providers if they use an ID that is non-permanent. For example, if provider example.com issues my an ID like ‘https://openid.example.com/rwandering and I later cancel my account, another user may get that same ID in the future. That means the new rwandering has access to those accounts where I used the ID. I hope Versign isn’t doing that, but I don’t know. Users who are their own providers ought to be sure that they never let their domains expire. This specific problem is resolved by using i-names as long as services correctly use the underlying i-number for logon identification.

I am more concerned about the difficulties for services that want to rely on OpenID (i.e., Relying Parties). How do you, Shannon Whitley, developer of many services, distinguish between a Verisign (which presumably you trust) and “Joe’s OpenIDs” which might just be a self-hosted Provider to facilitate spam and meddlesome bots?

I’m thinking of putting together “Robert’s Most Excellent Identity Provider Provider” which just enumerates (and serves) trust levels for Identity Providers. Maybe you can write that (but you have to use the name I came up with)

I hope this helps,
Robert

Thanks for doing so much research. I’d love to dive into all of this myself, having used OpenIDs for quite awhile.

Let’s say I’m using a “trusted” provider like Verisign. Is it reasonable to assume that everything is perfectly “okay?”

If I’m understanding correctly (and I’m not sure that I am), what you’re saying is that “untrusted” providers, like “Joe’s OpenIDs” could lure unsuspecting users in and cause harm. Am I missing anything? I mainly want to make sure that I’m not leaving myself open for issues if I am using somebody like Verisign (or my own server).

ak

Thanks for your comment. I am a little surprised that you agree with me.

I am concerned that the “Demand OpenID” push is raising demand for OpenIDs without raising awareness about these critical issues. Unfortunately, users are getting the idea that OpenIDs include built-in trust. I don’t tihnk JanRain is telling users this, but I do think that the overall OpenID message and value proposition for users and services should have been worked out before “Demand OpenID”. And since a JanRain employee came up with “Demand OpenID”, it appears that JanRain as a company does think that OpenID is ready for “primetime”.

Of course, maybe this just comes down to a definition of “primetime”. I never meant “mass use”, but general use outside of hardcore techies. The trust issue seems to me to be too big. And too big to wait for the market to work that out.

The bigger issue isn’t that users think OpenIDs confer trust, but that services can’t tell if they can trust an OpenID. The “OpenID provider trust” call should exist today.

I’ve thought of writing my own community-based service. I hope you guys are close to having something like that done.

Cheers,
Robert

OpenID is the protocol, then, for expressing the request for authentication from a provider and the results of that request. Web sites that consume OpenIDs must decide on their own which providers they want to trust, and why. You’re quite right that this is an emerging problem, and it’s an area that the company I work for (JanRain) sees an opportunity space to provide a useful service to these sites. As the marketplace develops, web sites will be able to make “OpenID provider trust” a service call they can make as well. When an OpenID is presented, if the OpenID provider is not known, a trusted service can be use to ask “Who is this provider? Do they follow the authentication policies I require?” In that way, websites can offload the complexity of vetting new providers by asking a trusted service that manages a database of providers and their attributes and policies.

This will be one of the developments that gets OpenID ready for “primetime”, I agree.