The more I read these “problem with OpenID” posts, the more I realize the solution is to turn the browser into an IdP. Making the browser the IdP mostly solves the problem of phishing, it completely solves the problem of an offline IdP, and is much more user-centric (I control my data at the very granular host level).
However, thinking through the browser as IdP brings up problems. Maybe you have input. Some problems (and potential solutions).
- Non-static IP address. Ok, my computer spends 80% of its time at one IP address, but the other 20% of the time I could be anywhere. This means my OpenID is different from time to time. Solutions:
- I log in directly with my browser-based IdP 80% of the time, and dynamically delegate[1] via a third-part 20% of the time.
- Usability problem: I would have to register both my main IP-based URL and my delegate URL to the site.
- Solution: Perhaps I could auto-register them both at login? Or perhaps I delegate 100% of the time? 100% delegation would still allow user-centricity, but it would not solve the “IdP offline” problem.
- Not at my browser all the time. Ok, so if my IdP is in the browser, what happens when I’m away from my browser? For me, I spend 97% of time in one browser I control, but this is not the case for all of us. Solutions:
- Third-party delegate IdP becomes primary OpenID for out-of-browser authentication.
- I carry around a copy of my Firefox at all times with me.
- Of course, solution 1 reintroduces the problem of phishing, and I’d have to store a password at my third party IdP (though that makes sense).
- Ugly OpenID. Yeah, it is probably better to be http://claimid.com/fred than http://152.2.210.81/fred, but most sites are going to mask the OpenID anyway by asking you to create a user account. And since the OpenID management is in the browser, it will easily autofill for you so you’d never really need to know your OpenID (though you would need to know your delegate OpenID).
So it strikes me that OpenID in the browser solves some of critical components of the OpenID “problem”, some of the time. Alone, it is optimal, but in reality we have dynamic IP’s and use different computers. It seems like it would fit 80% of use cases, though you’d have to delegate to have fault-tolerant browser-based OpenID. Of course, what about Cardspace – the design assumptions there seem to be that you’re at your trusted computer at all times – so maybe the bar isn’t being held that high.
I guess we can get caught up in the discussion of “Well, if you’re going to delegate, why bother”, which I think is a red herring. The problem here is really data and who controls it. When the data is in the borwser, you really, truly control your data. Your delegate is just a redirect in the either – we might think of it as a public service or something like a DOI.
This is fodder for an interesting discussion, but if you have any input I’d be interested to hear it. What do we lose by making the browser an IdP? Nothing – as far as I can see it is only a win.
[1] Dynamic delegation is the notion of a service that updates its delegation address based on where you are. For example, if you change IP addresses, the dynamic delegation service would simple update to point traffic to your new location.
Hello:
I’ve been reading your blog for quite some time and enjoy your work. I’d be interested to see your comments on this project; there is still alot to learn in this exciting field.
How Should Universities Utilize Social Networking Tools to Promote Civic Engagement?
http://inanafricanminute.blogspot.com/2007/03/how-should-universities-utilize-social.html
josh
The problems with having an OP on the client are dealing with discovery and association.
Both require inbound connections from the RP, which can be a pain in the ass when the OP is behind NAT.