141–150 of 188 posts
So I can log in everywhere using the exact same username? This will make it SO much easier for the user data trackers to capture and aggregate all of the information they can about me. I think I'll take a pass.
You can choose any email address you control. Persona doesn't force you to use one identity. Sites that use Facebook connect on the other hand...
Earlier quoted context omitted.
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…
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 o…
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.
Earlier quoted context omitted.
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 o…
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…
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!
Why promote Yahoo!'s email service? They still don't use SSL after you are logged in right? Sending your plaintext session cookie over the net, allowing people in your coffee shop to hijack your email. Nobody should be encouraging people to keep or get Yahoo email accounts.
Earlier quoted context omitted.
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 o…
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…
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.
Why promote Yahoo!'s email service? They still don't use SSL after you are logged in right? Sending your plaintext session cookie over the net, allowing people in your coffee shop to hijack your email. Nobody should be encouraging people to keep or get Yahoo email accounts.
can somebody explain to me why this is so much better than openid ?
Earlier quoted context omitted.
It's still pretty new (as the link states, it's still in beta). I'd say that is probably a big part of it. That, and the whole federated/shared/social login space is confusing ! First there was OpenID, but then everyone jumped to OAuth. But wait, OAuth isn't really about authentication?! Throw in xAuth and all of Eran Hammer's rants, and you quickly realize that anything resembling consensus is pretty tenuous, at bes…
OAuth is still very useful if you need more data from a user than just that he's who he says he is. If your app processes user data from another source, OAuth is still the best choice. Also, people recognize Facebook and Google as brands they already have accounts with. When a user sees a big blue/red Sign In With Facebook/Google button, that's an easier decision than hand-keying your credentials (especially on a tin…
That said, many of the applications that feature "sign in with Facebook", don't actually need access to my Facebook account. They may just be trying to make it easier for the user to sign in, but they also sometimes abuse that trust, and start posting things on your behalf.
Frankly, I'd much rather generate a random password for randomsiteijustfound.com and not worry too much about their password-hashing policy than trust them to do the right thing with access to my Facebook account.
This is why I like Persona -- if a site really just wants to make it easy for me to sign in, they'll use Persona, and I won't have to worry about them abusing my trust, because I'm not granting them access to anything else. Once I feel like they're trustworthy or useful enough, I can consider granting them OAuth authorizations to my Facebook account.