

Mozilla Persona (BrowserID) is a step in the wrong direction - zaroth
http://www.opine.me/mozilla-persona-browserid-is-a-step-in-the-wrong-direction/

======
callahad
Hi Zaroth,

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.

