Thank you for the thoughtful post! I'm about to hop on a flight, so this is a bit hasty, but you raise a bunch of good points, and I wanted to thank you for the thoughtful post. I've forwarded this to the Mozilla dev-identity mailing list, and I think it will be helpful as we announce our Beta and polish the service and protocol.
For updates on a few specific points:
> "Teaching users that it’s OK to type their credentials into popups is just crazy."
We agree, and are working on adding native support to Firefox so that users only enter their credentials in the browser chrome, and never in page content. We're also working on a project that will authenticate Gmail, Hotmail, and Yahoo users via OpenID or OAuth, eliminating both the Persona password and the verification email.
Native support should land in Firefox 17 (off by default), and the provider bridge should go live in 4-6 weeks.
> "The only way I could find to actually clear out my cached credentials from Persona.org was to go back into the Login dialog and click the ‘This is not me’ button."
You can also sign out by going to https://login.persona.org/ and clicking "sign out," but that's not ideal either. Native support in the browser will make this much better. If I recall correctly, we did some user testing earlier this year and found that no matter which option we went with -- logging out everywhere or just logging out of the site at hand -- a very large percentage of users were confused.
Do you have any alternative ideas for approaching this?
> "The Login dialog opened as if an email address should have been listed, but no email was present."
What sort of connection were you on? If I recall correctly, we've seen similar issues when users are on slow connections / high packet loss connections. I've filed a bug to investigate: https://github.com/mozilla/browserid/issues/2090
> "Validation is complicated enough they don’t want sites trying to do it themselves"
The data formats are still in flux while we wait for the IETF to finalize some specs, but if you don't mind keeping your validator up to date, you're totally welcome to do local validation. You can either reuse our validator (writtin in NodeJS), or use PyBrowserID which has experimental support for local validation.
This stuff will stabilize in mid-August when we formally anounce a "Beta" release and commit to API stability, etc. We're almost there! For the working group progress, see http://datatracker.ietf.org/wg/jose/charter/
> "even if a domain does advertise support for BrowserID, that doesn’t exclude certificates from being accepted that are generated by Persona.org."
> "Does BrowserID tell you if the user just recently reset their password? No."
Brian Warner has implemented something like this, which invalidates all login.persona.org-backed sessions upon a password change. Pull Request #2026: https://github.com/mozilla/browserid/pull/2026
> "The fact is, when BrowserID says ‘okay’, you don’t have any assurance the person on the other end even knows the user’s password. [...] requiring the website to abdicate all responsibility to a black box that just says ‘okay, let foo in’"
I strongly disagree with this characterization -- for the case of users with native IdP support, you're assured that the user agent successfully authenticated with the email provider within a window of time determined by that provider. For users of our fallback, this is never more than 24 hours, and in the case of public computers, is one hour by default.
That's a much stronger claim than you can make with a traditional password-based system, where a sniffed credential can be valid for months.
Thank you for the thoughtful post! I'm about to hop on a flight, so this is a bit hasty, but you raise a bunch of good points, and I wanted to thank you for the thoughtful post. I've forwarded this to the Mozilla dev-identity mailing list, and I think it will be helpful as we announce our Beta and polish the service and protocol.
For updates on a few specific points:
> "Teaching users that it’s OK to type their credentials into popups is just crazy."
We agree, and are working on adding native support to Firefox so that users only enter their credentials in the browser chrome, and never in page content. We're also working on a project that will authenticate Gmail, Hotmail, and Yahoo users via OpenID or OAuth, eliminating both the Persona password and the verification email.
Native support should land in Firefox 17 (off by default), and the provider bridge should go live in 4-6 weeks.
> "The only way I could find to actually clear out my cached credentials from Persona.org was to go back into the Login dialog and click the ‘This is not me’ button."
You can also sign out by going to https://login.persona.org/ and clicking "sign out," but that's not ideal either. Native support in the browser will make this much better. If I recall correctly, we did some user testing earlier this year and found that no matter which option we went with -- logging out everywhere or just logging out of the site at hand -- a very large percentage of users were confused.
Do you have any alternative ideas for approaching this?
> "The Login dialog opened as if an email address should have been listed, but no email was present."
What sort of connection were you on? If I recall correctly, we've seen similar issues when users are on slow connections / high packet loss connections. I've filed a bug to investigate: https://github.com/mozilla/browserid/issues/2090
> "Validation is complicated enough they don’t want sites trying to do it themselves"
The data formats are still in flux while we wait for the IETF to finalize some specs, but if you don't mind keeping your validator up to date, you're totally welcome to do local validation. You can either reuse our validator (writtin in NodeJS), or use PyBrowserID which has experimental support for local validation.
This stuff will stabilize in mid-August when we formally anounce a "Beta" release and commit to API stability, etc. We're almost there! For the working group progress, see http://datatracker.ietf.org/wg/jose/charter/
> "even if a domain does advertise support for BrowserID, that doesn’t exclude certificates from being accepted that are generated by Persona.org."
We're tracking that in Issue #1501: https://github.com/mozilla/browserid/issues/1501
> "Does BrowserID tell you if the user just recently reset their password? No."
Brian Warner has implemented something like this, which invalidates all login.persona.org-backed sessions upon a password change. Pull Request #2026: https://github.com/mozilla/browserid/pull/2026
> "The fact is, when BrowserID says ‘okay’, you don’t have any assurance the person on the other end even knows the user’s password. [...] requiring the website to abdicate all responsibility to a black box that just says ‘okay, let foo in’"
I strongly disagree with this characterization -- for the case of users with native IdP support, you're assured that the user agent successfully authenticated with the email provider within a window of time determined by that provider. For users of our fallback, this is never more than 24 hours, and in the case of public computers, is one hour by default.
That's a much stronger claim than you can make with a traditional password-based system, where a sniffed credential can be valid for months.