3 ms·

While I think Persona is way better than password-based auth, I can't help but feel that it's also a sideways step. No, authentication should be provided by the

While I think Persona is way better than password-based auth, I can't help but feel that it's also a sideways step. No, authentication should be provided by the user-agent, not by some third party identity provider (even if you control it by running your own). We have this for ssh: you have your private ssh key and it's up to you to manage having it in the right places (work desktop, laptop, phone, etc.) It's clunky, but that's OK: it's aimed at tech people. Browsers should do something similar: provide a storage for private and public keys as proof of identity. But they should additionally provide a way to sync those identities across multiple browsers and machines. This latter concept will be familiar to anyone who has used LastPass. The former, well it should basically be a dropdown with your identities, and you choose one before clicking the "Login" button.

mgbmtl 11y ago
To some extent, this is similar to SSL/TLS certificates that can be used to authenticate the user (not just the server). If I recall correctly, http://startssl.com/ http://startssl.com/ does that. It's not a very intuitive mode of authentication, but if the UI was improved, and combined with a sync service (& encrypted with a passphrase), I guess it could be usable? (also, presumably it requires the site to use https, but that's also much more expected today than it was 10 years ago)
- IgorPartola 11y ago
  Yeah, basically this. I have used it before and client side TLS certs are anything but intuitive. They are also not widely supported.
deno 11y ago
BrowserID works by default with email but it has absolutely to dependency on email. It uses it for namespacing and bootstrapping, but nothing else. So foo@bar.com may or may not have any MX records, all that is required is that bar.com can provide an assertion that you control foo@bar.com. The way bar.com determines that is entirely up to bar.com, it can be a password, smart crypto card, local kerberos or Windows auth, 3-way auth involving your cat Rufus, etc... https://developer.mozilla.org/en-US/Persona/Protocol_Overview https://developer.mozilla.org/en-US/Persona/Protocol_Overvie...

mgbmtl 11y ago

To some extent, this is similar to SSL/TLS certificates that can be used to authenticate the user (not just the server). If I recall correctly, http://startssl.com/ http://startssl.com/ does that. It's not a very intuitive mode of authentication, but if the UI was improved, and combined with a sync service (& encrypted with a passphrase), I guess it could be usable? (also, presumably it requires the site to use https, but that's also much more expected today than it was 10 years ago)

IgorPartola 11y ago
Yeah, basically this. I have used it before and client side TLS certs are anything but intuitive. They are also not widely supported.

deno 11y ago

BrowserID works by default with email but it has absolutely to dependency on email. It uses it for namespacing and bootstrapping, but nothing else. So foo@bar.com may or may not have any MX records, all that is required is that bar.com can provide an assertion that you control foo@bar.com. The way bar.com determines that is entirely up to bar.com, it can be a password, smart crypto card, local kerberos or Windows auth, 3-way auth involving your cat Rufus, etc... https://developer.mozilla.org/en-US/Persona/Protocol_Overview https://developer.mozilla.org/en-US/Persona/Protocol_Overvie...