The current OpenID delegation model is great. One adds some simple discovery code to one’s homepage and poof! you have an easy to remember OpenID that remains the same even if one changes providers. That’s all great, and I’ve been using it almost since OpenID came out.
But I think we can do even better.
When I’m at home on my own computer I like to use myopenid.com. Among other things, it lets me sign in with a client-side TLS certificate, which is much more secure than a password.
When I’m at school in the labs, I don’t want to install a certificate there. Nor do I want to use a password by itself. Myopenid.com no longer provides the best featureset for what I would like to do, but rather the OpenID-Jabber bridge at http://myid.asemantics.com is likely much closer.
So one solution is to add both OpenIDs to services I use, and then I can use the URL for the one I want, when I want. The problem with this solution is (1) the abstraction is horrible, and all the benefits of delegation go away (2) not all services I use let me associate multiple OpenIDs (I’m looking at you, PostRank).
So how do we solve this?
I would love to add the delegation discovery information for both providers to my homepage. Then, when logging in, the RP gets the list of providers I use, and presents me with a menu asking which one I prefer. Providers not yet upgraded to have this new functionality would just keep using the first one they found, so it degrades quite gracefully.
I’m very interested to see feedback from the community on this idea. Post comments below, or tweet @singpolyma 🙂
3 Responses
Well, having multiple providers listed in your XRDS document is nothing new, but most of the use cases to date have been for failover, in case one provider is down. So listing multiple providers is doable, but how would the RP know which one to send you to? As you’ve suggested, the RP would have to have additional smarts to prompt you. Two other ways to do this come to mind that wouldn’t require changes to the RP:
Use WordPress as your OpenID provider, then authenticate to WordPress using whichever OpenID you want. It’s basically chaining OpenIDs together and works fine. The downside is that it’s only as strong as the weakest link. When using a provider with strong auth like myopenid certificates, WordPress is most certainly the weakest link. But given that you’re delegating from WordPress anyway, it already is.
But what if WordPress knew where you were and could modify your OpenID delegation accordingly? If you were to use some kind of service like Brightkite, even if you kept all your checkins private, WordPress could use OAuth to get those checkins and dynamically changes your delegation. Of course, that puts a burden on you to checkin everywhere you go, but it’s certainly an interesting prospect.
Will’s idea seems much more doable (than providing a list of OpenIDs) — and is just cooler as a programming project. But, instead of using BrightKite (which is a third-party, and hence, unreliable), why not use the latest geolocation stuff slowly coming out? Firefox 3.1 is going to have it by the looks of it, so will Snow Leopard. I don’t know about you Linux folk, but I’m sure something is up your sleeves as well.
But I’m a little confused — why use multiple OpenIDs in the first place? The whole point of OpenID is to have *one* login, right? Doesn’t this kinda beat that purpose blue? If MyOpenID isn’t serving the purpose, just change your provider (instead of having primary, secondary, tertiary and so on…)
[P.S. OpenID-Jabber gateway looks wicked! :)]
well sure, the geo data could come from anywhere… it doesn’t really matter. Could be a third-party that provides it behind the scenes, or it could come from the client at the time of login. The only problem with the latter is that typically in an OpenID flow, you’ve not yet interacted with the OpenID provider at the time the RP is fetching the delegation information. Of course, you could pass the geo data to the RP, which then uses it during discovery, but then you’re talking about changing all kinds of flows, which is what I was trying to avoid.
As for why Stephen wants two OpenID providers… perhaps read the post again? MyOpenID does work great when he’s on his home computer with the client SSL certificate installed. So when at all possible, use the provider that supports that kind of strong authentication. But what about when he’s on a public terminal or on a mobile device? Those either don’t have the certificate installed, or (in the case of the public terminal) there are great security risks in putting your private certificate on the device. In these cases, it might be desirable to use a different provider. Think of OpenID as having *one* identifier, not necessarily *one* login. He is still using the same identifier (singpolyma.net) in both scenarios, he’s just changing which authentication provider is actually used.