Fred StutzmanThoughts about information, social networks, and privacy

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).

1. 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:
   1. 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.
   2. Usability problem: I would have to register both my main IP-based URL and my delegate URL to the site.
   3. 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.
2. 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:
   1. Third-party delegate IdP becomes primary OpenID for out-of-browser authentication.
   2. I carry around a copy of my Firefox at all times with me.
   3. 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).
3. 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.

I don’t exactly remember who came up with the idea, but in conversations with Chris Messina, Josh Peek and Brian Ellin, we stumbled across the idea of OpenID-enabling Firefox. I see a couple places where Firefox could implement OpenID.

• Password management can be done via OpenID. Currently, Firefox stores its master password on your system. It makes a lot of sense to allow this master password to be an OpenID. As it stands, your browser owns your identity – it makes a lot of sense to then tie your browser to your OpenID. What’s more, as the password is not stored locally, it is inherently more secure.
• Firefox could implement an OpenID-management. For example, if you verify your OpenID’s to Firefox, it would be able to let you select the identity credentials you want to present to a website. Whats more, Firefox could leverage this knowledge to let you create user-centric identity profiles that you control (as everything is tied back to your openid).

In thinking about how to drive OpenID adoption, it really make sense to go after the browser. We must think of our browser as we think of anything else on the net – your browser is a living record of your identity, and that information is extremely valuable.

As the OpenID community is offering 5,000 dollars to projects that implement OpenID, I’d really love to see Firefox take the initiative.