[groks]

I don't think you've actually implemented the protocol. Like most of the other examples I've looked at, you explicitly check every login attempt with the hard-coded mozilla verifier. This breaks two of the selling features of browserid:

1) Your identity provider doesn't know where/when you login because the relying party (the website) is supposed to cache the identity providers public key.

2) When identity providers start implementing browserid, it's not going to make any difference because you're not checking back with the identity providers website, as encoded in the assertion.

What you've implemented here is more like Microsoft Passport - a single point of failure through which all logins flow.

So, as a bootstrap mechanism the Persona service fails, because assuming people jump on the browserid bandwagon, we'll still be stuck using Persona because all the websites have implemented the protocol wrong (as in this case).

[sergiotapia]

You're correct. This is _not_ a persona provider. It would be more correct to call it "Here's how you can use Persona in an MVC3 application."

---

>So, as a bootstrap mechanism the Persona service fails, because assuming people jump on the browserid bandwagon, we'll still be stuck using Persona because all the websites have implemented the protocol wrong (as in this case).

Please elaborate here. You can just switch out the provider (in my case Mozilla) for another one easy enough. You're not tied down to a particular implementation.

[groks]

That's right, you're not a 'provider', you're a 'relying party' - but you are unconditionally relying on the bootstrap mozilla service. You're not supposed to swap that out and rely on some other service, you're supposed to look at the assertion provided by the browser (or the javascript shim right now, while we bootstrap). Who you verify the assertion with depends on the user's email address.

So, if tomorrow Google added support for browserid to Gmail, and [e-mail] tries to log in to your website, he would claim to be [e-mail] and pass you an assertion to that effect. You need to check that with Gmail. Of course, Gmail being popular you've probably already checked the assertion of many people claiming to have Gmail logins, so you already have the Gmail key cached, and can verify the assertion without any http requests to anywhere.

Right now, Gmail does NOT implement browserid, so the assertion which you receive will be that [e-mail] is vouched for by the mozilla browserid service, so you will end up checking the URL you've hard coded.

But if it's hard coded we can't proceed to the next stage, which is the distributed promise of browserid. AND, it puts lets less pressure on the likes of Gmail to implement browserid because no one will be checking gmail.com/.well-known/browserid.

[seanmonstar]

Actually, the the verifier (verifier.login.persona.org) runs code that could be run on any server. It _does_ check Gmail for the well-known file first, and then, since not found, uses the fallback of login.persona.org.

As soon as Gmail (or any id provider) implements a well-known file, the verifier will immediately use that instead.

And the script that does all this _could_ be run on your own server. The only reason we don't quite yet tell people to do that is to be absolutely sure the verifier is correct in every step. It's harder to get everyone to upgrade their own server, so while in beta, we offer the verifier.

[groks]

I think this is a bad idea:

You are using marketing terms like "Persona is distributed. Today" (last weeks blog title) but it isn't, because every auth request flows through mozilla servers. You are also advertising that it is so simple, the entire website example is 70 lines of python (recent talk), but it isn't, because you aren't implementing browserid, you're delegating to the centralised mozilla server.

Advertising that it is distributed and simple does not accurately communicate the current state of the implementation. Look at the spec:

https://github.com/mozilla/id-specs/blob/prod/browserid/inde...

> This assertion is a Backed Identity Assertion, as defined above. We call it assertion here for simplicity, since the Relying Party typically need only pass this assertion to a verifier service without worrying about the specific semantics of the assertion string.

It does not say that the centralised mozilla verifier is temporary, but expected.

This all leads to people getting the wrong impression. As you say, it is hard to get people to update software on their servers, but they don't even know that they have to - because it's distributed, today, and simple - so they aren't going to be looking. Another group of people are going to look at the spec and implementations and think: what is the point of yet another login scheme which just pipes everything through mozilla?

This is not going to help the adoption of browserid.

[sergiotapia]

I see what you mean now. I understand, but don't know how I could fix this. _Can_ this be fixed with the current state of Persona?

Specifically:

>Gmail key cached, and can verify the assertion without any http requests to anywhere.

Would love to read some example code if you have some. Thanks!

[groks]

This is the best example I've found:

https://github.com/mozilla/PyBrowserID/blob/master/browserid...