There an "online pin" system called 3DSecure (also known as Verified By Visa) that uses a system of tokens passed by JavaScript to present the user with a form that's held on their bank's servers. Implementing it is optional for the merchant, but if they choose not to then they're accountable for any fraud. If they do then liability is passed to the customer.
It's all very favourable to the credit card companies.
Long-running programs will happily continue using the same file handle until they are signaled in some way to reopen the file path (usually in response to USR1 and HUP). See Nginx, Apache httpd, MongoDB, etc.
> So your email provider doesn't know where you're logging in.
This is already the case. For browsers that use the shim, the certificate is stored in localStorage on the login.persona.org domain, and then given to the website you're trying to login to.
Whichever technology you want to use is fine. You need to publish 3 routes: /.well-known/browserid, an auth route, and a provision route.
The auth and provision routes need to be HTML pages that authenticate you however you want, and then sign a certificate with your key that you publish the .well-known file.
In short: easier to implement, everyone has an email address, improved privacy. OpenID tells the provider every time you log in to any website, Persona does not.
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.
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:
> 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.
I don't think it's so much to keep working on the prototype afterwards, but to be able to export it out of the tool (Napkin) and still be able to easily show someone your prototype.
