https://github.com/sergiotapia/ASP.Net-MVC3-Persona-Demo
Please give this a shot! I would only like them to keep more information on hand, like a first name, or an avatar so I don't pester my user with such requests.
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).
---
>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.
So, if tomorrow Google added support for browserid to Gmail, and jo@gmail.com tries to log in to your website, he would claim to be jo@gmail.com 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 jo@gmail.com 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.
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!
https://github.com/mozilla/PyBrowserID/blob/master/browserid...
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:
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.
We have a list of libraries/plugins in a ton of other languages on MDN: https://developer.mozilla.org/en-US/docs/Persona/Libraries_a...