BrowserId and our login process

BrowserId is a temporary (as far as I understand) solution that positions itself on Zooko's triangle [3] the same way as DNS does: by compromising decentralization. There is a centralized domain name (browserid.org) that allows identity providers and identity relying parties to find each other.

As far as I have understood (maybe someone else has a clearer understanding of this), browserid is better than xAuth, because it's not sniffable. xAuth would publish available identities in a public cookie, ready for any website to discover without the user's permission. In BrowserId, only the maintainers of browserid.org get to see your identities, and where you use them. Not any websites you happen to open in your browser.

I'm a bit cautious in proposing we use BrowserId, because of its current centralized nature. See the end-user privacy rights [4]. I think I support it as a temporary solution, but not as a permanent one. As I said, I would love to hear what others think about this.

Now for how it might work if we choose to support BrowserId in our apps:

- Right now, on https://myfavouritesandwich.org you have to manually type in your user address. That step would be replaced by a 'log in with browserid' logo. You would choose your user address from a list on the popup that's served by browserid.org, and then be redirected back. To see how this works, visit http://myfavoritebeer.org/ (American spelling). It seems we have a new trend with "my-favourite-[food]" demo apps! :)

- You have a password for BrowserId.org, or for your own email provider. In any case, you need to confirm ('accept') that you want to give your identity to the current web app.

- After that, the web app knows (for sure) that you are your email address. But the web app has no permission yet to access your unhosted storage. So if it's the first time you use the app, you still have to review the dataScope the app wants access to, and click 'allow' a second time.

- Then, your e2ee password for the app could be linked to your verified email. that's presumably where the password reminder would be sent anyway. the only important thing is that if you're going to use browserid.org as your Verified Email provider, then browserid.org would have access to all your data for all apps. Mind you, right now that is usually true of your email provider anyway. they could put your email address into any website, click 'remember password', intercept the email, and log into your account.

This is better than what we have, because if you're logged into browserid.org (or your email provider supports VerifiedEmailProtocol and you are logged into their webmail), then you don't have to type your user address into each app you visit.

If you are logged in to your VerifiedEmailProtocol provider (which for now will be browserid.org), then the actions to log into an app would be:

- click 'login'

- click 'allow use of this identity'

- click 'allow access to this dataScope'

- that's it. no need to put a password into the storage provider or the app. The only password you use is the one for your VerifiedEmailProvider.

An important question here is how easy it is to become your own VerifiedEmailProtocol provider instead of going through browserid.org. Another important question is if we can expect  browsers to implement VerifiedEmailProtocol at any point, so that we can get rid of browserid.org altogether.

If those two questions can be resolved, then it looks to me like we should probably adopt BrowserId. I think it will become very important to get a way to use non-Google accounts on Android and on ChromiumOS. Google is pushing hard to make sure we're logged into google while we use the web. [5] Many users are currently logged in to Facebook while they use the web. Mozilla seems to be our biggest hope, at this point, for fixing this situation. We need login to move to the browser, and we need this to happen in an open way.

I'm very interested in opinions and/or links to opinions of others about this.

Cheers!

Michiel

[1] https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest

Why not more effort with OpenPGP handling at the Browser ?  (It is already halfway there in browsers with Certificate handling! - Google Chrome / Options / Under the Hood / Manage Certificates )

I mean RFC 4880 is already on the Internet Standards Track.  Certificate Revocation is at the user level, so if a users private key is every compromised, he can revoke it http://en.wikipedia.org/wiki/Pretty_Good_Privacy#Certificates

Why not keep it decentralized and retained with the user ?  The browsers just need to surface HTTPS/SSL/TLS and Certifcate handling a little bit better and issues like this would be resolved from a user perspective.

Thoughts ?

--
-Thad
http://www.freebase.com/view/en/thad_guidry