3 ms·

> Passwordless works for users whose email providers are not also major OAuth providers, which is nice, but also pretty niche. You're making a flawed assumptio

> Passwordless works for users whose email providers are not also major OAuth providers, which is nice, but also pretty niche. You're making a flawed assumption that just because a major email provider offers OAuth, that websites themselves will also integrate with that OAuth provider. Yahoo Mail supports OAuth, but that's not worth a damn if sites don't explicitly integrate with Yahoo and provide a "Sign in with Yahoo" button. That's why we need email-based authentication. Because, in practice, sites are going to integrate with Gmail and Facebook and call it a day. (On the flipside, there's a great opportunity for Passwordless to offer optional, transparent integration with major OAuth providers, while falling back to an email loop for everyone else so people don't get locked out. That's what we did for Persona, and it mostly worked wonderfully.)

aianus 11y ago
> That's why we need email-based authentication. Because, in practice, sites are going to integrate with Gmail and Facebook and call it a day. So what? That covers like 95% of web users right there and if some users don't like it they can go through the full signup flow.
- dreamfactory2 11y ago
  That's a very Western centred view. We really seem to be losing sight of the internet as a global shared infrastructure, which was the point of the whole thing and where the benefits have come from. On the present course we might as well be going back to the arid experiences of fido and minitel.
pfooti 11y ago
> You're making a flawed assumption that just because a major email provider offers OAuth, that websites themselves will also integrate with that OAuth provider. Yahoo Mail supports OAuth, but that's not worth a damn if sites don't explicitly integrate with Yahoo and provide a "Sign in with Yahoo" button. I'm not really sure I buy this premise. As a developer, it's my job to provide login options. I'm 100% on board with not providing a username / password option unless my bosses demand it and ignore my counterarguments. But I fail to see how the passwordless model is not just an equivalent case with using lots of OAuth2 plugins. It's a neat system, don't get me wrong. I could see using it in addition to a typical suite of OAuth providers. But I don't see it as a drop-in, solve-everything replacement for OAuth2. It's really just a (node / express) library that approaches the same problems but exposes different implementation issues instead.

aianus 11y ago

> That's why we need email-based authentication. Because, in practice, sites are going to integrate with Gmail and Facebook and call it a day. So what? That covers like 95% of web users right there and if some users don't like it they can go through the full signup flow.

dreamfactory2 11y ago
That's a very Western centred view. We really seem to be losing sight of the internet as a global shared infrastructure, which was the point of the whole thing and where the benefits have come from. On the present course we might as well be going back to the arid experiences of fido and minitel.

pfooti 11y ago

> You're making a flawed assumption that just because a major email provider offers OAuth, that websites themselves will also integrate with that OAuth provider. Yahoo Mail supports OAuth, but that's not worth a damn if sites don't explicitly integrate with Yahoo and provide a "Sign in with Yahoo" button. I'm not really sure I buy this premise. As a developer, it's my job to provide login options. I'm 100% on board with not providing a username / password option unless my bosses demand it and ignore my counterarguments. But I fail to see how the passwordless model is not just an equivalent case with using lots of OAuth2 plugins. It's a neat system, don't get me wrong. I could see using it in addition to a typical suite of OAuth providers. But I don't see it as a drop-in, solve-everything replacement for OAuth2. It's really just a (node / express) library that approaches the same problems but exposes different implementation issues instead.